Azure AI Foundry の Model Router は、「とりあえずこのエンドポイントに投げれば、裏側で GPT‑4.1 や GPT‑5、o4‑mini などをいい感じに選んでくれる魔法の窓口」です。一方で、エンタープライズ利用では「どのモデルがいつ使われるのかをもっと厳密に制御したい」というニーズが強まっています。この記事では、2025 年時点の Model Router で「できること」「できないこと」と、その制約を前提にした現実的な設計パターンを整理します。
Azure AI Foundry「Model Router」とは何か
Azure AI Foundry（旧 Azure OpenAI / Foundry Models）の Model Router は、単一のチャットモデルとしてデプロイされ、プロンプトを解析してもっとも適した大規模言語モデル（LLM）にルーティングする仕組みです。GPT‑4.1‑nano / mini / 4.1、o4‑mini、GPT‑5‑nano / mini / GPT‑5 / GPT‑5‑chat といった OpenAI 系モデルに加え、最新版では Grok や Llama、DeepSeek、Anthropic Claude なども同一エンドポイントから呼び出せます。
開発者は OpenAI Chat Completions API と同じ形で、model に「model-router のデプロイ名」を指定し、messages にチャット履歴を渡すだけで利用できます。レスポンスの JSON には model フィールドが含まれ、実際に応答を生成した「裏側のモデル名（例：gpt‑4.1‑nano‑2025‑04‑14）」が記録されます。
バージョンと対応モデルのざっくり整理
Model Router 自体にもバージョンがあり、各バージョンごとに「固定のモデル構成」が定義されています。
| Model Router バージョン | 主な対象モデル | 主な特徴 |
|---|---|---|
| 2025‑05‑19 (preview) | gpt‑4.1 / 4.1‑mini / 4.1‑nano, o4‑mini | 基本的な自動ルーティングのみ |
| 2025‑08‑07 (preview) | 上記 + GPT‑5 / GPT‑5‑mini / GPT‑5‑nano / GPT‑5‑chat | GPT‑5 シリーズ対応 |
| 2025‑11‑18 (GA) | 上記 + Grok, DeepSeek, Llama, Claude など | Routing mode と Model subset が追加され、制御性が向上 |
この記事では、質問にある「2025‑05‑19 デプロイ版」を起点にしつつ、2025‑11‑18 の GA 版で追加された機能も踏まえ、「いま何ができるのか」を実務目線で整理します。
Model Router で「モデル制御」はどこまでできるか
よくある要望を整理すると、次の 5 つに集約できます。
- 外部／カスタム（微調整済み）モデルを候補に追加したい
- 特定のモデルだけは絶対に使わせたくない（除外・禁止）
- API パラメータや独自ヘッダーで、候補モデルを制限・指定したい
- プロンプトや設定で「推論特化モデル（o4 / GPT‑5）」を強制的に選ばせたい
- 将来的に、より直接的にルーティングを制御できるロードマップはあるのか
これに対する「2025‑05‑19 時点」と「最新 GA 版（2025‑11‑18）」の答えを表でまとめると、次のようになります。
| 要望 | 2025‑05‑19 版 | 2025‑11‑18 (GA) 版 | 実務での落としどころ |
|---|---|---|---|
| 外部・カスタム（微調整済み）モデルをルーティング対象に追加 | 不可 | 不可（Anthropic など一部公式モデル追加は可） | 自前の API やプロキシを用意し、「自作ルーター」側でモデル選択 |
| 特定モデルの使用禁止（除外） | 不可 | ポータルの「Model subset」で除外可能 | コンプライアンスやコスト要件に応じて、許可モデルだけをサブセットに含める |
| API パラメータ／独自ヘッダーで候補を制限 | 不可 | 不可（reasoning_effort 等は出力制御のみ） | アプリケーション側にルーティングレイヤーを実装し、その中から Model Router または個別モデルを選択 |
| プロンプトや温度設定などで「推論モデルを強制」 | 実質不可 | Routing mode=Quality で「傾向」は変えられるが強制は不可 | 推論が必須な処理は最初から o4 / GPT‑5 を直指定。それ以外を Router に任せる二段階構成 |
| 直接的なルーティング制御のロードマップ | 公開情報なし | Routing mode／Model subset 等の制御機能は追加されたが、 「API からモデルを指名」は未提供 | 長期的にも「完全手動ルーティング」は前提にしない。 必要なら自作ルーターで吸収 |
以降では、各項目ごとにもう少し踏み込み、実務でどう設計するのが現実的かを解説します。
外部・カスタム／微調整済みモデルをルーターに載せたい場合
現状：Model Router が扱えるのは「Microsoft / パートナー提供モデル」のみ
Model Router が内部で呼び出せるモデルは、バージョンごとに Microsoft が定義した「Underlying Models」のみで固定されています。
- GPT‑4.1 シリーズ
- o4‑mini（推論特化モデル）
- GPT‑5 シリーズ（2025‑08 以降）
- GPT‑4o / 4o‑mini、Grok、DeepSeek、Llama 等（2025‑11‑18 以降）
- Anthropic Claude（haiku / sonnet / opus、事前デプロイが必要）
これらはあくまで「Foundry 上の標準モデル」であり、ユーザーが自分で作成した次のようなモデルは、Model Router の候補に加えられません。
- Azure OpenAI / Foundry 上の 微調整（fine-tuning）済みモデル
- Azure Machine Learning などでホストする 独自 LLM
- オンプレミスや別クラウドにある 社内専用モデル
Claude だけは少し特殊で、「Claude モデルを自分の Foundry リソースにデプロイ → Model Router の『Model subset』で有効化」という二段階が必要ですが、あくまで「公式提供モデルを有効化している」だけであって、ユーザー独自モデルを混ぜられるわけではありません。
実務での回避策：自作ルーターを入口にする
この制約を超えて「社内モデルも含めて、ナレッジやタスクに応じて最適なモデルを選びたい」場合は、発想を変えて次のような構成にするのが現実的です。
- クライアント → 自作 API（Gateway / Orchestrator） → 各モデル（Foundry Model Router, 単体モデル, 社内 LLM…）
自作ルーター側で「どのモデルに投げるか」を決め、選択肢のひとつとして Azure AI Foundry の Model Router を使うイメージです。
// 擬似コード例（TypeScript）
type ModelId = "router" | "gpt-5" | "internal-llm";
function selectModel(input: string, meta: { tenant: string }): ModelId {
// 例：テナントごとのポリシーや入力の長さで分岐
if (meta.tenant === "strict-regulated") {
return "internal-llm"; // 社内モデルに固定
}
if (input.length < 800 && !input.includes("法的リスク")) {
return "router"; // 安いモデル中心に Model Router に任せる
}
return "gpt-5"; // 高度推論は GPT-5 を直指定
}
ポイントは「Model Router を唯一のルーターにしない」ことです。Model Router はあくまで「Azure / OpenAI 系モデルの中での最適化レイヤー」と割り切り、その外側に自作のポリシーレイヤーを用意する方が、長期的には柔軟で安全です。
特定モデルの除外・禁止はどこまでできるか
2025‑05‑19 版：完全なブラックボックス
初期の 2025‑05‑19 版 Model Router は、「裏側でどのモデル候補を使うか」をユーザー側から制御する機能がありませんでした。裏側の候補全体（gpt‑4.1 / mini / nano, o4‑mini）から、Model Router が独自のスコアリングに基づいて選択するだけです。
「絶対に o4‑mini は使わせたくない」「nano 系だけで回したい」といったニーズに対しては、
- Model Router を使わず、自分で gpt‑4.1‑mini などを直指定
- または、自作ルーターで gpt‑4.1‑mini のみを選択
という運用しか取れませんでした。
2025‑11‑18 GA 版：Model subset で「許可モデル」を選べるように
GA 版（2025‑11‑18）では、ポータルのデプロイ設定に「Model subset」が追加され、対象モデルのサブセットを GUI 上から選択できるようになりました。
- Routing mode（Quality / Cost / Balanced）を選択
- Model subset で、ルーティング対象に含めるモデルだけをチェック
- 新しく追加されたモデルはデフォルトで除外され、手動で追加するまで使われない
これにより、次のような運用が可能です。
| ユースケース | Model subset の例 | 狙い |
|---|---|---|
| コスト最優先の FAQ チャットボット | gpt‑4.1‑nano, gpt‑4.1‑mini のみ有効 | 高価な GPT‑5 / reasoning 系を完全に除外 |
| 高度な分析・コーディング用アシスタント | gpt‑5 / gpt‑5‑chat / o4‑mini のみ有効 | 常に高性能モデルのみから選択させる |
| 社内規程でサードパーティモデル禁止 | Anthropic / Grok / Llama などをチェックしない | コンプライアンス上許可されたモデルだけに限定 |
2025‑05‑19 版に固定している環境ではこの機能が使えないため、制御が必須なワークロードでは、やはり「Model Router を使わず、固定モデル直指定」が安全です。
API パラメータやヘッダーでモデル候補を制限できるか
Model Router 固有の「制御パラメータ」は存在しない
Model Router は「Chat Completions API と同じ形で使える」ことを重視して設計されています。そのため、API 側に「このリクエストは gpt‑5 系だけから選んで欲しい」といった制御用のパラメータやヘッダーは用意されていません。
model：Router のデプロイ名（例：my-router）messages：チャット履歴temperature,top_p,max_tokensなど：通常の出力制御パラメータ
2025‑11‑18 版からは、reasoning_effort パラメータが Model Router でもサポートされましたが、これは「Router が推論モデルを選択した場合に、そのモデルに渡される設定」であり、「推論モデルを必ず選ばせる」仕組みではありません。
どうしても「リクエスト単位で制御」したい場合
「この API 呼び出しだけは gpt‑5 を使いたい」といった、リクエスト単位の制御が必要な場合は、次のいずれかの設計が必要になります。
- Model Router を使わず、クライアントから直接
model=gpt-5を指定して呼び出す - 自作ルーターを挟み、例えば
X-Target-Modelヘッダーを解釈して内部でルーティングする
// 自作ルーター側のイメージ
const targetModel = req.headers["x-target-model"];
switch (targetModel) {
case "gpt-5":
callOpenAI("gpt-5", body);
break;
case "router":
callOpenAI("my-router", body);
break;
default:
// ポリシーベースで自動選択
callOpenAI(selectModel(body), body);
}
API レベルで「Model Router に直接命令する」ことはできないので、アプリケーションの前段に小さなゲートウェイサービスを置き、そこに制御ロジックを集中させるアーキテクチャが現実的です。
プロンプトや設定で「推論モデル」を強制できるか
Routing mode は「傾向」を変えるだけで、モデルを指名はできない
GA 版 Model Router では、デプロイ時に次の 3 つの Routing mode から選べます。
- Balanced（デフォルト）… コストと品質のバランスを取りつつ、複数モデルから選択
- Quality … 多少高価でも、品質重視で高性能モデルを選びやすくする
- Cost … 品質の許容範囲を広げて、なるべく安価なモデルを選ぶ
Quality モードにすると、複雑なタスクでは o4‑mini や GPT‑5 系が選ばれやすくなりますが、「必ず reasoning モデルだけを使う」わけではありません。Routing mode はあくまでルーター内部のスコアリングの重み付けであり、「このリクエストは必ず GPT‑5 で」といった指示は出せません。
プロンプトで「難しいタスク」を強調するのもあくまで“おまじない”
一部のブログや体験談では、「考え抜いて答えて」「複数ステップの推論が必要」などの文言を追加すると、より重い推論モデルが選ばれやすいという話もあります。しかし、これはルーターの内部判断に「それっぽく」影響を与えているに過ぎず、SLA として保証されているものではありません。
ビジネス上「必ず o4‑mini または GPT‑5 に通したい」処理（例：金額計算、法令解釈、重要なコード生成など）については、次のような二段構成が安全です。
- 軽めの処理：Model Router（Balanced or Cost モード）に任せる
- 重め・クリティカルな処理：最初から gpt‑5 / o4‑mini を直指定
ロードマップ：今後、もっと直接制御できるようになるのか？
2025 年後半にかけて、Model Router には次のような機能追加が行われました。
- GPT‑5 シリーズのサポート（2025‑08）
- Routing mode（Quality / Cost / Balanced）の追加
- Model subset（モデルサブセット）による対象モデルの制御
- Anthropic Claude や Grok、DeepSeek、Llama などの対応
- Agent Service への統合（エージェントのベースモデルとして利用）
一方で、「API パラメータで裏側のモデルを指名する」「このリクエストだけは GPT‑5 に固定するといったオーバーライド機能を提供する」といったロードマップは、公式ドキュメントやブログでは明示されていません。
現時点では、Microsoft は Model Router を「運用負荷を下げ、コストと品質のバランスをとるためのスマートなデフォルト」と位置づけており、「完全にユーザーがルーティングを手動制御するもの」とは位置づけていません。したがって、アーキテクチャ設計も「いつでも自前ルーターに切り替えられる」前提で構築しておくのが安全です。
制御が必要なときのおすすめ設計パターン
パターン 1：自前ルーター＋ Model Router の二段構成
最も汎用的で拡張性が高いのが、「自前ルーター（軽量な API）」 → 「Model Router / 個別モデル」という二段構成です。
| ステップ | 処理内容 | ポイント |
|---|---|---|
| 1. 入口ルーター | リクエスト属性（テナント、用途、重要度、入力長など）を見てルーティング先を判定 | 独自ヘッダーやスコアリングロジックを自由に実装可能 |
| 2-A. Model Router | 汎用チャット・要約・QA など、コストと品質のバランスを取りたい処理 | Routing mode と Model subset で調整しつつ「お任せ」 |
| 2-B. 固定モデル | 推論が重い、またはコンプライアンス的にモデルを固定したい処理 | gpt‑5 / o4‑mini / 社内 LLM などを直指定 |
この構成なら、将来 Model Router に仕様変更があっても、入口ルーター側のポリシーを調整するだけで影響を閉じ込めやすくなります。
パターン 2：ポリシーベースの簡易ルール
あまり複雑なルーターを書くのが難しい場合でも、「最低限のルール」をコードに埋め込んでおくと、無駄なコストや不必要な高性能モデルの利用を抑えられます。
| 条件 | 推奨モデル | 理由 |
|---|---|---|
| 入力トークン < 1,000 / 単純な QA / FAQ系 | Model Router（Balanced）＋ subset で nano / mini のみ | 多くの場合、軽量モデルで十分 |
| 「設計」「アーキテクチャ」「コードレビュー」といったキーワードを含む | gpt‑5 / gpt‑5‑chat | 高度な推論・長文生成が必要 |
| 金額計算・契約条文など、ミスできない領域 | gpt‑5 または gpt‑5＋二重チェック | モデルを固定し、テストと検証をしやすくする |
| 規制業種・機密度の高いデータ | 社内 LLM または利用を禁止 | コンプライアンス上、クラウド上の特定モデル利用を制限 |
パターン 3：フェイルオーバーと冗長構成
Model Router 自体も 429（レート制限）や 5xx（内部エラー）を返すことがあります。高い可用性が必要なシステムでは、ルーター単体に依存しないフェイルオーバー設計が重要です。
- 優先度つき候補リストを持つ
- 第 1 候補：Model Router（Balanced）
- 第 2 候補：gpt‑4.1‑mini の単体デプロイ
- 第 3 候補：社内キャッシュや簡易ルールベース
- 一定時間以内に応答がない場合は、次の候補に切り替える
- 遅延やエラー率をメトリクス化し、閾値を超えたらルーター利用を一時停止する
パターン 4：観測とガードレールを「アプリ側」に寄せる
Model Router は出力の品質や安全性を保証してくれますが、アプリケーション固有のガードレールまでは面倒を見てくれません。次のような観点をアプリ側で実装しておくと安心です。
- モデル別の利用状況の可視化
- レスポンス JSON の
modelフィールドで、どのモデルがどれだけ使われたかを集計 - Azure Monitor / Application Insights / 自前の Dashboard で可視化
- レスポンス JSON の
- 出力検証
- JSON スキーマチェック、数値範囲チェック、ビジネスルールチェックなど
- NG の場合は「再実行」または「別モデルで再生成」
- 安全フィルターと監査ログ
- コンテンツフィルターは Model Router デプロイで一括適用
- ビジネス的に問題のある出力はアプリ側で追加フィルター
パターン 5：コスト管理と契約面の工夫
2025 年 11 月以降、Model Router 自体の利用にも課金が発生するようになりました（従来は裏側モデル分のみ）。 これを踏まえ、次のような設計が重要になります。
- ワークロードごとに「月次コスト上限」を決め、メトリクスから超過しそうならフェイルセーフ（廉価モデル固定など）に切り替える
- 特に高価な GPT‑5 / reasoning 系は、Model subset や自前ルーター側のポリシーで利用を絞る
- 「PoC / 検証環境」は Auto-update を有効にし、「本番」はバージョン固定＋十分な検証を行ってからアップグレード
2025‑05‑19 版と GA 版の違いをもう一度整理
最後に、質問にある「2025‑05‑19 デプロイ版」と、現行 GA 版（2025‑11‑18）の違いを、制御という観点からまとめます。
| 項目 | 2025‑05‑19 版 | 2025‑11‑18 (GA) 版 | 実務的インパクト |
|---|---|---|---|
| 対応モデル | GPT‑4.1 / mini / nano, o4‑mini | 上記 + GPT‑5 シリーズ + 追加モデル多数 | 広いタスクを 1 つのエンドポイントでカバー可能 |
| Routing mode | Balanced 相当のみ | Quality / Cost / Balanced を選択可能 | コスト・品質の優先度をデプロイ単位で調整できる |
| Model subset | なし（候補モデルを絞れない） | あり（チェックしたモデルだけを候補にできる） | 「高価モデル禁止」「特定ベンダー禁止」などが Router レベルで実装可能 |
| 外部・カスタムモデル | 不可 | 依然として不可 | 自前ルーターや別サービスで統合が必要 |
| リクエスト単位のモデル指名 | 不可 | 不可（reasoning_effort はモデル選択後の制御） | 重要処理は固定モデル直指定が必須 |
| 課金 | 裏側モデルのみ | Router 自体にも課金（2025‑11 〜） | Router 利用の費用対効果を定期的に評価する必要 |
まとめ：Model Router には「できること」と「やらせない方がよいこと」がある
ここまでの内容を、設計方針として整理すると次のようになります。
- Model Router は「ブラックボックスな自動最適化レイヤー」と割り切る
- 裏側の候補モデルはバージョンごとに固定で、ユーザーが自由に追加・削除できるわけではない
- GA 版では Model subset により「候補から外す」ことは可能になったが、「API からの指名」はできない
- モデル選択をビジネスロジックの一部にしたいなら、自前ルーターを用意する
- テナント別ポリシー、用途別ポリシー、ヘッダーによるルーティングなどは、自作 API で実装する
- その中の 1 選択肢として Model Router を使うと考えるとスッキリする
- 推論モデルを「強制」したい処理は、Router に任せない
- 金額・契約・法令・コード生成など、誤りコストが高い処理は gpt‑5 / o4‑mini 等を直指定
- Router はあくまで「軽い処理や汎用タスクのコスト最適化」に使う
- Routing mode・Model subset・監視を組み合わせて、コストと品質を継続的にチューニングする
- Model subset で「使ってよいモデル」を絞り、Routing mode でコスト or 品質の軸を決める
- メトリクスで実際のモデル分布とコストを追い、必要に応じて構成を見直す
「とりあえず Router に投げればいい」と考えると、いざというときにコントロールできずに困る場面が出てきます。逆に、「Router の得意なところ（複数モデル間の自動最適化）」と「アプリ側で制御すべきところ（モデル選択ポリシー）」を意識的に分離しておけば、将来のモデル追加や価格変更にも柔軟に対応できるはずです。
今後も Model Router の機能は進化していくと考えられますが、少なくとも現時点では「モデル制御がビジネス要件なら、自前ルーター＋固定モデル指定を基本にし、Model Router はあくまで補助的な最適化レイヤーとして使う」というスタンスが、Azure AI Foundry を安全かつ効率的に使ううえでの現実解と言えるでしょう。
コメント