Claude Codeサブエージェント活用5パターン｜調査・実装・レビューを分けて並列で回す

「全部いい感じに直しといて」と3つのサブエージェントに同時に頼んだら、3人とも同じファイルのタイトルを別々に書き換えていました。

差分はやたら増えた。本文もそれっぽく良くなった。でも、検索キーワードはバラバラ、内部リンクの貼り方も三者三様で、最後に僕が手で揃え直すハメになりました。並列にして速くなるどころか、統合で半日溶けたんです。

サブエージェントは「人数を増やす機能」だと思っていると、たぶん同じ事故を踏みます。本当のコツは、走らせる前に「誰が何を触り、誰が読むだけか」を分けておくこと。今日はその分け方を、僕が実際に使っている5つのパターンに整理して紹介します。

この記事の要点

• サブエージェントは「別の作業机（コンテキスト）」を持つ専門担当。調査・実装・レビューを分けると手戻りが減る
• 並列化の本質は人数ではなく、衝突しない作業面（重ならない編集範囲）を先に切ること
• 役割は3つに分ける：読むだけのexplorer → 決めた範囲だけ触るworker → 疑って読むreviewer
• 結果は「短い証跡＋再現コマンド」で返させる。全文や生ログを戻すとメインの机が埋まる
• 使いすぎは逆効果。小さい修正を分けると、各エージェントが同じファイルを読み直して遅くなる

足場の全体像から知りたい人はClaude Codeのハーネス（足場）設計を、まず最小構成で試したい人は軽量ハーネスのワークフローを先に読むと、この記事の話がつながります。

そもそもサブエージェントって何？

ひとことで言うと、メイン会話とは別室で動く専門担当です。

ここでいう「別室」がポイントで、サブエージェントは新しい独立したコンテキストで始まります。コンテキストというのは、Claudeがその時点で覚えている会話・読んだファイル・コマンド出力をまとめた「作業机」のことだと思ってください。

机が散らかると、人間も判断を間違えます。AIも同じです。10言語の記事、複数ディレクトリの実装、レビュー、翻訳、検証を1本の会話に全部積むと、机がモノであふれ、同じ調査を繰り返し、最後に「どのファイルを誰が触ったんだっけ」と分からなくなる。

そこで、重い調査や長いログは別室（サブエージェント）に投げて、メインの机には要約だけを戻す。これだけで作業が驚くほど見通しよくなります。

用語を先に平易にしておきます。あとの章で繰り返し出てきます。

用語	この記事での意味
サブエージェント	別室で調査・実装・翻訳・レビューをする専門担当
コンテキスト	Claudeが今見えている会話とファイルの「作業机」
重ならない編集範囲	同時に動く担当が触るファイルを重ねない分担（disjoint write set）
explorer	まず読むだけの調査担当。原則として編集しない
worker	決められたファイルだけ編集する実装担当
委譲契約	目的・範囲・禁止事項・完了条件・戻り値を書いた小さな約束（handoff contract）

公式の仕様は、Claude CodeのSubagentsドキュメントが一次情報です。.claude/agents/に置いたエージェント定義はチームで共有できること、サブエージェントは新しいコンテキストで始まること、長い結果を返しすぎるとメイン会話のコンテキストも食うこと——このあたりは押さえておくと事故が減ります。

パターン1：いつ分割するかを「机を分ける価値」で決める

最初に身につけてほしいのは、テクニックより判断基準です。サブエージェントは万能ではありません。短い修正を細かく分けると、各エージェントが同じファイルを読み直して、かえって遅くなります。

僕の判断軸はシンプルで、**「机を分ける価値があるか」**の一点です。

仕事	分割向きか	理由
10言語の記事翻訳	向いている	言語ごとに触るファイルが分かれ、品質観点も明確
既存記事の重複調査	向いている	大量検索の結果を要約だけ戻せる
1ファイルの小さな文言修正	メインでよい	分ける説明コストのほうが大きい
認証処理の横断リファクタ	計画後なら可	先にexplorerで影響範囲を確定する必要がある
仕様が曖昧な新機能	まだ早い	メイン会話で要件を固めるのが先

僕がサブエージェントに任せるのは、次の3つを満たすときだけです。

1. 探索結果・ログ・翻訳候補など、メインに全部置くと重い情報が出る
2. 担当ごとに編集するファイルをきれいに分けられる
3. 返してほしい形をチェックリストや表で指定できる

逆に、要件の会話がまだ揺れているとき、同じファイルを複数人が触りそうなとき、秘密情報を読ませる必要があるときは止めます。秘密情報はそもそもプロンプトにもログにも載せない、というのがサブエージェント以前の鉄則です。

パターン2：役割を分ける（調査→実装→レビュー）

これが一番効くパターンです。いきなり実装させない。読むだけのexplorer → 決めた範囲だけ触るworker → 疑って読むreviewer、の順に流します。

flowchart TD
  A["メイン：目的と制約を決める"] --> B["Explorer：読むだけ。範囲を地図にする"]
  B --> C["メイン：編集範囲を確定する"]
  C --> D["Worker（日本語）：基準原稿を書く"]
  C --> E["Worker（英語・中国語…）：各言語に翻訳"]
  D --> F["Reviewer：metadata・リンク・プロンプトを確認"]
  E --> F
  F --> G["メイン：仕上げチェックと最終引き継ぎ"]

この図でいちばん大事なのは、workerを先に増やさないことです。

調査前にworkerを並べると、全員が同じ記事・同じ関連リンク・同じfrontmatterを読み始めます。一見すると並列で速そう。でも実際は、同じ読み込みを人数分やっているだけで、重複作業が増えるんですね。

僕は今、新しい仕事を始める前に必ず「誰が決めるか」「誰が編集するか」「誰が疑って読むか」を一行で書き分けるようにしています。この一文があるだけで、エージェント同士の責任の境界がはっきりします。

パターン3：並列で走らせるなら、先に作業面を切る

ここが冒頭の失敗談の核心です。並列化の本質は人数を増やすことではなく、衝突しない作業面を先に作ること。

たとえばブログサイトで「記事カードの表示」「OGP画像の生成」「関連記事ロジック」を同時に直すとします。このとき、workerごとに触ってよいファイルを固定してしまうのがコツです。

3人のworkerを、重ならない編集範囲で動かす。

Worker A:
- 編集可: site/src/components/BlogCard.astro
- 編集禁止: layouts, pages, content files
- 目的: カードのmetadata表示だけ改善

Worker B:
- 編集可: site/src/pages/og/[...slug].png.ts
- 編集禁止: components, article files
- 目的: OGPのタイトルとheroの挙動を検証

Worker C:
- 編集可: site/src/lib/relatedPosts.ts
- 編集禁止: components, pages, content files
- 目的: ルートを変えずに関連記事の選び方を改善

全workerは引き継ぎ票を返す:
- 変更したファイル
- 変更の理由
- 実行したテスト
- 残ったリスク

この分け方なら、あとから差分を見ても衝突しません。逆に「UI全体をよくして」と3人に頼むと、全員が同じコンポーネントを触り、最後の統合で壊れます。冒頭の僕の事故が、まさにこれでした。

記事の翻訳でも考え方は同じです。10言語をいっぺんに走らせるなら、まず日本語の基準原稿（canonical）を確定し、各言語はそれを自然にローカライズする。担当はこう切ります。

担当	編集してよいファイル	やること
ja-worker	blog/claude-code-subagent-patterns.mdx	構成・実例・プロンプト・導線を作る
欧州ロケール担当	blog-en, blog-es, blog-fr, blog-de, blog-pt	機械翻訳調を避けて自然に訳す
アジアロケール担当	blog-zh, blog-ko, blog-hi, blog-id	用語を各文化圏の読者向けに置き換える
review担当	10ファイルすべてを読むだけ	frontmatter・文字化け・コードフェンス・リンクを確認

翻訳担当には「要約するな」と明示してください。AI翻訳は長い記事を勝手に短く整えがちで、実例・失敗例・チェックリストが静かに抜け落ちます。

パターン4：結果をどう集約するか（コンテキスト予算を決める）

「サブエージェントを使えばメインの机は軽くなる」と思いがちですが、戻り値を全部貼れば結局メインが重くなります。別室で調べても、レポートを机いっぱいに広げたら散らかるのと同じです。

だから僕は、走らせる前に「戻してよい情報量」を決めます。これをコンテキスト予算と呼んでいます。

コンテキスト予算ルール:
- Explorerは箇条書き20個と表1つまで。
- Workerは変更ファイル・判断・チェック結果だけを返す。
- Reviewerは深刻度別の指摘だけ。記事の全文書き直しは返さない。
- 80行を超えるログは要約する。
- 迷いが残るときは生ログを吐かず、焦点を絞った質問を1つだけ返す。

ポイントは、本文の品質は長くてよいが、引き継ぎ（handoff）は短くすること。ここを混ぜると、メイン会話が記事本文・翻訳メモ・検証ログで埋まって、肝心の判断ができなくなります。「証跡は短く、再現コマンドは残す」を合言葉にすると、後から自分で追えるレポートになります。

コンテキストの基本的な扱いをもっと知りたい人は、Claude Codeのコンテキスト管理も合わせてどうぞ。

パターン5：レビューと検証は「疑う専任」を最後に置く

サブエージェントは実装者だけじゃありません。むしろ最後のreviewerと検証担当が効きます。

役割をはっきり分けるのがコツです。reviewerは「読者価値・SEO・落とし穴・重複」を見る担当、検証担当は「ビルド・リンク・コードフェンス・文字化け」を見る担当。実装者は自分の前提を信じやすいので、レビューは別人格に任せます。

読み取り専用で、こう頼みます。

レビュー用サブエージェントを読み取り専用で使う。

範囲:
- slug claude-code-subagent-patterns の10言語ファイルだけを読む。
- 何も編集しない。

レビュー観点:
- descriptionが120字以内か
- updatedDateが2026-06-07か
- heroImageが維持されているか
- 各言語が薄い要約でなく、完全なローカライズ記事になっているか
- 具体的な実例が3つ以上あるか
- 失敗例・落とし穴が具体的か
- コードフェンスが閉じているか
- 公式の外部リンクと内部リンクがあるか

指摘は深刻度順に、可能ならファイルパスと行番号つきで返す。

この読み取り専用レビューは、人間が見る前にめちゃくちゃ役立ちます。多言語記事だと「本文は自然なのにHindiだけコードフェンスが閉じてない」「Portugueseだけ末尾の導線が抜けてる」みたいな小さな事故が必ず起きるので、機械的に弾いてくれる門番がいると安心です。コード側のレビュー観点はコードレビューチェックリストにも整理してあります。

コピペで作る：読み取り専用レビュワー

考え方をすぐ試すなら、まず読み取り専用のレビュワーから始めるのが安全です。編集権限を渡さないので、失敗しても差分を壊しません。次のコマンドで .claude/agents/article-reviewer.md を作れます。

mkdir -p .claude/agents
cat > .claude/agents/article-reviewer.md <<'EOF'
---
name: article-reviewer
description: ClaudeCodeLabの記事を独自性・実装の具体性・SEO・公開リスクの観点でレビューする
tools: Read, Grep, Glob
---

割り当てられたファイルだけをレビューする。編集はしない。

チェック項目:
- titleとdescriptionが検索意図に合っているか
- 導入の最初の3行で読者の具体的な悩みに触れているか
- 実例・落とし穴・公式リンク・内部リンク・導線があるか
- コードフェンスが閉じていて言語ラベルがついているか
- 薄い要約や他ページの焼き直しになっていないか

返すもの:
- 深刻度順の指摘
- 合格/不合格の判定
- いちばん効く修正を1つ
EOF

nameは小文字とハイフンで一意にし、descriptionには「いつ使うべきか」を書きます。ファイルベースのエージェントは起動時に読み込まれるので、作ったあとは念のためセッションを再起動すると確実です。長いプロンプトをCLI引数に詰めるより、.claude/agents/に短く整理して置くほうが、チームでは断然扱いやすいです。

オーケストレーション（指揮役）側は、メイン会話の冒頭にこれを貼ると安定します。

あなたはオーケストレーターです。サブエージェントを使う前に委譲計画を作る。

目的:
- [一文のゴール]

ハード制約:
- 触ってよいのは: [正確なファイルかディレクトリ]
- 編集禁止: [対象外]
- 維持すべきもの: [metadata, 公開API, ルート, 画像 など]
- 必須の検証: [コマンドか手動チェック]

まずexplorerに読むだけをさせる。編集範囲が重ならないと確認するまでworkerを動かさない。
各workerには次を定義する:
- 編集可のファイル
- 編集禁止のファイル
- 期待する出力
- 完了条件

最終回答に必ず含める:
- 変更したファイル
- 実行したチェック
- 残ったリスク

僕がやらかした失敗3つ

正直に書きます。サブエージェントの使い始めは、事故ばかりでした。

ひとつ目は、冒頭の**「全員に同じ仕事を頼んだ」**やつ。編集範囲を切らずに「記事を良くして」と3人に投げて、タイトル・導入・導線を全員が触りました。差分は増えたのに品質は上がらず、統合で半日。今は「このworkerはこのファイルだけ」「このagentは読むだけ」と必ず分けます。

ふたつ目は、explorerの出力を長くしすぎたこと。検索結果を全件、ログを全文、メインに貼り戻していました。別室で調べた意味が消えて、机が一瞬で埋まる。今は「判断に必要な表と結論だけ」と上限を決めています。

みっつ目は、委譲契約が薄かったこと。「いい感じに翻訳して」だと、トーンも長さもSEOキーワードも揺れます。「要約禁止」「frontmatter維持」「失敗例を残す」「ローカル読者に自然な用語に」と書いてからは、戻ってくる品質が安定しました。約束を具体的にするほど、別室の仕事はブレなくなります。

よくある質問

Q. サブエージェントとメイン会話の使い分けは？ A. 「机を分ける価値があるか」で決めます。大量の調査結果やログが出る、担当ごとに編集ファイルを分けられる、戻り値の形を指定できる——この3つが揃えば別室へ。1ファイルの小さな修正はメインのままが速いです。

Q. 何個まで並列で走らせていい？ A. 数より「編集範囲が重ならないか」が先です。重ならない作業面を3つ作れるなら3人、2つしか作れないなら2人。同じファイルを触る並列は、人数を増やすほど統合で壊れます。

Q. 役割は必ず3つ（explorer / worker / reviewer）に分けるべき？ A. 全部必須ではありません。ただ最低限、読むだけのexplorerと疑って読むreviewerは分ける価値が大きいです。編集しないagentは失敗しても差分を壊さないので、最初の一歩に向いています。

Q. 結果がメインに戻ってきて、かえって重くなりました。 A. コンテキスト予算を先に決めていないサインです。「explorerは表1つと箇条書き20個まで」「80行超のログは要約」のように上限を渡してください。本文は長くてよくても、引き継ぎは短く、が原則です。

Q. 作ったエージェント定義がうまく呼ばれません。 A. ファイルベースのagentは起動時に読み込まれます。作成直後はセッションを再起動すると確実です。配置場所は.claude/agents/、nameは小文字とハイフンで一意に。詳細は公式ドキュメントを確認してください。

実際に試した結果

ClaudeCodeLabの記事改善でいちばん効果を感じたのは、翻訳を並列化することそのものよりも、最初に「日本語の基準原稿」「翻訳worker」「読み取り専用reviewer」を分けたことでした。

以前は10言語を一気に直そうとして、英語だけ濃く、日本語と他言語が薄いまま残る、という残念な結果になりがちでした。今は、基準原稿に実例と失敗談を先に固めてから、各言語には「要約禁止」「導線維持」を明示する。たったこれだけで、公開前レビューの指摘がぐっと具体的になりました。

冒頭の半日溶けた事故以来、僕がサブエージェントで最初に書くのは、賢いプロンプトではありません。「誰が決め、誰が編集し、誰が疑って読むか」の3行です。並列化するほど、この地味な3行が効いてきます。

まずは読むだけのexplorerとreviewerを1本の記事で試して、自分のチームに合う引き継ぎ票の形を固めるところから始めてみてください。足場全体の設計はハーネス（足場）の作り方、最小構成は軽量ハーネスにまとめてあります。委譲契約やレビュー観点をチーム向けに整理したい場合は、実務テンプレート集も役に立つはずです。