コードエージェント・オーケストラ - マルチエージェントコーディングを正しく機能させる方法
(addyosmani.com)- 単一のAIアシスタントと同期ループで協業していた方式から、複数のエージェントがそれぞれのコンテキストウィンドウとファイル範囲を持って非同期に動作するオーケストレーターモデルへの移行が、2026年現在進行中
- サブエージェント(Subagents)、エージェントチーム(Agent Teams)、階層的委任という3つの中核パターンがマルチエージェントコーディングの基本構造を成し、それぞれ並列性・専門化・分離・複合学習という効果を提供
- 共有タスクリストとピアツーピアメッセージングがエージェントチームの中核的な調整メカニズムであり、依存関係の自動解除とボトルネック回避を可能にする
- 2026年時点のツールエコシステムは、インプロセスのサブエージェント(Tier 1)、ローカルオーケストレーター(Tier 2)、クラウド非同期エージェント(Tier 3)の3層に区分され、多くの開発者は3層すべてを用途に応じて混在利用
- ボトルネックはコード生成ではなく**検証(Verification)**へ移っており、プラン承認・フック(Hooks)・AGENTS.mdを通じた品質ゲートと人間のレビューが、マルチエージェント体制の信頼性を決める中核要素
現在の転換: 指揮者からオーケストレーターへ
- 6か月前までは、ほとんどの開発者が単一のAIアシスタントと同期的に作業しており、単一のコンテキストウィンドウが作業の上限だった
- 現在、最も生産性の高い開発者たちは、それぞれのコンテキストウィンドウとファイル範囲、責任領域を持つ複数のエージェントを非同期に調整する方式へ移行している
- コンダクター(Conductor)モデル: 単一エージェントをリアルタイムの同期方式で誘導する; Claude Code CLI、Cursorエディタ内のエージェントモードが代表的なツール
- オーケストレーター(Orchestrator)モデル: それぞれのコンテキストウィンドウを持つ複数のエージェントを非同期に調整する; Agent Teams、Conductor、Codex、Copilot Coding Agentが代表的なツール
- オーケストレーターには、明確な仕様作成、作業分解、成果物検証という新たな能力が求められる
AI支援コーディングの8段階
- [オーケストレーション]
- L8 — 自分専用のオーケストレーター構築: エージェントの生成・ルーティング・管理を直接コードで書くコーディネーションレイヤーを自ら実装
- L7 — エージェント10個以上、手動管理: 「しまった、めちゃくちゃになった。」誤ったコンテキストが誤ったエージェントに渡され、「Claude CodeがClaude Codeを実行したらどうなる？」という疑問が始まる
- L6 — エージェント多重化: 待つのに飽きてエージェントを1つずつ追加で実行し、複数のストリームを行き来して止められなくなる状態
- [エージェント優先]
- L5 — エージェント優先、IDEは後回し: エージェントとの対話が主作業空間で、IDEはコード確認用
- L4 — diffが消え、対話が主導: 毎回diffをレビューせず、エージェントの挙動を観察しながら方向付けに集中
- [IDE時代]
- L3 — YOLOモード: エージェントがIDEで自由に実行され、信頼が高まる
- L2 — IDE内エージェント、権限は手動承認: すべてのファイル変更を直接許可し、完全に手動で制御
- L1 — AIなし: 従来型の開発ワークフロー
- Steve Yeggeが整理したAIツール活用の8段階フレームワークによれば、ほとんどの開発者はレベル3〜4にとどまっている
- オーケストレーション層はレベル6から始まり、レベル5までで培った能力とは根本的に異なるスキルセットを要求する
- ここではレベル5〜8を扱う
単一エージェントの限界
- コンテキスト過負荷: 単一エージェントが保持できる情報量には限界があり、大規模コードベースは単一のコンテキストウィンドウを圧倒する
- 専門化の欠如: データレイヤー、API、UI、テストをすべて処理するエージェントはジェネラリストにすぎず、データレイヤーだけを専任するエージェントのほうがはるかに優れたDBコードを書く
- 調整の欠如: ヘルパーエージェントを追加しても、相互通信・タスク共有・依存関係解決はできず、調整プリミティブなしにエージェントを増やすほど管理難度が上がる
- サブエージェントは最初の2つの問題を、エージェントチームは3つすべての問題を解決する
マルチエージェントが必要な理由
- 並列性 (3倍のスループット): フロントエンド・バックエンド・テストのエージェントが同時に作業
- 専門化 (集中したコンテキスト): 各エージェントは自分が担当するファイルだけを認識;
db.jsだけを知るエージェントは、コードベース全体を扱うエージェントより優れたDBコードを書く - 分離 (安全な実行): Gitワークツリーが各エージェントに独立した作業ディレクトリを提供し、マージ競合がない
- 複合学習:
AGENTS.mdファイルがセッション間でパターンと注意事項を蓄積し、各セッションが次のセッションを改善する - 集中したエージェント3体は、3倍長く作業するジェネラリストエージェント1体よりも一貫して高い成果を出す
パターン1: サブエージェント — 集中した委任
- Taskツールを使って親オーケストレーターから専門化された子エージェントを生成する; 最も単純なマルチエージェントパターンとして、まず試すべき
- 具体例: Claude Codeに「ExpressとSQLiteでブックマークマネージャー Link Shelf を構築せよ」というプロンプトを与えると、親オーケストレーターが3つのサブエージェントブリーフに分解
- データレイヤー・サブエージェント:
db.jsを構築し、その後DATA.mdレポートを作成 - ビジネスロジック・サブエージェント:
validation.jsを構築し、その後LOGIC.mdレポートを作成 - APIルート・サブエージェント:
DATA.mdとLOGIC.mdを読んだ後、server.jsを構築
- データレイヤー・サブエージェント:
- 最初の2つのサブエージェントは独立して並列実行され、3つ目は2つのレポート完了後に開始; 親が依存関係グラフを手動管理する
- サブエージェントの限界: 親が依存関係グラフを手動管理しなければならず、エージェント間のピアメッセージングや共有タスクリストもない; ファイル範囲の管理が緩いと衝突が起こりうる
- 合計約22万トークンで、コストはほぼ中立的な水準
-
階層的サブエージェント (チームの中のチーム)
- オーケストレーターが6つのサブエージェントを直接生成する代わりに、フィーチャーリード2人を生成し、それぞれのフィーチャーリードが自前で専門家を2〜3人生成する構造
- 親オーケストレーターは2エージェントだけを管理するためコンテキストをクリーンに保てる; フィーチャーリードAは「検索機能を構築」というブリーフを受け、自ら分解する
- 実際のエンジニアリング組織の運営方式と同じ原理: VPが個々のエンジニアに直接タスクを割り当てず、テックリードを通じて伝える
パターン2: エージェントチーム — 真の並列実行
- Claude Codeの実験的機能で、
export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1コマンドで有効化 - アーキテクチャは3層:
- チームリード(Team Lead): 作業分解、タスクリスト作成、結果の総合
- 共有タスクリスト: 状態(pending, in_progress, completed, blocked)・依存関係の追跡・ファイルロック
- チームメイト(Teammates): それぞれ独立したClaude Codeインスタンスで、独自のコンテキストウィンドウを持ち、tmuxの分割ペインで実行
- チームメイトは共有リストからタスクを自律的に選択し、ピアツーピアメッセージングで直接連携する(リードを介さない)
- あるチームメイトがタスク完了後に完了表示を行うと、それに依存していたブロック済みタスクが自動的にアンロックされる
Ctrl+Tでタスクリストの視覚的オーバーレイをトグル可能-
エージェントチームの中核メカニズム
- 共有タスクリスト: バックエンド担当が検索APIを完了としてマークすると、ブロックされていたテスト作成タスクが自動でpending状態に切り替わる; ファイルロックで同時編集を防止
- ピアメッセージング: バックエンドエージェントがフロントエンドエージェントへAPI契約を直接伝達 — "GET /search?q= returns [{id,title,url}]"; リードが調整のボトルネックになるのを防ぐ
- チームメイトがアイドル状態になると、リードに自動通知
-
エージェントチームの主要な推奨事項
- チームメイト3〜5人が最適点; トークンコストはチーム規模に比例して線形増加
- プラン承認: チームメイトが実装前にプランを作成すると、リードがレビューして承認または却下; コードが存在する前にアーキテクチャ上の問題を見つける方がはるかに低コスト
- 集中したチームメイト3人の方が、気の散ったチームメイト5人より一貫して優れた成果を出す
-
エージェントチームの信頼性向上のヒント
- ループガードレール + 内省ステップ: すべてのチームメイトに
MAX_ITERATIONS=8の上限を設定; 各再試行前に "何が失敗したのか? どの具体的な変更が修正につながるのか? 同じアプローチを繰り返していないか?" という内省プロンプトを強制 → 行き詰まるエージェントの発生が大幅に減少 - 専任の @reviewer チームメイト: Claude Opus 4.6(読み取り専用)をreviewerに指定し、lint・テスト・セキュリティスキャンツールのみを使用、各TaskCompletedイベントで自動トリガー; ビルダー3〜4人あたりreviewer 1人の比率; リードは常にレビュー完了済みのコードのみを受け取る
- ループガードレール + 内省ステップ: すべてのチームメイトに
パターン3: スケール時のオーケストレーション
- 5個、10個、20個以上のエージェントを複数のリポジトリや機能にまたがって管理するには、専用のオーケストレーションツールが必要
- Tier 1 — インプロセスのサブエージェント・チーム: Claude Codeのサブエージェント・エージェントチーム; 単一のターミナルセッションで、追加ツール不要; まずはここから始める
- Tier 2 — ローカルオーケストレーター: 独立したワークツリーで複数エージェントを実行し、ダッシュボード・diffレビュー・マージ制御を維持; 既知のコードベースで3〜10エージェントに最適; Conductor, Vibe Kanban, Gastown, OpenClaw + Antfarm, Claude Squad, Antigravity, Cursor Background Agents
- Tier 3 — クラウド非同期エージェント: タスクを割り当ててノートPCを閉じ、PRを待つ方式; クラウドVMで実行; Claude Code Web, GitHub Copilot Coding Agent, Jules by Google, Codex Web by OpenAI
- 2026年には、ほとんどの開発者が3つの階層をすべて使うようになる: Tier 1(インタラクティブ作業), Tier 2(並列スプリント), Tier 3(夜間のバックログ処理)
ツールスポットライト
-
Conductor by Melty Labs
- Macでマルチエージェントオーケストレーションを始める最速の方法; それぞれ独立したgitワークツリーで 複数のClaude Code・Codexエージェントを並列実行
- 視覚的ダッシュボードとdiff優先レビューUIを提供; APIコストのみ負担(無料); macOS専用(Apple Silicon・Intel)
- 同一リポジトリで3〜8個の機能を並列開発し、視覚的な監督が必要な場合に最適
-
Claude Code Web
claude.ai/codeからアクセス; 完全なブラウザベースで、ターミナル不要; GitHubリポジトリ接続後にタスク説明を入力 → Anthropic管理のクラウドVMで実行- 途中でのステアリング、自動PR生成、iOSアプリからのアクセスをサポート
- チーム(ターミナル)はエージェントと一緒に作業する方式で、Web(ブラウザ)は委任して席を外れる方式
-
GitHub Copilot Coding Agent
- IDEのCopilotエージェントモード(同期・インタラクティブ)とは別物で、GitHubの Copilot Coding Agentは完全非同期
- すべてのGitHub Issueを
@copilotに割り当てるか、Agentsパネルから開始 → GitHub Actions環境でドラフトPRを生成 - タグ付け前に 自己レビューのループ を実行; Claude Code・Codexなどのサードパーティエージェントにも同じパネルからアクセス可能; Slack、Jira、Linear、Azure Boardsからトリガー可能
-
Jules by Google
- Googleの非同期クラウドコーディングエージェントで、Geminiベース; GitHubリポジトリ接続 → タスク説明 → Julesがプラン生成 → 承認後にクラウドVMで実行 → 完全な推論プロセスとターミナルログを含むPRを返す
- オーディオチェンジログ、途中タスクの中断、GitHub Issueを直接パイプするJules Tools CLIを提供
- リポジトリの
AGENTS.mdを追加設定なしで自動的に読み込む
-
OpenAI Codex Web
- 各タスクはGitHubリポジトリが事前ロードされた 独立したサンドボックスコンテナ で実行
- Web、CLI(オープンソース)、macOSアプリ、IDE拡張機能、GitHub連携をChatGPTアカウントでつなぐサーフェスエコシステムを保有
- 検証可能な証拠(Verifiable Evidence) 機能: すべてのタスクについてターミナルログとテスト出力の引用を返し、実行履歴を監査可能
-
Cursor Cloud Agents + Glass
- Web、デスクトップアプリ、Slack、Linear、GitHub、API、PWA(cursor.com/agents のインストール)からエージェントを起動可能
- Glass: Cursorの新しいインターフェースで、エージェント管理をメイン画面にし、既存エディタは必要時にアクセスする補助ツールへ転換
- エコシステム全体を通じて コントロールプレーンが主要な体験 となり、エディタがその下にある一つの楽器になるというパターンを反映
-
Vibe Kanban
- "doomscrolling gap"(エージェント作業中の2〜5分の空白)を解消; タスクカードを作成し "In Progress" へドラッグすると、それぞれのワークツリー・ブランチを生成
- ボード内でdiffレビューや実行中エージェントへのフィードバック送信が可能; Claude Code, Codex, Gemini CLI, Amp, Cursor Agent CLI などをサポート; クロスプラットフォーム(Mac, Windows, Linux)、無料、BYOK
スケール拡張のためのヒント
-
マルチモデルルーティング
- すべてのタスクに最も高価なモデルが必要なわけではない。
MODEL_ROUTING.mdファイルを作成し、役割ごとにルーティングする:- 計画・アーキテクチャ → 安価な Gemini/Claude/OpenAI モデル
- 実装 → Sonnet、Opus または Codex
- レビュー → 専用のセキュリティモデル
- すべてのタスクに最も高価なモデルが必要なわけではない。
-
worktree ライフサイクルスクリプト
- 3つのシェルエイリアスで反復作業を自動化する:
agent-spin <feature>: worktree + ブランチ作成 + エージェント起動agent-merge <feature>: rebase + レビュー + PR 作成agent-clean: 完了した worktree を削除
- 約12行の bash。Conductor がこれを視覚的に処理する
- 3つのシェルエイリアスで反復作業を自動化する:
-
人間が書いた AGENTS.md のみを許可
- ETH Zurich の Gloaguen らの研究では、LLM が生成した AGENTS.md ファイルには利点がなく、平均で約3%の成功率低下と20%以上の推論コスト増加を引き起こすことが確認された
- 開発者が書いたコンテキストファイルは約4%の性能向上をもたらす
- エージェントが
AGENTS.mdに直接書き込むことは絶対に許可しないこと。リードがすべての行を承認しなければならない - 明確なセクションで簡潔に保つ: STYLE, GOTCHAS, ARCH_DECISIONS, TEST_STRATEGY
品質ゲート: 信頼しつつ検証する
-
3つの品質ゲート
- 計画承認: チームメイトがコーディング開始前に計画を作成 → リードがレビューして承認または却下 → 実装。悪いコードを修正するより、悪い計画を修正するほうがはるかに安い
- フック(Hooks): ライフサイクルイベントに対する自動チェック。
TeammateIdleフックは、エージェントが作業を中断する前にすべてのテストが通るか確認する。TaskCompletedフックは、完了としてマークする前に lint・テストを実行する。フックが失敗した場合、エージェントは通過するまで作業を続ける - AGENTS.md を通じた複合学習: 発見されたパターン・注意点・スタイルの好みを記録する。すべてのエージェントがセッション開始時に読み、各セッションで追記される
-
ボトルネックは検証に移る
- エージェントは驚くべき速度で印象的な出力を生成できる。その出力が正しいと確信することが難しい部分だ
- 変更前に通っていたテストが、その変更による回帰を検出できるとは限らない
- エージェントは技術的には有効でも重要なケースを見落とすテストを書くことがある
- コンテキストウィンドウの限界により、大規模コードベースで作業するエージェントは現在のビューの外にある重要な制約を見落とすことがある
- 単一の開発者にとっては厄介なエッジケースである不安定な環境も、40個のエージェントが同時に同じ不安定なテストに直面すると システム全体のブロッカー になる
- 検証インフラが生成能力に追いつくまでは、人間のレビューは任意の追加コストではなく 安全システム である
Ralph Loop と自己改善エージェント
-
Ralph Loop パターン
- Geoffrey Huntley と Ryan Carson が広めた。「寝ている間に出荷」の背後にあるパターン。Carson の独立ツール
ralph(snarktank/ralph) が中核ループを実装し、Antfarm プロジェクトは OpenClaw 上にマルチエージェントオーケストレーションを追加する - 5段階サイクル: Pick(tasks.json から次のタスクを選択) → Implement(変更を実施) → Validate(テスト・型・lint を実行) → Commit(チェック通過時にコミットし、タスク状態を更新) → Reset(エージェントのコンテキストを初期化してから次のタスクへ)
- 中核的な洞察: 各反復でリセットすることで混乱の蓄積を防げる。小さくスコープが明確なタスクは、1つの巨大なプロンプトより幻覚が少なく、よりクリーンなコードを生成する
- 安全装置: 自動再試行のためにエラーをフィードバックとして渡すが、3回以上デッドロックしたら終了して再割り当てする。常に feature branch で作業する。反復・時間・トークンの上限を設定する。エージェントが PR を作成し、マージ前に人間がレビューする
- コンテキストのリセット間でも4つのメモリチャネルを維持する: git のコミット履歴、進捗ログ、タスク状態ファイル(tasks.json)、長期的な意味記憶としての AGENTS.md
- Geoffrey Huntley と Ryan Carson が広めた。「寝ている間に出荷」の背後にあるパターン。Carson の独立ツール
-
時間とともにエージェントをより賢くする
- REFLECTION.md による自己省察: 各タスク後に「何が意外だったか、AGENTS.md に追加すべきパターン1つ、プロンプト改善1つ」を書くよう強制する。リードがレビューし、承認された学びをマージする
- トークン予算と終了基準: エージェントごとに上限を設定する(例: フロントエンド18万トークン、バックエンド28万トークン)。予算の85%で自動一時停止し、リードに通知する。同じエラーで3回以上デッドロックしたら終了し、新しいエージェントに再割り当てする
- Beads / 永続メモリ: Gastown の「beads」パターン — すべての決定と結果について、完全な出典を持つ不変の git ベース記録。エージェントはタスクグラフと SQL でアドレス可能なデータプレーンを通じて過去の beads を照会する。単純なベクトルベースの RAG ではなく、構造化されクエリ可能な制度的記憶である
これらすべてを機能させる規律
-
人間のボトルネックはバグではなく機能だった
- 人間の速度でコードを書くときは、早い段階で痛みを感じる。テスト失敗、コードレビューでの指摘、重複の発見 — 痛みが即座に現れるため、進めながら修正する
- オーケストレーションされたエージェント群では自然なボトルネックがない。小さなミス(コードスメル、重複、不要な抽象化)が、追いつけない速度で複合的に増幅される
- ループから外れた状態なので、アーキテクチャが新機能を受け入れられなくなるまで痛みを感じない
- すべての品質ゲート(計画承認、フック、トークン予算、人間レビュー) が存在する理由はこれであり、これがないとエージェントコーディングで自らを袋小路に追い込むことになる
-
タスクは委任し、判断は手元に残す
- エージェントに任せるべきもの: 合格/不合格の基準が明確なスコープのはっきりしたタスク、ボイラープレート、マイグレーション、テストスキャフォールディング、自分で試す時間がないアプローチの探索
- 自分で持つべきもの: アーキテクチャと API 設計(エージェントは学習データから多くの悪いアーキテクチャを学んでおり、エンタープライズパターンをスタートアップにそのまま適用する可能性がある)、何を作らないかを決めること(No と言うのはエージェントにない機能)、システム全体のコンテキストを踏まえたエージェント出力のレビュー
- 自分のシステムへの理解を失うと、修正・拡張・誤作動の検知能力も失う
-
仕様がレバレッジになる
- 50体のエージェントを並列でオーケストレーションするとき、曖昧な思考は単に速度を落とすだけでなく、数十件の並列実行全体に増幅 される
- 平凡な出力と卓越した出力の差は、ほぼ完全に 仕様の品質 に依存する
- 曖昧な仕様はフリート全体にエラーを増幅させる。明確なアーキテクチャ・統合境界・エッジケース・不変条件を備えた精密な仕様は、全体にわたる精密な実装へと増幅される
- コードを打ち込む機械的作業は自動化されつつある。システムを理解する認知的作業は、自律的に働くワーカーフリート全体にわたって 増幅 される
ファクトリーモデル
- もはや単にコードを書くのではなく、ソフトウェアを作る工場を構築する段階 にある
- 6段階の生産ライン: Plan(受け入れ基準のある仕様を書く) → Spawn(チームを作成してエージェントを割り当てる) → Monitor(5〜10分ごとに進捗を確認し、ブロッカーを解消する。張り付き監視はしない) → Verify(テスト実行・コードレビュー。ボトルネックは検証) → Integrate(ブランチをマージし、衝突を解消) → Retro(新しいパターンで AGENTS.md を更新。複合学習)
- 実用的なヒント:
- WIP 制限を設定する: 意味のあるレビューができる量を超えてエージェントを走らせないこと。3〜5個が最適点
- 終了基準を定義する: 同じエラーで3回以上デッドロックしたら中断して再割り当てする
- 非同期チェックイン: 5〜10分ごとに進捗を確認する。エージェントには自律的に作業させること
- 1ファイルに1オーナー: 2つのエージェントが同じファイルを編集しないようにする。衝突は速度を殺す
今日から始める5つのパターン
- サブエージェントに分解: Task ツールで、特定のブリーフとファイル所有権を持つ集中型の子エージェントを作成。設定は不要。今日から開始可能
- エージェントチームで並列化:
CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1を有効化。リード + メンバー3人を作成し、共有タスクリストで調整 - Git ワークツリーで分離: 各エージェントに専用のワークツリーを提供。マージ競合なし。Conductor が自動処理
- 信頼のための品質ゲート: リスクの高い変更にはプラン承認を要求。タスク完了時にテストを実行するフックを追加。検証なしでエージェントの出力を信用しない
- AGENTS.md で複合学習: パターン・注意点・スタイルの好みを文書化。各セッションで読み込みと更新を行い、知識を複合的に増幅
2件のコメント
エンジニアの特性なのか、なぜもっともらしい話を中身もなく延々と並べ立てるのか分かりません。私も関心のあるテーマだったので詳しく読んでみましたが、中身はありませんでした。
はぁ、Clcoを使う究極の理由――マルチエージェントで自分だけのオーケストレーション。
今5つのエージェントを運用中だけど、トークンがめちゃくちゃ速く消えていくので泣ける。