Microsoft Foundry / Azure OpenAIのModel routerは、1つのデプロイで複数のLLMを使い分け、プロンプトごとに適したモデルへ自動ルーティングするための機能です。2026年4月24日に更新されたMicrosoft Learnの公式ドキュメントでは、ルーティングモード、モデルサブセット、自動フェールオーバー、プロンプトキャッシュ、リージョンやレート制限など、実運用で確認すべきポイントが整理されています。IT管理者やプロダクトオーナーにとって重要なのは、「どのモデルを選ぶか」だけでなく、コスト・品質・可用性・コンプライアンスをどう運用設計に落とし込むかです。(Microsoft Learn)
Microsoft Foundry / Azure OpenAIのModel routerとは
Microsoft FoundryのModel routerは、ユーザーのプロンプトをリアルタイムに分析し、最も適した大規模言語モデルへルーティングする仕組みです。Microsoft Learnでは、Model routerを「他のFoundryモデルと同様にデプロイできる単一のモデルデプロイ」と説明しており、コスト削減、レイテンシー低減、応答性向上を狙える機能として位置付けられています。(Microsoft Learn)
従来のAzure OpenAI運用では、用途ごとにモデルを個別に選び、アプリケーション側で「この処理は高性能モデル」「この分類処理は軽量モデル」と振り分ける設計が一般的でした。Model routerを使うと、その判断の一部をFoundry側に任せられます。
たとえば、社内FAQのような単純な問い合わせは低コストなモデルへ、複雑な要約や推論が必要な依頼は高性能なモデルへ振り分ける、といった使い方が想定されます。
ただし、Model routerは「常に最高性能モデルを使う機能」ではありません。プロンプトの内容、選択したルーティングモード、モデルサブセット、デプロイ条件に基づいて、利用可能なモデルの中から選ぶ機能です。ここを誤解すると、期待した品質やコストにならない可能性があります。
2026年4月更新で押さえるべきポイント
2026年4月24日に更新された公式ドキュメントで、実務上とくに重要なのは次の点です。
| 更新・注目ポイント | 実務への影響 |
|---|---|
2025-11-18バージョンのModel routerが中心 | 利用できる基盤モデルや機能はModel routerのバージョンに依存する |
| Global Standard / Data Zone Standardをサポート | グローバル利用とデータ所在地を意識した構成を検討しやすい |
| ルーティングモードを選択可能 | コスト優先、品質優先、バランス重視をワークロードごとに選べる |
| モデルサブセットを指定可能 | 承認済みモデルだけを使う、特定モデルを除外するなどの統制が可能 |
| 自動フェールオーバーを搭載 | 単一モデルの一時的な問題によるアプリ停止リスクを下げられる |
| プロンプトキャッシュをサポート | 対応する基盤モデルにルーティングされた場合、キャッシュ効果を得られる |
| コンテキストウィンドウや画像・音声入力の制約が明記 | 大規模文書処理やマルチモーダル用途では事前確認が必須 |
公式ドキュメントでは、最新バージョン2025-11-18において、gpt-5.2、gpt-5.2-chat、DeepSeek、Grok、Claude、Llama系モデルなどのサポートや、Foundry Agent Serviceで使えるエージェントシナリオへの対応が説明されています。(Microsoft Learn)
Model routerで変わるモデル選定の考え方
Model routerの本質は、モデル選定を「固定」から「リクエスト単位の最適化」へ移すことです。
従来は、アプリケーション単位で1つのモデルを決めることが多くありました。たとえば、カスタマーサポートチャット全体で高性能モデルを使うと、簡単な質問にも高コストなモデルを使うことになります。逆に低コストモデルだけに固定すると、複雑な問い合わせで品質が落ちやすくなります。
Model routerでは、プロンプトの複雑さ、推論の必要性、タスクの種類などをもとにルーティングします。Microsoftの説明では、プロンプトは保存されず、アクセス権やデプロイタイプに基づく適格なモデルへルーティングされ、データゾーンの境界も尊重されます。(Microsoft Learn)
実務では、次のようなワークロードで特に効果を検証しやすいです。
| ワークロード | Model routerとの相性 | 理由 |
|---|---|---|
| 社内FAQチャット | 高い | 簡単な質問と複雑な質問が混在しやすい |
| カスタマーサポート一次対応 | 高い | 応答速度とコストの両立が重要 |
| 文書要約・議事録要約 | 中〜高 | 文書量や推論難度に差がある |
| コード生成支援 | 中〜高 | 簡単な補完と複雑な設計相談で必要性能が変わる |
| 法務・医療など高リスク判断 | 慎重に検討 | 品質優先や直接デプロイの併用が必要 |
| 常に同一モデルの出力が必要な処理 | 低い | 毎回同じモデルを使いたい場合は直接デプロイが向く |
ポイントは、Model routerを「全用途の置き換え」と考えないことです。多様なリクエストが流れる一般用途はModel router、特定モデルに固定すべき高リスク処理は直接デプロイ、というハイブリッド構成が現実的です。
ルーティングモードは3種類：Balanced、Quality、Cost
Model routerでは、カスタムデプロイを選ぶ場合にルーティングモードを指定できます。公式ドキュメントでは、Balanced、Quality、Costの3種類が示されています。設定しない場合はBalancedが既定です。(Microsoft Learn)
| モード | 向いている用途 | 判断基準 |
|---|---|---|
| Balanced | 一般的な業務チャット、社内FAQ、標準的な生成AI機能 | 品質とコストの両方を見たい場合の初期値 |
| Quality | 複雑な推論、重要文書の要約、レビュー業務 | コストより回答品質を優先したい場合 |
| Cost | 大量の分類、単純なQ&A、下書き生成 | 多少の品質差よりコスト削減を重視する場合 |
最初はBalancedで始めるのが現実的
多くの企業では、いきなりCostやQualityに寄せるより、Balancedでトラフィックを流して実績を見るほうが安全です。理由は、実際のユーザーのプロンプト分布が事前の想定と違うことが多いからです。
たとえば、プロダクトオーナーが「問い合わせは単純なFAQが中心」と考えていても、実際には契約条件、障害調査、ログ解釈、コード修正依頼が混在するケースがあります。最初からCostモードにすると、難しい問い合わせで品質不足が出る可能性があります。
おすすめの進め方は次の通りです。
| フェーズ | 設定 | 確認すること |
|---|---|---|
| 検証開始 | Balanced | どのモデルにどの程度ルーティングされるか |
| コスト最適化 | Costを一部用途で試す | 品質劣化が許容範囲か |
| 重要処理の強化 | Qualityまたは直接デプロイ | 誤回答時の影響が大きい処理を切り分ける |
| 本番安定化 | 用途別にモードを分ける | コスト、品質、レイテンシー、失敗率を継続監視する |
モデルサブセットはガバナンスの要
2026年4月更新で特にIT管理者が注目すべきなのが、モデルサブセットです。Model routerの最新バージョンでは、ルーティング対象に含める基盤モデルを指定でき、コスト、コンプライアンス、パフォーマンス特性をより細かく制御できます。新しい基盤モデルが利用可能になっても、明示的に追加しない限り選択には含まれません。(Microsoft Learn)
これは、エンタープライズ利用では大きな意味があります。モデルが増えるほど選択肢は広がりますが、同時に次のような確認事項も増えるためです。
- 自社のセキュリティ審査を通ったモデルか
- データ所在地やデータ処理条件が要件に合うか
- 特定の業務で利用してよいモデルか
- 出力品質やレイテンシーの検証が済んでいるか
- プレビュー扱いのモデルを本番に入れてよいか
特にグローバル企業では、国・地域ごとのデータ要件、監査要件、利用可能リージョンが異なります。Model routerを使う場合でも、「Microsoftが自動で選ぶから問題ない」ではなく、承認済みモデルだけをサブセットに入れる設計が重要です。
モデルサブセット設計の例
| 用途 | サブセット方針 | 理由 |
|---|---|---|
| 社内ナレッジ検索 | 承認済みの汎用モデル中心 | コストと品質のバランスを取りやすい |
| 法務レビュー支援 | 高品質モデル中心、プレビューは除外 | 出力品質と監査性を重視 |
| 大量分類処理 | 軽量・低コストモデル中心 | 1件あたりコストを下げやすい |
| エージェントワークフロー | ツール利用に適したモデルを含める | Function callingや推論性能が重要 |
| 本番初期導入 | 少なくとも2モデル以上を選択 | フェールオーバーの効果を得るため |
公式ドキュメントでも、カスタムデプロイ構成ではモデルサブセットがフォールバックセットとして機能するため、フェールオーバーの恩恵を受けるには少なくとも2つのモデルを含めるよう説明されています。(Microsoft Learn)
自動フェールオーバーで可用性は上がるが、過信は禁物
Model routerには組み込みの自動フェールオーバーがあります。既定のデプロイでサポート対象のすべてのモデルへルーティングする場合、単一モデルに一時的な問題が起きても、次に適したモデルへ透過的にリダイレクトされます。フェールオーバーは既定で有効で、追加構成は不要です。(Microsoft Learn)
これは、生成AIアプリケーションの運用では大きな利点です。従来は特定モデルの一時的な不安定さに備えて、アプリケーション側でリトライ、代替モデル、タイムアウト処理を実装する必要がありました。Model routerにより、その一部をサービス側で吸収しやすくなります。
ただし、可用性設計をすべてModel router任せにするのは危険です。次の点はアプリケーション側でも設計しておくべきです。
| 注意点 | 対応策 |
|---|---|
| モデルが変わると出力傾向も変わる | 回答品質の評価基準をログで追跡する |
| サブセットが1モデルだけだと代替先がない | 最低2モデル以上を選ぶ |
| リージョン障害には別設計が必要 | リージョン冗長化や業務継続手順を検討する |
| タイムアウトはアプリ側にも必要 | API呼び出しの再試行、バックオフ、ユーザー通知を設計する |
| 重要業務では説明責任が必要 | 応答のmodelフィールドを記録し、どのモデルが処理したか追跡する |
Model routerは可用性を高める部品ですが、SLA、監査、障害時対応を含む運用設計の代替にはなりません。
プロンプトキャッシュは「効く場合」と「効きにくい場合」がある
Model routerはプロンプトキャッシュをサポートします。公式ドキュメントでは、リクエストがプロンプトキャッシュ対応の基盤モデルで処理される場合、キャッシュされたトークンが自動的に使われ、追加設定は不要と説明されています。(Microsoft Learn)
ただし、Model routerでは毎回同じ基盤モデルにルーティングされるとは限りません。そのため、キャッシュの効果は「同じモデルが、重複するプロンプトプレフィックスを持つ連続リクエストを処理した場合」に出やすくなります。(Microsoft Learn)
キャッシュ効果が出やすい例
- 同じシステムプロンプトを使う社内チャット
- 同じ長い業務ルールを前提にした問い合わせ
- 同一テンプレートで繰り返す文書分類
- 固定のガイドラインを含むレビュー支援
キャッシュ効果が出にくい例
- 毎回まったく異なる長文ドキュメントを渡す処理
- ルーティング先モデルが頻繁に変わる処理
- 会話履歴が大きく変化するチャット
- モデルサブセットが広く、同じモデルに当たりにくい構成
コスト最適化を狙うなら、単にModel routerを有効化するだけでなく、システムプロンプトや共通指示を安定させる設計も重要です。
コンテキストウィンドウの制限に注意する
Model routerを使うときに見落としやすいのが、コンテキストウィンドウです。公式ドキュメントでは、Model routerの有効なコンテキストウィンドウは、基盤モデルの中で最小のモデルによって制限されると説明されています。より大きなコンテキストが必要な場合は、要件を満たすモデルをモデルサブセットで選ぶ必要があります。(Microsoft Learn)
つまり、「Model router配下に大きなコンテキスト対応モデルが含まれているから大丈夫」とは限りません。プロンプトがどのモデルにルーティングされるかによって、成功する場合と失敗する場合があり得ます。
長文文書やRAGを扱う場合は、次のように設計します。
| 課題 | 対策 |
|---|---|
| 入力文書が長すぎる | 事前要約、分割、関連部分の抽出を行う |
| コンテキスト超過エラーが出る | 大きなコンテキストに対応するモデルだけをサブセットに入れる |
| RAGの検索結果が多すぎる | 検索件数、チャンクサイズ、再ランキングを調整する |
| 会話履歴が肥大化する | 古い履歴を要約して保持する |
| モデルによって処理可否が変わる | 本番前に代表プロンプトでルーティングと失敗率を検証する |
公式ドキュメントでも、コンテキストを短くする方法として、プロンプトの要約、関連部分への切り詰め、ドキュメント埋め込みと検索の活用が示されています。(Microsoft Learn)
画像入力には対応するが、音声入力は処理しない
Model routerはVision対応チャットの画像入力を受け入れます。ただし、ルーティング判断はテキスト入力に基づくとされています。また、音声入力は処理しません。(Microsoft Learn)
この点は、マルチモーダルアプリを設計する際に重要です。
たとえば、画像付き問い合わせを受け付けるヘルプデスクでは、画像の内容に応じて最適モデルを選ぶというより、テキスト側の問い合わせ内容をもとにルーティングされると考えるべきです。音声については、別途音声認識でテキスト化してからModel routerへ渡す構成が必要になります。
対応リージョンとレート制限は本番前に必ず確認する
公式ドキュメントでは、Model routerのリソース制限として、米国東部2とスウェーデン中部が示され、Global StandardとData Zone Standardのデプロイタイプがサポート対象として掲載されています。また、model-routerの2025-11-18では、Data Zone StandardとGlobal StandardでRPM、TPMの既定値が異なります。(Microsoft Learn)
| 項目 | 確認すべきこと |
|---|---|
| リージョン | 利用したいFoundryリソースのリージョンでModel routerが使えるか |
| デプロイタイプ | Global StandardかData Zone Standardか |
| レート制限 | RPMとTPMが想定トラフィックに足りるか |
| エンタープライズ契約 | Enterprise / MCA-E向け上限が適用されるか |
| データ所在地 | グローバル利用時に社内ポリシーへ適合するか |
| 障害時対応 | リージョンやモデル単位の問題に備えた手順があるか |
日本企業がグローバル向けサービスで利用する場合は、単に「使えるか」だけでなく、データ処理地域、社内承認、監査ログ、利用部門ごとの責任範囲まで確認しておくと後戻りが少なくなります。
Claudeモデル利用時は個別デプロイが必要
Model routerでは、サポートされているLLMを個別にデプロイせずに利用できる場合があります。ただし、Claudeモデルについては例外で、Model routerで使うには事前にモデルカタログからデプロイする必要があります。(Microsoft Learn)
ここは導入時に詰まりやすいポイントです。
「サブセットにClaude系モデルを含めたのにルーティングされない」という場合、モデル自体の個別デプロイが済んでいない可能性があります。公式ドキュメントのトラブルシューティングでも、Claudeモデルがルーティングしない場合は、Model routerで有効にする前にClaudeモデルが個別にデプロイされていることを確認するよう案内されています。(Microsoft Learn)
Model routerを導入する基本手順
Model routerは、Foundry上で単一のモデルとしてデプロイします。公式の手順では、モデルカタログでmodel-routerを選択し、既定設定またはカスタム設定を選びます。既定設定ではサポートされているモデル間でルーティングし、カスタム設定ではルーティングモードやモデルサブセットを指定できます。(Microsoft Learn)
実務では、次の手順で進めると安全です。
| 手順 | 作業内容 | 確認ポイント |
|---|---|---|
| 事前整理 | 対象ワークロードを分類する | FAQ、要約、分類、エージェントなどに分ける |
| 要件確認 | 品質、コスト、レイテンシー、データ要件を決める | どれを優先するか明文化する |
| モデル承認 | 利用可能なモデルを社内で審査する | プレビュー扱いのモデルを本番利用するか決める |
| デプロイ | model-routerをデプロイする | リージョンとデプロイタイプを確認する |
| ルーティング設定 | Balanced / Quality / Costを選ぶ | 最初はBalancedで検証しやすい |
| モデルサブセット設定 | 承認済みモデルを選ぶ | 最低2モデル以上を推奨 |
| 検証 | 代表プロンプトで品質とコストを比較する | 単純・複雑・長文・画像ありなどを含める |
| 監視 | Azureポータルやログで利用状況を見る | 応答モデル、トークン、失敗率、コストを追跡する |
| 本番展開 | 段階的にユーザーへ展開する | 重要業務は直接デプロイとの併用も検討する |
特に重要なのは、PoCで「回答が良いか」だけを見るのではなく、どのモデルにルーティングされたか、どの程度のコストになったか、失敗時にどう振る舞うかまで確認することです。
運用で見るべきログとメトリクス
Model routerの運用では、モデルが自動選択されるからこそ、観測可能性が重要になります。Microsoftの解説では、選択されたモデルはAPIレスポンスのmodelフィールドで確認できるとされています。(Microsoft Learn)
最低限、次の項目は記録しておきたいところです。
| 観測項目 | 目的 |
|---|---|
| 選択された基盤モデル | どのモデルがどの用途で使われているか把握する |
| 入力・出力トークン数 | コスト増加の原因を特定する |
| レイテンシー | ユーザー体験への影響を確認する |
| エラー率 | コンテキスト超過、レート制限、モデル障害を検出する |
| ルーティングモード | 設定変更による影響を比較する |
| モデルサブセット | 承認外モデルが使われていないか確認する |
| ユーザー評価 | 実際の満足度や修正率を確認する |
たとえば、Costモードに変更した後に問い合わせの再送率やオペレーターへのエスカレーション率が上がった場合、表面上のAPIコストは下がっても、業務全体のコストは上がっている可能性があります。
よくある失敗と回避策
失敗：とりあえず全モデルにルーティングさせる
検証環境では問題ありませんが、本番環境で全モデルを無条件に対象にすると、社内承認が済んでいないモデルやプレビュー扱いのモデルが含まれる可能性があります。
回避策は、モデルサブセットを使い、業務・地域・リスクに応じて承認済みモデルだけを含めることです。
失敗：単一モデルだけをサブセットにする
単一モデルだけを指定すると、ルーティング最適化や自動フェールオーバーの利点がほとんど失われます。公式ドキュメントでも、フェールオーバー機能の恩恵を受けるには少なくとも2つのモデルを含めるよう説明されています。(Microsoft Learn)
固定モデルが必要なら、Model routerではなく直接デプロイのほうが適している場合があります。
失敗：長文処理をそのまま投入する
Model routerのコンテキスト制限は、基盤モデルの中で最小のモデルに左右されます。長文文書、RAG、大量の会話履歴を扱う場合は、要約、分割、検索結果の絞り込みを設計に入れる必要があります。
失敗：コストだけを見て品質劣化を見逃す
Costモードは有効な選択肢ですが、問い合わせ対応や業務支援では、回答品質の低下が人手対応増加につながることがあります。APIコストだけでなく、再問い合わせ率、修正工数、エスカレーション率も合わせて見ましょう。
失敗：モデル更新の影響を管理しない
Model routerの各バージョンは、基盤モデルとそのバージョンの特定セットに紐づきます。自動更新を選ぶと新バージョン利用時に基盤モデルのセットも変わり、パフォーマンスやコストへ影響する可能性があります。(Microsoft Learn)
本番環境では、自動更新を使うか、検証後に更新するかを運用ポリシーとして決めておくべきです。
IT管理者・プロダクトオーナー向け導入判断チェックリスト
Model routerを本番導入する前に、次の項目を確認してください。
| チェック項目 | 判断の目安 |
|---|---|
| 複数種類のプロンプトが混在しているか | 混在しているほどModel routerの効果を検証しやすい |
| 常に同一モデルが必要か | 必要なら直接デプロイを検討する |
| コスト最適化が重要か | 重要ならBalancedまたはCostで比較する |
| 品質低下の業務影響が大きいか | 大きい場合はQualityまたは直接デプロイを併用する |
| 承認済みモデル一覧があるか | ない場合はモデルサブセット設計の前に整備する |
| 長文入力が多いか | 多い場合はコンテキスト要件を満たすサブセットにする |
| Claudeモデルを使うか | 使う場合は個別デプロイを確認する |
| 監査ログが必要か | 応答のmodelフィールドやトークン情報を記録する |
| 利用リージョンが要件に合うか | 米国東部2、スウェーデン中部など公式情報を確認する |
| フェールオーバーを期待するか | サブセットに最低2モデル以上を含める |
どんな企業に向いているか
Model routerは、次のような企業・チームに向いています。
- 生成AIアプリを複数部門で使い始めている
- モデルごとのコスト差が大きく、最適化が課題になっている
- Azure OpenAI / Microsoft Foundryを標準基盤として運用したい
- 社内FAQ、問い合わせ対応、要約、分類、エージェントなど用途が広がっている
- モデル選定をアプリケーションごとに実装する負荷を減らしたい
- グローバル展開でデータゾーンや承認済みモデルの統制が必要
一方で、次のケースでは慎重に評価したほうがよいでしょう。
- 出力の再現性を重視し、毎回同じモデルを使いたい
- 特定モデルの性能検証に基づく厳密な承認フローがある
- 非常に長いコンテキストを常に扱う
- 音声入力をそのまま処理したい
- モデルが変わること自体が監査上の問題になる
このような場合は、Model routerを全面採用するより、直接デプロイと組み合わせるほうが現実的です。
まず何をすべきか
Microsoft Foundry / Azure OpenAIでModel routerを検討するなら、最初にやるべきことは「デプロイ」ではなく、自社のプロンプトを分類することです。
問い合わせ、要約、分類、コード支援、エージェント処理など、実際に流れるプロンプトを20〜50件ほど集め、難易度、重要度、許容コスト、必要レイテンシーで分類します。そのうえでBalancedモードを起点に検証し、モデルサブセットで承認済みモデルだけに絞り、ログでルーティング結果を確認します。
Model routerは、モデル選定を楽にする機能であると同時に、運用設計の質が結果に直結する機能です。2026年4月更新で整理されたルーティングモード、モデルサブセット、自動フェールオーバー、プロンプトキャッシュ、制限事項を踏まえ、まずは低リスクな業務から小さく検証し、コスト・品質・可用性のバランスを数値で見ながら本番展開するのが安全です。
コメント