Datawhale 実用情報
Google 最新：Teamwork
マルチエージェントとは、単にタスクを複数のエージェントに割り振ることではありません。それらのエージェントにどう協力させ、誤りを互いに強化し合わないようにするか。こちらの方がはるかに難しい問題です。Googleが最近オープンソース化したTeamworkフレームワークは、その答えを提示しています。数学、ハードウェアシミュレーション、オープンソース最適化といった最先端の領域でも実証された成果があり、設計思想を読むと、エージェントに取り組む人にとって示唆に富んでいると感じました。
本稿では主にその設計原理を分解し、マルチエージェントの協力問題をどう解決しているのかを見ていきます。
原文リンク：https://antigravity.google/blog/teamwork-when-ai-becomes-a-research-partner
1. マルチエージェントの難しさは分業ではなく、組織化にある
通常のタスクなら、基本的なマルチエージェント手法で十分なことが多いでしょう。しかし困難な研究・工学の問題になると、話は変わります。組織化が緩いエージェント群はすぐに軌道を外れます。あるエージェントが早い段階で誤りを犯すと、他のエージェントがそれに同意し、欠陥のあるアイデアの上にさらに構築を続けてしまうからです。
核心となるのは「何体のエージェントを使うか」ではなく、「どう組織化するか」です。Anthropicは以前、調整されたスウォームと独立した並行エージェントを、ソフトウェアの脆弱性探索で比較する実験を行いました。結果、調整されたスウォームの方がより多くの脆弱性を発見でき、その差は複雑なタスクほど顕著でした。
つまり、組織化が緩いエージェントが軌道を外れるのは、マルチエージェントシステム共通の病です。Teamworkが解決する問題は次の通りです。複数のエージェントに、数時間から数日かけて互いの作業に挑戦させ、さらに構築を進める前に欠陥を見つけさせ、最も強い部分を組み合わせて利用可能な解決策を作り上げる。Teamworkはこれを実現します。
2. Teamworkは、エージェント同士がどう誤りを訂正し合うのか
Teamworkは、多くの研究・工学問題に共通する構造を、具体的かつ設定可能な形にしています。候補ソリューションの生成、ストレステスト、最も良いアイデアをより強い解決策に統合する。このサイクルを軸に、Teamworkは3つの重要な設計を行っています。
候補の生成からテスト・統合を経て、次のラウンドへ
このサイクルはTeamworkの基盤です。単純なタスク分配ではありません。候補ソリューションはテストを経て、良いアイデアが抽出され、より強い次ラウンドの候補が形成されます。人間は目標設定と最終的な受け入れ判断を担当し、エージェントがイテレーションのプロセス全体を実行します。
協力パターンとエージェント自体を分離する
パターンは仕様であり、実行可能なプログラムではありません。オーケストレーションコードは含まれません。フレームワークがパターンを読み取ると、適切なエージェントを自動的に起動します。そのため、敵対的批判ループのような専門的な仕組みを、コードを変更せずに分野を越えて移植できます。
この設計の価値は、協力ロジックと各エージェントが実際に行う仕事を分離したことで、いったん書いたオーケストレーション戦略を、まったく異なる領域に再利用できる点にあります。
チーム規模は事前に決めず、進めながら調整する
フレームワークは、タスクの要求に応じてエージェントを何体生成するかを動的に決定し、数を事前に設定しません。エージェントの数とチーム構造は、実行中に問題の様相が明らかになるにつれて変化します。各タスクの実行は生きたプロセスであり、固定されたパイプラインではありません。
これはよくある問題を解決します。多くのフレームワークは、事前に使用するエージェントの数を決めておくことを要求しますが、複雑な問題の構造は、たいてい取り組み始めてから明確になるからです。
3. 5種類の問題には、5種類の異なる協力方法が必要
問題が異なれば、必要な協力方法も異なります。問題の構造が、エージェントをどう組織化するかを決めます。Teamworkは、問題のカテゴリーごとに専用パターンを提供しています。
3.1 分割できないタスクは、テストの中で反復的に改善する
独立したサブタスクに分割できない問題もあります。そのような問題は、試行錯誤と洗練を繰り返す必要があります。このパターンは、エージェントとテストと改善の密接なループを通じて少しずつ改良し、各テスト結果を次の修正に直接フィードバックします。
3.2 分割できるタスクは、複数のエージェントに並行して進めさせる
複数の独立した部分に分割できる工学的タスクでは、このパターンは作業を複数の並行ワーカーに扇出し（ファンアウト）し、同時にレビュアーを配置して各ワーカーの成果物を検査させます。
オーケストレーターは問題に応じて、何体のエージェントを配置し、何ラウンド実行するかを決定します。中心となる役割は固定ですが、実行規模は動的に調整されます。
3.3 数学の未解決問題は、複数のルートを先に挑戦させる
数学や理論計算機科学の未解決問題には、次のような特徴があります。有望に見える方法の多くが最終的には失敗し、その欠陥は深く試みて初めて見えることが多いのです。このパターンは、各候補を前進させる前に、必ずストレステストに通すようにします。
3.4 一歩ごとに、その一歩が成立するかを先に検証する
深さ優先の数学的推論では、一歩ごとに厳密な自己検証が必要です。このパターンは、完全な答えを出してから検証するのではなく、検証を推論のプロセスに組み込みます。
3.5 論文レビューでは、固定した評価軸で批判意見を整理する
論文や技術文書のレビューには構造化された分析が必要です。このパターンは、固定したレビュー評価軸でエージェントの批判意見を整理します。
4. 失敗した証明ルートにも、有用なものは残る
長い証明のパターンは、単独で取り上げる価値があります。最も難しい未解決問題を扱うからです。その設計は「生成してから検証する」という単純なものではなく、「生成・対抗・統合・学習」という完全なサイクルです。
4.1 各候補に専任の反証者（フォージャー）を割り当てる
複数の候補戦略を並行生成し、各戦略に1体のフォージャー（反証者）を割り当てます。フォージャーの唯一の仕事は、その戦略を打ち壊すことです。合成ツリーは、候補戦略とそれらの報告を組み合わせます。
反駁されたルートは、反対意見を添えたままプロセスに残ります。打ち壊されたルートにも、まだ有用なアイデアが含まれているかもしれません。これがこの設計の重要な洞察です。
4.2 長い証明を、依存関係のあるサブ問題に分解する
選ばれた戦略は証明計画へと展開され、サブ問題には明確な目標と明示的な依存関係が設定されます。依存グラフによって、独立したサブ問題は並行実行され、依存関係のあるサブ問題はトポロジカルな順序で実行されます。
こうすることで、長い証明を管理しやすい部分に分割しながら、ロジック全体の一貫性を保てます。
4.3 異なる案をトーナメント形式で層ごとに合成する
合成ツリーでは、各ノードが候補サンプルとその批判を読み取り、改善されたソリューションを生成します。合成されたソリューションが失敗した場合、ネットワークは蓄積された反対意見を使って再実行します。
このメカニズムにより、失敗は単なる破棄ではなく、有用な情報になります。
4.4 今回のラウンドで踏んだ落とし穴は、次のラウンドで繰り返さない
失敗した草稿は、次回の試行のために保持されます。検証者が見つけた問題は、答えに依存しない「落とし穴レジストリ」に抽象化され、よくある誤りのパターンが記録されます。共有ナレッジディレクトリには、証明済みの結果、失敗した方法、関連する参考文献が保存されます。
このような経験の蓄積により、後続の試行が同じ失敗を繰り返さないようになります。
5. エージェント開発者への示唆
Teamworkの設計原則には、参考になる点がいくつかあります。
5.1 マルチエージェントの核心はオーケストレーションロジック
単にタスクを分けるだけでなく、ストレステストの仕組み、結果の統合戦略、ラウンドをまたぐ学習の仕組みを設計する必要があります。組織化が緩いエージェント同士は、互いの誤りを強化し合います。この点は公式ドキュメントでも繰り返し強調されています。
5.2 1つの協力パターンを、異なる領域へ移行できる
オーケストレーションロジックとエージェントの記述を分離すれば、書いた協力戦略を異なる領域に移植できます。この設計思想はTeamworkだけでなく、自分でマルチエージェントシステムを作る際にも検討する価値があります。
5.3 エージェントの数を前もって固定しない
固定されたチーム構造をあらかじめ決めず、問題の現れ方に応じてエージェント数と組織化の方法を動的に調整しましょう。複雑な問題の構造は、取りかかる前に完全に予測できることはほとんどありません。
5.4 必ず誰かが反対意見を出す専任担当になる
Anthropicの研究は、もう一つ注意すべき問題も示しています。複数のエージェントが同じ状況に直面すると、人間よりも高い類似性を示すことがあります。あるエージェントの誤った判断が、他のエージェントにも複製され、体系的な失敗を引き起こします。
Teamworkの設計（フォージャー機構や批判ループなど）は、まさにこの同調効果に対抗するためのものです。各候補は前進する前に、独立したストレステストを通過しなければなりません。
5.5 小さなモデルでも、優れたオーケストレーションがあれば高難度の問題を解ける
日常的に開発で使うFlash級モデルでも、入念に設計されたオーケストレーションロジックと組み合わせれば、複雑な問題に対して強力な性能を発揮できます。TCSBenchで71%というスコアのうち、3件はFlash級モデルが初めて博士レベルの数学研究を生み出した結果です。
必ずしも最大のモデルを使う必要はありません。重要なのはオーケストレーションロジックの質です。
おわりに
Teamworkの設計原理を読んで感じたのは、マルチエージェントの未来はより大きなモデルを積み重ねることではなく、いかに優れた協力メカニズムを設計するかにある、ということです。生成・テスト・統合・学習のサイクルを細部まで作り込むことで、小さなモデルでも最先端の問題で力を発揮できます。
エージェントシステムに取り組んでいる人にとって、特に参考になる設計判断は次の3つです。オーケストレーションロジックとエージェント記述の分離、実行時適応、失敗を有益な情報として扱うこと。これらの考え方はマルチエージェントだけでなく、単一エージェントのシステムにも応用できます。
Anthropicのマルチエージェント研究は、マルチエージェントの協力には同調効果のような、まだ見えにくい問題があることを教えてくれます。オーケストレーションの仕組みを設計する際は、エージェント同士が誤りを増幅し合わないようにすることを特に考慮する必要があります。
仕組みをより深く学びたいなら、長い証明パターンのトーナメントネットワーク設計に注目するのがおすすめです。このパターンは最も難しい未解決問題を扱っており、戦略探索・分解・ラウンド間学習の仕組みを理解するうえで、複数のエージェントを真に協力させる方法の大きな手がかりになります。