Azure AI Foundry でモデルを選ぶときの重要ポイントは、「使えるモデルが増えた」ことだけではありません。管理者が最初に確認すべきなのは、モデルの提供区分、デプロイ方式、データ処理場所、課金、サポート、廃止予定です。
Microsoft Foundry Models は、OpenAI、Meta、DeepSeek、Hugging Face などを含む 1,900 以上の AI モデルを探し、評価し、デプロイするためのモデルカタログです。公式ドキュメントでは、モデルが大きく「Foundry Models sold by Azure」と「Models from partners and community」に整理され、企業利用ではこの違いがセキュリティ、SLA、契約、運用設計に直結します。(Microsoft Learn)
Azure AI Foundry の「Microsoft Foundry Models overview」で押さえるべき結論
Azure AI Foundry を利用している組織は、Microsoft Foundry Models overview を単なるモデル一覧として読むのではなく、AI モデル利用のガバナンス基準として確認する必要があります。
特に影響が大きいのは、次の4点です。
| 確認項目 | 管理者が見るべきポイント |
|---|---|
| モデルの提供区分 | Microsoft が販売・サポートするモデルか、外部パートナーやコミュニティ提供のモデルか |
| デプロイ方式 | Managed compute か Serverless deployment か |
| データ処理場所 | Global、Data Zone、Regional のどれに該当するか |
| ライフサイクル | 廃止予定、代替モデル、バージョン固定の要否 |
これまで Azure OpenAI Service を中心に使っていた企業でも、Azure AI Foundry ではモデル選択の幅が広がる一方、モデルごとに利用条件やデータ処理、可用性、コンテンツ安全対策が異なります。開発チームが自由にモデルを選べる状態にする前に、管理者側で「利用してよいモデル」「本番利用してよいデプロイ方式」「データを処理してよい地域」を明確にしておくことが重要です。
Microsoft Foundry Models overview とは何か
Microsoft Foundry Models overview は、Microsoft Foundry で利用できる AI モデルの全体像を説明する公式ドキュメントです。Foundry Models では、カスタム Copilot、AI エージェント、既存アプリの AI 強化、新しい生成 AI 機能の検証などを目的に、モデルの探索、比較、評価、デプロイを行えます。(Microsoft Learn)
Microsoft Foundry 自体は、エンタープライズ AI 運用、モデル開発、アプリケーション開発を統合する Azure の PaaS 型プラットフォームとして説明されています。従来の Azure AI Studio / Azure AI Foundry は、現在の名称では Microsoft Foundry に整理されており、エージェント、モデル、ツール、RBAC、ネットワーク、ポリシーなどを一元管理する方向に進んでいます。(Microsoft Learn)
つまり、Azure AI Foundry を利用している企業にとって、Microsoft Foundry Models overview は「どのモデルがあるか」を見るページではなく、AI モデルの採用・統制・運用ルールを決める入口です。
今回の更新ポイントを実務目線で整理
今回確認すべき中心は、モデルカタログがエンタープライズ利用を前提に、提供区分・デプロイ方式・データ処理・安全対策・ライフサイクルの観点で整理されている点です。
1,900以上のモデルを選べるが、選定基準がより重要になった
Microsoft Foundry では、基盤モデル、推論モデル、小規模言語モデル、マルチモーダルモデル、業界特化モデルなど、1,900 以上のモデルが提供されています。モデル提供元には Microsoft、OpenAI、DeepSeek、Hugging Face、Meta などが含まれます。(Microsoft Learn)
モデル数が多いことは利点ですが、実務では「性能が高そうだから使う」という選び方は危険です。たとえば、社内ナレッジ検索用の RAG、顧客向けチャット、コード生成、画像理解、医療・金融などの専門領域では、必要な要件が異なります。
| 利用シーン | 優先すべき判断基準 |
|---|---|
| 社内 PoC | すぐ試せること、コスト、API の扱いやすさ |
| 本番の顧客向けチャット | SLA、監視、コンテンツ安全性、リージョン |
| 機密データを扱う RAG | データ処理場所、ネットワーク分離、アクセス制御 |
| 大量バッチ処理 | Batch 系デプロイ、コスト、処理完了時間 |
| 高スループット API | Provisioned 系デプロイ、PTU、レイテンシ安定性 |
| 特定業界向け AI | モデルカード、ライセンス、責任ある AI の制約 |
管理者は、モデルカタログを「自由に選ぶ場所」ではなく、「承認済みモデルを選ぶ場所」として運用するのが現実的です。
モデルは2つの大分類で整理される
Microsoft Foundry Models overview では、モデルカタログが次の2種類に整理されています。
| 分類 | 概要 | 向いている用途 |
|---|---|---|
| Foundry Models sold by Azure | Microsoft がホスト・販売し、Microsoft Product Terms のもとで提供されるモデル | エンタープライズ本番利用、Microsoft サポートや SLA を重視する用途 |
| Models from partners and community | 外部パートナー、研究機関、コミュニティなどが提供するモデル | 専門性の高い用途、新しいモデルの検証、特定プロバイダーの機能活用 |
Foundry Models sold by Azure は、Azure Direct models / Direct from Azure models とも呼ばれ、Microsoft によるサポート、Azure サービスとの統合、Microsoft の Responsible AI 基準に基づくレビュー、エンタープライズ向けのスケーラビリティやセキュリティが特徴です。(Microsoft Learn)
一方、Models from partners and community は、Anthropic や Hugging Face などを含む外部提供モデルが中心です。多様で先進的なモデルを利用しやすい反面、サポート、契約条件、データ処理、ライセンスはモデル提供元ごとに確認が必要です。(Microsoft Learn)
影響範囲：誰が何を確認すべきか
今回の内容は、開発者だけでなく、Azure 管理者、セキュリティ担当、法務・コンプライアンス担当、コスト管理担当にも影響します。
| 役割 | 影響するポイント | 取るべき対応 |
|---|---|---|
| Azure 管理者 | モデルのデプロイ方式、リージョン、ネットワーク設定 | 利用可能なモデルとデプロイ方式を棚卸しする |
| セキュリティ担当 | コンテンツ安全性、ネットワーク分離、データ処理 | Content Safety、Private Endpoint、PNA 設定を確認する |
| 開発者 | API、SDK、モデル選択、バージョン差分 | モデルごとの対応 API と制限を確認する |
| データ管理者 | プロンプト、出力、学習データ、RAG データ | データ分類と処理場所をモデル選定条件に入れる |
| コスト管理担当 | Token 課金、VM 時間課金、Marketplace 課金、PTU | デプロイ方式ごとの課金構造を比較する |
| 法務・購買担当 | Product Terms、Marketplace、外部提供モデルの条件 | モデルカード、ライセンス、提供元の規約を確認する |
特にグローバル企業では、データ処理場所が問題になりやすくなります。Global 系デプロイは柔軟性やスループット面で有利ですが、推論データがどこで処理されるかを確認しないまま採用すると、社内規程や地域別コンプライアンスに抵触する可能性があります。
デプロイ方式の違い：Managed compute と Serverless deployment
Microsoft Foundry Models overview では、モデルの主なデプロイ方式として Managed compute と Serverless deployment が説明されています。(Microsoft Learn)
| 項目 | Managed compute | Serverless deployment |
|---|---|---|
| 基本イメージ | 専用 VM のマネージドコンピュートにモデルをデプロイ | Microsoft 管理の API としてモデルを利用 |
| 課金 | VM コア時間など、コンピュート利用に基づく | 入出力トークンなど API 利用に基づくことが多い |
| 向いている用途 | モデルや環境をより細かく制御したい用途 | すばやい導入、API 利用、運用負荷の軽減 |
| 認証 | キー、Microsoft Entra 認証 | キー、Microsoft Entra 認証 |
| コンテンツ安全対策 | Azure AI Content Safety を組み合わせる | 一部の言語モデルでは Content Safety フィルターが統合される |
| 注意点 | VM クォータ、ネットワーク、運用設計が必要 | モデル・提供元・デプロイ種別ごとの条件確認が必要 |
実務では、PoC や初期検証では Serverless deployment、本番の高負荷・低遅延・固定容量が必要な用途では Provisioned 系、モデル重みや実行環境の制御が必要なケースでは Managed compute を検討する流れが自然です。
ただし、Managed compute を使う一部モデル、たとえば Hugging Face モデルなどは、Foundry portal の hub-based project、つまり Foundry portal classic を利用する必要がある点に注意が必要です。(Microsoft Learn)
Serverless deployment の種類と選び方
Serverless deployment では、標準の従量課金型と、予約容量を使う Provisioned 型があり、さらに Global、Data Zone、Regional といったデータ処理場所の違いがあります。デプロイ種別は、データ処理場所、課金方式、レイテンシ、スループット上限に影響します。(Microsoft Learn)
| デプロイ種別 | 向いているケース | 注意点 |
|---|---|---|
| Global Standard | 汎用的な本番・検証、広いモデル可用性を重視 | 推論データが任意の Azure リージョンで処理される可能性 |
| Global Provisioned | 高スループット、安定した処理性能が必要 | 予約容量の設計が必要 |
| Data Zone Standard | EU / US データゾーン内で処理したい | 対象ゾーンとモデル対応を確認 |
| Data Zone Provisioned | データゾーン要件と安定スループットの両方が必要 | 利用可能リージョンと容量確認が必要 |
| Standard / Regional | 単一リージョンで処理したい | モデル可用性やクォータが限られる場合がある |
| Batch 系 | 大量非同期処理を低コストで行いたい | リアルタイム応答には向かない |
| Developer | Fine-tuned model の評価用途 | SLA や本番利用には不向き |
Global、Data Zone、Regional の違いは、単なるリージョン選択ではありません。公式ドキュメントでは、保存データは指定された Azure geography に保持される一方、推論データの処理場所はデプロイ種別により異なり、Global は任意の Azure リージョン、Data Zone は Microsoft 指定の US または EU データゾーン、Standard / Regional はデプロイリージョンで処理されると説明されています。(Microsoft Learn)
グローバル向けサービスを運用する場合は、「ユーザーが日本にいるか」だけでなく、「入力データに個人情報や機密情報が含まれるか」「社内規程で越境処理が許可されているか」「障害時にどの程度のレイテンシ変動を許容できるか」をセットで判断してください。
設定変更が必要になる可能性があるポイント
今回の内容を受けて、すべての環境で直ちに設定変更が必要になるわけではありません。ただし、次の条件に当てはまる場合は、設定や運用ルールの見直しが必要です。
| 条件 | 見直すべき設定・運用 |
|---|---|
| 開発者が自由にモデルをデプロイできる | Azure Policy、RBAC、承認フローを整備 |
| Global Standard を使っている | データ処理場所の社内許容範囲を確認 |
| Preview モデルを本番利用している | GA モデルまたはバージョン固定への移行を検討 |
| Serverless endpoint を公開している | Public network access、Private Endpoint、認証方式を確認 |
| モデルごとに安全基準が異なる | Content Safety、Guardrails、RAI ポリシーを標準化 |
| Anthropic や Hugging Face など外部モデルを使う | Marketplace、提供元の規約、データ処理条件を確認 |
特に注意したいのが、Serverless deployment のネットワーク分離です。公式ドキュメントでは、Serverless deployment のエンドポイントは、デプロイが存在するプロジェクトを含む Foundry hub の public network access フラグ設定に従うと説明されています。Private Endpoint を使って inbound 通信を保護するには、hub 側のネットワーク設定確認が必要です。(Microsoft Learn)
また、2024年7月11日より前に作成された Private Endpoint や Serverless deployment には制限があり、既存の Serverless deployment が新しいネットワーク構成に自動追従しないケースがあります。その場合、新しい Private Endpoint や Serverless deployment の再作成が必要になる可能性があります。(Microsoft Learn)
コンテンツ安全性と Responsible AI の確認ポイント
Foundry Models では、モデルを使う顧客側にも責任があります。公式ドキュメントでは、顧客は法令遵守、モデル説明やモデルカードの確認、用途に合ったモデル選定、Azure AI Content Safety などを含む適切な対策の実装に責任を持つとされています。(Microsoft Learn)
Serverless API でデプロイされる言語モデルでは、Azure AI Content Safety のテキストモデレーションフィルターが既定構成で利用できる場合があります。ただし、embedding モデルや時系列モデルなど、一部のモデル種別ではコンテンツフィルターが利用できない点に注意が必要です。(Microsoft Learn)
実務では、次のようなルールを作ると運用しやすくなります。
| 項目 | 推奨する運用ルール |
|---|---|
| 社内検証 | 低リスクデータのみ利用し、出力を人が確認 |
| 顧客向けチャット | Content Safety を有効化し、禁止トピックとエスカレーション条件を定義 |
| コード生成 | 秘密情報、認証情報、ライセンス違反コードの混入を検査 |
| RAG | 参照データのアクセス権と引用元を確認 |
| 業界特化用途 | モデルカード、透明性情報、利用制限をレビュー |
| 外部提供モデル | 提供元の利用規約、サポート、データ処理条件を承認制にする |
「AI に聞ける状態」を作るだけでは不十分です。誰が、どのデータを、どのモデルに、どの地域で処理させてよいかを決めることが、Azure AI Foundry 管理者の重要な役割になります。
外部パートナー提供モデルを使うときの注意点
Models from partners and community は、専門モデルや最新モデルを素早く使える点が魅力です。一方で、Azure Direct models と同じ感覚で扱うと、契約や責任分界点を見誤る可能性があります。
たとえば Claude models in Microsoft Foundry では、Claude モデルには Hosted on Azure と Hosted on Anthropic infrastructure の2種類があり、後者は Azure 外の Anthropic インフラ上で動作します。また、Claude モデルは Foundry Models from partners and community 経由で利用し、Azure Marketplace サブスクリプションが必要です。(Microsoft Learn)
この違いは、グローバル企業にとって重要です。単に「Microsoft Foundry から使える」ことと、「Microsoft が販売・ホスト・サポートする Azure Direct model である」ことは同じではありません。
外部モデルを本番利用する前に、最低限次の点を確認してください。
| 確認項目 | 見るべき内容 |
|---|---|
| 提供元 | Microsoft、Anthropic、Hugging Face など、誰が提供・運用するか |
| ホスティング | Azure 上で完結するか、外部インフラを使うか |
| 契約 | Microsoft Product Terms か、Marketplace / 提供元の条件か |
| データ処理 | プロンプト、出力、ログ、キャッシュの扱い |
| 課金 | Azure メーターか、Marketplace 課金か |
| サポート | Microsoft サポートか、提供元サポートか |
| 安全対策 | 既定フィルターの有無、追加実装の必要性 |
Instant access は便利だが、本番導入前に制限を確認する
Microsoft Foundry では、対応モデルを名前で呼び出し、デプロイなしで推論を開始できる Instant access が preview として提供されています。公式ドキュメントでは、Instant access により、デプロイ作成なしで対応モデルを呼び出せる一方、preview 期間中は West US 3 のプロジェクトのみ対応とされています。(Microsoft Learn)
Instant access は、PoC やモデル比較では非常に便利です。モデル名を変えるだけで試せるため、開発初期の速度は上がります。
ただし、本番利用では次の制約に注意してください。
| 目的 | Instant access | 通常の Deployment |
|---|---|---|
| すぐ試す | 向いている | やや手間がかかる |
| 最新モデルを素早く検証 | 向いている | デプロイ作成が必要 |
| 予約容量・安定スループット | 向かない | 向いている |
| 特定リージョンのデータ所在地要件 | 向かない場合がある | 選択肢が多い |
| モデルごとのカスタム Content filter | 制限あり | 向いている |
| Fine-tuned model | 非対応 | 対応 |
公式ドキュメントでも、Instant access ではカスタム Guardrails やモデル単位の Responsible AI ポリシーを設定できず、モデルごとに異なるコンテンツフィルタリングが必要な場合は Deployment を使うべきと説明されています。(Microsoft Learn)
移行期限・廃止予定で確認すべきこと
Microsoft Foundry Models overview 自体は、全モデル共通の一律移行期限を示すものではありません。移行期限は、モデルごとのライフサイクルと retirement schedule で確認します。
公式の Model retirement schedule では、Foundry Models の現在のライフサイクル段階、廃止日、推奨代替モデルが一覧化されています。たとえば、gpt-5-chat の一部バージョン、gpt-5.1-chat、gpt-5.2-chat の一部バージョン、gpt-5.3-chat などには、2026年6月29日付の retired が掲載され、代替として gpt-chat-latest が示されているものがあります。(Microsoft Learn)
管理者は、次の手順で移行リスクを確認してください。
| 手順 | 確認内容 |
|---|---|
| 1 | 既存の Azure AI Foundry / Azure OpenAI のデプロイ一覧を取得 |
| 2 | モデル名、モデルバージョン、デプロイ種別、リージョンを棚卸し |
| 3 | Model retirement schedule で廃止日と代替モデルを確認 |
| 4 | Preview モデルを本番利用していないか確認 |
| 5 | 代替モデルで API パラメーター、出力品質、トークン長、コストを検証 |
| 6 | 本番切替前に評価データセットで回帰テスト |
| 7 | モデル名・バージョン固定・IaC 定義・監視設定を更新 |
特に reasoning 系モデルや chat 系モデルでは、同じような名前でもサポートされるパラメーターが変わることがあります。たとえば温度パラメーター、tool calling、structured outputs、最大コンテキスト、出力トークン数が変わると、既存アプリの挙動やコストに影響します。
管理者が今すぐ確認すべきチェックリスト
Azure AI Foundry 管理者は、次のチェックリストを使って既存環境を確認すると、影響範囲を整理しやすくなります。
| チェック項目 | 確認できたら実施すること |
|---|---|
| 利用中モデルの一覧があるか | モデル名、バージョン、提供区分、デプロイ方式を台帳化 |
| Azure Direct model と外部提供モデルを区別しているか | 外部提供モデルは契約・データ処理・サポートを別途確認 |
| Preview モデルを本番利用していないか | GA モデルへの移行またはリスク承認を取得 |
| Retirement schedule を確認しているか | 廃止予定モデルは代替モデルで検証を開始 |
| Global / Data Zone / Regional を使い分けているか | データ所在地要件とリージョン戦略を明文化 |
| Serverless endpoint のネットワーク設定を確認したか | PNA、Private Endpoint、既存 deployment の再作成要否を確認 |
| Content Safety を標準化しているか | モデル種別ごとのフィルター可否を確認 |
| クォータと課金を把握しているか | Token、PTU、VM 時間、Marketplace 課金を分けて管理 |
| RBAC を最小権限にしているか | モデルデプロイ権限を開発者全員に渡さない |
| IaC 管理しているか | モデル、SKU、リージョン、ポリシーをコード化 |
このチェックリストで特に優先度が高いのは、モデル台帳の作成です。どの部署が、どのモデルを、どのデータで、どの地域にデプロイしているかが分からない状態では、廃止対応もコスト最適化もセキュリティレビューも後手に回ります。
失敗しやすいポイント
Azure AI Foundry のモデル活用でよくある失敗は、技術的な設定ミスよりも、運用設計の不足です。
モデル名だけで選んでしまう
「GPT 系だから安全」「Claude だから高性能」「Meta のモデルだから安い」といった判断は危険です。実際には、同じファミリーでもバージョン、提供区分、デプロイ方式、対応リージョン、プレビュー状態が異なります。
モデル選定時は、最低でも次の情報をセットで確認してください。
- モデル ID
- バージョン
- GA / Preview / Deprecated / Retired
- 対応 API
- 最大コンテキスト長
- 出力トークン上限
- デプロイ方式
- データ処理場所
- 課金方式
- モデルカードとライセンス
PoC の設定をそのまま本番化する
PoC では Instant access や Global Standard が便利ですが、そのまま本番に移すと、データ所在地、カスタムフィルター、スループット保証、監視、予算管理が不足することがあります。
PoC から本番に進める段階では、次の3点を必ず再評価してください。
| 観点 | 本番化前の確認 |
|---|---|
| 安全性 | Content Safety、禁止用途、監査ログ |
| 可用性 | SLA、Provisioned、障害時の切替 |
| 統制 | RBAC、Azure Policy、モデル承認フロー |
外部提供モデルの責任分界点を見落とす
Foundry Models from partners and community は強力ですが、すべてが Microsoft と同じ条件で提供されるわけではありません。契約、課金、サポート、データ処理、Content Safety の実装責任を必ず確認してください。
特に顧客データ、個人情報、医療・金融・公共領域のデータを扱う場合は、外部提供モデルの利用を個別承認制にするのが安全です。
グローバル運用での実用的な判断基準
グローバル企業や複数地域にサービスを展開する組織では、モデル選定を次のように分けると判断しやすくなります。
| 要件 | 推奨方針 |
|---|---|
| まず試したい | Instant access または Standard 系で PoC |
| 世界中のユーザーに広く提供したい | Global Standard を候補にしつつ、データ処理要件を確認 |
| EU または US のデータ境界を重視 | Data Zone 系を候補にする |
| 日本など特定リージョン処理が必要 | Regional / Standard 系の可用性を確認 |
| 大量アクセスでレイテンシを安定させたい | Provisioned 系を検討 |
| 大量の非同期処理を安く回したい | Batch 系を検討 |
| 機密性が高い業務 | Azure Direct model、Private Endpoint、Content Safety、監査ログを優先 |
実務上は、すべてのユースケースに同じモデルを使うよりも、「社内検証用」「低リスク業務用」「顧客向け本番用」「高機密データ用」のようにモデル利用レベルを分けると管理しやすくなります。
まず実施すべきアクション
Azure AI Foundry の「Microsoft Foundry Models overview」を確認した管理者は、まず次の順番で対応すると効果的です。
- 現在利用中のモデル、バージョン、デプロイ方式、リージョンを棚卸しする
- Azure Direct model と外部パートナー / コミュニティモデルを分類する
- Preview、Deprecated、Retired のモデルが本番に含まれていないか確認する
- Global / Data Zone / Regional のデータ処理方針を社内ルール化する
- Content Safety、ネットワーク分離、RBAC、Azure Policy の標準設定を決める
- 新規モデル採用時のレビュー項目をテンプレート化する
- 廃止予定モデルは代替モデルで評価し、切替計画を作る
Microsoft Foundry Models は、Azure AI Foundry のモデル活用を大きく広げる仕組みです。一方で、モデルの選択肢が増えるほど、管理者には「使わせないための統制」ではなく、「安全に使える選択肢を整備する統制」が求められます。
まずはモデル台帳を作り、提供区分、デプロイ方式、データ処理場所、廃止予定を見える化してください。そのうえで、業務ごとに利用可能なモデルと設定を定義すれば、Azure AI Foundry を PoC から本番運用へ移行しやすくなります。
コメント