Anthropic公式ガイド：モデル能力の向上に伴い、多くのサブAgentはスキルとツールに置き換え可能

AIアシスタントが注文照会、配送確認、返品・交換処理を行う際、業務が1つ増えるたびにサブAgentを1つ追加しなければならないのだろうか。

Anthropicの公式ガイドは、このアプローチを見直すことを提案している。モデル自身が手順を計画し、ツールを選択し、結果を検証する能力が高まるにつれ、かつてサブAgentに委ねていたタスクの多くは、単一のメインAgentに集約できるようになっている。

従来サブAgentのプロンプトに記述されていた業務フローは、必要なときにのみ読み込むスキルとして整理できる。注文照会や配送確認などの操作はツールを通じて実行する。メインAgentはユーザーの元のリクエストとツールから返された結果を一貫して保持し、次にどのルールを読み込み、どのデータを照会すべきかを判断する。

これにより、途中のディスパッチや情報の引き継ぎを削減しながら、各業務チームがそれぞれの専門的なフローを引き続き保守できる。どのサブAgentを統合でき、どれを残すべきかは、実際のタスクを通じて検証する必要がある。

モデルの進化に伴い、サブAgentの作成を抑えられる理由

サブAgentは独自のコンテキストウィンドウ（タスク処理時に読み込める情報群）を持ち、固有のツールや指示が割り当てられている。振り分けを担うコーディネーターがタスクをサブAgentに割り当て、処理結果を受け取る。

メインループとは、同一のモデルが次のステップを決定し、ツールを呼び出し、結果を読み込んで行動を継続するサイクルを、回答を出力するか予算制限に達するまで繰り返す仕組みを指す。

従来、チームはモデルの外部にルーティング、計画、検証のステップを設け、モデルに代わって作業を段取りしていた。より新しいモデルは、自身で手順を組み立て、進捗を説明し、作業しながら自己検証する能力が高まっているため、外部による段取りの一部は冗長になりつつある。Anthropicが顧客の移行を支援する中で、固定的なマルチAgent構造が新しいモデルの能力発揮をかえって阻害しているケースが見られた。モデルをアップグレードする際には、従来のワークフローが依然として必要か再点検する価値がある。

モデルが強化されたとはいえ、ターン数やコストの予算、書き込み権限、結果の検証は依然として維持する必要がある。特定のサブAgentを残すかどうかも、具体的なタスクでのパフォーマンス次第である。

Anthropicの応用AIチームが複数の企業導入事例を比較したところ、1つのAgentが必要に応じてスキルを利用する構成は、「すべての内容を単一のプロンプトに詰め込む」構成や「複数のサブAgentに分散させる」構成よりも回答品質が優れるケースが多く、単一タスクのコストや待機時間も抑えられる傾向が見られた。

ある顧客の比較検証では、マルチAgentフレームワークをシングルループに再構築した結果、実行速度が約2倍に向上した。

元の英語アニメーション：階層構造とメインループ

Agentを細かく分割しすぎると生じる課題

注文チームがAgentを1つ作り、物流チームがもう1つ作り、その上に振り分けを担当する「統括役」を置く。チームが増えるほどシステムも細分化され、最終的には企業の組織図のような構造になっていく。これこそが、Agentシステムにおけるコンウェイの法則（Conway's Law：システム構造は組織のコミュニケーション構造を反映する）の現れである。

細分化しすぎると、通常は次の5つの問題が生じる：

1. 引き継ぎ時の詳細の脱落：システムは異なるAgent間でどのコンテキストを渡すかを判断する必要があり、伝言を繰り返す中で重要な詳細が抜け落ちやすくなる。
2. Agentの乱立と形骸化：各チームが個別にサブAgentをリリースすることで、社内に機能が重複し、統一基準を欠き、継続的な保守がなされないインスタンスが蓄積しやすくなる。
3. ルールの錯綜：自チームの業務ルールを担保しようと各チームがグローバルプロンプトに要件を追記し、ルール同士が衝突して、一貫したトーンや基準を維持することが困難になる。
4. 個別テストは高得点でも全体の目的が未達：各業務グループが自らの担当部分のみをテストして高いスコアを出しても、ユーザーの目的全体が達成されたかを検証する主体が存在しない。
5. 階層的な呼び出しによるレイテンシの増大：1回のリクエストが複数回の独立したモデル呼び出しと引き継ぎを経由するため、ユーザーの待ち時間が長くなる。

なぜ引き継ぎで情報が漏れやすいのか。振り分けを担当するAgentは通常、情報の一部を抜き出してサブAgentに渡し、サブAgentは自身のコンテキスト内で処理を行った上で、要約や結果を返却する。双方が同じツールを使えるからといって、双方が完全な処理プロセスを把握しているとは限らない。

Anthropicは、問題タイプごとに分割して階層的に情報を伝達するこのプロセスを「伝言ゲーム」（Telephone Game）に例えている。引き継ぎを選択的な要約に依存すると、後続のステップで必要となる詳細な背景が要約から抜け落ちやすくなる。

コードを書く際、機能の実装とテストの作成は、同じ設計背景に依存することが多い。

問題タイプ別に分割した場合、まず機能Agentがコードを書き、テストAgentに引き継いでテストを作成し、さらにレビューAgentに引き継ぐことになる。テストを作成するAgentは初期実装と要約された説明を受け取るだけであり、前のAgentがなぜ特定の設計判断（トレードオフ）を下したのかを把握できないため、テスト作成時に重要な境界条件を見落としやすくなる。

同一のAgentに機能とテストの両方を書かせれば、実装時の設計背景をそのまま引き継ぐことができる。後続の検証器（Verifier）はテストの実行と結果の報告のみを担当するため、コード記述時の推論プロセス全体を把握する必要はなく、独立して処理できる。

元の英語図：コンテキストに応じた境界設定

カスタマーサービスのシナリオでも同様である。例えば、ユーザーから「この注文は公演で急ぎで使用するため、必ず速達で発送してください。また、梱包にプラスチック留め具は使用しないでください」という要望があったとする。システムが問題タイプに応じて注文Agentと物流Agentに分割されている場合、注文モジュールがチケットの要約を生成して物流モジュールに引き継ぐ際に、「速達」だけを抽出し、「公演で急ぎ、プラスチック留め具禁止」という制約条件を引き継ぎから漏らしてしまう恐れがある。

同一のAgentに元のリクエストとツールの結果を保持させれば、こうした引き継ぎによる漏れを減らすことができる。長い対話では依然として情報の見落としが生じる可能性があり、共有コンテキストにも容量の上限はあるものの、少なくとも「選別した上で言い換える」ステップを1回減らすことができる。

同一のAgentでスキル、ツール、ナレッジベースをオンデマンドで活用する方法

タスクを単一のAgentに集約する場合でも、最初からすべての業務ルールやツールの説明を詰め込むことは避けるべきである。プロンプトが長すぎると、Token消費が増加し、モデルの注意力が分散してツールの選択ミスを招く恐れがある。

まずは簡潔な「目次」を提示し、特定の能力が必要になった段階で対応する詳細内容を読み込ませる。これが段階的開示（Progressive Disclosure）である。ユーザーがすでに伝えた要件や照会済みの結果は保持し続け、現時点で不要な業務ルール、ツールパラメータ、参考資料は展開しないでおく。

スキルはAgentに「どのように実行するか」を伝える。 例えば返品・交換の手順、ルール、判断基準などは、サブAgentのプロンプトからスキルとして再整理できる。メインAgentは通常は簡潔な要約のみを参照し、タスクで必要になった際に初めて完全な説明を読み込む。

ツールはデータの照会、操作の実行、または固定フォーマットの結果返却を担う。 例えば注文照会や配送確認がこれに該当する。メインAgentはどの操作が必要かを判断した上で、ツール検索を通じて具体的なパラメータ定義を読み込む。

ツールを設計する際は、ユーザーが達成したい目的に沿って関連データをまとめることができ、各バックエンドAPIをそのまま1対1でモデル用ツールとして公開する必要はない。これにオンデマンド検索を組み合わせることで、モデルは低レイヤーのインターフェースが並ぶ長いリストから1つずつ選別する負担から解放される。

ナレッジベースには、必要時にのみ参照する資料を格納する。 業務ポリシー、指標の定義、製品仕様などは、検索ツールやクエリツールを通じて読み込むか、スキルの参照ドキュメントとして扱うことができる。必要なときにのみ参照することで、外部コードによって大量の背景資料が一度にプロンプトへ連結される事態を防ぐ。

Anthropicの知見によると、システムプロンプトに直接記述するツール定義が30–50個を超えると、モデルのツール選択ミスが増加する傾向がある。これは同時に読み込む定義数を制御すべきという示唆であり、ツールライブラリ全体にそれだけのツールしか持てないことを意味するわけではない。Claude Codeでは上位モデル向けにシステムプロンプトをスリム化した際、80%以上削減されたが、その一部はスキルやツールのオンデマンド読み込みによるものである。元のアーキテクチャ図に示されている4–5個のデータツールも特定シナリオの例示に過ぎず、実際の数量は業務要件に応じて決定される。

あるタスクの処理において、基本データの照会、在庫の確認、送料の計算を同時に行う必要があり、これら3つの呼び出しが互いに独立して前後依存関係を持たない場合、3つのサブAgentを起動する必要はまったくない。モデルは単一の推論の中でこれらのツール呼び出しを同時に発行でき、Agentを実行するプログラムがこれらの操作を並行して実行した上で、加工されていない元の返却結果を一度に同一モデルへと戻す。

元の結果を受け取ったモデルは、追加の質問をするか、最終回答を提示するか、あるいは新たに返されたデータに基づいて後続の計画を調整するか、次のアクションを決定できる。呼び出し間に依存関係がない場合にのみ並行実行が可能であり、このアプローチにより、並行実行のスピードを享受しつつ、すべての元の情報を同一のコンテキスト内に保持できる。

Agentを実行するプログラムが、最大ターン数、コスト予算、書き込み権限の制限を担う。モデルが最終回答を出力するか、予算を使い切った時点でループは終了する。

共有コンテキストには依然として容量制限が存在する。極めて長いタスクに対処する際は、注意力の希薄化を防ぐために、記憶機能、ノート記録、能動的なコンテキスト管理手法を組み合わせる必要がある。

サブAgentへの委任が依然として適している作業

Anthropicは、サブAgentの維持を検討すべき3つの状況を挙げている：

第1に、コンテキストが長くなりすぎて実際のパフォーマンスが低下している場合。 実際のテストで検証する必要がある。タスクの実行時間が長くなり、参照情報が蓄積するにつれて、モデルが初期の要件を見落とし始め、タスクの完了精度が下がるような状況である。この場合、比較的独立した調査や整理タスクをサブAgentに委ねることで、メインループの負荷を軽減できる。

第2に、タスクが並行かつ独立した処理に適しており、完了後にそのコンテキストを破棄できる場合。 例えば、複数のコード修正アプローチを同時に試す、異なる方向性を独立してリサーチする、あるいは専用の検証器（Verifier）を構成する場合などが該当する。検証器はテストを個別に実行して結果の詳細とエラー情報を返すだけでよく、実装プロセスの全容を読み込む必要はない。完了後はそのセッションを破棄できるため、試行錯誤の過程でメインコンテキストが汚染されるのを防ぐことができる。

第3に、同一のAgentでは依然としてツールの選択を誤る、あるいは指示同士の共存が真に困難な場合。 異なる業務のルールが明確に衝突している場合や、ツール検索を導入してもモデルが適切なツールを選択できない場合は、専用のサブAgentを用意して切り離して処理できる。なお、前述の30–50個のツールという指標は経験則に基づく警戒ラインであり、この数に達したら直ちにサブAgentを分割しなければならないという意味ではない点に注意が必要である。

どのステップでコンテキストを共有すべきかを優先的に見極めた上で、サブAgentの境界を決定する。 サブAgentの維持を決定する場合は、システムの他の部分との依存が少なく、コンパクトな結果を返すだけで済む独立タスクを割り当てるべきである。2つのステップ間で中間の推論プロセスを頻繁にやり取りしたり、同一の低レイヤーデータを深く共有したりする必要がある場合は、単一のメインループ内に留める方が適している。

既存システムを段階的に改修し、その妥当性を判断する方法

既存システムは段階的に改修できる。まずは改修前後のパフォーマンスを比較できるテストを用意し、一度に1箇所ずつ変更を加えていく。

中央チームがまず約10個のゴールデンサンプル（Golden Examples：期待される結果が明確に定義された典型タスク）を用意し、ユーザーのリクエストからタスク完了までを一気通貫でテストする。基準に沿って最終回答の品質をチェックすることを起点としつつ、アーキテクチャの比較においては、タスクが真に完遂されたかを重視する必要がある。

ディスパッチャーを残している段階では適切なサブAgentを選択できているかを検証し、統合後はメインAgentが適切なスキルを読み込み、正しいツールを呼び出せているかを検証する。これらのログは失敗原因の特定に役立つ。

元の英語アニメーション：3つの移行アプローチ

次の3つのアプローチは組み合わせて使用でき、固定された順序で完了させる必要はない：

1. 頻繁に連携するサブAgentの統合： 使用頻度が高く、連続して呼び出されることが多く、同一のデータを読み込むサブAgentをまず特定する。実際のリクエストにおいて、ある担当Agentを呼び出した直後にもう一方を続けて呼び出すことが多い場合、まずこの2つを統合して引き継ぎを減らすことができる。

2. サブAgentをツールとして呼び出す： サブAgentの内部ロジックを直ちに書き換える予定がない場合、メインAgentがユーザーとの直接の対話を維持しつつ、サブAgentをツールとしてラップして必要に応じて呼び出す形をとることができる。この方式により、サブAgentの返却構造を統一的に規定し、メインループ内でデータを検証できるようになる。 ツールとしてラップした後も、各サブAgentには独自のプロンプト、コンテキスト、保守チーム、局所評価が存在し続ける。呼び出しのたびにモデルの処理サイクルが起動するためレイテンシが増加し、返される要約で情報が欠落するリスクも依然として残る。したがって、サブAgentがユーザーと直接複数ターンの対話を行う必要がある場合にのみ、サブAgentに対話を完全に引き渡す「完全なハンドオフ」（Full Handoff）を採用することが推奨される。それ以外の多くのケースでは、メインループ内のスキルとツールへと集約する方が適している。

3. サブAgentをスキルとツールへ折りたたむ： 各サブAgentのプロンプトに含まれていた業務フロー、トラブルシューティング手順、ルールをスキルとして整理し、呼び出していたバックエンドインターフェースをMCPデータツールに変換する。移行の際は一度に1つのサブAgentのみを折りたたみ、評価データセット上でサブAgentの有無によるタスクパフォーマンスを比較した上で、同等以上の効果が確認されてから元のサブAgentの削除を検討することが推奨される。

高速化を果たした後も、従来正しく処理できていた事項に誤りが生じていないか検証する。

アーキテクチャのパフォーマンスを比較する際は、最終評価の総合スコアを見るだけでなく、個別のテストケースが「パスから失敗」に転じたか、あるいは「失敗からパス」に転じたかを詳細に点検する必要がある。

AnthropicがサンプルのカスタマーサポートAgentをテストした際、あるサブAgentを別のAgentに統合したところ、応答速度は向上したものの、元々はパスしていたタスクが1件失敗した。メインAgentが注文照会ツールを持ったことで、物流担当への配送予定日確認のステップをスキップし、ユーザーに直接回答してしまったのである。

このエラーは2回の実行中1回のみ発生した。そのため、頻繁に一連で実行される業務フローや違反してはならないルールには対応するテストを用意し、同一タスクを複数回実行することで偶発的なエラーを発見しやすくする必要がある。

複数の業務チームが今後それぞれ保守すべき対象

各チームはそれぞれの専門プロセスを引き続き保守するが、その役割分担は「各チームがAgentを1つずつ抱える」体制から、次の2つへとシフトする：

• 中央の少数精鋭チーム：全体で統一されたシステムプロンプトとエンドツーエンドの評価ベンチマークを保守し、回答全体のトーンや品質を担保するとともに、本番適用を控えた新たなスキル、ツール、評価を審査する。中央チームを小規模に保つことで、調整コストを抑え、イテレーションを加速できる。
• 各業務チーム：自らの業務ノウハウをスキルファイルやMCPツールへと落とし込み、スキルに付随する局所評価データセットを提供する。チーム内のスキル直接責任者（DRI）がスキルの品質と独自性を維持し、重複したスキルや使われていないスキルを定期的に点検・整理する。/skill-creatorを用いてスキルの検証・スリム化・重複排除を行い、/skill-doctorを用いてスキルのコストや利用状況を確認し、休眠状態のコンテンツを整理することで、スキルが無秩序に蓄積するのを防ぐ。

業務上の制約や権限チェックは、ツールおよびAgentを実行するプログラム側で担保できる：

• ツールの事前依存性チェック：ツールBの実行がツールAの返却結果に依存している場合、ツールBの内部でチェックを行うことができる。前提となる結果が不足している場合、ツールBは何が不足しているかを明示したプロンプトを返す。モデルはそのプロンプトを読み取ることで、ツールAを追加で呼び出すべきかを判断できる。ただし、ツールのバリデーションはツールが呼び出されたときにのみトリガーされるため、モデルがツールをスキップして直接テキストを出力することを防ぐことはできない。エンドツーエンドの評価によって、こうした不備を事前検知できる。実際の運用環境では、回答が出力される前に出力チェックを行うことも可能である。例えば、配送予定日の確認が必須要件である場合、必要な確認ステップが完了しているかをチェックし、欠けている場合は回答の出力を保留して、Agentに補足実行させるか、未確認である旨を説明させることができる。
• ユーザーに応じた動的権限管理：異なる権限ロールごとに専用のAgentを構築する必要はない。ツール側でリクエスト元ユーザーの権限を直接検証し、未認可の操作に対しては明確な平文で拒絶理由を返すことで、メインループがユーザーに直接理由を説明できるようになる。これにより、単一のループで異なる権限レベルのユーザーに安全に対応できる。

Anthropicは移行キット（Migration Kit）も提供しており、自社のAgentに適用する前にシミュレーション環境で試用できる。以下の4つの補助スキルが連携している：

• /claude-api build-eval：中央チームが管理するエンドツーエンドの評価データセットの構築を支援し、または業務チームがスキルに付属させる局所評価を生成する。
• /claude-api prompt-audit：プロンプト、スキル、ツールの説明に含まれる旧モデル向けの陳腐化したルールを洗い出し、差分比較の形式でスリム化や修正の提案を行う。
• /claude-api hillclimb：既存の評価に基づいてイテレーティブなチューニングを行い、スキル・ツールへの折りたたみ前後とサブAgent維持時のパフォーマンス差異の比較に利用できる。
• /claude-api cost-optimize：呼び出しにおけるToken分布とコストの行き先を分析し、Promptキャッシュの活用、冗長な入出力の削減、モデル選定の最適化に関する提案を行う。

モデル能力の向上に伴い、従来サブAgentが担っていた作業の一部はメインAgentに集約できる。どれを統合でき、どれを残すべきかは、実際のタスクによって判断する。まずは小規模なエンドツーエンド評価を確立し、一度に1箇所ずつ変更を加え、タスク達成度の高いアプローチを残していく。