Anthropic Subagent: マルチエージェント時代のアーキテクチャ革命

シングルエージェントが天井に当たるとき

最近Claude CodeやDeep Researchを使ったことがあれば、気づいたかもしれません。これらのツールは以前よりずっと賢くなったように見えます。

それは錯覚ではありません。Anthropicは2025年にマルチエージェントアーキテクチャを静かにローンチし、内部テストでは90%を超えるパフォーマンス向上を示しました。しかし、代償も明らかです——トークン消費量はシングルエージェントの15倍です。

これは興味深い疑問を提起します:なぜマルチエージェントシステムを使うのか?単一のAIでは不十分なのか?

答えは、よく議論されるものの真に致命的な問題にあります:コンテキストウィンドウです。

コンテキスト:AIエージェントのアキレス腱

第一原理に戻りましょう:AIモデルは本質的に関数であり、入力はコンテキスト、出力は応答です。コンテキストには会話履歴、ツール呼び出し結果、外部ドキュメント、中間推論などが含まれます...タスクの複雑さが増すにつれて、コンテキストはどんどん長くなります。

問題が生じます:

1. コンテキストの劣化(Context Rot):コンテキストウィンドウが満杯になると、LLMのパフォーマンスは著しく低下します。ベンダーは200k、500kトークンのサポートを宣伝していますが、実効コンテキストは多くの場合256kトークン未満です。

2. コスト爆発:トークンベースの課金モデルでは、抑制されないコンテキストの成長はコストが線形または超線形に増加することを意味します。

3. 情報ノイズ:AIに複雑なタスク(コードレビューなど)を実行させると、数十のファイルを読み取り、複数のチェックツールを実行する必要があります。これらすべての中間情報がコンテキストに詰め込まれ、簡単な質問をしたいときに、AIは無関係な詳細の山の中で迷子になってしまいます。

これがシングルエージェントが天井に当たる理由です。

Subagent:脳を分割する

Anthropicの答えはシンプルです:1つの脳がすべてを保持できないなら、複数の小さな脳に分割する。

これがSubagent(サブエージェント)の中核的なアイデアです。アーキテクチャは大まかに次のようになります:

ユーザーリクエスト
    ↓
リードエージェント
    ↓ タスク分解
    ├─→ Subagent 1: 関連コードを検索
    ├─→ Subagent 2: セキュリティ脆弱性を分析
    ├─→ Subagent 3: テストカバレッジをチェック
    └─→ Subagent 4: コードスタイルをレビュー
         ↓ 並列実行
    ← ← ← ← 結果を集約
    ↓
リードエージェント統合
    ↓
ユーザーに返す

主要な設計原則

1. タスク分解:リードエージェントが複雑なリクエストを複数のサブタスクに分解
2. 並列実行:複数のSubagentが同時に作業し、それぞれが独自のコンテキストウィンドウを持つ
3. コンテキスト分離:Subagentの作業詳細がリードエージェントのコンテキストを汚染しない
4. 結果圧縮:Subagentは中間プロセス全体ではなく、最も重要な発見のみを返す

実例を挙げましょう。Claude Codeでコードレビューを行っているとします:

• シングルエージェントモード:ファイルA、ファイルB、ファイルCを読み取る...コンテキストはどんどん長くなり、トークン制限のために一部のファイルを放棄する可能性があります。

• マルチエージェントモード:

  • Subagent 1がファイルA-Dを処理し、セキュリティ問題を発見 → 3つの重大な脆弱性を返す
  • Subagent 2がファイルE-Hを処理し、パフォーマンスをチェック → 2つのパフォーマンスボトルネックを返す
  • Subagent 3がテストファイルを処理し、カバレッジを評価 → カバレッジレポートを返す
  • リードエージェントがこれらの圧縮された結果を統合し、完全なレビューを作成

リードエージェントの視点からは、数万トークンの生データではなく、数百トークンの要約のみを受け取ります。

理論から実践へ:Claude CodeのSubagent

Claude Codeユーザーなら、知らないうちにすでにSubagentを使っている可能性があります。

Claude CodeはTaskツールを通じてSubagentを呼び出します。例えば、Claudeに「このプロジェクトの認証フローを調査して」と依頼すると:

1. メインエージェントがリクエストを分析
2. Taskツールを介してExploreタイプのSubagentを起動
3. Subagentがコードベースを探索し、関連ファイルを読み取り、認証ロジックを理解
4. Subagentが要約を返す:「このプロジェクトはJWT + OAuth2を使用、コアロジックはauth/service.ts:120にあり、潜在的なトークンリフレッシュ問題がある」
5. メインエージェントがこの要約に基づいて会話を続ける

このプロセス中、Subagentは20個のファイルを読んだかもしれませんが、メインエージェントのコンテキストは数百トークンしか増加していません。

実践的なヒント

Subagentをより活用したい場合、いくつかのヒントがあります:

1. 明確なサブタスク境界:AIに明確な指示を与える。例えば「Subagentを使ってセキュリティ問題を分析し、別のSubagentでパフォーマンスをチェックする」

2. 並列思考:並列化可能なタスクをリストアップし、複数のSubagentを同時に実行させる。コードレビューが「数分」から「数秒」に短縮される秘訣はここにあります。

3. ツール権限の分離:異なるSubagentは異なるツールアクセス権限を持てます。例えば、セキュリティレビューのSubagentは機密APIにアクセスできますが、コードスタイルチェックのSubagentには不要です。

コストとトレードオフ

これらの利点を述べた後、冷水を浴びせる必要があります:マルチエージェントは万能薬ではありません。

最も直接的な問題はコストです。15倍のトークン消費量は、Claude APIを使用している場合、請求書が急騰することを意味します。

Anthropic自身も認めています:マルチエージェントシステムは結果の価値がコストをはるかに上回るタスクに最適です。

「結果の価値がコストをはるかに上回る」とは何でしょうか?

• ✅ 複雑な技術調査(Deep Research)
• ✅ 大規模コードベースの包括的レビュー
• ✅ 複数のデータソースを必要とする意思決定分析
• ❌ シンプルなコード補完
• ❌ 日常会話
• ❌ 単一ファイルの修正

もう1つの課題はオーケストレーションの複雑さです。以下を設計する必要があります:

• リードエージェントのタスク分解戦略
• Subagentの責任境界
• 結果の集約と重複排除方法
• エラー処理とフォールバックメカニズム

これは単に「マルチエージェントをオンにする」だけでは解決できません——タスクの深い理解が必要です。

マルチエージェントの未来:オーケストレーションパターンの進化

より高いレベルの視点から見ると、AnthropicのSubagentはマルチエージェントオーケストレーションの1つの実装に過ぎません。業界が探求しているオーケストレーションパターンには以下が含まれます:

1. Orchestrator-Workerパターン(Anthropicのアプローチ):中央オーケストレーター + 並列ワーカー
2. Group Chatパターン:共有対話を通じて問題を解決する複数のエージェント
3. 階層的パターン:多層エージェント、上位レベルが下位レベルを監督
4. イベント駆動パターン:イベント駆動のエージェントコラボレーション

各パターンは異なるシナリオに適しています。例えば、Group Chatは「議論」と「討論」を必要とする創造的タスクに適しており、階層的パターンは大規模エンタープライズワークフローに適しています。

Microsoftはまた、異なるプラットフォームのエージェントが安全にコンテキストを共有できるModel Context Protocol(MCP)を推進しています。想像してください:個人AIアシスタントが専門的なコードレビューAI、専門的なデータ分析AIにタスクを委任でき、それぞれが独立したコンテキストと専門知識を持っています。

この方向性は興味深いです:AIエージェントの未来は単独行動ではなく、チームワークです。

最後に

AnthropicのSubagentアーキテクチャは本質的に1つの質問に答えています:単一のコンテキストウィンドウを超える複雑なタスクをAIがどのように処理できるか?

答えは分割統治です:

• リードエージェントを戦略計画に使用
• Subagentを戦術実行に使用
• コンテキスト分離でメイン会話の明瞭性を保護
• 並列実行で効率を向上

これは革命的なイノベーションではありません——ソフトウェアエンジニアリングのマイクロサービス、分散システムの概念をAIに適用することに近いです。しかし、まさにこの「成熟したパラダイムを新しい領域に移行する」アプローチが、マルチエージェントシステムを真に実用的にしました。

もちろん、15倍のコストは冗談ではありません。これは、マルチエージェントが現在「贅沢品」であり、高価値タスクに適していることを意味します。しかし、モデル推論コストが継続的に低下するにつれて(これはほぼ必然的な傾向)、マルチエージェントはますます普及するでしょう。

おそらく近い将来、シングルエージェントを振り返ると、今シングルスレッドプログラムを見るのと同じように感じるでしょう:機能的ですが、なぜ並列にしないのか?

参考資料:

• Anthropic Engineering Blog: Multi-Agent Research System
• Microsoft Learn: AI Agent Orchestration Patterns
• Claude Code Documentation: Subagents
• Industry Research: Context Window Management 2025

関連記事:

• Claude Code拡張性の深掘り
• Cursor vs GitHub Copilot完全比較