1. はじめに

この記事を作成する背景は、Foundry Models の候補が多く、性能ランキングだけでは契約や運用上の制約を判断できないことです。本記事の目的は、モデルを分類する実務的な 4 軸と主要機能を整理し、選定からデプロイまでの判断順序を示すことです。

2. Foundry Models とは

2.1 現行名称

製品名は Azure AI Studio、Azure AI Foundry を経て Microsoft Foundry へ変更され、モデル群は Foundry Models と呼ばれます。ポータル URL は https://ai.azure.com のままです。本記事では現行名を使い、検索性が必要な箇所だけ旧称を併記します。

2.2 モデルカタログと統合推論基盤

Foundry Models は、基盤モデル、推論モデル、SLM、マルチモーダル、業種特化モデルなどを発見・比較・評価・デプロイする仕組みです。確認基準日時点の公式概要では 1,900 を超えるモデルを扱います。モデル数は増減するため、一覧そのものではなく分類方法を理解することが重要です。公式概要

複数プロバイダーのモデルを共通の認証・スキーマで扱える統合エンドポイントも提供されます。ただし、すべてのモデルが同じ機能、リージョン、デプロイタイプに対応するわけではありません。

3. モデルを捉える 4 つの分類軸

以下は公式 UI の唯一の分類ではなく、契約から運用までを順序立てて判断するための本記事独自の実務整理です。公式カタログには Collection、Industry、Capabilities、Inference tasks、Deployment options など別のフィルターもあります。

モデルの種類を捉える 4 つの分類軸（調達区分・モダリティ・デプロイタイプ・ライフサイクル）を示す図

3.1 調達区分

最初に、モデルが Azure から直接販売されるか、パートナー／コミュニティ経由かを確認します。

観点Foundry Models sold by AzureModels from partners & community
契約・販売主体Microsoftサードパーティ提供元
課金Azure サブスクリプションAzure Marketplace 経由
SLA・サポートMicrosoft の条件提供元の条件
データ処理Microsoft の規約を確認提供元の規約も確認
主なデプロイStandard、Provisioned、Batch などモデルごとに異なる

Azure OpenAI のモデルは sold by Azure に含まれます。一方、同じプロバイダーでもモデルごとに区分が異なる場合があります。個別モデルの帰属はカタログで確認してください。Azure 直販モデル／パートナー・コミュニティモデル

3.2 モダリティ／タスク

次に「何を処理するか」で候補を絞ります。具体的なモデル名は時点情報になるため、ここではタスク単位で整理します。

タスク主な用途
テキスト／チャット／推論対話、生成、複雑な問題解決
埋め込み／リランク検索、RAG、類似度、順位付け
画像／OCR画像生成、視覚理解、文書解析
音声リアルタイム対話、STT、TTS
動画動画生成
分類／時系列ラベル付け、需要・数値予測

機能呼び出し、構造化出力、長いコンテキストなどの能力は、同じタスク内でもモデルごとに異なります。必要能力を先に列挙してからモデルカードで照合します。

3.3 デプロイタイプ

トラフィック特性、データ所在、コスト、専用計算資源の要否で選びます。公式のデプロイタイプ

タイプ適する要件課金の考え方
Global Standard変動負荷、検証、一般用途トークン従量
Data Zone StandardUS／EU ゾーン内での処理トークン従量
Regional Standard単一リージョンでの処理トークン従量
Provisioned（PTU）恒常高負荷、予測可能な性能処理能力を予約
Batch大量の非同期処理割引従量
Managed Compute専用 GPU、OSS、NIM 等VM／計算資源単位
Instant／Priority即時試用／優先処理Preview を含む

Standard は最初の比較基準にしやすく、安定した高負荷には PTU、夜間処理や一括評価には Batch が向きます。Batch の割引率など具体的な価格は変更されるため、価格ページで確認してください。

3.4 ライフサイクル

モデルの性能だけでなく、Preview、GA、Deprecated、Retired のどこにいるかを確認します。モデル廃止ポリシー

段階新規デプロイ運用上の扱い
Preview可SLA や本番利用条件を個別確認
GA可廃止日と更新方針を管理
Legacy条件付き後継候補を評価
Deprecated制限あり期限までに移行
Retired不可推論停止

Standard は設定によりモデル更新を自動化できますが、Provisioned は移行計画が必要です。ファインチューニング済みモデルは、学習停止と推論停止の日付が分かれる場合があります。ポータル表示、API のライフサイクル状態、廃止日を併読してください。

4. モデル選定の意思決定フロー

4 軸を上流から並べると、候補を機械的に絞れます。

Foundry Models の選び方を示す意思決定フロー図（調達区分からライフサイクル耐性までの絞り込み順序）

  1. 調達区分: Microsoft の契約・サポートが必要か、特定提供元のモデルが必要かを決めます。
  2. モダリティ: チャット、推論、埋め込み、画像、音声など必要なタスクと能力を定義します。
  3. デプロイタイプ: 負荷、データ所在、性能保証、バッチ処理、専用 GPU の要件で選びます。
  4. ライフサイクル: GA / Preview、廃止日、更新方法を運用設計へ組み込みます。

この順序なら、1,900 超の一覧から直接 1 モデルを選ぶのではなく、要件を満たす小さな候補群を作ってから品質・性能・コストを比較できます。

5. 選定から運用を支える主要機能

確認基準日: 2026-07-07

以下の GA / Preview は時点情報です。公式ページ間で表示更新の時期がずれる場合もあるため、導入時は対象リージョンとモデルのページを確認してください。

段階主な機能役割
選ぶカタログ、ベンチマーク、Model Router候補比較と動的ルーティング
鍛えるSFT、DPO、RFT、評価振る舞いの調整と品質測定
守るGuardrails、Prompt Shields、Red Teaming有害出力、攻撃、安全性の検証
運ぶPTU、Spillover、Batch、Prompt Caching性能とコストの最適化
実装する統合推論 API、Structured Outputs、Tool Calling、Foundry Localアプリへの組み込み
測るEvaluation、Monitoring、Tracing、Private Link、RBAC可観測性とガバナンス

5.1 選ぶ

モデルカタログでは、提供元、業種、能力、タスク、デプロイ方法で絞り込みます。ベンチマークは品質・安全性・性能・コストの比較材料ですが、公開データだけで本番品質を保証するものではありません。自社データで評価してください。

Model Router は、要求ごとに候補モデルへ振り分ける単一エンドポイントです。コスト、品質、バランスなどの方針を選べますが、利用可能モデル、リージョン、コンテキスト長の制約を確認します。Model Router

5.2 鍛える

プロンプトや RAG で解決できない振る舞いは、SFT、DPO、RFT などのファインチューニングを検討します。対応手法、対象モデル、課金方式は変化するため、モデルカードと公式手順を基準にします。ファインチューニングの実践記事

評価は、品質、類似度、RAG、安全性、ツール呼び出しなどを測ります。ローカル評価とクラウド評価を使い分け、モデル変更前後を同じデータセットで比較します。

5.3 守る

コンテンツフィルター、Prompt Shields、Protected Material 検出、リスク評価、AI Red Teaming を多層で組み合わせます。Guardrails は入力、ツール呼び出し、ツール応答、最終出力の介入点を管理します。Guardrails の概要

Preview 機能は SLA、リージョン、処理対象を確認し、GA 機能と同じ前提で本番採用しないようにします。

5.4 運ぶ

PTU は処理能力を予約し、Spillover は容量超過時に Standard へ退避します。Batch は大量非同期処理、Prompt Caching は共通プレフィックスの再利用に向きます。割引率や対象モデルを固定値として設計せず、採用時点の価格と制限を確認します。

5.5 実装する・測る

統合推論 API は OpenAI v1 互換の呼び出しを提供します。新規実装では現行 SDK とエンドポイントを選び、廃止予定の旧 SDK／パスへの依存を避けます。Foundry Models のエンドポイント

運用では Evaluation、Monitoring、Tracing を組み合わせ、トークン、レイテンシ、成功率、品質劣化を追跡します。Private Link、Entra ID、RBAC、CMK、データ処理条件もモデル選定と同時に確認します。Observability

6. まとめ

  • モデルは 調達区分 → モダリティ → デプロイタイプ → ライフサイクルの順で絞ります。
  • 調達区分で契約・課金・SLA・データ処理・サポート主体を確認します。
  • 最終候補は、自社データを使って品質・性能・コスト・安全性を比較します。
  • 機能は 選ぶ・鍛える・守る・運ぶ・実装する・測る の 6 段階で設計します。
  • モデル名、GA / Preview、リージョン、料金、廃止日は採用直前に再確認します。

まず第 4 章のフローで調達区分とデプロイタイプを仮決めし、候補モデルを少数に絞って評価してください。

7. 参考情報

この記事の執筆にあたり、AI の支援を受けています。