Azure AI Foundryは、モデル・エージェント・ツールを1つのAzureリソースの下でまとめて扱うMicrosoftのAI開発基盤です。名称は2025年11月のIgnite以降「Microsoft Foundry」へ移り、「Azure AI Foundry」は同じ製品の旧ブランド名にあたります。実務でいちばん判断に困るのは「すでにAzure OpenAI Serviceを使っているのに、Foundryへ移る意味はあるのか」という点でしょう。この記事は、その差の正体(結論から言えばAzureリソースの種別そのもの)を起点に、自動アップグレード、モデルカタログの実体、料金の考え方までMicrosoft Learnで確認できる範囲に絞って整理します。現行名としての全体像・使い方・料金体系はMicrosoft Foundry(Azure AI Foundry)とは何か?エンタープライズ向け生成AI統合プラットフォームの概要にまとめているので、製品全体の把握が目的ならそちらから読んでください。
まとめ:Azure AI FoundryとAzure OpenAIの違いの要点
- 両者の違いは機能一覧の差である前にAzureリソースの種別の差です。
kindがOpenAIならAzure OpenAIリソース、AIServices(+allowProjectManagement: true)ならFoundryリソースになります。 - Microsoft Learnは、Foundryリソースを「Azure OpenAIリソースに対する機能の上位集合(superset)」と明記しています。エージェントサービス、Foundry API、Foundry Tools、パートナーモデルはFoundry側にしかありません。
- 自分で移行しなくても、Microsoftが対象リソースを自動でアップグレードします。止めたい場合は明示的な延期またはオプトアウトが必要です。
- アップグレードしてもリソース名・エンドポイント・APIキー・既存ジョブは保持され、既存機能の料金も変わりません。問題があればロールバックできます。
- モデルカタログにGeminiはありません。Google由来で使えるのはオープンウェイトのGemmaファミリーだけです。
- プラットフォーム自体の利用料は無料で、課金はモデル推論・エージェント・ツールといったサービス単位に発生します。
Azure OpenAIとAzure AI Foundryの違いを決めているリソース種別
日本語の解説では「Azure OpenAIは部品、Foundryは作業場」といった比喩で説明されがちですが、課金と権限に効くのはもっと即物的な部分です。Azureの管理面から見れば、両者は同じ Microsoft.CognitiveServices/accounts というリソースの、kind プロパティ違いにすぎません。だから「並べて比較して選ぶ」のではなく「既存リソースを変換する」のが正しい理解になります。
| 機能 | Azure OpenAIリソース | Foundryリソース |
|---|---|---|
| Azureが販売するモデル | Azure OpenAIのみ | Azure OpenAI/Black Forest Labs/DeepSeek /Meta/SpaceXAI(旧xAI) /Mistral/Microsoft |
| Marketplace経由のパートナー・コミュニティモデル | 不可 | 可 |
| バッチ/保存済み補完/ファインチューニング/評価 | 可 | 可 |
| エージェントサービス | 不可 | 可 |
| Foundry API(統合エンドポイント) | 不可 | 可 |
| Foundry Tools(音声・視覚・言語・Content Understanding) | 不可 | 可 |
出典はMicrosoft Learnの「Upgrade Azure OpenAI to Microsoft Foundry」(ms.date 2026年8月19日)です。なお同ページの表はベンダー名を旧称の「xAI」のまま載せていますが、モデル一覧側(同2026年8月26日)は改称後の「SpaceXAI」表記に切り替わっています。
新規に作るなら、上位集合であるFoundryリソース(kind: AIServices)から始めるのが既定です。あえてAzure OpenAIリソースを選ぶ理由が残るのは、Weights & Biases連携を使う場合と、RBACの適用範囲をOpenAI機能だけに絞りたい場合に限られます。
アップグレードで保持される設定と、変わらないコスト
移行のハードルは想像より低く設定されています。Learnは、リソース名・Azureリソースタグ・ネットワーク構成・アクセスおよびID構成・APIエンドポイントとAPIキー・カスタムドメイン名、そしてファインチューニングジョブやバッチなどの既存状態がそのまま維持されると列挙しています。既存アプリの接続先を書き換える必要はありません。料金についても「既存のAzure OpenAI機能に対して追加費用は発生しない(you don’t pay more for existing Azure OpenAI functionality)」と明示されています。つまり移行そのものは無償で、増えた機能を使ったときだけ課金が増える構造です。
すでに移行済みかどうかは、リソースのプロパティで判別できます。アップグレード済みのリソースにだけ読み取り専用の previousKind が現れます。
{
"properties": {
"previousKind": "OpenAI"
}
}
Microsoftによる自動アップグレードと、その止め方
ここが日本語記事でほとんど触れられていない、いま最も実務に効く変化です。Microsoft Learnは「Microsoftは対象となるAzure OpenAIリソースをMicrosoft Foundryリソースへ自動的にアップグレードします」と述べています。つまり移行は必ずしも自分で決めるものではありません。対象に選ばれたリソースはAzureポータルの「Resource upgrade」に通知が出るほか、APIバージョン 2026-01-15-preview でJSONビューを開くと次のブロックが現れます。
"foundryAutoUpgrade": {
"mode": "Enabled",
"plannedByMicrosoft": true,
"scheduledAt": "2026-04-15T00:00:00Z",
"statusReason": "<service-provided-status>"
}
予定日を動かすだけならポータルの「Defer upgrade」で延期し、恒久的に止めるなら既存のデプロイ定義で foundryAutoUpgrade.mode を Disabled に設定します。AzureRMプロバイダーはこのプレビュープロパティを公開していないため、Terraformで止めるならAzAPIプロバイダーの azapi_update_resource を使います。オプトアウトには Microsoft.CognitiveServices/accounts/write を含むロールが要ります。プライベートネットワークやCMKを使うリソースは初期の自動対象から外れていますが、除外が恒久的だとは書かれていません。セキュリティレビューが終わっていない組織ほど、先に状態を確認しておくべきです。なお foundryAutoUpgrade が無いことを「対象外の証明」として自動化に組み込まないよう、Learnは明確に釘を刺しています。
着手前に潰しておくべき前提と制約
前提として、サブスクリプションまたはリソースグループのOwnerロールと、対象リソースでのシステム割り当てマネージドIDの有効化が要ります。そのうえで、事前に確認しないと当日に止まる条件があります。まず機能とモデルの提供状況はリージョンで異なり、エージェントサービスはAzure OpenAIより限られたリージョンでしか使えません。CMKで暗号化したリソースは申請ベースでしか移行できず、Weights & Biases の構成はFoundry側でサポートされません。プライベートエンドポイントを持つリソースはポータル経由で移行できないため、削除して作り直すか、BicepまたはTerraformで管理します。プライベートネットワーク構成では、Foundryが openai.azure.com・services.ai.azure.com・cognitiveservices.azure.com の3つのFQDNで機能を公開するため、DNSゾーンも3つ揃えないと一部機能に到達できません。
もうひとつ見落とされやすいのが権限です。Learnの表によれば、Cognitive Services User ロールはアップグレード後にFoundryの全機能へ広がります(Cognitive Services OpenAI User はOpenAI機能のままです)。ワイルドカードでロールやポリシーを当てている組織は、移行前に定義を見直すべきです。非OpenAI機能を段階的に開放したいなら、モデルデプロイのポリシーを先に設定します。
テンプレートで移行する場合の変更点は3つだけです。
resource foundry 'Microsoft.CognitiveServices/accounts@2025-06-01' = {
name: foundryName
location: location
identity: { type: 'SystemAssigned' }
sku: { name: 'S0' }
kind: 'AIServices' // OpenAI から変更
properties: {
allowProjectManagement: true
customSubDomainName: foundryName
disableLocalAuth: true
}
}
TerraformのAzureRMプロバイダーを使う場合は、リソースを作り直さずに OpenAI と AIServices を行き来するためにバージョン4.56.0以降が必要です。
Azure AI Studioから2度の改称と、ポータル2系統の対応関係
検索語と製品名が一致しないのは、この製品が短期間に2度改称されたためです。Microsoft Learnの「Evolution of Foundry」表が公式の対応関係を示しています。
| 観点 | 以前 | 現在 |
|---|---|---|
| ブランド | Azure AI Studio/Azure AI Foundry | Microsoft Foundry |
| ブランド | Azure AI Services | Foundry Tools |
| ポータル | Foundry (classic) | Foundry |
| エージェントAPI | Assistants API | Responses API |
| APIバージョン | 毎月の api-version 指定 | v1安定ルート(/openai/v1/) |
| リソースモデル | ハブ+Azure OpenAI+Azure AI Services | Foundryリソース(単一・プロジェクト内包) |
| SDKとエンドポイント | 複数パッケージ (azure-ai-inference/azure-ai-generative /azure-ai-ml/AzureOpenAI())× 5つ以上のエンドポイント |
azure-ai-projects 2.x+OpenAI() ×単一のプロジェクトエンドポイント |
| 用語 | Threads/Messages/Runs/Assistants | Conversations/Items/Responses /Agent Versions |
実務上の注意は、ドキュメントが /azure/foundry/(新)と /azure/foundry-classic/(旧)の2系統に分かれている点です。Hugging Faceのモデルのようにマネージドコンピューティングへデプロイするものは、いまでもハブベースのプロジェクトが前提で、カタログから選ぶとclassicポータルが開きます。手順を検索するときは、どちらの系統を読んでいるか先に確かめてください。なお「Azure OpenAI」の名前自体は消えていません。製品ページの正式表記は「Azure OpenAI in Foundry Models」です。
Geminiが無いモデルカタログと、Google由来で使えるGemma
「azure ai foundry gemini」で検索して来た方には、先に結論をお伝えします。Foundryのモデルカタログに Gemini はありません。Azureが販売するモデルの一覧(ms.date 2026年8月26日)にも、パートナー・コミュニティモデルの一覧(同2026年9月1日)にも、GoogleおよびGeminiの記載は1件もありません。前者に章立てされているのはAzure OpenAI・Black Forest Labs・Cohere・DeepSeek・Meta・Microsoft・Mistral・Moonshot AI・SpaceXAI、後者はAnthropic・Cohere・Meta・Microsoft・Mistral AI・NTT Dataです。
Geminiそのものが要件なら、Google Cloud側のVertex AIかGemini APIを併用する構成になります。逆にAzureのRBAC・ネットワーク・監査の内側で完結させたいなら、同じ研究基盤から出たオープンウェイトのGemmaへ置き換えるのが現実的な代替です。
Gemma 4の仕様とライセンス
Gemma 4はGoogle DeepMindが2026年4月2日に公開したモデル群で、ライセンスはApache 2.0、FoundryへはHugging Faceコレクション経由で提供されています。テキスト・画像・動画のマルチモーダル入力に対応し、コンテキストウィンドウはE2B/E4Bが128Kトークン、26B A4B/31Bが256Kトークンです。140以上の言語で事前学習され、35以上の言語をそのまま扱えます。Gemini 3と同じ研究基盤から作られている、とMicrosoftのFoundryブログは説明しています。旧世代のGemma 3系(unsloth-gemma-3-12b-it など)も一般提供のままカタログに残っています。いずれもマネージドコンピューティングへのデプロイです。
カタログ2区分の分かれ目:Azureメーター課金とMarketplace課金
モデル選定で実際に手が止まるのは性能比較ではなく、調達の壁です。カタログは「Azureが販売するモデル」と「パートナー・コミュニティのモデル」の2区分に分かれており、この区分で課金経路と必要権限が変わります。前者はMicrosoftがサポートしエンタープライズSLAが付き、Azureメーターで課金されます。後者はモデル提供元がライセンス条件と価格を決め、Azure Marketplace経由で請求されるため、購読時に Microsoft.MarketplaceOrdering/* 系の権限が必要になります。Foundryリソースにしか無い代表例はAnthropicのClaudeで、Learnもパートナー区分の筆頭に挙げています。
問題は、Cloud Solution Provider契約や学生・無料クレジットのサブスクリプションではMarketplaceでの購入自体ができない点です。社内の調達ルールでMarketplace購入が止まっている組織では、パートナー区分のモデル(AnthropicのClaude、NTT Dataのtsuzumi など)が「カタログには見えるのにデプロイできない」状態になります。判定はベンダー単位でなくモデル単位で行ってください。Cohereのように両区分に同名の章を持つベンダーもあります。
Copilot StudioとFoundryの選び分け
同じ「AIエージェントを作る」でも、Copilot StudioとFoundryは想定する担当者が違います。Microsoftが2026年1月5日に公開した比較記事は、Copilot Studioを業務部門の担当者・IT管理者・プロメイカー向けのSaaS/ローコード環境、Foundryをプロ開発者向けのPaaS/プロコード環境と位置づけています。Copilot StudioのエージェントはMicrosoftのクラウドで動きインフラ管理が不要な代わりに、モデルの挙動やランタイムへ踏み込む余地が限られます。Foundryは自社のAzureサブスクリプション上で動くため、ネットワーク・データ所在地・CI/CD・可観測性を自分で設計できる反面、構築工数がかかります。
判断基準は単純です。カスタムコード、モデルの調整、オンプレミスのデータのいずれかが要件に入るならFoundry、入らないならCopilot Studioで始めるほうが早く着地します。両者は排他ではありません。開発者がFoundryで専用のツールやエージェントを作り、業務部門がCopilot Studioで利用者向けの体験を組む併用パターンが一般的だとMicrosoftは説明しています。
料金:プラットフォームは無料で、課金はサービス単位
Azureの価格ページのFAQは「The Foundry platform is free to use and explore」と述べており、ポータルやプロジェクトを持つこと自体に費用はかかりません。課金はFoundry Models、Foundry Agent Service、Foundry IQ、Foundry Tools、Foundry Control Planeとサービスごとに別体系で発生します。
モデル推論の課金は、デプロイ方式で性質が変わります。サーバーレスデプロイは入出力トークンへの従量課金で、Global Standard・Data Zone Standard・Global Batch・Regional Provisioned などから選びます。一方のマネージドコンピューティングはモデルの重みを専用の仮想マシンに載せる方式なので、推論していない時間も含めた仮想マシンのコア時間で課金されます。Hugging Faceのオープンモデルを常時待機させる構成では、ここが想定外のコストになりやすい部分です。コンテンツフィルターにあたるAzure AI Content Safetyも別課金です。
初期検証だけなら、Azureの30日間200米ドルクレジットの範囲でも「Azureが販売するモデル」の比較や評価は試せます。ただし前述のとおり無料クレジットのサブスクリプションではMarketplace購入ができないため、AnthropicのClaudeなどパートナー区分のモデルはこの枠では動かせません。手元のPCで費用をかけずに検証したい場合は、同じモデルカタログとSDKの流儀をローカルで使えるFoundry Localとは?使い方・対応モデル・SDK実装を解説【Microsoft製ローカルAI】も選択肢になります。
よくある質問
Cloud FoundryとAzure AI Foundryは同じものですか?
まったく別の製品です。Cloud Foundryはアプリケーションを動かすオープンソースの実行基盤で、現在はLinux Foundation傘下のプロジェクトとして開発されています。Azure AI Foundry(現Microsoft Foundry)はMicrosoftの生成AI開発基盤で、両者に技術的な継承関係はありません。名前が似ているため検索結果が混ざりますが、cf push などの操作が出てくる記事は前者の話です。
Azure OpenAI Serviceは廃止されるのですか?
廃止の予定は公表されていません。Microsoft Learnは前後どちらのリソース種別も一般提供(GA)でサポート対象だと明記し、製品名も「Azure OpenAI in Foundry Models」として維持されています。ただし前述のとおり自動アップグレードの対象にはなり得るので、現状のまま据え置きたいなら放置ではなく延期かオプトアウトの操作が要ります。サービス自体の機能や料金はAzure OpenAI Serviceとは?できること・料金・導入事例まで実務目線で解説で整理しています。
アップグレード後に元へ戻せますか?
戻せます。ロールバックの前に、プロジェクト・接続・Azure OpenAI以外のモデルデプロイを削除する必要があり、その後にFoundry (classic) ポータル、Azureポータル、またはARM/Bicepテンプレートで kind を OpenAI に戻します。リージョンごとの上限にも注意が要ります。Azure OpenAIリソースは1サブスクリプション・1リージョンあたり30、Foundry側の AIServices リソースは同100が上限で、埋まっているとそれぞれロールバックとアップグレードが失敗します。
Foundryで11,000以上のモデルが使えるという説明は正しいですか?
出典によって数え方が違います。Microsoft Learnのモデルカタログ概要は「10,000を超えるモデル」と記載し、毎月およそ50モデルが追加されるとしています。一方でAzureの価格ページとFoundryブログは11,000以上という数字を使っています。いずれも増加中の概数なので、特定の数値を要件定義に書くより、必要なモデルがカタログにあるかを直接確認してください。
エージェント機能を使うには何が必要ですか?
Foundryリソースであることに加えて、エージェントサービスが提供されているリージョンを選ぶ必要があります。エージェントの作成にはEntra IDのデータプレーンロール(Foundry User、Foundry Project Manager、Foundry Owner など)が必要で、サブスクリプションのOwnerやContributorだけでは作成できません。この点はFoundry Agent Serviceとは?旧Azure AI Agent Serviceからの移行と料金・実装手順【2026年8月時点】で詳しく扱っています。