技術 約9分で読めます

Claude Codeマルチエージェントレビューから見る、サブエージェントとオーケストレーションの違い

AI Claude コードレビュー DevTools AIエージェント

AnthropicがClaude Codeのリサーチプレビューとして、マルチエージェント構成による自動コードレビュー機能を公開した。PRがオープンされると複数のエージェントが並列動作し、バグを検出して重要度でランク付けしてからGitHubにコメントとして投稿する。

なぜ「マルチエージェント」か

従来の自動コードレビューツールは、静的解析ルールや単一モデルの1パス読み込みに依存していた。Claude Codeの実装は異なる。

PRが届くと複数のエージェントが並列で動き、それぞれ独立してバグを探す。各エージェントが見つけた問題を他エージェントが検証して誤検知を除去し、重要度でランク付けした上で概要コメントとインラインコメントの両形式で提示する。

設計上の判断として「深さを速度より優先」している。Anthropicが既に公開しているオープンソースのGitHub Actionより詳細なレビューを行う代わりに、平均レビュー時間は約20分かかる。

内部での実運用数値

Anthropicが社内で実運用した結果が公開されている。

PR規模検出対象割合平均検出件数
1000行以上84%7.5件
50行未満31%0.5件

検出精度については「99%以上が正確」と報告している。誤検知が少ない背景には、エージェントの検証フェーズが機能している。

導入前後でコードレビューカバー率が大きく変わった。全PRに対してレビューが行われた割合は、導入前16%から導入後54%に上昇している。小規模チームや、PRが多量に来るオープンソースプロジェクトでこの差は大きい。

実際に検出されたバグの例

Anthropicが公開している具体例が2つある。

1つ目は、見た目には些細な1行変更だったが認証機能を破壊する重大バグ。コード量が少ないため人間がレビューをスキップしがちな変更で、これを検出した。

2つ目はTrueNASプロジェクトの事例。PRが変更した行そのものではなく、変更によって接触した隣接コードの型不一致を発見した。暗号化キーのキャッシュがリクエストごとに消去されてしまうバグで、変更差分だけを見ていると見落とす種類の問題だった。

コストと管理機能

PR規模と複雑度によって1レビューあたり15〜25ドルかかる。トークン消費量ベースの課金なので、変更行数が多いほど高くなる。

管理機能としては月間支出上限の設定、リポジトリ単位での有効化制御、コストと採用率を確認できる分析ダッシュボードが用意されている。

導入手順はシンプルで、管理者がClaude Code設定からGitHub Appをインストールして対象リポジトリを選択する。開発者側は追加設定なしで、PRを開くと自動的にレビューが走る。

利用条件

Team および Enterprise プランで研究プレビューとして利用可能。個人プランは対象外。

現時点での位置づけはあくまでリサーチプレビューで、精度や機能は継続的に改善される予定。コスト面での懸念があれば、まず小規模なリポジトリや特定チームに限定して試す運用が現実的だろう。

サブエージェントとオーケストレーションは何が違うのか

このPRレビュー機能に限らず、2026年に入ってから「マルチエージェント」という言葉がAIコーディングツール全般で飛び交っている。ただし同じ「マルチエージェント」でも、内部のアーキテクチャはツールによってまったく違う。大きく分けると「サブエージェント型」と「オーケストレーション型」の2系統がある。

サブエージェント型

親エージェントが子エージェントを生成し、子は自分のコンテキストウィンドウ内で独立に動く。親は子の最終出力だけを受け取り、子の推論過程は見えない。Claude Codeの設計がまさにこれで、メインエージェントがExploreやPlanといった専門サブエージェントをMarkdownファイルで定義し、必要に応じて起動する。

特徴は単純さ。親子間のインターフェースは「タスク指示→結果返却」のみで、エージェント間の通信プロトコルを設計する必要がない。Anthropicの報告では、Claude Opus 4をリードにSonnet 4をサブエージェントとして使う構成で、Opus 4単体比で90.2%のパフォーマンス向上が出ている。

graph TD
    A[メインエージェント] -->|タスク指示| B[サブエージェント A<br/>Explore: 読み取り専用]
    A -->|タスク指示| C[サブエージェント B<br/>Plan: 設計特化]
    A -->|タスク指示| D[サブエージェント C<br/>汎用: 編集可能]
    B -->|結果のみ| A
    C -->|結果のみ| A
    D -->|結果のみ| A

オーケストレーション型

中央のオーケストレーターがワークフロー全体をグラフやステートマシンとして管理し、エージェント間の状態共有・メッセージパッシングを制御する。LangGraphやCrewAIがこちら。

サブエージェント型との最大の違いは、エージェント間が共有状態を持てること。LangGraphなら共有ステートオブジェクト、CrewAIなら短期・長期・エンティティの3種のメモリをエージェント間で参照できる。その代わり、ワークフローの構造は開発者が事前に定義する必要がある。

観点サブエージェント型オーケストレーション型
状態共有なし。子は親の最終出力のみ受け取るあり。共有ステートやメモリ経由
ワークフロー定義不要。親が動的に子を生成必要。グラフや役割を事前設計
エージェント間通信親子間の一方向のみ双方向。ハンドオフやメッセージング
向いている用途並列探索、独立した専門タスク複雑なステップ間依存のあるワークフロー
コンテキスト管理各エージェントが隔離共有による汚染リスクあり

Claude Codeの PRレビュー機能がサブエージェント型を選んでいるのは合理的だ。コードレビューは「探す→検証する→報告する」の独立したフェーズに分割でき、フェーズ間で共有すべき状態が少ない。各エージェントが見つけたバグリストを最後に集約すれば十分で、途中で他のエージェントの推論過程を参照する必要がない。

主要マルチエージェントフレームワークの現状

以前の記事でClawsとCordを取り上げたが、そこで名前を挙げたフレームワーク群もその後動きがあった。

OpenAI Agents SDK

2024年のSwarmは教育目的の実験的フレームワークだったが、2025年3月にプロダクション向けのAgents SDKに置き換わった。2025年10月のDevDayではビジュアル開発ツールとエンタープライズ機能を追加するAgentKitも発表されている。

中心となるプリミティブは3つ: Agent（エージェント定義）、Handoff（エージェント間の制御委譲）、Guardrails（入出力バリデーション）。「Handoff」はOpenAI独自の用語で、あるエージェントが別のエージェントに明示的に制御を渡す操作を指す。サブエージェント型の「結果を返して終わり」とは異なり、制御フロー自体が移動する。

Microsoft AutoGen → Microsoft Agent Framework

AutoGenは2025年1月にv0.4で完全に非同期・イベント駆動に書き直された。ただしMicrosoftはAutoGenとSemantic Kernelを統合した「Microsoft Agent Framework」を発表し、AutoGenは今後クリティカルなバグ修正のみの対応になる。

一方でAutoGenからフォークしたコミュニティ版AG2が2024年11月に分岐しており、こちらは独自路線で開発が続いている。エージェント間を会話として扱う設計は柔軟だが、合意形成のオーバーヘッドでレイテンシが最も大きいフレームワークでもある。

CrewAI

LangChainに依存しない独立したPythonフレームワーク。GitHub 20,000スター超、認定開発者10万人以上。

Crews（自律エージェントチーム）とFlows（イベント駆動オーケストレーション）の二層構造で、同等のワークフローをLangGraphより2〜3倍速く実行できるとされる。100以上の組み込みツールと計画エージェントを内蔵しており、プロダクション投入までの時間はLangGraphの60%程度という報告もある。

LangGraph

ワークフローをノードとエッジの有向グラフで表現する。PyPIダウンロード数4,700万以上で、エコシステムの規模は最大。

最大の差別化ポイントはチェックポイント機能で、ワークフローを途中で一時停止し、環境をまたいで再開できる。長時間実行のワークフローやhuman-in-the-loopが必要なケースに強い。ただしグラフ定義の設計コストが高く、シンプルなタスクには過剰になりがち。

Google ADK + A2Aプロトコル

GoogleのAgent Development Kitはコードファースト、Gemini最適化だがモデル非依存のツールキット。注目すべきはA2A（Agent-to-Agent）プロトコルで、2025年4月に公開されたオープン標準。異なるフレームワーク（ADK、LangGraph、CrewAI等）で構築されたエージェント同士を相互接続できる。フレームワーク戦争の先にある「異種エージェント間通信」の標準化を狙っている。

Codex CLIとの組み合わせ

OpenAIのCodex CLIはMCPサーバーとして公開でき、codex() と codex-reply() の2ツールを外部から呼べる。つまりAgents SDKで組んだオーケストレーションの1ノードとしてCodex CLIを配置したり、Claude CodeからMCP経由でCodexを呼び出す構成が可能になる。

実際、tmuxでClaude CodeとCodexを連携させる構成は以前試した。あのときはtmuxのセッション管理で擬似的に連携させたが、MCP経由なら各エージェントのコンテキストを隔離したまま協調できる。

Claude CodeがPRのバグを検出し、修正案の生成をCodexに委譲する、あるいはその逆といった構成も技術的には組める。ただし現実的にはモデル間の出力品質の差やコンテキストの受け渡しロスがあるので、同一モデルファミリ内でサブエージェントを増やすほうが安定する場面のほうが多い。

2026年2月にはCodex App Serverアーキテクチャも公開され、CLI・VS Code拡張・Webアプリ間で統一的にマルチエージェントワークフローを実行できるようになった。

Claude Codeのサブエージェント実装の詳細

Claude Codeのサブエージェントは、YAMLフロントマター付きのMarkdownファイルで定義される。各サブエージェントが持つのは以下の3つ。

  • 独立したコンテキストウィンドウ
  • カスタムシステムプロンプト
  • ツール権限（読み取り専用 or フルアクセス）

v2.1.19以降ではTeammateTool / Agent Teamsという上位機構も導入されている。従来のサブエージェントは親→子の一方向通信だったが、Agent Teamsではエージェント同士がディスク上のJSONインボックス（~/.claude/<teamName>/inboxes/<agentName>.json）を介してダイレクトメッセージを送り合える。共有タスクリストからタスクを取り合う仕組みもあり、サブエージェント型の単純さを維持しつつオーケストレーション型の柔軟さに近づいている。

graph TD
    subgraph サブエージェント型（従来）
        P1[親エージェント] -->|指示| C1[子A]
        P1 -->|指示| C2[子B]
        C1 -->|結果| P1
        C2 -->|結果| P1
    end

    subgraph Agent Teams（v2.1.19〜）
        L[リーダー] -->|タスク割当| T1[チームメイトA]
        L -->|タスク割当| T2[チームメイトB]
        T1 <-->|JSON inbox| T2
        T1 -->|結果| L
        T2 -->|結果| L
    end

ファイルシステムベースの通信というのは泥臭いが、OSプロセスとして各エージェントを分離できるため、クラッシュ耐性がある。tmuxベースのスポーン実行にも対応しており、ターミナル上で複数のClaude Codeインスタンスが協調して動く姿が実際に見られる。

オーケストレーションフレームワークがインメモリのメッセージパッシングやイベントバスを使うのに対して、Claude Codeはファイルシステムという最もプリミティブなIPCに寄せている。サーバーレス・クラウドネイティブ志向のフレームワーク群とは正反対のアプローチだが、ローカル開発環境での実用性は高い。