7月29日、Claudio Masoloが「Microsoft Three-Layer LLM Routing Architecture for AI Agents on AKS」と題した記事を公開した。MicrosoftがAzure Kubernetes Service（AKS）上でAIエージェントのLLMトラフィックを効率よくルーティングするための3層参照アーキテクチャを公開したことについて詳しく紹介している。

なぜ「エージェント向け」ルーティングが必要か

チャットと違い、AIエージェントは「計画→実行→観察」のループを回しながら1タスクで数百回のLLM呼び出しを発生させる。たとえばGPT-4クラスのモデルが1呼び出しあたり数セントかかるとすれば、数百回のループが日常的に走るエージェントでは、1エージェント・1タスクあたりのコストが容易に数ドル規模に達しうる（※編集部の考察）。そのほとんどは、ツール引数の補完・Yes/Noの判定・要約といった軽量なタスクであり、GPT-4のような最上位モデルを使う必要はない。しかし全呼び出しを強力なモデルに送れば、コストとレイテンシは呼び出し数に比例して膨らむ。

さらに、単純なラウンドロビンの負荷分散は状況を悪化させる。200トークンの補完リクエストが、10万トークンのプリフィル処理中のGPUポッドのキューに詰まる一方、隣の空きポッドが遊んでいる——という事態が起きる。

Microsoftが公開した参照アーキテクチャは、この問題を「どのモデルが答えるか」「呼び出しをどう管理するか」「どのGPUレプリカが処理するか」という3つの意思決定に分解し、それぞれ専用コンポーネントに担わせる設計だ。

3層の構成

第1層：意味ルーティング — RouteLLM

プロンプトの内容を解析し、安価なモデルで強力なモデルと同等の回答品質を出せるかを予測する。lm-sysが開発したOSSで、行列因子分解（Matrix Factorization、以下「mf」）ルーターを人間の選好データで訓練したものだ。

重要な数字がある。RouteLLMがテストしたモデルペアでは、mfルーターがGPT-4のMT-Benchスコアの約95%の品質を維持しながら、GPT-4への転送を全体の約26%に抑え、全量を強いモデルに送る場合と比べてコストを最大85%削減できた。

ただしMicrosoftは、この数値が自動的に適用されるわけではないと明記している。RouteLLMのトレーニングに使ったモデルペア固有の値であり、たとえばphi-4-mini/GPT-5.1の組み合わせには直接当てはまらない。実トラフィックでエスカレーション閾値を校正し直す必要がある。

また、プロンプトキャッシュの存在がコスト計算を複雑にする点も指摘されている。キャッシュヒットした入力トークンは割引されるが、モデルを切り替えると両方のキャッシュが冷える。「強いモデルへの呼び出しコスト」は見かけより低い場合があり、閾値の設定に影響する。

第2層：ポリシー管理 — agentgateway

OpenAI互換のオープンソースAIプロキシ。認証・エージェントごとのレート制限・コスト追跡・ガードレールをプロンプトの意味を解析せずに処理する。強いモデル（Azure OpenAI）へのバックエンドと、弱いモデル（KAITO提供ポッド）へのバックエンドを持ち、後者にはinferenceRoutingポリシーを設定する。プロジェクト自体は比較的新しく、著者も「フィールド名がリリースごとに変わる可能性がある」と注意を促している点は留意が必要だ。

第3層：GPU対応配置 — Kubernetes Gateway API Inference Extension

KubernetesのSIG Network傘下で開発が進む拡張仕様で、v1.0.0に到達したばかりの段階だ。Endpoint Pickerが、vLLMのKVキャッシュ占有率（vllm:kv_cache_usage_perc）とキュー深度（vllm:num_requests_waiting）をリアルタイムで参照し、選択されたモデルのどのGPUレプリカにリクエストを送るかを決定する。agentgatewayはext-procプロトコルでEndpoint Pickerを直接呼び出す設計のため、Gateway APIゲートウェイを別途立てずに済む。なお、v1移行時にCRDの名称・構造が大幅に変更されており、既存の設定ファイルを流用する際は公式ドキュメントでのフィールド確認が必須となる。

GPU管理とvLLM実行はKAITOが担い、観測性はAzure Managed PrometheusとGrafanaで、agentgatewayのルーティング・コスト指標とvLLMのGPU指標を一元的に可視化する。

段階的な導入が可能

記事では、全層を一度に導入する必要はないと述べられている。

• エージェント数が少なく、モデルも1つだけの場合：agentgatewayによるガバナンスのみで十分
• 自前でモデルをホストするが、複数モデルは不要な場合：KAITOとInference Extensionで対応し、RouteLLMは不要
• 強いモデルと弱いモデルの間に明確なコスト差があり、軽量なトラフィックが多い場合：RouteLLMを追加する価値がある

注意点：コンポーネントはまだ若い

著者自身が次のように警告している。

Several pieces here are young, and field names drift between releases — the Inference Extension renamed and restructured CRDs on its way to v1. Everything below was validated end-to-end on AKS in mid-2026 against Inference Extension v1.0.0 and agentgateway v1.3.1. Treat the manifests as the shape of the solution, pin your versions, and confirm fields against the docs at the end. The decomposition is stable; specific flags and CRD fields move quickly.

（これらのコンポーネントはまだ若く、リリースごとにフィールド名が変わる。InferencePoolとInferenceObjectiveはAPIグループが異なる。分解の考え方は安定しているが、具体的なフラグやCRDフィールドは変化が速い。）

なお、MicrosoftのFoundry model routerはRouteLLMの意味ルーティング層をマネージドサービス化したものだ。一方、Endpoint PickerのGPU対応配置については、現時点でマネージドの選択肢はなく、どのゲートウェイを使う場合でもクラスター内での運用が必須となる。

詳細はMicrosoft Three-Layer LLM Routing Architecture for AI Agents on AKSを参照していただきたい。