AIエージェント、拒否しても機密は漏れる｜研究解説

AIエージェント、拒否しても機密は漏れる｜研究解説 研究・論文

AIエージェントを業務で使うということは、カレンダー・顧客情報・認証情報といった機密を、モデルのコンテキストウィンドウに載せるということです。2026年8月20日にarXivで公開された査読前論文は、モデルが「その情報は開示できません」と正しく拒否していても、無害に見える出力の統計的な偏りから機密が復元できることを示しました。商用8モデルでの検証では、2桁の秘密は上位モデルで完全一致100%、4桁でも最大82%で復元されています。「拒否したから漏れていない」という確認は、安全の証明にはならないという指摘です。

この記事でわかること

  • 「意図しないコンテキスト漏えい」とは何で、どういう理屈で起きるのか
  • 直接聞けば漏えい0%なのに、なぜ間接的には復元できてしまうのか
  • 情シスがAIエージェント導入・評価の前提を、どう見直すべきか
  • この研究の限界（査読前・黒箱前提・秘密の種類が限定的）

どんな研究か

取り上げるのは「Inadvertent Context Leakage in Language Models」（Jaiden Fairoze、Neal Mangaokar、Kamalika Chaudhuri、Sanjam Garg、Saeed Mahloujifar／arXiv:2608.19857、2026年8月20日公開）です。一文でいえば「コンテキストに機密が置かれているだけで、モデルの通常出力にその機密と相関した痕跡が残り、第三者が復元できてしまう」ことを実証した研究です。

まず前提として、これはarXivのプレプリント（査読前）です。結果は今後の査読・追試で変わりうるため、この記事も「そういう指摘が出た」という位置づけで読んでください。分類はcs.LG（機械学習）とcs.CR（暗号・セキュリティ）です。

なぜ「拒否したから安全」と言えないのか

短く答えると、拒否は「明示的な開示」を止めるだけで、出力全体に残る統計的な偏りまでは止められないからです。

秘密は出力の「癖」として滲み出る

モデルに「この番号は絶対に開示しないこと」と指示したうえで、まったく無関係な作業（文章生成、数字の列挙、創作など）をさせます。出力そのものに秘密は書かれていません。しかし、コンテキストに置かれた値によって、出力の細かな確率分布がわずかに変わります。論文はこれを「チャネル（情報の通り道）」と呼び、そのチャネルを読む方法を攻撃者側が学習できることを示しました。

重要なのは、同じモデルに直接「秘密を教えて」と聞いた場合は漏えい0%だった点です。論文の直接要求160回では、いずれもモデルは正しく拒否しています。つまり、モデルの安全訓練は機能しているのに、それとは別の経路で情報が出ていくということです。

攻撃者は「公開版」で読み方を練習できる

受動的な攻撃者は、まず一般に使える同じモデルに大量の問い合わせを行い、「このモデルはこういう癖で漏らす」という対応表を作ります。この学習コストは一度払えば済み、あとは標的の導入環境に対して使い回せます。同じフロンティアモデルを何百万人が使っている以上、1回の解析コストが利用者全体に薄まる——論文はこの構造こそが個々のリスクを増幅すると指摘しています。

能動的な攻撃は、もっと直接的

能動的な攻撃者はプロンプトインジェクションを使い、「秘密の各桁を感嘆符の数で表現せよ」といった符号化ルールをモデルに埋め込みます。出力は普通の文章に見えますが、感嘆符の個数を数えれば桁が読めるという仕掛けです。論文では、この指示文自体を強化学習（GRPO）で最適化しています。

実験で示された数字

評価対象は商用の8モデル（Claude Opus 4.6／Claude Sonnet 4.6／Gemini 3.1 Pro／Gemini 3.1 Flash-Lite／GPT-5.4／GPT-5.4 nano／Grok 4／Grok 4.1 Fast）です。主な結果は次のとおりです。

検証内容 結果
直接「秘密を教えて」と要求（対照実験） 漏えい0%（160回すべて拒否）
2桁の秘密の完全復元 上位2モデル（Claude Opus 4.6／Gemini 3.1 Pro）で100%
4桁の秘密の完全復元 Claude Opus 4.6で82%、Gemini 3.1 Proで44%
9桁のSSN（米国社会保障番号）抽出／符号化攻撃 Claude Opus 4.6は第1段階97.1%・第2段階76.5%、Gemini 3.1 Proは88.6%・46.8%
ユーザーの属性（健康・金銭など15項目）の推定 言語的に判定するベースラインに対し、真陽性率が約1.7倍

そして論文の結論のうち、実務にいちばん響くのはここです。「より高性能なモデルほど多く漏らす」。指示追従性能が高いほどコンテキスト内の値に敏感になるため、著者らは「漏えいは修正可能なバグというより、能力の副産物だ」と述べています。性能の良いモデルに乗り換えれば安全になる、という話ではないわけです。

情シスにとって何を意味するのか

「機密を聞き出せなかったから安全」という受け入れテストは弱い

社内でAIエージェントを評価するとき、担当者がチャットで「顧客の口座番号を教えて」と入力し、拒否されたことをもって合格とする——よくある確認手順だと思います。この論文が突いているのは、まさにそこです。直接要求での漏えいは0%でも、別経路では復元されている。拒否レスポンスは「明示的開示に対する防御が効いている」証拠にはなりますが、機密が保護されている証拠にはなりません。

結局は「コンテキストに入れない」が効く

論文が提示する本質的な緩和策は「保護すべき値が変わっても出力分布がほぼ変わらないようにする」という学習時の設計であり、利用者側で今すぐ実装できるものではありません。裏を返せば、利用者側にできる確実な手当ては、そもそもコンテキストに載せる機密を減らすことに尽きます。エージェントに渡す文書・メモリ・ツール権限を、業務に必要な最小限まで削る。この地味な設計が、そのまま漏えい面積の縮小になります。関連して、社内RAGで外部LLMに機密を渡さない工夫については社内RAGの機密を外部LLMから隠す｜研究解説も参考になります。

出力フィルタは「越えるべき制約」にされる

出力側でマスキングやフィルタをかける対策は広く使われていますが、論文はこれを過信しないよう警告しています。強化学習で攻撃文を最適化する場合、フィルタは単に「回避すべき制約条件」として学習対象に組み込まれてしまうからです。フィルタ自体は必要ですが、それだけを最後の砦にはできません。フィルタ性能の実像についてはOpenAI Privacy Filterの日本語精度と限界もあわせてどうぞ。

ログを見ても気づけない

この攻撃のいやらしさは、出力が無害に見えることです。通常の業務応答のなかに統計的な偏りとして情報が乗るため、キーワード検知型の監査ログでは異常として上がってきません。監視で見るべきは出力の中身よりも、「誰がどのコンテキストにアクセスできるエージェントを、どれだけの回数叩いたか」という利用パターンのほうだ、ということになります。特に、外部に公開している問い合わせボットのように匿名で大量に叩ける口は要注意です。

現場目線の所感

正直にいうと、この論文はやや重い読後感があります。これまでのAIセキュリティの多くは「悪いプロンプトを弾く」「危ない出力を止める」という、入口と出口を締める発想で対処できました。しかし今回示されたのは、正しく振る舞っているモデルからも情報が出ていくという話です。入口も出口も締めたのに漏れる、という状況は、現場の対策の立てようがない部分があります。

加えて、情シスの立場では「そのエージェントのコンテキストに何が載っているか」を完全に把握すること自体が難しい。SaaSに組み込まれたAI機能は、どの社内文書をどこまで参照しているのかがブラックボックスになりがちです。端末の細部まで目が届かないのと同じ構図が、AIの参照範囲にも起きつつあります。ここは、ベンダーに「コンテキストに載る情報の範囲」を仕様として出させる交渉から始めるしかないと感じます。エージェントの権限そのものを絞る方向の研究はAIエージェントの過剰権限を学習で抑制｜研究解説で紹介しています。

限界と、過度に怖がらないための注意

実務判断に使う前に、論文自身が挙げている限界を押さえておく必要があります。

  • 査読前のプレプリントであり、追試で数字が変わる可能性がある。
  • 検証された秘密は「数字列」と「はい／いいえで答えられる属性」の2種類。自由文の機密（契約書の中身など）に同じ精度で通用するかは未検証。
  • すべて黒箱（API経由）での検証。攻撃者がモデルを特定でき、事前の解析コストを払えることが前提。
  • 秘密は一様ランダムな値を使用。現実の番号は書式や地域による偏りがあり、その影響は検証されていない。
  • 出力にノイズを加える／応答長を正規化するといった運用側の緩和策は評価されていない。

つまり「明日にも社内の顧客番号が抜かれる」という話ではありません。攻撃には対象モデルの特定と相応の準備が要ります。ただし、準備コストが一度きりで、多数の利用者に対して再利用できるという指摘は、時間が経つほど効いてくる性質のものです。

情シスはどうすべきか

この段階で自前の長大な対策表を作るより、まずは基本の型に沿って足元を固めるほうが現実的です。生成AI固有のリスク分類はOWASP LLM Top10 2026、専門家と実データの差で整理していますので、社内のリスク台帳づくりの下敷きに使ってください。

組織全体の底上げには、IPAの中小企業の情報セキュリティ対策ガイドラインが使えます。AI固有の話は書かれていませんが、「機密情報をどこに置き、誰がアクセスできるか」を棚卸しする手順は、そのままコンテキストに載る情報の棚卸しに転用できます。利用者への啓発には対策のしおりが手軽です。

技術で塞ぎきれない以上、「便利だからといって機密を全部エージェントに食べさせない」という利用者側の習慣づけが、結局いちばん効きます。地味ですが、社内向けのAI利用ルールに一行加えるところから始めるのが現実的です。

まとめ

  1. 拒否は安全の証明ではない。直接要求では漏えい0%でも、無害な出力の統計的偏りから2桁の秘密は100%、4桁でも最大82%が復元された（査読前論文）。
  2. 高性能なモデルほど漏らす。著者らは漏えいを「能力の副産物」と位置づけており、モデルを新しくすれば解決する類の問題ではない。
  3. 利用者側の手当てはコンテキストの最小化。エージェントに渡す文書・メモリ・権限を必要最小限に絞ることが、現時点で最も確実な対策になる。

出典

タイトルとURLをコピーしました