Issue一覧を眺め、ふと手が止まる。
「DB設計の修正、UIのレスポンシブ化、Vercel DeployのDB接続エラー、Textareaの高さバグ...1週間でいけるか？」
2人チームの受託開発で、残タスクが10件以上並ぶことは珍しくありません。人間を増やせないならClaude Code Agent を増やすしかない。順番に倒すんじゃなく、同時に。
今回は採用管理システムの受託開発で、Task tool から専門subagentを並列起動し役割分担させた記録です。この記事では 設計・実装・レビュー・テストを別々のsubagentに分業させる運用アーキテクチャ を中心にまとめます。
この記事で話すこと
- Task tool / subagent で役割分担するとなぜ速いのか
- 設計/実装/レビュー/テストを分けた4つの専門subagentの設計
- 実案件で使ったプロンプト雛形と設定例
- 並列実行のハマりどころ（マージ競合・コンテキスト膨張・料金）
- Claude Max / Teams プランでの運用コスト感
採用AIシステムそのものの話はAI書類選考の受託開発事例に、全体プロセスはClaude Codeで受託開発を1週間で回した話にまとめました。本記事はその続編で、Agent運用のレシピだけを抜き出したものです。
そもそもClaude Code Agentの「subagent」って何なの
Claude Code には Task tool という別Agent派遣用の組み込みツールがあります。これを経由すると別の独立した会話コンテキストを持つAgentを起動できる。これが subagent です。
使い方は2パターンに大別できます。
| 使い方 | 何に向くか | 例 |
|---|---|---|
| 一発派遣 | タスクを丸投げして結果だけ返す | 「TextareaバグのPRレビューだけやって」 |
| 並列派遣 | 独立タスクを複数まとめて起動 | 「フロントUI修正・API修正・マイグレーション作成を同時進行」 |
ポイントは、各subagentが自分のコンテキストだけで完結するところ。過去の会話履歴を引き継がずトークン節約になり、専門人格を演じさせやすい。
素のままTask toolを呼ぶと毎回「君はレビュワーだ」と説明する羽目になります。これがダルくなり、.claude/agents/ に役割ごとのsubagent定義を置いて使い回すやり方に落ち着きました。
4つの専門subagentに分けた理由
採用AI案件で最初に試したのは「全部メインセッションで進める」でした。5万トークンを超えたあたりから応答が遅くなり、修正の手戻りも増える。
そこで役割ごとに切り出しました。落ち着いたのが次の4つです。
| Subagent | 担当 | 主なTool |
|---|---|---|
| architect | スキーマ変更・API設計・影響範囲洗い出し | Read, Grep, Glob |
| implementer | コード実装・マイグレーション生成 | Read, Edit, Write, Bash |
| reviewer | diff レビュー・設計ポリシー準拠チェック | Read, Grep, Bash(git diff) |
| test-writer | Vitest テストの追加 | Read, Edit, Write, Bash(test) |
なぜこの4分業かと言うと、読むコンテキストの粒度がまるで違うからです。
- architect は「DBスキーマとAPIルーティング全体」を俯瞰する必要がある
- implementer は「今触っているファイル周辺」だけ深く読めばいい
- reviewer は「git diff の差分」を起点に前後関係を追えばいい
- test-writer は「実装ファイル」と「既存テストの書き方」だけで済む
同じタスクを1つのagentに投げると全部読み込もうとしトークンが爆発します。専門化すると各subagentが読むファイル数が1/3〜1/4に減りました。
設定：.claude/agents/ にsubagentを定義する
プロジェクトルート直下の .claude/agents/<name>.md に置くと自動で subagent 登録されます。共通で使う場合は ~/.claude/agents/ に置きます。実際に使っている reviewer agentの定義を載せます。
---
name: pr-reviewer
description: |
指定されたPR（またはブランチ）のdiffをレビューする専門agent。
Use when: PR番号やブランチ名を指定してレビュー依頼されたとき。
tools: Read, Grep, Bash
---
# PR Reviewer
あなたは採用管理システムのコードレビュー担当です。
## レビュー観点
1. **型安全性**: any が混入していないか、Zod validation が通っているか
2. **楽観ロック**: updatedAt ベースの競合検出が外れていないか
3. **権限**: admin / assistant の分岐が実装ポリシーに沿っているか
4. **テスト**: 新しい分岐にテストが追加されているか
## アウトプット
- 🔴 Must Fix（マージブロッカー）
- 🟡 Should Fix（強く推奨）
- 🟢 Nice to Have
指摘は**根拠となる行番号**と**修正案**をセットで返すこと。
ここで効くのが tools: の絞り込みです。reviewerに Edit や Write を渡すと勝手にコードを書き換え始め「レビューのはずがリファクタリング大会」になります。権限を絞ることで人格がブレない。
implementer 側は逆に Edit, Write, Bash までフル装備です。代わりに「設計判断はしない」「architectの出力を前提に動く」と明記しています。
並列実行の実例：採用AI案件のある1日
実際に走らせた日の記録。朝積まれていたのはこれ。
- Textarea の
field-sizing-content由来の巨大空白バグ（UIコンポーネント修正） - 全画面レスポンシブ対応タスク
- 選考評価サマリのUI改善
- 内部管理セクションの楽観ロック競合改善
この4つ、ファイル境界がほぼ被っていないのがポイント。Textareaバグは components/ui/、レスポンシブは app/candidates/ 配下です。評価サマリは components/evaluation/、楽観ロックは api/candidates/[id]/ と prisma/。独立なら同時に走らせられます。
メインセッションからこう起動しました。そのままコピペで投入できる最小形です。
Task(architect): 楽観ロック改善の設計を作って。
影響範囲・DBマイグレーション要否・API仕様変更の有無を返す。
Task(implementer): Textarea の field-sizing-content 削除を実装。
既存Textareaのmin-h-16は維持すること。
Task(implementer): 選考評価サマリのUI改善3点をブランチ evaluation-ui に実装。
Task(test-writer): 楽観ロック改善のAPIに対する統合テストを追加。
architectの出力を待ってから着手。
architect と最初の implementer、UI改善 implementer は完全並列。test-writer だけ architectの出力待ちです。
ファイル境界を分析してからぶん投げる
素直に並列起動すると、2つのsubagentが同じファイルを触ってコンフリクトする事故が起きます。最初の数回で学び、今は「これとこれは独立」を確認してから分散させています。分析はAgent自身にやらせるのが一番早いです。
メインセッション: 以下4つのタスクのファイル境界を分析して、
並列実行できる組み合わせを返して。
[Textareaバグ修正, レスポンシブ対応, 評価サマリUI改善, 楽観ロック改善]
返ってくるのは「Textareaバグ修正と評価サマリUI改善は独立」「レスポンシブ対応は評価サマリUI改善と同じpageを触る可能性あり、直列推奨」といった判定です。worktreeでの分解パターンを敷けば、subagentごとに作業ディレクトリを切れます。
料金の話：Claude Teams / Max プランだと現実的か
「料金」で検索して来た方もいると思うので正直に書きます。
subagentを並列起動すると、トークン消費は起動した数だけ増えます。4タスクを逐次処理したケースと4つの subagent 並列で処理したケースを usage ログで比較しました。並列版で1.3〜1.6倍くらいの消費でした（独立コンテキストなので単純4倍にはならない）。
2026年4月時点でこんな整理です。
| プラン | Agent運用との相性 | 体感 |
|---|---|---|
| Pro | 1日数本なら | 並列3本までが安全圏 |
| Max (5x) | 個人受託の主戦場 | 並列実行を気にせず回せる |
| Max (20x) | 複数案件の並行運用 | 1週間で48PR出した本案件ではこれ |
| Teams | チーム共有・管理が必要な規模 | 使用量の可視化が地味に効く |
Teamsプランで助かるのが消費量ダッシュボード。「この案件でどれだけAgent使ったか」を出さないとコスト運用ができないので、月末の精算に直結する機能です。
個人開発やスポット受託なら Max (5x) から始め、必要なら上げれば十分です。
ハマったポイント3つ
きれいな話ばかりになりそうなので、失敗も残します。
1. subagentが「前の自分」の存在を知らない
同じsubagentに連続で依頼しても新しい会話として起動されるため前回の判断を覚えません。「さっき直したファイル」は通じない。
対策は、文脈をプロンプトに明示的に詰めて渡すこと。ケチるとreviewerが「なぜこの実装か理解できない」と言い、マージ済みコードにMust Fixを付けてきます。
2. 並列実行中のマージが一番の難関
worktreeを切って並列にぶん投げた後、手動マージの段で詰まります。各subagentは自分のブランチの中でしか動かないので統合フェーズで人間が汗をかきます。
最近は dev-integrate のような統合専用skillを用意し、マージ順序・競合予測・テスト実行までパイプライン化しています。詳しくは分解と統合に書きました。
3. reviewerがレビュー厳しすぎ問題
pr-reviewer をちゃんと設計すると人間より厳しい指摘を返してきます。型ガードの漏れ、テストカバレッジの穴、命名の一貫性...全部拾ってくる。
嬉しいようで納期前はつらい。運用は Must Fix以外は差分PRに回す ルールにして初回レビューで止まらないようにしました。完璧を求めるとマージできない、という受託あるあるはAIでも起きます。
設計のキモ：Agent同士を会話させない
最後にやらないほうがいいことを1つ。subagent同士を直接会話させる設計は忘れましょう。
理論上は「architectの出力を implementer が読み、reviewer が結果を読む」と連鎖させたくなります。でも途中で誤解すると誤解が下流にそのまま伝播します。しかも中間の判断がメインに見えない。
今の運用は Hub-and-spoke（メインがHub、subagentがspoke）。メインが結果を見て次を決める。遠回りに見えて、中間成果をメインが検閲できるので事故が少ないです。
Agent Team の協調設計でも同じ結論に至っています。
まとめ
今回の話を短く要約します。
- 1本のsubagentで全部やらせるな。役割で切れ。 architect / implementer / reviewer / test-writer の4分業が基準
.claude/agents/に人格とtools:を定義し、権限で人格をブレさせない- 並列起動の前にファイル境界分析をやらせる
- 料金は案件単位のトークン消費を月次で追うのが現実的
- subagent同士を会話させず、メインがHubとして中間成果を検閲する
採用AI案件では、この運用にしてから1週間で48PRを出せました。最初からこの体制だったわけではなく、数日は1人でやり「分業しないと終わらないな」と気づいたところから増やしていった順番です。
いきなり4並列はやりすぎです。まずは reviewer だけ を .claude/agents/pr-reviewer.md に切り出すところから始めるのがおすすめです。人間より早く丁寧に指摘が返ってきた瞬間、「景色が変わるな」と手応えが出ます。implementer、architect、test-writer と増やせば、チームに4人（？）増えています。
夜中に1人で全PRレビューしていた自分に、このやり方を教えてあげたい。
