16台のClaude Opus 4.6が並列稼働し、約2,000セッション、2万ドルのAPI費用をかけて、10万行のCコンパイラをゼロから自律的に構築した。GCCのトーチャーテストの99%をパスし、Linux 6.9のカーネルコンパイルにも成功。Anthropic CEOのDario Amodeiは「社内コードの90%以上がAIエージェントによって書かれている」と公言し、GitHubの公開コミットの4%がすでにClaude Codeによるものだという分析もある。
AIエージェントの「量」が開発を根本から変える — そう期待したくなる数字が並ぶ。
しかし、The Registerの批判的レビューはこのコンパイラの別の側面を照らし出した。手動でライブラリパスを指定しなければHello Worldすらコンパイルできない。GCCのアセンブラとリンカに依存しており、自立的なコンパイラとは言い難い。生成コードの効率はGCCの全最適化を無効にした場合よりも劣る。Rustで書かれたコード品質はエキスパートが書くものには遠く及ばない。
10万行を「自動生成できる力」と「GCCに依存する脆さ」。この両面にこそ、マルチエージェント開発の本質が宿っている。
1. エージェントチームとは何か — アーキテクチャの全体像
Claude Codeのエージェントチーム機能は、環境変数 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 で有効化される実験的機能だ。複数のClaude Codeインスタンスが「チーム」として協調動作する仕組みで、アーキテクチャは以下のように構成される。
チームリーダー1台 + チームメンバー複数台。各メンバーは独立したClaude Codeセッションとして起動し、それぞれが独自のコンテキストウィンドウを持つ。通信は ~/.claude/teams/{team-name}/inboxes/ 配下のJSONファイルを介したピアツーピア方式。エージェントが sendMessage を呼ぶとインボックスにメッセージが記録され、他のエージェントがこれを監視・取得する。共有タスクリストにはpending/in_progress/completedの3状態があり、タスク間の依存関係を管理する。ブロッキングタスクが完了すれば、依存タスクが自動で解除される。
表示モードはin-process（デフォルト）とsplit panes（tmux/iTerm2使用）の2種類。リーダーを調整・指示のみに限定するデリゲートモードや、チームメンバーが実装前にプランを提出して承認を受けるプラン承認機能も備える。
サブエージェント（従来のTask機能）との違いを整理する。
| 項目 | サブエージェント | エージェントチーム |
|---|---|---|
| コンテキスト | 親セッション内で動作 | 独立したコンテキストウィンドウ |
| 通信 | 結果を親に返すのみ | メンバー間の直接通信が可能 |
| 調整 | 親エージェントが仲介 | 自己調整・自律協調 |
| コスト | 相対的に低い | 各インスタンスが個別課金 |
| 用途 | 集中的・単発タスク | 複雑な協調作業 |
この機能の誕生経緯自体が興味深い。2026年1月24日、開発者Mike Kellyがフィーチャーフラグの裏に隠された「Swarms」機能を発見し、claude-sneakpeekというツールで解放した。このニュースはHacker Newsで281ポイント・207コメントを獲得。コミュニティが独自にtmuxベースの並列実行パターンを構築し、OpenClawなどのオーケストレーションツールを開発した。こうしたユーザー主導のイノベーションが十分に成熟したことを受け、2月5日にClaude Opus 4.6と同時に正式発表された。コミュニティの実践が公式機能化を後押しした、稀有な事例だ。
2. なぜマルチエージェントが必要なのか — 単一エージェントの構造的限界
エージェントチームの背景には、単一エージェントが抱える構造的な限界がある。
コンテキストウィンドウの汚染問題。 Google ChromeのエンジニアリングマネージャーAddy Osmaniは、LLMの性能がコンテキストの拡大に伴って低下するメカニズムを分析している。CSSのバグ修正に取り組んでいるコンテキストに、PMの戦略メモやインフラのログが混入すると、性能は「受動的に薄まる」のではなく「能動的に悪化する」。無関係な情報がモデルの注意を分散させ、関連する情報の重み付けを歪めるためだ。エージェントチームでは各メンバーが独立したコンテキストウィンドウを持つことで、この汚染を構造的に回避できる。
逐次処理とアンカリングバイアス。 単一エージェントによるデバッグでは、最初に立てた仮説に引きずられるアンカリングバイアスが生じやすい。エージェントチームでは複数のエージェントが異なる仮説を並列で検証できるため、対抗的な議論構造が自然に形成される。フロントエンド・バックエンド・テストの各レイヤーを別々のエージェントに割り当てれば、コンテキスト切り替えのコストも消える。
市場もこの方向を追認している。AI Code Assistant市場は2025年の47億ドルから2033年には146億ドルに成長する見通しだ（SNS Insider）。開発者の82%がAIコーディングツールを日常的に使用し、AIが生成・補助したコードの割合は41%に達している（Panto AI）。単一エージェントの限界を超える手段への需要は、確実に存在する。
この構造的利点は理論的には正しい。だが、実際にスケールさせたとき何が起きるか。次のセクションでは、理論と実践の間に横たわるギャップを直視する。
3. 冷水を浴びせるデータ — マルチエージェントの不都合な真実
「AIを増やせば生産性が上がる」。この素朴な期待を、複数の研究が明確に否定している。
Google DeepMindの制御実験。 180件の制御実験から得られた結果は厳しい。逐次的な推論を要するタスク（PlanCraftベンチマーク）で、マルチエージェント構成のすべてのバリアントが単一エージェントに対して39〜70%のパフォーマンス低下を記録した。Claude自身をマルチエージェント構成にした場合でも35%低下。さらに、エージェントに100回のツール呼び出し予算を与えた場合、実際に使用されたのは平均14.24回の検索と1.36回のブラウジングのみ。リソースの85%は未使用のまま放置された。予算を2倍にしても精度向上はわずか0.2ポイント。トークンとツール呼び出しの大半は、問題解決ではなく自己定位と調整に消費されている。
人月の神話、再び。 Fred Brooksが1975年に示した「9人の妊婦を集めても1ヶ月で赤ちゃんは生まれない」という原則は、AIにも等しく適用される。Cコンパイラ実験自体がこれを実証した。独立したテストケースが多数存在するフェーズでは16エージェントの並列化が有効に機能したが、Linuxカーネルコンパイルという分解不可能な単一タスクに到達した途端、エージェントは同じバグに集中して効率が低下した。並列化の効果はタスクの分解可能性に完全に依存する。
トークンコスト爆発。 各チームメンバーが独自のコンテキストウィンドウを持つため、消費は線形どころか指数関数的に増大しうる。887,000トークン/分の消費速度が報告された事例がある。企業チームの報告では、コストは予想の300〜500%に達する。エージェントチームの計画モード実行時、標準セッション比で約7倍のトークンを消費する。
調整オーバーヘッド。 OpenReviewの研究は、主要マルチエージェントフレームワークにおけるトークン重複による非効率性が53〜86%に達することを示した。エージェントが増えるほど、実際の問題解決ではなく「互いの状態を把握する」ためにリソースが費やされる。
ハルシネーションの連鎖。 単一エージェントのハルシネーションは局所的だが、マルチエージェント構成ではエラーが増幅される。研究が示すエラー増幅係数は17.2。直感的に言えば、1つのエージェントが95%正確であっても、3つのエージェントが多数決で合意すると、特定の条件下で正解率が14%まで落ちうる。複数のAIが同じ間違いに「合意」することで、誤った回答への確信度が上がるためだ。単体では低確率のエラーが、複数のAIの「集合知」として増幅されるという逆説がここにある。
Cognitionの明確な反論。 Devinを開発するCognitionは「Don't Build Multi-Agents」と題したブログで、マルチエージェント構成を名指しで批判した。「サブタスクエージェントはメインエージェントからのコンテキストを欠いており、明確に定義された質問に答える以上のことはできない」。2025〜2026年時点では、単一エージェントに強力なコンテキストエンジニアリングを施すアプローチの方が優位だという主張だ。
Cコンパイラの再評価。 The Registerのレビューに立ち戻ると、GCCのアセンブラ・リンカへの依存、GCC最適化無効版以下の生成コード効率、エキスパートに遠く及ばないRustコード品質 — これらの事実は、「10万行の自動生成」という数字の印象とは異なる像を結ぶ。人間が精巧なテストスイートと実行ハーネスを事前に構築しており、完全自律でもない。コンピュータサイエンスの学部生が毎学期Cコンパイラを書いていることを考えれば — もちろん教育用の簡易コンパイラとGCCテスト互換の本格的コンパイラではスコープが大きく異なるが — 2万ドルのコスト妥当性には検討の余地がある。
4. では、どう使うべきか — 階層的ハイブリッドという解
批判データの山を前にして、結論を「マルチエージェントは使うな」とするのは早計だ。問題は「使うか否か」ではなく「どう組織するか」にある。これは技術選定の問題ではなく、組織設計の問題だ。
UC Berkeleyが306人の実務者を対象に行った調査が、この方向を裏付ける。本番稼働に成功しているAIエージェントシステムの80%が、自律的な計画ではなく人間が設計した構造化ワークフローを使用していた。68%がエージェントのステップ数を10以下に制限している。批判データが示す「マルチエージェントの限界」は、裏を返せば「設計の重要性」を証明している。
マルチエージェント判定フロー
具体的な判断基準を示す。
Step 1: タスクは独立した部分に分解可能か？
No → 単一エージェントを使う。逐次的な推論が必要なタスク（複雑なアルゴリズム設計、密結合なリファクタリング）は、マルチエージェントで39〜70%劣化するというDeepMindのデータを思い出すべきだ。
Step 2: 分解した部分は異なるファイル/ディレクトリを編集するか？
No → サブエージェント（Task機能）で十分。同一ファイルへの同時編集は公式ドキュメントが認める競合リスクを伴う。
Step 3: エージェント間の議論・相互レビューが価値を生むか？
Yes → エージェントチームの出番だ。異なるレイヤー（フロントエンド/バックエンド/テスト）の並列開発、対抗的なデバッグ仮説の検証、設計レビューの多角的評価。これらのシナリオでは、独立コンテキストと直接通信の組み合わせが力を発揮する。
コスト損益分岐の目安
3エージェント並列でトークン消費は約2〜3倍になる。一方、独立性の高いタスクであれば所要時間は1/2〜1/3に短縮できる。損益分岐は「並列化によって削減される開発者の時間単価」と「追加トークンコスト」の比較で決まる。1時間あたり5,000〜10,000円の開発者コストを前提にすれば、3エージェントで2時間短縮する場合、追加トークン代の1万〜2万円は十分にペイする。ただし、この計算はタスクの独立性が高い場合にのみ成立する。
実践パターン
最もROIが高い運用パターンは以下の4ステップだ。
- Plan modeで設計（安価・約1万トークン）— タスク分解の骨格を作る
- 人間がタスク分解を検証 — 依存関係の見落とし、ファイル競合の可能性を精査
- チームに分散実行（高価だが高速）— 検証済みのタスクリストに基づいて並列処理
- 人間がレビュー・統合 — AI生成コードの品質チェックと最終的な設計判断
このパターンの核心は、「高価なフェーズ（実行）の前に安価なフェーズ（設計）で品質を担保する」という非対称な投資構造にある。
競合との位置づけ
エージェントチームの立ち位置を競合と比較して明確にしておく。GitHub Agent HQはClaude、Codex、Copilotを統合するマルチエージェントプラットフォームで、ベンダーロックインを避けたい組織に適する。OpenAI Codexはネットワーク無効のコンテナで実行する完全隔離型で、セキュリティ要件の厳しい環境に向く。Devinは単一の強力なエージェントにコンテキストエンジニアリングを施すアプローチで、Cognitionの「マルチエージェントを作るな」宣言と一貫している。Claude Codeエージェントチームの差別化要因は、開発者のローカル環境でネイティブに動作し、既存のCLIワークフローとシームレスに統合される点にある。
5. 「オーケストレーター」としての開発者 — これからの専門性
Cコンパイラ実験でNicholas Carliniが見せた役割は、従来の「コーダー」とは根本的に異なるものだった。コードを書いたのは16台のAIエージェントだ。Carliniが行ったのは、問題の分解、テストスイートの設計、GCCを「オラクル」として使う戦略の構築、そして16台のエージェントが同じバグに集中する非効率を解消するための再編成。これは「オーケストレーター」としての仕事だ。
Dario Amodeiは「AIは6〜12ヶ月以内にソフトウェアエンジニアのほぼすべての仕事をエンドツーエンドで引き継ぐだろう」と語った。この予測が正しいか否かに関わらず、開発者に求められるスキルセットが変容していることは明白だ。
オーケストレーターに求められる4つのスキル
タスク分解能力。 どの粒度でタスクを分割すべきか。粒度が粗すぎればエージェントが行き詰まり、細かすぎれば調整オーバーヘッドが爆発する。UC Berkeleyの調査が示す「ステップ数10以下」という経験則は一つの目安だが、本質は「各サブタスクが独立してテスト可能か」という判断にある。
コンテキスト設計力。 各エージェントに何を見せ、何を見せないか。Addy Osmaniが指摘するように、コンテキストの汚染はモデル性能を「能動的に悪化」させる。AGENTS.mdの設計、ディレクトリレベルの所有権設定、必要最小限のコンテキスト注入 — これらはプロンプトエンジニアリングを超えた、情報アーキテクチャの設計能力だ。
品質検証のメタスキル。 AI生成コードを効率的にレビューする手法の確立。10万行のコードを逐一読むのは非現実的だ。重要なのは、テストカバレッジの戦略的設計、エッジケースの体系的な洗い出し、そして「AIが自信を持って間違える」パターンの認識。エラー増幅係数17.2という数字が意味するのは、「複数のAIが合意した結論ほど慎重に検証せよ」という逆説だ。
コスト感覚。 トークン消費の見積もり・監視能力。887,000トークン/分という異常値を事前に予測するのは困難でも、Plan modeでの設計フェーズでおおよその規模感を掴み、実行フェーズでリアルタイムに監視する習慣は必須になる。「2025年の開発者の問いは『どのツールが最も賢いか？』だった。2026年は『どのツールがクレジットを燃やさないか？』になった」というコミュニティの声は、この変化を端的に表現している。
不安を感じるのは正しい
Cコンパイラを構築したCarlini自身が、元ペネトレーションテスターとして「プログラマーが自ら検証していないソフトウェアをデプロイする」未来に「不安を感じる」と述べている。作った本人が不安を覚えるという事実を、軽く見るべきではない。
Klarnaの事例はこの不安に具体性を与える。AI導入で人員削減を行ったKlarnaのCEOは、AIが「人間スタッフより低品質な仕事を提供した」と認め、人間の再雇用を開始した。単一エージェントですら品質管理が困難な現状で、マルチエージェント構成はその課題を乗算する。
Amodeiの「90%以上のコードがAI生成」という主張が正しいなら、開発者が今後12ヶ月で学ぶべきは「コードの書き方」ではない。AIが書いたコードの検証方法、AIチームの組織設計、そして「何をAIに任せないか」の判断基準だ。
結論 — 10万行の力と、GCCに依存する脆さの間で
冒頭のCコンパイラに立ち戻る。
16台のAIエージェントが自律的に10万行のコードを生成し、GCCトーチャーテストの99%をパスした。これは紛れもない技術的達成だ。同時にそのコンパイラは、GCCのアセンブラとリンカなしには動作せず、生成コードの効率は最適化を全て切ったGCC以下であり、Rustコードの品質はエキスパートの水準に達していない。
この二重性こそが、マルチエージェント開発の現在地を正確に映し出している。「AIの数を増やせば生産性が上がる」という素朴な期待は、DeepMindの39〜70%低下データ、エラー増幅係数17.2、トークン消費の300〜500%超過によって明確に否定された。だが同時に、適切に設計された構造化ワークフローの中でマルチエージェントを運用すれば、独立性の高いタスクの並列処理で実証された価値がある。
開発者に突きつけられているのは、「AIを使うか否か」の二択ではない。「複数のAIをどう組織し、何を任せ、何を任せないかを設計する能力」こそが、これからの専門性になるという現実だ。
まずは小さく始めることを推奨する。Plan modeで1つのタスクを分解し、2〜3台のエージェントで並列実行する。トークン消費を観測し、単一エージェントとのコスト・品質を比較する。そしてその結果を — 成功も失敗も — コミュニティに共有する。フィーチャーフラグの裏に隠された機能をコミュニティが掘り起こし、公式機能化を推進したように、この技術の「正しい使い方」もまた、実践者たちの手で形成されていく。
参考資料
ソース（公式）
- Anthropic Engineering Blog — Building a C Compiler
- Claude Code公式ドキュメント — Agent Teams
- Cognition — Don't Build Multi-Agents
レビュー・分析
- The Register — Anthropic's AI-built C compiler
- Google DeepMind — Towards a Science of Scaling Agent Systems
- ImagineX — UC Berkeley 306人調査
技術分析
- Addy Osmani — Claude Code Agent Teams
- alexop.dev — From Tasks to Swarms
- paddo.dev — Claude Code's Hidden Multi-Agent System
コスト・市場データ
- SNS Insider / Yahoo Finance — AI Code Assistant Market
- Panto AI — AI Coding Assistant Statistics
- WebProNews — Claude Code's Hidden Cost Problem
- SaaStr — Anthropic $14B ARR
- Constellation Research — Claude Code Revenue