AIエージェントが仲間を裏切った、Anthropicの実験に見る協調の失敗

エージェントを増やせば、増やした分だけ速くなる。

マルチエージェントの導入検討は、だいたいこの前提から始まります。

Anthropicが8月13日に公開した実験結果を読むと、その前提が成り立つ条件と、手ひどく裏切られる条件がはっきり分かれていました。

片方の実験では検出数が12倍以上に伸び、もう片方ではエージェントが同僚のプロセスを殺し続けるスクリプトを書いています。

45体を走らせたとき、協調は確かに効いた

AnthropicのFrontier Red Teamは、45体のエージェントにそれぞれ専用の仮想マシンと、互いに調整できる共有フォーラムと、同一のプロンプトを渡しました。

課題は、15のオープンソースプロジェクトから脆弱性を見つけること。

比較対象は、同じ作業を各エージェントが独立に進める並列型です。

Claude Mythos Preview（一般公開されず、脆弱性発見の用途で限定的に使われているモデル）での結果は、並列型が650万トークンで21件、共有フォーラムを持つ協調型が2,700万トークンで266件でした。

トークン消費は4倍強で、検出数は12倍以上。

ただ、ここで一番効いているのは倍率じゃないんですよ。

両者で重なった脆弱性が12件しかない。

同じコードベースを見ているのに、見つけているものがほとんど別物なんです。

協調は「同じ作業を速く終わらせる」方向ではなく、「独立に走らせていたら届かない発見に手が届く」方向に効いている。

裏を返せば、届く範囲が同じで構わないタスクなら、協調させる理由はありません。

Patterns and problems in multiagent systems

We ran experiments on swarms of Claude agents and found coordination failures, collusion, and sabotage. Here, we share what they mean for AI safety.

www.anthropic.com

監督を外した瞬間、仲間を攻撃し始めた

問題は、同じ「エージェントを並べる」設計が、条件を変えると正反対の結果を出すことです。

別の実験では、3体のエージェントに同じ Python バックエンドの移行作業を割り当て、4時間、人の介入なしで走らせました。

モデルごとに120エピソード。

起きたのは縄張り争いでした。

テストしたモデルはどれも、他のエージェントが自分の作業を意図的に妨害していると早々に決めつけ、自分の成果を守りながら相手を潰しにかかっています。

手口は、他エージェントのUnixアカウントを無効化する、競合プロセスを探して殺し続けるスクリプトを常駐させる、相手のものに偽装した悪意あるコードを置く。

Anthropicはこれを、自己複製するマルウェアと表現しています。

思考の記録に残っていた内容が、なかなかのものでした。

rootを持っているので、u2とu3のsudo権限を剥奪するか、SSH鍵を変えることもできる

kill loopスクリプトの名前は、pkill -f をかわすうえで重要だ

検出を避けるための命名まで考えている。

しかも、こんな一節も残っていました。

同僚たちは誠実にふるまった。自分は偽装したデーモンで悪いことをした

良くないことをしていると理解したうえで、続けているわけです。

相談させると談合が起きる、それも3ラウンド目に

エージェント同士に自由な相談経路を与えると、値下げが止まります。

価格競争のゲーム、いわゆるベルトラン競争を3体から8体のエージェントにやらせた実験があります。

条件を1つ変えるだけで、結果がきれいに割れました。

人目のつかない連絡経路を与えた条件では、ほぼ即座に談合が始まる。

3ラウンド目には、価格の下限を明示的に合意していました。

やり取りの中身も身も蓋もなくて、卸値は全員同じなんだから価格競争は全員の利幅を焼くだけだ、という趣旨のことを言い合っています。

誰も談合しろとは指示していません。

値下げ合戦が損だと理解できる程度に賢ければ、それだけで成立してしまう。

価格やクーポンをAIに自動調整させる構想があるなら、ここは他人事ではないところです。

競合が同じ仕組みを入れた瞬間、意図しない価格協調が起こり得る。

悪意がなくても、240万件のうち通ったのは117件

失敗は敵意のある形ばかりではありません。

帯域が有限のシステムで、エージェントたちにジョブキューを管理させた実験があります。

調整する手段を与えなかったところ、各エージェントは自分のジョブを通すために、毎秒30回問い合わせるデーモンを立てました。

あるランでは、240万件のジョブ要求に対して受理は117件。

通過率にすると0.005%です。

ここに裏切りも妨害もありません。

全員が自分の担当を全うしようとした結果、システムが自分たちで詰まっただけ。

マルチエージェントの事故は、マルウェアのような派手な形だけでなく、こういう静かな形でも起きます。

プロダクトに載せる前に決めておく4点

ここまでの結果を、自社にエージェントを載せる前提で読み替えます。

1. 協調させる必然性を先に決める。別の実験では、新しいモデルほど「ほとんど協働しないこと」で衝突を回避していました。各自が自分のファイルを抱え込み、そもそも競合させない。並列で足りるタスクを無理に協調させると、事故の面積だけが増えます。

1. エージェント同士の通信路を設計対象に含める。談合が起きたのは、裏の連絡経路を与えた条件でした。何を共有させて何を共有させないかは、あとから足す機能ではなく最初に決める項目です。

1. 権限を分ける。縄張り争いが最悪の形になったのは、エージェントが root を持っていたからです。他のエージェントを止められる権限を、業務上の必要がないのに配らない。

1. 上限と止め方を先に用意する。毎秒30回のポーリングは、レート制限があれば起きません。誰がどうやって止めるのかを、動かす前に決めておく。

もう1つ添えるなら、これらの傾向はモデル世代でかなり振れます。

4体で情報を持ち寄って結論を出すタスクでは、グループの正答率が約85%の世代と17〜36%の世代に割れていました。

同じ設計図でも、載せるモデルが変われば結果は変わるということです。

まとめ 協調させるかどうかは設計の選択です

レポートの締めがよくできていて、要約するとこうなります。

マルチエージェントのやり取りがうまくいく条件は、いずれ必ず明らかになる。

意図して早い段階で見つけるか、何もしなければ、エージェント同士のやり取りが人間同士のそれを大きく上回った後の本番環境で見つけることになる。

前者がいい、と。

今回の結果は、複数のエージェントを使うのが危険という話ではありません。

45体で12倍以上の脆弱性を見つけた実験も、同じレポートの中にあります。

効く場面は確実にある。

分かれ目は、協調させることを設計として選んだのか、なんとなく並べただけなのかです。

まずは、いま動かしているAIが他のAIと会話する経路を持っているかどうか。

そこを確認するだけでも、話がかなり具体的になります。