機密情報をLLMに入力してよいかどうかは、「個人情報だから禁止」「学習をオフにしたから安全」という基準では決まりません。守るべき対象は、許可していない相手に渡さないことです。入力を止めることだけが唯一の手段ではありません。
📑目次
判断の単位は3つあります。テクノロジーの現場では、この3つをすべて同時に満たせるタスクだけを通します。
- 情報分類（Public / Internal / Confidential）
- LLM環境（組織が契約・保存先・学習利用を確認できる Managed か、個人契約の Unmanaged か）
- Tool Call の露出範囲（メール送信、投稿、任意URLの取得など、外へ運べる呼び出し）
会社契約のAPIで顧客メールを要約し、元担当者だけに返すなら、LLMへの入力はありますが、許可外の相手には渡っていません。逆に、エージェントがファイルパスだけをTool Callに載せて公開チャンネルへアップロードすると、中身がモデルを経由しなくても機密情報は外へ出ます。
貼る前にデータを分類し、環境がManagedかどうかを確認し、露出系のTool Callの宛先を許可相手に限定します。書けない場合は、そのタスクでは出しません。
テクノロジー現場向け：分類・環境・露出先の判断表
現場の既定は、行を上から当てはめ、1つでも満たせないならそのタスクでは出さない、です。表は方針です。規制業種の契約（BAAなど）は別途確認してください。
| 情報分類 | LLM環境 | Tool Call の条件 | 現場の既定 |
|---|---|---|---|
| Public | Unmanaged でも可 | 取込系に Public 以外を混ぜない | 個人ChatGPT可。社内文書を混ぜたら即停止 |
| Internal | Managed 必須 | 露出先が社内に収まる | 個人アカウント禁止。チャンネル全員が読める範囲だけ検索 |
| Confidential | Managed 必須 | 露出先を許可相手に限定。必要なら人の承認。取込は露出先に出してよい情報だけ | 学習OFFだけでは不足。send_email 等は実行前検査 |
表の出典
出典は次の4件です（2026年8月時点）。
- OpenAI Help（データ利用）
- OWASP AI Agent Security Cheat Sheet
- AgentFlow（arXiv 2608.22868v1）
- Claw in Plain Sight（arXiv 2608.20658）
禁止文の根拠になる調査数値
数値も禁止文の根拠として使います。出典の数値は調査時点の二次引用であり、自社の実測値ではありません。
- C2 Data Technology は、従業員の27%が機密を公開AIへ入力し、職場のAI利用の3分の2が個人アカウントだと整理しています（Salesforce、Verizon DBIR / LayerX 経由の二次引用）。
- 時事通信（2026-08-25） は、Microsoft 調査として日本のナレッジワーカーのシャドーAIを78%と伝えています。
表を満たせない場合の代替手段は、マスキング、必要フィールドのみの抽出、ローカルLLM、人間だけの処理です。ローカル実行そのものが機密の許可証ではなく、外部送信口が残っていないかが条件です。
学習OFFと貼り付け禁止では機密は止まらない
個人ChatGPTの学習OFFは、「その会話がモデル改善に使われない」設定です。組織が保存先・再委託・Tool Callを制御できることと同義ではありません。
同じモデル名でも契約経路が違う
OpenAI Help は、契約経路で学習利用を分けています。
- 個人向け ChatGPT / Codex は、オプトアウトしない限り学習利用しうる
- ChatGPT Business / Enterprise / API は、既定で入出力を学習に使わない
同じモデル名でも、契約経路が違えば環境が異なります。個人アカウントで学習をオフにしても、消費者向け経路のままです。
貼り付け禁止が見ない経路
貼り付け禁止の限界は、経路の数にあります。C2 Dataは、機密情報がLLMに入る経路を3つに分けています。
- プロンプトへの貼付
- RAG / エージェントの tool context
- 学習・ファインチューニング
禁止文は、利用の3分の2を占める個人アカウントを見ません。同記事が引用する DataGrail 2026 では、調査した 2,400 の AI ベンダーのうち 63.6% が、サードパーティ AI 再委託を法務文書で開示していません。承認済みツールでも、サブプロセッサが未開示なら Confidential は載せない判断になります。
日本側の裏取り
日本側の裏取りも、禁止だけでは足りない方向です。時事通信は次を整理しています。
- Samsung 型のソース貼付
- 日本 78% の無許可利用
- IBM Cost of a Data Breach 2025 で侵害の 20% がシャドーAI起因
BBSec SQAT（2026-08-26 更新） は、アクセス制御が正しくても外部生成AIへ貼れば別経路で外へ出ると書いています。ACL を通ったあとに、ブラウザの個人タブが残っている、という構造です。
禁止ポリシーは必要ですが、それだけでは制御になりません。先に置くべきは、承認済みのManaged経路です。禁止を強く打ち出すと、計測できない個人アカウントに仕事が流れるようになります。
Managed LLM環境かどうかを確認する
Managedとは、「会社が契約し、入力の行き先を確認・制御できる」ことです。モデル名や「社用PC」では足りません。テクノロジー部門が許可した拡張機能でも、ログイン主体が個人ならUnmanagedです。
確認の順
確認は次の順序で十分かどうかを調べます。
- 契約主体が組織か個人か。個人の無料 / Plus は Unmanaged です。
- 学習利用の既定。Business / Enterprise / API は OpenAI 公式で既定オプトアウトです。個人はオプトアウトしても消費者向け経路です。
- 保存期間、リージョン、サブプロセッサ。未開示なら Confidential を載せません。
- ログと監査。プロンプトや tool 引数が平文で残るなら、Confidential は対象外です。
ローカルLLMと社内ボット
外部へ出せないデータはローカルLLMを使う、という切り分けは時事通信も推奨しています。ただし「学習しない」は入力そのものを消すわけではありません。要約結果を誰に再配布するかは、別の認可の問題です。C2 Dataが示すCSAのパターンは次の通りです。
- プロンプトや tool call の前に PII を redact する
- コンテキストに入るフィールドを最小化すること
社内ナレッジボットでも同じです。Managed なら条件付きで使えますが、露出先はチャンネル読者全員です。検索対象は、そのチャンネルに出してよい文書だけにします。質問者本人が権限を持たない文書まで取込ませない、は 本番障害の一次調査をAIに渡す前の ReadOnly と人間承認 と同じ考え方です。読み取り専用でも、後続の送信口があれば持ち出しになります。
Tool Callの露出先は実行前に絞る
エージェントの読み取り権限と、そのデータをどの宛先に送ってよいかは、別の認可です。プロンプトに「機密を出すな」と書いても、それは執行境界にはなりません。
プロンプト指示では止まらない（Claw）
Claw in Plain Sight（arXiv 2608.20658） は、120 セッションでセッション単位の開示を 20.8–75.0% と報告しています。
- 強いプライバシー指示でも S0 66.7% から S3 26.7% まで下がるだけで、止まりません
- Claude 設定は S3 でも 18 中 8 が漏洩しています
- 検査位置は tool 実行前です
- 読めてよいフィールドでも、tool 引数へ無断コピーしうる、が論文の論点です
この論文は合成プロファイルと生成引数の観測であり、実ユーザーの流出率ではありません。
多段フローはリクエスト単位の認可では表せない（AgentFlow）
フロー側は AgentFlow（Virginia Tech、2026-08-24） が、次を分けます。
- 顧客レコード読取は可
- メール送信は可
- SSN を外部メールするのは持ち出し
各ステップが局所的に正当でも、つながると方針違反になります。AgentDojo 949 件では、確認済み侵害 33.0% が 0.0%、utility 46.7% が 63.3% です。リクエスト単位の認可（誰が何をしてよいか）では、多段フローを表せません。AgentFlow のスコープは、ポリシー可視な tool / sink です。
権限の種類で手順を分ける
手順は権限の種類ごとに分けます。
- 取込系（ファイル読取、社内検索）は、露出先に出してよい情報だけを対象にします。
- 露出系（メール、投稿、任意URL fetch）は、宛先が分類の許可相手に収まるかを見ます。クエリに機密を載せる fetch は露出系です。
- 書き込み・実行は人の承認です。OWASP は次を確認対象に列挙し、認可をモデル出力に頼るなと書いています。
– send_email
– execute_code
– database_write
– file_delete
Qiita の c_u（2026-08-30） は、同一 MCP でも読み取り専用なら L1、書き込み許可なら L3 と整理し、
ALLOW_WRITE_OPERATIONSの既定は false です。読み取りトークンと書き込みトークンは分けます。 - 間接プロンプトインジェクションを前提にします。私有データ、非信頼コンテンツ、外部送信が揃う構成は組みません。時事通信が挙げる「顧客リストを送れ」が文書に入るケースは、実行前検査で止める対象です。
プロンプト側の認可境界の書き方は、指示文の削減には効果がありますが、停止装置にはなりません。参照は次の通りです。
- GPT-5.6 の lean system prompt と認可境界
- MCP の都度同意をどこで切るかは OBO と認可サーバーの判断基準
- 学習の順番を先に置きたい場合は AIセキュリティ学習ロードマップ2026
出してよいかを決めるチェックリスト
次にやるべきことは、1タスク1行で記録することです。空欄が1つでもあれば、そのタスクでは出しません。
- 情報分類を Public / Internal / Confidential で書いた。迷うなら Confidential。
- LLM経路は組織契約の Managed か。個人ChatGPT・個人APIキーなら Internal 以上は中止。
- 学習OFFを確認したか。確認しても個人経路なら Managed ではない。
- 取込対象は、この露出先に出してよい文書だけか。質問者本人が読めない範囲を検索させていないか。
- 露出系 Tool Call の宛先は許可相手に閉じているか。send_email / 投稿 / 任意URL は実行前に人確認か。
- 書き込みフラグは既定オフか。読み取りトークンと書き込みトークンは分かれているか。
- 間接プロンプトインジェクションで「顧客リストを送れ」が文書に入っても、実行前検査で止まるか。
- 監査ログに機密が平文で残らないか。残るなら Confidential を載せない。
代替手段は、マスキング、必要フィールドのみの抽出、ローカルLLM、人間だけの処理です。チェックリストは方針の実装です。契約・規制の最終判断は、法務とセキュリティの文書に戻してください。
よくある質問
Q1. 学習をオフにすれば顧客メールを個人ChatGPTに貼ってよいか。
よくないです。OpenAI 公式でも個人向けと Business / Enterprise / API は学習の既定が違います。学習OFFは Managed 環境の定義ではありません。Internal / Confidential は組織契約経路へ回します。
Q2. 社内ナレッジボットが全社チャンネルに回答してよいか。
Managed なら条件付きです。露出先はチャンネル読者全員なので、検索対象はそのチャンネルに出してよい文書だけにします。本人が権限を持たない文書まで取込ませません。
Q3. エージェントに社内ファイル読取を与えてよいか。
読取そのものは露出ではありません。ただし後続のメール・投稿・fetch に乗ります。Claw は、読めてよいフィールドでも tool 引数へ無断コピーしうると示しています。読取範囲を露出先に合わせて切り、実行前に引数を見ます。
Q4. 生成AIを一律禁止すれば足りるか。
足りません。時事通信・C2 Data・SQAT はシャドーAI（日本 78%、利用の3分の2が個人アカウント）を、禁止だけでは見えない経路として扱います。承認済み Managed を先に置きます。
Q5. プロンプトに「機密を外部へ出すな」と書けばよいか。
削減はしますが、停止ではありません。Claw は強い指示でも開示が残ると報告しています。OWASP は認可をモデル出力に頼るなと書いています。境界は tool 実行前のポリシーです。
関連記事:
まとめ
機密をLLMに出す制限は、分類 × Managed環境 × Tool Call露出先の積集合です。どれか欠けると、そのタスクでは出しません。
学習OFFと貼り付け禁止は補助です。公式の契約区分、シャドーAIの数値、tool 引数の論文が、単純な一本線では3つのケースを分けられない理由になります。
次の一手は、上のチェックリストを1本の業務フローに適用することです。空欄があれば経路を変えるか、止めます。
著者
krona23
IT業界20年以上の実務経験を持ち、日本国内有数のPVを誇る大規模Webサービスで事業部長・CTOを複数社で歴任。Windows/iOS/Android/Webと技術の変遷を経験し、現在はAIネイティブへの変革に注力。DevGENTでは、AIコードエディタ・自動化ツール・LLMの実践的な使い方を日英西3言語で発信中。
コメントを残す