AIセキュリティ

生成AIの情報漏えい対策とは?RAG時代に必要なアクセス制御と統制設計の3軸

記事バナー画像

ざっくりまとめ

  • 生成AIの普及で情報漏えいの「起き方」が根本から変わった——従来の「人が検索する」モデルから「AIが社内データを横断的に参照する」モデルへの移行が、既存のアクセス制御を無効化しつつある
  • ガートナーが2025年2月に実施した調査で、企業のAI活用における情報漏えいリスクへの懸念が高まっていることが確認されており、対策の優先度は今年中に上げるべき段階にある
  • 入力データの分類・プロンプトとログの管理・権限と監査の3軸で、統制設計を始めるための判断基準を整理する

「検索者がAI」になると、何が崩れるのか

これまでの情報漏えい対策は「人がどこにアクセスするか」を制御する設計だった。フォルダのアクセス権、VPNの認証、ダウンロードの制限——どれも「人間の操作」を前提にしている。

生成AIはその前提を壊す。AIエージェントが社内の議事録・顧客データ・財務資料を横断的に読み込み、質問に答える。人なら「この資料は関係ない」と判断して飛ばすところを、AIは関連しそうなテキストをすべて文脈に取り込む。速度・量・無意識性がまるで違う。

結果として起きるのは、意図しない情報の結合だ。単体では問題ないデータが、AIによって組み合わせられたとき初めて機密情報になる。従来のアクセス制御は「ファイル単位」で考えていたが、AIは「文脈単位」で動く。ここにギャップがある。

漏えいが起きる3つの経路を整理する

生成AI特有の漏えいルートは、大きく3つに分類できる。

プロンプトへの直接入力

最も頻度が高い経路だ。社員が業務効率化のためにChatGPTなどの外部サービスに顧客名・契約金額・個人情報を貼り付ける。「要約して」「メールを書いて」——その一文に機密が含まれていても、入力した本人が漏えいと認識していないケースが多い。

RAGによる社内ナレッジ連携

社内ドキュメントをAIに読み込ませて回答精度を上げる仕組み(RAG)は、今多くの企業が導入を検討している。問題は、検索インデックスに載った情報が「誰でも質問できる状態」になることだ。本来は経営層しか見られないはずの資料が、一般社員のプロンプト一発で要約されて返ってくる——権限設計を後回しにしたまま導入した結果だ。

ログと会話履歴の扱い

AIとの会話ログには、社員が何を調べ、何を入力したかが残る。このログが適切に管理されていなければ、漏えいの事後検知ができないだけでなく、ログ自体が漏えいの対象になる。ログはリスクであり、同時に監査の命綱でもある。

生成AI時代の情報漏えい3経路と対策軸の対応
漏えい経路 × 対策軸マトリクス 漏えい経路 入力データ分類 プロンプト/ログ管理 権限/監査 プロンプトへの 直接入力 (外部サービス貼り付け) ◎ 最重要 機密ラベル付与 ○ 有効 入力フィルタリング △ 補助的 利用ポリシー周知 RAG社内ナレッジ 連携 (検索インデックス経由) ○ 有効 データ分類の粒度設定 △ 補助的 クエリログ保存 ◎ 最重要 ロールベース権限制御 ログ・会話履歴 の扱い (監査証跡・漏えい対象) △ 補助的 保存対象の定義 ◎ 最重要 保持期間・暗号化設定 ○ 有効 アクセス監査の自動化 ◎ 最重要 ○ 有効 △ 補助的 漏えい経路 × 対策軸 ① プロンプトへの直接入力 入力データ分類 ◎ 機密ラベル付与 ログ管理 ○ 入力フィルタリング 権限/監査 △ 利用ポリシー周知(補助的) ② RAG社内ナレッジ連携 権限/監査 ◎ ロールベース権限制御 データ分類 ○ 分類粒度の設定 ログ管理 △ クエリログ保存(補助的) ③ ログ・会話履歴の扱い ログ管理 ◎ 保持期間・暗号化設定 権限/監査 ○ 監査の自動化 データ分類 △ 保存対象の定義(補助的)
◎は各経路で最優先すべき対策軸。複数の軸を組み合わせて多層防御を構成する。

3つの対策軸——何から手をつけるか

対策の骨格は「入力データの分類」「プロンプト/ログ管理」「権限/監査」の3軸だ。優先順位はこの順番ではない。組織の現状に応じて起点が変わる。

入力データの分類から始める組織

社内にデータ分類の基準がない、あるいは「なんとなく機密」という状態の組織はここから入る。AIに何を入力してはいけないかを定義しないまま導入しても、ルールは機能しない。「社外秘」「部門内限定」「公開可」の3段階でいい。粗くても定義があることが先決だ。細かすぎる分類は現場に無視される。

プロンプトとログの管理

外部のAIサービスを業務利用している組織で最初に整備すべきなのがここだ。どの社員が何を入力したか、ログを取得・保存する仕組みがなければ、事後の調査も是正もできない。保持期間と暗号化の設定を決め、ログ自体へのアクセスを制限する——この三点セットが最低ラインになる。

権限と監査の設計

RAGや社内AIポータルを構築・運用している段階の組織に効く対策軸だ。「このロールのユーザーはこのデータカテゴリにしかアクセスできない」という制御を、AIの検索レイヤーに適用する。人間のアクセス権とAIの検索権を別々に設計する視点が必要で、ここを後回しにすると権限の「抜け穴」がAIの回答経由で広がる。

社内ナレッジ連携時に見落とされるルール

挿絵

社内文書をAIに接続するプロジェクトで最も見落とされるのが、「誰がどこまで見ていいか」のポリシーをAI側に反映させるステップだ。SharePointやGoogle Driveのアクセス権は設定されていても、その権限設定がRAGのインデックスに引き継がれていないケースは珍しくない。

もう一つの盲点は「過去データ」だ。数年前に作成した資料には、現在の機密基準では公開不可の情報が含まれていることがある。AIに参照させる前に対象データのスコープを絞り、古い資料は除外か再分類するプロセスが必要になる。

運用開始後の継続的な監査も設計に含めること。AIが参照できるデータは時間とともに増える。初期設定だけで安心するのは危うい。

明日からの統制設計——チェック3点

まず自社の現状を3点で確認する。

  • 外部AIサービスへの業務データ入力に関するルールが、文書として存在するか
  • 社内AIツールのログが取得・保存されており、誰がアクセスできるか定義されているか
  • RAG等の社内ナレッジ連携において、元データの権限設定がAI側にも反映されているか

3点すべて即答できる組織は少ないはずだ。一つでも「わからない」があれば、それが今週着手すべき調査項目になる。ガートナーが2025年2月の調査で確認した懸念は、杞憂ではなく設計の不備から来ている。

まとめ

生成AIによる情報漏えいは、悪意ある持ち出しより「善意の業務利用が構造的に漏えいを起こす」ケースの方がはるかに多くなる。対策は禁止ではなく設計だ。入力データの分類・ログ管理・権限制御の3軸を、自社のAI利用フェーズに合わせて一つずつ整備する。まず「ログが取れているか」の確認から始めてほしい。