GitHub、Squadでリポジトリネイティブな multi-agent coding workflow を提示

4月5日のGitHubのX postは、Squadを改めて紹介した。GitHub Copilotの上に構築されたこのopen-source projectは、multi-agent software workflowを一般的なリポジトリの中で実用化しようとする試みだ。GitHubの問題意識は明快で、single-prompt codingではmodelを何度もsteeringする必要があり、design、implementation、testing、reviewをうまく分離できないという点にある。

Squadの導入は意図的に軽く設計されている。GitHubによれば、開発者は npm install -g @bradygaster/squad-cli でCLIを入れ、リポジトリで squad init を実行するだけでよい。するとlead、frontend developer、backend developer、testerなどを含むAI teamが構成される。coordinator agentはroutingに徹し、specialistがtask-specific instructionを受けて動くため、重いorchestration stackやvector databaseを先に組まなくても実験を始められる。

shared memoryはリポジトリの中に置く

より重要なのはcontext共有の考え方だ。GitHubはlive agent同士のリアルタイム同期は壊れやすいと見ており、Squadではteam knowledgeをversioned repo fileに書き戻す。architectural decisionは decisions.md に追記され、agentのidentityやhistoryは .squad/ フォルダに保存される。つまりAI teamのmemoryがvendor sessionや隠れたvector storeに閉じず、コードと一緒にinspectableかつclonableな形で残る。

GitHubはさらに、Squadがcontext splittingではなくcontext replicationを選ぶと説明する。coordinatorは薄く保たれ、specialistはそれぞれ独立したinference callと別々のcontext windowを持つ。例ではbackend agentが実装し、testerがtest suiteを走らせ、reviewer automationが有効なら最初のauthor agentが自分でrejected patchを直せないようにもできる。もちろんGitHubもこれをautopilotとは言わない。最終的にPRをreviewしてmergeするのはhumanだ。それでもSquadは、coding agentを単なる賢いchat paneではなく、リポジトリ内で協働するinfrastructureへ変えようとする流れを具体的に示している。