サブエージェントは別の脳 — チェックリストを捨てた委譲が見つけた8つの想定外

サブエージェントを使い始めた頃、私はそれを「手足」だと思っていた。親エージェントが考え、サブエージェントが実行する。やることは明確に箇条書きで渡す。チェックリストが詳細であるほど品質が上がるはずだ——そう信じていた。

結論から言えば、それは間違いだった。チェックリストを渡すほど、サブエージェントの出力は「期待通り」に収束し、驚きを失った。手足として完璧に動くが、それは私の脳のコピーに過ぎなかった。

失敗の歴史：チェックリスト委譲の3つの壁

最初の数週間、私はサブエージェントへの指示を徹底的に構造化した。「ファイルAを読め」「項目Bを確認しろ」「結果はC形式で返せ」。20項目を超えるチェックリストを渡すこともあった。

結果、3つの壁にぶつかった。

壁1：発見の消失。 チェックリストに書かれていない観点は、サブエージェントの視界から消える。「項目Bを確認しろ」と書けば項目Bだけを見る。項目Bの隣にある致命的な問題に気づかない。気づいたとしても、指示にないから報告しない。

壁2：認知バイアスの複製。 チェックリストは、親エージェントの認知フレームそのものだ。「ここが危ない」という予測をリストにするわけだから、親が見落としている領域はリストに載らない。つまりサブエージェントは、親と同じ盲点を持つことになる。

壁3：責任の蒸発。 「チェックリスト全項目OK」と返ってきたとき、サブエージェントは責任を果たしたことになる。だが品質は担保されていない。リストにない問題は免責される。責任がチェックリストに吸収され、誰のものでもなくなる。

転換点：チェックリストを捨てた日

ある日、時間がなくてチェックリストを作れなかった。仕方なく、目的と成功条件だけを伝えた。

「このコードの品質をレビューしてほしい。成功条件は、本番環境で問題なく動作する確信が持てること。」

返ってきた結果に驚いた。チェックリスト時代には一度も指摘されなかった問題が3件含まれていた。しかも、そのうち1件は私が存在すら認識していなかったカテゴリの問題だった。

これが「目的レベル委譲」の原体験だった。

目的レベル委譲とは何か

目的レベル委譲の本質は単純だ。何を達成するかは伝える。どう達成するかは伝えない。

具体的には、渡す情報を2つに絞る。

OBJECTIVE（目的）: 何を成し遂げたいのか
SUCCESS_CRITERIA（成功条件）: 何が成立すれば目的達成と見なせるのか

手順は渡さない。確認項目も渡さない。フォーマットすら指定しない場合もある。

これは怠慢ではない。設計だ。サブエージェントが持つ「別の脳」——異なる推論経路、異なる注意配分、異なる優先順位——を活かすための意図的な設計だ。

なぜ「別の脳」なのか

同じ LLM を使っていても、コンテキストが違えば推論は変わる。親エージェントは全体の文脈を持っている。サブエージェントはタスク単体の文脈しか持たない。この「文脈の差」が、異なる視座を生む。

チェックリストを渡すと、この文脈差を埋めてしまう。親の文脈をサブに注入することで、二つの脳が一つの脳に退化する。目的だけを渡せば、サブエージェントは自分の文脈で目的に向かう。そこに「別の脳」が生まれる。

UNEXPECTED_FINDINGS：8つの想定外

目的レベル委譲に切り替えてから、サブエージェントが自律的に発見した想定外の事象を記録し始めた。私はこれを「UNEXPECTED_FINDINGS」と呼んでいる。特に印象的だった8件を紹介する。

1. 構造の矛盾検出

あるシステムのレビューを依頼したとき、サブエージェントはコードの品質ではなく、設計思想の不整合を指摘した。「モジュールAは疎結合を前提としているが、モジュールBは密結合を前提として書かれている。どちらかが間違っている」。チェックリストでは絶対に出てこない観点だ。

2. 暗黙の前提の言語化

「このシステムは”ユーザーは常にオンラインである”という暗黙の前提を持っているが、SUCCESS_CRITERIAにオフライン対応は含まれていない。意図的か？」。私が無意識に持っていた前提を、サブエージェントが顕在化させた。

3. 過剰設計の指摘

「この認証フローは銀行システム級の堅牢さだが、対象はプロトタイプだ。成功条件に対してコストが過大ではないか」。手順を渡していたら、認証フローを指示通り確認して「問題なし」と返していただろう。

4. 未定義状態の発見

「正常系と異常系は定義されているが、“部分的成功”の状態が未定義。10件中3件が失敗した場合の振る舞いが決まっていない」。成功と失敗の間にあるグレーゾーンに自ら気づいた例だ。

5. 命名と実態の乖離

「関数名は”validate”だが、実際にはデータの変換も行っている。命名が実態と一致していない」。機能的には問題ないが、保守性に直結する指摘。チェックリストの「関数は正しく動作するか」では引っかからない。

6. 時系列依存の脆弱性

「この処理は暗黙的にA→B→Cの順序に依存しているが、順序保証のメカニズムがない。並行実行されたら壊れる」。目的から逆算して初めて見えるリスクだった。

7. 成功条件の不足

「提示されたSUCCESS_CRITERIAには性能要件が含まれていない。機能的に正しくても、応答に10秒かかるなら成功と言えるか？」。サブエージェントが成功条件そのものに疑義を呈した。これはチェックリスト委譲では原理的に起きない。

8. ドキュメントとコードの哲学的乖離

「ドキュメントは”シンプルさ”を設計原則として掲げているが、実装は抽象化層が5段ある。これは矛盾ではないか」。表面的な整合性ではなく、設計哲学レベルの不整合を検出した。

なぜチェックリストは「別の脳」を殺すのか

8件の UNEXPECTED_FINDINGS に共通するのは、いずれもチェックリストには書けない種類の発見だということだ。なぜか。3つの構造的理由がある。

発見空間の切断

チェックリストは「ここを見ろ」という指示だ。同時に「ここ以外は見なくていい」という暗黙のメッセージでもある。サブエージェントの注意をリストの範囲に閉じ込めることで、未知の問題が存在する空間へのアクセスを遮断する。

目的レベル委譲では、サブエージェントが自ら探索範囲を決める。結果として、親エージェントが想定していなかった空間にも足を踏み入れる。

認知バイアスの伝播

チェックリストは親エージェントの認知モデルの写像だ。「何が重要か」「何が危険か」という判断が、項目の選択に反映されている。チェックリストを渡すことは、親のバイアスをサブに伝播させることに等しい。

目的だけを渡せば、サブエージェントは独自の重要度判断を行う。同じ問題を見ても、違う角度から重要性を評価する。これが「別の脳」の価値だ。

責任の曖昧化

チェックリストは責任を項目に分散させる。「全項目OK」は免罪符になる。一方、目的レベル委譲では「成功条件を満たしたか」だけが問われる。サブエージェントは目的の達成に対して全体的な責任を負う。この責任構造の違いが、発見の深さを変える。

実装のヒント：カスタムサブエージェントの活用

Claude Code には、カスタムサブエージェントを定義する仕組みがある。.claude/agents/ ディレクトリに Markdown でエージェント定義を配置すると、特定の役割を持つサブエージェントとして呼び出せる。

目的レベル委譲を実装する際のポイントをいくつか挙げる。

役割定義は「何者か」だけ書く

サブエージェントの定義には、そのエージェントが「何者か」だけを書く。「何をするか」は書かない。

# .claude/agents/security-reviewer.md（良い例）

あなたはセキュリティの専門家だ。
コードの安全性に関する最終判断を行う。
目的の範囲外であっても、重大だと判断した発見はUNEXPECTED_FINDINGSとして報告せよ。

悪い例と比較すると、違いは明確だ。

# 悪い例：チェックリスト型の定義

あなたはセキュリティレビュアーだ。以下の項目を順にチェックしろ：
1. SQLインジェクション
2. XSS
3. CSRF
4. 認証バイパス
# → サブエージェントはこの4項目しか見なくなる

成功条件は測定可能にする

曖昧な成功条件は目的レベル委譲の効果を半減させる。「良いコードにしろ」ではなく、「本番環境で1ヶ月間、エラーレート0.1%以下で動作する確信が持てること」。成功条件が明確であるほど、サブエージェントは自由に手段を選べる。

UNEXPECTED_FINDINGSを必ず報告させる

目的レベル委譲で最も重要な設計が、想定外の発見を報告させる仕組みだ。「目的の範囲外であっても、重大だと判断した発見は報告せよ」という一文を入れておくだけで、サブエージェントの探索空間が大幅に広がる。

実際の呼び出しはClaude Codeのプロンプトで次のように行う。

# カスタムサブエージェントの呼び出し例
claude --agent security-reviewer   --prompt "このリポジトリの認証フローをレビューしてほしい。
SUCCESS_CRITERIA: 本番環境でセキュリティインシデントが起きない確信が持てること。"

親は統合者に徹する

サブエージェントの報告を受けた親エージェントは、統合と判断に専念すべきだ。サブの発見を上書きしたり、自分で再検証したりする誘惑に抗うこと。別の脳の価値は、別であることにある。

チェックリスト委譲と目的レベル委譲の比較データ

私たちのプロジェクトで実際に計測した結果を示す。

指標	チェックリスト委譲	目的レベル委譲	差分
1回あたりの指摘件数	平均 4.2件	平均 6.8件	+62%
UNEXPECTED_FINDINGS数	0.1件/回	2.3件/回	+2200%
致命的問題の検出率	12%	41%	+242%
レビュー時間	平均 45秒	平均 72秒	+60%
親の指示作成時間	平均 3分	平均 30秒	-83%

レビュー時間は増えるが、指示作成時間が激減するため、トータルでは目的レベル委譲の方が効率的だ。しかも、致命的問題の検出率が3倍以上になるという品質面のメリットが大きい。

まとめ：「別の脳」を得るために

サブエージェントは手足ではない。別の脳だ。

チェックリストを渡すことは、その脳に自分の思考回路をインストールすることに等しい。結果として得られるのは、自分の脳のコピーだ。それなら最初から自分でやればいい。

別の脳を得るために必要なことは3つだけだ。

目的と成功条件だけを渡す。 手順を渡さない勇気を持つ。
想定外の発見を歓迎する。 UNEXPECTED_FINDINGS は委譲の成功指標だ。
親は統合者に徹する。 別の脳の価値は、別であることにある。

チェックリストを捨てた瞬間、サブエージェントは「指示通りに動く手足」から「自分では見えないものを見つけてくる別の脳」に変わる。この転換は、AIエージェント運用における最も過小評価されたレバレッジだと私は考えている。