Microsoft Foundry Model Router、28 地域へ拡大しモデルプール刷新

Microsoft は最近、Foundry Models におけるモデルルーターの展開地域を、グローバル標準デプロイ向けに 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 はサポート終了に伴いプールから除外されています。デフォルト構成のチームは再デプロイなしでこの変更を自動的に受け取れますが、モデルサブセットを手動で設定していたチームには適用されません。

この違いは重要です。発表内容と ドキュメント の記述に食い違いがあるためです。

今回のアップデートを発表した Sanjeev Jagtap 氏は、自動配信を今回のリリースの核心として強調しました。

最も重要な点は、あなたが何も行う必要がないということです。これらの更新は自動的に発生します。サポート対象モデルプールが刷新されてもエンドポイントは安定しており、チームはモデルルーターを再デプロイすることなく更新を受け取ることができます。

Azure MVP でありクラウドエンジニアの Christos Panagiotidis 氏は、発表文に明記されていないこの違いについて 指摘 しています。

API の安定性と、モデルの動作に関する安定性は別問題です。

プールに追加された新しいモデルは、回答スタイルやツールの選択行動、構造化出力の信頼性、レイテンシ分布、トークン使用量、拒否行動、そして失敗パターンまで変化させる可能性があります。ある専門家はこう指摘しています。

応答スキーマ自体は同一のままでも、アプリケーションのビジネス成果は変わってしまうことがあります。

デフォルト設定での展開において、この主張は正しいです。Model Router はバランスモードで展開され、明示的な指示がない限りサポート対象セット全体に適用されます。つまり、デフォルト設定のままのワークロードでは、これまで評価したことがない候補が 2 つ増える一方で、以前アクセスしていた 4 つのモデルは利用できなくなります。デプロイの更新もバージョンアップもありません。

公式ドキュメントには、今回の発表で触れられていない回避策が記載されています。チームはルーティングを特定のサブセットに制限することが可能で、この設定では後から導入された新しいモデルは、明示的に追加されるまでデフォルトで除外されます。プール利用範囲を限定したチームにとっては、ブログ記事が称賛するような刷新の影響を受けないように保護されているのです。今回の更新はオプトアウト方式であり、そのオプトアウト設定に手を加えるチームはほとんどないでしょう。

発表には明記されていませんが、ルーティングモードは 3 つ存在します。デフォルトの「バランス」モードはコストを抑えつつ品質を維持するもので、「クオリティ」モードは法的レビューや医療要約、複雑な推論など重要なタスク向けに設計されています。一方、「コスト」モードは大量の分類処理や単純な質問応答を対象としています。モードやサブセットの変更には最大 5 分かかる場合があります。

今年初めに発表された制約事項 こちら は、その重要性に見合うほど注目されていませんが、モデルプールが常に変動するため、このルールも固定のものではなく動的に適用されるものです。Microsoft によると、有効なコンテキストウィンドウのサイズは、プール内の最小の基盤モデルのウィンドウサイズに等しくなります。つまり、入力プロンプトが大きすぎる場合でも、ルーティングアルゴリズムがたまたま対応可能なモデルを選んだ場合にのみ処理が成功します。したがって、プールに小さなモデルを追加すると、そこを経由するすべてのリクエストに対する最大処理能力（上限）が引き下げられることになります。

さらに、同じガイダンスには 2 つの制限事項が含まれています。ルーティング判断はテキストベースのみであるため、ビジョン入力は受け付けられますが、画像はどのモデルを選ぶかという決定には影響しません。また、音声入力はサポートされていません。加えて、ルーター自体の入力プロンプトコストも基盤モデルのコストに上乗せされるため、節約効果の主張には必ずこの上乗せ分が含まれていることになります。

Anthropic のモデルには、発表時の脚注やドキュメントのトラブルシューティング項目に記載されている前提条件があります。ルーターがこれらのモデルを選択できるようになるためには、Claude モデルを同じ Foundry アカウントに同一 SKU で別途デプロイしておく必要があります。このデプロイが行われていない状態でサブセットから参照しようとすると、「InvalidResourceProperties」エラーが発生します。つまり、Claude Opus 4.8 がサポートリストに追加されたとしても、自動的に利用可能になるわけではありません。

Microsoft は今回の地域拡大について、コンプライアンスの観点から説明しています。規制要件やガバナンス、顧客信頼の維持のため、推論リクエストは特定の地理的範囲内に留める必要があるという点です。対象地域が 2 か所から 28 カ所に増えることで、データ所在地（レジデンシー）の義務を負うチームにとっての実現可能性は大きく変化します。しかし、この発表資料では、特定の境界内にある候補モデルが利用できない場合に、データゾーンの制約とプール選択がどのように相互作用するかについては言及されていません。

Foundry のモデルルーターは、ポータル、REST API、CLI、ARM テンプレートを通じてデプロイ時に強制される Azure Policy に基づいて動作します。このため、許可されたパブリッシャーリストには Microsoft と、プール内のすべてのモデルのパブリッシャーが含まれている必要があります。

これはデプロイ時のガバナンスであり、Microsoft が最近発表した Azure API Management の AI Gateway tier（ランタイムポリシーの背後にモデルを配置し、ワークロードが到達できる範囲を制御する）と併用した場合の両者の連携方法については、公開資料で明確に説明されていません。

今回の発表では、精度の数値や単一モデルベースラインとのコスト比較、選択ステップにおけるレイテンシのオーバーヘッドといった測定データは一切含まれていません。Microsoft のガイダンスでは、初期デプロイを構成の起点として扱い、本番トラフィックを送信する前にベンチマークを実施することを推奨しています。

また、品質、コスト、レイテンシを一度の実行で計測できる オープンソースの評価パイプライン を公開しており、ルーターを意識したコスト計算や、実際にどの基盤モデルが利用されたかのレポート機能も備えています。

すべてのレスポンスには選択されたモデル名が model フィールドに含まれるため、事後に意思決定の監査が可能です。

プラットフォームチームにとって、今回のリリースによりモデル選択は実行時に行う判断となり、プラットフォーム側で柔軟に決定できるようになります。デフォルト設定では、プールへの更新が到着次第自動的に反映される仕組みです。

パナギオティディス氏は、その後の運用を以下のように定義しています。プールの刷新は管理された依存関係の更新として扱い、評価されたリクエストごとに選択されたモデルを記録し、前年同期と比較します。また、更新によって許容できない結果が生じた場合に備え、プールへのアクセスを制限する道筋も確保しておくべきです。

著者について

ステフ＝ヤン・ウィゲルス

ステフ＝ヤン・ウィゲルス氏は、InfoQ のシニアクラウド編集者の一人であり、オランダの VGZ でドメインアーキテクトとして勤務しています。現在の専門分野は、統合プラットフォームの実装、Azure DevOps、AI、および Azure プラットフォームソリューションアーキテクチャです。

ウィゲルス氏は定期的にカンファレンスやユーザーグループで講演を行い、InfoQ にも寄稿しています。さらに、マイクロソフトからは過去 16 年にわたり「Microsoft Azure MVP」として認定されています。

詳細を表示 | 非表示