オープンソースプロジェクト「Squad」は、GitHub Copilot上に構築されたマルチエージェントシステムです。リポジトリ内で複数のAIエージェントが協調して設計・実装・テスト・レビューを行う仕組みと、その背後にあるアーキテクチャパターンを解説します。
AIコーディングツールを使ったことがある方なら、このパターンに心当たりがあるでしょう。プロンプトを書く、モデルが意図を取り違える、プロンプトを修正する、より良い出力を引き出す——。こうした作業を繰り返していると、ソフトウェアを作ることよりも、モデルの操縦に時間を取られていることに気づきます。
プロジェクトが大きくなるにつれ、課題は「どうプロンプトを書くか」から「設計・実装・テスト・レビューをどうコンテキストを失わずに連携させるか」へと変わっていきます。
マルチエージェントシステムは、こうした壁を越える優れたアプローチですが、通常は膨大なセットアップが必要です。オーケストレーション層の構築、フレームワークの接続、ベクターデータベースの設定など、タスクを1つ委譲するだけでも何時間もかかってしまいます。
Squadは、GitHub Copilot上に構築されたオープンソースプロジェクトで、事前構成済みのAIチームをリポジトリ内に直接セットアップします。重厚なオーケストレーション基盤や高度なプロンプトエンジニアリングの知識がなくても、マルチエージェント開発をアクセスしやすく、理解しやすく、実用的に使えるようにすることを目指しています。
npm install -g @bradygaster/squad-cliをグローバルに1回実行し、リポジトリごとにsquad initを1回実行するだけで、Squadはリード、フロントエンド開発者、バックエンド開発者、テスターからなる専門チームをリポジトリに配置します。
1つのチャットボットが役割を切り替えるのではなく、Squadは、重い中央集権型インフラなしにリポジトリネイティブなマルチエージェントオーケストレーションを実現します。
Squadがエージェント間の作業を協調させる仕組み
必要な作業を自然言語で記述するだけで、Squad内のコーディネーターエージェントがルーティングを判断し、リポジトリのコンテキストを読み込み、タスク固有の指示を持った専門エージェントを起動します。
例えば、「チーム、JWT認証が必要だ——リフレッシュトークン、bcrypt、一式頼む。」と入力すると、チームが並列で動き始めます。バックエンド担当が実装を引き受け、テスターが対応するテストスイートの作成を開始し、ドキュメント担当がプルリクエストを作成します。数分以内にファイルが作成され、ブランチが切られます。これらの専門エージェントは、命名規則や先週火曜日に決めたデータベース接続の方針をすでに把握しています。プロンプトに書いたからではなく、リポジトリにコミットされた共有のチーム決定事項と、各エージェント自身のプロジェクト履歴ファイルから読み込んでいるからです。
手動で出力をテストし、何度も修正を重ねるプロンプトのやり取りを強いる代わりに、Squadは内部でイテレーションを処理します。バックエンド担当が初期実装を作成すると、テスターがそれに対してテストスイートを実行します。テストが失敗した場合、テスターはコードをリジェクトします。ここで重要なのは、オーケストレーション層が元のエージェントによる自己修正を防止する仕組みです。Squadのレビュアープロトコルは、元の作成者がリジェクトされた作業を修正することを防ぎ、別のエージェントが修正を担当します。これにより、独立したコンテキストウィンドウと新鮮な視点による真の独立レビューが強制されます。単一のAIが自分自身のミスをレビューするのとは根本的に異なります。レビュアー自動化が有効なワークフローでは、開発者はすべての中間的な試行ではなく、この内部ループを生き残ったプルリクエストをレビューします。
これはオートパイロットでもなければ、最初のセッションから魔法のように動くものでもありません。エージェントは確認の質問をすることがありますし、妥当だが誤った仮定を置くこともあります。プルリクエストのレビューとマージは、引き続き開発者自身が行います。これは自律的な実行ではなく、協調的なオーケストレーションです。
リポジトリネイティブオーケストレーションを支えるアーキテクチャパターン
Squadを使う場合でも、独自のマルチエージェントワークフローを構築する場合でも、リポジトリネイティブオーケストレーションの構築から学んだいくつかのアーキテクチャパターンがあります。これらのパターンは、「ブラックボックス」的な振る舞いから、リポジトリレベルで検査可能かつ予測可能なものへとアーキテクチャを移行させます。
1. 共有メモリのための「ドロップボックス」パターン
多くのAIオーケストレーションは、エージェント間の同期にリアルタイムチャットや複雑なベクターデータベース検索に依存しています。しかし、これは脆弱になりがちです。ライブエージェント間での状態同期は、実際には非常に困難です。
代わりにSquadは「ドロップボックス」パターンを採用しています。特定のライブラリの選定や命名規則といったアーキテクチャ上の意思決定は、構造化されたブロックとしてリポジトリ内のバージョン管理されたdecisions.mdファイルに追記されます。これは、リポジトリ内での非同期的な知識共有がリアルタイム同期よりもスケールするという考えに基づいています。Markdownファイルをチームの共有脳として扱うことで、永続性、可読性、そしてチームが行ったすべての意思決定の完全な監査証跡が得られます。このメモリはライブセッションではなくプロジェクトファイル内に存在するため、切断や再起動後もコンテキストを復元し、中断した場所から続行できます。
2. コンテキスト分割ではなくコンテキスト複製
AI開発における最大のハードルの1つは、コンテキストウィンドウの制限です。単一のエージェントがすべてを行おうとすると、「ワーキングメモリ」がメタ管理で溢れ、ハルシネーションにつながります。
Squadはこの問題を、コーディネーターエージェントを薄いルーターとして維持することで解決します。コーディネーター自身は作業を行わず、専門エージェントを起動します。各専門エージェントは独立した推論呼び出しとして実行され、それぞれが独自の大きなコンテキストウィンドウ（対応モデルでは最大20万トークン）を持つため、1つのコンテキストを4つのエージェントで分割するのではなく、リポジトリのコンテキストを各エージェントに複製する形になります。
複数の専門エージェントを並列で実行することで、複数の独立した推論コンテキストが同時に動作します。これにより、各エージェントは他のエージェントの思考とスペースを奪い合うことなく、リポジトリの関連する部分を「見る」ことができます。
3. モデルの重みによる暗黙的メモリではなく、プロンプトによる明示的メモリ
AIチームのメモリは、可読かつバージョン管理されるべきだと考えています。エージェントがプロジェクトについて何を「知っている」のか、推測しなければならない状態であってはなりません。
Squadでは、エージェントのアイデンティティは主に2つのリポジトリファイルから構築されます。チャーター（エージェントの役割定義）とヒストリー（これまでの活動履歴）、そして共有のチーム決定事項です。これらはすべてプレーンテキストです。.squad/フォルダに格納されているため、AIのメモリはコードと一緒にバージョン管理されます。リポジトリをクローンすると、コードだけでなく、すでに「オンボーディング済み」のAIチームも手に入ります。なぜなら、チームのメモリがリポジトリ内のコードと一緒に格納されているからです。
マルチエージェントワークフローへの参入障壁を下げる
Squadで最も大きな成果は、誰でも手軽にエージェント開発を始められるようにしたことです。AIチームにコードの作成を手伝ってもらうためだけに、インフラとの格闘、複雑なプロンプトエンジニアリングの習得、煩雑なCLI操作に何時間も費やす必要はないはずです。
リポジトリネイティブオーケストレーションがどのような体験かを確認するには、SquadのGitHubリポジトリをチェックして、実際の問題にSquadを投入し、ワークフローがどのように進化するかを体験してみてください。