「Claude Codeに大きめのタスクを任せたら、途中から仕様が抜け落ちた」「最初は良かったのに、後半のレビューが甘くなった」。受託開発の現場でClaude Codeを使い始めたチームから、こうした声をよく聞きます。
原因の多くは、能力ではなく1セッションに役割を詰め込みすぎていることです。計画・実装・レビューを同じ文脈窓で回すと、長くなるほど初期の前提が薄まり、判断が場当たり的になります。
この記事では、サブエージェントを使ってClaude Codeを「planner（計画役）」「writer（実装役）」「reviewer（レビュー役）」の3レイヤーに分割する設計を紹介します。役割分担で文脈窓を守りながら、長い作業の品質と速度を両立させる運用テンプレートです。
なぜ「1人で全部」だと精度が落ちるのか
Claude Codeに限らず、生成AIは扱える文脈に上限があります。1セッションで設計討議・実装・レビュー・修正を全部こなすと、後半に入る頃には以下が起きがちです。
- 序盤で合意した非機能要件（性能・セキュリティ・運用制約）が暗黙化する
- 直近のコード差分に注意が引っ張られ、全体整合のチェックが甘くなる
- 自分が書いたコードを自分でレビューする状態になり、欠陥に気付きにくい
人間のチーム開発でも、設計者と実装者とレビュアーが同一人物になると品質が落ちる、という話はよく出ます。同じことがAIエージェントにも起きている、というのが運用上の前提です。
レビュー観点そのものの整理はAI生成コードのレビューが甘くなる前に｜現場で効く4観点で扱っています。本記事は、その「観点」を誰に持たせるかという分担設計の話だと考えてください。
3レイヤー設計の全体像
サブエージェント運用は、ざっくり次の3層に分けて考えると現場で機能します。
planner：要件と設計の番人
役割は、タスクのゴール・制約・成功条件を文章で固定することです。具体的には次を出力させます。
- 入力前提（対象ファイル、依存範囲、触ってはいけない領域）
- ゴールと完了条件（何が動けばOKか、何はスコープ外か）
- リスクと検証観点（壊れやすい箇所、最低限のテスト方針）
このアウトプットは、後続のwriter・reviewerに渡す共通仕様書になります。ここを口頭の指示で済ませると、後段に入った瞬間に設計の根拠が消えます。
plannerが仕様書として生成するドキュメントのフォーマットの例です。
# タスク仕様書: [タスク名 / Issue #]
## 入力前提
- 対象ファイル: `src/auth/login.ts`、`src/auth/session.ts`
- 依存範囲: `src/lib/` 配下（読み取りのみ可）
- 触ってはいけない領域: `src/middleware/`、DBマイグレーションファイル
## ゴールと完了条件
- ゴール: ログイン処理の読みやすさを改善し、新人が5分で流れを追える状態にする
- 完了条件①: `login.test.ts` の全テストが通る
- 完了条件②: `POST /api/login` のリクエスト・レスポンス形式が不変
- スコープ外: エラーメッセージ文言の変更、セッション層の変更
## リスクと検証観点
- 注意箇所: Auth0 トークン検証ロジック（外部依存）
- 最低限のテスト: 正常ログイン / 認証失敗 / トークン期限切れの3ケースwriter：実装に集中するエージェント
writerには、plannerが作った仕様書だけを渡します。ここで重要なのは、writerに設計を再議論させないことです。
- 仕様書に書かれていない判断は「TODOコメント」として残させる
- 触ってよい範囲を明示し、横展開のリファクタは禁止する
- 出力はパッチ（差分）と変更要約に限定する
「ついでに直しておきました」をAI側にやらせ始めると、レビューコストが跳ね上がります。役割を狭く切ることで、人間レビュアーの負担を下げます。
reviewer：別セッションで読む第三者
reviewerは、writerとは別のセッションで起動します。渡すのはplannerの仕様書とwriterの差分のみで、writerが内部的に使った試行錯誤のログは渡しません。
- 仕様書の完了条件を満たしているか
- 暗黙仕様（既存のエラー処理・ログ・命名規則）を破っていないか
- テスト観点が不足していないか
「同じ文脈で書いた人がレビューしない」という単純な原則を、エージェントの分け方で機械的に担保するのがポイントです。
reviewerの観点をチェックリスト化する場合、スラッシュコマンド（.claude/commands/review-impl.md）として置くのがおすすめです。
---
description: "writerの差分をレビューし、仕様書との整合性を確認する"
---
以下の3観点で差分をレビューし、問題があればファイル名・行番・重要度（must/should/nits）で指摘すること。
## 検証観点
1. **完了条件の充足**: plannerの`完了条件①②`を一つずつ確認する
2. **暗黙仕様の違反**: 正常終了時のログ形式・エラー消辺方法・命名規則が既存コードと一貫しているか
3. **テスト不足**: スコープ内の差分に対して异常系・境界値テストが存在するか
## レビューしないこと
- writerの作業模機や試行錯誤のログ（仕様書と差分のみ判断する）
- スコープ外のファイルのコード品質（今回のタスク範囲外）受託現場に落とすときの3つの実装ポイント
3レイヤーをそのまま導入してもうまくいかないことがあります。受託開発の現場で運用に乗せるときは、次の3点がポイントになります。
1. plannerの出力を「ファイルとして残す」
仕様書は会話の中ではなく、docs/ や Issue 本文など永続化される場所に置きます。会話の中だけに置くと、再開時にplannerをやり直すコストが発生し、結局1人で全部やる運用に戻ります。
2. writerに渡すスコープを物理的に絞る
「このディレクトリ配下だけ」「このファイルだけ」のように、writerが触れる範囲をリポジトリ構造で絞り込みます。レガシーコードに対する文脈設計はClaude Codeにレガシー調査を任せる4点設計が参考になります。
writer専用のCLAUDE.mdスニペットの例です。
## writerモードの運用ルール
### 触ってよい範囲
- `src/auth/login.ts`、`src/auth/session.ts` のみ
- 既存テストファイル（修正は可、削除は不可）
### やってはいけないこと
- 仕様書（`docs/task-spec/`）の内容を変更しない
- スコープ外のファイルをリファクタしない（追加修正の展開禁止）
- `git commit` / `git push` を自分で実行しない（提出は人間が行う）
### 出力フォーマット
- 修正差分（unified diff形式）
- 判断できなかった箇所は `TODO: 要確認 — [reason]` コメントで残す3. reviewerの観点をチェックリスト化する
reviewerに毎回同じ観点を出させるため、レビュー観点をプロンプト側にチェックリストとして埋め込みます。これがないと、reviewerが「全体的に良さそうです」で終わるリスクが高まります。
PMとテックリードの線引き
3レイヤー運用は、エンジニアだけの話ではありません。PMやテックリードがどこに入るかを決めておかないと、結局「AIが書いたコードの最終責任者が不在」という状態になります。
- planner段階では、PMがスコープと完了条件にレビューを入れます。
- writer段階では、テックリードが触ってよい範囲を確定します。
- reviewer段階では、人間レビュアーが最終判断を持ちます（マージ責任者を1人決める）。
PM側の関わり方の基本線はPMがClaude Codeを使うときの3ルールで整理しています。サブエージェント設計は、その3ルールをチーム運用に展開した形だと捉えられます。
まとめ：役割を狭く切ると、Claude Codeは速くなる
Claude Codeで成果を出しているチームほど、1セッションに何でも詰め込まず、planner・writer・reviewerに役割を分けています。文脈窓を守るための設計だと考えると、「分けたほうが速い」が直感的になります。
- 1人で全部やらせると、長くなるほど精度が落ちる
- planner・writer・reviewerの3レイヤーで文脈窓を分割する
- PM・テックリードはレイヤーごとに最終判断の所在を決めておく
テックエイドの「AIX-101」と「AIX-102」では、こうしたサブエージェント設計を含む「実装×レビュー分離」の運用パターンを、受託開発の現場を題材に手を動かしながら学べます。チームでAIを定着させたいPM・マネージャーの方は、関連講座をぜひご確認ください。