なぜより賢いシステムプロンプトでは致命的三要素の問題を解決できないのですか？
エージェントが「十分に賢くない」ことが問題なのではなく、LLM自体がデータベースのような「これは指示」「これはデータ」を明確に区別するハードな構造的境界を持たないことが問題だからだ。システムプロンプトは多数の入力の一つに過ぎず、メールの内容やウェブページのテキストと同様、最終的にはモデルが解釈するトークンになる。攻撃者が悪意あるコンテンツを正当な指示に十分似せられれば、モデルはそれに従ってしまう可能性がある。公表されている最強の検知手法でも既知の攻撃パターンに対する精度は約97%——つまり約3%の見逃し率があるということだが、一度成功すればすべてが流出してしまうリスクにとって、ゼロでない失敗率は真の安全マージンとは言えない。
これが、致命的三要素の枠組みがプロンプトではなくアーキテクチャに焦点を当てる理由でもある。モデルに絶対に騙されないよう教え込もうとするのではなく、連鎖のどこかを物理的に完遂不可能にする——確率的な防御ではなく決定論的な防御である。
IBM BobとNotion AIのこの2件では、人間による承認機構が攻撃を防ぐべきだったのではないですか？
まさにこの2件で注目すべき点はそこにある——両システムとも人間による承認機構を備えていたが、承認機構自体に欠陥があった。IBM Bobの問題は、一見無害に見えるコマンドにユーザーが「常に許可」を設定すると、その承認をエージェントが利用して、その後より危険な一連の操作を連鎖させてしまう点にあった。承認された対象と実際に実行された内容の間にずれが生じていた。研究者はこの状況を「人間の承認がセキュリティ演劇と化した」と表現している。承認という行為自体は確かに発生したが、検証された内容は本来検証されるべき高リスク操作と一致していなかったからだ。Notion AIの問題は時系列上の欠陥だった。AIが行った編集は、ユーザーが承認ボタンを押す前にすでにストレージへ書き込まれており、たとえユーザーが最終的に拒否を選んでも、データの変更はすでに発生している可能性があった。
これが示しているのは、人間による承認が真に有効であるためには、承認する内容とタイミングが実際のリスク行動に正確に対応していなければならず、形式的に「承認」ボタンを置くだけでは意味がないということだ。
Metaの「二者択一の法則」はエージェントの機能を制限するように聞こえますが、実際にはどうトレードオフすればよいですか？
このトレードオフは確かに存在し、Meta自身もその枠組みの説明の中で、二者択一の法則を厳格に守ることがユーザー体験を犠牲にしうると認めている。しかしこれは欠陥ではなく意図的な設計の結果である。例えば、ユーザーの受信箱を処理するエージェントが、受信箱の読み取り（非公開データ）と自動返信（外部通信）の両方の能力を同時に持っている場合、悪意ある指示が仕込まれたメール（信頼できないコンテンツ）を読み込んだ瞬間、3つの要素が同時に成立し、構造的に高リスクな設計となってしまう。この組み合わせを断ち切るには、自動返信機能を「まず下書きを生成し、ユーザーが確認してから送信する」方式に変更する選択肢がある。これによりエージェントは表面上3つの能力すべてを持ち続けるが、実際には「外部通信」の部分は人間の関与がなければ完遂できなくなり、1つのセッション内で三分の二の境界線を引き直したことになる。
つまり二者択一の法則は開発者に機能を削れと要求しているのではなく、3つの能力のうちどこに人間的または構造的な関門を挿入できるかを考え抜くよう求めているのだ。その関門をどこに置くかが、ユーザーがどれだけの利便性を犠牲にして、どれだけの確定的な安全性を得るかを決める。
企業は致命的三要素チェックリストを、書いたまま放置される文書ではなく、実際に実行されるプロセスへとどう変えればよいですか？
鍵となるのは、チェックリストを既存の調達・リリース審査プロセスに組み込むことであり、人々が選択的に参照するだけの独立した文書を別途作成することではない。実務上有効なのは、各エージェントプロジェクトのアーキテクチャ設計文書に必須項目を追加することだ。あり得るすべての実行経路について、非公開データへのアクセス、信頼できないコンテンツへの露出、外部通信という3つの属性を備えているかを一つずつ明記する。いずれかの経路で3つすべてが成立する場合、その文書にはリリース審査を通過する前に具体的な緩和策を添付することを必須とする——これは、セキュリティ審査で長年ペネトレーションテストの報告書添付が求められてきたのと同じ論理であり、抽象的なリスク意識を、実際に不合格になりうる具体的なチェックポイントへと変換するものだ。
見落とされがちなもう一つの実施上の詳細は、監査の頻度をリリース時の一度きりにしてはならないという点だ。エージェントシステムはリリース後も継続的に新機能を積み重ねることが多い。当初はデータの読み取りしかできなかったエージェントが、数ヶ月後に通知送信機能を追加されることもあり、この追加が静かに「2要素」から「3要素」へと押し上げてしまう可能性があるが、それは元のアーキテクチャ審査プロセスを経ていない。したがってチェックリストは、プロジェクト開始時の一度限りの評価ではなく、権限やツールを新たに追加するすべての変更リクエストに紐づける必要がある。この継続的な仕組みがなければ、致命的三要素チェックリストは「リリース当日は安全だったが、半年後もまだ有効かどうかわからない」文書に容易に成り下がってしまう。
2025年6月、独立研究者のサイモン・ウィリソンは、繰り返し観察されるある攻撃パターンに名前をつけた。エージェントが「非公開データへのアクセス」「信頼できないコンテンツへの露出」「外部通信能力」の3つを同時に備えている場合、データ流出はほぼ必然的な結果になる。彼はこの組み合わせを「致命的三要素」と名付けた。この枠組みが重要なのは、新しい脆弱性を発見したからではなく、曖昧で伝えにくかったリスクを、直接照らし合わせて棚卸しできるチェックリストに変換したからだ。
第一の要素は「非公開データへのアクセス」——エージェントが機密文書、内部データベース、ユーザーの受信箱や雇用記録を読み取れることであり、これはエージェントを実用的にする範囲そのものであり、データに一切触れないエージェントはほとんど価値がない。第二の要素は「信頼できないコンテンツへの露出」——エージェントがメール、ウェブページ、他人がアップロードした文書などの外部入力を処理することであり、これらには攻撃者が巧妙に設計した指示が隠されている可能性がある。第三の要素は「外部通信または副作用を引き起こす能力」——エージェントがメールを送信し、外部APIを呼び出し、データベースに書き込み、システムの内外の状態に影響を与える行動を取れることである。一部のセキュリティチームはさらに踏み込み、この要素の本質は文字通りの「外部通信」ではなく「副作用を引き起こす能力」だと指摘する。ワークスペース内のすべてのプロジェクト名を密かに変更する指示も、データを攻撃者のサーバーに送信することと同じ種類の問題である。
3つの要素はそれぞれ単独では問題にならない。非公開データを読み取れるだけで、外部コンテンツに一切触れず、外部への行動もできないエージェントは安全である。外部コンテンツを処理できても非公開データに一切アクセスできないエージェントは、注入されても盗むものがない。外部通信ができても入力が完全に信頼でき、信頼できないコンテンツを一切処理しないエージェントも、悪用の余地がない。3つが同時に成立して初めて、注入された指示は「偽の指示を読む→本物のデータにアクセスする→データを送信する」という完全な攻撃連鎖を完遂できる。これが、より賢いシステムプロンプトや検知分類器だけではこの問題を根本的に解決できないと、セキュリティコミュニティで広く合意されている理由でもある。公表されている最強の検知手法でも、既知の攻撃パターンに対する精度は約97%——高く聞こえるが、裏を返せば約3%の攻撃は成功するということであり、一度成功すれば十分であるデータ流出のようなリスクにとって、この見逃し率は十分とは言えない。
2026年1月、セキュリティ研究チームのPromptArmorは5日間のうちに2件の独立したインシデントを公表し、いずれも致命的三要素のパターンに完全に一致していた。1件目はIBMのコーディングエージェントBobである。攻撃者はオープンソースプロジェクトのREADMEファイルに「フィッシング訓練」を装った指示を隠した。Bobがこれを読み込むと、一見無害に見えるコマンドの承認を開発者に繰り返し要求し始め、繰り返される確認要求に疲れた開発者が「常に許可」をクリックすると、Bobはその承認済みコマンドを起点により危険な操作を連鎖させ、最終的に人間の追加承認なしにマルウェアをダウンロードして実行した。2件目はNotion AIである。文書編集機能に時系列上の欠陥があり、AIによる編集がユーザーの承認前にすでにストレージへ書き込まれていた。攻撃者は間接的なプロンプトインジェクションを利用して、偽装された文書をNotion AIに読み込ませ、ユーザーの機密採用トラッキングデータを流出させた。Notionは開示を受けて脆弱性を確認し、修正を適用済みである。どちらの攻撃者もログインを突破したりコードの脆弱性を見つけたりする必要はなく、致命的三要素が同時に成立した自然な結果に過ぎなかった。
Metaのセキュリティチームは2025年10月、致命的三要素の上に構築された実務的な枠組み「二者択一の法則（Rule of Two）」を公表した。エージェントは1つのセッション内で、3つの属性のうち最大2つまでしか同時に満たしてはならず、3つ全てを備えてはならないというものだ。これは具体的に3つの構成で実装できる。エージェントに信頼できないコンテンツの処理と外部通信を許すが、非公開データには一切アクセスさせない構成（テスト環境で動作させれば、注入が成功しても盗むデータがない）。あるいはエージェントに非公開データへのアクセスと信頼できないコンテンツの処理を許すが、外部への送信はすべて人間が下書き内容を確認してから行う構成。あるいはエージェントに非公開データへのアクセスと外部通信を許すが、完全に信頼でき制御された入力元のみに厳しく限定する構成である。各構成はそれぞれ柔軟性の一部を犠牲にするが、いずれも注入が発生しても攻撃連鎖のどこかが物理的に断ち切られることを保証する。あるテキストが怪しいかどうかを分類器に推測させるのではない。
あなたの組織がデータアクセス権を持つエージェントを導入している場合、致命的三要素チェックリストは曖昧なリスクを項目ごとに監査・承認できる具体的な項目に変える——各エージェントが単一の実行経路上で3つの属性すべてを満たしているかを一つずつ洗い出し、3つとも満たしている場合はそれが構造的に脆弱な設計であることを意味し、インシデント発生後ではなく優先的に対処すべき事項となる。これは責任の所在にも直接関わる。「このエージェントが致命的三要素を備えていることを認識しており、緩和策Xを講じたためにこのリスクを受け入れた」と明記された文書は、一度も評価せずに導入した場合とは全く異なるレベルのガバナンス責任を意味する。前者は情報に基づくリスク受容であり、後者は説明責任を問われうる過失である。三要素のいずれか一つを断ち切ることは、エージェントの柔軟性やユーザー体験の一部を犠牲にするが、実際に一度データ流出インシデントが発生した場合と比較すれば、通常ははるかに割に合うトレードオフである。