GitHub、リポジトリ内マルチAI agentワークフロー「Squad」を公開

GitHubは2026-03-19の投稿で、GitHub Copilotベースのオープンソースプロジェクト Squad を紹介した。狙いは、multi-agent開発を別個の orchestration framework や vector database を前提にした重い構成から切り離し、リポジトリ内でそのまま動く workflow に近づけることだ。CLIを入れて各リポジトリで初期化するだけで、役割分担されたAIチームを作れるという構成になっている。

Squadが用意するもの

GitHubの説明では、まず npm install -g @bradygaster/squad-cli を実行し、各リポジトリで squad init を実行すると、lead、frontend developer、backend developer、tester が作られる。coordinator agent が作業を振り分け、リポジトリの文脈を読み取り、役割別 specialist を起動する。GitHubはこれを、別の control plane を先に作らなくても multi-agent 動作を始められる入口として位置づけている。

重要なのは、Squad が単一の chatbot の役割切り替えとして設計されていないことだ。GitHubはこれを repository-native orchestration と説明する。agentごとに別々の context window と責務があり、チーム全体はリポジトリ内の共有メモリを持つ。実運用で agent システムが不安定になる理由は、モデル性能より coordination の失敗であることが多く、この設計はかなり実務的だ。

なぜ構造が重要か

GitHubが強調する設計上のポイントは三つある。第一に、アーキテクチャ判断や規約をリポジトリの decisions.md に残し、隠れた session に閉じ込めないこと。第二に、1つの context を分割するのではなく、specialistごとに必要な文脈を複製して持たせること。第三に、agentの役割定義と履歴を .squad/ 配下の plain-text ファイルに保存し、inspectability と portability を高めていることだ。

さらにGitHubは、一度 reject された作業を同じ agent に修正させない方針も説明している。別の agent が修正に入るため、1つのモデルが自分の出力を自分で「レビュー」する一般的な構図よりも独立性の高い確認ループになる。ただしGitHubはこれを autonomous delivery とは呼ばない。最終的な PR の確認と merge は依然として人間が担当し、agent も質問したり、誤った前提を置いたりする可能性がある。

なぜ注目されるのか

Squadのポイントは、multi-agent coordination を infrastructure プロジェクトではなく、リポジトリの一部としてパッケージ化したことにある。この考え方が機能すれば、より多くのチームが standalone chat session ではなく、version control、CI、PR に近い形で inspectable な agent workflow を試せるようになる。大きな焦点は、役割分離と repository-native memory が、agentic coding をデモではなく日常のエンジニアリングに耐えるレベルまで安定化できるかどうかだ。