最近、「マルチエージェント」「並列化」という言葉をよく聞きます。LangGraph、Google ADK、CrewAI、AutoGen── 複数のAIエージェントを組み合わせて、専門化や並列実行で高速化する、というアプローチです。

正直、最初に聞いたときは「新しいフレームワークを入れないとできないのか」と思いました。
でも、よく考えると、自分が普段やっていることも、ある意味でマルチエージェントです。
Sonnet 4.6 で実装して、Opus 4.7 でレビューする。これも複数のAIを使い分けている。今回は、マルチエージェントと並列化について、自分なりに整理してみます。

• マルチエージェントは何が嬉しいか
• 並列化は万能ではない
• 主なフレームワーク
• Claude Codeでもマルチエージェントはできる
• 7-parallel-Taskを試してみたら止められた話
• 専用モデルとレビュー体制
• コストとメリット
• まとめ

マルチエージェントは何が嬉しいか

複数のエージェントを使うことには、いくつかのメリットがあります。

専門化による品質向上

一つのエージェントに「全部やって」と頼むより、役割を分けたほうが、各タスクの質が上がります。リサーチに特化、文章作成に特化、レビューに特化。各エージェントが「自分の役割」だけに注意を払えるので、注意が分散しない。
これは、人間の組織でも同じ構造です。集中している領域が狭いほど、その領域の質は上がる。

並列実行による高速化

独立したタスクを並列に実行すれば、時間が短縮できます。
5つのファイルを同時にリファクタ、複数のAPIを同時に調査、別々のテストを並列実行── 逐次処理では時間がかかるものが、並列なら速くなる。

コンテキスト分離

各エージェントが自分のコンテキストだけを持つ。共通のコンテキストが肥大化しない。
以前の記事で書いた「長い文脈になると注意が分散する」という問題を、構造的に避けられます。

検証層の追加

「実装エージェント → レビューエージェント」のように、別のエージェントが検証する構造。
以前書いた「AIの自己評価を当てにしない」を、構造化できる。

並列化は万能ではない

ただ、「マルチエージェントにすれば速くなる」と単純には言えません。

並列が効くタスクは、こんな場合:

• タスクが完全に独立している(互いに依存なし)
• ファイル境界が明確、重複なし
• 3つ以上の関連しないタスク

並列が効かないタスクもあります:

• タスクに依存関係がある(B が A の出力を必要とする)
• 共有ファイル・状態がある(マージコンフリクトリスク)
• 一つのファイルを複数の観点で修正する(同時に編集できない)

通常の機能開発は、設計 → 実装 → テストの依存関係があります。
実装したコードに対してテストを書く。同時にはできない。
リファクタも、コードベース全体の整合性が必要なので、安易に並列化すると壊れる。

並列化には、隠れたコストもあります:

• オーケストレーション(誰がどれをやるか決めるオーバーヘッド)
• 結果の統合(並列の結果をまとめる作業)
• 競合の解決(同じファイルを複数が触ると衝突)
• デバッグの難しさ(並列だと問題の特定が困難)

これらが並列化のメリットを食い潰すこともあります。
並列化は判断軸が必要で、闇雲に並列にすればいいわけではない。

主なフレームワーク

業界では、マルチエージェントを構築するためのフレームワークがいくつかあります。

• OSS: LangGraph、CrewAI、AutoGen
• ベンダー製: Google ADK、OpenAI Agents SDK、AWS Strands Agents

これらは、自分でAIエージェントを構築するためのフレームワークです。本番のAIサービスを作る用途で活きます。

業界の動きとして興味深いのは、agentskills.io という共通仕様が広がっていること。
Claude Code、Gemini CLI、Cursor、Google ADK など40以上の製品で、同じ形式のskillが動くようになっています。フレームワークごとに skill を書き直す必要がなく、可搬性が確保される方向に進んでいる。

ただ、これらは Claude Code のようなコーディングアシスタントの代替ではなく、別レイヤーの道具です。「AIにコードを書いてもらう」という用途には、フレームワークを入れる必要はない。

Claude Codeでもマルチエージェントはできる

ここで気付いたのは、マルチエージェントのために専用フレームワークを入れる必要はないということ。Claude Code 自体に、Subagent 機能があります。主な使い方は3つ:

組み込みSubagent

Explore(高速、読み取り専用、コードベース検索)、Plan(計画立案)、general-purpose(汎用)が最初から入っている。Claude が自動的に判断して使ってくれる。

カスタムSubagent

.claude/agents/(プロジェクト)または ~/.claude/agents/(ユーザー)にMarkdownファイル(YAML frontmatter付き)を置くと、独自の Subagent が定義できる。これは skill と同じ構造です。

並列実行(Task/Agentツール)

最も興味深い部分。Claude が Task ツール(現在は Agent に改名)を呼ぶと、複数のサブエージェントが並列実行される。各サブエージェントが独立したコンテキストを持ち、結果だけが親エージェントに返される。

例えば、「75ファイルで使われている関数を deprecated にする」というタスクなら、親エージェントが grep で対象を特定して、ファイルごとにサブエージェントを並列起動する。各サブエージェントが担当ファイルを修正、親が結果を集約、という流れになる。

つまり、ADKや LangGraph のような専用フレームワークを入れなくても、Claude Code 単体でマルチエージェントの主要機能が使える。以前 skills の検証について書いた記事で書いた「今あるもので解決できないか考える」と同じ話です。新しい道具を入れる前に、手元の道具を見直す。

7-parallel-Taskを試してみたら止められた話

実際にマルチエージェントを試してみたくなって、ネット記事で見かけた 7-parallel-Task パターン── 機能実装を Component / Styles / Tests / Types / Hooks / Integration / Config の7つに並列分割するもの── を、CLAUDE.md に書こうかと考えました。これを書いておくと、機能実装のときに自動的に並列化されるらしい。

ただ、書く前に「これCLAUDE.mdに書く価値あるか?」とAIに聞いてみました。

Sonnet の応答は「効果は薄い」。理由:

• このテンプレートは React/Next.js 前提で、自分のスタック(Rails + Vue)に合わない
• Claude Code が並列 Agent を spawn するかはタスクの複雑さ次第。CLAUDE.md に書いても「常に7並列」にはならず、指示が宙に浮く
• Rails の成果物(コントローラ・サービス・モデル・テスト)は相互依存。テストは実装の後

念のため Opus にも聞いてみたら、もう一段強い結論が返ってきました。
「機能しない可能性が高い」。追加された観点:

• 「7-parallel-Task distribution」という用語が曖昧。「並列で Task ツールを7つ起動せよ」と解釈するか、「7つの観点で考えろ」と解釈するか不定
• Claude Code の方針(「不要な subagent spawn を避ける」「依存のないタスクのみ並列化」)と直接衝突する
• 分類が React/Next.js モデル(Hooks は Vue では composables、Styles は Tailwind 中心)。どのファイルを作ればいいか分類できない指示は、Claude が無理やり当てはめてゴミファイルを生む
• CLAUDE.md は「常時適用される制約・規約」を書く場所。「機能実装時は」という条件分岐はノイズになる。書きたいなら skill 化してトリガーを絞るのが筋

なるほど、と思いました。これは、以前から書いてきた論点が、自分が試そうとして AI に止められた事例です。

• ネット記事のテンプレートをそのまま使わない ── 以前ハーネスについて書いた記事で書いた「ハーネス作りが目的化しないように」「自分のコードベースに合わせて育てる」
• Claude Code 本体の方針と衝突する書き方をしない ── 以前書いた「ハーネスの方針と矛盾する指示は、どう動くか分からない」

そして、ここで興味深いのは、Sonnet と Opus で判断の解像度に差があったこと。Sonnet は「効果は薄い」と慎重に言うだけだったが、Opus は「機能しない可能性が高い」と踏み込み、解決策(skill化、特定タスク向けにトリガーを絞る)まで提案してくれた。以前書いた「別モデルでレビューする」が、こういう場面で効きます。

専用モデルとレビュー体制

ここで、自分の運用を振り返ってみます。
実は、自分は既にマルチエージェントを使っていました。専用フレームワークを入れているわけではないけど、複数のAIを役割で使い分けている。整理すると、3層のレビュー体制になっています。

1層: 実装後のレビュー(push前)

• Sonnet 4.6: 実装担当
• Opus 4.7: レビュー(別の視点)
• Codex(OpenAI): レビュー(別ベンダー、さらに別の視点)

レビューの指示は、タスクの重要度で変えています。通常のタスクなら「Git ステージしているファイルをレビューして」、重要な変更なら「Git ステージしているファイルを厳しくレビューして」と一言加える。同じモデル、同じ仕組みでも、指示の温度を変えることで、レビューの厳しさが変わります。

2層: PRレビュー(push後、マージ前)

• CodeRabbit
• Copilot code review

3層: 最終的な人間のレビュー

• 自分
• メンバー

なぜこんなに多層化するのか。理由は、各層で偏りを相殺できるから。

以前 skills の検証について書いた話と繋がりますが、AIに「自己評価して」と頼んでも、ハルシネーション込みで信用しきれない。同じモデルに自分の出力をレビューさせると、同じ偏りで盲点を見落とす。だから、異なるモデル、異なるベンダー、異なるタイミングでレビューする。

実際、Opus と Codex に同じコードのレビューを頼むと、指摘される点が違うことが多いです。同じ Anthropic の Sonnet と Opus でも視点が違うし、ベンダーが違えばさらに違う。各モデルに学習データや思考の癖があって、それがレビューの観点の違いとして現れる。

これは、以前書いた「完成度のギャップ(70% → 90% → 95%)」を埋める一つの方法かなと思います。一つのAIで95%に到達できないなら、複数のAIで多層的にチェックすることで、95%に近づく。

マルチエージェントというと専用フレームワークを思い浮かべがちですが、実態としては、役割を分けた複数のAIを使い分けること。これは、ADKを入れなくても、日常的にできる話です。

コストとメリット

ただ、多層化にはコストがあります。

• API利用料が増える(複数モデルを呼ぶ)
• レビューを統合する手間
• 矛盾した指摘が出たときの判断負荷

「3層もレビューする必要があるのか」と思うかもしれません。タスクの重要度によって、層を増やしたり減らしたりするのが現実的です。

• 個人開発の試作品: Sonnet で実装、自分で確認(1層)
• 業務の軽量タスク: Sonnet で実装、PRレビュー、人間のレビュー(2層)
• 業務の通常タスク: Sonnet で実装、実装後のレビュー、PRレビュー、人間のレビュー(3層)

これは、以前開発プロセスについて書いた「部分採用、いいとこ取り」と同じ発想です。すべてのタスクで全部のレビューを通す必要はない。タスクの重要度に応じて、層の深さを変える。

まとめ

「マルチエージェント・並列化」と聞くと、新しいフレームワークが必要に思えますが、よく見ると、普段の使い方の延長です。

• 役割を分けて複数のAIを使う = マルチエージェント
• 独立したタスクを別々のエージェントに渡す = 並列化
• 別モデルでレビューする = 検証層の追加

これらは、Claude Code 単体でできるし、自分の運用でも(意図せず)実践していることがあります。専用フレームワーク(LangGraph、Google ADK 等)は、本番のAIサービスを構築する用途で活きる道具で、コーディングアシスタントには過剰です。

そして、並列化は判断軸が必要です。タスクが独立しているか、依存関係があるか、共有ファイルがあるか。並列化すれば速くなるわけではなく、タスクの性質で判断する。これは、人間が普通の開発で考えていることと、本質的に同じです。

7-parallel-Task の事例で見たように、ネット記事のテンプレートを鵜呑みにしないのも重要です。自分のスタックに合うか、ハーネス本体の方針と衝突しないか、CLAUDE.md と skill のどちらに書くべきか。判断軸は以前から何度も書いてきました。

これも結局、いつものエンジニアリングの延長な気がしています。道具より判断。手元の道具を見直す。鵜呑みにしないで、自分の文脈で判断する。マルチエージェント特有の話というより、何かを設計するときの基本かもしれません。