なぜAI開発はコード生成からタスク管理へ変わるのか。GitHub公式Copilot CLI「/fleet」完全ガイド

Copilot CLIにヤバい機能が来た。「/fleet」だ。

1つのファイルをチマチマ直す時代は終わった。

これからは5つのファイルを同時に編集する。

裏側でオーケストレーターが動き、複数のサブエージェントが並列で走る。

マルチエージェント時代が、ついにターミナルにやってきた。

SNS運用を自動化しませんか？

ThreadPostなら、投稿作成・画像生成・スケジュール管理までAIがサポート。

無料で始める

ターミナルで動くマルチエージェントの衝撃

Copilot CLIの「/fleet」は、単なるコード生成コマンドではない。

背後に強力なオーケストレーターを備えた、自律型の開発チームだ。

プロンプトを投げると、オーケストレーターが即座にタスクを分解する。

依存関係を洗い出し、同時に実行できる作業を見つけ出す。

そして、バックグラウンドで待機する複数のサブエージェントに一斉に仕事を割り当てる。

各サブエージェントは独立したコンテキストウィンドウを持ち、ファイルシステムを共有する。

これまでのAIコーディングは、常に逐次処理だった。

ファイルAを読み込み、修正し、次にファイルBを開く。

しかし「/fleet」は違う。

異なるファイル、異なるディレクトリの修正を、完全に同時並行で進行させる。

各サブエージェントは直接会話することはできない。

全ては中央のオーケストレーターが取り仕切る。

オーケストレーターの動きは、熟練のプロジェクトマネージャーそのものだ。

タスクを配り、進捗をポーリングで監視する。

完了した作業から回収し、依存関係がクリアされた次のタスクを波状的に投下する。

最後にすべての成果物を検証し、ひとつの完成品として合成する。

これがターミナル上で、コマンド一発で実行される。

`/fleet <YOUR OBJECTIVE PROMPT>` と打つだけだ。

非インタラクティブモードでも動く。

`copilot -p "/fleet <YOUR TASK>" --no-ask-user` で、ターミナルから直接実行できる。

※この記事は、Claude Codeで1人SaaS開発しているしんたろーが、海外AI最新情報を開発者目線で解説する「AI活用Tips」です。

開発者はコーダーからプロジェクトマネージャーへ

AIに「この機能を作って」と丸投げするフェーズは終わった。

僕らはAIを「開発チーム」としてマネジメントする立場になった。

僕は毎日Claude Codeを使っている。

ターミナルで動く強力な自律型エージェントだ。

Claude Codeに巨大なタスクを投げると、たまに迷子になる。

コンテキストが膨れ上がり、自分が今どのファイルを触っているか分からなくなるからだ。

単一のエージェントにすべてを処理させるアプローチには限界がある。

だからこそ、タスクの境界を引くことが効いてくる。

Copilot CLIの「/fleet」は、この境界引きを開発者に強制してくる。

「ドキュメントを作って」という曖昧なプロンプトは最悪だ。

これだとオーケストレーターはタスクを分割できない。

結果として、1つのエージェントが順番に処理する羽目になる。

正解はこうだ。

「API仕様書と、エラーコード一覧と、認証フローの3つのマークダウンを作成して。最後にそれらをリンクするインデックスを作って」

成果物を具体的にリストアップする。

インデックス作成は他の3つが終わってから、という依存関係も明確に伝える。

これで初めて、オーケストレーターは3つのタスクを並列で走らせることができる。

これはプログラミングではない。要件定義とプロジェクトマネジメントだ。

プログラミング言語の文法知識より、自然言語でのタスク分割能力が問われる。

これが、開発者に求められるスキルの変化だ。

しんたろー：
Claude Codeに「いい感じにリファクタリングして」って投げたら、関係ないファイルまで巻き込んで大惨事になったことがある。
オーケストレーターにタスクを委譲するって、結局は人間の言語化能力が試されてるんだよな。

スコープと依存関係の明示がすべてを決める

まずは成果物を具体的に定義する癖をつける。

「機能を実装して」ではなく「コントローラーとモデルとテストコードの3つのファイルを作成して」だ。

タスクの解像度を、物理的なファイル単位まで落とし込む。

これがオーケストレーターに並列化の余地を与える。

次にスコープを限定する。

どのディレクトリを触っていいか、どのファイルは絶対に書き換えてはいけないか。

これを明示しないと、複数のエージェントが同じファイルを奪い合って暴走する。

「/fleet」のサブエージェントたちはファイルシステムを共有しており、ファイルロックは存在しない。

2つのエージェントが同じファイルに書き込んだ場合、後から終わった方が黙って上書きする。

エラーも出ない。マージもされない。ただ上書きされるだけだ。

スコープの分離は、衝突を防ぐための絶対的な防波堤だ。

複数のエージェントが同一ファイルに書く必要がある場合は、それぞれ一時パスに書かせてオーケストレーターに最後にマージさせる。

依存関係の言語化も必須だ。

「データベースのマイグレーションが終わってから、APIのエンドポイントを実装して」

順序を教えないと、並列で走って確実にエラーを吐く。

有向非巡回グラフ（DAG）を頭の中で描き、それを自然言語に翻訳する。

GitHub公式ドキュメントが示す依存関係の書き方はこうだ。

「1. マイグレーションSQL → 2. ORMモデル（1に依存）→ 3. APIハンドラーとテスト（2に依存、3と4は並列）」

3と4が並列で走れるのは、2が完了してから。

この構造を自然言語で書けるかどうかが、並列処理の効率を決める。

Claude CodeでThreadPostを開発している時も、このスコープと順序の明示が一番効く。

曖昧な指示は、AIを混乱させる最大の要因だ。

しんたろー：
`/fleet`のドキュメント読んでたら、ファイルロックが存在しないって書いてあって背筋が凍った。
「後から終わった方が黙って上書き」って、人間のチームでこれやったら即クビだよな。

ここまで読んだあなたに

今なら無料で全機能をお試しいただけます。設定後はAIが投稿案を毎日生成。確認して選ぶだけ。

無料で始める

カスタムエージェントで役割分担を最適化する

「/fleet」にはもう一つ強力な機能がある。

`.github/agents/` ディレクトリにカスタムエージェントを定義し、プロンプトから参照できる。

各エージェントはモデル、ツール、指示を個別に設定できる。

ドキュメント作成タスクには軽量モデル、複雑なロジック実装には重いモデル、という使い分けが可能だ。

たとえばこう書く。

`/fleet Use @technical-writer.md as the agent for all docs tasks and the default agent for code changes.`

モデルを指定しない場合、エージェントはデフォルトモデルを使う。

タスクの性質に合わせてモデルを選ぶことで、コストと精度のバランスを取れる。

オーケストレーターが本当に並列で動いているか確認する方法

`/fleet` を実行したあと、本当に並列で動いているかを確認する手順がある。

まず、Copilotが作業を開始する前に提示するプランを確認する。

複数のトラックに分解されているか、それとも1本の長い線形プランになっているか。

線形プランになっていたら、プロンプトの粒度が足りていない。

次に `/tasks` コマンドを実行する。

バックグラウンドで動いているタスクの一覧が表示される。

複数のトラックが同時に進行していれば、並列化は成功している。

1つしか動いていなければ、プロンプトを見直す。

並列化されていないと感じたら、一度止めてこう指示する。

「まず独立したトラックに分解してから、並列で実行して。各トラックのステータスと障害を別々に報告して」

この一文で、オーケストレーターの動き方が変わる。

マルチエージェント開発FAQ

Q1: Copilot CLIの「/fleet」を使う際、サブエージェント同士が同じファイルを同時に編集して競合することはありませんか？

ファイルロックは存在しない。2つのエージェントが同じファイルに書き込んだ場合、後から終わった方が黙って上書きする。エラーも出ない。

オーケストレーターが依存関係を解析し、独立して実行可能な作業だけを並列でディスパッチするが、プロンプトで「どのディレクトリを誰が触るか」というスコープを明示することが競合防止の根本的な対策だ。複数エージェントが同一ファイルに書く必要がある場合は、それぞれ一時パスに書かせてオーケストレーターに最後にマージさせる構成にする。

Q2: 「/fleet」はどんなタスクに向いていて、どんなタスクには向いていませんか？

複数ファイルの同時リファクタリング、複数コンポーネントのドキュメント生成、API・UI・テストにまたがる機能実装、状態を共有しない独立したコード修正に向いている。

一方、厳密に線形で単一ファイルの作業には通常のCopilot CLIプロンプトの方がシンプルで速い。`/fleet` はオーケストレーションのオーバーヘッドがあるため、分散できる実作業がない場合はコストだけがかかる。

Q3: マルチエージェントにタスクを依頼する際、どのようなプロンプトを書けば効率よく並列処理されますか？

成果物を具体的にリストアップし、それぞれのスコープと依存関係を明示することだ。「ドキュメントを作って」ではなく「4つのマークダウンを作成し、AとBが終わったらCを作る」と指示する。

これによりオーケストレーターが並列化可能なタスクを正確に判断する。一斉にサブエージェントを走らせるためのトリガーは、具体的なファイル名と順序の指定だ。