AIエージェントの群れを操る「フリートエンジニアリング」とは何か

Posted at 2026-07-24

はじめに

「1体のコーディングエージェントと対話しながらコードを書く」段階から、「複数のエージェントを同時に走らせ、その群れ（fleet）を設計・監督する」段階へ——2025年から2026年にかけて、開発現場ではこの移行を指す言葉がいくつも現れました。そのひとつが フリートエンジニアリング（fleet engineering） です。

この記事で分かることは、次の3点です。

「フリートエンジニアリング」という言葉が指すものと、その用法が2系統に割れている実情
なぜ単一エージェントから「群れ」運用へ向かうのか、その技術的背景
群れを回すための代表的なアーキテクチャ・運用パターンと、その限界

対象読者は、Claude Code・Cursor・GitHub Copilot などのコーディングエージェントを日常的に使っていて、「複数同時に動かす運用」に興味がある開発者です。前提知識は、LLM を使ったコーディング支援ツールに一度でも触れたことがある程度で十分です。

なお筆者は、この記事を書くにあたり各社の一次情報（公式ブログ・ドキュメント）を追いかけて整理しました。用語の解像度がまだ低い領域なので、事実と筆者の推測は分けて書いています。

背景：言葉の定義がまだ固まっていない

まず正直に書くと、「fleet engineering」はまだ確立した定義を持つ単一の造語ではありません。2025〜2026年に複数の当事者が並行して使い始めた、収束途上の呼称です。そして用法が大きく2つに割れています。

ひとつは、企業内で多数のエージェントを統治・運用するというガバナンス寄りの意味です。たとえば Cobus Greyling 氏は fleet engineering を「本番ソフトウェアに求めるのと同じ厳格さで、組織横断的に多数のエージェントを運用する規律」と定義しています（Cobus Greyling, 2026-06-18）。この文脈では、LangChain の「LangSmith Fleet」のような、業務エージェント全般を build/use/manage するプロダクトが背景にあります（LangChain Blog, 2026-03-19）。

もうひとつが、この記事で扱う開発者が複数のコーディングエージェントを並列に走らせて設計・監督する開発規律です。こちらは "fleet engineering" という熟語よりも、"running a fleet" や "agentic engineering" という言い回しで語られることが多いのが実態でした。

注目すべきは、コーディング文脈で "fleet" を明確に機能名として採用した最も分かりやすい一次ソースが GitHub だという点です。GitHub Copilot CLI の /fleet コマンドは「複数のサブエージェントを並列に同時稼働させる」機能として定義されています（GitHub Blog, 2026-04-01）。Docker も社内のCIで動く7つのエージェントロールを "a fleet of agents" と呼んでいます（Docker Blog, 2026-05-01）。

つまり「fleet engineering」という言葉の最初の使用者を一意に特定することは、筆者が調べた範囲ではできませんでした。同時多発的に生まれた収束語、と捉えるのが妥当そうです。

なぜ今、単一エージェントから「群れ」へ向かうのか

背景には、いくつかの技術的な圧力があります。

並列化がそのままスコアと速度に効く。Anthropic は、リードエージェントが3〜5体のサブエージェントを同時に spawn する構成で、複雑な調査タスクの時間を最大90%短縮し、単一エージェントを大きく上回ったと報告しています。さらに「トークン使用量だけで性能分散の80%を説明できる」とも述べており、探索を並列に広げて計算を投入できること自体が品質に効く、という示唆です（Anthropic Engineering, 2025-06-13）。

コンテキスト長の限界。単一エージェントの文脈窓は有限で、大規模な移行や横断監査ではあふれます。サブエージェントに専用のコンテキストで作業させて要約だけ返させれば、主対話を汚さずに済みます（Claude Code Docs）。

作業隔離技術の普及。複数エージェントが同じリポジトリで衝突せずに動く土台として、git worktree による分離が定着しました。Cursor 2.0 は最大8体を並列に走らせ、worktree やリモートマシンでファイル競合を防ぎ、各エージェントに独立したコピーを与えます（Cursor 2.0 Changelog）。

ただし、これらの動機は同時に制約でもあります。Anthropic は「エージェントはチャットの約4倍、マルチエージェントは約15倍のトークンを使う」ため、タスクの価値が高い場合にのみ成立すると明言しています。「なぜ今か」の答えは、そのまま「どこで使うべきか」の答えでもあるわけです。

代表的なアーキテクチャ・運用パターン

群れの回し方には、いくつか繰り返し登場する型があります。

オーケストレーター + サブエージェント（fan-out / fan-in）

中心はこの型です。リードエージェント（オーケストレーター）が複雑なタスクを具体的な小タスクに分解し、複数のサブエージェントを起動して並列に処理させ、結果を統合します。

重要なのは、GitHub /fleet の設計が明言しているように、サブエージェント同士は直接会話せず、オーケストレーターだけが調整するという点です。各サブエージェントは自分専用のコンテキストウィンドウを持ちますが、ファイルシステムは共有します（GitHub Blog）。

生成と評価の分離

もうひとつの核が、実装するエージェントと評価するエージェントを分けることです。Docker は "Ralph-loop" と呼ぶ仕組みで、ワーカーが実装し、独立したレビューアが差分を評価し、人間のレビュー前に最大5回まで反復させています。各反復は別々のモデル呼び出しです（Docker Blog）。

human-in-the-loop を最後の砦として残す

生成物が増えるほど、検証の仕組み化が要ります。Docker のフリートは「PR は作るがマージはしない」と明言しています。承認とマージは人間が担うわけです。GitHub /fleet でも、オーケストレーターが各サブエージェントの出力を検証してから最終成果物を組み立てます。

ハマりどころ：懐疑論も無視できない

ここまで並列運用の利点を書きましたが、強い反対論があることも押さえておくべきです。

Cognition（Devin を開発）の Walden Yan 氏は「Don't Build Multi-Agents」で、マルチエージェントは意思決定が分散しすぎて脆く、並列エージェントは十分な共有文脈を欠くために解釈が衝突すると主張しました。示された原則は「メッセージ単体ではなく、エージェントの全トレースと文脈を共有せよ」「行動は暗黙の決定を伴い、矛盾する決定は悪い結果を生む」というものです（Cognition, 2025-06-12）。彼は、互いの作業を見ずにUIコンポーネントを別々に作ると視覚スタイルが食い違う、という例を挙げ、単一スレッドの線形エージェントを推奨しました。

興味深いのは、両陣営が「共有文脈の欠如こそ失敗要因」という診断では一致している点です。割れているのは処方箋で、Cognition は「避けよ（線形で行け）」、Anthropic や GitHub、Docker は「独立に分割できる探索・検証タスクなら並列が勝つ。ただし文脈共有と検証を設計せよ」という立場です。

補足として、Walden Yan 氏は後に「実際に機能する構成もいくつか見つかった」旨を発信しているとされますが、筆者は一次ポストの全文を取得できず、確証は取れていません（要検証）。

つまり実務上のハマりどころは、相互依存の強い作業を無理に並列化することに集約されます。並列化して勝てるのは、独立に切り出せるタスクに、文脈共有と検証を設計として乗せられたときだけ、というのが現時点での結論です。

実務で回すときの勘所

一次情報から拾える実践知を、筆者なりに整理すると次のようになります。

タスクは「独立性」で切る。相互依存が強い作業は並列化しない。
worktree で隔離する。同じファイルを触るタスクは別チェックアウトに分離する。
仕様（受け入れ基準）ベースでレビューし、逐次マージする。全ブランチを一気にマージしない。
生成と評価を分ける。実装エージェントと独立レビューアを分離し、人間レビュー前に自動反復を挟む。
コストは価値で正当化する。マルチエージェントは15倍のトークンを使う前提で、価値・並列度・コストの釣り合いを事前に見積もる。

エンジニアの役割は、「コードを書く人」から「仕様を書き、作業を分解し、群れの出力を検証・監督する人」へと移っていきます。GitHub は開発者を「チームに仕事を割り振るプロジェクトリード」に喩えていますが、この比喩がフリートエンジニアリングの本質をよく表していると思います。

まとめ

フリートエンジニアリングは、まだ言葉としては固まっていません。エンタープライズのエージェント統治を指す用法と、コーディングエージェントの並列運用を指す用法が並走しています。ただ、後者の実体——オーケストレーター＋サブエージェント、worktree 隔離、生成と評価の分離、human-in-the-loop——は各社の一次情報で確かに動いており、無視できる流行りではありません。

一方で、Cognition の「共有文脈を割るな」という指摘は今も有効な設計制約です。勝ち筋は「独立に分割できるタスク × 文脈共有と検証の設計」。この2つが揃わないなら、まだ1体の線形エージェントで丁寧に進めたほうが速い、というのが誠実な結論だと筆者は考えています。

実際にエージェントの群れを回してみた知見や、うまくいった/いかなかった構成があれば、ぜひコメントで教えてください。

参考

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up