プログラムによる足場なしで行った11のマルチエージェントソフトウェア構築からの実践的知見

マルチエージェントシステム実験からの主要技術的知見

プログラム的な足場なしで構築された11の自律マルチエージェントソフトウェア（2億9500万トークン、98エージェントセッション、610万行のワーカー出力に基づく）の分析から、AIコーディングエージェントを扱う開発者向けの実用的な洞察が明らかになりました。

スコープ強制とオーケストレーション

スコープ強制はプロンプトではなく機械的に解決される： プロンプトベースのアプローチはコンパイラ圧力下で0/20回失敗した一方、機械的アプローチ（エージェントにすべてを編集させ、スコープ外ファイルにはgit revertを使用）は20/20回成功しました。重要な洞察：モデルに境界を尊重するよう依頼するのではなく、事後的に強制すること。

オーケストレーターコストはメモリに制約される： 入力コストの約95%は会話履歴の再読み込みに費やされています。「状態保持プレミアム」とは、出荷コードを一切書かないフロンティアオーケストレーターが、ワーカー群全体と同じコストになることを意味します。最適化は、より安価な推論ではなく、ターン数の削減と再取り込みの軽減を目指すべきです。

調整とスケーリングのダイナミクス

モデルは自律的に調整を発見しない： 完全なツールアクセスを持つベアプロンプトOpusは、委任も仕様書作成も並列ディスパッチの発見も一切行わず、単独ですべてを構築しました。調整テンプレートが実際の作業を行います。

深さと品質は異なるスケーリングを示す： 10ドメイン以下の場合、フラットディスパッチは階層構造よりもスループット、トークン効率、実時間で優れています。10ドメインを超えると、階層構造はフラットディスパッチでは達成できない並列性を可能にします。

コンテキスト制限が働くまでは単独作業が調整を上回る： 単独作業のスループットは約325 LOC/分で、プロジェクトサイズに影響されません。ピラミッド型スループットはワーカー数に比例してスケールします。約30K LOC未満では、委任は純粋なオーバーヘッドとなります。

ワーカーパフォーマンスと型システム

ワーカーモデルの能力がスループットを決定する： 同一アーキテクチャ、同一仕様で3つのワーカーモデルが生成した結果：17,761 LOC vs 6,001 vs 1,818—9.8倍の格差。アーキテクチャは並列スループットを可能にし、ワーカーモデルがそれを決定します。

型契約は共通語彙を提供する： テストしたすべてのスケール（6–36モジュール）で、読み取り専用制約下でも、契約なしで統合は成功しました。しかし契約がない場合、並列ワーカーは構造的に互換性のない型を静かに生成し、相互参照がないためにのみコンパイルされます。盲目的に書かれた単一の984行の契約が、10の独立ドメインにわたって保持されました。

型契約はスケール時の調整オーバーヘッドを排除する： 制御されたスケーリングテスト（1–20ワーカー、固定仕様）では、50ドメインビルド全体で統合エラーはゼロでした。10ワーカーが最適点：2.05倍の実時間高速化。20ワーカーでは、直列フェーズの依存関係が並列化の利得を相殺します（アムダールの直列部分約44%）。

コンテキストと委任パターン

コンテキストプライミングは機能する；形式は重要ではない： 設計コンテキストがない場合の公式転送は0%、ある場合は100%（条件ごとにN=10）。静的参照ドキュメントは、合成的ブート会話と同一の転送率を生み出します。

委任圧縮は本質的である： 各委任層は損失のある要約装置として機能します。定量的要件（「80の武器」）は消失し、構造的要件（型インターフェース）は残ります。解決策：ワーカーは圧縮されたプロンプトチェーンに依存するのではなく、ファイルシステムから完全な仕様を読み取るべきです。

良好な要約による圧縮回復は堅牢である： 11の圧縮イベント全体でタスクの再発はゼロ。モデルは期待状態を述べ、その後ディスクを読み取って検証します。

失敗モードと修正策

• 抽象化反射： 調整する代わりにオーケストレーターを構築する—プロンプトで名前を指定する
• 自己モデルエラー： 偽の能力を主張する—利用可能なツールを明示的に文書化する
• アイデンティティのパラドックス： 二重役割を保持できない—別々のモデルインスタンスを使用する
• 委任圧縮： 列挙的仕様とファイルシステムアクセスを併用する