Claude Code: サブエージェントの成果物が8.6倍に膨れ上がる理由
TL;DR
- サブエージェントに対話的タスクは向いていない
- 過剰出力傾向は「セッション独立性」という設計思想に起因する
- 対話的タスクではコンテキスト節約効果も活かせない
はじめに
Claude CodeでのSDD（仕様書駆動開発）やエージェントワークフローで、出力された要件定義書や仕様書のボリュームが想定以上で、レビューや修正にうんざりしたことはありませんか？
一見、詳細に記述された成果物を出すのは悪いことではないように見えます。
しかし、用語定義、承認欄、変更履歴、アクセシビリティ要件……頼んでもいない項目が山盛りで返ってきたら、それは本当に「良い仕事」でしょうか？
実は、その原因はサブエージェントに対話的タスクを任せていることかもしれません。
前回の記事では、Claude Codeのサブエージェントがメインとコンテキストが完全に分離されていることを確認しました。
今回は、それを踏まえて浮かんだ疑問「サブエージェントは対話的タスクに向くのか」を、Claude Codeへの直接ヒアリングと実験の両面から検証。
結論として、対話的タスクにサブエージェントは向いていないことが明らかになりました。
まずはClaude Codeに聞いてみた
内部ツールの事情を1番理解しているのは本人だろうと思ったので、まずはClaude Code自身に投げてみました。
実際にサブエージェントで要件定義（対話的タスク）を行った後、そのセッション内で率直な評価を求めました。
対話的タスクとサブエージェントの相性は良くない
質問: 今回、サブエージェントで対話的タスク（要件定義）を行いましたが、サブエージェントは対話的タスクに向いていると思いますか？率直な意見を聞かせてください。
Claude Codeの回答（要約）：
率直に言うと、サブエージェントは対話的タスクにはあまり向いていないと考えます。
対話的タスクには、カスタムスラッシュコマンドの方が適していると思います。
スラッシュコマンドはメイン会話内で展開されるため、コンテキストを自然に維持できます。
Claude Codeは、その理由も説明してくれました。
理由1: ステートレスな設計との相性が悪い
[サブエージェント] → 質問を生成
↓
[メインエージェント] → ユーザーに質問を中継
↓
[ユーザー] → 回答
↓
[メインエージェント] → 回答をまとめて新しいサブエージェントに渡す
↓
[サブエージェント（新規）] → 前回のコンテキストを再度読み込み...
対話のたびにコンテキストの再構築が必要。
理由2: 中継コストが高い
- トークン消費が増大
- 情報が間接的になり、ニュアンスが失われるリスク
- 対話のリズムが遅くなる
理由3: 本来の用途との乖離
サブエージェントは以下のような自己完結型タスクに向いている：
- コードベースの探索・検索
- ファイルの分析・レビュー
- 定型的な処理の実行
続けて、新しいセッションでサブエージェントが向いているタスクについても確認しました。
セッションを変えたのは、上記の会話による対話タスクは向かないと自己言及したバイアスを取り除きたかったからです。
質問: サブエージェントの特性を活かした機能の例はありますか？
Claude Codeが挙げた活用パターン：
1. 専門化による探索的な処理
| 専門領域 | 活用例 |
|---|---|
| コードレビュー | 品質・セキュリティ・保守性の審査 |
| デバッグ | エラー原因分析、テスト失敗調査 |
| 要件定義 | 必要な情報を収集して文書作成 |
| コードベース探索 | 大規模プロジェクトの構造把握 |
※「要件定義」については後述の追加質問で深掘りします。
2. 並列実行による効率化
メインエージェント
├─ サブエージェントA（コードレビュー）
├─ サブエージェントB（セキュリティ解析）
└─ サブエージェントC（パフォーマンス分析）
→ 各分析が独立コンテキストで同時進行
3. コンテキスト分離のメリット
- メイン会話の汚染防止
→長い調査ログがメイン会話に残らない - 専門コンテキスト維持
→各サブエージェントが専門領域に集中 - 結果のみ返却
→必要な結論だけをメインに報告
「要件定義」は本当にサブエージェント向きか？
ここで興味深い点に気づきました。
Claude Codeは活用例として「要件定義」を挙げていますが、先の質問では「対話的タスクに向かない」と回答しています。
この矛盾について追加で質問しました。
質問: 先ほど要件定義を活用例として挙げましたが、対話のたびにメインが仲介する必要がありました。要件定義のような対話的タスクは、サブエージェントに向いていると思いますか？
Claude Codeの回答：
現在のサブエージェントアーキテクチャは対話的タスクには向いていません。
サブエージェントの設計上の制約
| 特性 | 内容 |
|---|---|
| ステートレス | 各呼び出しは独立、前回の会話を保持しない |
| 単一返却 | メインに1回だけ結果を返して終了 |
| 間接対話 | ユーザーと直接やり取りできない |
要件定義でもサブエージェントが向いているケース
| パターン | 適性 |
|---|---|
| 対話の収集・進行 | ❌ メインが担当すべき |
| 収集済み情報の分析 | ✅ サブエージェント向き |
| 要件書の構造化・整形 | ✅ サブエージェント向き |
| 要件の検証・矛盾チェック | ✅ サブエージェント向き |
より適切な設計
メインエージェントが対話を担当
↓
対話完了後、収集した情報をサブエージェントに渡す
↓
サブエージェント：分析・構造化・文書生成
↓
成果物をメインに返却
つまり、参照できる情報源があって自律的に動けるなら、要件定義の一部（分析・構造化）もサブエージェント向きと理解しました。
これは実装やデバッグなどのタスクも同様と思われます。
実験で検証
では、実際にサブエージェントで対話的タスクを行った実験を見てみましょう。
使用モデルはリリースほやほやのOpus 4.5(claude-opus-4-5-20251101)です。
余談ですが、凄いモデルですよね。
速さと精度が段違いで、今まで滞っていた仕事がどんどん進んでいく感覚があります。
実験設計
TODOアプリの「優先度自動調整機能」の要件定義を、サブエージェントとカスタムスラッシュコマンドの両パターンで実施。
両者とも以下のシンプルな定義で実験しました：
ユーザーと対話しながら、機能の要件を明確に定義してください。
以下の項目を確認してください：
- 機能の目的
- 主要な機能
- 優先順位
- 制約事項
要件定義書を出力ディレクトリにマークダウン形式で作成してください。
- 対話を通じて要件定義書（機能仕様書）を作成
- 作成後に「手動調整機能も残したい」と修正依頼
カスタムスラッシュコマンドはメイン上で実行されるため、「サブエージェント vs メイン実行」の比較となります。
対話フローの違い
サブエージェント:
1. 初回質問（詳細な選択肢6問） → Task終了
2. 回答を受けて追加質問（4問） → Task終了
3. 文書作成（266行） → Task終了
4. 修正依頼 → 詳細質問（10問） → Task終了
5. 回答を受けて大幅更新（560行） → Task終了
カスタムスラッシュコマンド:
1. 初回質問（目的について）
2. 追加確認（トリガー条件）
3. 具体的なルール確認
4. 制約事項確認
5. 開発方針確認
6. 文書作成（61行）
7. 修正依頼
- 選択肢3つ提示（手動設定の優先順位について）
- 回答に基づいて4行追加（65行）
印象として、サブエージェントを使った場合は、1度に複数の質問を投げられやすいです。
対してカスタムスラッシュコマンドでの対話は1問1答が多く、ユーザとの往復を増やしがちです。
ここは、後述の設計思想が表れているポイント。
重要な違いは、サブエージェントでは会話の往復ごとにセッションが終了している点です。
Claude Codeに直接確認したところ：
質問: （会話のやり取りの中で）サブエージェントのセッションは継続していますか？
回答: いいえ、サブエージェントのセッションは継続していません。各Task呼び出しは独立したセッションです。サブエージェントはタスクを完了すると自動的に終了します。
成果物の比較
| 項目 | サブエージェント | カスタムスラッシュコマンド |
|---|---|---|
| 初回成果物 | 266行 | 61行 |
| 修正後成果物 | 560行 | 65行 |
| 成果物比率 | 約8.6倍 | - |
| 詳細度 | 過剰（用語定義、承認欄、変更履歴、アクセシビリティ要件等、指示していない要件を含む） | 必要十分（指示に相応なシンプルな構成） |
| ユーザー意向の反映 | 網羅性優先 | 定義に忠実 |
サブエージェントは指示していない「用語定義」「承認欄」「変更履歴」「将来拡張」「アクセシビリティ要件」まで勝手に追加していました。
最終的な成果物は、カスタムスラッシュコマンド時の約8.6倍にも及ぶ超大作です。
あれほどシンプルな定義と指示なのに…これでは成果物のレビューで苦しむのも当然です。
引き続き、実験結果を確認していきましょう。
修正時の挙動
「手動調整機能も残したい」という修正依頼に対して：
サブエージェント: 10問の詳細質問を行い、確認後に約300行追加（UI/UX要件、一括変更機能、確認ダイアログ、変更履歴機能、変更理由・メモ機能など）
カスタムスラッシュコマンド: 選択肢3つ（手動設定優先/高い方を採用/一時的）を提示 → 回答に基づいて4行追加
プロンプト忠実度
今回の実験で、プロンプト忠実度にも差があることが判明しました。
| 観点 | サブエージェント | カスタムスラッシュコマンド |
|---|---|---|
| 出力先 | 指定と異なるディレクトリに出力 | 指定通り |
| 質問内容 | 定義にない項目（通知機能等）も質問 | 定義に沿った質問 |
| 成果物の範囲 | 定義を大幅に超える内容 | 定義に忠実 |
メインがサブエージェントに指示を渡す際に「気を利かせて」定義にない項目を追加してしまう傾向が見られました。これはメイン→サブの伝達過程で「編集」が入ることが原因と考えられます。
コンテキスト消費
それぞれ成果物を出力・修正した後に/contextを実行して消費量を比較しました。
サブエージェント: Messages 25.6k 12.8%
カスタムスラッシュコマンド: Messages 5.6k 2.8%
差分: 約20k (10%)
今回の実験では、対話的タスクではコンテキスト節約効果がないことが確認できます。
それどころか、サブエージェントの方がコンテキストを約5倍多く消費するという結果でした。
なお、メインセッション上でのコンテキスト消費は上述通りですが、実際にはサブエージェント内で使ったメインには隠蔽された消費もあるので、アカウント単位での消費トークン数という観点ではより大きな差が出ると思われます。
なぜサブエージェントは過剰出力になるのか
実験結果とClaude Codeの説明から、サブエージェントの過剰出力傾向の原因が見えてきました。
セッション独立性という制約
UI画面上は連続したキャッチボールに見えますが、サブエージェントは各呼び出しでセッションが終了します。
擬人化すると下記通りの流れです。
ユーザーの指示
↓
メイン:
サブエージェントさん、ユーザが仕様書作ってって言ってるよ
一般的にはこういう形式だから、そう書いてね
↓
サブ:
OK。あれ？そう書くの？俺は聞いてないんだけど…
まぁでも、そういう指示なら統合して書いとくね
それより不足情報があって今のままじゃ仕様書作れないよ
何度も聞かなくて良いように網羅的に質問するからユーザに聞いてね
↓
メイン:
仕様書作成にあたってサブエージェントからの質問に回答してください
↓
ユーザーの回答
↓
メイン:
サブエージェントさん、あ、もういなかった。
仕方ないから新しいサブエージェントに分かるようにして伝えるか
質問と回答のセットをリストにして…っと、
新しいサブエージェントさん、これで仕様書作って
↓
サブ:
おお、なんか知らんが必要なことを先に聞いてくれてて助かる
仕様書できたよ
パスはここで要約はこうだよ
↓
メイン:
仕様書ができました！
パスはここで要約はこうです！
これは非効率的ですよね。
サブエージェントは、まるで問い合わせの度に新しい担当に変わってしまうカスタマーセンターのようです。
メインはサブのこの特性を理解しているので「前の質問はこうで、ユーザはこう答えた」と伝えます。
まさにこの部分がコンテキスト上のオーバーヘッドになるため、トークン消費量で優位性がないのでしょう。
また、初回のサブエージェント呼び出し時に、メインはサブの定義内容を知らないため、入力プロンプトとして親切にも勝手に「こういう仕様書にして」と伝える現象も確認できました。
サブは入力を無視できず、それに応えようとします。
他にも実用上の懸念として、このメインを仲介する云わば伝言ゲームを繰り返す過程で、質問と回答の要約編集によってニュアンスが変わったり漏れがでたりする可能性があります。
Claude Codeを使ったことのある誰もがオートコンパクトで嫌というほど経験した、要約によって失われるアレと同じです。
サブエージェントの構造的な制約
サブエージェントは、その構造から下記のような特性をもっています。
メインはサブエージェントに対して
- サブのフロントマターのみを知っている
- サブの内部プロンプトを呼び出し時点で認識できない
- ゆえに余計な情報を含んだ入力をすることがある
サブは
- メインからの入力を否定・拒否できず、無理にでも応えようとする
- 不足や確認があっても同セッション内で聞けない
- そのため1度で完璧な成果物を出そうとする
- または1度で完璧な回答を得られる質問をする
結果として、ユーザーが必要としていない詳細も含まれた「過剰な出力」になりがちです。
使い分けの指針
判断フロー
対話が必要？
├─ YES → メインで実行
└─ NO → サブエージェント検討
↓
探索的な作業？
├─ YES → サブエージェント
└─ NO → メインで十分
開発フェーズでの適用
| フェーズ | 推奨 | 理由 |
|---|---|---|
| 要件定義 | メイン | 対話的、段階的合意 |
| 仕様書作成 | 状況による | 下記参照 |
| 設計・タスク分解 | サブエージェント | 探索的、成果物重視 |
| 実装 | 状況による | 下記参照 |
| デバッグ | 状況による | 下記参照 |
状況によって分かれるフェーズ
仕様書作成と実装とデバッグは、前提条件によって向き不向きが分かれます。
| フェーズ | 自律的（サブエージェント向き） | 対話的（メイン向き） |
|---|---|---|
| 仕様書作成 | 既にあるものを解析し文書化 | 対話から仕様を定める |
| 実装 | 詳細設計が既にある | 詳細設計がない |
| デバッグ | 「このエラー直して」と一任 | 「一緒に原因を探って」 |
SDD（仕様書駆動開発）のワークフローでは詳細設計が先にあるため、実装・デバッグともにサブエージェント向きとなります。
仕様書作成に関しては、新機能を作り始める際などの対話から仕様を定める際にはメイン向きです
既に要件定義がされている場合や、リバースエンジニアリング的に実装から逆算して仕様書を作ったり修正する場合は、調査・解析・分析のためサブエージェントが向きます。
まとめ
今回は、Claude Codeへの直接ヒアリングと実験から、サブエージェントの特性を明らかにしました。
同じプロンプトであっても、メインで完結するかサブエージェントを介すかで大きな違いが確認できました。
サブエージェントの設計思想
- 独立したエキスパートとして1回で完結させる
- セッション独立性により、対話的タスクには不向き
- 結果として過剰な出力になりがち
使い分けの基準
- 対話が必要 → メインで実行
- 探索的・自律的 → サブエージェント
対話的タスクにサブエージェントを使う問題
- 過剰な出力になりがち
→文章量にして8.6倍の成果物 - コンテキスト節約効果も活かせない
→むしろ多く消費 - プロンプト忠実度の低下
→勝手に項目追加
既存のSDD（仕様書駆動開発）ワークフローでは、要件定義や仕様書作成もサブエージェントが担っているケースがあるかもしれません。
しかし、対話的タスクはメインで実行することで、より良質な成果物が得られる可能性があります。
もし「質問が指示以上に詳細すぎてダルい！」とか「成果物が重くてレビューがしんどい」と感じた場合、それはサブエージェントに本来不向きな対話的タスクを強いた結果かもしれません。
なお、例えば仕様書作成のときには、既存コードベース内の調査やベストプラクティスを探すWebフェッチなどコンテキストウィンドウを圧迫するような探索的タスクを必要とする場合があるかと思います。
その際は、1つのサブエージェントの内部で、
- 既存実装を見て、
- ベストプラクティスを調査して、
- ユーザと対話して、
- 仕様書を作る
と対話をタスクに含めるのは、明確なアンチパターンと言えます。
- メインがユーザと対話しながら
- 既存実装を調べるサブエージェントを呼び出し結果だけを得て、
- ベストプラクティスを調べるサブエージェントを呼び出し結果だけを得て、
- 最終的な仕様書を（メイン、またはサブエージェントが）作成する
ことで、品質と効率を兼ね備えることができます。
また、補足として現在であれば対話的タスクのコンテキスト効率を上げる手段としてはスキルが適切です。
これについては、またの機会に記事にしたいと思います。
参考資料
- 公式ドキュメント:Subagents - Claude Code Docs
- 実験リポジトリ: claude-code-experiments
Discussion