Dynamic WorkflowsとSubagentは同じものですか？複雑なタスクにはどちらを使うべきですか？
同じものではない。両者の違いは「誰が計画を握っているか」にある。Subagentを使う場合、Claudeが動的に、派生させるかどうか、いくつ派生させるか、それぞれ何をするかをその場で判断する——この意思決定プロセス自体がモデルによるリアルタイムの判断だ。一方Dynamic Workflowsは、まず固定のスクリプトとして書き、協調フロー全体を明確に定義し、そのスクリプトが大量のSubagentの並行実行を指揮する——制御フロー自体があらかじめ確定的に書かれており、毎回その場で決めるものではない。
日常的なタスクにはSubagentで十分だ——それは初心者が最初に触れる、最も直感的なマルチタスク処理方法である。Dynamic Workflowsが適しているのは、数十から数百もの並行インスタンスを実行する必要があるほどの規模で、かつそのプロセス自体が再利用可能なスクリプトとして書く価値がある場面だ。これはすでにほとんどの人が日常で遭遇するタスクの規模を超えており、「先進的に聞こえる」からといって優先的に選ぶ必要はない。
なぜ「タスクの範囲が不確定」な時こそ、複数のSubagentには適さないのですか？
複数のSubagentの運用は「どのように分割すべきかすでにわかっている」ことを前提としているからだ。役割、分担、各Subagentが担当すべき範囲を事前に決める必要があり、その切り分け自体がタスクについて十分な理解を必要とする。タスクの範囲さえまだ把握できていないなら、切り分け自体が推測になり、推測が外れれば再調整が必要になる。この再調整のコストは、最初から単一のAgentに探索させながら調整させる場合より高くなることが多い。
単一のAgentの強みは、こうした状況でこそ際立つ。探索の過程で発見した新しい情報に基づいて次に何をすべきかを動的に調整でき、事前に固定した分担表を用意する必要がない。これが業界が「タスクの範囲が不確定な時は、複数の役割に急いで分割するより、単一の適応型Agentを優先すべき」と推奨する理由でもある。まず範囲を把握し、本当に並行処理が必要になってから分割を検討する方が、最初から分担を決めてかかるより安全であることが多い。
ネストしたSubagentの「2〜3階層の最適点」は絶対的なルールですか？例外はありますか？
絶対的なルールではなく、実務上ほとんどの場面に当てはまる経験則だ。その前提は「結果をまとめるコストが深さに応じて積み重なる」ということであり、これは大半のタスクで確かに成り立つが、もしあなたのタスクが本質的により深い層の独立した分割を必要とするなら（例えば本当に自然な4階層構造があり、各階層が互いに独立していて、返される要約も非常に簡潔である場合）、3階層を超えることが必ずしも間違いというわけではない。
本当にチェックすべきなのは「2〜3階層を超えているかどうか」という数字自体ではなく、「もう1階層深く分割することで得られる並行処理の効果が、その1階層分増えるまとめコストを上回っているかどうか」だ。1階層深くするたびに損をしているなら、それは深さが行き過ぎている。しかしタスクの構造自体がより深い階層を本質的に必要とし、各階層が実際にかなりの時間を節約しているなら、数字自体は重要ではなく、実際の効果こそが判断基準となる。
初心者で、Subagentに触れ始めたばかりですが、最初から「過剰設計」に走らないようにするにはどうすればいいですか？
最も実用的な最初の一歩は、この記事で紹介した自問プロセスを自分に強制的にたどらせることで、飛ばさないことだ。まずタスクが互いに依存しないサブタスクに分割できるかを問い、答えられないならまだ分割しない。次に、分割によって生じるプロセスのノイズが本当に見たくないものかを問い、答えが曖昧なら、まず単一のAgentに直接処理させてみて、メインの会話が実際にノイズで読みにくくなるほど埋め尽くされているかを観察する。そうなっていないなら、そのタスクはそもそもSubagentを必要としないというサインだ。
もう一つの実用的な習慣は、まず単一のAgentでそのタスクを一度実行してみて、中間プロセスの量がどれくらいか、自然に分割できる独立したセグメントがあるかを自分の目で観察してから、次の同種のタスクにSubagentの分担を設計するかどうか決めることだ。「複雑になると先に想定して複数のSubagentを事前に武装する」のではなく「まず問題を体験してから解決策を設計する」に置き換えることで、単純なタスクを複雑にしてしまう傾向を効果的に防げる。
Subagentが流行り始めてから、よくある新しい習慣が生まれた。複雑そうなタスクに出会うと、反射的に「Subagentに任せよう」と考えてしまうことだ。この直感は半分正しい——Subagentは確かに独立したコンテキストと並行実行という利点をもたらす。しかしもう半分は危険だ。「複雑そうに見える」ことは「本当にSubagentが必要」であることを意味しない。分割すべきでないタスクを無理に複数のSubagentに分割すると、多くの場合、効果を上回る調整コストが発生し、効率向上にはつながらない。
Subagentの核心的な価値は「独立したコンテキスト」と「並行実行」にある。ある作業が大量の関心のない中間プロセス（大量のファイルを調べる、大量の探索的コマンドを実行するなど）を生む場合、あるいはある作業が互いに独立し依存関係のないサブタスクに分割できる場合、そこでSubagentが真価を発揮する——例えば4つの異なるモジュールのセキュリティを同時に監査する場合、4つのSubagentが分担して進め、それぞれの探索プロセスが互いに干渉することなく、最終的に結論だけをメインの会話に持ち帰る。
タスクそのものが線形で、各ステップが前のステップの結果に依存している場合、複数のSubagentに分割して並行処理することは助けにならないどころか、調整の複雑さを生み出す——後続のSubagentに前のSubagentの結果を渡す方法を考えなければならず、そのコミュニケーションコストは、単一のClaudeに順序立てて処理させるより高くなることが多い。もう一つよくある過剰設計は、タスクの範囲自体がまだ不確定な場合だ。これをいくつに分割すべきかさえまだ整理できていないのに、複数の固定された役割のSubagentに無理に割り当ててしまうと、探索の途中で発見した新しい情報に基づいて方向を動的に調整することがClaudeにできなくなる。学び続け、進めながら調整できる単一のAgentの方が、事前に役割を切り分けた複数のSubagentより柔軟だ。
Subagentはさらに自分自身のSubagentを派生させ、階層を形成できる——モジュールを担当するSubagentが、さらにファイルレベルのSubagentに分割することもできる。これは階層が明確な大規模タスクを処理する際に有用だが、1階層下がるごとにトークンコストが著しく上昇する。業界の実務経験では、おおむね「2〜3階層が効率の最適点であり、この深さを超えると、各階層から返ってきた要約をまとめる時間が、並行処理で節約した時間を上回ってしまう」とされている。深さは深ければ深いほど良いわけではなく、タスク自体に本当にそれだけの独立した階層があるかどうかに対応させるべきであり、「たくさんのSubagentを使った」ことを見せるために無理に深さを積み重ねるべきではない。
複雑そうなタスクに直面したら、まず3つの質問をするとよい。このタスクは互いの結果に依存しないサブタスクに分割できるか？答えが否（各ステップが前のステップの結果を待つ必要がある）なら、単一のAgentで順序立てて処理すべきであり、Subagentに分割すべきではない。答えが是なら、次に問う。これらのサブタスクそれぞれの探索プロセスは、自分が全く見る必要のないノイズか？ノイズの量が少なく、実際メインの会話に表示されても構わないなら、直接処理する方が独立したインスタンスを起動するより手間が少ないかもしれない。「独立して分割できる」ことと「プロセスのノイズが本当に隔離を必要とする」ことの両方が成立して初めて、Subagentが本当に出番となる時だ。
Subagentを1つ起動するたびに、一定の固定コストがかかる——独立したインスタンスを起動するコスト、そして最終的に複数のSubagentの報告をまとめる統合コストだ。タスクに本当の並行性がなければ、このコストは並行処理で節約した時間で相殺されず、純粋な余分な出費になる。ネストの深さも同じ論理で、1階層下がるごとに結果をまとめるコストが積み重なっていく。Subagentを使うべきか、どこまで深く使うべきかを判断することは、本質的にあなたの予算を守ることにつながる。正しい場所で使えばSubagentは処理時間を大幅に短縮できるが、間違った場所で使えば、支払うのは実質的に高いトークンコストであり、得られるのは「一見すごそうに見える」実行方法だけで、本当の効率ではないかもしれない。