GitHub Copilot CLIの/fleetコマンドで複数エージェントを同時実行する

GitHub Copilot CLIに /fleet コマンドが追加された。ひとつのプロンプトを投げると、内部のオーケストレータがタスクを分解し、独立した作業を複数のサブエージェントに並列で振り分ける。マルチファイルのリファクタリングやドキュメント一括生成のように「自然に分割できるタスク」で効く機能だ。

Copilot CLIは2026年2月にGAになったばかりで、Explore、Task、Code Review、Planといったビルトインエージェントや & キーによるクラウド委任機能を備えていた。 /fleet はその延長線上にある、並列実行のためのコマンドだ。

オーケストレータの5ステップ

/fleet を実行すると、メインエージェントがオーケストレータとして以下の処理を行う。

graph TD
    A[プロンプト受信] --> B[タスク分解]
    B --> C[依存関係の分析]
    C --> D[独立タスクを<br/>並列ディスパッチ]
    D --> E[完了ポーリング]
    E --> F{後続タスク<br/>あり?}
    F -->|あり| G[次のウェーブを<br/>ディスパッチ]
    G --> E
    F -->|なし| H[成果物の検証と統合]

プロンプトを離散的なワークアイテムに分解する
どのアイテムが並列実行可能かを判定する
独立したアイテムをバックグラウンドのサブエージェントとして同時ディスパッチする
完了をポーリングし、依存先が終わった後続ウェーブを順次投入する
全出力を検証し、最終成果物を統合する

ポイントは「ウェーブ」の概念。依存関係のあるタスクは先行タスクの完了を待ってから次のウェーブとして投入される。完全にフラットな並列ではなく、DAG（有向非巡回グラフ）的なスケジューリングになっている。

使い方

基本構文はシンプルで、/fleet の後にやりたいことを書くだけだ。

/fleet Refactor the auth module, update tests, and fix the related docs in docs/auth/

非インタラクティブなターミナルで使う場合はこう。

copilot -p "/fleet <YOUR TASK>" --no-ask-user

プロンプトの書き方で並列度が決まる

/fleet の効果はプロンプトの書き方に大きく依存する。曖昧な指示だとオーケストレータがタスクを分割できず、結局逐次実行になる。

悪い例と良い例を比較する。

曖昧な指示だと分割できない。

/fleet ドキュメントを全部書き直して

具体的に書けば分割しやすくなる。

/fleet 以下の4ファイルのAPIドキュメントを作成:
- docs/authentication.md: OAuth2フローの説明
- docs/endpoints.md: 全エンドポイントのリファレンス
- docs/errors.md: エラーコードの一覧と対処法
- docs/index.md: 上記3ファイルへのリンクと概要（3ファイルの完成後に作成）

後者の場合、オーケストレータは authentication.md、endpoints.md、errors.md の3つを第1ウェーブで並列生成し、3つとも完了してから index.md を第2ウェーブで生成する。依存関係を明示的に書くことで、オーケストレータが正しくスケジューリングできる。

公式ブログでは、プロンプトに含めるべき要素として以下を挙げている。

要素	効果
ファイル・モジュール境界	サブエージェントの担当範囲が明確になる
制約条件（触らないファイル等）	意図しない変更を防ぐ
検証基準（lint、型チェック、テスト）	サブエージェントが自律的に品質を担保
依存関係の宣言	ウェーブの順序が正しくなる

ファイル競合の問題

/fleet には重大な制約がある。サブエージェント間にファイルロックの仕組みがない。同じファイルに複数のサブエージェントが書き込むと、最後に書き込んだエージェントの内容で上書きされる。しかもサイレントに。エラーも警告も出ない。

対策は2つ。

ひとつは、各サブエージェントに明確に異なるファイルを割り当てること。プロンプトで「このファイルはこのタスク専用」と明示する。もうひとつは、各サブエージェントが一時パスに書き込み、オーケストレータが最後にマージする構成にすること。ただし後者はプロンプト設計がかなり複雑になる。

Claude Codeのマルチエージェントレビューでは複数エージェントが並列に動いてPRをレビューするが、あちらは各エージェントの出力がコメントという形で独立しているため、ファイル競合の問題は構造的に発生しない。 /fleet は実際にファイルを編集するため、この問題が表面化する。

コンテキスト共有の制限

もうひとつ知っておくべき制約がある。サブエージェントはオーケストレータの会話履歴を引き継がない。 /fleet 以前にCopilot CLIと会話していた内容、たとえば「このプロジェクトはReact 19を使っている」「テストはVitestで書いて」といったコンテキストは、サブエージェントには伝わらない。

つまり /fleet プロンプトは自己完結している必要がある。必要なコンテキストはすべてプロンプト内に含めるか、参照すべきファイルパスを明示する。

カスタムエージェントとの連携

.github/agents/ ディレクトリに定義したカスタムエージェントを /fleet から呼び出せる。プロンプト内で @agent-name 記法を使って指定する。

/fleet @technical-writer.md を使ってdocs/配下のドキュメントを更新し、
@test-writer.md を使ってtests/配下のテストを追加して

サブエージェントはデフォルトで低コストモデルを使うが、カスタムエージェントのプロファイルで特定のモデルを指定できる。これはコスト面で重要だ。サブエージェントごとにpremium requestが消費されるため、並列数が多いとリクエスト消費が急増する。

GA時点のpremium request枠はFreeプラン50回/月、Pro 300回、Pro+ 1,500回で、超過分は$0.04/回。モデルごとの乗数もあり、Claude Opus系は3倍消費になる。 /fleet で5つのサブエージェントをOpusで動かすと、1回の実行で15リクエスト以上消費する計算だ。

/tasksで実行状況を確認する

/fleet 実行中に /tasks コマンドを打つと、バックグラウンドで動いているサブエージェントの一覧とステータスが表示される。実行前にオーケストレータの分解計画を確認して、意図通りに複数トラックに分かれているかチェックするのが望ましい。

どんなタスクに向いているか

/fleet が効果を発揮するのは、自然な並列性を持つタスクだ。

向いているのはこんなタスクだ。

複数ファイルにまたがるリファクタリング
コンポーネントごとのドキュメント一括生成
API、UI、テストが独立して書ける機能実装
複数の独立したバグ修正を一括実行

逆に向いていないのはこっち。

単一ファイル内の変更
前のステップの結果を見ないと次が書けない厳密にリニアな作業

後者のケースでは、通常のCopilot CLIプロンプトのほうがシンプルで速い。

各社エージェントモードとの比較

ターミナルベースのAIコーディングツールでマルチエージェント並列実行を提供しているのはCopilot CLIだけではない。Claude CodeのAgent TeamsやCord（Claws構想の実装例）と比較すると、コンテキスト共有とファイル分離の設計に明確な差がある。

項目	Copilot CLI `/fleet`	Claude Code Agent Teams	Cord (Spawn/Fork)
コンテキスト継承	なし。プロンプト内容のみ	CLAUDE.md自動読み込み	Spawn: 依存先出力のみ / Fork: 全兄弟結果
エージェント間通信	なし	JSONインボックス	SQLite経由の依存グラフ
ファイル競合防止	なし（サイレント上書き）	OSプロセス分離	MCPスコープ制御
オーケストレーション	AIが自動分解・ウェーブ実行	利用者が明示定義	エージェントが実行時に設計
永続化	なし（セッション限り）	`.claude/` ファイルシステム	SQLite
状態の可視性	`/tasks` で一覧表示	親が最終出力のみ受領	SQLクエリ可能
必要プラン	Copilot Free以上（premium request制）	Claude Pro以上 or API	なし（OSS + 任意のAPI）

コンテキスト共有の設計差

マルチエージェント実行で最も差が出るのが「サブエージェントにどこまでコンテキストを渡すか」だ。

/fleet はサブエージェントに会話履歴を一切渡さない。プロンプトの内容だけが各サブエージェントの入力になる。「テストはVitestで書く」「importは相対パスで」といったプロジェクト慣習は、毎回プロンプトに含めるか .github/agents/ のカスタムエージェントに埋め込む必要がある。ウェーブ間でも同様で、第1ウェーブの結果が第2ウェーブのサブエージェントにそのまま渡るわけではない。オーケストレータが中継はするが、サブエージェント同士が直接やり取りする手段はない。

graph LR
    A[オーケストレータ] -->|プロンプト<br/>コピー| B[Sub 1]
    A -->|プロンプト<br/>コピー| C[Sub 2]
    A -->|プロンプト<br/>コピー| D[Sub 3]
    B -.->|共有なし| C
    C -.->|共有なし| D

Claude CodeのAgent Teamsはこの問題を構造的に軽減している。各サブエージェントが起動時に CLAUDE.md を自動で読み込むため、プロジェクト固有のルール（フレームワーク、コーディング規約、ディレクトリ構造等）はプロンプトに書かなくても暗黙的に共有される。v2.1.19以降ではさらに、ディスクベースのJSONインボックス（~/.claude/<teamName>/inboxes/<agentName>.json）を介したエージェント間メッセージングが可能だ。共有タスクリストからタスクを取得し、処理結果を他のエージェントに直接送信できる。ファイルシステムというもっともプリミティブなIPCを採用しているため、エージェントがクラッシュしてもメッセージキューが消えることはない。

graph LR
    E[CLAUDE.md] -.->|自動読込| F[Agent 1]
    E -.->|自動読込| G[Agent 2]
    F <-->|JSON<br/>inbox| G
    H[共有タスクリスト] --- F
    H --- G

Cord（Spawn/Forkモデル）はコンテキスト制御の粒度がさらに細かい。

モード	動作
Spawn	子タスクは依存先として宣言されたタスクの出力のみを受け取る。並列の独立タスク向き
Fork	子タスクは全兄弟タスクの結果を継承する。集約・意思決定タスク向き

MCPサーバーがスコープを強制するため、子タスクが親の管理外のリソースにアクセスすることを構造的にブロックする。全タスクの状態・依存関係・出力はSQLiteに保存されるため、エージェントのクラッシュ後も途中から再開できる。

ファイル分離のアプローチ

コンテキスト共有と同じくらい重要なのが、複数エージェントが同じリポジトリを同時に編集するときのファイル競合だ。

/fleet にはファイルロックの仕組みがなく、同じファイルへの同時書き込みは最後の書き込みでサイレントに上書きされる。前述の通り、利用者がプロンプトで担当ファイルを明示的に分離するしかない。

Claude Codeはv2.1.25以降のCowork機能で、Apple Virtualization.frameworkによるVM分離を導入した。各エージェントが独立したVMで動作し、vsock（Virtio Socket）でホストと通信する。ファイルシステムレベルでの競合は原理的に発生しないが、VM1台あたり10GB以上のディスクを消費する。Agent Teamsの場合はOSプロセスとして分離されるものの同じファイルシステム上で動くため、ファイル競合の防止は利用者の設計に委ねられる。

CordはMCPサーバーによるスコープ制御でアクセス可能なリソースを制限し、意図しないファイルへの書き込みを構造的にブロックする。

ツール	分離方式	ファイル競合リスク	コスト
`/fleet`	プロセス分離のみ	高（サイレント上書き）	低
Agent Teams	OSプロセス分離	中（設計依存）	低
Cowork VM	VM分離（vsock通信）	なし	高（10GB+/VM）
Cord	MCPスコープ制御	低（構造的ブロック）	低

プラン要件と実行コスト

機能面の比較に加えて、そもそもどのプランで使えるかが選択に直結する。

/fleet はCopilot Freeを含む全プランで利用可能だが、サブエージェントごとにpremium requestを消費する。Freeプランの月50回ではまともな並列実行は難しく、Proの300回でもモデル次第ですぐ枯渇する。Pro+（月$39 / 1,500回）以上、あるいは超過課金（$0.04/回）を許容できる環境が現実的だ。

Agent TeamsはClaude Codeが使えるプランであれば利用可能。Pro（月$20）以上のサブスクリプションまたはAPI利用が必要で、Freeプランでは使えない。Proには使用量の上限があり、複数エージェントの同時実行はトークン消費がエージェント数に比例するため、実運用ではMax（月$100〜$200）かAPI直接利用が前提になりやすい。

Cordはオープンソースのため、プラン制限なし。LLMのAPI料金だけが変動コストになる。

3ツールとも「マルチエージェント並列実行」を謳っているが、無料〜低価格帯のプランで実用的に使えるものは実質ない。並列数が増えるほどリクエスト/トークン消費が線形に増えるため、マルチエージェント機能は中〜上位プラン向けの機能と考えたほうがいい。

設計思想のトレードオフ

/fleet はプロンプトひとつで分割と並列化を自動判断する。利用者がサブエージェントを意識する必要がなく、手軽さでは最も優れている。その代わり、コンテキスト喪失やファイル競合のリスクを利用者が管理する必要がある。

Agent Teamsは CLAUDE.md によるコンテキスト共有とエージェント間通信で、より構造化された協調を実現する。設定の手間はかかるが、プロジェクト慣習の伝達漏れが起きにくい。PRの並列レビューのように、各エージェントの出力が独立したコメントとして分離されるユースケースとの相性が良い。

Cordはコンテキスト制御の粒度が最も細かく、SpawnとForkを使い分けることでタスクごとに最適なコンテキスト量を調整できる。MCPによる権限制御も含め、安全性を重視した設計だ。ただし500行のPython + SQLiteという小さなPoC段階で、プロダクション向けのツールではまだない。

どれが正解かはタスクとプラン次第だ。「4ファイルのドキュメントを一括生成」のような単純な並列タスクなら /fleet の自動分解で十分。プロジェクト固有のルールが複雑でエージェント間の調整が必要ならAgent Teams。セキュリティ上の分離が必要ならCordのスコープモデルか、Claude CodeのVM分離が選択肢に入る。いずれの場合も、利用中のプランでサブエージェントを複数走らせるコストが現実的かどうかは事前に確認しておきたい。

Codex CLI・Gemini CLI・オープンLLM系の対応状況

ここまでの比較はCopilot CLI、Claude Code、Cordの3ツールだったが、ターミナルベースのAIコーディングツールは他にもある。Codex CLI、Gemini CLI、オープンLLM系ツールのマルチエージェント並列実行への対応状況を見ておく。

Codex CLI: git worktreeによるサブエージェント分離

OpenAIのCodex CLIにはSubagents機能がある。自然言語で「各ポイントごとにエージェントをスポーンして」と指示すると、複数のサブエージェントが並列に起動する。/fleet のように「プロンプトを投げれば自動でタスク分解」ではなく、ユーザーが並列化を明示的に指示するスタイルだ。

最大の特徴はファイル分離のアプローチにある。Codex CLIのサブエージェントは各自がgit worktreeで隔離されたリポジトリコピー上で動作する。同じファイルに複数のサブエージェントが同時に書き込む状況が構造的に発生しない。/fleet のサイレント上書き問題と比較すると、gitの仕組みを使った競合回避は明らかに安全だ。

graph TD
    A[ユーザー指示] --> B[メインエージェント]
    B --> C[Sub 1<br/>worktree A]
    B --> D[Sub 2<br/>worktree B]
    B --> E[Sub 3<br/>worktree C]
    C --> F[結果統合]
    D --> F
    E --> F

管理面では /agent コマンドでアクティブなエージェントスレッドの一覧・切り替え・停止が可能。codex exec による非対話モードでCI/CDパイプラインへの組み込みにも対応する。さらにCodex CLI自体をMCPサーバーとして公開し、OpenAI Agents SDKから複数エージェントをオーケストレーションする構成も取れる。

ただしタスク分解の自動化という点では /fleet に及ばない。/fleet はプロンプトからDAG的な依存関係を推論してウェーブ実行まで自動化するが、Codex CLIでは並列化の設計はユーザー（またはAgents SDKのコード）が行う。手軽さの /fleet、安全性のCodex CLI、という棲み分けになっている。

Gemini CLI: 本体は未対応、拡張エコシステムで部分カバー

Gemini CLI本体にはマルチエージェント並列実行機能がない。サブエージェント機能自体は存在するが、ツールコールが逐次実行のため並列化できない状態だ。GitHubでは並列サブエージェント実行のIssue（#17749、#14963）が立っているが、ファイル競合の解決を含めまだ開発中。Claude Code Agent Teams相当の機能を求めるFeature Request（#19430）も出ている。

本体の不足を補っているのが拡張機能エコシステムだ。

拡張	概要
Conductor（Google公式）	Context-Driven Developmentを掲げ、2エージェント並列のリファレンス実装を提供。Write-Lockでファイル競合を回避する設計だが、本格的なマルチエージェント並列は提案段階（Issue #66）
Maestro（コミュニティ）	22の専門サブエージェントをTechLeadエージェントが調整するオーケストレーション構成

Gemini CLIの最大の強みは、無料でGemini 2.5 Pro（100万トークンコンテキスト）にアクセスできる点だ。コスト面では他のどのツールよりも敷居が低い。ただし並列エージェント機能が本体に入るまでは、/fleet やAgent Teamsと同列に比較するのは難しい。

オープンLLM系: 単体での並列実行は未実装

Qwen Code（Alibaba公式、GitHub 21.6k stars）はClaude Codeライクなターミナルエージェントで、SubAgentsやSkills機能を内蔵している。ただしフリート型の並列オーケストレーション機能は持っていない。Aider（42.7k stars）も同様で、architectモードとcodeモードの2段階ワークフローはあるが、並列エージェント実行のサポートはGitHub Issueで要望されたまま未実装だ。

オープンLLM系のCLIエージェント単体で、/fleet のような並列実行を内蔵しているものは現時点で確認できなかった。並列実行を実現するには、外部オーケストレータに頼る形になる。

ツール	stars	概要
Emdash	3.6k	23種のCLIエージェント（Claude Code、Qwen Code、Codex等）をgit worktreeで隔離して並列実行するデスクトップアプリ
AgentsMesh	1.2k	リモートワークステーション上で複数CLIエージェントを並列実行・協調させるプラットフォーム
mco	263	任意のCLIエージェントをIDE非依存で統合制御する軽量オーケストレーションレイヤー

これらはいずれもエージェント自体ではなく、既存CLIエージェントのラッパーだ。モデル性能の向上に対して、ツール側の並列化基盤が追いついていない。

全ツール比較

前節までの3ツールに加え、Codex CLIとGemini CLIを含めた全体像を整理する。

項目	Copilot CLI `/fleet`	Claude Code Agent Teams	Cord	Codex CLI Subagents	Gemini CLI
自動タスク分解	あり（DAGウェーブ）	なし（利用者定義）	エージェントが設計	なし（明示指示）	未対応
ファイル分離	なし（サイレント上書き）	OSプロセス	MCPスコープ	git worktree	未対応
コンテキスト継承	プロンプトのみ	CLAUDE.md自動読込	依存グラフ	プロンプトのみ	—
エージェント間通信	なし	JSONインボックス	SQLite	なし	—
状態の可視性	`/tasks`	親が最終出力受領	SQLクエリ	`/agent`	—
コスト	premium request制	Pro〜 or API	OSS + API料金	API課金	無料（Gemini 2.5 Pro）

ファイル競合という観点では、Codex CLIのgit worktree分離が現行ツール中で最もクリーンだ。タスク分解の自動化では /fleet が唯一のフルオート。コスト最安はGemini CLIだが、並列機能が本体にない。

結局のところ、マルチエージェント並列実行はどのツールでも「中〜上位プラン向けの機能」という状況に変わりはない。