企業で生成AIやAIエージェントの利用が広がる一方、「情報漏えいがこれまで以上に起きるのでは」と不安を感じている方は多いのではないでしょうか。ガートナーが2025年2月に実施した国内調査では、企業の56.6%が「AI／生成AI／AIエージェントの活用で、これまで以上に情報漏えいが発生することが不安」 と回答しています（日経クロステック Active：生成AI活用で生じる情報漏洩リスクを意識せよ）。本記事では、「生成AIが危ない」と決めつけるのではなく、データの“ユーザー”が人間からAIへ置き換わることで、漏えいの“起点”と“拡散速度”が変わるという視点から、脅威モデル→守るべき対象→対策の3本柱→明日から使える最小構成の実装チェックまで、設計に落とし込みやすい形でまとめていきます。

社内Agentの設計やRAGのセキュリティをもっと知りたい方は、次の記事もあわせてどうぞ。社内Agentの設計観点は社内Agent導入の設計書——RAG・Tools・権限・監査を中核に据える、RAGのセキュリティアンチパターンはRAG構築でやってはいけないセキュリティ・アンチパターンとOWASP Top 10 2025、境界防御から可視化への流れは2026年サイバーリスクへの準備——境界防御から可視化とアイデンティティへで深掘りできます。

何が変わったのか——脅威モデルを「検索者＝AI」で再定義する

まず、なぜ生成AIで情報漏えいが「増えうる」と言われるのか、背景から押さえておきましょう。

人間が検索者だった時代は、探索に“現実的な上限”があった

従来、ファイルサーバやSharePoint、Wiki、チケット、メールには、機密や準機密が混ざって存在していました。人間が検索する場合は、「どこにあるか知らなければ探せない」「時間がかかる」「権限が限定される」ため、探索には現実的な上限があり、意図せず大量の重要情報が一気に漏れるリスクは、ある程度抑えられていました。

ところが、検索する側がAIに変わると、この前提がくずれます。

検索者がAIになると、漏えいの“起点”と“拡散速度”が変わる

生成AI、とくにRAG（検索拡張生成）やエージェントは、次の四つを同時に満たしやすいです。

高速：大量文書を短時間で走査・要約できる
横断：複数リポジトリ・SaaSをAPIやコネクタで串刺しできる
再構成：断片情報を統合し、「本来は別々に保管していたはずの機密」を文章として生成できる（“推論漏えい”の形）
拡散：チャットログ、回答の共有、コピペ、外部ツール連携で二次流通しやすい

ガートナーシニアディレクターアナリストの矢野薫氏は、「人から生成AIへの置換で探索範囲が拡大し、学習・回答生成を通じて拡散性が高まる」 と整理しています（EnterpriseZine：ガートナーが明かす「AIセキュリティ6大脅威」）。つまり、検索者がAIになった世界では、「過剰共有が“発見されてしまう”かもしれない」という前提で設計しておくと安心、という考え方になります。

守るべき対象は3点セット——元データだけでは足りない

「何を守るか」を決めるとき、「データ」だけをイメージしていると、現場の対策がなかなか噛み合わないことがあります。ガートナーの講演要旨では、守りたい重要データを次の3つに分けて考えるとよい、とされています。

元データ

いちばんイメージしやすいのが、ファイル、DB、チケット、メール、議事録、設計書、顧客情報など、もともと存在する情報資産です。

対象データ（RAG・エージェント用に加工されたデータ）

ここが「データ」と一言で言ったときに見落としがちな層です。RAGのインデックス、ベクトルDB、要約・抽出結果、集約済みデータが該当します。

RAGのインデックス、ベクトルDB、要約・抽出結果、集約済みデータです。ここが “新しいデータ層”としてどんどん増えていく 点は、設計する側として押さえておきたいところです。「元データを直接見せない」つもりでも、実装によってはインデックスや埋め込みが準機密の集合体になっており、権限・暗号・バックアップの扱いが曖昧になりがちです。

生成結果

3つ目は、AIが出力したものそのものです。チャット回答、要約、提案書、コード、説明文、出力ログなどがここに入ります。ここも二次流通やコピペで漏えいが広がりやすいため、DLPや監査の対象に含めておくと安心です。

対策の3本柱——サービス評価・コンテンツ保護・アウェアネス

では、上で見た「守るべき3層」を踏まえて、どんな対策があるでしょうか。ガートナーが示す「3つの取り組み」を、設計に落とし込みやすい形にすると、次の3本柱になります。

第一の柱：生成AIサービスの評価（SaaSセキュリティ評価の拡張）

まずは「どのサービスを、どんな条件で使うか」を評価するフェーズです。ここで押さえておきたいリスクは、大きく二つです。

学習による漏えい：入力がモデル改善等に利用される／されうる、または外部に残る
サービス内残留データの漏えい：ベンダー侵害・内部不正・設定不備など

「AIだから特別」と考えるより、いつものSaaS評価に、AI特有の項目を足すイメージでチェックすると取り組みやすいです。ベンダーが情報を開示しない場合は、第三者評価や先行事例の有無で候補を絞り、それでも難しければ情報の種類・期間・利用者を絞ったスモールスタートから始める、という進め方があります。評価するときの観点の例を、次の表にまとめておきます。

技術者向けの評価観点（チェックリスト例）

観点	確認したいこと
データの扱い	保持期間、学習利用の有無、オプトアウト可否
ログ	プロンプト／出力／添付の保存範囲、エクスポート可否
テナント・暗号	テナント分離、暗号化、キー管理（BYOK／HYOKの可否）
ガバナンス	管理API、監査ログ、DLP連携、CASB／SASE連携
コネクタ	権限制御（最小権限、スコープ、委任）

第二の柱：コンテンツ（データ）の保護——「公開設計」か「最小権限」かを先に決める

サービスを選んだら、次は「中身のデータをどう守るか」です。ここでは、アプローチを次の二つに分けて考えると整理しやすくなります。

(A) 広く活用したい：多くの人がアクセスできる環境では、重要情報を入れない・排除する
(B) 重要情報を使って分析したい：アクセスできる人を最小限にして保護する

私たちがやりがちなのは、(A)と(B)を混ぜたまま「とりあえずRAGで便利にしよう」と進めてしまうことです。まず 「このユースケースは(A)のナレッジ基盤か、(B)の限定分析か」 を決めておくと、権限・データ加工・監査・運用を一気に設計しやすくなります。

データの分類は、「法規制／契約／競争力／知る必要性」 の観点で見直してみてください。法規制データは機械検出しやすい一方、契約・競争力データは二次加工・分散が多く、少し入念な検証が必要になることが多いです。実装レベルでいうと、例えば次のような手段があります。

実装に落とす代表例

DLP：入力・アップロード・共有・エクスポートの制御（生成結果も対象にする）
暗号・鍵管理：KMaaS、BYOK／HSM、ベクトルDBやログ領域の暗号化
権限制御：IGAで「誰がどの情報にアクセスできるか」を棚卸し、PAMで特権経路を封じる
EDRM／IRM：コピー・転送・印刷など“出力後”の制御
データフロー管理：生成→加工→共有→廃棄までをID基準で追えるようにする（AIにもIDを割り当てる発想）

第三の柱：教育ではなくアウェアネス——現場の意思決定を変える

「ルールを押し付ける」だけだと反発が出やすい、という声はよく聞きます。ガートナーでは、当事者が自分で判断できる“アウェアネス” に寄せていくことが有効、とされています。また、セキュリティアンバサダーを単独で置くと「上から言われている」と感じられやすいため、DXアンバサダーと一本化すると受け入れられやすくなる、という現場寄りの提案もあります。

技術者としては、「啓発」だけでなく、安全な利用がしやすい“既定値”を用意するプロダクト設計の考え方が役に立ちます。

デフォルトで危険なデータを入れにくいUI（分類・注意喚起・自動マスキング）
テンプレ：安全なプロンプト例、共有NG例、社内ルールの短文化
「困ったらここ」の相談導線（アンバサダー／CoE／窓口）

明日から使える——最小構成の実装チェック（フェーズ0〜2）

「やることが多すぎて何から手をつければいいかわからない」というときは、最初の1〜2週間→スモールスタート→RAG／エージェント拡張の順で、最小限のセットから始めてみるのがおすすめです。以下、各フェーズで「何をやるか」を具体的にまとめました。

フェーズ0：最初の1〜2週間でやること

アクション	具体的な内容
サービスを1つに絞る	使う生成AIサービスを1つに決め、テナント設定・ログ・学習利用を評価する（SaaS評価＋AI項目のチェックリストを使う）
入力禁止データを定義する	個人情報、契約条件、未公開財務、認証情報など、入力禁止データを短い文章で定義し、関係者で共有する

成果物の例：『利用する生成AIサービス一覧と評価メモ』『入力禁止データ定義（1ページ）』

フェーズ1：スモールスタート（利用者とガードを限定）

アクション	具体的な内容
利用者を絞る	デジタルスキルが高めの人、短期パイロット、情報の種類を制限したうえで利用範囲を決める
DLP相当のガードを入れる	最低でもプロンプト／添付の検知・ブロック・監査ログを用意する。既存のDLPやCASBで「生成AI経由」を検知できるか確認する

成果物の例：『パイロット利用者リストと情報種別』『プロンプト／添付の監査ログ取得方法のドキュメント』

フェーズ0と1が回り始めたら、いよいよRAGやエージェントの範囲を広げる段階です。

フェーズ2：RAG／エージェントを拡張するとき

アクション	具体的な内容
ユースケースごとに(A)(B)を決める	「広く活用(A)」か「限定分析(B)」かをユースケースごとに決め、データ境界を引く。(A)なら重要情報をRAGに載せない、(B)ならアクセス者を限定し監査を強める
AIにもID・権限を割り当てる	エージェントやRAGがアクセスするシステムには、最小権限・監査・PAM経路を整える。ツール実行権限が最重要なので、どのAPI・DBに何ができるかを明文化する

成果物の例：『RAG／エージェント別のデータ境界一覧』『AI用サービスアカウントと権限一覧・レビュー手順』

まとめ——生成AI対策は「AIの問題」ではなく「探索と共有の設計問題」

ここまでのおさらいです。

検索者がAIになったいまは、過剰共有が“発見されてしまう”かもしれない前提で設計しておくと安心
守る対象は3層：元データ／対象データ（RAGのインデックス等）／生成結果
打ち手は3本柱：サービス評価 → コンテンツ保護 → アウェアネスの順で、現場を巻き込みながら回していく
明日から：フェーズ0で「1サービス＋入力禁止データの定義」から始め、フェーズ1で利用者とDLP相当のガードを限定し、フェーズ2でRAG／エージェント拡張時に(A)(B)の境界とAIの権限を明文化する

生成AIの情報漏えい対策は、特別なツールをたくさん入れることより、脅威モデルを「検索者＝AI」で更新し、守る対象を3点セットで捉え、サービス評価・コンテンツ保護・アウェアネスを段階的に回していく考え方が役に立ちます。まずはフェーズ0のチェックから、手を動かしてみるところから始めてみてください。

作成日：2026年2月24日