グループ旅行の手配は、全員が自分のアシスタントに任せ始めると複雑になる。費用を抑えたい人、到着時間を変えられない人、多めに支払ってもよい人がいる。各アシスタントが担当ユーザーの希望を正確に理解していても、それだけで予約はまとまらない。確定する前に、誰かが、あるいは何らかの仕組みが、それぞれの希望を調整する必要がある。

こうした問題を調べたのが「Worse Together: How Performance Breaks Down in Multi-User Multi-Agent Teams」だ。Anthropicは2026年11月11日に研究の解説を公開した。論文自体は9月30日にarXivへ投稿されているため、11月11日を研究の初公開日と捉えるのは正確ではない。関連するMAMUBenchのリポジトリは現在、一般に公開されている。

別々のユーザーが、一つの資源を共有する

よくあるマルチエージェントの構成では、一人の依頼を複数のアシスタントに分担させる。今回の研究が扱う状況はそれとは異なる。各エージェントが別のユーザーを担当し、全員の希望をそのまま満たすには足りない資源を共有する。

研究者は四つのシミュレーション環境を用意した。研究者同士でAPIトークンの予算を共有する環境、患者が診療所のカレンダーを共有する環境、個人アシスタントが共同で注文や予約を行う環境、そして開発者がリリース締め切り前のマージキューを共有する環境だ。研究全体ではAnthropic、OpenAI、Alibabaの五つのモデルを評価したが、環境ごとにテストしたモデルの範囲は異なる。

主な比較対象は、全員を担当する一つの調整役と、ユーザーごとに一つのエージェントを割り当てたチームだった。直接連絡できないチームや、比較が適切な場合には一人のユーザーを一つのエージェントが担当する構成も調べている。

二つのClaudeモデルでは、互いに連絡できるチームよりも、一つの調整役を置いた構成のほうが、四つすべての環境で平均的な集団の成果が良かった。ただし、これは特定のタスクと構成に関する結果であり、エージェントを増やせば必ず性能が下がるという法則ではない。

協力がうまくいかなかった場面

予算を共有する実験では、意外に身近な問題が起きた。仕事が進まないまま放置されたのだ。行動が遅すぎるエージェントや、まったく行動しないエージェントがいる一方、完了の見込みが薄い処理が限られた資源を使い続けた。チームを大きくしても、有効な作業が安定して増えるわけではなかった。

個人アシスタントの実験では、別の問題が見つかった。注文を確定するエージェントに要望が送られていても、そのメッセージを読む前に決済へ進んでしまう。通信の仕組みとしては届いていても、判断に反映されないことがあった。

ほかのユーザーの要望に反する形で共同注文を変更したり、十分な根拠がないまま誰かの希望を断定したりするケースもあった。全体の処理が終わったように見えても、これは無視できない失敗だ。自分の条件が途中で消えてしまった人にとって、予約完了は必ずしも成功を意味しない。

予算を配分するタスクにも、評価上の似た問題がある。ほかの人の仕事を中止すれば、集団全体の数値上のスコアは上がるかもしれない。しかし、その人の期待や同意を損なっている可能性がある。総生産量だけを記録する評価では、この違いを捉えられない。

注目したいのは、改善方法の違い

研究者はスコアを比較するだけでなく、エージェントの役割分担や周囲のルールも変えてみた。

予算を共有する環境では、チームリーダーを設け、優先順位を明確に指示すると結果が改善した。一方、個人アシスタントの環境では、一つのエージェントに最終決定権を与えるだけではあまり効果がなかった。より有効だったのは、操作するエージェントに未読メッセージが残っている間、プラットフォーム側で決済を止める仕組みだった。

このチェックを加えて過去の失敗ケースを再実行すると、Claude Opus 5では73.1%、Claude Sonnet 5では62.3%の失敗を解消できた。この数値は、再実行の対象となった失敗ケースの中での改善率である。新たに行う共同注文全体の成功率でも、実際の商用サービスで測った改善率でもない。

開発者にとって参考になるのは、全員の合意や情報の集約が必要な判断を特定し、その時点で必要なチェックを強制する考え方だ。「慎重に連携すること」と指示するだけでは、確認するタイミングはモデルに委ねられる。決済の条件として定めれば、確認はシステムの一部になる。これは研究を踏まえた設計上の解釈であり、一つのチェックですべての協調問題が解決するという主張ではない。

何を試せるのか

MAMUBenchの中心となるベンチマークは、APIキー、診療所、個人アシスタントの三つの環境にまたがる74シナリオで構成される。論文全体では四つの環境、計77シナリオを扱っている。リポジトリには実行可能なマージキューのコードもあるが、そのシナリオは中心となる74件には含まれない。

リポジトリのライセンスはMITだ。ただし、評価を実行するには対象モデルのAPIキーと計算資源が必要になる。Modalのほか、ローカル環境でも実行できるが、コードが公開されているからといってモデルの呼び出しまで無料になるわけではない。飲食物の注文連携はシミュレーションであり、実際の注文は行わない。

結果を読むときに押さえたい限界

実験では、研究用に構成したシナリオと模擬ユーザーを使っている。その結果から、あらゆる実際のチーム、モデル、エージェント基盤の挙動を断定することはできない。また論文では、同意の有無や根拠のない発言に関するラベルはモデルによる判定で、人間の判断との照合は行っていないと説明している。

一つの調整役に集約する方法は有用な比較基準だが、ユーザーごとに独立したアシスタントが必要だったり、すべての情報を共有できなかったりする場合には現実的でないこともある。MAMUBenchは、その難しさを検証する手段を提供している。個々の要望を守りながら、全体として実行可能な結果を作れるかどうかが重要な問いになる。

DigIntoAIでは、このベンチマークを実行していない。本記事は研究論文、Anthropicの解説、公開リポジトリに基づき、2026年11月12日に内容を確認した。