01 重要ポイント
AIエージェントをApple、Microsoft、Googleなどの企業に似た構造に組織化した後、Alexが発見した重要なポイントは以下の通りです:
-
MicrosoftやAppleのように、複数の「競合する」チーム（最終製品を作るために競争するチーム）を持つ企業は、中央集権的な階層構造よりも優れた成績を示しました。
-
GoogleやAmazon、Oracleのような、単一障害点（1人のリーダーが重要な決定を下すなど）を持つシステムは、パフォーマンスが低くなりました。
-
大手テクノロジー企業の組織構造は、問題解決能力に中程度ではあるが顕著な影響を与えました。
02 AIエージェントとテクノロジー大手の組織
SWE-benchのように、単にAIエージェントの数を増やしてパフォーマンスを向上させる以前の方法では、顕著な結果は得られませんでした。
これは、数を増やすだけでは問題を解決できないことを示唆しています。
では、AIエージェントのソフトウェアエンジニアリング能力を向上させるには、他にどのような方法があるでしょうか？
3週間前、AlexはJames Huckleによる「コンウェイの法則」に関する記事を偶然目にしました - ソフトウェアや製品のアーキテクチャは、それを作り出した組織構造を反映するよう運命づけられているというものです。
Jamesは、Amazon、Google、Facebook、Microsoft、Apple、Oracleの誇張された組織構造を示すイラストを紹介し、次のようなアイデアを提案しました：
大手テクノロジー企業の人間と同様に、マルチエージェントのコミュニケーション構造が問題解決アプローチを形作る可能性がある。
これに触発されたAlexは、JamesのこのSWE-benchインスタンスに関する仮説をテストすることにしました。
03 実験セットアップ
著者はAIエージェントを異なる企業構造に組織化し、SWE-bench-liteの13インスタンスの「ミニ」サブセットで6つの異なる組織構造を評価しました。
これら6つの組織を構築するにあたり、著者はいくつかの核心的な観察に基づいてマルチエージェントの組織構造を設計しました：
Amazon
トップに「マネージャー」がいる二分木。
この構造を再現するために、Alexは多数のエージェントにコードリポジトリの検索を行わせ、1つのエージェントに最終的なコードリポジトリの更新を実行させました。
Amazonに似た木構造ですが、中間層の間のつながりがより多い。
Alexはこれを再現するために、1つの層内のすべてのエージェントの結果を集約し、次の層のエージェントに渡しました。
Meta (Facebook)
階層構造はありませんが、エージェント間に多くの接続があるメッシュ組織です。
Alexは元のエージェント設計を修正し、異なるエージェント間の遷移の可能性を高めました。
Microsoft
それぞれが独自の階層を持つ競合チームを重視しています。
基本的に、Alexは Amazon の構造を再調整し（エージェントの数を減らし）、3回の別々の実行（各実行で階層構造を少しずつ調整）から「最良の」解決策を選ぶためにベクトル類似度投票法を使用しました。
Apple
多くの小さな競合チームがあり、それぞれが最小限の構造を持っています。
Alexは Microsoft と同じ「最良の解決策」アプローチを使用しましたが、エージェントの階層なしでより多くの実行を行いました（各実行で異なる遷移を持つ）。
Oracle
2つの異なるチーム、より大きな「法務」二分木とより小さなエンジニアリングツリーがあります。
Alexは法務チームをコードリポジトリを検索し重要なコンテキストを取得するエージェントとして解釈し、エンジニアリングチームを実際にコードを書くエージェントで構成しました。
両チームの構造はAmazonに似ており、トップに1つのエージェントが「法務」と「エンジニアリング」間の情報転送を調整しています。
04 評価結果
SWE-benchでの各パッチセットを評価するために、著者はSWE-bench評価を使用しました。
結果は以下の通りです：
組織図パフォーマンス分析
異なる企業構造がパフォーマンスにどのように影響するかについての著者の観察結果は以下の通りです：
- 競争的なチームは成功の可能性を高めます。
最も優れたパフォーマンスを示した2つ（MicrosoftとApple）はどちらも問題解決のために競争する複数のチームを持っていましたが、他の企業は1つの巨大なチームが単一のパッチを生成しているように見えました。