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