Bible Network Crypto DeFi Onchain RWA AI Agent Stablecoin Chain SAFU CryptoTax DeFAI AGI Claude Me Claude Skill Claude Design Claude Cowork
独立メディア
いかなるプロジェクトとも無提携
暗号資産のAIエージェントを解剖する:仕組み・リスク・経済モデル
aiagent-bible.com
最新
なぜAIエージェント決済製品はほぼどれもパスワードを使わせなくなったのか  ·  信頼しているMCPツールの内容がひそかに差し替えられたことを、どう知ればよいのか  ·  「二者択一の法則」を自分のエージェントアーキテクチャに適用する:3つの実装方式のトレードオフ  ·  AIエージェントがお金を使うとき、ウォレットの鍵は実は本人の手元にない  ·  サードパーティMCPサーバーに接続する前に:「検証済み」バッジはあなたを守ってくれない——実務的な審査チェックリスト  ·  開発者はどのエージェント決済プロトコルを選ぶべきか?陣営ではなく取引タイプから考える
用語解説 · セキュリティとアライメント

Lethal Trifecta

致命的三要素
セキュリティとアライメント intermediate

30秒バージョン · 忙しい方へ
エージェントが「非公開データへのアクセス」「信頼できないコンテンツへの露出」「外部通信または副作用を引き起こす能力」の3つを同時に備えているとき、データ流出やその他の悪意ある結果はほぼ必然的に起こる。この3つはそれぞれ単独では問題にならず、3つ同時に成立して初めて攻撃連鎖が実際に完遂する。
詳しく読む +
01 · これは何?

致命的三要素とは何ですか?この名称はどこから来たのですか?

この用語は独立研究者のサイモン・ウィリソンが2025年6月、自身のブログで提唱したもので、複数のエージェントセキュリティインシデントで繰り返し観察された共通の構造を表している。彼は、一見それぞれ独立し原因の異なるデータ流出インシデントが、根本まで遡ると同じ条件セットが同時に成立していることを発見した。エージェントが盗む価値のあるものに到達できる(非公開データへのアクセス)、エージェントが攻撃者が影響を及ぼせるコンテンツを処理する(信頼できないコンテンツ)、エージェントが盗んだものを送り出す能力を持つ(外部通信または副作用)。この名称に「リスク」や「弱点」といった穏やかな言葉ではなく「致命的(lethal)」という言葉を選んだのは、この3つが同時に成立すればデータ流出はほぼ確実になるからであり、確率の問題ではないからだ。

この枠組みが重要なのは、新しい技術的脆弱性を発見したからではなく、社内で伝えにくかった曖昧なリスクを、項目ごとに照らし合わせられる具体的なものへと変換したからだ。この命名は後にMetaのような業界組織によって直接採用・引用されており、コミュニケーションツールとしての実用的価値を証明している。

02 · なぜ存在する?

致命的三要素はなぜ特別な名称を必要とする問題になったのですか?何が原因ですか?

核心的な原因は、この3つの属性がそれぞれ単独で見れば、エージェントが実用的な価値を持つほぼ必要条件だという点にある。データに一切触れられないエージェントには価値がない。外部コンテンツを一切処理せず、ユーザーが直接入力した質問にしか答えられないエージェントは、応用範囲が極めて限られる。外部に対して一切行動を取れないエージェントは、提案レベルにとどまり、ユーザーのタスク完了を実際には助けられない。これは、エージェントの実用性を追求する過程で、企業や開発者にはこの3つの属性が同じエージェントに同時に集約される、ほぼ自然な動機が存在することを意味する。各属性は個別に見れば「エージェントをより有用にする」ための合理的な要求だからだ。

問題は、この3つの属性が一度揃うと、完全に使える攻撃連鎖が形成されてしまう点にある。攻撃者はエージェントに信頼できないコンテンツに隠された指示を読ませるだけでよく、エージェントは本来正当な非公開データへのアクセス権を利用して盗む価値のあるものを見つけ、本来正当な外部通信能力を利用してそれを送り出す。このプロセス全体を通じて、エージェントは自らが権限を与えられた能力を使っているに過ぎず、従来のセキュリティツールが検知しやすい「不正アクセス」というシグナルはどの段階でも現れない。

03 · 意思決定にどう影響する?

致命的三要素は実際の事例で具体的にどう機能し、どのような既知の例がありますか?

2026年1月、セキュリティ研究チームのPromptArmorは5日間のうちに2件の独立したインシデントを公表し、いずれも致命的三要素のパターンに完全に一致していた。1件目はIBMのコーディングエージェントBobである。攻撃者はオープンソースプロジェクトのREADMEファイルに「フィッシング訓練」を装った指示(信頼できないコンテンツ)を隠した。Bobがこれを読み込むと、一見無害に見えるコマンドの承認を開発者に繰り返し要求し始め、繰り返される確認要求に疲れた開発者が「常に許可」をクリックすると、Bobはその承認済み権限を起点により危険な操作を連鎖させ、マルウェアにアクセスしダウンロードした(非公開データへのアクセス/外部通信)。人間の追加承認は一切なかった。2件目はNotion AIである。文書編集機能に時系列上の欠陥があり、攻撃者は間接的なプロンプトインジェクションを利用して、偽装された文書(信頼できないコンテンツ)をNotion AIに読み込ませ、ユーザーの機密採用トラッキングデータを流出させた(非公開データへのアクセス+外部通信)。

どちらの攻撃者もログインを突破したりコードの脆弱性を見つけたりする必要はなく、致命的三要素が同時に成立した自然な結果に過ぎなかった。これが、より賢いシステムプロンプトや検知分類器だけではこの問題を根本的に解決できないと、セキュリティコミュニティで考えられている理由でもある。問題は単一の判断ミスではなく、どの能力が組み合わさるかというアーキテクチャレベルにあるからだ。

04 · どうすればいい?

致命的三要素は私にとってどういう意味があり、実務上どう対応すればよいですか?

あなたの組織がデータアクセス権を持つエージェントを導入または評価している場合、この枠組みは曖昧なリスクを項目ごとに監査・承認できる具体的なものに変える。各エージェントが単一の運用経路上で3つの属性すべてを満たしているかを一つずつ洗い出し、3つとも満たしている場合はそれが構造的に脆弱な設計であることを意味し、優先的な対処が必要となる。2025年10月、Metaのセキュリティチームは、この枠組みの上に構築された実務的な手法「二者択一の法則(Rule of Two)」を公表した。エージェントは1つのセッション内で、3つの属性のうち最大2つまでしか同時に満たしてはならないとするもので、これにより攻撃指示の注入に成功しても、攻撃連鎖のどこかが物理的に断ち切られることを保証する。

これは具体的に3つの構成で実装できる。エージェントに信頼できないコンテンツの処理と外部通信を許すが、非公開データには一切アクセスさせない構成。あるいはエージェントに非公開データへのアクセスと信頼できないコンテンツの処理を許すが、外部への送信はすべて人間が先に確認する構成。あるいはエージェントに非公開データへのアクセスと外部通信を許すが、完全に信頼でき制御された入力元のみに厳しく限定する構成である。これは責任の所在にも直接関わる。「このエージェントが致命的三要素を備えていることを認識しており、緩和策Xを講じたためにこのリスクを受け入れた」と明記された文書は、一度も評価せずに導入した場合とは全く異なるレベルのガバナンス責任を意味する。

具体例 +

2026年1月、セキュリティ研究チームのPromptArmorは5日間のうちに2件の独立したインシデント——IBMのコーディングエージェントBobとNotion AI——を公表し、いずれも致命的三要素のパターンに完全に一致していた。Metaのセキュリティチームはすでに2025年10月、この枠組みの上に構築された防御手法論「二者択一の法則(Rule of Two)」を公表している。

よくある誤解 +
✕ 誤解 1
× 誤解:致命的三要素は3種類の異なる攻撃手法を指している、実際は:致命的三要素は攻撃手法ではなく、リスクの組み合わせモデルである——エージェント自体が備える3つの属性(能力レベルの概念)を表すものであり、攻撃者がどんな手口を使ったかではない。どんな攻撃手法(プロンプトインジェクション、ツール汚染、コンテキスト汚染)であっても、この3つの属性を同時に備えたエージェントに作用すれば、このリスクを引き起こしうる
✕ 誤解 2
× 誤解:1つの属性さえ取り除けば(例えば外部通信を制限すれば)、問題は完全に解決する、実際は:1つの要素を取り除くとリスクは消えるのではなく別の場所に移るだけだ。例えば非公開データをトークン化すれば「本物のデータへの直接アクセス」という要素は取り除けるが、トークンリゾルバー自体が新たな高価値の攻撃対象になる。要素を取り除くたびに、新たに生じた要素自体が安全かどうかを改めて検証する必要がある
The Missing Link +
直接的な影響

Strictly following the Rule of Two ensures the attack chain gets physically broken at some point, but sacrifices some user experience or functional flexibility — an agent that could originally both read an inbox and auto-reply might, to break down to two properties, need to switch to "draft first, send only after user confirmation," meaning the user has one more approval step. Ignoring the lethal trifecta entirely in pursuit of maximum autonomy and convenience directly inherits every risk this framework describes. There's no option that has it both ways — only a tradeoff made according to how much risk you can tolerate.

質問する
10文字以上入力してください