Claude Codeのサブエージェント設計｜7つの役割と検証の受け渡し

Claude Codeを使っていると、こんな壁に突き当たることがあります。「調べてほしいことが多すぎて、1回の依頼では最後まで届かない」という壁です。

たとえば「社内の資料を全部見て、古くなっている記述を洗い出して」という依頼。ファイルが数十個ある時点で、1つの流れで全部読むと、後半に進むころには前半で読んだ内容が薄れていきます。人間が同じ作業をしても同じことが起きるので、これはAI特有の弱点ではありません。1つの頭で持てる量には限りがあるという、ごく当たり前の制約です。

サブエージェントは、このような仕事を分担する選択肢です。本記事では、公開済みのX記事とClaude Code公式資料をもとに、調査・監査の分け方、変更が衝突する条件、親が確認する範囲を整理します。業務例と推奨する進め方は、編集部の設計案として示します。

7人のAI社員という構成を、役割と成果物に分解する

2026年6月9日のClaude Code Studio記事では、sairahul1氏のソフトウェア開発の分担案を紹介しました。7つの役割を持たせる構成例であり、Claude Codeの公式な標準編成ではありません。また、24時間の自走や完成を保証するものでもありません。

人数より、前の工程の何を受け取るかを決める

実装担当へ曖昧な要望だけを渡すと、各担当が違う前提で作り始めます。問い合わせ一覧なら、誰が何を絞り込むのか、0件のときどうするのか、既存の権限をどう維持するのかを設計に残します。前の担当の「完了しました」という文章だけで、次の工程を始めないことが大切です。

検証担当には、設計と実物を両方渡す

実装者の説明だけでレビューすると、説明から抜けた要件を見落とす可能性があります。検証担当には、受け入れ条件、差分、テスト結果、確認できる画面を渡します。問題があれば、満たしていない条件を示して実装担当へ返してください。

人が決める箇所と、既に任せた範囲を明確にする

元の構成例では、要件、設計、コード変更のレビュー依頼（PR）の3地点で人が確認します。実務では、すでに委任された作業まで毎回止める必要はありません。新しい判断が必要な条件と、合意済みの範囲で進められる条件を区別します。公開や外部操作の範囲も、担当の名前だけから推測しないようにします。

最初から7体を起動するより、実装と検証の2役で、成果物を受け渡せるかを試す方法もあります。これは編集部の導入案です。役割を増やす判断は、同時に動かした数ではなく、統合と検証まで終わった仕事で行います。

サブエージェントとは何か——「分身」ではなく「別の担当者」

まず言葉の整理からです。Claude Codeのサブエージェントは、親のセッション（あなたが直接話しかけている相手）が、別の作業用のセッションを立ち上げて仕事を任せる仕組みです。

参照: Claude Code公式ドキュメント：サブエージェント

独立した文脈と、引き継ぐ情報の違い

サブエージェントは、独立した文脈で動作します。親の会話を引き継いで分岐する方式（fork型）など、起動方法によって渡される情報は異なります。依頼文に必要な前提を含め、使っている方式で何が引き継がれるかを公式資料で確認してください。

会話の経緯を引き継がずに依頼する方式なら、先入観を減らして確認させる使い方ができます。人間の会議でも、経緯を全部知っている人ばかりだと、過去の判断に引きずられることがあります。必要な条件を明示したうえで、初めて読む担当者として点検してもらう方法です。

返ってくるのは作業ログではなく「結論」

もう1つの性質は、サブエージェントが読んだファイルの中身が、親の手元にそのまま流れ込まないことです。返ってくるのは、その担当者がまとめた結論だけ。

この「結論だけ返る」という性質が、分担の向き不向きを決めます。結論に圧縮できる仕事は分担に向き、圧縮すると意味が失われる仕事は向きません。

2026年7月時点の入れ子の深さ

2026年7月のClaude Codeの更新で、サブエージェントがさらにサブエージェントを立ち上げられる深さの初期値が引き上げられました（従来の1段から3段へ）。つまり「担当者が、さらに補助担当を雇う」ことが標準でできるようになっています。

入れ子の深さを増やす場合は、目的・対象・完了条件が次の担当へ伝わり、根拠を親まで戻せるかを確認します。本記事では、まず親から子へ直接依頼する1段で試し、必要な場合に分割を増やす進め方を推奨します。

分担すべき仕事・1体で抱えるべき仕事

「並列にすれば速い」と考えて何でも分けると、かえって遅くなります。判断基準を表にまとめます。

迷ったときの一言判断

判断に迷ったら、こう自問してください。「この作業の結果を、A4半ページの報告書にまとめて渡してもらえれば十分か？」

最終結果だけを受け取れば判断できる仕事なら、サブエージェントへ任せる候補になります。途中経過を見ながら仕様を決めたい仕事なら、親の会話で進めるほうが適しています。これに加え、担当同士が同じファイルを変更しないか、結果を独立に確認できるかも確かめます。

調査・監査は問いで分け、変更作業は担当範囲を確かめる

実務でいちばん多い失敗が、分け方を間違えることです。

やりがちな分け方: ファイルで割る

「資料が30個あるから、10個ずつ3体に配ろう」——これは一見合理的ですが、多くの場合うまくいきません。担当者はそれぞれ自分の10個しか見ていないので、「30個を横断して初めて分かること」が誰の目にも入らないからです。同じ記述が3箇所で食い違っている、といった一番価値のある発見が丸ごと落ちます。

うまくいく分け方: 観点で割る

同じ30個を、全員に見せます。そのうえで、担当者ごとに違う問いを渡します。

• 担当A: 「日付や金額が、他の資料と食い違っている箇所はどこか」
• 担当B: 「もう使われていない古い呼び名が残っている箇所はどこか」
• 担当C: 「読んだ人が次に何をすればいいか分からない箇所はどこか」

3体とも同じ資料を見ますが、探す観点を変えています。指摘が重なる場合もあるため、親が重複を除いて根拠を確認します。これが「問いで割る」方法です。

もう1つの型: 同じ問いを複数体に調べさせ、根拠を突き合わせる

特に「これは本当に問題なのか」を確かめたいときに効きます。1体が「これは不具合です」と報告してきたとき、その主張を否定する側に立ってもらう担当を2〜3体立ち上げ、「これは実は問題ではない、という説明ができるか」を試させます。

複数の担当が同じ指摘を出したら、確認の優先順位を上げる材料にはできます。ただし、一致した人数だけで正しいとは判断しません。指摘が再現するか、根拠のファイルやログがあるかを確認します。全員が否定した場合も、その理由を確かめます。PLaiでは、このように反証と根拠を照合する形を社内の監査で使っています。

親と子の役割分担——親は「配る人」に徹する

設計でもう1つ大事なのが、親側の振る舞いです。

親がやること

1. 全体像をつかむ: 何を調べる仕事なのか、どこまで分かれば完了なのかを決める
2. 問いを設計して配る: 上で書いた「観点で割る」を、依頼文の形にして渡す
3. 結論を突き合わせる: 返ってきた報告を並べ、重複を消し、矛盾を洗い、優先順位をつける
4. 最終的な判断を下す: これは対応する／これは今回は見送る、を決める

親がやってはいけないこと

担当者と同じ範囲を、目的なく重複して調べる——これが一番もったいないパターンです。担当者に配ったのに、待っている間に自分でも読み始めると、親の頭が調査内容でいっぱいになり、肝心の「突き合わせる」役割が果たせなくなります。

親は調査の全範囲を重複して調べる必要はありません。担当者の報告を受けたら、根拠となる資料や結果を確認し、食い違う点を調べます。調査の分担と、最終判断に必要な確認を分けましょう。

依頼文に必ず入れる5項目

起動方法によって引き継ぐ情報が異なるため、依頼文には必要な前提を明記します。次の5つを必ず入れてください。

入れ子はどこまで深くすべきか

Claude Code v2.1.219の公式リリースでは、入れ子の深さの初期値が1から3へ変更されたと記載されています。利用環境の設定を確認したうえで、必要な分担の深さを選びます。

1段（親→子）: 最初に試す構成

まず親が独立した問いを2つ程度に分け、担当を立て、返ってきた結論を束ねます。報告の根拠と不明点を追えるかを確認してから、対象を増やす方法です。

2段（親→子→孫）: 子の担当をさらに分ける場合

対象が広く、子の担当内に独立した作業があるなら、さらに分割する方法があります。子が各報告を整理して親へ返す役割を持ち、根拠の参照先を省かないようにします。報告が集まりすぎる場合は分割数を見直します。

3段以上: 情報の受け渡しと統合の負担を確認する

起動方法と依頼文によって、下の担当へ渡る情報は異なります。深い構成を使う場合も、目的・制約・根拠の参照先を渡し、各段階で誰が結果を統合するかを決めます。深さだけでは、精度や成果は判断できません。

同じファイルの変更と、独立した変更を分ける

並列に書く作業では、同じファイルへの変更と、文章全体の一貫性を確認します。独立した変更を分担できる場合もありますが、最後の統合と検証は必要です。

理由1: 同じ場所を同時に触ると壊れる

2体が同じファイルを書き換えると、後から書いたほうが前の変更を消してしまいます。人間のチームでも、同じ書類を2人が別々に上書き保存すれば同じ事故が起きます。

参照: Claude Code公式変更履歴

並列に書くなら、担当ファイルを分けるか、Git worktreeなどで作業場所を分離してから統合します。変更量だけでなく、依存関係、統合の手間、全体を検証できるかで分担を決めます。

理由2: 文体と構成の一貫性が壊れる

文章は、書き手が変わると継ぎ目が出ます。用語の選び方、説明の丁寧さ、たとえ話の入れ方——読む側は驚くほど敏感に気づきます。

一つの記事を仕上げる場合は、調査を分担し、最後の構成・用語・文体を一人の担当がそろえる方法を推奨します。独立した記事やファイルの執筆は、担当範囲を決めたうえで並行して進められます。

よくある失敗と、その直し方

失敗1: 依頼文が短すぎて、見当違いの報告が返る

「この資料をチェックして」だけでは、担当者は何を探せばいいのか分かりません。起動方法によっては会話の記憶を引き継がないため、必要な前提が渡っているかを確認してください。前述の5項目を必ず書きます。

失敗2: 担当者を立てすぎて、束ねられなくなる

10体に投げると、返ってくる報告も10本です。読んで突き合わせるだけで疲れ果て、結局どれも活かせません。最初は3体から始め、束ねる作業が回ることを確認してから増やしてください。

失敗3: 「速くなる」を期待しすぎる

分担に期待できることは、待ち時間の短縮や、異なる観点からの点検です。ただし、担当の起動・重複した調査・統合にも時間がかかります。終わるまでの時間と確認できた範囲を比べ、分け方を調整します。

失敗4: 報告をそのまま鵜呑みにする

担当者の報告は「読んだ本人がそう感じた」という一次情報の要約です。特に「これは問題です」という報告は、前述の反証させる型で確かめてから対応を決めてください。Claude Codeの業務活用でも触れているとおり、「作った」と「使える」の間には必ず点検の工程が要ります。

失敗5: サブエージェントに「決めさせて」しまう

担当者に「どちらがいいか決めて」と丸投げすると、判断の根拠が親に残りません。あとから「なぜこれを選んだのか」を説明できなくなります。担当者には選択肢と根拠を出させ、選ぶのは親（最終的には人間）という線を守ってください。人間の組織で、調査担当に決裁権を渡さないのと同じことです。

業務での使いどころ：5つの設計例

分担の設計例を5つ挙げます。個々の例で速度や精度を測定した結果ではなく、自分の業務へ置き換えるための案です。

例1: 社内ナレッジの棚卸し

資料が増えると、古い記述が残ることがあります。例えば「日付の食い違い」「使われなくなった呼び名」「導線が切れている箇所」に観点を分け、別の担当に調べてもらいます。報告された箇所を原文と照合し、重複や誤検出を除いてから、分担が役立ったかを判断します。

例2: 施策案を出すとき

案出しでは、「守りの案」「攻めの案」「お金をかけない案」のように前提を変えて担当を分ける方法があります。出そろった案を親が比較し、実現性と違いを確認します。案の数や担当の数だけでは、質や幅が広がったとは判断しません。

例3: 作った資料の点検

できあがった提案書を、「数字の根拠」「読み手にとっての分かりやすさ」「言い過ぎていないか」の3観点で点検させます。作った本人（と作ったAI）は自分の文章の穴に気づきにくいので、まっさらな担当者に見せる価値が大きい場面です。AI社員の作り方の全体像と組み合わせると、役割ごとの点検担当をそのまま常設できます。

例4: 毎朝の定例チェックを分担で回す

毎朝の確認なら、受信箱・予定・チャット・タスクごとに担当を分ける案があります。必要な閲覧権限を確かめ、最終的には親が未対応の項目と今日の優先順位をまとめます。

受信箱の確認とタスクの確認では、見る資料や判断基準が異なることがあります。観点ごとに担当を分ける場合は、調べる範囲と報告項目を先にそろえ、漏れや重複を親が確認します。バックオフィス自動化の進め方で紹介した、定例業務の手順を決める考え方も使えます。

例5: 比較検討の材料集め

ツールや外注先を選ぶときは、候補ごとに担当を立て、同じ質問リストで調べる方法があります。比較しやすい形にはなりますが、公開情報の量は候補によって違うため、調べた範囲と不明な項目も残します。AI開発ツールの比較のような横並びの記事でも、根拠のそろい方を確かめてから結論を出します。

今日から始める3ステップ

1. いま抱えている「量が多くて終わらない調べもの」を1つ選ぶ。資料の棚卸し、競合の比較、過去のやりとりの洗い出し、どれでも構いません。
2. その仕事で独立して確認できる問いや、重ならずに変更できる範囲を探します。担当同士が同じ前提やファイルを頻繁に確認し合う必要があるなら、分け方を見直します。
3. 依頼文に5項目（目的・対象・問い・報告の形・やらないこと）を書いて、3体に投げる。返ってきた3本を並べて、重複を消し、矛盾を洗う。ここまでが1周です。

1周回すと、「どの粒度で割ると束ねやすいか」が体感で分かります。そこから先は、自社の業務に合わせて調整していくだけです。ナレッジの整備が追いついていないと感じたら、先にナレッジ構築の進め方を読んで土台を作ってください。担当者に渡す「前提」が社内に文章として存在していないと、依頼文を毎回ゼロから書くことになります。

報告を照合する練習例：架空のdocs/release-notes.mdに「対象版2.1.293」、docs/setup.mdに「確認版2.1.292」と書きます。担当Aは差を指摘できますが、親は「対象版」と「確認版」が別の意味なら誤記とは限らないと確かめます。担当Bには、手順に実行場所や成功条件がない箇所を探してもらいます。最終表を「採用する指摘／根拠／見送る指摘と理由」に分ければ、多数決で修正を決めるのを避けられます。

読み取りだけの分担を、1回試す

次は編集部の依頼例です。対象を実在するファイルへ変更し、Claude Codeの会話へ入力します。

次の確認を独立したサブエージェントへ分担してください。
目的：公開前の説明の矛盾を見つける。
対象：docs/release-notes.md と docs/setup.md。
担当A：日付と版番号の食い違いを調べる。
担当B：手順の入力と完了条件の不足を調べる。
報告：根拠のファイルと箇所、問題、確認範囲、不明点。
制約：読み取りのみ。変更・公開・外部送信はしない。
最後に親が重複を除き、原文で根拠を確認してください。

依頼後は、担当を起動した表示と実際の報告を確認します。起動できなかった場合を「分担できた」と扱わず、環境の制限や設定を確認してください。報告がそろったら、親が指摘箇所を元のファイルで照合します。この照合までを最初の1周に含めます。

チームで使うときの決めごと

一人で使う場合は自分の頭の中だけで完結しますが、複数人で同じ仕組みを使う場合は、先に決めておかないと事故が起きる項目があります。

決めごと1: 誰が「親」をやるか

同じ案件で2人が別々に担当者を立てると、同じ調査が二重に走り、結論が食い違ったときにどちらを採るか分からなくなります。案件ごとに親役を1人に決めるのが原則です。人間の会議で司会を2人置かないのと同じです。

決めごと2: 依頼文をどこに残すか

うまくいった依頼文は資産です。その場限りで消してしまうと、次に同じ調査をするとき、また一から書くことになります。依頼文は社内のナレッジとして残すようにしてください。月に数回しか使わない調査ほど、書き方を忘れているので効きます。

決めごと3: 報告を信じてよい水準を決める

先に決めておきたいのは、指摘を受けた後に何を確認すれば対応へ進めるかです。再現手順、根拠のファイル、影響範囲、変更後の確認方法を報告に含めます。外部に影響する変更では複数の視点で確認する方法も使えますが、担当者の合意だけを実行の条件にせず、根拠と必要な承認を確かめます。

実務で試すときに確認したいこと

分担は、作業対象が独立している部分から始めます。同じファイルを同時に変更すると衝突しやすいため、担当ファイルや受け渡す成果物を決めます。各担当の完了だけで全体を終えず、最後に組み合わせた状態で動作と内容を確認する役割を残してください。

この記事の「並列作業の衝突を防ぐ」を、自社の業務［業務名］に置き換えて検討します。
前提：［現在の手順・使ってよい資料・確認担当］
確認したいこと：同時作業の担当範囲と、最後に統合して確認する人は決まっていますか？
上の資料で分かること、不明なこと、最初に確認することを分けて整理してください。事実や実績を作らず、提案には理由を添えてください。外部送信や設定変更は行わず、検討用の案を出してください。

よくある質問

Q. 何体まで同時に動かせますか

技術的な上限より先に、人間が束ねられる上限が来ます。報告を読んで突き合わせる作業は親（最終的にはあなた）の仕事なので、慣れないうちは3体、慣れても7体前後が現実的です。

Q. 担当者が途中で失敗したらどうなりますか

失敗した担当の報告やログを読み、どこまで処理が進んだかを確認します。他の担当の結果を再利用できる場合もありますが、ファイル変更や外部操作が途中まで実行されていないか、後続の担当がその結果に依存していないかも調べます。影響を切り分けられた範囲だけを、重複実行にならない形でやり直します。

Q. 費用は増えますか

総費用は、使うモデル、各担当の処理量、親の統合、再試行で変わります。1体と複数体で同じ範囲の作業を試し、これらを含む総量で比較します。並列化だけで安くなるとは限りません。

Q. 社内に手順書がまだありません。それでも使えますか

使えます。むしろ手順書を作るための材料集めに、分担がよく効きます。「この業務について、過去のやりとりから手順らしきものを拾って」という依頼を、対象期間ごとに分けて複数体に投げると、頭の中にしかなかった手順が文章として出てきます。それを人間が整えれば手順書の初稿になります。順番としては、手順書ができてからAIに任せるのではなく、AIに材料を集めさせながら手順書を育てるほうが現実的です。

Q. 途中で方針を変えたくなったら、動いている担当者はどうなりますか

方針が変わった場合は、担当へ追加指示を届けられる方式か、進行中の変更を止める必要があるかを確認します。連絡や中断の方法は実行環境によって異なります。前提が固まっていない仕事では、まず親の会話で小さく試し、役割を分ける範囲を決めます。

Q. 分担させた結果を、そのまま社外に出してよいですか

出さないでください。担当者の報告は材料であって、成果物ではありません。社外に出るものは必ず人間の承認を通す——この線は、AIの性能が上がっても動かさないのが安全です。

まとめ

Claude Codeのサブエージェントは、「速く終わらせる道具」というより「1つの頭では持ちきれない量を、複数の頭に分けて持たせる道具」です。要点を3つに絞ります。

• 調査は問いや観点で分けると、同じ資料を異なる角度から確認できます。ファイル単位で修正を分ける場合も、ファイルをまたぐ影響は親が確認します。
• 同じファイルの変更は担当を調整し、文章全体をそろえる役を決めます。独立したファイルは並行して変更できる場合があります。
• 親は調査の重複を避け、返ってきた報告の根拠と矛盾を確認します。

そして深さは、能力ではなく責任の追跡可能性で決めます。3段まで潜れるからといって潜る理由にはなりません。「なぜこの結論になったのか」を最後まで説明できる範囲に留めるのが、業務で使うときの一番大事な作法です。

参考出典

• Claude Code公式：サブエージェント
• Claude Code公式：v2.1.219リリース

※ 入れ子の深さなど、バージョンで変わる仕様は公式資料と利用環境の設定で確認してください。本記事の分担例は、公式仕様を踏まえた編集部の提案です。自社の業務へ合わせて設計する場合は、AI社員構築代行もご覧ください。