時代に翻弄されるエンジニアのブログ

ゲームプログラマをやっています。仕事やゲームや趣味に関してつらつら書きたいと思います。

マルチエージェントでAI開発を構造化する「GitHub Copilot Orchestra」

こんにちは、takuです。

AIコード生成の課題と向き合った結果

AIにコードを書かせる時、みなさんはどんな風に進めていますか?

自分はCopilotやCursorを使っていて、確かにコード生成のスピードは上がりました。

でも正直なところ「本当にこれでいいのか?」という不安が常にあったんです。

テストと実装意図の不透明さ

AIが生成したコードをそのまま使うと、テストが不十分だったりします。

後から見返した時に「なぜこう実装したのか」が分からなくなることもありました。

コンテキスト管理の難しさ

特に困るのが、コンテキストの管理です。

複数のファイルを跨いだ実装をAIに依頼すると、途中で指示が曖昧になる。

結局自分で修正する羽目になります。

AIとのやり取りが増えるほど、会話履歴が長くなって、AIが最初の意図を見失ってしまうこともありました。

そんな中で見つけたのが「GitHub Copilot Orchestra」というリポジトリです。

https://github.com/ShepAlderson/copilot-orchestra

GitHub Copilot Orchestraとは

これは、VS Code Insiders上で動くマルチエージェントシステムです。

AIによる開発を「Plan → Implement → Review → Commit」というサイクルで構造化してくれます。

テスト駆動開発(TDD)を強制する仕組みも組み込まれていて、品質面でも安心できそうだと感じました。

4つのエージェントの役割

Copilot Orchestraは、4つの専門エージェントで構成されています。

Conductor(指揮者)

全体の指揮を執るメインエージェント。

ユーザーからの要求を受け取り、他のエージェントを呼び出します。

planning-subagent(計画担当)

コードベースを調査し、関連ファイルや関数を洗い出します。

既存のパターンや制約を把握して、Conductorに報告します。

implement-subagent(実装担当)

TDDのサイクルを厳格に守りながら実装を進めます。

テストを書いて失敗させる → 最小限のコードを書く → テストを通す、という流れです。

code-review-subagent(レビュー担当)

git上の未コミット変更を確認し、テストカバレッジやコード品質をチェック。

承認、修正必要、失敗のいずれかの判定を返します。

実装サイクルの流れ

Conductorが計画を作成し、3〜10のフェーズに分けてユーザーに提示します。

計画を承認すると、implement-subagentが各フェーズを順番に実装。

実装が終わると、code-review-subagentがレビューを実施。

問題なければ、Conductorがコミットメッセージを生成して提示します。

ユーザーがコミットして次のフェーズに進む合図を送ると、同じサイクルが繰り返されます。

すべてのフェーズが完了すると、最終的な完了レポートが生成されます。

セットアップ方法

まず、VS Code Insidersが必要です。

通常版ではなくInsiders版が必要な理由は、カスタムエージェント機能がInsiders版でしか使えないからです。

リポジトリをクローンしたら、4つの.agent.mdファイルをコピーします。

プロジェクトルートに置けばそのプロジェクト専用、ユーザーデータディレクトリに置けば全プロジェクトで使えます。

実際の使い方

GitHub Copilot Chatのエージェントドロップダウンから「Conductor」を選択。

自分がやりたいことを伝えます(例:「JWT認証をExpressのAPIに追加したい」)。

Conductorが計画を提示してくるので、内容を確認して承認。

「Open Questions」があれば答えることで、計画がより精緻になります。

実装フェーズに入ると、implement-subagentが各フェーズを自動実装。

フェーズ終了ごとにレビューが入り、問題なければコミットメッセージが生成されます。

ユーザーはそれを使ってgitコミットし、「次のフェーズに進んで」と伝えます。

すべて完了すると、plans/ディレクトリに完了レポートが生成されます。

途中で中断しても、各フェーズの完了ドキュメントから進捗を確認できます。

構造化されたAI開発の可能性

この仕組みの面白いところは、AIの役割が明確に分かれている点です。

自分一人でAIとやり取りしていると、指示が曖昧になったり、途中で迷子になったりします。

でも、エージェントごとに役割が決まっていると、それぞれが専門性を発揮できるんですよね。

TDDの強制が効く

AIが生成したコードをそのまま使うのではなく、必ずテストを先に書かせる。

それを通すための最小限の実装をさせる。

この流れがあるだけで、コードの品質が段違いに上がるんじゃないかと思います。

変更履歴が細かく残る

各フェーズごとにレビューとコミットが入るので、後から追いやすい。

問題があった時に、特定のフェーズだけ巻き戻すこともできます。

運用上の課題はあるかも

実際に使ってみるまでは分からない部分もあります。

フェーズ分けがうまくいかない場合や、AIのレビューが甘い場合にどう対処するのか。

そういった運用上の課題は出てくるかもしれません。

構造化というアプローチ

それでも、AIによる開発を「構造化する」というアプローチは、今後のAI活用において一つの方向性を示してくれている気がします。

自分も、このツールを実際に試してみて、どこまで実用的なのか、どんな場面で活きるのかを検証してみたいと思っています。

AIとの協働が当たり前になってきた今、こういった「AIをどう使いこなすか」という枠組み自体が、エンジニアにとって重要なスキルになっていくのかもしれませんね。