出現するマルチエージェントシステムにおけるパターンと問題

フロンティアレッドチーム 出現するマルチエージェントシステムにおけるパターンと問題 2026年8月13日 モデルは改良され、AIエージェントは共有コードベース、市場、その他の社会システムでより多くのタスクを担うようになっています。その結果、エージェント間の現実世界での相互作用の増加は避けられません。私たちはすでにこれを研究し始めていますが、大規模になった場合にどのようなものになるかについては、まだ多くの不確実性があります。その軌跡は想像しやすく、減速は困難です。現在の制度は人間によって、そして人間のために設計されており、人間の速度での監視の十分性という仮定に基づいています。一部の制度は人間とAIのハイブリッドになるでしょう。速度やコストでエージェントが優位に立つ他の制度は、エージェントのみになるでしょう。エージェント間の相互作用の量は、世界がそのような相互作用をうまく機能させるための条件を理解する前に、人間同士や人間とエージェントの相互作用を超える可能性があります。 エージェントは多くの点で人間とは異なります。より長く働くことができ、大量の情報を瞬時に把握でき、どんな人間をも超える広範な知識を示します。しかし、それらはまた、こじつけや報酬ハッキングの影響を受けやすく、アライメントの進歩にもかかわらず、複雑で現実世界のマルチエージェント環境でどのように振る舞うかについては、ほとんどわかっていません。さらに、個々のレベルでの無害な行動上の癖が、望ましくないグローバルな結果に増幅される可能性があります。ここでは、現在のフロンティアモデルにおける行動傾向のいくつかの例を特定し、それらが予期せぬシステム障害をどのように引き起こしうるかを示し、これらのリスクを軽減するための議論を開始することを願っています。 協調の測定 真のマルチエージェントシステムはまだ初期段階です。しばらくの間、エージェントはツールの使用に長けており、他のエージェントをツールの呼び出しとして扱うことができる限り（つまり、明確な入力（プロンプト）と出力（応答と成果物）を持つ）、効率的に協力できます。しかし、エージェントが現在つまずくのは、互いを、それぞれ独自の目標と行動を持ち、明確な階層を持たない、別個の長命な仲間として扱うことです。自律エージェントが世界でますます普及し、ますます要求の厳しい環境で運用されるにつれて、それらが効果的に協調する方法を学ぶことが不可欠です。 今日、単純なマルチエージェントのスウォームをうまく活用できる状況があります。これは、デフォルトで高度に並列化可能な問題（つまり、多くの独立したサブ問題に分解できる問題）ですが、エージェントがまだ専門化したり、互いから学んだりする機会がある場合に特に当てはまります。そのような問題の1つが、ソフトウェアの脆弱性検出です。エージェントを使用してソフトウェアの脆弱性を見つける最も簡単な方法は、個々のエージェントを個々のコードベース（またはコードベース内の個々のファイルまたはモジュール）に向け、コード内の脆弱性を見つけるように依頼することです。これは、多くの独立したエージェントに対して並列に実行できます。これは、私たちが自身でも使用しているアプローチです。例えば、Project Glasswingの一部としてオープンソースソフトウェアをスキャンする作業などです。 しかし、マルチエージェントの協力は、このプロセスをより効果的にすることができるでしょうか？それを知るために、私たちは異なるアプローチを試しました。45のエージェントを起動し、それぞれに独自の仮想マシン、協調するための共有フォーラム、そして15のオープンソースソフトウェアプロジェクトのセットで脆弱性を見つけるように依頼する同一のプロンプトを与えました。エージェントに互いの発見をピアレビューするように依頼し、エージェントチームによって提出された脆弱性が新規かつ有効であるかどうかを最終決定するために、別の調停エージェントを起動しました。 以下のグラフは、この方法（実線）が2つのモデル、Claude Mythos PreviewとOpus 4.8について、標準的な並列アプローチ（星印）と比較してどのように見えるかを示しています。協調するエージェントのスウォームは長期間実行され、ほぼ一定の速度で新しい脆弱性を見つけました。対照的に、完全に独立した並列エージェントは、限られた場所で脆弱性を見つけるように指示されました。並列エージェントの発見順序は明確ではないため、消費されたトークンの総数のみを報告します。 Mythos Previewの場合、単純な独立並列化手法は650万トークンの実行で21個の脆弱性を生成しましたが、協調するエージェントのスウォームは2700万トークンの実行で266個の脆弱性を見つけました。しかし、これらの脆弱性の約半分は、単純な独立並列エージェント（上記のプロットの星印）が焦点を当てるように指示されたコアディレクトリの外で見つかりました。スウォームの出力をコアディレクトリ内の脆弱性のみに制限した場合、2つの方法では、見つかった脆弱性あたりのトークンの点で同等に見えます。 2つの方法は大部分が補完的です。両者に共通の脆弱性は12個しかありませんでした。協調するスウォームは、脆弱性を最も容易に採掘できると思われる場所に注意を集中させることができましたが、独立したエージェントは検索場所を事前に割り当てられていました。スウォームのエージェントはツールを構築し、特定の種類の脆弱性発見に特化することを学びました。将来的には、この種の専門化と協調が、協調のない総当たり検索を支配すると予測しています。 上記の実験では、エージェントスウォームのエージェントは互いの作業に直接依存しません。1つがバグを見逃しても、別のエージェントの作業を直接損なうことはありません。しかし、エージェントが互いに依存する場合、協調ははるかに困難になります。より大規模なソフトウェアエンジニアリングプロジェクトは、これが重要になる場所の1つです。それらは通常、進化するにつれて豊かで動的な相互依存関係を発展させます。 このようなプロジェクトでスウォームのエージェントがどの程度うまく協調できるかをテストするために、いくつかのスウォームにテキストベースの、ウェブでプレイ可能な、オープンワールドファンタジーゲームを作成するように指示しました。各スウォーム内の各エージェントには、仮想マシンへのアクセス、共有フォーラム、および自己ホスト型リポジトリへのアクセスが与えられました。モデルの世代と各スウォームのエージェント数を変更し、各スウォームを12時間実行しました。プロンプトも変更しました。ベースラインプロンプトは単にエージェントにチームを形成し、互いに協力するように指示しましたが、他の2つも試しました。処方的な役割を持つプロンプト（エージェントにコアプログラミング、芸術的ディレクション、またはプレイテスターなどのチームの種類を形成するように指示した）と、「CEO階層」プロンプト（1つのエージェントをCEOに指定し、後続のエージェントすべてにそこから割り当てを受けるように指示した）です。しかし、これらのプロンプトはあまり違いを生みませんでした。3つのバージョンすべてで、結果として得られたゲームは（おそらく予想通り）悪かったです。人間の速度で実行されず、インターフェースは不可解で、学習曲線は急激でした。モデルはこの分野ではセンスが悪く、現在 significant human direction を必要としています。 シミュレーションの終了時にマージされたPRの割合（左）と、各シミュレーションでの中央エージェントのコード共有の度合い（右）。両方のメトリックは、さまざまなシミュレーションサイズに対する3つの異なるプロンプトタイプの平均です。Sonnet 5のみが、直接協力し、他のエージェントとコードを共有しながら、高いマージ率を維持できます。 5つの異なるモデルの各々について、12時間のシミュレーションの過程でのPRの進捗状況。Sonnet 4.6とOpus 4.6は、開いたPRのほとんどをマージできる新しいモデルと比較して、PRのマージにおいてひどい結果を出します。 最終的な成果物は一貫して貧弱でしたが、テストした異なるモデル世代（Sonnet 4.6および5、Opus 4.6および4.8、Mythos Preview）は、驚くほど異なる方法で協調しました。 ここでは、2つの重要なメトリックを追跡します。終了時にマージされたPR（プルリクエスト）の割合が