Claude Codeのサブエージェントに仕事を分ける判断基準

入力と最終的な成果物

この記事では、架空の制作依頼8件（requests.json）と判定規則（judging-rules.md）を使います。確認作業は2つのサブエージェントに分けます。最終的な成果物は、IDごとに decision（ready か hold）と issue_codes を持つ1つのJSONです。判定規則は11条あり、その中で10種類のissue codeを定めています。

• request-checker: 制作依頼の不足と矛盾を見る担当です。目的、対象、尺、納期、確認者、素材許諾を確認します。

• claim-checker: 商品根拠の欄を見る担当です。approved_claim と source_ref が空になっていないかを確認します。

入力データは /resources#practice の練習セットに、2つの担当の定義は /resources#skills の教材に入っています。同じデータを1つの会話で確認する方法は「Claude Codeで制作依頼を確認する」で扱っています。この記事は、確認を担当ごとに分けるときの判断に絞ります。

分ける仕事を決める

公式ドキュメントによると、サブエージェントはそれぞれ専用のコンテキストウィンドウで作業し、親には要約だけを返します。使えるツールも担当ごとに制限できます。一方で、やり取りを何度も重ねる作業、各段階で多くの文脈を共有する作業、小さな修正はメインの会話で進めるよう案内されています（Create custom subagents）。

今回の確認は3つの観点すべてで「分けてよい」側に当てはまります。商品根拠の欄は、制作要件の欄とは別に確認できます。ドキュメントでも、並列での調査は調べる対象が互いに依存しない場合に最も向いていると説明されています。

担当ごとの入力と出力を定義する

配布している2つの定義の中身は次のとおりです。どちらも tools を Read だけにしています。model: inherit は、メインの会話と同じモデルを使う指定です。

---
name: request-checker
description: 制作依頼の不足と矛盾を確認する担当
tools: Read
model: inherit
---

requests.json と judging-rules.md を読み、各依頼の id、decision、issue_codes、確認先を返してください。欠損を推測で補わず外部操作は行いません。

---
name: claim-checker
description: 商品根拠の記載を確認する担当
tools: Read
model: inherit
---

requests.json の approved_claim と source_ref が欠けるIDを列挙してください。実在商品の正確性を証明する仕事ではありません。外部操作やファイル変更は行いません。

2つの担当の返し方は違います。claim-checker は欠落のあるIDだけを返すので、一覧に出てこないIDは「根拠欄に欠落なし」と読みます。request-checker は判定規則をすべて読むため、根拠欄のコードも含めて全件を返します。この重なりを、次の節で説明する突き合わせに使います。担当を厳密に分けたい場合は、自分の作業用コピーの定義に、返してよいコードを列挙してください。

claim-checker が確かめるのは、根拠欄が空かどうかだけです。「無糖の商品として紹介する」という記載が実際の商品と合っているかまでは確かめません。

注意したい点がもう1つあります。サブエージェントは親の会話履歴を見ず、親が書いた委任メッセージから作業を始めます（Create custom subagents）。今回の記録でも、親が claim-checker に送った委任文は「効能・数値・比較表現など」の確認を求めていて、定義より範囲が広くなっていました。範囲を守らせたい場合は、依頼文にも「欄の欠落だけを見る」と書いてください。

教材を配置して再現する

production-review-practice のZIPを展開すると、同じ名前の最上位フォルダができます。その中に、入力3ファイルが入った exercise/ と、期待結果と照合スクリプトが入った answer-key/ があります。期待結果をAIに見せないよう、exercise/ の3ファイルだけを作業フォルダへコピーします。

mkdir -p ~/cc-practice/request-check
cp production-review-practice/exercise/* ~/cc-practice/request-check/
cp -R /path/to/skills-and-reviewers/.claude ~/cc-practice/request-check/

3行目でコピーしている .claude は隠しフォルダです。この中に2つの担当の定義が入っています。コピーが終わったら ~/cc-practice/request-check/ で新しい Claude Code セッションを開き、実測で使った次の依頼文を送ります。

request-checker と claim-checker にそれぞれ確認を依頼してから、両者の結果を突き合わせてください。requests.json と judging-rules.md を読み、8件すべての不足と矛盾を判定してください。入力を推測で補完せず、規則の基準日を使ってください。results の id、decision、issue_codes、confirmation（誰に何を確認するかを短い日本語で記載）を返してください。外部への送信や制作開始は行いません。

実測では print モードを使い、MCPを使わない条件として次のフラグを付けました。CLIが返したJSONは、ホスト側のスクリプトが保存しています。

cd ~/cc-practice/request-check
claude -p --setting-sources project --strict-mcp-config --mcp-config '{"mcpServers":{}}' "（上の依頼文）"

返ってきたJSONを actual-results.json として作業フォルダに保存してください。答え合わせは、教材の最上位フォルダに戻って実行します。

cd production-review-practice
python3 answer-key/check_result.py ~/cc-practice/request-check/actual-results.json

照合するのは id、decision、issue_codes だけです。confirmation の文章が正しいかどうかは対象外なので、人が読んで確認してください。

親が結果を突き合わせる

突き合わせの規則は次の3つにしています。これは設計の例です。

1. request-checker の結果に8件のIDが一度ずつそろっているかを見ます。欠けや重複があれば、そこで止めます。

2. claim-checker が挙げたIDと、request-checker が missing_approved_claim や missing_source_ref を付けたIDを比べます。食い違ったら親は自分で決めず、人が requests.json の該当欄を確認します。

3. issue_codes が1つでもあれば hold、1つもなければ ready とします。

実測の記録には、親が出した次の2つの呼び出しが残っています。どちらも run_in_background: true でした。

Agent(subagent_type: request-checker, description: 制作依頼の不足・矛盾確認)
Agent(subagent_type: claim-checker,   description: 商品根拠の記載確認)

先に記録の限界を書いておきます。ログには StructuredOutput が3回記録されていて、どれも全8件と全コードを含んでいます。どの出力がどちらの担当のものかは記録から切り分けられないため、この実測は役割分担が守られたことの実証にはなりません。言えるのは、2つの呼び出しが行われ、最終的なJSONが期待結果と一致したということです。

最終的なJSONの内容は次のとおりです。右端の列は、定義上どちらの担当の範囲かを示しています。

同時編集を避ける

2つの担当はどちらも Read しか使えないので、同じファイルを同時に書き換えることは起こりません。統合結果をファイルに残す役は1人に決めておくと、取り違えも防げます。なお、今回の実測では保存をホスト側のスクリプトが行っていて、AIによる書き込みは測っていません。

担当に編集を任せる場合に使える手段も、ドキュメントに載っています（Create custom subagents）。

• isolation: worktree を設定すると、その担当は一時的な git worktree で作業します。

• disallowedTools: Write, Edit を設定すると、ほかのツールは引き継いだまま書き込みだけを外せます。

権限についても補足します。作業ディレクトリ内のファイルの読み取りは、Manual モードでも承認なしで実行されます。バックグラウンドの担当が承認の必要な操作に進むと、その確認はメインのセッションに表示されます。そこでセッション全体に効く許可を選ぶと、その許可は親の会話にも適用されます。特定の担当を使わせたくない場合は、permissions.deny に Agent(claim-checker) のような規則を追加します（Configure permissions）。tools の制限は、Claude Code がその担当に渡すツールを絞る設定です。実際のサービスの認証や最小権限の設計を置き換えるものではありません。

1回の実演で言えることと言えないこと

この記録から言えるのは、この条件で1回実行したところ、最終的なJSONが規則どおりの判定と一致したということだけです。分担しない場合と比べていないため、「並列にすると速い」とは言えません。人の確認時間も記録していないので、作業時間が減ったかどうかもわかりません。各担当は自分でもリクエストを送り、それはメインの会話と同じ利用上限に数えられます。コストの見方は「Claude Codeのタスク費用を把握する」を参照してください。また、根拠担当が見るのは欄の欠落だけなので、商品情報が正しいことの保証にはなりません。

分担せずに同じ手順を毎回呼び出したい場合は、スキルにまとめる方法もあります。比較は「制作確認をSkillsにまとめる」で扱っています。

次の一歩

自分の業務から確認作業を1つ選び、次の用紙に担当と成果物を書き出してください。「行わないこと」と「不一致時に確認する人」が埋まらない場合は、まだ分ける段階ではありません。

担当名:
受け取るファイルと欄:
返す形式（キーとなるIDと項目）:
行わないこと:
使えるツール:
不一致時に確認する人:
実測する項目（時間 / コスト / 人の確認時間）:

用紙が埋まったら、練習セット で同じ分担を一度実行してください。結果は 記録票 の run-log.csv の空いている行に、人の確認時間とあわせて残します。実際の業務データで試す前の社内確認には、法人確認票 を使ってください。論点を行ごとに記入する1つのCSVです。