Sub-agent Pooling

Sub-agent Poolingは「タスクごとに直接新しいSub-agentを作成する」ことと比べて、具体的にどんなコストを節約しますか？すべてのシナリオでリソースプーリングを行う価値がありますか？

リソースプーリングが節約するコストは3種類に分けられますが、すべてのシナリオでプーリングにリソースを投じる価値があるわけではなく、プーリング自体の実装・保守コストが見合うかを検討する必要があります。

節約されるコストタイプ1：接続確立コスト。Sub-agentが外部サービスに接続する必要がある場合（前述のMCP Server項目で触れたような、データベースやAPIサービスへの接続）、毎回この接続を再確立するには通常ネットワークハンドシェイクや認証といった手順が伴い、これらのステップ自体に時間がかかります（数十ミリ秒から数百ミリ秒程度）。プーリングにより接続は1回確立すればよく、その後は繰り返し利用でき、この接続の繰り返し確立の時間を節約できます。

節約されるコストタイプ2：設定読み込みコスト。Sub-agentの初期化に比較的大規模な設定やリソース（ルールリスト・ホワイトリストデータ）の読み込みが必要な場合、インスタンスを再作成するとこの読み込みプロセスが繰り返し実行されます。プーリングによりこの読み込みプロセスも1回だけで済みます。

節約されるコストタイプ3：並行制御の間接的な価値（前述のカードポイントで触れた）、この価値は直接的な時間やお金の節約ではなく、システムの安定性の向上です——技術的にSub-agentの再作成コストが低くても、固定サイズのプールはシンプルで効果的な並行上限メカニズムを提供し、この価値はタスク量が突然急増しうるシナリオで特に重要です。

プーリングを行う価値がないシナリオ：Sub-agentの初期化コスト自体が非常に低い場合（外部接続や大量のデータ読み込みを伴わない純粋な関数ロジックにすぎない）、プーリングが節約できる初期化コストはごくわずかですが、プーリング自体の実装（借用/返却ロジックの管理・状態クリーンアップの処理）は追加のコード複雑さを増やします。この場合、プーリングの保守コストが節約できるパフォーマンスコストを上回る可能性があり、行う価値がありません。システムのタスク量自体が非常に安定して低い場合（1日数十件のタスクのみ処理）、Sub-agentの再作成によるパフォーマンス負荷自体が目立たず、並行制御の価値も大きくありません（そもそもタスク量が急増しないため）、プーリングがもたらす限界効益は限定的です。

プーリングの価値を判断する実務的なシグナル：Sub-agentの初期化プロセス自体がタスク処理時間全体のかなりの割合を占めている（初期化に200ミリ秒かかり、タスク自体のコア処理は100ミリ秒しかかからないなど）、またはシステムがタスク量の突発的なピークに頻繁に直面していると気づいたら、この2つのシグナルはどちらもリソースプーリングを実装する価値があることを示します。初期化コストが全体のタスク処理時間に対して無視できるほど小さく、タスク量が安定して予測可能であれば、プーリングの投資対効果は通常低くなります。

記事のカードで「返却時の状態クリーンアップ」が最も見落とされやすい問題だと触れられていますが、具体的にSub-agent内部の何をクリーンアップする必要があり、見落としがないようどう確保しますか？

クリーンアップが必要な内容は、「この情報が次のタスクに漏洩したらどれだけ被害が大きいか」で優先順位を分類でき、目的もなくすべてをクリーンアップしようとするのではありません。

優先度高：ユーザーID機密データに関連するあらゆるコンテキスト。Sub-agentがタスクAを処理している際、ユーザーAの個人情報・APIキー・その他の機密データをメモリや内部状態に一時保存し、それをクリアせずにタスクBに貸し出すと、タスクBはユーザーAの機密情報を意図せず読み取ってしまう可能性があります（Sub-agentの推論プロセスが「前の対話ラウンドで言及された内容」を参照する可能性があり、対話履歴が正しくリセットされていないと古い機密内容が新しいタスクの推論文脈に誤って持ち込まれる可能性があるなど）——これは優先的にクリーンな状態を確保すべきカテゴリです。エラーが直接データ漏洩を引き起こし、セキュリティレベルの深刻な問題に相当するためです。

優先度中：ビジネスロジックに関連する一時状態。前述のLangGraph項目で触れた「照会回数」「累積コスト」といったカウンタなど、Sub-agent内部に類似の一時カウントがあり返却時にリセットされていない場合、次のタスクがこのSub-agentを借用する際にゼロ以外のカウントから始まってしまう可能性があり（本来あるべきゼロからではなく）、前述のリトライ戦略・Circuit Breakerで議論した回数上限やコスト上限の計算に偏差が生じます——この種のエラーは直接機密データを漏洩させませんが、前述の保護メカニズムを機能不全にしたり誤判定させたりします。

優先度低だが依然として注意が必要：キャッシュデータ。Sub-agentがパフォーマンスのために一部の照会結果（前回の市場データなど）を一時保存している場合、この種のキャッシュが適切に処理されないと、次のタスクがリアルタイムデータを再照会せず誤って期限切れのキャッシュデータを使ってしまう可能性があります——これは前述のスリッページ許容度記事で議論した「データの時効性」の問題と呼応し、キャッシュがきちんとクリーンアップされていないと、Sub-agentが古いデータに基づいて時期にそぐわない判断を下す可能性があります。

見落としがないよう確保する具体的な方法：毎回返却時に手動で1項目ずつクリーンアップする（新しく追加されたフィールドや状態を見落としやすい）より、より堅牢な方法は、Sub-agentの内部状態を明確に構造化されたオブジェクトとして定義し（前述のStructured Outputの考え方と呼応）、プールに返却する際は「既知のフィールドをクリーンアップする」のではなく「状態オブジェクト全体を新しい、事前定義された初期状態に直接リセットする」ことです。こうすることで後で新しいフィールドが追加されても、それがこの状態オブジェクトの一部である限り、リセットロジックが自動的にカバーし、新しいフィールドを追加するたびに手動でクリーンアップロジックの行を追加する必要がなく、「あるフィールドのクリーンアップを忘れる」という見落としの発生確率を大幅に下げられます。

タスクが到着する速度がプールのサイズを大幅に超え、すべてのSub-agentが借用済みになった場合、新しいタスクをどう処理すべきですか？直接拒否すべきですか？

直接拒否は1つの選択肢ですが唯一の選択肢ではありません。実務上いくつかの一般的な処理戦略があり、どれを選ぶかはタスク自体の性質（待てるか、時効性があるか）によります。

戦略1：キューで待機。タスクが特に緊急でなく、多少の処理遅延が最終結果に影響しない場合、新しいタスクは待機キューに入り、Sub-agentが返却され空き状態になるのを待って順番に処理されます。この戦略の重要な設計は合理的な待機タイムアウトメカニズムを持つことです——キュー内のタスクがある時間閾値を超えて待機し、まだ処理される順番が来ていない場合、無期限にキューで待機させ続けるのではなく、能動的にキューを諦め「システムが現在過負荷状態です、後で再試行してください」と報告すべきです。これは前述のリトライ戦略記事で議論した「すべての失敗を無限に解決しようとする必要はない」という縮退の考え方と呼応します。

戦略2：直接拒否し、明確な過負荷状態を報告。タスク自体に強い時効性がある場合（前述のスリッページ許容度記事で議論したように、市場データはいつでも古くなる可能性があり、キューで待機するとタスク完了時には市場状況が完全に変わっている可能性がある）、キューで待機することがむしろより大きな問題を引き起こす可能性があります（もはや合理的でなくなった操作を古いデータで実行してしまう）。この場合、新しいタスクを直接拒否し「現在リソースが満杯です、後で再試行してください」と明確に報告する方がむしろ安全な方法であり、「遅延して再試行するかどうか」の決定権を呼び出し側に返し、システム自身がどれだけキューで待たせるか決めるのではありません。

戦略3：プールサイズを動的に拡張する（弾力的プーリング）。基盤リソース（APIクォータ・計算リソース）が許せば、システムはプールが継続的に満杯であることを検知したら動的に追加の一時的なSub-agentインスタンスを作成して現在のピーク負荷に対応し、ピークが過ぎタスク量が正常水準に戻ったら余分な一時インスタンスを解放し、元のプールサイズに戻るよう設計できます。この戦略はより良い弾力性を提供しますが、実装の複雑さも高くなり、「動的拡張」自体は完全に無制限であってはいけません（そうでなければ前述のCircuit Breaker項目で議論した無制限のリソース消費リスクに戻ってしまいます）。通常「最大拡張倍率」を設定し、無制限の拡張を避けます。

どの戦略を選ぶかの判断根拠：核心的な問いは「このタスクについて、キューで待つことによる被害と、直接拒否することによる被害のどちらが大きいか」です——キューで待つこと自体がタスクの結果を悪化させないなら（タスクが時効性に敏感な判断を伴わない）、キューは通常ユーザー体験がより良い選択肢です。キューで待つことが古いデータで不適切な決定を下すことにつながる可能性があるなら（特に金銭操作を伴うタスク）、直接拒否してユーザーに決定権を返す方が通常より安全な選択肢です。この判断はタスクタイプごとに戦略を設定すべきで、システム全体が単一の戦略ですべてのタスクを処理すべきではありません。

複数の異なるSub-agentタイプを持つ複雑なマルチAgentシステム（「照会型」「分析型」「実行型」の3種類のSub-agentが同時に存在するなど）で、リソースプーリングは統一された大きな1つのプールを使うべきか、それとも各タイプごとに独立したプールを持つべきですか？

各タイプごとに独立したプールを持つべきで、統一して1つの大きなプールに混在させるべきではありません。理由は前述のCircuit Breaker項目で議論した「ユーザーレベルは独立したブレーカーを使うべきでグローバル共有すべきでない」と同じ種類の設計ロジックです——異なるタイプのSub-agentはリソースニーズの特性もリスクレベルも異なり、混在させて管理すると不必要な結合問題を生みます。

同じプールに混在させることの問題：照会型・分析型・実行型のSub-agentが同じプールを共有すると、よくある障害シナリオは——ある時点で大量の照会型タスクが殺到し（多くのユーザーが同時に市場データを照会したいなど）、プール全体のリソースを占有し、実行型タスク（より緊急でより重要な実際の取引実行かもしれない）がむしろSub-agentを借りられず、キューに並ぶか直接失敗を強いられます。これは典型的な「重要でないタスクが重要なタスクに必要なリソースを占有する」というリソース競合問題であり、前述の最小権限項目で議論した「異なる役割の権限とリソースは無差別に一緒に管理すべきでない」というより広範な設計原則と呼応します。

分離プーリングの具体的な設計：照会型Sub-agentのプールは比較的大きく設計できます（照会型タスクは通常量が多いが1回あたりのリソース消費とリスクは低いため）。実行型Sub-agentのプールは比較的小さく設計しますが、より高いキュー優先権を与えます（実行型タスクは通常数が少ないが毎回より高いリスクと重要性を伴い、他のタイプのタスクに押し出されないよう専用リソースを確保する価値がある）。分析型Sub-agentのプールサイズは両者の間で、分析タスクの実際の到着頻度に基づいて動的に調整されます。

追加の価値：分離プーリングによりリソース使用状況の監視と診断が容易になる。すべてのSub-agentが同じプールに混在していると、システムに「タスクのキュー待機時間が長くなった」といった問題が発生した際、どのタイプのタスクがボトルネックを引き起こしているか判断が困難です。各タイプが独立してプールの使用率を監視していれば、「照会型タスク量の急増が照会プールを満杯にしたのか、それとも実行型Sub-agent自体の処理時間が長くなり実行プールの回転が遅くなったのか」をより正確に特定でき、この診断精度の向上はシステム運用にとって価値が高いです。

この設計が呼応する核心原則：マルチAgentシステムのリソース管理は、前述で繰り返し議論した権限管理やCircuit Breaker設計と同じ基盤ロジックに従います——異なる役割・異なるリスクレベルのコンポーネントは、リソースと保護メカニズムをそれぞれ分けて設計すべきで、「ある段階の異常や輻輳」の影響範囲がその段階自体の範囲に限定され、本来正常に動作していた、あるいはさらに重要な他の段階に意図せず波及しないようにすべきです。