SECTION 01
単一エージェント運用を卒業すべきタイミング
この記事はClaude Codeの機能解説ではありません。Skills・MCP・Actionといった個別機能の話ではなく、複数のエージェントにどう役割を分け、どう並列で回すかという「設計論」を扱います。すでにClaude Codeを使い込んでいて、次のステップを模索している方に向けた内容です。
単一エージェントの運用を卒業すべきサインは、コーディング速度ではなく確認・管理が律速になった瞬間です。AIでコードを書く速度は体感で大きく上がります。しかしその前後にある動作確認やインフラ設定といった人間作業がボトルネックになると、全体のスループットは頭打ちになります。
これまでの経験のなかで、待ち時間を有効活用しようと複数プロジェクトを同時に走らせた時期がありました。AIにタスクAを投げている間にプロジェクトBを進め、Bの待ち時間にAの結果を確認する。理論上は効率的ですが、実際にはコンテキストスイッチのコストが想像以上に高く、頭がこんがらがりました。
最終的に落ち着いたのは、ひとつのプロジェクトに集中して、そのなかで複数タスクを並列にAIへ依頼するスタイルです。同時に進めるプロジェクトは最大でも2つまでにして、プロジェクトごとに画面を分けています。頭のリソースを分散させないほうが、トータルの生産性は高いと実感しています。
つまり並列開発の単位は「プロジェクト×プロジェクト」ではなく「1プロジェクト内のタスク×タスク」です。この前提を間違えると、管理コストが膨らんで本末転倒になります。ここから先は、1プロジェクト内でサブエージェントをどう設計するかに絞って解説していきます。
SECTION 02
親エージェントと子エージェントの責務分離パターン
並列開発を安定させる基本構造は、親エージェントが「計画・分岐・承認」を担い、子エージェントが「実行・報告」に徹するという分離です。親は全体の見通しを持ち、子はスコープを限定された作業に集中します。この分離がないまま複数エージェントを走らせると、誰が何を判断するのか曖昧になり、すぐに破綻します。
具体的な役割テンプレートとしては、4つの責務に分けるのが扱いやすい形です。要件定義・実装・レビュー・テストのそれぞれを別の子エージェントに担当させ、親エージェントがタスクの流れを制御します。
それぞれの責任範囲を整理すると、次のようになります。
- 要件定義エージェント: ユーザーの意図を構造化し、実装仕様に変換する
- 実装エージェント: 仕様どおりにコードを生成し、差分を報告する
- レビューエージェント: 実装結果を検証し、問題点をリストアップする
- テストエージェント: 動作確認を行い、ログを残す
ここで重要なのは、「考える存在」と「動く存在」を分離して初めてスケールする体制が生まれるという点です。ローカルPCに複数のリポジトリクローンを作り、別ブランチでそれぞれのエージェントにタスクを依頼してエージェントモードで回す。この構成で試行錯誤するなかで、役割が混ざった瞬間に精度が落ちることを何度も経験しました。
なお、ここで説明している「親が采配して子が実行する」構造は、Claude Code公式のsubagentsに相当します。subagentsは単一セッション内で独立コンテキストを持ち、完了後に要約を親へ返す仕組みです。
一方、複数エージェントが並列に動いて相互にやり取りする構成が必要な場合は、公式ではagent teamsとして整理されています。agent teamsは現時点では実験的機能であり、subagentsとは異なるレイヤーです。本稿で扱う設計の多くはsubagentsの延長で実現できますが、エージェント間の相互通信が必要になった段階ではagent teamsや外部オーケストレーションを検討する必要があります。
親エージェントには承認ゲートとしての役割も持たせます。子エージェントの実行結果を受け取り、次のステップに進めるかどうかを判断する。この判断を子に任せてしまうと、品質のチェックポイントが消えてしまいます。
SECTION 03
State共有と構造化データの受け渡し設計
複数のエージェントが協調するとき、最初に決めるべきはエージェント間で渡す情報の最小単位です。何でも渡せばいいわけではなく、ファイルパス・差分・エラーログなど、次の工程に本当に必要な情報だけを構造化して受け渡します。
Claude Codeの標準機能で実現できる範囲は想像以上に広いです。CLAUDE.mdにプロジェクトのルールや仕様を書いておけば、それが全エージェントの共通コンテキストになります。Skillsを使えば、特定のタスクパターンをテンプレート化して子エージェントに渡せます。公式にはSkillをsubagentで実行する context: fork も用意されており、独立コンテキストでのタスク実行が可能です。
ただし標準機能だけでは限界もあります。特に以下のようなケースでは、外部の仕組みを検討する必要が出てきます。
- エージェント間で実行状態を動的に同期したいとき
- タスクの依存関係が複雑で条件分岐が多段階になるとき
- エラー発生時のリトライや代替パスを自動で切り替えたいとき
外部フレームワークを使うかどうかの判断基準は、「条件分岐の深さ」と「状態管理の複雑さ」で決まります。直列に3つ程度のタスクを流すだけならClaude Code単体で十分です。しかし、分岐が3段階以上になったり、エージェント間で状態を持ち回す必要が出てきたら、専用のオーケストレーション層を検討する段階です。
受け渡すデータはJSONなどの構造化フォーマットに統一しておくのが鉄則です。自然言語のまま渡すと、次のエージェントが解釈を間違えるリスクが高まります。たとえば「修正が必要なファイル一覧」を文章で渡すより、ファイルパスの配列で渡したほうが後続の処理が安定します。
SECTION 04
無限ループと往復修正を止める停止条件の設計
サブエージェントを導入して最初にぶつかる壁が、AI同士が不毛な修正を繰り返す無限ループです。実装エージェントがコードを直し、レビューエージェントが指摘し、また直して、また指摘されて……このサイクルが終わらなくなることがあります。
これを防ぐには、3つの停止トリガーを事前に設計しておく必要があります。
- 最大試行回数: リトライは最大3回までといった上限を設定する
- 差分ゼロ検知: 前回と同じ修正を繰り返したら自動停止する
- 人間介入ポイント: 判断が割れたらAI側から人間に問いかける設計にする
試行錯誤のなかで気づいたのは、ガードレール設計が先でなければ安定しないということです。ルール・仕様・制約をしっかり作り込んだうえで初めて、丸投げに近い運用が成立します。事前にデザインの方針や命名規則といった「AIへのコーディング規約」を渡しておくと、やり取りの往復が明らかに減ります。
特に効果的なのは、困ったらAI側から呼びかけてもらう設計にすることです。子エージェントの指示に「判断に迷った場合は作業を止めて、迷っている内容を報告してください」と明記しておきます。AIが勝手に推測して進むより、止まって聞いてくれるほうが手戻りは圧倒的に少なくなります。
停止条件はプロジェクトの性質に合わせて調整する必要があります。新規開発なら試行回数を多めに許容し、本番環境に近い修正なら1回のリトライで人間に戻す。この匙加減が並列開発の安定性を左右します。
SECTION 05
コストを壊さないモデル配置と役割別の使い分け
複数のエージェントを動かすと、トークン消費が単純に倍以上になることを覚悟しなければなりません。すべての役割に最高性能のモデルを割り当てると、コストがあっという間に膨らみます。ここで重要なのが、タスクの難易度に応じたモデルの適材適所です。
基本方針として、計画・レビューのように判断力が要る工程にはopus、実装のような実行系にはsonnet、軽作業にはhaikuを割り当てます。subagentごとに sonnet / opus / haiku などのモデルを個別に設定できるため、役割に応じた使い分けが可能です。計画フェーズで方向性を間違えると全体が崩れるため、ここだけはコストを惜しまないのが得策です。
トークン消費を抑えるうえで最も効くのは、受け渡し情報の構造化です。エージェント間で渡すプロンプトに不要なコンテキストが混ざっていると、それだけでトークンが膨らみます。具体的には以下の工夫が効果的です。
- 子エージェントにはそのタスクに必要な情報だけを渡す
- ファイル全体ではなく変更対象の関数やブロック単位で渡す
- エラーログも関連部分だけを抜粋して渡す
さらに進んだ考え方として、タスク難易度に応じた動的ルーティングがあります。親エージェントがタスクの内容を判断し、簡単な修正ならhaiku、複雑なロジック変更ならopusに振り分ける仕組みです。これは実装のハードルが上がりますが、コストと品質のバランスを取るうえでは理想的な設計です。
ただし最初から動的ルーティングを組む必要はありません。まずは役割ごとに固定のモデルを割り当てる静的な構成で始めて、コストと品質のバランスを観察しながら段階的に最適化していくのが現実的な進め方です。
SECTION 06
管制塔がないと並列開発は破綻する
並列でエージェントを動かし始めると、新たなボトルネックが現れます。「進捗確認という名の雑務」に時間が溶けていく問題です。どのタスクが終わったのか、どのエージェントが今何をしているのか。これを確認するだけで時間が消えていきます。
多くのサービスを作ってきた経験のなかで、この問題を根本から消すために管制塔となるツールを自作しました。Claude Code・Codex・Cursor CLIに対応し、プロジェクト単位でタスクを並列に依頼・管理できる仕組みです。AIが自動でコードレビューし、動作確認まで回せる設計を組み込んでいます。
このツールを作るきっかけになったのは、かつて自律型AIエンジニアの先駆け的なサービスを使っていたときの経験です。期待どおりに動かないことが多く、信頼しきれなかった記憶がありました。あのとき「こうだったらいいのに」と思っていた体験を、自分の手元で再現したかったのが動機です。
管制塔に求められる機能を整理すると、次のようになります。
- タスクの一覧管理: 各エージェントの進捗をひと目で把握できる
- 自動レビュー: コード変更が入ったら自動でレビューが走る
- 動作確認の自動化: ブラウザ自動化環境と連携した確認フローを含む
- モデルの自動割り当て: タスク内容に応じて適切なモデルを選択する
管制塔なしで並列開発を続けると、エージェントの数が増えるほど人間の管理負荷が増えるという逆説的な状況に陥ります。AIを使って生産性を上げたはずなのに、AIの管理で時間が溶けていく。この罠を避けるには、管理そのものを自動化する仕組みが不可欠です。
SECTION 07
エージェントに渡すルールの設計原則
サブエージェントの品質を安定させるカギは、事前に渡すルールの精度にあります。開発・レビュー・動作確認をそれぞれ別のエージェントに分けてサイクルを回す以上、各エージェントが守るべき基準を明文化しておかないと、出力のばらつきが大きくなります。
ルールの渡し方にもコツがあります。長大なドキュメントを丸ごと渡すのではなく、そのタスクに関係するルールだけを抜粋して渡すのが重要です。不要な情報が混ざるとエージェントの注意が分散し、肝心なルールを見落とすことがあります。
実際に効果を実感しているルールの例は以下のとおりです。
- 命名規則とコーディングスタイル: ファイル名・変数名・関数名のパターンを統一する
- 禁止パターン: 使ってほしくないライブラリや書き方を明示する
- 報告フォーマット: 作業完了時に何をどの形式で返すかを指定する
AIへの指示にも「コーディング規約」的なものが必要だという感覚です。デザインの統一感を保つこと、余計な説明を入れないこと、こうした細かいルールを事前に渡しておくだけで、やり取りの往復が明らかに減ります。
ルールはCLAUDE.mdやSkillsに書いて全エージェントから参照できる状態にしておくのが理想です。ただし、レビュー用のルールと実装用のルールは観点が違うので、役割ごとにファイルを分けておくと運用しやすくなります。
SECTION 08
Claude Code標準機能と外部フレームワークの境界線
サブエージェント構成を組むとき、Claude Code単体でどこまでやるか、外部フレームワークを使うべきかは多くの人が迷うポイントです。結論から言えば、ほとんどのソロ開発・小規模チームではClaude Code標準機能で十分に回せます。
Claude CodeのSkillsとCLAUDE.mdを組み合わせれば、タスクのテンプレート化、共通ルールの配布、サブエージェントの起動までカバーできます。MCPを使えば外部APIや外部ツールへの接続も可能で、シンプルな並列構成ならこれだけで成立します。
外部フレームワークが必要になるのは、以下のような場面です。
- エージェント間の状態遷移が複雑で、フローチャートのような管理が要るとき
- 複数のAPIやサービスを横断する処理を自動化したいとき
- エラー時のリトライ・フォールバックを細かく制御したいとき
判断の軸は「今の構成で管理しきれているか」です。CLAUDE.mdとSkillsでタスクが流れているうちは無理に外部ツールを足す必要はありません。管理が追いつかなくなった、あるいは条件分岐が手作業では追えなくなった時点で、オーケストレーション層の導入を検討すれば十分です。
SECTION 09
実践ワークフロー：1つの機能追加を並列で回す流れ
ここまでの設計論を、具体的なワークフローに落とし込んでみます。1つの機能追加を並列エージェントで処理する場合、どういう流れになるのかを順を追って説明します。
まず親エージェントが要件を分解します。「ユーザープロフィール編集機能を追加する」という依頼を受けたら、API設計・フロントエンド実装・バリデーション追加・テスト作成の4タスクに分割します。依存関係がないタスクは同時に子エージェントへ振り分けます。
子エージェントはそれぞれのスコープ内で実装を完了し、結果を構造化データで返します。返却フォーマットは事前に決めておきます。
- 変更ファイル一覧: パスの配列で返す
- 実装内容の要約: 何をどう変えたかを箇条書きで返す
- 未解決の懸念点: 判断に迷った箇所があれば明記する
親エージェントは結果を受け取り、レビューエージェントに検証を依頼します。レビューが通れば統合し、指摘があれば実装エージェントに差し戻します。この差し戻しは最大3回までとし、それを超えたら人間に判断を仰ぐ設計です。
最後にテストエージェントが動作確認を行います。Playwright系のMCPやブラウザ自動化環境を組み合わせれば、スクリーンショット付きの確認まで回すことも可能です。ただしこれはClaude Code単体の標準機能ではなく、MCP等の拡張レイヤーを組み込んだ前提での話です。この一連の流れが自動で回ることで、人間が介入するのは最初の要件確認と最終承認だけになります。
SECTION 10
次のフェーズ：AIに主体を渡す並列開発の未来像
ここまでは人間が設計し、AIが実行するという構図でした。しかし次のフェーズでは、AIに主体を渡す方向に進んでいくと考えています。人間がやるのは最初の意思決定と、要所での確認だけにしたい。これが目指している姿です。
具体的に実験しているのは、AIと対話して作るものの壁打ちをし、方向が決まったらそのまま計画を立ててもらい、開発を進めてもらう流れです。開発するAIとの対話もAIに任せる。これまでは自分が主導してAIをうまく使うという感覚でしたが、もう少しAIに主導権を渡してみたらどうなるかを試しています。
この流れを実現するうえで必要な要素は3つあります。
- 対話から課題を抽出し、タスクを自動生成する仕組み
- タスクごとに適切なモデルを自動で割り当てるルーティング
- 実行結果の自動検証と、必要に応じた人間へのエスカレーション
「AIを使う時代」から「AIを束ねる時代」へ。コーディングを任せるだけでなく、計画・実行・検証のサイクル全体をAI主導で回す。その管制塔を人間が設計し、要所だけを見守る。これが並列開発の延長線上にある、次の開発スタイルだと考えています。
もちろん、今すぐすべてを任せられるわけではありません。まずは今回紹介した設計パターンで手元の開発を安定させることが先です。並列開発の土台ができてこそ、その先のAI主導開発が見えてきます。焦らず、一段ずつ進めていくのが結局は最短ルートです。
