こんにちは、AIニュースアプリ Morning AI 開発者の矢野哲平です。この記事ではGitHub Copilot CLIに追加された /fleet コマンドについて触れます。
Run multiple agents at once with /fleet in Copilot CLI - The GitHub Blog
/fleet とは何か
/fleet はGitHub Copilot CLIの新しいスラッシュコマンドです。簡単に言うと、1つのプロンプトから複数のサブエージェントを並行して走らせる仕組みです。
ちなみに直訳すると"艦隊"の意味です。
/fleet を使うと、異なるファイルやモジュールへの変更を同時に進められます。
動作の流れ
内部ではオーケストレーターが以下の処理を行います。
- タスクを離散的な作業項目に分解する
- 依存関係を分析し、並行実行できるものとそうでないものを識別する
- 独立した項目をバックグラウンドでディスパッチする
- 完了をポーリングし、次のウェーブをディスパッチする
- 出力を検証し、最終成果物を統合する
各サブエージェントは独立したコンテキストウィンドウを持ちますが、ファイルシステムは共有されます。この「ファイルシステム共有」が後述する注意点に繋がります。
使い方
基本的な使い方はシンプルです。
/fleet Refactor the auth module, update tests, and fix the related docs in the folder docs/auth/
つまり、/fleetコマンドの後にプロンプトを描きます。
非対話的に実行したい場合は --no-ask-user フラグを付けます。
copilot -p "/fleet <YOUR TASK>" --no-ask-user
プロンプトの書き方が肝になる
/fleet の効果を引き出すには、プロンプトの書き方が重要です。曖昧な指示より、具体的な成果物とファイルパスを明示するほうがうまく動きます。
/fleet Create docs for the API module:
- docs/authentication.md covering token flow and examples
- docs/endpoints.md with request/response schemas for all REST endpoints
- docs/errors.md with error codes and troubleshooting steps
- docs/index.md linking to all three pages (depends on the others finishing first)
この例では3つのドキュメントが並行生成され、index.md は他の3つが完了してから作られます。依存関係を自然言語で書くだけで、オーケストレーターが実行順序を判断してくれます。
依存関係が複雑なケースでも同様です。
/fleet Migrate the database layer:
1. Write new schema in migrations/005_users.sql
2. Update the ORM models in src/models/user.ts (depends on 1)
3. Update API handlers in src/api/users.ts (depends on 2)
4. Write integration tests in tests/users.test.ts (depends on 2)
Items 3 and 4 can run in parallel after item 2 completes.
この場合、ステップ3と4はステップ2の完了後に並行実行されます。
注意すべき落とし穴
同一ファイルへの書き込み
複数のサブエージェントが同じファイルに書き込むと、最後に完了したエージェントの内容で上書きされます。エラーは出ません。静かにデータが消えます。
対策はシンプルで、各エージェントに別々のファイルを割り当てるか、一時パスを使うことです。
サブエージェントはコンテキストを引き継がない
サブエージェントはオーケストレーターの会話履歴を見られません。
直前の会話で「さっき話したあの件」と書いても伝わらないということです。
/fleet のプロンプトに必要な情報をすべて含める必要があります。
カスタムエージェントとの組み合わせ
.github/agents/ ディレクトリに専門的なエージェント定義を置くことで、/fleet と組み合わせて使えます。
モデル、ツール、命令を個別に指定できるため、テスト専用エージェントやドキュメント専用エージェントを用意しておくと便利そうです。
例えば、テクニカルライターのエージェントを設定したとします。(technical-writer.md)
これを/fleetで呼び出すと以下のようになります。
/fleet Use @technical-writer.md as the agent for all docs tasks and the default agent for code changes.
向いているタスク、向いていないタスク
| 向いている | 向いていない |
|---|---|
| 複数ファイルの同時リファクタリング | 単一ファイルの線形な作業 |
| 複数コンポーネントのドキュメント作成 | |
| API・UI・テストにまたがる機能実装 | |
| 状態を共有しない独立したコード修正 |
単一ファイルの修正に /fleet を使うと、オーケストレーションのオーバーヘッドが無駄になります。
まずは小さく試すのが良さそう
個人的に、同一ファイル上書きの問題は実際にハマりそうだなと思います。エラーが出ないのが厄介です。
使い始めるなら、ファイル境界が明確で依存関係が少ないタスクから試すのが良いかなと。
例えば、複数のドキュメントファイルを同時に生成するようなケースが最も安全に /fleet の恩恵を受けられると思います。