サブエージェントとは何か、通常の「複数ステップのタスク」とどう違うのか？
サブエージェントとは、メインタスクが独立した子問題をまるごと切り出し、別に動作する独立したClaudeインスタンスに処理を任せ、完了後に結果をメインタスクへ返す仕組みである。メインタスクはサブエージェント内部でどのような推論が行われたかを知る必要はない。これは通常の複数ステップタスクとは大きく異なる。通常のタスクでは、同一のClaudeインスタンスがステップ1、ステップ2、ステップ3を順に処理し、すべてのステップが同じコンテキストウィンドウを共有する。ステップが増えるほど、初期の情報が押し出されたり曖昧になったりしやすい。
サブエージェントはこの問題を避けられる。各サブエージェントは割り当てられた作業だけを保持する専用のクリーンなコンテキストウィンドウを持ち、メインタスクの他の内容に一切影響されない。例えば「20社分のベンダー契約を確認してほしい」というメインタスクの場合、通常は同じ会話の中で1件ずつ確認していくため、15件目を見る頃には1件目の詳細が曖昧になっているかもしれない。サブエージェント方式では20件を複数のインスタンスに分配し、それぞれが担当分だけに集中するため、前に見た内容に判断が影響されない。
サブエージェントにはどんなリスクがあり、最も見落とされやすいのはどれか？
最も見落とされやすいのは「調整コスト」である。サブエージェントは並行処理のため速いが、それぞれ自分の担当分の情報しか見えず、他のサブエージェントが何をしているかは分からない。もしタスク間に隠れた関連があった場合——例えばサブエージェントAが確認した契約条項が、実はサブエージェントBが別の契約を判断する材料になるべきだった場合——分割することでその関連が見落とされてしまう。メインタスク側が後で突き合わせを行わない限り、両者をつなぐ責任を誰も持たないためだ。
2つ目に見落とされやすいリスクは、結果の品質のばらつきである。各サブエージェントは独立して動作するため、タスクの説明が十分に明確でない場合、同じ曖昧な指示に対して異なる解釈をする可能性があり、最終的に統合した結果のスタイルや判断基準が揃わないことがある。これはコンプライアンス審査や法律文書の照合など、厳格で統一された基準が求められる作業では特に危険である。表面上はすべて確認済みに見えても、審査の厳しさがサブエージェントごとに異なっているかもしれないからだ。
どのような場合にサブエージェントを使うべきで、どのような場合には避けるべきか？
核心となる判断基準は、タスクが互いに独立しており、並行実行が可能で、結果同士を参照し合う必要がないかどうかである。プロジェクト内の3つの異なるモジュールのコード品質を同時にチェックする、3社の競合の価格戦略を同時に調査する、3社の異なる顧客の会議メモを同時に整理するといった作業は、すべて同時に行っても結果が互いに影響しないため、サブエージェントに向いている。
逆に適さないのは、タスクが強く依存し合い、後のステップが前のステップの結果を待たないと次に何をすべきか決められない場合である。まず市場レポートを分析し、その結果に基づいて特定の論点をさらに深掘りするかどうかを決める、といった「結論が出て初めて次が分かる」タスクがこれにあたる。このような場合にサブエージェントに分割すると、中間結果をリアルタイムで交換できないため調整コストが増えてしまう。単一の順次処理で、各ステップが前のステップの推論過程を完全に見られる形にする方が適している。簡単な判断法は、「これらのサブタスクは同時に投げられるか、それとも順番通りに行う必要があるか」を自問することだ。答えが「同時に」であれば、サブエージェントが適している。
上級者はサブエージェントのタスクをどう設計すれば、結果の品質をより安定させられるか？
上級者の要点は、分配後に基準のばらつきに気づいて修正するのではなく、分配前に基準を統一しておくことである。具体的には、判断基準・出力フォーマット・記載すべき重要項目を含む簡潔で明確な共通ガイドラインを事前に用意し、各サブエージェントに「この契約を確認して」ではなく「以下の5つの基準でこの契約を確認し、各基準について適合・不適合を判断し、根拠となる具体的な条項番号を添えて」という形で渡す。こうすることで各サブエージェントは独立して動作していても、出発点のガイドラインが揃っているため、統合後の結果のスタイルや厳格さも揃いやすくなる。
もう一つの上級テクニックは、サブエージェントの結果を単純につなぎ合わせるのではなく、実際の「統合ステップ」を設計することである。メインタスクがすべてのサブエージェントの結果を受け取った後、サブエージェント間で矛盾する判断がないか、本来相互参照すべきだったのに独立して処理されてしまった隠れた関連がないかを重点的に確認するクロスチェックを行うべきだ。この統合チェックこそが、サブエージェントが「互いを見えない」という構造的な限界を補う重要な動作であり、サブエージェントタスクの品質を左右する分かれ目となる。
20社分のベンダー契約を確認し、支払条件と違約条項を洗い出す必要があるとする。自分で1件ずつ読む代わりに、まず共通の審査基準（支払期日は60日を超えないか、違約金は契約総額の10%を超えないか、一方的な解約条項がないかなど）を作成し、システムに20件をサブエージェントへ分配して並行処理させる。各サブエージェントは同じ基準を受け取り、担当分だけに集中し、最後にすべての判断を1枚の比較表に統合する。順番に1件ずつ読むよりはるかに速く、出発点の基準が統一されているため、20件全体の審査の厳しさも揃いやすい。実務上の要点は、バッチ処理可能で分割でき、かつ事前に明確な基準を書き出せるレビュー作業こそ、この方式で時間を最も節約でき、同時に品質の一貫性も保てるということだ。
サブエージェント最大の利点はスピードである。並行処理できる作業を実際に同時に終わらせられるため、1つ終わるまで次を待つ必要がない。バッチ処理可能で依存の少ない繰り返し作業に特に有効である。代償は調整コストで、各サブエージェントは自分の担当分の情報しか見えず、他が何をしているか分からないため、タスク間の隠れた依存関係が見落とされやすく、この構造的な限界を補うために追加の統合チェックが必要になる。サブエージェントが適するのは、タスク数が多く、互いに独立しており、判断基準を事前に明確に書き出せる場合である。適さないのは、タスクが強く連動している場合、前のステップの中間結果をリアルタイムで参照する必要がある場合、または基準自体が曖昧で進めながら調整が必要な場合である。要するに、サブエージェントは時間効率と調整の複雑さを交換する仕組みであり、その交換が割に合うかどうかはタスク間の依存度の低さにかかっている。