これは何か
これは実践から導き出された3つのサブエージェントワークフロー設計原則である。分配前に共通基準を書く、明確な統合ステップを設計する、まず小規模でテストしてタスクが分割に適しているか確認する、というものだ。この3つの原則が解決する共通の問題は、サブエージェントの概念は直感的に聞こえるが、実際に再利用可能なワークフローとして設計する際に、基準の不一致、統合の粗雑さ、タスク自体が分割に適していないといった箇所で失敗しやすいことである。
3つの原則はそれぞれサブエージェントワークフローの3つの段階に対応する。分配前（基準を書く）、統合時（チェックステップを設計する）、本格適用前（小規模検証）であり、サブエージェントワークフローの設計から実際の運用までの全過程をカバーする。
なぜ存在するのか
この3つの原則が重要な理由は、サブエージェントの並行処理アーキテクチャ自体が「基準の不一致」と「互いを見えない」という2つの構造的問題を本質的に生み出すのであって、たまたま操作を誤ったわけではないからだ。各サブエージェントは独立したインスタンスであり、明確な共通基準がなければ、それぞれが自分の解釈で曖昧な指示を補完するのは、このアーキテクチャの下で必然的に起こることであり、運が悪かったわけではない。同様に、各サブエージェントが自分の担当分のデータしか見えないことも並行処理アーキテクチャの本質的な限界であり、サブエージェントが「より丁寧に作業する」ことで自動的に解決するものではない。
この3つの原則が存在する意義は、この2つの構造的問題に対してワークフロー設計段階で先に予防することであり、結果が出てからおかしいと気づいて事後対応することではない。3つ目の原則（小規模テスト）は、タスク同士の関連性の度合いが事前に正確に評価しにくいことが多く、実際に一度実行してみて初めて統合コストが見合うかどうかが分かるからであり、これが事前判断だけに頼れず検証ステップを組み込む必要がある理由である。
あなたの判断にどう影響するか
あるバッチタスクにサブエージェントを使うべきか評価しているなら、この3つの原則は計画の順序を変える。以前は「このタスクは分割できる」と思ったらすぐに分配作業に入っていたかもしれないが、今はまず自分に3つの質問をすべきだ。このタスクには具体的で実用的な共通基準を書けるか。統合されたサブエージェントの結果に、矛盾する判断や本来相互参照すべきだったのに個別に処理されてしまった関連がある可能性はないか。確信が持てない場合、事前に2〜3件のデータで小規模テストを行ったか。この3つを十分に考えてから、全データに本格適用するかどうかを決めるべきだ。
これは時間の配分方法にも影響する。以前は「サブエージェントは時間を節約できるはず」と考え、すべての時間をサブエージェントの完了待ちに充てていたかもしれないが、今は統合チェックのステップにも時間の一部を確保すべきだ。このステップはあってもなくてもよい仕上げの動作ではなく、ワークフロー全体の品質が信頼できるかどうかを左右する重要な部分だからだ。
上級者向け応用
上級者は統合チェックのステップ自体も専門のサブエージェントとして設計でき、メインタスクに戻って手動で処理する必要がなくなる。具体的には、実際の作業を担当するサブエージェントに加えて、「統合レビュー用サブエージェント」を追加で配置する。このサブエージェントは元データを処理せず、他のサブエージェントの出力結果だけを読み取り、矛盾する判断や見落とされた相互参照がないかを専門的にチェックする。この方法の利点は、統合レビューが元のタスクとは異なる視点から取り組めることで、「タスクをこなす」ことではなく「問題を見つける」ことに集中でき、通常はメインタスクが自分でついでにチェックするより問題を見つけやすい。
もう一つの上級テクニックは、共通基準自体もClaudeに設計を手伝ってもらい、自分だけの考えに頼らないことだ。具体的には、まずこのタスクの種類について、異なるサブエージェントが異なる意味に解釈しうる曖昧な部分をClaudeにリストアップしてもらい、それらの曖昧な部分を一つずつ明確に書き出す。このステップは、分配前に「基準自体が十分具体的か」を確認する作業に相当し、各サブエージェントがそれぞれ解釈し終えて統合時に基準の曖昧さが発覚するのを待つより、はるかに効率的であり、原則1で述べた基準の不一致の問題を根本から防げる。
サブエージェントの概念は直感的に聞こえる。並行処理できる作業を複数の独立したインスタンスに分けて同時に行い、順番に処理するよりはるかに速く終わらせる、というものだ。しかし概念を知っていることと、実際に再利用可能なワークフローとして設計することの間には距離がある。多くの人が初めてサブエージェントを試すと、統合結果がめちゃくちゃになったり、サブエージェント同士の判断基準が一致しなかったり、順次処理より時間がかかったりする状況に遭遇する。本稿では実践から導き出した3つの設計原則を紹介し、サブエージェントのワークフローが「すごそうに聞こえる」段階に留まらず、実際に運用できるようにする方法を解説する。
サブエージェントで最もよくある失敗は、各サブエージェントに与えられる指示が曖昧すぎて、それぞれが自分の解釈で補完してしまい、統合結果のスタイルや判断基準が全く一致しなくなることだ。例えば3つのサブエージェントにそれぞれ契約書を審査させる場合、「この契約に問題がないか確認して」とだけ伝えると、サブエージェントAは支払条件を重視し、サブエージェントBは違約責任を重視するかもしれない。統合結果は一見すべて審査済みに見えるが、実際には審査の視点が全く異なり、並べて比較することができない。解決策は、タスクを分配する前に時間をかけて簡潔だが具体的な共通基準を書くことだ。例えば「支払期日、違約金の割合、一方的な解約条項の3点について審査し、各点について適合・不適合の判断を示してください」といった具合に、各サブエージェントが同じ物差しを使い、それぞれの主観的判断に頼らないようにする。
サブエージェントが並行処理する際の本質的な限界は、各サブエージェントが自分の担当分のデータしか見えず、他のサブエージェントが何をしているか分からないことだ。もしタスク同士に実は関連があった場合——例えばサブエージェントAが審査した支払条件が、実はサブエージェントBが別の契約の競業避止条項をどう判断すべきかに影響する場合——こうした関連は、それぞれが独立して作業していると見落とされやすい。したがって統合は単に3つの結果を貼り合わせて終わりにするのではなく、それ自体を独立したステップとして設計すべきだ。メインタスク（あるいは統合専門のサブエージェント）にすべての結果を改めて読ませ、矛盾する判断がないか、本来相互参照すべきだったのに個別に処理されてしまった隠れた関連がないかを重点的に確認する。この統合チェックのステップこそ、サブエージェントが「互いを見えない」という構造的な限界を補う重要な動作である。
並行処理できそうに見えるタスクのすべてが、実際に分割すると効率的になるわけではない。タスク間の関連性が想定より高かった場合、統合チェックのコストを含めると、サブエージェントに分割した方が順次処理より全体の時間がかかってしまうことがある。実践上より確実な方法は、まず2〜3件のデータでサブエージェントを小規模にテストし、統合された結果の品質に問題がないか、統合ステップに過剰な追加時間がかかっていないかを確認してから、残りの全データにこのワークフローを適用することだ。小規模テストの段階ですでに統合に時間がかかっている、あるいはサブエージェント同士の判断が頻繁に矛盾していることが分かった場合、通常はタスク自体の関連性が当初の評価より高いことを意味し、この場合は分割方法を調整するか、いっそ順次処理を維持する方が、サブエージェントを無理に適用するより効率的である。
すでにバッチ処理的な作業にサブエージェントを試し始めているが、統合結果があまり信頼できない、あるいは結果を整理する時間が想定より多くかかっていると感じるなら、上記のいずれかのステップを見落としている可能性が高い。共通基準が明確に書かれていない、統合が形式的な貼り合わせにすぎない、あるいはタスク自体が分割に適していないのに無理に分割している、といった具合だ。この3つの原則をサブエージェントワークフローの設計前チェックリストとして扱うことで、「すごそうに聞こえるが実際には信頼できない」というギャップを大幅に縮められる。