もし私のエージェントの中核タスクが3つの属性すべてに同時に貼り付いていて、どの要素も全く分解できない場合、どうすればよいですか？
この状況は通常、そのエージェントの設計自体がアーキテクチャレベルで構造的リスクを抱えていることを意味し、まず一歩下がって問う価値がある。このタスクは本当に1つのエージェントがこの3つの能力すべてを同時に備える必要があるのか、それとも、それぞれ2つの属性しか持たない複数のサブエージェントに分割し、追加の検証層を通じて互いに連携させることはできないか、と。例えば「受信箱を読み、対応が必要かを判断し、必要なら対応する動作を自動実行する」という複合型エージェントは、3つの役割に分割できる。受信箱を読み取り、構造化された要約を生成するだけのエージェント（非公開データへのアクセス＋信頼できないコンテンツへの露出はあるが外部通信はできない）。構造化された要約に基づいて何をすべきかを判断するエージェント（生のメール内容には直接触れず、すでにフィルタリング・整理された結果のみを処理する）。実際に動作を実行するエージェント（非公開データへのアクセス＋外部通信能力はあるが、入力はすべて前段のエージェントの構造化された判断から来ており、生の信頼できないコンテンツに直接晒されない）。
このように分解すると、どの役割も3つの属性すべてを同時には持たず、たとえ1つの部分が突破されても、攻撃連鎖は役割間の引き継ぎ地点で断ち切られる。このアプローチはシステム全体の複雑さと遅延を犠牲にする代わりに、各役割を独立して監査し、独立して権限を制限できるという利点を得る。
方式2（先に下書きを出してから承認する）が最も実装しやすいように聞こえますが、これを優先的に選ぶべきですか？
実装の容易さは確かに方式2の利点だが、それがデフォルトの第一選択であるべきことを意味しない。その実際の防御力は、あなたが完全にはコントロールできない変数に大きく依存する。ユーザーが本当に下書きの内容を注意深く読むかどうかだ。IBM Bobの事件はすでに、承認リクエストが十分な頻度で現れ、ユーザーが繰り返される確認要求に疲れると、「承認」という動作が「判断を伴う関門」から「反射的なボタンクリック」へと容易に退化してしまうことを証明している。この段階まで退化すると、方式2が実務上提供する保護は、紙の上で見えるものよりもはるかに低くなる。
より現実的な判断方法は、自分自身に問うことだ。このエージェントはどれくらいの頻度で承認を必要とするか。あるタスクフローが連続して5、6回の承認を必要とするなら、方式2の実際の効力は承認疲れによって大幅に削がれてしまい、この場合はアーキテクチャ自体でリスクを防ぐ方式1か3（ユーザーの継続的な警戒心に頼るのではなく）を優先的に検討すべきだ。承認頻度がもともと低く、1つのタスクに1回の承認しか必要としないなら、方式2の効力は比較的維持されやすく、この場合は確かに相対的にシンプルで効果的な選択となる。
方式3では「より低い権限のサブプロセス」で先にフィルタリングすると述べていますが、このサブプロセス自体が新たな攻撃対象になりませんか？
これは鋭い質問であり、答えは「なる、ただしリスクレベルは異なる」だ。サブプロセスは確かに攻撃者の次のターゲットになるが、メインエージェントとの重要な違いは権限範囲にある。サブプロセスはフィルタリングと予備的な処理のみを行うよう設計されており、非公開データへのアクセスや外部通信の能力を持たない。たとえサブプロセス自体が突破されても、攻撃者が手に入れるのはせいぜい「フィルタリング結果を操作する」能力であり、非公開データを直接動かしたり外部に何かを送信したりする能力ではない。これは、信頼できないコンテンツという要素を分解しても、リスクが完全に消えるわけではなく、「メインエージェントが突破され、直接データ流出が発生する」というリスクから、「サブプロセスが突破され、さらにメインエージェントの権限制限を突破しなければ実害を引き起こせない」というリスクへと格下げされることを意味する。攻撃者が乗り越えるべき障害が1つ増えるのだ。
これはより根本的な原則とも呼応している。致命的三要素のどの要素を分解するとしても、本質的にはリスクを新たに生じた要素へと移すことであり、リスクを消し去ることではない。サブプロセス自体のフィルタリングロジックも定期的な監査が必要であり、それが「表面上はフィルタリングしているように見えるが、実際には信頼できないコンテンツをそのままメインエージェントに渡している」という名ばかりの状態に誤って設計されていないかを確認する必要がある。これが、アーキテクチャの複雑さが高い方式3が、方式1や2よりも継続的なメンテナンス投資を必要とする理由でもある。
すでに二者択一の法則を適用しているエージェントに、後から新機能を追加する際、うっかり3つ目の属性を再び加えてしまわないようにするにはどうすればよいですか？
最も直接的な方法は、「二者択一の法則に違反していないか確認する」ことをリリース前のアーキテクチャレビューチェックリストに書き込み、エンジニアの記憶に頼るのではなく、強制的なチェックポイントにすることだ。具体的には、すべての新機能提案に、この新機能が既存のエージェントの役割に、これまでなかった非公開データへのアクセス、信頼できないコンテンツへの露出、または外部通信能力を新たに与えるかどうかを明示するよう求めることができる。答えがイエスなら、現在この役割がもともと取り除いていたのはどの要素か、新機能はその要素を再び加えようとしているのかを明確に説明しなければならない。もしそうであれば、この新機能は既存の役割に直接積み重ねるべきではなく、新しい、より権限の制限された役割に分割することを検討すべきだ。
実務上よくある見落としの状況は「段階的な機能拡張」だ。あるエージェントがもともとデータの読み取りしかできなかった（外部通信は取り除かれていた）ものが、後になってユーザーから「ついでに通知も送ってもらえないか」と繰り返し要望され、エンジニアリングチームが既存の役割に通知送信機能を直接追加してしまい、この小さな変更がその役割を再び三要素すべて揃った状態に戻してしまったことに気づかない、というケースだ。これが、アーキテクチャレビューチェックリストがプロジェクト開始時に一度だけ行われるものであってはならず、権限やツールを新たに追加するすべての変更リクエストに紐づける必要がある理由でもある。二者択一の法則が日常的な機能の積み重ねによってひそかに破られないようにするためだ。
致命的三要素（非公開データへのアクセス、信頼できないコンテンツへの露出、外部通信能力）が何かを知ることと、自分のエージェントアーキテクチャの中で実際にそれをどう分解するかを知ることは、別の問題だ。Metaのセキュリティチームは2025年10月、「二者択一の法則（Rule of Two）」を公表し、具体的な実装原則を示した。エージェントは1つのセッション内で、3つの属性のうち最大2つまでしか同時に満たしてはならないというものだ。この記事が扱うのは次のステップ、すなわち3つの属性それぞれを1つずつ分解した場合、実務上それがどのようなものになり、それぞれのトレードオフは何かということだ。
エージェントの中核タスクが信頼できないコンテンツの処理と外部通信である場合（メールに自動返信するウェブ閲覧アシスタントなど）、非公開データへのアクセスという要素を分解することは、エージェントを完全に隔離された環境、あるいは匿名化されたテストデータにしかアクセスできない環境に限定することを意味する。たとえ注入が成功しても、攻撃者が手に入れるのは無関係な内容だけだ。このアプローチの利点は実装が比較的単純であることだ。複雑な人間による承認フローが不要で、エージェントは継続的に自律動作できる。欠点は機能の完全性を犠牲にすることだ。多くの実用的なシナリオは、エージェントが実際の非公開データに触れることで初めて意味を持つ（ユーザー自身の注文履歴を調べる手伝いをするなど）。中核タスク自体が非公開データと切り離せないなら、このアプローチはそもそも適用できない。
エージェントが非公開データへのアクセスと信頼できないコンテンツの処理の両方を必要とする場合（受信箱を読み取り、メール内容に基づいてタスクを整理するアシスタントなど）、外部通信という要素を分解することは、「自動送信」を「まず下書きを生成し、ユーザーが確認してから送信する」に変えることを意味する。このアプローチの利点は、たとえエージェントの判断がハイジャックされ悪意あるコンテンツを含む下書きを生成しても、それが自動的に実害を引き起こすわけではなく、ユーザーが確認画面で異常に気づける機会がある点だ。欠点はユーザー体験が中断されることだ。エージェントが複数のステップを連続して処理する必要がある場合、ユーザーは何度も承認を求められるかもしれず、この防御線の実際の効力は、ユーザーが本当に下書きの内容を注意深く読むかどうかにかかっている。見慣れたインターフェースを見て反射的に確認ボタンを押すのではなく。これはまさにIBM Bobの事件で見られた「人間の承認がセキュリティ演劇と化す」のと同じリスクだ。
エージェントが非公開データへのアクセスと外部通信能力の両方を必要とする場合（口座残高の照会と送金の実行ができる金融アシスタントなど）、信頼できないコンテンツという要素を分解することは、エージェントを完全に信頼でき制御された入力元のみに厳しく限定することを意味する。ユーザーが貼り付けた任意のウェブページのコンテンツやサードパーティの文書を直接読み取らせない。この種のコンテンツを本当に処理する必要がある場合は、まず独立した、より低い権限のサブプロセスで予備的な処理とフィルタリングを行い、生のコンテンツではなくその結果を、実際の操作権限を持つメインエージェントに渡す。このアプローチの利点はエージェントの自律性と機能の完全性を保てる点だ。欠点はアーキテクチャの複雑さが最も高くなることで、追加の隔離層とプロセスの設計が必要になり、「何を信頼できる入力と定義するか」自体も継続的なメンテナンスと更新が必要で、一度設定すればそれで終わりというものではない。
3つのアプローチに絶対的な優劣はなく、選択はエージェントの中核的な価値提案がどの属性から切り離せないかによって決まる。エージェントの価値が「自分のデータの処理を手伝ってもらう」ことにあるなら、非公開データへのアクセスは通常取り除けず、方式2か3を検討すべきだ。エージェントの価値が「外の世界を閲覧するのを手伝ってもらう」ことにあるなら、信頼できないコンテンツへの露出は通常取り除けず、方式1か2を検討すべきだ。エージェントの価値が「一連の動作を自動的に完了してもらい、ずっと見張っている必要がない」ことにあるなら、外部通信の自律性は通常中核的なセールスポイントであり、方式1か3を検討すべきだ。実務上、多くのエージェントシステムは異なる機能モジュールにそれぞれ異なるアプローチを適用している。例えば同じアシスタントでも、一般的な照会を処理する際は方式1（非公開データに触れない）を採り、口座操作を処理する際は方式2（先に下書きを出してから確認）を採る、といった具合だ。システム全体で同じ分解ロジックを使わなければならないという決まりはない。
あなたがエージェントシステムのセキュリティアーキテクチャを設計または監査している場合、二者択一の法則は具体的な検収基準を与えてくれる。実際のあらゆる運用経路について、それがどの要素を分解しているか、そしてその分解が実務上本当に有効に機能しているか（例えば「下書き確認」がユーザーによって本当に注意深く読まれているか、それとも形式的な関門に過ぎないか）を一つずつ確認することだ。これはあなたの説明責任の基盤に直接関わる。「この機能モジュールは中核タスクに不要なため、意図的に非公開データへのアクセスを取り除いた」と明記されたアーキテクチャ文書は、三要素を一度も評価せずに導入した場合とは全く異なるレベルのガバナンス責任を意味する。前者は後の調査の際、「この経路のリスクはすでに評価され緩和されている」と明確に示せる。後者は判断プロセス全体をゼロから再構築する必要があり、しかもそれは実際のインシデントが発生した後に、やむを得ず行うことになる可能性が高い。