Sub agentに何を任せるべきか：デリゲーション判断の3軸ヒューリスティクス

Claude Code の Sub agent 機能を使い始めると、最初は「タスク分割して並列で投げれば速い」と単純に考えがちです。しかし実際にやってみると、並列で投げたほど速くもならないし、結果の統合に時間がかかることに気づきます。

経験上、Sub agent は「タスク分割」だけで決めるとほぼ失敗します。文脈の独立性・リスクの可逆性・検証可能性の3軸で判断するのが安定した運用です。今回はこの3軸と、並列起動本数の決め方を体系化します。

なぜ「タスク分割」だけでは失敗するのか

Sub agent はメインセッションの文脈を持たない

Sub agent はメインセッションとは独立したコンテキストで動きます。つまりメインで議論した内容は引き継がれません。タスクの依頼文だけで動くため、「ここまでで決まった前提」「議論で却下された案」などが反映されません。

これを知らずに「Aの実装を Sub agent に任せて、メインで Bを進めよう」と並列化すると、Sub agent がメインで却下した方針で実装を始めるような事故が起きます。

並列実行のオーバーヘッドは無視できない

Sub agent を1つ起動するだけでも、依頼文の作成・結果の読解・統合判断に時間がかかります。並列で5本起動すると、5本分の結果を読んで統合する時間が必要です。統合コストが並列化の利得を上回るケースは普通にあります。

「並列だから速い」は、統合コストを差し引いた後の正味の時間で初めて成立します。並列化に向く性質をタスクが持っているかを見極める必要があります。

デリゲーション判断の3軸

軸1: 文脈の独立性

問い: そのタスクは、他のタスクとの依存関係なしに進められるか？

独立性が高い例:

• 8領域それぞれの調査（領域ごとに完結する）
• 複数の競合製品を並列で評価
• 別ファイル・別モジュールの実装
• ドキュメント・ブログ記事の下書き

独立性が低い例:

• 同じファイルの異なる関数を実装（マージ衝突リスク）
• 設計と実装（設計が決まらないと実装できない）
• 依存関係のあるテスト（順序が必要）

判定基準: タスクの依頼文が1ページ以内に収まり、メインセッションで議論した内容を引用しなくても進められるなら、独立性は高いと判断できます。

軸2: リスクの可逆性

問い: そのタスクの結果が間違っていた場合、どれだけ簡単に取り消せるか？

可逆性が高い例:

• 調査・リサーチ（間違っていても破棄するだけ）
• 下書き作成（採用しないなら使わなければ良い）
• 候補案の生成（複数案から選ぶ前提）

可逆性が低い例:

• 本番環境への変更
• DB マイグレーション
• 共通ライブラリの破壊的変更
• リリース・公開作業

判定基準: Sub agent の結果が間違っていた場合、5分以内に巻き戻せるなら可逆性は高いと判断できます。「やり直しが利かない作業」は Sub agent ではなくメインセッションで人間が監視しながら進めるべきです。

軸3: 検証可能性

問い: そのタスクの結果が「正しい / 間違っている」を、人間が短時間で判断できるか？

検証しやすい例:

• 既存テストが通るかどうか（自動）
• 仕様書の項目を網羅しているか（チェックリスト）
• 出力形式が指定通りか（フォーマット検証）

検証しにくい例:

• 「このアーキテクチャは将来性があるか」
• 「この文章は読みやすいか」
• 「この実装は最良か」

判定基準: 結果を10分以内に「合格 / 不合格」判定できるなら、検証可能性は高いと判断できます。検証に1時間以上かかるタスクを Sub agent に任せると、検証コストが並列化の利得を上回ります。

3軸を使った判定マトリクス

3軸それぞれを「高 / 低」で評価し、組み合わせで判断します。

理想ケース（3軸とも高）に該当するのは以下のようなタスクです。

• 8領域の並列リサーチ（独立性高 / 可逆性高 / 検証可能性高）
• 複数候補案の並列下書き（独立性高 / 可逆性高 / 検証可能性高）
• 別モジュールのテスト追加（独立性高 / 可逆性高 / 検証可能性高=テスト通過）

逆にアンチパターンは以下です。

• 「実装と設計を並列で」（依存関係あり、独立性低）
• 「本番デプロイ作業を Sub agent に」（可逆性低）
• 「アーキテクチャ提案を Sub agent に丸投げ」（検証可能性低）

並列起動本数の決め方

起動本数の上限

並列で起動する Sub agent 数は、統合作業を担当する人間1人がさばける範囲に収めます。経験的には3〜5本が現実的な上限です。

• 1〜2本: 統合は容易だが、並列化の利得も小さい
• 3〜5本: 利得と統合コストのバランスが良い
• 6本以上: 統合作業が破綻し始める

8本以上を並列で動かしたい場合は、統合用の追加 Sub agentを立てる構成にします。各領域 Sub agent → 統合 Sub agent → メインセッションの3層構造です。

タスクサイズの目安

各 Sub agent に投げるタスクは、10〜30分で完結するサイズが目安です。

• 5分未満: メインセッションで直接やった方が速い
• 10〜30分: Sub agent の本領発揮
• 60分以上: タスクが大きすぎる。さらに分割するか、メインで進める

長時間タスクを Sub agent に任せると、進捗確認のコストも並行で発生します。30分待って結果を見るより、10分タスク3つに分けて段階的に確認する方が安全です。

エンジニアにとっての価値

1. AI を「使い分ける」スキルが体系化される

なんとなく Sub agent を使うのではなく、3軸で明示的に判断できるようになります。判断基準があると、「なぜこのタスクを Sub agent に任せたか」を後から振り返って改善できます。

2. 人間チームのマネジメント原理に通じる

3軸は AI に固有のものではなく、人間チームへの仕事の振り方と本質的に同じです。「自分でやるか、人に任せるか」「任せても安全な相手か」「結果を検証できるか」は、上司・部下・外注の関係でも全く同じ判断軸です。

AI を使い分けるスキルを磨くと、副産物として移譲・監督・検収の構造を学べます。マネジメント経験のないエンジニアでも、AI 経由でこの感覚が育ちます。

3. 「並列化すれば速い」の幻想から抜け出せる

並列化は統合コストを差し引いた後の正味で測るべきだと体感できます。これは AI に限らず、マルチタスク・チーム編成・タスク管理にも応用が効く発想です。

落とし穴と対処

落とし穴1: 独立性を過大評価する

「別ファイルだから独立」と思っても、共通の型定義や設定を変更する場合は実は依存しています。依頼文を書いてみて1ページに収まるかを毎回チェックします。書いてみて長くなるなら独立性は高くありません。

落とし穴2: 可逆性をテスト環境で判断する

「ローカルで動くから可逆」と思っても、本番反映後は別の話です。最終的なデプロイ先での可逆性で判断します。テスト環境での実験は別カテゴリです。

落とし穴3: 検証を Sub agent 自身に任せる

「検証も Sub agent にやらせれば良い」と思いがちですが、検証を依頼する側が検証結果を検証する必要があります。Sub agent に「自分の結果を検証して」と頼むのは構造的に弱い設計です。検証は別 Sub agent または人間が行います。

落とし穴4: 3軸の評価を細かくしすぎる

「独立性は中の上」のような細かい評価をすると判断が遅れます。「高 / 低」の2段階で十分です。グレーゾーンに該当するタスクは、原則として Sub agent ではなくメインで進めます。

適用範囲

このフレームが効くシーン：

• Sub agent を日常的に使う運用
• 大規模な調査・リサーチタスク
• 複数候補から選ぶタイプの意思決定
• チームで AI 利用ルールを整備するとき
• 自分の AI 利用を振り返って改善したいとき

効きにくいシーン：

• 短時間で完結する作業（並列化の利得がない）
• 一回限りの試行錯誤（毎回 3軸 評価する余裕がない）
• 既知のパターン作業（過去の判断を流用すれば良い）

まとめ

「タスク分割」だけで Sub agent を使うとほぼ失敗します。3軸ヒューリスティクスで判断すると、Sub agent の本領が発揮されるケースだけに絞れます。AI を「使い分ける」スキルは、人間チームのマネジメント原理と本質的に同じなので、移譲・監督・検収の感覚を AI 経由で学ぶことができます。並列化の利得は統合コストを差し引いた後で初めて測れる、という当たり前の原則を意識すると、Sub agent 運用が安定します。