コンピュータ操作エージェントはデフォルトで過剰共有する

「Q3の数字」を同僚に転送するよう指示されたコンピュータ操作エージェントは、何がQ3の数字に当たるのか、どのファイルにそれが入っているのか、そして隣に開かれているスプレッドシートが同じメールに含まれるべきものかどうかを判断しなければなりません。2026年6月のあるベンチマークは、15のフロンティアなエージェントにこの種の判断をさせ、そのうち11が検証シナリオの半数を超える場面で非公開情報を漏洩させ、平均漏洩率が67.9%に達したことを明らかにしました。¹

コンピュータ操作エージェントにおけるプライバシーの失敗は、プロンプトインジェクションではありません。攻撃者が何かを仕込むわけではないのです。エージェントが漏洩するのは、役に立とうとしているのに、自分が行動しているコンテキストにどの情報が属するのかを見分けられないからです。 新たな論文 Capable but Careless: Do Computer-Use Agents Follow Contextual Integrity? は、この失敗モードに名前を与え、それを測るベンチマークを構築し、フロンティア全体に広く見られることを示しています。¹

この結果が注目に値するのは、エージェントのセキュリティをめぐる議論がこれまでほとんど見過ごしてきたリスクを切り出している点にあります。私は以前、2つの信頼できない入力と、ツールを使うエージェントが攻撃者によって引き起こされる失敗について書きました。コンテキスト上の過剰共有は、ちょうど逆の形をしています。危険は内側にあり、適切な開示についてのエージェント自身の判断にこそ宿るものであり、ループの中に悪意あるものが何もないときでさえ表れるのです。

要点（TL;DR）

• コンピュータ操作エージェント（CUA）は、メール、カレンダー、ToDoリストといった個人向けアプリをまたいで行動します。アプリケーション横断のアクセスは便利ですが、それによってエージェントはあるコンテキストの情報を、本来属さない別のコンテキストへ持ち込めるようになってしまいます。¹
• Capable but Careless（2026年）は、このリスクを実行可能で決定論的に採点されるシナリオへと変換し、15のフロンティアなエージェントを評価するベンチマーク、AgentCIBench を提示しています。¹
• このベンチマークは、視覚的近接（visual co-location）、タスクの曖昧さによる過剰共有（task-ambiguity overshare）、受信者の不一致（recipient misalignment）という3つの失敗モードを標的としています。¹
• 15のエージェントのうち11が50%を超えるシナリオで漏洩し、平均漏洩率は67.9%に達しました。しかもその失敗は、エージェントがタスクを完遂するためにエンドツーエンドで行動したときにも持続したのです。¹
• その枠組みとなるのが contextual integrity であり、プライバシーとは秘密保持のことではなく、情報がそのコンテキストにふさわしい形で流れることだという、Helen Nissenbaum の考え方です。² エージェントには能力があります。欠けているのは、情報がどこへ流れてよいのかという感覚なのです。

プロンプトインジェクションとは異なる失敗

私自身のものを含め、エージェントのセキュリティに関する研究の多くは、攻撃者を出発点とします。誰かがウェブページやツールの説明、あるいは文書の中に指示を隠し、エージェントがそれに従ってしまう。その防御策は、入力を信用せず、エージェントがそれをもとに行える操作を制限することです。

コンテキスト上の過剰共有には、攻撃者がいません。ユーザーが妥当な要求をし、エージェントがそれに応えようとして、その過程で別のコンテキストに属する非公開のものを開示してしまうのです。論文はこれを contextual integrity を通して捉えています。これは Helen Nissenbaum のプライバシー理論であり、情報の流れには、それが生じるコンテキストに結びついた規範が伴うとする考え方です。² あなたの診断結果をセラピストが知っているのは適切なことです。しかしセラピストがそれを雇用主に転送すれば、技術的には秘密が破られていなくても、その情報が越えてはならないコンテキストの境界を越えたために規範が侵害されます。

コンピュータ操作エージェントは、そうしたコンテキストの数々を同時にまたいで動作します。メールを下書きしながらあなたのカレンダーを見ることができ、一人に送るときも連絡先一覧の全体を見ることができ、ひとつの項目について答えるときもToDoリスト全体を見ることができます。そうした隣り合わせのどれもが、ある場所では適切なものを、適切でない場所へ持ち込んでしまう機会となるのです。エージェントは乗っ取られているわけではありません。過剰に役立とうとしているのであり、複数コンテキストの環境では、その過剰な親切がプライバシーの漏洩のように見えてしまうのです。

エージェントが漏洩する3つの経路

AgentCIBench は、このリスクを3つの失敗モードにわたる決定論的に採点されるシナリオとして操作可能にしています。これは論文の中でも腑に落とす価値のある部分です。なぜなら、それぞれがエージェントの触れる現実のインターフェースに対応しているからです。¹

視覚的近接（visual co-location）。 エージェントは、インターフェース上でタスクの対象の隣に位置する禁止された項目を取り込んでしまいます。請求書を1通添付するよう指示されると、隣の1通も一緒につかんでしまう。どちらも画面上にあったため、近さが関連性として読み取られたのです。開示を引き起こしたのはタスクではなく、UIのレイアウトでした。

タスクの曖昧さによる過剰共有（task-ambiguity overshare）。 仕様が不十分なプロンプトを与えられると、エージェントは尋ねたり絞り込んだりするのではなく、密度の高い個人的な状態をそのまま吐き出します。「私が取り組んでいることを伝えて」が、受信者が決して見るべきでない項目も含めたToDoリスト全体になってしまうのです。曖昧さは、より少ない開示ではなく、より多い開示の方へと解決されていきます。

受信者の不一致（recipient misalignment）。 エージェントは、ふさわしくない宛先へ内容を送ってしまいます。正しい情報が誤った相手に届く。ひとつの関係にだけ属していたデータに、全員返信の本能を当てはめてしまうようなものです。

この3つのモードには共通の根本原因があります。エージェントがアクセスを許可とみなしてしまうことです。隣の請求書、ToDoリスト全体、より広い受信者の集まりを見ることができるという理由で、それを使うことが適切であるかのように振る舞ってしまう。contextual integrity とはまさに、アクセスと適切さは別物であるという判断のことであり、このベンチマークは、現在のエージェントがその区別を確実には行えていないことを示しています。

どれほど深刻で、なぜそれが続くのか

見出しを飾る数字は、ささいなものではありません。15のフロンティアなエージェントのうち11が半数を超えるシナリオで漏洩し、平均漏洩率は67.9%に達しました。¹ この分野の大半で3回に2回の割合で現れる失敗モードは、もはやエッジケースではありません。デフォルトの挙動なのです。

エージェントを世に出そうとする者にとって最も重要なのは、その失敗が、孤立した探りのテストだけでなく、エージェントがタスクを完遂するために環境内でエンドツーエンドに行動したときにも持続したという点です。¹ 人工的な条件下でのみ現れる漏洩なら、簡単に切り捨てられるでしょう。しかし、エージェントが実際の仕事をこなす中でも生き残る漏洩は、そのエージェントがどう動作するかという性質そのものなのです。論文は、まさにこの理由から、コンテキスト上の開示の検証をデプロイ前の安全チェックとして位置づけています。¹

この失敗が続くのは、エージェントの通常の目的のうちに、それに抗うものが何もないからです。エージェントはタスクを完遂すれば報われます。開示しすぎてもタスクの完遂が妨げられることはめったにないため、過剰な開示は、挙動を形づくるループの中でなんのコストも負いません。アクセスできる情報の一部がこのコンテキストでは立ち入り禁止だ、という明示的な信号がなければ、役に立つ道と漏洩する道は同じ一本の道になってしまうのです。

ではどうすればよいか

その対処法は、エージェントの能力を下げることではありません。適切さを、推し量ってもらうのを前提とした規範ではなく、エージェントがチェックする制約にすることです。このパターンは、私が承認プロンプトについて論じてきたことと響き合います。エージェントに、何が境界を越えるのかを黙って決めさせて信用してはならないのです。

開示の可否を、アクセスではなく、受信者とコンテキストに基づいて判断する。 エージェントが送信、添付、共有を行う前に問うべきなのは「エージェントはこれを見られるか」ではなく「これはこの流れの中で、この受信者に対してふさわしいか」です。アクセスは許可の代理指標として誤っており、3つの失敗モードはいずれも、それを代理指標として使ってしまった事例なのです。

曖昧さを許可証ではなく、停止の合図として扱う。 仕様が不十分な要求は最もリスクの高い入力です。なぜなら、エージェントはそれを開示の方へ解決してしまうからです。要求が曖昧なときに絞り込んだり尋ねたりするエージェントは、見えるものすべてで空白を埋めるエージェントよりも漏洩が少なくなります。

デプロイ前に漏洩を検証する。 この論文の貢献は、ひとつには方法そのものにあります。すなわち、contextual integrity を測定可能なものへと変える、決定論的に採点されるシナリオです。攻撃者由来の失敗を捕らえる可観測性やサンドボックス化のチェックと並べて、コンテキスト上の開示をデプロイ前のチェックとして扱うことで、それらのチェックでは覆えない隙間が塞がれます。

より大きな論点は、エージェントの安全性には2つの半分があるということです。一方の半分は敵対的なものです。信頼できない入力、インジェクション、ツールの汚染といった、攻撃者が引き起こす失敗です。もう一方の半分は気質的なものです。誰も攻撃していないとき、正当なアクセスを使ってエージェントが何をするか、ということです。コンピュータ操作エージェントは、あなたが持つあらゆるコンテキストをまたいで行動できるだけの能力を備えています。そうすべきかどうかという問いに、現状では3回に2回の割合で誤って答えているのです。

重要なポイント

コンピュータ操作エージェントを導入する人へ： - デプロイ前のチェックに、コンテキスト上の開示の検証を加えましょう。攻撃者を中心に据えた評価では、過剰共有は捕らえられません。 - 共有の操作の可否は、エージェントがデータにアクセスできるかどうかではなく、受信者とコンテキストの適切さに基づいて判断しましょう。 - 曖昧な要求は最もリスクの高いケースとして扱いましょう。エージェントは曖昧さを、より多い開示の方へと解決してしまうからです。

エージェントとプロダクトを作る人へ： - 3つの失敗モード（視覚的近接、タスクの曖昧さによる過剰共有、受信者の不一致）は、具体的なUIの面に対応しています。近さが関連性として読み取られることを前提に、それぞれの面を設計しましょう。 - タスク完遂の報酬は、過剰な開示に抗う信号を一切与えません。適切さが重要であるなら、それを明示的な制約にしましょう。

セキュリティとプライバシーのレビュアーへ： - contextual integrity は使える枠組みを与えてくれます。情報の流れを、秘密か否かの二択にではなく、コンテキストの規範に照らして評価しましょう。 - フロンティアなエージェント全体で平均67.9%という漏洩率は、現状のデフォルトが、開示の制御なしには自律的な複数コンテキストの行動にとって安全でないことを意味します。

よくある質問（FAQ）

contextual integrity とは何ですか

contextual integrity とは、Helen Nissenbaum によるプライバシーの理論で、情報の流れには、それが生じるコンテキストに結びついた規範が伴うとするものです。プライバシーが保たれるのは、情報がそのコンテキストにふさわしい形で動くときであり、たとえ技術的に何も秘密でなかったとしても、それを統べる規範が許さないコンテキストへと情報が越えていったときには、プライバシーは侵害されます。

これはプロンプトインジェクションとどう違うのですか

プロンプトインジェクションは敵対的なものです。攻撃者がエージェントを乗っ取る指示を隠します。コンテキスト上の過剰共有には攻撃者がいません。ユーザーが正当な要求をし、エージェントが役に立とうとして、別のコンテキストに属していた情報を開示してしまうのです。この2つには異なる防御が必要であり、攻撃者を中心に据えた検証では過剰共有は検出できません。

AgentCIBench とは何ですか

AgentCIBench は、Capable but Careless で提示されたベンチマークであり、コンテキストをまたいだ漏洩を、実行可能で決定論的に採点されるシナリオへと変換します。3つの失敗モード（視覚的近接、タスクの曖昧さによる過剰共有、受信者の不一致）を検証し、15のフロンティアなコンピュータ操作エージェントの評価に用いられました。

いくつのエージェントが失敗したのですか

検証された15のフロンティアなエージェントのうち、11が50%を超えるシナリオで非公開情報を漏洩させ、平均漏洩率は67.9%でした。その失敗は、孤立した探りのテストだけでなく、エージェントがタスクを完遂するためにエンドツーエンドで行動したときにも持続しました。

より良いプロンプトでこれを直せますか

プロンプトは助けにはなりますが、論文の枠組みが示唆しているのは、持続する対処法は構造的なものだということです。すなわち、開示の操作の可否をアクセスではなく受信者とコンテキストの適切さに基づいて判断し、デプロイ前に漏洩を検証することです。タスク完遂の目的は過剰な開示に抗う信号を一切与えないため、適切さは前提とするのではなく、制約として強制されなければならないのです。

出典

• Anmol Goel and Iryna Gurevych, “Capable but Careless: Do Computer-Use Agents Follow Contextual Integrity?,” arXiv, June 22, 2026: arxiv.org/abs/2606.23189
• Helen Nissenbaum, “Privacy as Contextual Integrity,” Washington Law Review 79, no. 1 (2004), この枠組みの起源であり、後に Privacy in Context（Stanford University Press, 2010）で展開されました: Washington Law Review
• 関連するエージェントのセキュリティに関する文章: 2つの信頼できない入力、承認プロンプトは認可ではない、そして見えないエージェント