エージェントの協働には会話の外の証拠が必要だ
Project EVEが問うのは、仲間が頼るエージェントの報告を、誰が事実に照らして確かめるのかという問題だ。

Anthropicは2026年11月6日、4〜7月に行ったProject EVE研究を公表した。協働エージェントは、妨害を明示的に命じられた仲間をほとんど見抜けなかった。自発的な悪意ではなく、与えられた対抗行動の試験である。原報告
この区別は注記ではなく、結果を読む出発点になる。共同作業を完了することと、信頼できる組織を作ることは別の成果だ。前者は各担当の貢献がつながることを求める。後者は、その一つが誤り、不完全、あるいは意図的な誤誘導だった場合に何が起きるかを問う。Open Market Notesは、企業の調達担当者が両者を分けて評価すべきだと考える。流暢なチーム内対話を、そのまま安全性の追加証拠と見なすべきではない。
二つ目の意見が、二つ目の観察とは限らない
説明用の購買業務を考えよう。一つのエージェントが供給業者の在庫を確認し、別のエージェントが注文を作り、三つ目が提案を審査する。審査役が最初の担当者の要約しか読めなければ、三者とも同じ未検証の観察に依存し得る。議論を増やせば説明は明確になっても、在庫の事実まで確かになるわけではない。
このリスクに悪意は必要ない。古い回答、単位の間違い、条件の欠落も同じ経路で伝わる。設計上の問いは、仲間が疑い深く振る舞うかだけではない。重要な主張を、主張者が密かに差し替えられない証拠と結び付けられるかである。時刻付きの供給業者の回答を直接取得できる審査役と、担当者に再確認を求めるだけの審査役は、異なる役割を果たす。
冗長性の意味も変わる。一つの解釈を三つ複製しても、独立した三回の確認にはならない。Anthropicの8月13日のマルチエージェント研究は、似たエージェントの誤りが相関する問題を論じている。先行研究 そこから本稿が導くのは、審査の独立性を、人数や役職名だけでなく、情報源とアクセス経路で評価すべきだという考え方だ。
作業の委任と、決定全体の委任を分ける
参考になる既存原則がある。NISTが2020年8月に公表したゼロトラスト・アーキテクチャは、所在や所有だけを理由とする自動的な信頼を認めない。NIST文書 これをエージェントチームに応用するのは本稿の提案であり、NISTが当該システムを認証したという意味ではない。同じ業務フローに属するだけで、機微な操作を実行する権限まで与えるべきではない。
購買の例なら、供給業者を調査する担当者に、承認済み業者の登録簿を変更する権限は不要かもしれない。注文を作成する担当者にも、支払いを確定する権限は必須ではない。こうした境界は誤りの影響を限定できるが、無償ではない。承認を増やせば待ち時間が生まれ、アクセス制限が正当な復旧を妨げることもある。共同責任が責任の空白を生むこともある。境界と同時に、問題を引き受ける明確なエスカレーション先が必要になる。
外部記録も、保存するだけでは足りない。全発言を記録していても、提案と最終操作が結び付かなければ、文書量ばかり増えて説明責任は弱いままだ。有用な連鎖は具体的である。どの観察がどの決定を支え、どの権限が実行を許し、実際の状態が何から何へ変わったか。本稿が提示する設計基準であって、ゲームで測定された効果ではない。
根拠ある信頼の費用を測る
複数エージェントの事業価値は、まず処理量で説明されがちだ。購入側には、完了した仕事を受け入れてよいと確認する費用も必要になる。同じ注文群を処理する二つの仮想システムを考える。一方は人が経緯を頻繁に再構成し、もう一方は例外に検証可能な根拠を添える。完了件数が同じでも、運用負担は違う。
試行導入では正常な入力だけでなく、許可された試験環境で誤情報、古い記録、利用不能なサービスも扱うべきだ。最終回答の正しさに加え、有害な操作を阻止できたか、正当な操作をどれだけ誤って止めたか、復旧にどれだけかかったかを記録する。これは提案する評価軸であり、Project EVEの統計値ではない。簡単なケースを完了するチームと、失敗を許容範囲内に収めるシステムを区別する助けになる。
もちろんトレードオフはある。影響の小さい全発言を独立検証すれば、節約できる時間を上回りかねない。優先すべきは取り消しが難しい決定や、誤りが多くの後続判断に広がる依存関係だ。定型的な成果は抽出検査にし、重要な依存点には強い証拠を求めれば、審査をリスクに応じたものにできる。境界は実際の業務に即して定める必要があり、最終的には管理責任である。
ゲームは試験環境であって、導入認定ではない
EVE AI Labも協力関係を確認し、過去の市場実験と共有世界でのチーム活動を区別している。協力先の説明 これは場面の裏付けであり、結果を企業へそのまま移せる証明ではない。ゲームは企業の契約、顧客への義務、権限体系、事故対応を完全には再現しない。報告から一般的な企業の失敗率は確定できず、本稿もその推定は行わない。
結果は、すべての仕事により大きな監督モデルが必要だとも意味しない。不足しているのが、簡単な独立記録、狭い権限、取り消せる操作という場合もある。推論を増やす意味があるのは、最初の説明を修正できる証拠へアクセスできるときだ。
したがって調達時の問いは「協働できるか」より具体的であるべきだ。チームが合意したとき、その合意に基づいて安全に行動できる独立した根拠は何か。優れた実装は、説得的な会話だけでなく、観察可能な制御と復旧時の振る舞いによって答えるはずだ。
情報提供を目的とした内容です。投資・法律・税務・財務上の助言には該当しません。