Azure AIの公式ドキュメント更新「group model availability tables by model capabilities」は、モデルの実行仕様そのものが大きく変わったというより、Global Standard のモデル可用性表を、モデルの機能別に確認しやすく整理した更新と見るのが実務上の正しい捉え方です。開発者やクラウド管理者がまず確認すべきなのは、「使いたいモデルがあるか」だけではありません。利用リージョン、デプロイ種類、モデルバージョン、Chat・Embedding・Audio・Image/Video などの機能カテゴリまでセットで確認する必要があります。
今回の更新は、Azure OpenAI in Microsoft Foundry Models を使っているチームにとって、設計・運用・移行準備の見直しポイントになります。特に、社内の設計書やIaC、モデル選定表、リージョン別の運用ルールを公式ドキュメントの表に合わせて管理している場合は、単なる表示変更として流さず、確認手順を更新しておくべきです。
Azure AIの公式ドキュメント更新「group model availability tables by model capabilities」で何が変わったか
2026年4月28日の MicrosoftDocs/azure-ai-docs のコミットでは、Azure OpenAI in Microsoft Foundry Models 向けの Global Standard model availability に関する表が、機能カテゴリ別に整理されました。GitHub上のコミットでは「group model availability tables by model capabilities」として記録され、2ファイルが変更され、150行追加・1行削除されています。(GitHub)
具体的には、standard-global-by-capability.md という新しい include ファイルが追加されました。このファイルのメタ情報には、Global Standard model availability - grouped by capability、ms.date: 04/28/2026、ms.service: microsoft-foundry、ms.subservice: foundry-openai が設定されています。(GitHub)
また、既存の models-azure-direct-openai.md 側では、従来の standard-global.md include がコメントアウトされ、新しい standard-global-by-capability.md が読み込まれる形に変更されています。つまり、公式ドキュメントの表示構造が「従来の表」から「機能別にグルーピングされた表」へ置き換えられた更新です。(GitHub)
| 確認項目 | 変更前の見方 | 更新後の見方 |
|---|---|---|
| モデル可用性 | モデル一覧から対象モデルを探す | まず機能カテゴリを選び、その中でモデルとリージョンを確認する |
| 主な分類軸 | モデル名・リージョン中心 | Chat、Embedding、Audio、Image and Video などの能力別 |
| 実務上のメリット | 一覧性はあるが、用途別確認がしづらい | RAG、音声処理、画像生成などユースケース単位で確認しやすい |
| 注意点 | 表の構成変更に気づきにくい | スクレイピングや社内資料の更新が必要になる可能性がある |
追加された機能別テーブルの中身
新しく追加された表は、Global Standard のモデル可用性を以下のような機能カテゴリに分けています。
| 機能カテゴリ | 主な確認用途 | 実務で見るべきポイント |
|---|---|---|
| Chat models | チャット、推論、エージェント、コード支援 | 対象モデル、バージョン、リージョン、API対応 |
| Embedding models | RAG、検索、類似度計算、ベクトル化 | 既存ベクトルの再生成要否、リージョン対応 |
| Audio models | 音声認識、音声生成、リアルタイム音声 | 利用リージョン、プレビュー扱い、遅延要件 |
| Image and Video models | 画像生成、動画生成 | 対応リージョン、商用利用時の審査・制約確認 |
コミット上では、Chat models、Embedding models、Audio models、Image and Video models というタブ形式の見出しが追加されています。Chat models では多数の GPT 系・reasoning 系・audio 関連モデルを含む大きな可用性表があり、Embedding models では text-embedding-ada-002、text-embedding-3-large、text-embedding-3-small が並びます。Audio models ではリアルタイム音声や文字起こし系モデル、Image and Video models では画像生成・動画生成系モデルの可用性が分けて掲載されています。(GitHub)
この分類は、設計時の確認ミスを減らすうえで重要です。たとえば「Japan EastでAzure AIを使えるか」と聞かれたとき、今後は単にリージョンを見るのではなく、「Chat用途なのか」「Embedding用途なのか」「Audio用途なのか」「Image/Video用途なのか」を分けて確認する必要があります。
これはAPI仕様変更ではなく、まずはドキュメント構成変更として見る
今回の更新で注意したいのは、ドキュメントの表が整理されたことと、Azure AIの実行時仕様が変更されたことを混同しない点です。
コミット内容から読み取れる主な変更は、Global Standard の可用性表を機能別の include ファイルへ置き換えたことです。したがって、既存のAPI呼び出し、デプロイ済みリソース、アプリケーションコードがこのコミットだけで直ちに壊れると判断するのは早計です。
ただし、運用面では影響があります。公式ドキュメントをもとに社内のモデル選定表、アーキテクチャレビュー資料、IaCテンプレート、監査用チェックリストを作っている場合、参照元の表構造が変わることで、確認フローや自動取得スクリプトに修正が必要になることがあります。
Azure AI運用で確認すべき4つの軸
Azure AIでモデルを選ぶときは、モデル名だけで判断すると失敗します。Microsoft Learn の公式ページでも、Azure OpenAI は異なる機能・価格帯のモデルで構成され、モデル可用性はリージョンやクラウドによって異なると説明されています。(Microsoft Learn)
実務では、次の4つを必ずセットで確認します。
| 確認軸 | 確認する内容 | 見落とした場合のリスク |
|---|---|---|
| モデル能力 | Chat、Embedding、Audio、Image/Video のどれか | ユースケースに合わないモデルを選ぶ |
| リージョン | Japan East、East US 2、Sweden Central など | 本番環境でデプロイできない |
| デプロイ種類 | Global Standard、Data Zone Standard、Standard、Provisioned など | データ所在地、SLA、性能、コストの前提が崩れる |
| モデルバージョン | モデル名に加えて日付・バージョンを確認 | テスト済みの挙動と本番の挙動がずれる |
特にGlobal Standardは、任意のAzureリージョンで処理される可能性があるデプロイ種類です。データ所在地の要件がある場合は、Data Zone型やStandard型との違いを確認する必要があります。公式ドキュメントでは、Global型は任意のAzureリージョン、DataZone型は指定されたデータゾーン内、Standard/Regional型はデプロイリージョンで処理されると整理されています。(Microsoft Learn)
Global Standardを使うときの判断基準
Global Standard は、多くのAzure AI活用プロジェクトで候補に入りやすいデプロイ種類です。公式ドキュメントでは、Global Standard は GlobalStandard というSKUコードで示され、汎用的なワークロードや最大クォータ制限に適した選択肢として整理されています。(Microsoft Learn)
ただし、「Global Standardで利用できる」ことは、「すべての要件に最適」という意味ではありません。以下のように判断すると、設計レビューでの手戻りを減らせます。
| 要件 | Global Standardが向いているケース | 別の選択肢を検討すべきケース |
|---|---|---|
| データ所在地 | データ処理場所に厳格な制約がない | 単一リージョン、EU/米国データゾーンなどの制約がある |
| トラフィック | 可変・バースト型の利用 | 常時高負荷で低遅延のばらつきを抑えたい |
| コスト | 従量課金で始めたい | 予測可能な大規模利用でPTUを検討したい |
| モデル選択 | 新しいモデルや幅広いモデルを試したい | 特定リージョン固定が最優先 |
公式ドキュメントでは、Global Standard はAzureのグローバルインフラストラクチャを使って利用可能なデータセンターへ動的にルーティングし、最も高い初期スループット上限や幅広いモデル可用性を持つ一方、大量ワークロードでは待機時間の変動が大きくなる可能性があると説明されています。(Microsoft Learn)
開発者が確認すべきポイント
開発者が今回のAzure AI公式ドキュメント更新で最初に見るべきなのは、アプリケーションが使う機能カテゴリとモデルバージョンです。
たとえば、RAGアプリケーションならChat modelsだけでなくEmbedding modelsを確認する必要があります。音声入力を扱うアプリならAudio modelsを確認します。画像生成や動画生成を含むアプリならImage and Video modelsを見る必要があります。
コード側で確認する項目
| 項目 | 確認内容 |
|---|---|
| デプロイ名 | コード内の deployment や環境変数が実際のAzure AIデプロイ名と一致しているか |
| モデルバージョン | テスト済みモデルと本番モデルのバージョンが一致しているか |
| リージョン | 本番リージョンで対象モデル・機能が利用可能か |
| API種別 | Chat Completions、Responses、Embeddings、Audioなど用途に合うAPIか |
| フォールバック | 対象リージョンで利用できない場合の代替モデル・代替リージョンがあるか |
失敗しやすいのは、「チャットモデルが使えるリージョンだから、EmbeddingやAudioも当然使える」と考えてしまうことです。今回のように機能別テーブルで整理されると、この誤解は見つけやすくなります。
クラウド管理者が確認すべきポイント
クラウド管理者は、モデル可用性だけでなく、クォータ、データ所在地、コスト、監査対応を確認する必要があります。
Azure AI FoundryやAzure OpenAI関連の運用では、利用者が「公式表で✅が付いているから使える」と判断しても、サブスクリプション側のクォータ、権限、リージョン制限、組織ポリシーによって実際にはデプロイできないことがあります。
管理者向けチェックリスト
| 確認項目 | 実施内容 |
|---|---|
| サブスクリプション | 対象モデルをデプロイできる権限・クォータがあるか確認する |
| リージョンポリシー | 社内で許可しているAzureリージョンと公式可用性を照合する |
| データ所在地 | Global、DataZone、Standardの違いを設計書に明記する |
| コスト管理 | モデル、デプロイ種類、利用量に応じた課金見積もりを更新する |
| 監査証跡 | モデル選定理由と参照した公式ドキュメントの日付を残す |
SLAや性能要件も重要です。公式ドキュメントでは、プロビジョニングされた種類ではスループットが保証され待機時間の差異が小さくなる一方、標準の種類ではベストエフォートサービスが提供されると説明されています。(Microsoft Learn)
ソリューションアーキテクトが確認すべきポイント
ソリューションアーキテクトは、今回の更新を「モデル選定表が見やすくなった」だけで終わらせず、アーキテクチャ上の判断軸を機能カテゴリ単位に再整理する機会として扱うべきです。
たとえば、生成AIアプリケーションは1つのモデルだけで構成されるとは限りません。実際には、以下のような組み合わせになります。
| ユースケース | 必要になりやすい機能 | 確認すべき表 |
|---|---|---|
| 社内ナレッジ検索RAG | Chat + Embedding | Chat models、Embedding models |
| コンタクトセンター支援 | Chat + Audio | Chat models、Audio models |
| マーケティング素材生成 | Chat + Image | Chat models、Image and Video models |
| マルチモーダル業務支援 | Chat + Audio + Image | 複数カテゴリを横断して確認 |
このとき、各機能が同じリージョン・同じデプロイ種類で揃うとは限りません。可用性が分かれている場合、アーキテクチャ上は次の判断が必要です。
- すべての機能を同一リージョンに寄せるのか
- 一部機能だけ別リージョンに分けるのか
- Global Standardを使うのか、Data ZoneやStandardを優先するのか
- 利用できない機能は代替モデルや外部サービスで補うのか
- 将来のモデル追加・廃止に備えて抽象化レイヤーを設けるのか
特にエンタープライズ環境では、モデル選定は技術的な性能だけでなく、データ所在地、監査、コスト、社内承認プロセスと密接に関わります。
日本リージョン利用者が特に見るべき点
日本語圏の読者にとっては、Japan Eastなど日本リージョンでの可用性が重要です。ただし、Japan Eastで一部のChatモデルが使えるからといって、AudioやImage/Videoのモデルも同じように使えるとは限りません。
2026年4月28日のコミット上では、japaneast はChat modelsの表に含まれ、多くのChat系モデルに✅が付いています。また、Embedding modelsでは japaneast に対して text-embedding-ada-002、text-embedding-3-large、text-embedding-3-small が✅となっています。一方で、Audio modelsの japaneast 行は掲載モデルに対して - が並び、Image and Video modelsでも japaneast 行は - が並ぶ形になっています。(GitHub)
これは、「日本リージョンでAzure AIを使う」設計でも、用途によって現実的な選択肢が変わることを意味します。RAGならJapan Eastで検討しやすい一方、音声や画像・動画生成を本番機能に含める場合は、別リージョンや別デプロイ種類、データ所在地要件との整合性を早めに確認する必要があります。
公式表を見るときの実務手順
Azure AIのモデル可用性を確認するときは、次の順番で見ると判断がぶれにくくなります。
| 手順 | 作業 | 判断ポイント |
|---|---|---|
| 1 | ユースケースを機能に分解する | Chat、Embedding、Audio、Image/Videoのどれが必要か |
| 2 | 対象デプロイ種類を決める | Global Standardでよいか、DataZoneやStandardが必要か |
| 3 | 候補リージョンを絞る | 社内ポリシー、データ所在地、利用者所在地を確認 |
| 4 | モデル名とバージョンを確認する | 同名モデルでもバージョン違いがないか |
| 5 | クォータと権限を確認する | Azure PortalやFoundry側で実際にデプロイ可能か |
| 6 | 代替案を用意する | 未対応・クォータ不足・廃止予定に備える |
この流れをチームの標準手順にしておくと、「開発時は動いたが本番リージョンではデプロイできない」「モデルはあるがEmbeddingが使えない」「音声機能だけ別リージョンが必要だった」といった手戻りを減らせます。
社内資料やIaCで注意すべき点
今回の更新で見落とされやすいのが、公式ドキュメントの表を機械的に参照している仕組みです。
たとえば、次のような運用をしている場合は確認が必要です。
- GitHub上のMarkdown表をスクレイピングして社内モデル一覧を作っている
- 公式表の列順を前提にCSV化している
- モデル名とリージョンの対応表を手作業でコピーしている
- IaCテンプレートに許可モデル一覧を固定値で入れている
- アーキテクチャレビュー用のExcelに旧表を貼り付けている
表が機能別に分かれると、列順やテーブル数が変わります。スクレイピング前提の仕組みは壊れる可能性があります。できれば、公式表の見た目に依存するのではなく、社内では次のような構造で管理するのが安全です。
model_name
model_version
capability
deployment_type
region
availability
last_checked_date
source_url_or_commit
owner
notes特に capability と last_checked_date を入れておくと、今回のようなドキュメント更新に追従しやすくなります。
移行準備でやるべきこと
今回の更新は、移行準備の観点でも良い棚卸しタイミングです。モデル可用性表が機能別になったことで、既存環境がどのモデル能力に依存しているかを洗い出しやすくなりました。
既存環境の棚卸し
まず、現在使っているAzure AI関連リソースを一覧化します。
| 棚卸し項目 | 記録例 |
|---|---|
| アプリ名 | 社内FAQ Bot、議事録要約、音声問い合わせ対応 |
| 使用モデル | gpt-4o、gpt-4.1-mini、text-embedding-3-large など |
| 機能カテゴリ | Chat、Embedding、Audioなど |
| リージョン | Japan East、East US 2 など |
| デプロイ種類 | Global Standard、Standard など |
| 本番/検証 | Production、Staging、PoC |
| 依存API | Chat Completions、Responses、Embeddings、Audio |
移行・変更前の検証
モデルやリージョンを変更する場合は、単にデプロイできるかだけでなく、以下を確認します。
- 既存プロンプトで出力品質が変わらないか
- JSON出力やStructured outputsの挙動が要件を満たすか
- RAGの検索品質がEmbeddingモデル変更で変わらないか
- レイテンシがSLAやUX要件を満たすか
- トークン上限や最大出力長が業務要件に足りるか
- コストが想定内に収まるか
- 監査・ログ・データ所在地の説明ができるか
Embeddingモデルを変える場合は特に注意が必要です。公式ドキュメントでは、text-embedding-3-large は最新かつ高性能なEmbeddingモデルである一方、Embeddingモデル間ではアップグレードできず、text-embedding-ada-002 から移行するには新しいEmbeddingの生成が必要だと説明されています。(Microsoft Learn)
よくある誤解と注意点
✅が付いていれば本番利用に適しているとは限らない
可用性表の✅は、そのリージョンとデプロイ種類で利用可能であることを示す目安です。性能、SLA、プレビュー扱い、データ所在地、社内ポリシーまで保証するものではありません。
特にプレビュー表記のあるモデルは慎重に扱う必要があります。公式ドキュメントでは、プレビューモデルを本番環境で使うことは推奨されず、プレビュー指定のモデルは標準的なAzure OpenAIモデルライフサイクルに従わないと説明されています。(Microsoft Learn)
Global Standardは選択リージョンだけで処理されるわけではない
Global Standardは、デプロイ時にリージョンを選ぶため「そのリージョン内だけで処理される」と誤解されがちです。しかし、公式ドキュメントではGlobal型は任意のAzureリージョンで処理される可能性があると整理されています。データ所在地の要件が厳しい業務では、この点を設計書と利用規約レビューに明記する必要があります。(Microsoft Learn)
ドキュメント更新とモデル廃止を混同しない
今回のコミットは、可用性表を機能別に整理する更新です。モデル廃止そのものを告知する更新ではありません。モデル廃止については、公式ページでも最新情報はモデルリタイアメントガイドを参照するよう案内されています。(Microsoft Learn)
ただし、モデル可用性とモデル廃止は運用上セットで確認すべきです。新しいモデルに移行する場合は、利用可能リージョンだけでなく、旧モデルの廃止予定、移行先モデル、検証期間を確認しましょう。
実務で使える確認テンプレート
Azure AIのモデル可用性をレビューするときは、以下のテンプレートをそのまま使うと便利です。
確認日：
参照した公式ドキュメント：
対象サービス：Azure AI / Azure OpenAI in Microsoft Foundry Models
対象アプリ：
対象機能：Chat / Embedding / Audio / Image and Video
利用予定モデル：
モデルバージョン：
デプロイ種類：Global Standard / Data Zone Standard / Standard / Provisioned
利用予定リージョン：
データ所在地要件：
クォータ確認：
本番利用可否：
代替モデル：
代替リージョン：
検証担当：
承認者：
備考：このテンプレートでは、「モデル名」だけでなく「対象機能」「デプロイ種類」「リージョン」「確認日」を分けて記録するのがポイントです。Azure AIのモデル可用性は時期によって変わるため、確認日を残しておくと監査や障害対応で説明しやすくなります。
今回の更新を受けて次に取るべき行動
今回のAzure AI公式ドキュメント更新は、表面的にはドキュメントの整理ですが、実務ではモデル選定・リージョン設計・社内運用ルールを見直すきっかけになります。
まずは、自社で利用しているAzure AIアプリケーションをChat、Embedding、Audio、Image/Videoに分解してください。そのうえで、各機能について、利用モデル、モデルバージョン、リージョン、デプロイ種類、クォータ、データ所在地要件を確認します。
特に日本リージョンを前提にしている場合は、「Chatは使えるがAudioやImage/Videoは同じ前提で使えない」といった差が出る可能性があります。PoC段階では動いても、本番設計ではデータ所在地、レイテンシ、コスト、社内承認が問題になることがあります。
Azure AIを安定して運用するには、公式ドキュメントの可用性表を「モデル一覧」として見るのではなく、ユースケース別の設計判断表として扱うことが重要です。今回の「group model availability tables by model capabilities」は、その確認方法を機能別に整理し直すための更新と捉え、社内資料・IaC・移行計画を早めに見直しましょう。
コメント