この記事は playpark Blog からの転載です。

この記事で分かること

Claude Code Agent のTask toolでsubagentを「分業させる」運用に至った背景
4種類の専門subagent（architect / implementer / reviewer / test-writer）に分けた検証設計
並列起動から得られた判断材料（速度・トークン消費・統合コスト）

背景: こういう疑問があった

Claude CodeのTask toolでsubagentを並列起動できるのは知っていた。ただ「1つのagentに全タスク投げる」のと「役割ごとにagentを分ける」で、どちらが実案件で機能するのかは正直分からなかった。

「役割を分けたほうが綺麗そう」というのは設計者の感覚論であって、トークン消費・実行時間・統合コストを含めて優位かどうかは別問題。受託案件で約1ヶ月回した上で、判断材料を残す。

仮説

仮説1: 役割を分けるとsubagentごとの読込ファイル数が減り、トークン消費は単純合算より小さくなる
仮説2: subagent並列化は統合フェーズで詰まり、「4並列 = 4倍速」にはならない
仮説3: tools: を絞ることでsubagentの「逸脱」（レビューのはずがリファクタリング）を抑止できる

検証設計

項目	内容
検証対象	Claude Code Agent (Task tool + `.claude/agents/`)
検証案件	採用管理システムの受託開発（2人チーム）
期間	約1ヶ月
比較対象	「メインセッション単独」vs「4分業 + 並列起動」
測定	usage ログのトークン消費、PR数、マージまでの時間

4分業の役割設計

Subagent	担当	渡す `tools:`
architect	スキーマ変更・API設計・影響範囲の洗い出し	Read, Grep, Glob
implementer	コード実装・マイグレーション生成	Read, Edit, Write, Bash
reviewer	diffレビュー・設計ポリシー準拠チェック	Read, Grep, Bash
test-writer	Vitest ユニット/統合テストの追加	Read, Edit, Write, Bash

なぜこの4分業かと言うと、それぞれ読むべきコンテキストの粒度が違うから。architect は「DBスキーマ + API全体」を俯瞰する必要がある一方、implementer は「今触っているファイル周辺」だけ深く読めば済む。同じタスクを1つのagentに投げると、全部を読み込もうとしてトークンが膨らむ。

検証コード: subagent定義の最小例

---
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してリファクタリングを始める事故を防げる。

結果

仮説	結果	判定
仮説1: トークン削減	各subagentで読込ファイル数が体感1/3〜1/4に	△（並列分の重複で総量は1.3〜1.6倍）
仮説2: 統合律速	マージフェーズが最大ボトルネック	○
仮説3: 権限縛り	Edit/Writeを渡さないreviewerは指摘のみで止まる	○

仮説1は「ファイル単位の読込は減るが、並列起動分のオーバーヘッドで総トークンは増える」という形で部分的にしか成立しない。「役割分業 = トークン節約」とは単純に言えない。

仮説2は明確に成立した。並列で4本走らせても、統合フェーズで人間（とメインセッション）が手作業を入れる必要があり、ここを設計しないと速度効果がほぼ消える。

結論: どう判断すべきか

「subagentを並列で増やせば速くなる」ではなく「統合可能な単位に分解できれば速くなる」が正しい。サブスク枠（Claude Pro / Max 5x / Max 20x / Teams）でAgentを並列実行すること自体は現実的だが、速度効果は事前のファイル境界分析と統合フローの設計に依存する。

最初から4並列を組まず、まず reviewer 1本だけ を .claude/agents/pr-reviewer.md に切り出すところから始めるのを推奨する。指摘の質が安定してから implementer / architect / test-writer を順に増やすと、統合事故が起きにくい。

さらに深掘りしたい方へ

この記事ではsubagent分業に至った背景と検証設計を中心に解説しました。

【Claude Code Agent】Task toolで専門subagentを並列起動し、採用AI案件を分業した実践 ではさらに：

1日の並列実行ログ（Textarea / レスポンシブ / 評価サマリ / 楽観ロック改善）
Claude Pro / Max (5x / 20x) / Teams プランごとの運用コスト感
subagent同士を会話させないHub-and-spoke構成の判断理由

を扱っています。

playpark について

playpark LLC - 業務自動化・AI活用・Web開発

お問い合わせ | ブログ