この記事でわかること
- Copilot CLIの/fleetコマンドの仕組みと基本的な使い方
- 複数ファイルに作業を分割するプロンプト設計のコツ
- 依存関係の宣言方法とよくあるエラーの回避策
プロジェクトの規模が大きくなると、AIに1つずつタスクを頼む作業が地味にストレスになってきます。「フロントエンドのコンポーネントを修正しながら、同時にバックエンドのAPIも書き換えたい」——そんな場面で力を発揮するのが、GitHub Copilot CLIに追加された /fleet コマンド。複数のエージェントを同時に走らせ、並列でコード変更を進められる機能です。
2026年3月にGitHub公式ブログで発表されたこの機能は、Copilot CLIの使い方を大きく変える可能性を秘めています。ただし、並列処理ならではの落とし穴もあるため、正しい理解が欠かせません。
この記事では、/fleetの導入から実践的なプロンプト設計まで、開発現場ですぐに使えるノウハウを体系的にまとめました。
Copilot CLIの/fleetとは？並列エージェント実行の基本
/fleetコマンドの概要と登場背景
GitHub Copilot CLIは、ターミナル上でCopilotの支援を受けながらコーディングできるツール。従来は1つのプロンプトに対して1つのエージェントが順番に処理を進める仕組みでした。
/fleetはこの制約を取り払い、1回のプロンプトで複数のエージェントを同時に起動するコマンドです。たとえば、3つのファイルを同時に編集したり、テストコードとプロダクションコードを並行して生成したりできます。
背景にあるのは、現代の開発プロジェクトが抱える「タスクの粒度」の問題。マイクロサービスやモノレポ構成が主流になり、1つの機能追加でも複数のディレクトリ・ファイルにまたがる変更が必要になるケースが増えました。/fleetはこの課題に対するGitHubの回答と言えるでしょう。
従来のCopilot CLIとの違い
従来のCopilot CLIでの作業フローと、/fleetを使った場合の違いを整理すると次の通り。
| 項目 | 従来のCopilot CLI | /fleet使用時 |
|---|---|---|
| エージェント数 | 1つ | 複数（並列） |
| 処理方式 | 逐次実行 | 並列実行 |
| ファイル操作 | 1ファイルずつ | 複数ファイル同時 |
| 依存関係の管理 | 不要 | 明示的に宣言 |
| 所要時間 | タスク数に比例 | 大幅に短縮 |
体感では、3〜5ファイルにまたがる変更作業で処理時間が半分以下になるケースも珍しくありません。ただし、すべてのタスクが並列化に向いているわけではない点は注意が必要です。この判断基準については後述します。
/fleetの導入と初期セットアップ
Copilot CLIのインストールと前提条件
/fleetを使うには、まずCopilot CLIが最新バージョンであることを確認してください。GitHubは頻繁にアップデートをリリースしているため、古いバージョンでは/fleetコマンド自体が認識されない場合があります。
インストール手順（macOS / Linux）:
- ターミナルで npm install -g @githubnext/github-copilot-cli を実行
- github-copilot-cli auth でGitHubアカウントの認証を完了
- copilot –version でバージョンを確認
Windows環境でも同じnpmコマンドで導入できます。WSL2を使っている場合はLinuxと同じ手順でOK。
前提条件として押さえておきたいのが以下の3点。
- GitHub Copilotの有効なサブスクリプション（Individual、Business、Enterpriseいずれか）
- Node.js 18以上がインストール済みであること
- Git リポジトリ内で実行すること（/fleetはリポジトリのコンテキストを参照するため）
サブスクリプションのプランによって同時実行できるエージェント数に差があるかは、2026年4月時点で公式に明示されていません。ただし、Business以上のプランでは制限が緩和される傾向にあるため、大規模な並列実行を考えている場合はプランの確認をおすすめします。
/fleetコマンドの基本構文
/fleetの基本的な書き方はシンプル。通常のCopilot CLIプロンプトの先頭に /fleet を付けるだけです。
基本構文: /fleet “タスクの説明”
実行すると、Copilot CLIがプロンプトの内容を解析し、自動的にタスクを分割して複数のエージェントに振り分けます。ここが従来のコマンドとの最大の違いで、ユーザーが手動でタスクを分ける必要はありません。
ただし、「自動分割に任せきり」だと意図しない結果になることも。より正確に制御したい場合の明示的な書き方は次のセクションで詳しく解説します。
実践：/fleetのプロンプト設計テクニック
ここからが本題。/fleetを最大限に活かすには、プロンプトの書き方がカギを握ります。漠然と指示を出すのではなく、タスクの分割方法を明確に伝えることで精度が大きく変わるのが実感です。
タスクをファイル単位で分割する方法
最も基本的な使い方が、ファイル単位での作業分割。プロンプト内で対象ファイルを明示することで、各エージェントが担当範囲を正確に把握できます。
例：APIエンドポイントとフロントエンドを同時に更新する場合
/fleet “src/api/users.tsにGET /users/:id/profileエンドポイントを追加して、src/components/UserProfile.tsxでそのAPIを呼び出すプロフィール表示コンポーネントを作成して”
このように書くと、Copilotは2つのエージェントを起動します。1つ目がバックエンドのAPI追加を、2つ目がフロントエンドのコンポーネント作成を、それぞれ同時に進行。
プロンプト設計で意識したいポイントは3つ。
- ファイルパスをフルパスで指定する：曖昧な指定だとエージェントが誤ったファイルを編集するリスクがある
- 各ファイルでの作業内容を具体的に記述する：「適切に修正して」のような曖昧な指示は避ける
- 1エージェントあたりの作業量を適度に絞る：1つのエージェントに10ファイルの変更を任せるより、2〜3ファイルずつ分けたほうが精度は高い
依存関係を宣言して実行順序を制御する
並列処理で最もトラブルが起きやすいのが、ファイル間の依存関係。たとえば、型定義ファイルを先に作成し、その型を使うコンポーネントを後から生成する——という順序が必要な場面は頻繁に発生します。
/fleetでは、プロンプト内で依存関係を明示的に宣言できます。
依存関係を含む記述例:
/fleet “まずsrc/types/user.tsにUserProfile型を定義して。次にその型を使ってsrc/api/users.tsにfetchProfile関数を実装して。最後にsrc/components/Profile.tsxでfetchProfileを呼び出すコンポーネントを作って”
「まず」「次に」「最後に」のような順序を示す言葉を入れると、Copilotがタスクの依存グラフを構築してくれます。依存関係のないタスク同士は並列に、依存があるタスクは順序を守って逐次実行という動き。
ここで大切なのは、不要な依存関係を作らないこと。すべてのタスクを直列にしてしまうと、/fleetを使う意味がなくなってしまいます。「本当にこのタスクは前のタスクの完了を待つ必要があるか？」を常に自問してみてください。
プロンプトのアンチパターンと改善例
/fleetで失敗しやすいプロンプトのパターンを、改善例と合わせて紹介します。実際に試してみて「これはうまくいかない」と感じたものばかりです。
パターン1：指示が曖昧すぎる
- NG: /fleet “プロジェクト全体をリファクタリングして”
- OK: /fleet “src/utils/date.tsの日付フォーマット関数をdayjsに移行して、src/utils/string.tsの文字列処理関数にエラーハンドリングを追加して”
曖昧な指示だと、エージェント同士が同じファイルを編集しようとしてコンフリクトが発生する原因に。
パターン2：同一ファイルを複数エージェントに触らせる
- NG: /fleet “src/index.tsの前半を修正して、同じsrc/index.tsの後半も修正して”
- OK: 同一ファイルの変更は1つのエージェントにまとめるか、関数を別ファイルに切り出してから並列化
パターン3：依存関係の方向を間違える
- NG: コンポーネントの生成を先に指示し、そのコンポーネントが使う型定義を後から指示する
- OK: 型定義やインターフェースなど「参照される側」を先に指示
これらのパターンを避けるだけで、/fleetの成功率は格段に上がります。
/fleetの活用シーン｜現場で役立つ5つのユースケース
具体的にどんな場面で/fleetが威力を発揮するのか。開発現場でよくあるシーンを5つ取り上げました。
1. フルスタック機能の一括実装
バックエンドAPI、フロントエンドコンポーネント、データベースマイグレーションを同時に生成。1つの機能追加に必要な全レイヤーの変更を一度に指示できるのが最大の強みです。
2. テストコードの並列生成
プロダクションコードの変更と同時に、対応するユニットテスト・統合テストを別エージェントに書かせるパターン。テストを後回しにしがちな開発者にとって、変更とテストが同時に揃うのは地味にありがたい仕組み。
3. マイクロサービス間の整合性を保った更新
サービスAのAPIレスポンス形式を変更する際に、サービスBのクライアントコードも同時に修正。サービス間の整合性を保ちながら並列で作業を進められます。
4. ドキュメントとコードの同時更新
コードの変更に合わせて、READMEやAPIドキュメント、CHANGELOGを同時に更新させるケース。「コードは直したけどドキュメントが古いまま」という事態を防げます。
5. リファクタリング時のファイル分割
大きなファイルを複数の小さなモジュールに分割する際、各モジュールの生成を並列で実行。分割後のインポートパスの更新まで含めて一度に指示すると効率的です。
Copilot CLIをコーディング支援以外にも活用したい方は、GitHub Copilotの基本ガイドも合わせてチェックしてみてください。
/fleet使用時の注意点とトラブルシューティング
便利な/fleetですが、並列処理特有のトラブルに遭遇することもあります。事前に知っておけば対処は難しくありません。
コンフリクトの回避と解消
複数エージェントが同時にファイルを編集する以上、マージコンフリクトのリスクは常に存在します。/fleetは内部的にコンフリクト検知の仕組みを持っていますが、完全ではないのが現状。
コンフリクトを避けるための実践的なルールは以下の通り。
- 1ファイル1エージェントの原則を守る
- 共有モジュール（utilsやconstantsなど）への変更は、他のタスクとは分離して先に実行する
- package.jsonやlock fileのような共有設定ファイルは、/fleetの対象から外して手動で更新するのが安全
万が一コンフリクトが発生した場合、Copilot CLIはコンフリクト箇所をハイライト表示してくれます。通常のGitコンフリクト解消と同じ手順で対処できるため、Git操作に慣れている方なら問題ないでしょう。
パフォーマンスとレート制限
並列実行数を増やしすぎると、APIのレート制限に引っかかる場合があります。体感として、同時に5エージェント程度までが安定動作のラインです。
レート制限に達した場合の挙動はプランによって異なりますが、一般的にはエージェントの一部がキューに入り、先行のエージェントが完了次第、順番に実行される形になります。エラーで全体が止まるわけではないので、過度に心配する必要はありません。
処理が遅いと感じたら、以下を確認してみてください。
- プロンプトが複雑すぎないか（1タスクあたりの指示を簡潔にする）
- リポジトリの規模が大きすぎないか（コンテキストウィンドウの制約）
- ネットワーク環境に問題がないか
Copilotの料金体系や各プランの詳細については、GitHub Copilotの料金プラン比較で詳しく解説しています。
よくあるエラーメッセージと対処法
/fleet使用中に遭遇しやすいエラーとその対処法を表にまとめました。
| エラーメッセージ | 原因 | 対処法 |
|---|---|---|
| Conflicting file edits detected | 複数エージェントが同じファイルを編集 | ファイルの担当を分離してリトライ |
| Dependency cycle detected | 依存関係が循環している | プロンプトの依存順序を見直す |
| Rate limit exceeded | API呼び出し回数が上限に到達 | エージェント数を減らすか、時間を空けて再実行 |
| Context window exceeded | リポジトリのコンテキストが大きすぎる | 対象ファイルを絞り込む |
| Agent timeout | エージェントの処理が時間切れ | タスクをより小さな単位に分割 |
エラーが出た場合でも、成功したエージェントの結果はそのまま保持されます。失敗したタスクだけを再実行すればよいので、全体をやり直す必要はありません。
まとめ
GitHub Copilot CLIの/fleetコマンドは、複数のエージェントを並列実行することで開発速度を引き上げる実践的な機能です。
押さえておきたいポイントを整理すると、以下の3点に集約されます。
- ファイル単位でタスクを分割し、各エージェントの担当範囲を明確にする
- 依存関係は明示的に宣言し、不要な直列化を避ける
- 1ファイル1エージェントの原則を守り、コンフリクトを未然に防ぐ
まずは2〜3ファイル程度の小規模な並列実行から試してみてください。プロンプトの書き方に慣れてきたら、徐々にエージェント数を増やしていくのが失敗の少ないアプローチです。
Copilot CLIを日常的に使っている開発者であれば、/fleetの導入で作業効率が体感できるレベルで変わるはず。特にフルスタック開発やマイクロサービス構成のプロジェクトでは、試す価値のある機能と断言できます。
AIコーディングツールの全体像を把握したうえで、自分のワークフローに合った使い方を見つけてみてください。
よくある質問（FAQ）
Q: /fleetコマンドはGitHub Copilotの無料プランでも使えますか？
A: /fleetはCopilot CLIの機能であり、GitHub Copilotの有効なサブスクリプション（Individual以上）が必要です。無料トライアル期間中でも利用できますが、同時実行数やリクエスト回数にはプランごとの制限が適用される場合があります。
Q: /fleetで同時に実行できるエージェントの上限は何個ですか？
A: 公式には明確な上限が公表されていませんが、実用上は5エージェント程度が安定動作の目安です。それ以上に増やすとレート制限に達しやすくなり、一部のエージェントがキュー待ちになる可能性があります。プロジェクトの規模やプランに応じて調整してください。
Q: /fleetで生成されたコードにコンフリクトが起きた場合、どうすればよいですか？
A: Copilot CLIがコンフリクト箇所を検知してハイライト表示してくれます。通常のGitマージコンフリクトと同じ要領で手動解消が可能です。予防策としては、1ファイルを複数のエージェントに同時編集させないことが最も効果的です。
Q: /fleetは既存のGitブランチやワークフローに影響を与えますか？
A: /fleetの変更はローカルのワーキングディレクトリに直接反映されます。Gitブランチを自動で作成したりコミットしたりはしないため、既存のブランチ戦略への影響はありません。変更内容を確認してから、通常通り手動でコミット・プッシュする流れです。
Q: /fleetとGitHub Copilot Workspaceの違いは何ですか？
A: Copilot WorkspaceはブラウザベースのAI開発環境で、課題の分析からプルリクエスト作成までを一貫してサポートするツール。一方、/fleetはCopilot CLIのコマンドで、ターミナル上での並列コード生成に特化しています。Workspaceがプロジェクト全体の計画立案向きなのに対し、/fleetは具体的なコーディングタスクの高速化が目的という違いがあります。
コメント