まず結論
GitHub Copilot CLI /fleet は、1つのタスクを複数のファイルや独立した方向（API、UI、テスト、ドキュメントなど）に分割できる場合に使う価値があります。すべてのプロンプトを高速化する万能ボタンではありません。安全な使い方は、ファイルの所有権を明確にし、プロンプト内で依存関係を宣言し、実行後に人間が最終レビューを行うことです。2つのサブエージェントが同じファイルを編集する必要がある場合、/fleet は通常、適切な出発点ではありません。
GitHubの2026年4月1日のリリースには実用的な意味があります。並列サブエージェントがCopilot CLIのファーストクラス機能になり、チーム独自の仕組みに頼る必要がなくなりました。開発者にとって重要なのは、マルチエージェントコーディングが格好いいかどうかではなく、/fleet がどの条件下で本当に時間を節約しつつ、コードベースの信頼性を損なわないかです。
前提条件： GitHub Copilot CLI をインストールし、いずれかの Copilot プラン（Free、Pro、Pro+、Business、Enterprise）が必要です。copilot --version を実行してCLIが利用可能か確認してください。有効なCopilotサブスクリプション以外の追加設定は不要です。
2026-04-01 に変わったこと
2026-04-01、GitHubはCopilot CLI /fleet の公式ガイドを発表しました。新しいシグナルは実務レベルのものです：GitHubはユーザーに対して、マルチエージェント実行を隠れた実装詳細として扱うのではなく、並列作業項目、依存関係、ファイル境界を軸にプロンプトを構成するよう明確に伝え始めました。
実務上のギャップも明確です。多くの開発者はすでにCopilotをシングルスレッドの計画や編集に使っていますが、いつ並列化すべきかの明確なルールを持っていません。/fleet はそのルールを提供します — タスクオーケストレーションとして扱う限り。
ここでは、/fleet を使って境界の明確なマルチファイル作業を早く終わらせつつ、サイレント上書きリスクやレビューの死角を作らない方法に絞る。
/fleet が実際にやること
GitHubの2026-04-01公式ブログによると、/fleet はCopilot CLIのスラッシュコマンドで、オーケストレーターが目的を作業項目に分解し、複数のバックグラウンドサブエージェントを派遣し、依存関係の完了を待ち、最終結果を統合します。
重要なのは実行モデルです：
- 各サブエージェントは独自のコンテキストウィンドウを持つ
- すべてのサブエージェントは同じファイルシステムを共有
- サブエージェント同士は直接通信しない
- オーケストレーターがどのトラックを並列実行し、どれを待機させるかを決定
共享ファイルシステムがメリットとリスクの両方を説明します。メリットは明白で、独立したファイルを同時に進められること。リスクも同様に明白で、共有ファイルが衝突ポイントになることです。
正しいタスク形状のときだけ /fleet を使う
適しているケース：
- APIハンドラー、テストファイル、ドキュメントを別々のファイルで同時に更新
- 複数ページのドキュメントを一括生成
- 明確に分離されたモジュールにまたがる機能のリファクタリング
- 複数ディレクトリに対する反復的で互いに独立した編集
適さないケース：
- 単一ファイルのバグ修正
- 問題自体がまだ明確でないタスク
- 各ステップが次の判断に影響するハイリスクなマイグレーション
- 2つ以上のエージェントが同時に同じファイルを編集する必要がある変更
シンプルなルール：
開始前に各エージェントに明確なファイルの所有権を割り当てられないなら、まだ /fleet を使わないでください。
安全なワークフローを一画面で
| ステップ | やること | なぜ重要か |
|---|---|---|
| 1 | ファイルまたはディレクトリ単位で出力を定義 | オーケストレーターには具体的な作業項目が必要 |
| 2 | 依存関係を明示的に宣言 | そうしないとCopilotが順序を誤る可能性がある |
| 3 | 境界と検証ルールを設定 | 範囲のドリフトや暗黙的な拡大を制限 |
| 4 | タスクが分割可能と確認してから /fleet を実行 |
線形な作業に並列化を加えてもオーバーヘッドが増えるだけ |
| 5 | 最終diffをレビューし実際のチェックを実行 | 並列出力にも責任あるレビュアーが必要 |
5ステップ。/fleet を有用かつノイズのないものに保つために必要な最低限のプロセスです。
ステップ1：成果物にマッピングするプロンプトから始める
GitHub自身の例が、曖昧なプロンプトがなぜ性能を発揮しないかを示しています。「ドキュメントを構築する」は良い /fleet プロンプトではありません。オーケストレーターが独立したトラックを識別しにくいためです。より良いプロンプトは各タスクを具体的なファイル、フォルダ、またはテストターゲットにマッピングします。
コピー可能な例：
/fleet Update the authentication docs in four tracks:
1. docs/authentication.md covering login flow and token refresh
2. docs/endpoints.md with request and response examples
3. docs/errors.md with auth-related error codes and fixes
4. docs/index.md linking the three pages above (depends on 1, 2, and 3)
Rules:
- no changes outside docs/
- preserve existing terminology from docs/styleguide.md
- mark done only when markdown lint passes
なぜこれが機能するか：
- 各トラックに目に見える成果物がある
- 他の3つに依存するのは1つのトラックだけ
- オーケストレーターは最初の3項目をきれいに並列化できる
- 検証ルールが明示的
ステップ2：速度を求める前にファイル境界を明確にする
GitHubの公式 /fleet ブログでは、ある警告が際立って明確に述べられています：サブエージェントはファイルシステムを共有し、ファイルロックがありません。2つのエージェントが同じファイルに書き込むと、最後に完了したものがサイレントに勝ちます。
つまり、プロンプト設計の本質的なスキルは「もっと多くのエージェントを要求する」ことではなく、「書き込みターゲットの重複を減らす」ことです。
次のような書き方を使います：
/fleet Implement feature flags in three tracks:
1. API layer in src/api/middleware/ with unit tests
2. UI toggles in src/components/flags/
3. definitions in config/features.yaml
Constraints:
- no dependency changes
- no edits outside assigned directories
- report blockers before expanding scope
- run tests relevant to each track before marking done
実行前に所有権を割り当てることで、「アプリ全体にfeature flagを追加」のような広範なリクエストより信頼性の高いプロンプトになります。
ステップ3：依存関係を使って待機が必要な部分だけをシリアライズ
並列実行はタスクグラフが部分的に独立している場合にのみ有用です。タスク全体が線形なら、/fleet はあまり加速せず、可動部品が増えるだけです。
良いマイグレーションプロンプトの例：
/fleet Migrate the user profile flow:
1. add the schema in migrations/008_profiles.sql
2. update src/models/profile.ts (depends on 1)
3. update src/api/profile.ts (depends on 2)
4. update tests/profile.test.ts (depends on 2)
Rules:
- do not change unrelated endpoints
- stop if the schema change requires a rollback plan
この例では、項目3と4は項目2の完了後に並列実行できます。これが /fleet がうまく処理する部分並列のパターンです。
ステップ4：重要な2つのコマンドパスを把握する
GitHubの公式ガイドは2つの基本的な起動方法を示しています：
対話モード
/fleet Refactor the auth module, update tests, and fix docs in docs/auth/
実行中に分解を確認しオーケストレーターを誘導したい場合は、対話モードの方が簡単です。
非対話モード
copilot -p "/fleet <YOUR TASK>" --no-ask-user
2026-04-02時点で、GitHubの公式 /fleet アナウンスでは、非対話モードにはプロンプト-レスポンスループがないため --no-ask-user が必須と明記されています。
制約がすでにプロンプトに完全にエンコードできるほど明確な場合にのみ、非対話モードを使ってください。まだ交渉が必要なら、対話モードにとどまりましょう。
ステップ5：傍観者ではなくレビュアーとして実行を見守る
GitHubは分解が実際に行われたかを確認し、/tasks でバックグラウンド作業を検査することを推奨しています。すべての /fleet 実行が本当に並列化されるわけではないため、これは重要です。
確認すべきこと：
- Copilotが実行前に作業を複数のトラックに分解しているか？
- 異なるトラックが同時に進行しているか？
- 各トラックが異なるファイルやディレクトリを担当しているか？
- 宣言し忘れた依存関係でブロックされているトラックがないか？
実行が線形すぎる場合は、より構造化されたプロンプトで停止して再試行します：
Decompose this into independent tracks first, then execute tracks in parallel.
Report each track separately with status, changed files, and blockers.
この表現は、一般的な「続けて」より良い監査証跡を提供します。
ステップ6：分割が本当に成立するときだけ専門エージェントを追加
GitHubの4月1日の例では、.github/agents/ でエージェントを定義し、特定のトラックにルーティングできることも示されています。あるレーンがドキュメント中心で別のレーンがコード中心の場合に有用です。
エージェントファイルの例：
---
name: technical-writer
description: Documentation specialist
model: claude-sonnet-4
tools: ["bash", "create", "edit", "view"]
---
You write concise technical documentation.
Follow docs/styleguide.md.
その上で次のようにプロンプトを書きます：
/fleet Use @technical-writer.md for docs tasks and the default agent for code changes.
タスクの分割が安定している場合にのみ行う価値があります。境界がまだ曖昧なら、カスタムエージェントはコア問題を解決せずにワークフローを複雑にするだけです。
最大の失敗パターン
2つのエージェントが1つのファイルを編集
ファイル衝突は最も明確な失敗ケースです。GitHubはファイルロックがないことを明示しています。同じファイルが複数のトラックに関わる場合、1つのエージェントで処理するか、サブエージェントに一時ファイルへ書き込ませて制御されたステップで後からマージします。
プロンプトがチャット履歴に依存
サブエージェントはオーケストレーターの会話履歴全体を見ることができません。重要なルールがチャット内にしか存在しない場合、1つ以上のトラックがそれを見落とす可能性があります。
対策：本当の制約を /fleet プロンプト自体に書くか、エージェントが読めるリポジトリ内のファイルに記載してください。
タスクが実際には線形
すべてのステップが前のステップに依存している場合、/fleet はあまり加速しません。可動部品が増えるだけです。
対策：まず標準のCopilot CLIタスクを実行するか、Copilotに計画を立てさせてから並列化するかを決めてください。
「複数のエージェントがチェックした」として最終レビューをスキップ
並列実行は独立した検証ではありません。依然として1回のオーケストレーション実行です。
対策：diffをレビューし、実際のチェックを実行し、マージ前に1つの人間による承認ゲートを維持してください。
実際のリポジトリ向けプロンプトテンプレート
ガードレールが組み込まれた出発点が必要なとき、これを使ってください：
/fleet Complete this task in parallel only where work is independent.
Objective:
[describe the outcome]
Tracks:
1. [file or directory owner + output]
2. [file or directory owner + output]
3. [file or directory owner + output]
Dependencies:
- [track 3 depends on track 1]
- [track 2 can run immediately]
Constraints:
- no edits outside assigned files unless blocked
- no dependency upgrades
- preserve public API names unless explicitly requested
- list blockers before expanding scope
Validation:
- run [tests/lint/typecheck]
- report changed files per track
- mark done only when all listed checks pass
このテンプレートは3つのことを同時に行います：Copilotに何を構築するか、何に触れないか、何をもって完了とするかを伝えます。
よくある質問
/fleet は通常のCopilot CLIプロンプトより優れていますか？
タスクに本当の並列構造がある場合にのみ。単一ファイルの作業や高度に結合したリファクタリングでは、通常のCopilot CLIプロンプトの方がシンプルです。マルチエージェントワークフローのより広い視点と判断基準については、AIエージェント実用ガイドをご覧ください。
/fleet をうまく使うには .github/agents/ のカスタムエージェントが必要ですか？
不要です。明確なファイル境界の方がカスタムエージェントより重要です。ベースのワークフローが既に機能してから、専門エージェントを追加してください。
どのGitHub Copilotプランに Copilot CLI が含まれていますか？
2026-04-02時点で、GitHubの公式Copilot CLIおよびプランページによると、Copilot CLIはFree、Pro、Pro+、Business、Enterpriseのすべてのプランで利用可能です。GitHubの現在の個人プランページではProが月額$10/ユーザー、Pro+が月額$39/ユーザーと表示されています。
結論
GitHub Copilot CLI /fleet は、作業の分割方法がすでに分かっている場合に有用です。メリットは「より多くのエージェント」からではなく、よりクリーンな分解から生まれます。
ファイル単位で成果物を定義し、依存関係を宣言し、一度の最終レビューを維持すれば、/fleet は境界の明確なマルチファイル作業を短縮できます。タスクがまだ推測、共有ファイル、または暗黙のコンテキストに依存している場合、並列化は誤った最適化方向です。
検証情報
2026-04-02に公式GitHub情報源に基づき検証：
- 公式 /fleet ガイド：GitHubブログ、Matt NighとBrian LaFlammeによる「Run multiple agents at once with /fleet in Copilot CLI」（2026-04-01公開）。オーケストレーターモデル、共有ファイルシステム（ファイルロックなし）、
/tasks検査、--no-ask-user非対話モード、.github/agents/カスタムエージェントを確認。 ソース：https://github.blog/ai-and-ml/github-copilot/run-multiple-agents-at-once-with-fleet-in-copilot-cli/ - Copilot価格：GitHub Copilotプランページに Free（$0）、Pro（$10/ユーザー/月）、Pro+（$39/ユーザー/月）が記載。Copilot CLIはFreeを含むすべてのプランに含まれる。
ソース：
https://github.com/features/copilot/plans
2026-04-02検証。トピックトリガーは共有 news-pipeline データベースで確認（GitHub ブログ2026-04-01公開記事：https://github.blog/ai-and-ml/github-copilot/run-multiple-agents-at-once-with-fleet-in-copilot-cli/）。同公式ブログに基づき、/fleet の主要動作、プロンプトパターン、依存関係の例、.github/agents/ の使用法、/tasks 検査、共有ファイルシステムの警告、非対話モード copilot -p "/fleet <YOUR TASK>" --no-ask-user の使用法を検証。GitHubの公式Copilot CLIおよびプランページ（2026-04-02確認）でCopilot CLIの利用可能性および現行プラン情報を検証：https://github.com/features/copilot/cli および https://github.com/features/copilot/plans。