Azure AI Foundryとは？Azure OpenAIとの違い・モデル・料金と始め方（現Microsoft Foundry）

Azure AI Foundryは、モデル・エージェント・ツールを1つのAzureリソースの下で扱うMicrosoftのAI開発基盤で、現在の正式名称は「Microsoft Foundry」です。実務で判断に困るのは「すでにAzure OpenAI Serviceを使っているのに、Foundryへ移る意味はあるのか」という点でしょう。結論から言えば、両者の差はAzureリソースの種別そのものにあります。この記事はそこを起点に、自動アップグレードの止め方、Geminiが無いモデルカタログ、東日本リージョンの単価、Azure CLIとPythonで動かすまでの手順を、2026年10月時点のMicrosoft Learnと価格APIで確認できる範囲に絞って整理します。現行名での全体像はMicrosoft Foundryとは？できること・料金の仕組み・始め方【2026年10月】にまとめているので、製品全体の把握が目的ならそちらから読んでください。

まとめ：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キー・既存ジョブは保持され、既存機能の料金も変わりません。問題があればロールバックできます。
• Azure AI FoundryとMicrosoft Foundryは同じ製品の旧名と現行名です。改称と同時にポータル・API・SDKが新世代へ切り替わりましたが、旧ポータルはFoundry (classic) として残っています。
• モデルカタログにGeminiはありません。Google由来で使えるのはオープンウェイトのGemmaファミリーだけです。
• プラットフォーム自体は無料で、課金はモデル推論などのサービス単位です。東日本のGlobal Standardでは、gpt-5.4-miniが入力100万トークンあたり0.75ドル、出力4.50ドルです。
• 新規に始めるなら、Azure CLI 2.80.0以降で az cognitiveservices account create --kind AIServices からリソースを作り、Pythonは azure-ai-projects 2.x系（2026年10月時点の最新は2.9.0）の AIProjectClient で呼び出します。

Azure OpenAIとAzure AI Foundryの違いを決めているリソース種別

日本語の解説では「Azure OpenAIは部品、Foundryは作業場」といった比喩で説明されがちですが、課金と権限に効くのはもっと即物的な部分です。Azureの管理面から見れば、両者は同じ Microsoft.CognitiveServices/accounts というリソースの、kind プロパティ違いにすぎません。だから「並べて比較して選ぶ」のではなく「既存リソースを変換する」のが正しい理解になります。

表のFoundryリソースで使えるAzure販売モデルの内訳は、Azure OpenAI／Black Forest Labs／DeepSeek／Meta／SpaceXAI（旧xAI）／Mistral／Microsoftです。「パートナー等のモデル」はMarketplace経由のパートナー・コミュニティモデルを指します。Foundry Toolsに含まれるのは、音声・視覚・言語・Content Understandingです。Content Understandingの料金や解析APIの使い方はAzure Content Understandingとは？Document Intelligenceとの違い・料金・REST APIの使い方【2026年10月】にまとめています。

出典はMicrosoft LearnのUpgrade Azure OpenAI to Microsoft Foundry（ms.date 2026年8月19日）です。同ページの表はベンダー名を旧称の「xAI」のまま載せていますが、Azureが販売するモデルの一覧（同2026年9月21日）は改称後の「SpaceXAI」表記に切り替わっています。

新規に作るなら、上位集合であるFoundryリソース（kind: AIServices）から始めるのが既定です。あえてAzure OpenAIリソースを選ぶ理由として代表的なのは、Weights & Biases連携を使う場合と、RBACの適用範囲をOpenAI機能だけに絞りたい場合です。既存リソースを据え置くかどうかは、次の節以降で挙げるCMK・プライベートエンドポイント・権限の制約も合わせて判断します。Azure OpenAI単体で何ができ、どう課金されるかを先に押さえたい場合は、Azure OpenAI Serviceの機能と料金を整理した記事を前提知識として読むと、この差がつかみやすくなります。

既存リソースのアップグレードで保持される設定と、変わらないコスト

移行のハードルは想像より低く設定されています。Learnは、リソース名・Azureリソースタグ・ネットワーク構成・アクセスおよびID構成・APIエンドポイントとAPIキー・カスタムドメイン名、そしてファインチューニングジョブやバッチなどの既存状態がそのまま維持されると列挙しています。既存アプリの接続先を書き換える必要はありません。料金についても「既存のAzure OpenAI機能に対して追加費用は発生しない（you don’t pay more for existing Azure OpenAI functionality）」と明示されています。つまり移行そのものは無償で、増えた機能を使ったときだけ課金が増える構造です。

すでに移行済みかどうかは、リソースのプロパティで判別できます。アップグレード済みのリソースにだけ読み取り専用の previousKind が現れます。

{
  "properties": {
    "previousKind": "OpenAI"
  }
}

Azure CLIから確かめるなら、次の1行で kind と previousKind を並べて表示できます。誰がいつ変換したかは、アクティビティログで Microsoft.CognitiveServices/accounts/write 操作を絞り込むと追えます。

az cognitiveservices account show \
  --name my-openai-resource \
  --resource-group my-rg \
  --query "{kind:kind, previousKind:properties.previousKind}" \
  --output table

Microsoftによる既存リソースの自動アップグレードと、その止め方

日本語の上位記事ではほとんど触れられていない変化です。Microsoft LearnのManage automatic upgrades from Azure OpenAI to Microsoft Foundry（ms.date 2026年8月19日）は「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 を使います。Learnが示す定義は次のとおりで、既存リソースのIDを渡して更新だけを行います。

variable "azure_openai_resource_id" {
  type = string
}

resource "azapi_update_resource" "disable_foundry_auto_upgrade" {
  type        = "Microsoft.CognitiveServices/accounts@2026-01-15-preview"
  resource_id = var.azure_openai_resource_id

  body = {
    properties = {
      foundryAutoUpgrade = {
        mode = "Disabled"
      }
    }
  }
}

terraform plan で既存アカウントの置き換えや削除が出ていないことを確かめてから適用してください。オプトアウトには Microsoft.CognitiveServices/accounts/write を含むロールが要ります。プライベートネットワークやCMKを使うリソースは初期の自動対象から外れていますが、除外が恒久的だとは書かれていません。セキュリティレビューが終わっていない組織ほど、先に状態を確認しておくべきです。なお foundryAutoUpgrade が無いことを「対象外の証明」として自動化に組み込まないよう、Learnは「プロパティが無いことを唯一の判定材料にしない」と明記しています。

テンプレートで止める場合は、API版の選び方にも注意が要ります。accountsリソースのAPI変更履歴では、foundryAutoUpgrade は 2026-01-15-preview・2026-05-15-preview・2026-07-15-preview・2026-09-15-preview のプレビュー版で追加され、安定版の 2026-07-01 と 2026-09-01 では削除されています。BicepやARMテンプレートを安定版のAPIで書いていると、このプロパティを書けません。オプトアウトだけはプレビュー版のAPIで別の定義を当ててください。

Foundryへの移行着手前に確認すべき権限・ネットワークの前提と制約

前提として、サブスクリプションまたはリソースグループの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機能を段階的に開放したいなら、モデルデプロイのポリシーを先に設定します。

テンプレートで移行する場合に必須の変更は、kind を AIServices にし、allowProjectManagement と customSubDomainName を設定することです。下の例の disableLocalAuth: true はAPIキー認証を止める別の設定なので、APIキーで接続している既存アプリがあるなら、Entra ID認証へ切り替えるまで false のままにしてください。Bicepの基本的な書き方やデプロイの流れはAzure Bicepのインストールからデプロイまでの実務手順で扱っています。

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    // APIキー認証を止める。キー接続のアプリが残るならfalse
  }
}

TerraformのAzureRMプロバイダーを使う場合は、リソースを作り直さずに OpenAI と AIServices を行き来するためにバージョン4.56.0以降が必要です。

Azure CLIでFoundryリソースとプロジェクトを作りモデルをデプロイする

ここからは、既存のAzure OpenAIを持たない状態から新規に始める手順です。Microsoft LearnのQuickstart: Set up Microsoft Foundry resources（ms.date 2026年8月25日）に沿って、ポータルを使わずAzure CLIだけで組み立てます。CLIは2.80.0以降が必要です。az cognitiveservices account project 系のコマンドはこの版で追加されたもので、古いCLIでは unrecognized arguments で失敗します。CLIで作る場合、リソースグループに対するContributorかOwnerがあれば作成できます。

2026年10月26日に公式コンテナ mcr.microsoft.com/azure-cli:latest（azure-cli 2.91.0）で各コマンドの --help を確認したところ、以下で使う引数はすべて実在しました。--allow-project-management には --manage-projects という別名があり、ヘルプには「AIServices kind only」と書かれています。

東日本のリソースグループからプロジェクト作成までのCLIコマンド

次のコマンドは、東日本リージョンにリソースグループ、Foundryリソース、プロジェクトを順に作ります。--custom-domain に渡すサブドメインはAzure全体で一意である必要があり、他者が使っている名前だと CustomDomainInUse で止まります（リソース名そのものの一意性はリソースグループ内です）。

az login
az group create --name my-foundry-rg --location japaneast

az cognitiveservices account create \
  --name my-foundry-resource \
  --resource-group my-foundry-rg \
  --kind AIServices \
  --sku S0 \
  --location japaneast \
  --custom-domain my-foundry-resource \
  --assign-identity \
  --allow-project-management true

az cognitiveservices account project create \
  --name my-foundry-resource \
  --resource-group my-foundry-rg \
  --project-name my-foundry-project \
  --location japaneast

引数のうち --assign-identity を落とすと、プロジェクト作成が「マネージドIDを有効にせよ」というエラーで失敗します。--allow-project-management は作成後に変更できないので、Foundryとして使う前提なら最初から true にしておきます。Learnのサンプルは eastus ですが、ここでは国内の検証を想定して japaneast に置き換えました。モデルと機能の提供はリージョンで差があるため、次の手順で使いたいモデルが東日本に出ているかを先に確認してください。なお、次の例で使う GlobalStandard は推論をAzureの全世界のデータセンターへ振り分ける方式で、リソースを東日本に作っても推論の処理場所は国内に限定されません。国内での処理が要件なら、リージョン単位の Standard や Regional Provisioned をそのモデルが東日本で提供しているかを一覧で確かめてから選びます。

東日本でモデルの提供状況と退役日を確かめてデプロイする

モデル名・版・SKUの組み合わせはリージョンごとに異なります。いきなりデプロイせず、一覧で確かめてから指定するのが失敗しない順番です。例に使う gpt-5.4-mini（版 2026-03-17）は、Learnのモデル退役スケジュール（ms.date 2026年9月21日）で退役予定日が2027年9月21日です。1巡前の定番だった gpt-5-mini（版 2025-08-07）は2027年2月9日に退役予定なので、これから作るシステムの既定モデルには向きません。

az cognitiveservices model list \
  --location japaneast \
  --query "[?model.name=='gpt-5.4-mini'].{version:model.version,skus:join(',',model.skus[].name)}" \
  --output table

az cognitiveservices account deployment create \
  --name my-foundry-resource \
  --resource-group my-foundry-rg \
  --deployment-name gpt-5.4-mini \
  --model-name gpt-5.4-mini \
  --model-version "2026-03-17" \
  --model-format OpenAI \
  --sku-capacity 10 \
  --sku-name GlobalStandard

az cognitiveservices account project show \
  --name my-foundry-resource \
  --resource-group my-foundry-rg \
  --project-name my-foundry-project \
  --query 'properties.endpoints."AI Foundry API"' --output tsv

組み合わせが合わないと DeploymentModelNotSupported が返ります。最後のコマンドが出力する https://my-foundry-resource.services.ai.azure.com/api/projects/my-foundry-project 形式の値が、次の章でプロジェクトエンドポイントとして指定する接続先です。退役日が近づいたときの挙動はデプロイの versionUpgradeOption で決まり、新しい既定版が出た時点で上げる OnceNewDefaultVersionAvailable、退役時にだけ上げる OnceCurrentVersionExpired などから選べます。アプリのひな形とインフラ定義をまとめて展開したい場合は、Azure Developer CLI（azd）のazd upの使い方で解説しているテンプレート方式も選べます。

azure-ai-projects 2.xでFoundryモデルを呼ぶ

Foundryのコードは、Azure OpenAI時代の「複数パッケージ×複数エンドポイント」から、azure-ai-projects 2.x系と単一のプロジェクトエンドポイントへ集約されました。Quickstart: Get started with Microsoft Foundry SDK（ms.date 2026年9月3日）の導入行は azure-ai-projects>=2.3.0 のままですが、PyPIの最新は2.9.0です。2026年10月26日に python:3.12-slim コンテナで最新版を入れると、azure-ai-projects 2.9.0 と依存の openai 3.37.0 が入り、依存条件は openai>=3.0.0 でした。1.x系とは互換性が無く、1.x向けの手順はFoundry (classic) 側のドキュメントにあります。

pip install "azure-ai-projects>=2.9.0,<3" azure-identity
az login

認証は DefaultAzureCredential で、手元では az login のサインイン情報がそのまま使われます。APIキーを環境変数に置かずに済むので、検証段階からキーレス運用に寄せられます。

from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient

# 前章で取得したプロジェクトエンドポイント
FOUNDRY_PROJECT_ENDPOINT = "https://my-foundry-resource.services.ai.azure.com/api/projects/my-foundry-project"

project = AIProjectClient(
    endpoint=FOUNDRY_PROJECT_ENDPOINT,
    credential=DefaultAzureCredential(),
)
openai = project.get_openai_client()

# Responses APIで呼び出す。modelにはデプロイ名を渡す
response = openai.responses.create(
    model="gpt-5.4-mini",
    input="Azure AI FoundryとAzure OpenAIの違いを1文で説明してください。",
)
print(response.output_text)

get_openai_client() が返すのは素の openai.OpenAI クライアントです。同じコンテナで認証をダミーに差し替えて組み立てると、接続先は https://my-foundry-resource.services.ai.azure.com/api/projects/my-foundry-project/openai/v1/ になりました（Azure側へは送信していません）。つまり responses.create の書き方はOpenAIのSDKと同じです。Learnのサンプルには「Foundryが直接提供するすべてのモデルに対応する」という注記があり、デプロイ名を差し替えればAzure OpenAI以外のモデルにも同じコードで投げられます。モデルごとにクライアントを持ち替えていたAzure OpenAI時代との、実務上の差はここにあります。

SDKを入れずにcurlでResponses APIの疎通を確認する

疎通だけを見たい場合や、Python以外の言語から呼ぶ前の確認には、REST直叩きが早く済みます。アクセストークンは https://ai.azure.com/.default のスコープで取得し、60〜90分で期限が切れます。

export AZURE_AI_AUTH_TOKEN=$(az account get-access-token \
  --scope https://ai.azure.com/.default --query accessToken -o tsv)

curl -X POST "https://my-foundry-resource.services.ai.azure.com/api/projects/my-foundry-project/openai/v1/responses" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $AZURE_AI_AUTH_TOKEN" \
  -d '{"model": "gpt-5.4-mini", "input": "Hello from Foundry"}'

パスの /openai/v1/ が、改称表にある「v1安定ルート」です。毎月の api-version クエリを付けずに済みます。このv1 APIは移行前のAzure OpenAIリソースでも使えるので、Foundryへの移行とAPIの書き換えは別々の時期に進められます。

組み込みロール名の改称と、Ownerでもエージェントを作れない理由

Foundryの組み込みロールは改称が進行中です。Learnによれば Foundry User／Foundry Owner／Foundry Account Owner／Foundry Project Manager は、それぞれ旧Azure AI User／Azure AI Owner／Azure AI Account Owner／Azure AI Project Managerにあたり、ロールIDと権限は変わっていません。移行期間中は画面やドキュメントに新旧の名前が混在するため、スクリプトではロール名でなくGUIDで指定するようLearnは勧めています。開発者に最小権限で使わせるなら、プロジェクトのスコープにFoundry User（53ca6127-db72-4b80-b1b0-d745d6d5456d）を割り当てます。

PROJECT_ID=$(az cognitiveservices account project show \
  --name my-foundry-resource \
  --resource-group my-foundry-rg \
  --project-name my-foundry-project \
  --query id -o tsv)

az role assignment create \
  --role "53ca6127-db72-4b80-b1b0-d745d6d5456d" \
  --assignee-object-id "<security-group-object-id>" \
  --assignee-principal-type Group \
  --scope $PROJECT_ID

よくある詰まりが「サブスクリプションのOwnerなのにエージェントを作れない」というものです。OwnerやContributorは管理プレーン（デプロイの作成など）の権限で、エージェントの作成のような開発操作にはEntra IDのデータプレーンロールが別に要ります。コードが403で落ちたら、まずこの割り当てを疑ってください。

Azure AI FoundryとMicrosoft Foundryの違い：2度の改称とポータル2系統

Azure AI FoundryとMicrosoft Foundryは別製品ではなく、同じ製品の旧名と現行名です。ただし名前が変わっただけではなく、改称と同時にポータル・エージェントAPI・SDK・リソースモデルが新世代へ切り替わりました。製品はAzure AI Studio→Azure AI Foundry→Microsoft Foundryと短期間に2度改称されたため、検索語と製品名が一致しなくなっています。Microsoft LearnのMicrosoft Foundryとは（ms.date 2026年8月13日）にある「Evolution of Foundry」表が、公式の対応関係です。

表の旧ブランド2名称はAzure AI StudioとAzure AI Foundryです。以前のリソースモデルは、ハブ＋Azure OpenAI＋Azure AI Servicesという構成でした。以前の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」です。旧名称時代にどんな業務で使われていたかは、Azure AI Studioの活用事例｜企業の導入例と使いどころを整理（現Microsoft Foundry）に残しています。

Geminiが無いモデルカタログと、Google由来で使えるGemma

「azure ai foundry gemini」で検索して来た方には、先に結論をお伝えします。Foundryのモデルカタログに Gemini はありません。Azureが販売するモデルの一覧（ms.date 2026年9月21日）にも、パートナー・コミュニティモデルの一覧（同2026年9月21日）にも、GoogleおよびGeminiの記載は1件もありません（2026年10月26日に両ページの本文を検索して確認）。前者に章立てされているのは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を併用する構成になります。Vertex AIの機能と料金、Azure Machine Learningとの違いはVertex AIの機能・料金とSageMaker／Azure MLとの違いを解説した記事で比較しています。逆にAzureのRBAC・ネットワーク・監査の内側で完結させたいなら、同じ研究基盤から出たオープンウェイトのGemmaへ置き換えるのが現実的な代替です。

Gemma 4の仕様とライセンス、Foundryでの2つの提供経路

Gemma 4はGoogle DeepMindが2026年4月2日に公開したモデル群で、ライセンスはApache 2.0です。テキスト・画像・動画のマルチモーダル入力に対応し、コンテキストウィンドウはE2B／E4Bが128Kトークン、26B A4B／31Bが256Kトークンです。140以上の言語で事前学習され、35以上の言語をそのまま扱えます。Gemini 3と同じ研究基盤から作られている、とMicrosoftのFoundryブログは説明しています。旧世代のGemma 3系（unsloth-gemma-3-12b-it など）も一般提供のままカタログに残っています。

Foundryでの提供経路は2つあり、課金の形がまったく違います。1つはHugging Faceコレクション経由でマネージドコンピューティングへ載せる方法で、トークン従量ではなく仮想マシンの稼働時間で課金されます。もう1つはFireworks on Foundryのモデル一覧（ms.date 2026年10月13日）に載る FW-Gemma-4-26B-A4B-IT と FW-Gemma-4-31B-IT です。ただしこの2モデルはプロビジョンドスループットの表にだけあり、Global ProvisionedとData Zone Provisionedで最小200 PTU・100 PTU刻みの予約になります。同じページのトークン従量（Global Standard）の表にGemmaは無いので、少量をトークン単位で試す使い方はどちらの経路でもできません。

カタログ2区分の分かれ目：Azureメーター課金とMarketplace課金

モデル選定では、性能とは別に調達の条件も確認が要ります。カタログは「Azureが販売するモデル」と「パートナー・コミュニティのモデル」の2区分に分かれており、この区分で課金経路と必要権限が変わります。前者はMicrosoftがサポートしエンタープライズSLAが付き、課金経路はAzureメーターです。後者はモデル提供元がライセンス条件と価格を決め、Azure Marketplace経由で請求されるため、購読時に Microsoft.MarketplaceOrdering/* や Microsoft.SaaS/register/action などの権限が必要になります。サブスクリプションのOwnerとContributorはこれらの権限を含むロールです。Foundryリソースにしか無い代表例はAnthropicのClaudeで、Learnもパートナー区分の筆頭に挙げています。Claudeの請求単位はClaude Consumption Unit（CCU）で、新しく作るデプロイは自動的にCCU課金になり、それ以前のデプロイはモデル別の料金プランのまま続きます。既存の処理をCCUへ移すには、デプロイを作り直します。

問題は、契約形態によってはMarketplaceでの購入自体ができない点です。パートナーモデル一覧は、Claudeを使えないサブスクリプションとして、Cloud Solution Provider契約、従量課金の支払い方法を持たない学生・無料試用・スタートアップクレジットのサブスクリプション、Azureクレジットだけで使うスポンサー契約、韓国のEnterprise契約を挙げています。社内の調達ルールでMarketplace購入が止まっている組織でも、パートナー区分のモデル（AnthropicのClaude、NTT Dataのtsuzumi など）が「カタログには見えるのにデプロイできない」状態になります。判定はベンダー単位でなくモデル単位で行ってください。Cohereのように両区分に同名の章を持つベンダーもあります。

Claudeを東日本リージョンで使えるか、デプロイ前に確認する提供範囲

国内案件で見落とされやすいのがリージョンです。2026年9月21日版のパートナーモデル一覧では、ClaudeのGlobal Standardデプロイが載っているのは米国の各リージョンとスウェーデン中部で、Asia Pacificの表（japaneast・japanwest を含む）にClaudeの行はありません。Asia Pacificの表に並ぶのはCodestral・Llama 4 Scout・Ministral・Mistral系だけです。Data Zone Standardも米国データゾーンのみなので、東日本リージョンに作ったFoundryリソースからは、現時点ではClaudeをデプロイできない前提で設計する必要があります。Claudeを使う部分だけを米国リージョンのリソースへ切り出す場合も、推論はGlobal Standard（全世界で処理）か米国データゾーンで処理される前提になります。データ所在地の要件が厳しい案件では、Claudeを使うかどうか自体を要件定義の段階で決め、代替にするAzure販売モデルも、国内で処理できるデプロイ方式が東日本にあるかで選んでください。同じページには、Claudeに「Azure上でホスト」と「Anthropicの基盤でホスト」の2形態があり、モデルによって提供形態とライフサイクル段階が違うという注記もあります。

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で始めることです。社内システムのデータを読むだけなら、Copilot StudioにもPower Platformのコネクター経由で接続する経路があるので、それだけを理由にFoundryを選ぶ必要はありません。両者は排他ではありません。開発者がFoundryで専用のツールやエージェントを作り、業務部門がCopilot Studioで利用者向けの体験を組む併用パターンが一般的だとMicrosoftは説明しています。費用構造とデータ管理の観点からAzure OpenAIとMicrosoft 365側のCopilotを比べたい場合は、Azure OpenAIとCopilotの違いを費用とデータ管理で比べた記事が判断の材料になります。

Azure AI Foundryの料金：プラットフォームは無料、モデルはデプロイ方式ごとに課金

Microsoft Foundryの価格ページのFAQは「The Foundry platform is free to use and explore」と述べており、ポータルやプロジェクトを持つこと自体に費用はかかりません。課金はFoundry Models、Foundry Agent Service、Foundry IQ、Foundry Tools、Foundry Control Planeとサービスごとに別体系で発生します。

「結局いくらかかるのか」に答えるには、モデルの単価を見るのが早道です。価格ページは単価をJavaScriptで描画するため、ここでは同じ値を返すAzure Retail Prices APIから、2026年10月26日に東日本（japaneast）のGlobal Standardの単価を取得しました。

単価はいずれも100万トークンあたりの米ドルです。たとえば1回あたり入力2,000トークン・出力500トークンの問い合わせを月1万回処理すると、入力2,000万トークンと出力500万トークンになり、gpt-5.4-miniなら15ドル＋22.5ドルで月37.5ドル、gpt-5-miniなら5ドル＋10ドルで月15ドルです。同じAPIで優先処理（priority processing）を選ぶとgpt-5.4-miniの入力は1.5ドル・出力9ドルと2倍になり、急がない処理をBatchへ回せば入力0.375ドル・出力2.25ドルに下がります。単価は改定されるので、見積もりの直前に価格APIか価格ページで取り直してください。

デプロイ方式によって課金の仕組みも変わります。Global Standard・Data Zone Standard・Global Batchなどのサーバーレスデプロイは、上の表のような入出力トークンの従量課金です。Global・Data Zone・Regionalの各Provisionedはスループットの予約で、推論の有無にかかわらず、デプロイしたPTU数に応じて時間単位で課金されます。一方のマネージドコンピューティングはモデルの重みを専用の仮想マシンに載せる方式なので、推論していない時間も含めた仮想マシンのコア時間で課金されます。Hugging Faceのオープンモデルを常時待機させる構成では、ここが想定外のコストになりやすい部分です。Azure OpenAIのモデルに標準で組み込まれたコンテンツフィルターは追加料金なしで、プロンプトシールドなどを単体のAzure AI Content Safetyサービスとして呼ぶ場合はそちらの料金がかかります。前章のCLI例で使った GlobalStandard はトークン従量のサーバーレス側なので、呼ばなければ費用は発生しません。検証が終わったら az group delete --name my-foundry-rg でリソースグループごと消しておくと、消し忘れによる課金を防げます。

初期検証だけなら、Azureの30日間200米ドルクレジットの範囲でも「Azureが販売するモデル」の比較や評価は試せます。ただし前述のとおり無料クレジットのサブスクリプションではMarketplace購入ができないため、AnthropicのClaudeなどパートナー区分のモデルはこの枠では動かせません。ローカル環境で費用をかけずに検証したい場合は、同じモデルカタログとSDKの流儀をローカルで使えるFoundry Localとは？使い方・対応モデル・SDK実装を解説【Microsoft製ローカルAI】も選択肢になります。

Azure AI Foundryの採用条件とAzure OpenAIを据え置く場面

新規に生成AIのシステムをAzure上で組むなら、原則としてFoundryリソースから始めてください。Azure OpenAIリソースで始めても機能の差は後から自動アップグレードで埋まる方向に動いており、あえて狭い種別を選ぶ利点はほぼ残っていません。

採用を急ぐべきなのは、まずOpenAI以外のモデル（Mistral、DeepSeek、Llama、Claudeなど）を同じコードで比較したい場合です。エージェントをアプリの中核に据える場合も、エージェントサービスはFoundry側にしか無いので待つ理由がありません。サービスごとにエンドポイントとSDKが分かれて保守が重くなっている場合も、プロジェクトエンドポイント1本へ寄せられるFoundryが有利です。なお月次の api-version 指定が要らないv1 APIはAzure OpenAIリソースでも使えるので、APIバージョンの追随だけが悩みなら、移行しなくてもv1 APIへ書き換えるだけで解消します。

逆に、しばらくAzure OpenAIのまま据え置く判断が妥当な場面もあります。Weights & Biases連携を本番で使っている場合、Cognitive Services Userをワイルドカードで広く割り当てていて権限の棚卸しが終わっていない場合、プライベートエンドポイントとカスタムDNSの構成変更に変更管理の承認が要る場合です。このときは放置せず、foundryAutoUpgrade.mode を Disabled にして、移行時期を自分で決められる状態にしておくのが実務上の落としどころです。

Foundry上でのRAGやエージェント開発、Azure OpenAIからの移行設計を社内だけで進めるのが難しい場合は、一創の生成AI開発・AI受託開発でPoCから本番運用まで一貫して支援しています。リソース設計・権限設計・モデル選定の段階から相談いただけます。

よくある質問

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以上という数字を使っています。いずれも増加中の概数なので、特定の数値を要件定義に書くより、必要なモデルがカタログにあるかを直接確認してください。リージョン単位の提供状況は、本文で紹介した az cognitiveservices model list --location で確かめられます。

エージェント機能を使うには何が必要ですか？

Foundryリソースであることに加えて、エージェントサービスが提供されているリージョンを選ぶ必要があります。エージェントの作成にはEntra IDのデータプレーンロール（Foundry User、Foundry Project Manager、Foundry Owner など）が必要で、サブスクリプションのOwnerやContributorだけでは作成できません。この点はFoundry Agent Serviceとは？旧Azure AI Agent Serviceからの移行・料金とブラウザ自動化の実装手順【2026年10月】で詳しく扱っています。

関連記事

• Microsoft Foundryとは？できること・料金の仕組み・始め方【2026年10月】
• Azure OpenAI Serviceとは？できること・料金・導入事例まで実務目線で解説
• Foundry Agent Serviceとは？旧Azure AI Agent Serviceからの移行・料金とブラウザ自動化の実装手順【2026年10月】
• Foundry Localとは？使い方・対応モデル・SDK実装を解説【Microsoft製ローカルAI】
• Azure AI Studioの活用事例｜企業の導入例と使いどころを整理（現Microsoft Foundry）