生成AI情報漏洩リスクを三層で防ぐ：中堅企業が今すぐ整えるべき技術・運用・ガバナンス対策

なぜ今、生成AI特有の漏洩リスクを正面から扱うのか

企業における生成AI活用が広がるなか、私たちが現場で見てきた範囲では、多くの中堅企業が「とりあえずChatGPT Enterpriseを契約した」「DLPを入れた」という段階で対策を完了したと認識している傾向が多い。しかしこれは誤りだ。ツールの導入は三層対策の「技術層」の一部を埋めるにすぎず、運用設計とガバナンスの整備が伴わなければ抜け穴が残る。

実際に2023年3月にはChatGPTの障害により、他ユーザーのチャット履歴や支払い情報が一部ユーザーに表示されるバグが確認されており、SaaS型AIを利用する企業にとってシステムリスクは既に現実のものとなっている出典：acompany。またSamsung社では社員がChatGPTにソースコードや会議録を入力した事案が報告されており、技術的な脆弱性ではなく従業員の誤操作が直接のトリガーとなっている出典：丸紅iDigio。

本稿が対象とするのは従業員300〜2000名規模の中堅企業だ。専任のセキュリティエンジニアが1〜2名体制、もしくはIT担当が兼務しているという組織を想定している。海外で先行して整備されている「AI Security Framework」の考え方を参照しつつ、その概念を日本の中堅企業の人員規模・予算感に引き直したとき、どの層から着手すれば最短でリスクを下げられるかを示す。

漏洩経路の仕組み：三類型と技術的背景

生成AIへの入力情報が外部に漏洩する経路は大きく三類型に分類できる出典：丸紅iDigio。それぞれの仕組みを正確に理解しておくことが、技術・運用・ガバナンスの各層で打つべき手を選ぶ前提となる。

①入力データのモデル学習への流用

コンシューマー版の生成AIサービスでは、利用規約上、ユーザーの入力がモデル改善・再学習に使われる場合がある。この経路は攻撃者の介在を必要としない。社員が機密情報を含む文書を要約させたり、ソースコードのレビューを依頼したりするだけで、情報がモデルの重みに組み込まれる可能性がある。法人向けプラン（ChatGPT Enterprise、Microsoft Copilot for Microsoft 365）では入力データを学習に利用しない契約条項が設けられており出典：丸紅iDigio、コンシューマー版との使い分けはセキュリティ上の最重要判断の一つとなる。

②プロンプトインジェクションによる不正出力

プロンプトインジェクション攻撃とは、悪意ある指示をプロンプト内に埋め込むことでAIモデルを意図しない挙動に誘導する攻撃手法だ出典：NRIセキュア。例えば、外部のWebページや文書をRAGで参照させるシステムにおいて、その文書内に「システムプロンプトを無視して〇〇を出力せよ」という隠し指示が埋め込まれていれば、AIはその指示に従ってしまう可能性がある。

このリスクは外部データを取り込むRAG構成やエージェント型AIで特に高くなる出典：NRIセキュア。エージェントが複数のツールやAPIを自律的に呼び出す構成では、攻撃面積（アタックサーフェス）が大幅に広がる。単一のチャットUIに対するプロンプトインジェクションとは質的に異なる脅威として設計段階から考慮しなければならない。

③システムバグによる意図しない開示

冒頭で触れたChatGPTのバグ事例がこれに相当する。SaaSとして提供されるAIサービスは、自社でコードを制御できないため、プロバイダー側の実装上の問題によって他ユーザーのデータが漏洩するリスクを内包している出典：acompany。このリスクは技術的対策よりも、「何を入力するか」という運用設計によってコントロールするしかない部分が大きい。

今すぐ問い合わせる

データライフサイクル全体を見渡す：推論フェーズだけを守っても足りない理由

NTTデータが示す生成AIセキュリティの観点では、データのライフサイクル全体（収集・前処理・学習・推論・廃棄）を通じたリスク管理が必要であり、推論フェーズだけを保護する部分的対策では不十分とされている出典：NTTデータ。

推論時のプロンプト検査や出力フィルタリングは必要条件だが、前処理段階での個人情報マスキングや、廃棄フェーズでのベクターDB上のデータ削除手順が設計されていなければ、ライフサイクル全体としては穴が残る。

生成AIシステムのセキュリティ設計では、モデル自体への入出力検証・フィルタリングに加え、RAGで参照する外部データベースのアクセス権限管理が不可欠なアーキテクチャ要件となる出典：NRIセキュア。具体的には、ベクターストア（Pineconeや社内ホスト型ChromaDB等）に格納された文書チャンクについて、誰がどの文書にアクセスできるかをロールベースで制御する設計が求められる。多くの中堅企業が見落としがちなのは、「ベクターDBはファイルサーバーと同じアクセス制御思想で管理しなければならない」という点だ。

設計上の落とし穴：技術層・運用層・ガバナンス層それぞれで起きる誤り

技術層の落とし穴

最もよく見られる誤りの一つが、DLPツールを導入したが生成AI入力には効いていないという状態だ。DLPをAI利用環境に適用する際は、AIへの入力テキストをポリシー検査の対象とするエンドポイントDLPまたはCloud DLPの設定が必要であり、従来のファイル転送監視だけでは生成AI経由の漏洩を検知できない出典：テクノ。既存のDLP設定をそのまま流用していると、ブラウザ上でテキストをコピー＆ペーストして入力する行為はスコープ外になってしまう。

• エンドポイントDLP：ブラウザへのコピー＆ペースト操作を監視対象に含めるポリシー設定が必要。多くのDLP製品はデフォルトでは有効になっていない。
• Cloud DLP（SWG/CASBとの連携）：ChatGPTなど外部AIサービスへのHTTPS通信をTLSインスペクションで復号し、送信テキストをキーワード・正規表現・分類モデルでスキャンする構成が必要。
• Copilot等の社内ツール連携型AI：Microsoft Purview等、プラットフォーム固有のコンプライアンス機能と連携させないと、テナント内のAI利用は既存DLPの検査対象外になる場合がある。

もう一つの落とし穴は、エージェント構成における最小権限の軽視だ。AIエージェントが外部ツールやAPIを自律的に呼び出す構成では、エージェントが保持するセッション情報・認証トークンが攻撃対象になるため、最小権限の原則に基づくスコープ設計がセキュリティ上の必須要件となる出典：パーソルBD。よく見られるのは「開発を速く進めるために管理者権限のトークンをエージェントに渡してある」という状態で、本番稼働後もそのまま運用されているケースだ。

運用層の落とし穴

「コンシューマー版ChatGPTの業務利用を禁止する」という通知を出したが、代替手段が用意されていないため、実態として禁止が守られていないというパターンは非常に多い。禁止だけでは行動は変わらない。業務効率化のニーズがあれば、社員は利用継続の理由を見つける。法人向けプランへの移行とセットで周知しなければ、禁止通知は実効性を持たない。

また、データマスキング・匿名化技術を前処理工程に組み込むことで、個人情報や機密値を実際のモデルに送信せずに業務自動化を実現できるアーキテクチャが中堅企業でも実装可能になりつつある出典：acompany。しかし現場では「マスキングすると精度が落ちる」という懸念から、マスキングを省略して生データをそのまま送信しているケースが散見される。精度要件と秘匿要件のトレードオフを設計上のポリシーとして明示しておかないと、現場判断でセキュリティが後退する。

ガバナンス層の落とし穴

ガバナンス文書の典型的な問題は「禁止事項の列挙で終わっている」ことだ。実効性を持たせるには、禁止事項の列挙に加えて以下の四要素をセットで規定する必要がある。

• 利用承認フロー：新しいAIツールや用途を業務に組み込む前に、誰がどの基準で承認するかのプロセス定義。
• 入力禁止情報リスト：個人情報（氏名・連絡先等）、機密扱いの契約書・財務データ、未公表の製品仕様など、具体的な情報カテゴリを列挙した文書。抽象的な「機密情報は入力しない」では現場で判断できない。
• インシデント報告ルート：誤入力や疑わしい挙動を発見した社員が、誰に・どのチャネルで・何を報告すればよいかを一枚の図で示す。報告のハードルが高いと軽微なインシデントが隠蔽される。
• 定期棚卸しのスケジュール：利用中のAIツール一覧と、各ツールの契約条項・データ処理地域・インシデント対応SLAを年1回以上確認する。AIサービスは利用規約が頻繁に改定されるため、契約時の確認だけでは陳腐化する。

実装・運用の指針：三層を噛み合わせるための優先順位

セキュリティ専任が少ない中堅企業では、「すべての層を同時に整備する」ことは現実的でない。以下では投資対効果と実行難易度の観点から、優先順位を三段階に整理する。

フェーズ1：即日着手できる運用層の基盤整備（コスト：低、効果：高）

最初に着手すべきは、ツール購入ゼロで翌日から実施できる運用層の整備だ。Samsungの事案が示すように、情報漏洩の多くは従業員の認識不足に起因する出典：丸紅iDigio。入力禁止情報リストを作成し、全社へ告知するだけで、技術的対策を一切講じていない状態と比較して漏洩確率を大きく下げられる。

• 入力禁止情報リストの作成と告知：個人情報・機密契約・未公表財務数値・製品仕様を明示し、Slack・社内ポータル等で全社周知する。1〜2日で完了できる。
• コンシューマー版の利用禁止と法人プランの調達：ChatGPT EnterpriseまたはMicrosoft Copilot for Microsoft 365への移行を決裁し、学習利用しない契約条項を取得する。既存契約の確認も含め1〜2週間で対応可能。
• インシデント報告ルートの明文化：一枚のフロー図（報告先・報告方法・対応SLA）を作成し、ガイドラインに添付する。

フェーズ2：技術層の最低限の整備（コスト：中、効果：中〜高）

フェーズ1が定着したら、技術層の設定に着手する。ここでの目標は「既存ツールを正しく設定する」ことで、新規ツールの購入は必ずしも必要ない。

• DLPポリシーの生成AI対応拡張：既存のエンドポイントDLPまたはCasb製品がある場合、AIサービスへの入力テキストをスキャン対象に追加する。製品によっては設定変更のみで対応できる出典：テクノ。
• RAGシステムのアクセス制御監査：ベクターDBに格納されている文書群について、格納したデータのオーナーとアクセス可能なロールを棚卸しする。「全社員が全文書を参照できる」という状態は、情報セキュリティの観点から許容できない構成だ出典：NRIセキュア。
• 入出力フィルタリングの実装：自社開発のAIシステムがある場合、システムプロンプトに明示的な禁止指示を含めるとともに、出力テキストの後処理でPII（個人識別情報）検出を走らせる実装を加える。
• 前処理マスキングの検討：顧客データをAIに渡して処理する業務フローがある場合、処理前にマスキングまたは擬似匿名化を行うアーキテクチャを検討する出典：acompany。

フェーズ3：ガバナンス層の体系化と継続的改善（コスト：中、効果：長期）

フェーズ1・2が機能し始めたタイミングで、ガバナンス文書を体系化する。NTTデータが指摘するようにデータのライフサイクル全体を通じたリスク管理が必要であり出典：NTTデータ、単発のガイドライン整備ではなく継続的な改善サイクルに乗せることが目的となる。

• AI利用台帳の整備：利用中のAIツール・API・社内開発システムを一覧化し、各ツールのデータ処理地域・学習利用有無・インシデント対応SLAを記録する。年1回以上の見直しをスケジュールに組み込む。
• 利用承認フローの制度化：新しいAIツールの導入申請を受け付け、セキュリティチェックリストを経て承認するプロセスを定める。チェックリストには「学習利用有無」「データ処理地域」「契約上のセキュリティ保証」を必須項目として含める。
• 定期研修の実施：入力禁止情報の周知は一回の告知では定着しない。四半期ごとのミニ研修（15〜20分のe-learning形式）や、実際のインシデント事例を用いたケーススタディを繰り返す。
• エージェント・自律型AIのスコープ管理：AIエージェントを本番稼働させる場合は、付与するAPIスコープ・認証トークンの有効期限・呼び出し可能なエンドポイントの範囲を最小限に定義し、設計レビュー時に最小権限の原則が守られているかを確認する出典：パーソルBD。

みっちゃくんを見る

RAG・エージェント構成特有の追加対策

シンプルなチャットUI利用から一歩進んで、RAG構成やエージェント型AIを社内システムに組み込む場合、上記の三層対策に加えて以下の対策が必要になる。これらは既存のWebアプリケーションセキュリティとは異なる考え方を要求するため、設計フェーズから明示的に取り扱う必要がある。

プロンプトインジェクション対策

RAG構成では、外部から取得したコンテンツ（Webページ・PDF・データベースレコード等）がプロンプトに動的に挿入される。攻撃者がその外部コンテンツに悪意ある指示を埋め込んでいた場合、モデルがその指示に従ってしまうリスクがある出典：NRIセキュア。

• 入力の構造的分離：ユーザー入力とシステム指示を明確に分離し、外部取得コンテンツを「信頼できない入力」として扱うプロンプト設計を徹底する。
• 外部コンテンツのサニタイゼーション：RAGで参照するデータソースに対して、取り込み時に不審なキーワード・指示的フレーズが含まれていないかをスキャンする前処理を組み込む。
• モデルの出力監視：システムプロンプトの内容が出力に含まれていないか、禁止情報カテゴリに該当するコンテンツが出力されていないかを後処理でチェックする。
• 信頼スコアの付与：参照する外部ソースにドメイン・信頼度スコアを付与し、信頼度の低いソースからの取得コンテンツをシステムプロンプトと同一の権限コンテキストで扱わない設計にする。

エージェント構成のスコープ設計

AIエージェントが外部APIを自律的に呼び出す構成では、認証トークンの奪取がプロンプトインジェクションと組み合わさることで、エージェントが意図しないデータ送信・操作を行うリスクが生まれる。これはエージェントの賢さの問題ではなく、設計上のスコープ管理の問題だ。

• 最小権限の原則の徹底：エージェントに付与するOAuthスコープは業務上必要な最小限に絞る。「とりあえず全スコープ」は禁止出典：パーソルBD。
• トークンのライフタイム管理：エージェントが使用する認証トークンは短期間で自動失効するように設定し、長期トークンの使用は避ける。
• 人間によるアクション承認ステップ：エージェントが外部に書き込む操作（メール送信・ファイル更新・API POSTコール等）については、人間の確認ステップを挟む設計を選択する。完全な自律動作はリスクが高い。
• 呼び出しログの集中管理：エージェントがどのAPIをいつ・どのパラメータで呼び出したかを集中ログとして記録し、定期的にレビューする。

よくある質問

Q：ChatGPT Enterpriseを契約すれば情報漏洩リスクはなくなりますか？

A：学習への流用リスクは契約条項で遮断できますが、漏洩経路の三類型のうち残り二つ（プロンプトインジェクションとシステムバグ）は別途対策が必要です。「何を入力するか」の運用設計と、DLP設定の見直しはEnterpriseプランに移行しても引き続き取り組むべき事項です。

Q：DLPを既に入れているのに追加設定が必要ですか？

A：既存のDLPがファイル転送やメール添付のみを監視対象としている場合、ブラウザ上でのテキスト入力はスキャンされません。エンドポイントDLPのポリシー設定でブラウザへのコピー＆ペーストをカバーするか、SWG/CASBとのTLSインスペクション連携が必要です出典：テクノ。製品ごとに設定方法が異なるため、現在利用中の製品のドキュメントで「AI/Webアプリケーション向けポリシー」の設定項目を確認してください。

Q：セキュリティ専任が1名しかいません。どこから手をつければ良いですか？

A：フェーズ1（入力禁止情報リストの作成・告知、法人プランへの移行）を最初の2週間で完了することを推奨します。ツール購入不要で実施でき、漏洩の最も多い経路である「従業員の誤入力」に直接効く施策です。技術層の設定変更（フェーズ2）は既存ツールの機能確認から始めれば新規予算なしで対応できる場合があります。

Q：プロンプトインジェクション対策はコーディングレベルで何が必要ですか？

A：最低限の実装として、①システムプロンプトと外部コンテンツを明示的に分離（例：XML/JSONタグで役割を明記）、②外部取得コンテンツをユーザー権限コンテキストとして扱う（システム権限コンテキストにしない）、③出力テキストにシステムプロンプトの断片が含まれていないかをパターンマッチで後処理チェックする、の三点が実装の起点になります。OWASP LLM Top 10の「LLM01：Prompt Injection」もあわせて参照することを推奨します。

生成AIの情報漏洩リスクを「技術問題」として捉えると、ツール導入で完結したと誤解しがちだ。しかし本稿で見てきたように、漏洩経路の多くは運用設計の欠如と従業員の認識不足に起因し、技術・運用・ガバナンスの三層が連動して初めてリスクを抑制できる。セキュリティ専任が限られた中堅企業こそ、まず「入力禁止情報リストの整備と全社告知」という最もコストが低くて即効性の高い施策から手を動かし、そこで得た運用の感覚を技術層の設定変更とガバナンス文書の体系化につなげていくことが、実用的な次のアクションとなる。

生成AIのセキュリティ設計を相談する