- 公開日
AI利用ポリシーを現場で使える形にするには、方針の一項目ごとに「どの条件なら何をするか」「できないときは何へ切り替えるか」「誰が、どの仕組みで止めるか」を決めます。禁止文をプロンプトへ写すだけでは、入力してはいけない情報の送信や、許可されていない操作を止める仕組みにはなりません。
まず一つの業務に絞り、規程の文言、現場の手順、AIへの依頼、実際の制限を対応させましょう。ここでは顧客からの問い合わせを整理する架空の業務を使い、方針を具体的な動作へ変える方法を説明します。後半では、ポリシーで最低限決める項目と、社内文書にそのまま使える雛形を示します。
規程の一文を、判断できる条件へ分ける
架空の社内規程に「顧客を識別できる情報と契約上の秘密情報は、一般向けAIサービスへ入力しない。業務上必要な場合は、情報管理責任者が認めた経路と用途に限る」とあるとします。問い合わせには氏名、連絡先、注文番号、商品への要望、個別の契約条件が含まれています。
業務の目的は、よくある要望をまとめてFAQの改訂候補を作ることです。顧客本人への返答や注文の更新は含めません。この目的なら、氏名や注文番号を使わずに整理できる部分があります。一方、個別契約の内容がなければ判断できない問い合わせは、同じ手順で処理できません。
「顧客情報に注意する」という表現を、次のような判断へ分けます。
- 入力前に、担当者が情報の種類と利用目的を確認します。
- 不要な識別情報や秘密情報は、承認された社内の処理環境で取り除きます。
- 一般化した要約で目的を達成できるなら、元の意味を保って要約し、その要約自体の入力可否を確認します。
- 必要な情報を除くと判断できない場合は、承認済み経路の利用条件を照合します。条件が不明なら処理を保留します。
これは架空規程に基づく運用例です。自社へ適用するときは、規程の対象情報、許可サービス、契約条件を実際の資料で確かめます。「社内で作成した要約だから入力できる」とは判断しません。
入力制限は、送信する前の作業へ置く
禁止情報を含む原文を一般向けAIへ渡してから「個人情報を削除してください」と頼むと、そのサービスへの入力は既に起きています。削除を依頼する場所と、削除後の情報を利用する場所を分ける必要があります。
この例では、担当者が承認された社内環境で入力用の文章を準備します。元の問い合わせが「担当者名、連絡先、注文番号、交換希望の事情」を含む場合、FAQ案に必要なのは「交換条件を分かりやすく知りたいという要望」のような内容です。ただし、氏名を消しても、珍しい取引条件や出来事の組み合わせが残れば顧客を特定できることがあります。機械的な置換だけで入力可とせず、残った情報を目的と規程に照らして確認します。
OWASPの「LLM02:2025 Sensitive Information Disclosure」は、機密情報の入力検査や必要最小限のアクセスを対策に挙げる一方、システムプロンプトの制限が常に守られるとは限らないと説明しています。ここで示す事前確認は、その注意点をこの業務へ適用するための設計例です。
入力する文章だけでなく、添付ファイルや検索で取得する情報にも同じ確認が必要です。本文から氏名を消しても、添付された原本や参照先から再び取得できれば、利用範囲は絞れていません。入力経路全体を対象にし、確認できない経路は使わない状態から始めます。
禁止事項と代替行動を、短い依頼文へ落とす
元の依頼が「問い合わせを読み、FAQ案を作ってください。顧客情報は出さないでください」だけでは、どの資料が使えるか、情報が足りない場合に何を返すかが曖昧です。事前処理を終えた入力に対して、次の依頼へ変えられます。
入力可と確認済みの問い合わせ要約だけを使い、FAQの改訂候補を作成してください。
各候補に、要望の要約、案の根拠になった入力箇所、確認が必要な点を付けてください。
氏名、連絡先、注文番号、個別の契約条件を推測して補わないでください。
禁止情報と思われる内容が残っている場合は、その内容を回答へ転載せず、該当箇所を識別できる項目番号と確認理由を示して、その項目の処理を保留してください。
追加情報が必要な場合は必要な情報の種類を示し、担当者の確認へ戻してください。
顧客への送信や注文変更は行いません。この依頼の意図は、使える資料とできる仕事を限定し、困ったときの返し方を具体化することです。「入力可と確認済み」という表示は担当者の確認を表すもので、AI自身が規程適合を認証するものではありません。差し替える箇所は対象業務、禁止情報の種類、出力項目、照会先です。
情報不足の項目には「個別条件の確認が必要」と返すことを期待します。残りの要約だけで成立するFAQ案は作成できますが、除外した情報を推測で埋めてはいけません。処理を止める範囲は、不足や禁止情報が影響する範囲に合わせます。
回答後は担当者が、元の承認済み要約と各候補を照合します。入力にない条件の追加、顧客の再特定につながる記述、未確認事項の断定がないかを確認し、問題があれば該当候補を差し戻します。これは期待する手順であり、この依頼文の性能を実測した結果ではありません。
文言とは別に、アクセスと操作を制限する
プロンプトが担うのは、要約の仕方や不足時の回答など、AIへ求める振る舞いです。顧客データへのアクセス、送信先、外部操作の可否は、利用者の注意と文章指示だけに依存させない設計が必要です。
たとえばFAQ案の作成用環境では、顧客データベース全体の検索権限やメール送信機能を付けず、確認済み要約だけを参照できるようにします。承認済み経路へ切り替える場合も、利用者、対象情報、目的が承認の範囲内かをシステムと担当者で確認します。AIが「承認されています」と出力したことを承認の証拠にはしません。
OWASPの「LLM07:2025 System Prompt Leakage」は、権限の分離や認可の境界チェックをLLMへ委ねず、独立して強制するよう求めています。実装する場合は、誰が何へアクセスできるかをアプリケーション側で判定し、記録から追える状態にします。
管理者は、文言が存在することと制限が働くことを別々に確かめます。架空の識別情報を使った試験で、禁止対象が入力前に止まるか、未許可の参照が拒否されるか、承認済み要約は処理できるかを確認する設計にします。拒否メッセージが出ても、その前に情報が送られていれば入力制限の確認には合格しません。
担当者と証拠を、一つの記録で結ぶ
方針と手順の対応を維持するため、次のような記録を用意します。以下は架空業務の記録様式で、実施済みの確認結果ではありません。
| 記録する対象 | 判断する人 | 残す証拠と状態 |
|---|---|---|
| 規程の適用範囲 | 情報管理責任者 | 規程の版、対象情報、認める用途、例外条件 |
| 入力用要約の利用可否 | 業務担当者、必要に応じ責任者 | 原資料の管理番号、削除・要約した範囲、確認日、判断理由 |
| 権限と送信経路 | システム管理者 | 設定の識別情報、確認対象、期待動作、試験結果または未確認 |
| FAQ案の採否 | 業務責任者 | 参照した入力箇所、修正内容、採用・差戻し・保留 |
証拠を残すために、禁止情報を別の共有表へコピーしないようにします。原本は許可された保管先に置き、記録には必要な参照と判断理由だけを残します。照会先が不在なら、影響する処理を保留します。承認済み経路を使えない場合も、未承認のサービスへ持ち替えず、社内で人が整理する手順へ戻します。
NISTのAI RMF Playbook「Govern」は、組織の方針・プロセス・手順への反映（GOVERN 1.2）、AIリスクに関する役割・責任と連絡経路の明確化（GOVERN 2.1）、リスク管理プロセスの継続的な監視と定期的な見直し（GOVERN 1.5）を挙げています。上の表は、これらを一つの業務の記録へ落とした例です。なお、Playbookは自主的な利用のための指針です。この表の形式や役職名が、すべての組織に一律に義務付けられているわけではありません。
AI利用ポリシーで最低限決める項目
一つの業務で方針を動作へ落とせたら、同じ考え方をポリシー全体へ広げます。次は、社内ポリシーで少なくとも決めておきたい項目の例です。記入例は架空の小規模事業者を想定したもので、業種や扱う情報に応じて調整が必要です。
| 項目 | 決める内容 | 記入例 |
|---|---|---|
| 対象サービスと業務 | 使ってよいAIサービスと、使う業務 | 承認済みサービス一覧に載るものだけ。問い合わせの整理やFAQ案の作成に使う |
| 入力してよい情報 | 情報の区分と、迷ったときの判断者 | 公開情報と社内の一般情報は可。顧客を特定できる情報は不可 |
| 出力の確認 | 誰が、何と照合するか | 業務担当者が、元の資料と照合してから使う |
| AIに任せない操作 | 送信・削除・支払いなど | 送信と削除は人が行う |
| 迷ったときの行き先 | 照会先と、確認までの代替手順 | 情報管理責任者へ照会。確認までは手作業で対応 |
| 記録 | 残す項目と保存期間 | 判断理由・確認者・日時。原文は参照先だけ記録 |
| 例外の申請 | 新しいサービスや用途の申請先 | 情報システム担当が審査し、責任者が承認 |
| 見直し | 責任者と時期 | 半期ごと、またはサービス追加時 |
よくある失敗は三つあります。禁止事項の一覧だけで、迷ったときの行き先がないこと。方針をプロンプトに貼るだけで、入力前の確認がないこと。AIエージェントのようにツールを操作できる仕組みを使い始めたのに、送信や操作の権限を決めていないことです。表の「迷ったときの行き先」と「AIに任せない操作」は、これらを埋めるための項目です。
AI利用ポリシーのテンプレート
上の表の項目を、そのまま社内文書に貼れる雛形にしたものです。空欄を自社の内容で埋めて使います。
【AI利用ポリシー（雛形）】第＿版／適用日：＿＿＿＿／責任者：＿＿＿＿
1. 対象サービスと業務
使用してよいAIサービス：承認済みサービス一覧（管理：＿＿＿＿）に記載のもの
使用してよい業務：＿＿＿＿
2. 入力してよい情報
入力可：公開情報、社内の一般情報
入力不可：顧客・従業員を特定できる情報、契約上の秘密情報、＿＿＿＿
判断に迷う場合：入力せず、＿＿＿＿へ照会する
3. 出力の確認
確認者：＿＿＿＿
照合する資料：元の資料・問い合わせ原文
外部へ出す前に必ず人が確認する
4. AIに任せない操作
送信、削除、支払い、権限変更、＿＿＿＿
5. 迷ったときの行き先と代替手順
照会先：＿＿＿＿
確認が済むまでの対応：手作業、または一般的なテンプレートのみAIで作成
6. 記録
残す項目：判断理由、確認者、日時、参照先（原文は複製しない）
保存期間：＿＿＿＿
7. 例外の申請
新しいサービス・用途の申請先：＿＿＿＿
承認者：＿＿＿＿
8. 見直し
時期：半期ごと、またはサービス追加時
見直す人：＿＿＿＿この雛形は架空の小規模事業者を想定した例で、特定の法令やガイドラインが定める様式ではありません。業種や扱う情報、適用される法令に応じて項目を追加してください。雛形に書いた禁止事項も、プロンプトへ貼るだけでなく、前半で示したように入力前の確認、権限の設定、記録へ対応させて初めて現場で働きます。
AI利用ポリシーでよくある質問
ポリシーとガイドラインは、どう分ければよいですか。
呼び方は組織によって異なります。この記事では、守るべき決まり（使ってよいサービス、入力してはいけない情報、AIに任せない操作）をポリシー、具体的な使い方や依頼文の例を手引き（ガイドライン）として分けています。一つの文書にまとめても構いませんが、決まりと例を区別して書くと、例を更新するたびに決まりまで変わったように見える混乱を防げます。
無料版や個人のアカウントで使ってよいかは、どこに書きますか。
雛形の「1. 対象サービスと業務」に書きます。承認済みサービス一覧に載っていないもの、たとえば業務用に契約していない無料版や個人アカウントを使ってよいかを明記します。決めていないと、利用者ごとに判断が分かれ、入力した情報の扱いを組織が把握できなくなります。
決めたポリシーは、どう周知すればよいですか。
適用日、対象者、照会先を一緒に伝えます。配布するだけでなく、対象業務の担当者が「入力してよい情報」と「迷ったときの行き先」を説明できるかを確かめます。改訂したときは版と適用日を更新し、旧版を使い続ける人が出ないよう配布先をそろえます。
小さな組織でも、全項目を最初から決める必要がありますか。
最初は、AIを使っている一つの業務について、雛形の1〜5（対象サービスと業務、入力してよい情報、出力の確認、AIに任せない操作、迷ったときの行き先）から決める方法があります。記録・例外の申請・見直しは、利用する業務やサービスが増えた段階で加えます。ただし、入力してはいけない情報と、AIに任せない操作は、最初から決めておきます。
方針と現場がずれたときに見直す
規程、利用サービス、対象情報、接続機能が変わったときや、保留が繰り返されて業務が進まないときは、対応表へ戻ります。禁止文を増やす前に、入力用要約を作れるか、許可経路が使えるか、判断者が決まっているかを確認します。更新するときは、責任者が適用日と対象業務を決め、ポリシー、テンプレート、確認項目を一緒に改め、旧版を使い続ける人が出ないよう配布先をそろえます。
事前処理には担当者の確認時間がかかり、権限を分けるには設定や試験も必要です。負担が大きい場合は、扱う業務や資料の範囲を狭める選択もあります。禁止条件を外して負担を減らすのではなく、許可された範囲で続けられる作業を決め、方針の一文が具体的な動作と証拠につながっているかを確かめましょう。
AIを使う前に確かめる12項目は「AIを使う前の安全確認チェックリスト」にまとめ、記入用のAIKYシート（PDF・Excel）も配布しています。
基本から確認する：この記事の前提になる考え方は、「プロンプトの書き方ガイド（依頼文の基本6項目と例文）」にまとめています。
