機密情報はなぜLLMから漏れるのか？OWASP LLM02 Sensitive Information Disclosureを解説
はじめに
2023年4月、Samsungの半導体部門の従業員がChatGPTに業務関連のソースコード・会議の文字起こしを入力し、それが学習データに取り込まれた可能性がある事故が3件発生しました。20日以内に立て続けに3件起きたことで、Samsungは社内でのChatGPT利用を全面禁止する措置を取りました。これは特殊な攻撃ではなく、便利なツールへの信頼が技術的・組織的なコントロールなしに使われた結果起きた事故です。
参考：Samsung Engineers Feed Sensitive Data to ChatGPT - Dark Reading
このように、LLMから機密情報が漏洩するリスクは現実のものとなっています。OWASP Top 10 for LLM Applications 2025では、Sensitive Information Disclosureが2023年版の6位から2位に急上昇しました。
この記事ではLLM02の仕組み・攻撃シナリオ・対策を初心者エンジニア向けに整理します。
Sensitive Information Disclosureとは？
OWASPの定義では、機密情報はLLMへの入力（in）とLLMからの出力（out）の両方向で漏洩しうるとされています。対象となる機密情報の例はこちらです。
| 種類 | 例 |
|---|---|
| 個人識別情報（PII） | 氏名・住所・メールアドレス・電話番号 |
| 金融情報 | クレジットカード番号・口座情報・取引履歴 |
| 医療情報 | 診断結果・処方情報・カルテ |
| 業務機密 | ソースコード・経営戦略・契約内容 |
| 認証情報 | APIキー・パスワード・トークン |
| 法的文書 | 契約書・社内規定 |
LLMの応答は下流システムに信頼されて再利用される傾向があるため、たった一度の漏洩が次の侵害につながる構造的な怖さがあります。
なぜ漏れるのか？3つの経路
機密情報がLLMから漏洩する経路は、大きく3つに分けられます。
① 学習データに含まれていた情報
LLMが学習データとして取り込んだ機密情報が、ユーザーの質問に応じて出力されてしまうケースです。
2023年にはChatGPTに「Poemという単語を永久に繰り返して」と指示することで学習データを吐き出させる攻撃が研究者によって報告されました。これは モデルの内部に保持された学習データを引き出す手法（モデル反転攻撃） の一例です。
筆者の体験例では、LLMで生成したコードに別の会社のCopyrightが記載されていたことがありました…！
② RAGのナレッジベース経由
RAGシステムが参照する社内ドキュメント・データベースから、アクセス権限のない情報が引き出されるケースです。
GDPRの観点では、RAGシステムが他ユーザーのデータをユーザーAのクエリに対して返してしまうと、それは報告義務のあるデータ侵害として扱われます。RAGのアクセス制御は単なる技術的な問題ではなく、コンプライアンス上の重大事項です。
③ コンテキスト・セッション経由
複数ユーザーが同じLLMアプリを使う場合、セッション間の分離が甘いと別ユーザーの情報が混入することがあります。
[実例ベースのシナリオ]
社内の生産性向上アシスタントを導入。
モデルがユーザー間のやり取りで継続学習する設計だった。
ユーザーが「最近のカスタマーサポート対応を要約して」と依頼。
→ 別ユーザーが扱っていた内容を含む応答が返る：
「John Smithさんの注文#67890は遅延し、
末尾4591のカードに3,200ルピーを返金しました。
メールは [PII] です」
→ セッション間の入出力分離不足、サニタイズ不足、
プロンプトの過剰な保持が原因。
具体的な攻撃・事故シナリオ
シナリオ①：学習データの引き出し
研究者によって報告された有名な事例で、特定のプロンプトを工夫することでLLMの学習データに含まれていた個人情報や機密情報を引き出せることが示されています。 CVE-2019-20634（Proof Pudding攻撃） では、漏洩した学習データを用いてモデル抽出・反転攻撃が可能になり、攻撃者がメールフィルタなどのセキュリティ制御を回避できるようになりました。
シナリオ②：従業員による無意識の入力
Samsung事件のように、従業員が業務効率化のためにLLMへ機密情報を入力してしまうケースです。攻撃者が存在しなくても、組織のポリシー・技術的コントロールが整備されていないだけで漏洩が発生します。
シナリオ③：RAGにおけるアクセス制御不備
社内ドキュメントを参照するRAGシステムで、本来アクセス権限のないユーザーが巧みな質問を通じて機密情報を引き出すケースです。LLMは取得したドキュメントの内容と質問の妥当性を厳密に判断できないため、検索結果がそのままLLMのコンテキストに渡る設計では情報漏洩のリスクが残ります。
法規制との関係
LLM02が他の脆弱性と比べて特に重大なのは、直接的に法規制違反となる点です。
| 法規制 | 関連する違反内容 | 罰則の規模 |
|---|---|---|
| GDPR（EU） | 個人データの偶発的・違法な漏洩 | 最大2,000万ユーロまたは全世界売上の4% |
| HIPAA（米・医療） | 保護対象保健情報（PHI）の無断開示 | 民事・刑事罰 |
| DPDP Act 2023（インド） | 同意なしのデータ処理 | 最大2.5億ルピー |
| APPI（日本・個人情報保護法） | 個人情報の漏洩 | 報告義務・行政指導 |
「うっかり漏れた」では済まないのが、LLM02の怖さです。
対策
OWASPは多層防御を推奨しており、4つの柱で整理できます。
① データ衛生（Data Hygiene）
機密データがそもそも学習パイプラインに入らない設計にします。これが最も根本的な対策です。
- 学習データから個人情報・機密情報を除去する（データサニタイズ）
- 差分プライバシー（Differential Privacy）の導入を検討する
- 利用規約で「ユーザーデータを学習に使わない」明示する、もしくはオプトアウト機能を提供する
② アクセス制御（最小権限の原則）
RAGや外部データソースに対するアクセス制御を厳密にします。
- ナレッジベースへのアクセスをユーザー・ロール単位で制御する
- セッション間の入出力分離を実装する
- LLMが取得できる情報の範囲を明示的に絞る
③ 入出力フィルタリング
LLMへの入力・出力の双方をチェックします。
- 入力時：機密情報パターン（クレジットカード番号・SSNなど）を検出してブロック
- 出力時：PII・APIキー・社内識別子を含む応答をフィルタリング
- エラーメッセージから詳細情報が漏れないよう設定をハードニング
④ ガバナンス・教育
組織として運用ルールを定めます。
- 従業員向けに「LLMに入力してはいけない情報」のガイドラインを策定
- ベンダーの利用規約・データ取り扱いポリシーを精査
- 機密性が高い用途ではオンプレ・プライベートクラウドLLMの利用を検討
まとめ
- Sensitive Information Disclosureは2025年版で2位に急上昇した重要リスク
- 漏洩経路は「学習データ」「RAGナレッジベース」「セッション・コンテキスト」の3つ
- GDPRやHIPAAなど法規制に直結するため、技術的対策だけでは不十分
- 「データ衛生」「アクセス制御」「入出力フィルタリング」「ガバナンス」の4層で多重防御する
- 機密情報は最初からLLMに入れない設計が最も確実
LLMの便利さと機密情報のリスクは表裏一体です。「入れない」「出さない」を両方設計に組み込みましょう！
関連記事
プロンプトインジェクション（LLM01）の詳細はこちら。
システムプロンプト漏洩（LLM07）はこちら。
RAGとIndirect Injectionの関係はこちら。
Discussion