Agent Design Patterns

テーマ

Routing（ルーティング） ​

入力を分類し、種別ごとに専門化された下流の処理経路（プロンプト・モデル・ツール群）へ振り分ける。関心の分離により、ある入力種別への最適化が他の種別の性能を劣化させることを防ぐ。

別名 ​

呼称出典
Handoff OrchestrationAzure「AI Agent Orchestration Patterns」。エージェント自身が転送を判断する動的な変種
Triage / Dispatch / Transfer / DelegationAzure が Handoff の別称として記載
Handoffs / Decentralized patternOpenAI「A Practical Guide to Building Agents」／ Agents SDK。エージェント間で実行権を一方向に移譲する分散型

問題 ​

多様な入力を単一の万能プロンプトで処理すると、ある入力種別向けの最適化が別の種別の性能を下げる。返金対応の精度を上げるために指示や例を追加すると、技術サポートの応答が引きずられて劣化する——プロンプトが全種別を同時に満たすことを強いられるためである。

全種別に対応しようとするプロンプトは肥大化し、添付するツールも増え続ける。ツールが多すぎるとモデルのツール選択精度そのものが落ちるため、機能を足すほど全体が悪くなるという構造的な行き詰まりに達する。

コンテキスト ​

適用する:

  • 入力に明確に異なるカテゴリが存在し、その分類が（LLMまたは従来の分類モデルで）正確にできる場合
  • カテゴリごとに最適なプロンプト・ツール・モデルが異なる場合（一般質問・返金依頼・技術サポート等）
  • 易しい質問は小型モデルへ、難問は大型モデルへ振り分けるコスト・レイテンシ最適化

適用しない（不要な）ケース:

  • カテゴリの境界が曖昧で分類器の精度が出ない——誤分類のコストが専門化の利益を食い潰す
  • 全入力がほぼ同種で、単一の最適化されたプロンプトで足りる
  • 誤ルーティングがUX上致命的で、フォールバック等の回復手段を用意できない

解決 ​

前段に分類器を置き、入力のカテゴリを判定する。分類器はカテゴリのラベルだけを返し、実際の振り分けは決定論的なディスパッチャがカテゴリ→経路の対応表にもとづいて行う。各経路はそのカテゴリ専用のプロンプト・ツール・モデルを持ち、他の経路を気にせず独立に最適化できる。

これは静的な事前分類（Anthropic の Routing ワークフロー）である。これに対し、処理の途中でエージェント自身が能力限界を認識し、より適切なエージェントへ制御を移す動的な変種が Azure の Handoff である。動的変種は「最適な担当が処理中にしか判明しない」場合に有効だが、転送の連鎖が予測不能になるため、無限転送ループの防止（Budget Guard の併用）が必須になる。

python
ROUTES = {
    "general":   Route(model="small", prompt=faq_prompt,    tools=[kb_search]),
    "refund":    Route(model="small", prompt=refund_prompt, tools=[payment_api]),
    "technical": Route(model="large", prompt=tech_prompt,   tools=[diagnostics]),
}

def handle(user_input):
    category = llm(classify_prompt, user_input)     # 前段の分類（ラベルのみ返す）
    route = ROUTES.get(category.label)              # 振り分け自体は決定論的
    if route is None or category.confidence < THRESHOLD:
        return fallback(user_input)                 # 誤分類の受け皿を必ず用意する
    return llm(route.prompt, user_input,
               model=route.model, tools=route.tools)

実装の要点:

  • 分類とディスパッチを分離する。 分類器はカテゴリのラベルだけを返し、経路の選択は決定論的な対応表で行う。分類器の出力に経路の実装詳細を持ち込まない
  • 誤分類の受け皿を設計する。 信頼度が低い・未知カテゴリの入力はフォールバック経路（汎用プロンプトまたは人間）へ送り、誤ルーティングをログして分類器の改善対象として観測する
  • 動的 Handoff では転送に上限を設ける。 エージェント間のたらい回しや無限転送ループは典型的な障害モードであり、転送回数の上限を決定論的に強制する

トレードオフ ​

  • ✅ 経路ごとにプロンプト・ツール・モデルを独立して専門化でき、全体の精度が上がる。あるカテゴリの改善が他のカテゴリを壊さない
  • ✅ 易しい入力を小型モデルに振り分けることで、品質を保ったままコストとレイテンシを最適化できる
  • ⚠️ 分類器自体が新たな失敗点になる。誤分類された入力は下流の専門経路では回復できないため、誤分類の検知とフォールバック経路の設計が必須
  • ⚠️ 動的 Handoff は転送の連鎖が予測不能になり、無限ループや過剰なたらい回しで応答が遅延・破綻するリスクを持ち込む

クラウドパターンとの対応 ​

クラウドパターン本パターンでの再定義
Gateway Routing「URLパスやヘッダ等のリクエスト属性による転送」から「意味内容の分類による転送」へ。振り分けの判断材料が構造化された属性から、非構造な自然言語の意味理解に変わった
Content-Based Router（EIP）「メッセージの内容を検査して宛先を決める」構造をそのまま継承した直系。ルーティング条件が宣言的なルール記述から分類器（LLM・分類モデル）の推論に置き換わった

関連パターン ​

  • Prompt Chaining — 各経路の内部実装として使う。ルーティング先が単一のLLM呼出である必要はない
  • Orchestrator-Workers — 混同しやすい。Routing は1つの経路を選ぶ、Orchestrator-Workers はタスクを分解して複数のワーカーを実行し結果を統合する
  • Budget Guard — 動的 Handoff 変種の転送回数上限として併用する。無限転送ループの構造的な遮断
  • Layered Guardrails — 分類器はユーザー入力に直接触れるため、分類を誘導する注入攻撃への防御層として併用する

出典・参考 ​

本文: CC BY 4.0 / コード片: MIT。GitHub で寄稿を受け付けています。