サブエージェント設計パターン — コンテキストファイアウォール
サブエージェントによるコンテキスト分離（ファイアウォール）パターンを解説し、マルチエージェント構成でのトークン効率と品質向上を実現する手法を示す
サブエージェントとは何か
サブエージェントとは、親エージェント（オーケストレーター）が Task ツールを使って生成する子エージェントのことだ。各サブエージェントは独立したコンテキストウィンドウを持ち、特定のタスクを実行して結果を親に返す。
Orchestrator（親）
├── Task: "DBスキーマを設計して" → Sub-Agent A → 結果
├── Task: "APIルートを実装して" → Sub-Agent B → 結果
└── Task: "UIコンポーネントを作って" → Sub-Agent C → 結果この構造の最大の利点はコンテキストファイアウォール——各サブエージェントが互いのコンテキストを汚染しないことだ。
コンテキストファイアウォールの効果
トークン効率の劇的改善
モノレポで単一エージェントが全レイヤーを扱う場合と、サブエージェントで分離する場合のルールローディングを比較する。
| 構成 | ルールのトークン消費 |
|---|---|
| 単一エージェント（全レイヤー） | 約16,800トークン |
| バックエンド専門サブエージェント | 約4,300トークン |
| フロントエンド専門サブエージェント | 約3,000トークン |
約4倍のトークン削減。しかもこれはルールだけの話で、コードの読み込みも含めると差はさらに広がる。
クロスコンタミネーション防止
フロントエンドのエージェントがバックエンドのルール（DB命名規約、API認証パターン等）を見ることがない。そのため、無関係なルールに引きずられた誤った実装が発生しない。
基本パターン
パターン1: 専門家委任（Specialist Delegation）
最もシンプルなパターン。タスクの種類に応じて専門エージェントに委任する。
<!-- .claude/agents/backend-specialist.md -->
---
name: backend-specialist
description: "バックエンドのAPI・DB・ビジネスロジックを担当する"
tools: ["Read", "Write", "Edit", "Bash", "Glob", "Grep"]
---
## スコープ
- src/api/ 配下のファイル
- src/db/ 配下のファイル
- src/services/ 配下のファイル
## スコープ外（触らない）
- src/components/
- src/pages/
- public/
## ルール
- APIレスポンスは必ず型定義する
- エラーハンドリングを必ず実装する
- テストを同時に書く親エージェントの使い方:
Task: "ユーザー一覧APIを実装して。backend-specialist を使って。"パターン2: フェーズ分離（Phase Isolation）
TDD記事で詳述した、開発フェーズごとにエージェントを分離するパターン。
Phase 1: テストライター → 失敗するテストを書く
Phase 2: 実装者 → テストを通す最小実装
Phase 3: リファクタラー → コード品質を改善各フェーズのエージェントは前フェーズの出力のみを入力として受け取る。実装計画やリファクタリング意図がフェーズ間で漏洩しない。
パターン3: 並列実行（Parallel Execution）
独立したタスクを複数のサブエージェントで並列実行する。
Orchestrator
├── [並列] Task A: "認証ミドルウェアを実装"
├── [並列] Task B: "ロギングユーティリティを実装"
└── [依存] Task C: "A, Bを使ってAPIルートを実装" (A, B完了後)Git worktree を使えば、各エージェントが独自の作業ディレクトリを持ち、マージコンフリクトなく並列作業できる。
# ワークツリーの作成
git worktree add ../project-auth feat/auth
git worktree add ../project-logging feat/logging推奨チーム規模は3〜5エージェント。トークンコストは線形にスケールするため、これを超えるとオーケストレーションのオーバーヘッドが利益を上回る。
パターン4: 階層的オーケストレーション（Teams of Teams）
6つのタスクを1つのリードが管理する代わりに、2つのフィーチャーリードがそれぞれ3つの専門家を管理する。
Orchestrator
├── Feature Lead: 認証
│ ├── DB スペシャリスト
│ ├── API スペシャリスト
│ └── テストスペシャリスト
└── Feature Lead: ダッシュボード
├── UI スペシャリスト
├── データフェッチスペシャリスト
└── テストスペシャリスト各フィーチャーリードがコンテキストの境界を管理するため、トップレベルのオーケストレーターは軽量に保てる。
品質ゲートの実装
サブエージェントの出力を無条件に受け入れるのは危険だ。品質ゲートを設置する。
計画承認ゲート
## ワークフロー
1. サブエージェントは実装前に計画を提出する
2. 親エージェント（またはHook）が計画をレビューする
3. 承認後に実装を開始する自動検証ゲート
Hook を使い、サブエージェントのタスク完了時に自動検証する。
{
"hooks": {
"PostToolUse": [
{
"matcher": "Task",
"hooks": [
{
"type": "command",
"command": "npm run test -- --run && npx biome check ."
}
]
}
]
}
}サブエージェントの結果がテストやリントに通らなければ、親エージェントはタスクを再実行するか、問題をフィードバックする。
AGENTS.md による累積学習
サブエージェントの運用で得られた知見を AGENTS.md に蓄積する。
<!-- AGENTS.md -->
## 学習事項
- DBマイグレーション時はスキーマのバックアップを先に取る
- React Server Componentsではuse clientを忘れやすい
- APIテストではレスポンスの型チェックも含める研究では、人間が書いた AGENTS.md は成功率を約4%向上させる一方、LLMが自動生成した AGENTS.md は効果がないか、むしろ推論コストを20%増加させるという結果が出ている。知見の蓄積は人間が行う必要がある。
Ralphループパターン
長時間の自律稼働に適したパターン。ステートレスだが反復的な実行を行う。
1. タスクリストからタスクを選択
2. 実装
3. 検証（テスト、型チェック、リント）
4. パスしたらコミット
5. コンテキストをリセット
6. 1に戻る外部メモリはGit履歴、進捗ログ、タスク状態、AGENTS.md を通じてリセットを超えて永続化する。各ループが独立したサブエージェントのように振る舞い、コンテキストの肥大化を防ぐ。
検証がボトルネック
Addy Osmani が指摘する通り、「ボトルネックはもはや生成ではなく検証だ」。エージェントは驚異的な速度で出力を生成できるが、その出力が正しいかどうかの判断こそが難しい。
並列エージェントの速度は、小さなミスをシステム的な負債に複合化させる。人間のレビューは最終防衛線として不可欠だ。
3層の運用モデル（2026年）
| Tier | 形態 | ユースケース |
|---|---|---|
| Tier 1 | Claude Code サブエージェント | 対話的な開発作業 |
| Tier 2 | ローカルオーケストレーター（3〜10エージェント） | 並列スプリント |
| Tier 3 | クラウド非同期エージェント | バックログの消化（一晩放置） |
多くの開発者は3つの Tier を状況に応じて使い分ける。Tier 1 で対話的に作業し、Tier 2 で並列に開発を進め、Tier 3 でバックログを一晩で処理する。
実践ポイント
- 仕様の精度がレバレッジ: 50のエージェントを並列で動かすとき、曖昧な仕様はエラーを乗算する。仕様を書く時間は惜しまない
- pass/fail 基準を明確に: 各サブエージェントに「何をもって完了とするか」を明示する
- スコープを狭く保つ: 1つのサブエージェントが扱うファイル範囲を明確に限定する
- 人間が判断すべきこと: アーキテクチャの決定、「何を作らないか」の判断、全体コードレビューは委任しない
- 段階的に規模を拡大する: まず2〜3エージェントで運用し、成功パターンを確立してからスケールする