マイクロソフトは最近、Foundry ModelsのModel Routerを拡張し、グローバル標準デプロイメントの対応リージョンを2から28へ、データゾーンデプロイメントの対応リージョンを21へ拡大しました。また、モデルルーターが選択するモデルプールも刷新されています。今回のリリース以前は、モデルルーターは East US 2 と Sweden Central の2リージョンでのみ稼働していた。
モデルプールには Anthropic Claude Opus 4.8 と GPT-5.6 ファミリーが追加された。一方で、gpt-5-chat、gpt-5.2-chat、gpt-5.3-chat、および DeepSeek-V3.1 はサポート終了（EOL）に伴い除外された。デフォルト構成を使用しているチームは、再デプロイ不要でこの変更が適用される。特定のモデルセットを構成しているチームには、この変更は自動適用されない。
この違いは重要だ。なぜなら、発表内容とドキュメントでは説明の仕方が異なるためだ。
このアップデートを発表したSanjeev Jagtap氏は、このリリースのポイントは変更が自動的に適用されることだとしている。
もっとも重要なポイントは、利用者側で対応する必要がないことです。サポート対象のモデルプールが刷新されてもエンドポイントはそのまま維持されるため、アップデートを受けるためにモデルルーターを再デプロイする必要はありません。
Azure MVP でありクラウドエンジニアのChristos Panagiotidis氏は、この発表では暗黙のままとなっていた区別を明確に指摘している。
API の安定性と挙動の安定性は別物です。
モデルプールに新しいモデルが追加されると、回答スタイル、ツール選択の動作、構造化出力の信頼性、レイテンシの分布、トークン使用量、拒否応答の挙動、さらには障害パターンが変化する可能性がある。同氏は次のように述べている。
レスポンスのスキーマは同一のままでも、アプリケーションのビジネス成果が変わる可能性があります。
デフォルトのデプロイメントについては、Jagtap 氏の説明は正確だ。モデルルーターは、特に指定がない限り、サポート対象の全モデルセットに対して Balanced モードで動作する。そのため、デフォルト設定のワークロードでは、これまで評価したことのない2つの新たな候補モデルが追加される一方、利用されていた可能性のある4つのモデルは削除される。しかも、これらの変更はデプロイやバージョン番号の更新なしに適用される。
ドキュメントでは、発表では触れられていない例外的な制御手段について説明している。チームはルーティング対象を任意のモデル群に制限でき、その構成では後から追加された新しいモデルは、明示的に追加しない限りデフォルトでは対象に含まれない。そのため、モデルプールを制限しているチームは、ブログ記事で強調されている今回のモデルプール刷新の影響を受けないよう保護されている。このアップデートはオプトアウト方式だが、その設定を変更しているチームは多くないだろう。
3つのルーティングモードが存在するが、これらについては発表では触れられていない。Balanced は品質を維持しながらコストを最適化するモードで、デフォルト設定となっている。Quality は重要度の高い業務向けで、マイクロソフトは法務レビュー、医療要約、複雑な推論などを例として挙げている。Cost は大量の分類処理や単純な質問応答向けのモードだ。モードや対象モデルセットの変更は、反映まで最大5分かかる。
今年初めに公表されたある制約は、 これまで受けてきた以上の注目に値する。モデルプールが変化するようになったことで、その制約は固定条件ではなく動的なものになったためだ。マイクロソフトによると、有効なコンテキストウィンドウは基盤となるモデル群のうち、もっとも小さいコンテキストウィンドウに制限される。また、上限を超えるサイズのプロンプトは、ルーターがたまたま対応可能なモデルを選択した場合にのみ処理される。そのため、より小さなコンテキストウィンドウを持つモデルがプールに追加されると、そのプールを経由するすべてのリクエストの上限が引き下げられることになる。
さらに、同じガイダンスには2つの制約が記載されている。1つ目は、ルーティングの判断がテキスト情報のみに基づいて行われる点だ。そのため、画像入力自体は受け付けられるものの、どのモデルを選択するかの判断に画像は影響しない。また、音声入力には対応していない。2つ目は、モデルルーターが基盤モデルの利用料金に加えて、ルーター自身の入力プロンプトに対する料金も課金する点だ。このため、コスト削減効果をうたう場合でも、その中にはルーター利用分の追加コストが含まれている。
Anthropicのモデルには、発表では脚注として、ドキュメントではトラブルシューティング項目として記載されている前提条件がある。Claudeモデルをモデルルーターの選択対象にするには、同じFoundryアカウント内に対応する SKU で個別にデプロイしておく必要がある。また、そのデプロイが存在しない状態でモデルサブセットにClaudeモデルを指定すると、InvalidResourcePropertiesエラーが発生する。そのため、Claude Opus 4.8がサポート対象モデルの一覧に追加されたとしても、それだけで利用可能になるわけではない。
マイクロソフトは、このリージョン拡大をコンプライアンスの観点から位置付けており、推論リクエストを特定の地理的境界内に留める必要があるのは、規制要件、ガバナンス要件、あるいは顧客の信頼に関する要件が理由だと説明している。対応リージョンが2から28へ拡大されたことで、データレジデンシー要件を持つチームにとって、モデルルーターの活用はより現実的な選択肢となった。一方で、公開されている資料では、データゾーンの制約下において、候補となるモデルがその境界内で利用できない場合に、モデルプールの選択がどのように行われるのかについては説明されていない。
モデルルーターは、Foundryモデルのデプロイメントに対して組み込みのAzure Policyを適用し、ポータル、REST API、CLI、ARM テンプレートを通じたデプロイ時にポリシーを強制する。このため、許可されたパブリッシャーの一覧には、マイクロソフトに加えて、モデルプール内のすべてのモデルのパブリッシャーを含める必要がある。これはデプロイ時のガバナンス機能であり、最近発表されたAzure API ManagementのAI Gateway tierに関して新たな疑問を残している。AI Gateway tierは実行時のポリシーに基づいてモデルへのアクセスを制御し、ワークロードが利用できるモデルを制限する機能を提供する。両方を導入した場合、それらがどのように連携して動作するのかについて、公開されている資料では説明されていない。
この発表には測定結果が含まれていない。単一モデル構成との比較における精度指標やコスト比較、ルーティングの選択処理によるレイテンシのオーバーヘッドなどは示されていない。マイクロソフトは、初回デプロイメントを出発点となる構成として扱い、本番トラフィックを流す前にベンチマークを実施することを推奨している。また、品質、コスト、レイテンシを1回の実行で測定できるオープンソースの評価パイプラインを公開しており、このパイプラインにはモデルルーターを考慮したコスト計算機能や、ルーターが実際にどの基盤モデルへルーティングしたかをレポートする機能も含まれている。
すべてのレスポンスには、選択されたモデル名がmodelフィールドに記録されるため、どのモデルが使用されたかを後から監査できる。
プラットフォームチームにとって、このリリースによりモデル選択はプラットフォーム側が実行時に行う判断となり、デフォルト構成ではモデルプールの変更が発生すると自動的に受け入れられるようになる。Panagiotidis氏は、その後に必要となる運用上の考え方について、モデルプールの更新を管理対象の依存関係アップデートとして扱うべきだと説明している。具体的には、評価対象となるすべてのリクエストについて実際に選択されたモデルを記録し、前期間との比較をする、更新によって許容できない結果が生じた場合に備えてモデルプールを制限できる手段を維持しておくことが重要だとしている。