単一のAIに全部やらせようとすると、必ずどこかで詰まる。コンテキストが枯渇する、直列処理で待ち時間が長い、複雑なタスクで出力品質が落ちる。こうした問題をマルチエージェント構成で解決するのが、今のClaude Codeの使い方として理にかなっている。
この記事では、Claude Codeのマルチエージェント機能を実際のプロジェクトで使える形に落とし込んだパターンを3つ紹介する。
なぜマルチエージェントか
単一AIの限界
Claude Codeのコンテキストウィンドウは大きいが、有限だ。大型リファクタリングや複数ファイルにまたがる調査をやらせると、会話が長くなるにつれて初期情報が圧迫され、出力品質が下がっていく。
また、「フロントエンドのコード生成」「バックエンドのAPI設計」「テストコードの作成」を順番にやらせると、単純に3倍の時間がかかる。これらに依存関係がなければ、並列に走らせればいい。
マルチエージェントで解決できること
| 課題 | 解決策 |
|---|---|
| コンテキスト枯渇 | 各エージェントに独立したスコープを持たせる |
| 直列処理の遅さ | 依存関係のないタスクを並列実行 |
| 出力品質のばらつき | 役割特化のエージェントに専門タスクを割り当て |
Claude Codeのエージェント起動方法
Taskツールでサブエージェント起動
Claude CodeにはTaskツールが組み込まれており、サブエージェントを起動できる。CLAUDE.mdやプロンプトでオーケストレーターに指示を与えると、Taskツールを使って複数のエージェントを立ち上げられる。
# オーケストレーターが複数タスクを並列起動するイメージ
tasks = [
{"task": "フロントエンドのReactコンポーネントを生成", "model": "claude-sonnet-4-5"},
{"task": "バックエンドのFastAPI実装を生成", "model": "claude-sonnet-4-5"},
{"task": "pytest単体テストを生成", "model": "claude-sonnet-4-5"},
]
モデル選択の使い分け
コストと品質を両立させるには、役割に応じてモデルを使い分けるのが鉄則だ。
| モデル | 役割 | 使い所 |
|---|---|---|
| Opus | オーケストレーター | タスク分解・設計判断・最終統合 |
| Sonnet | ワーカー（標準） | 調査・実装・コードレビュー |
| Haiku | ワーカー（軽量） | ファイル検索・grep・単純な変換 |
「全部Opusで動かせばいいじゃないか」と思うかもしれないが、それだとコストが3〜5倍になる。Opusはオーケストレーターとしての判断に使い、繰り返し作業はSonnet/Haikuに任せるのが合理的だ。
バックグラウンド実行
run_in_background: trueを指定すると、タスクが非同期で走る。完了を待たずに次のタスクを起動できるので、並列度が上がる。
実践パターン3選
パターン1: 並列リサーチ
複数のURLやドキュメントを同時に取得・分析させるパターン。競合調査や技術調査で特に有効だ。
【オーケストレーターへの指示例】
以下の3つを並列で調査してください：
- URL-A のAPIドキュメントを読んで主要エンドポイントをまとめる
- URL-B の実装例を分析してベストプラクティスを抽出する
- URL-C のChangelog から破壊的変更を特定する
各タスクをサブエージェントに割り当て、全て完了したら結果を統合してください。
直列でやると3回分の待ち時間が発生するが、並列なら最も遅いタスクの時間で全部終わる。調査フェーズを半分以下の時間で完了できる。
パターン2: 並列コード生成
フロントエンド・バックエンド・テストを同時生成するパターン。モジュール間のインターフェースだけ先に決めておけば、実装は独立して進められる。
【オーケストレーターへの指示例】
以下の共通インターフェースに基づいて、3つのエージェントを並列起動してください：
- エージェントA: ReactでUserListコンポーネントを実装（API: GET /api/users）
- エージェントB: FastAPIでUsersエンドポイントを実装（レスポンス: {id, name, email}[]）
- エージェントC: 上記2つのpytestテストとReact Testingライブラリテストを生成
完了後、インポートパスと型定義の整合性を確認して統合してください。
ポイントはインターフェースを先に固定すること。「レスポンスの型が決まってないとテストが書けない」という問題を、先にスキーマだけ合意することで解消できる。
パターン3: パイプライン型
前の結果を次に渡す逐次実行パターン。各ステージで処理を完結させることで、エラーの局所化とコンテキストの節約ができる。
【パイプライン例: コードレビュー → 修正 → テスト生成】
ステージ1（Sonnet）: src/auth/login.py をレビューして問題点リストを出力
↓ 問題点リストを渡す
ステージ2（Sonnet）: 問題点リストに基づいてlogin.pyを修正
↓ 修正コードを渡す
ステージ3（Haiku）: 修正後のコードに対するpytestを生成
各ステージが前のステージの出力だけを入力として受け取るので、コンテキストが膨らまない。3000行のファイル全体を毎回渡す必要がなくなる。
注意点
コンテキスト汚染を防ぐ
各エージェントには独立したタスクを与えること。「全部やって」と渡すのではなく、「この特定の問題だけ解決して」と絞り込む。エージェント間で共有すべき情報はオーケストレーターを経由させる。
結果の統合
サブエージェントの出力は必ずオーケストレーターが確認・統合する。「フロントが期待するAPIレスポンスの型」と「バックエンドが返す型」が微妙にずれるケースが起きやすい。最終的な整合性チェックはOpusに任せるのが安全だ。
コスト管理
並列実行は速いが、コストも並列に発生する。長い調査タスクを10個同時に走らせると、単純に10倍のトークンを消費する。Haikuで済むタスクはHaikuを使い、Opusが必要な判断タスクに絞って使うことが重要だ。
目安として「10分以上かかる調査はSonnetワーカーに分担」「5秒で終わるファイル検索はHaiku」くらいの感覚で使い分けると、コストを抑えながら品質も維持できる。
まとめ
| パターン | 向いているタスク | 時間削減効果 |
|---|---|---|
| 並列リサーチ | 競合調査・技術調査・ドキュメント分析 | 〜1/3 |
| 並列コード生成 | フロント/バック/テストの同時実装 | 〜1/3 |
| パイプライン型 | レビュー→修正→テストの段階的処理 | コンテキスト節約 |
マルチエージェントで重要なのは、「どこを並列化してどこを直列にするか」の判断だ。依存関係があるタスクを無理やり並列化すると、後で統合コストが増える。まず依存グラフを描いてから、並列化できるブランチを特定するのが正しい順序だ。
この記事で紹介したマルチエージェントパターンをカスタムスキルに組み込むと、さらに自動化できます。
/code-review（コードレビュー）・/refactor-suggest（リファクタリング）・/test-gen（テスト生成）の3スキルをセットにした Code Review Pack（¥980） を PromptWorks で販売中。
みょうが (@myougaTheAxo) — セキュリティ重視のClaudeエンジニア。