Azure AI FoundryでAzure OpenAIリソースをMicrosoft Foundryへアップグレードする変更は、「既存環境を作り直す移行」ではなく、既存のAzure OpenAIリソースをFoundryリソースとして使えるようにする拡張です。APIエンドポイント、APIキー、リソース名、ネットワーク構成、既存の微調整ジョブやバッチなどは基本的に維持されます。一方で、利用できるモデルやAgent Service、評価機能、Foundry Toolsが広がるため、管理者はRBAC、Azure Policy、プライベートネットワーク、リージョン対応を先に確認する必要があります。(Microsoft Learn)
特に社内AIアプリやCopilot的な業務アシスタントをAzure OpenAIで構築している企業では、「既存アプリは動き続けるか」だけでなく、「誰が新しいモデルやエージェント機能を使えるようになるか」を確認することが重要です。アップグレード後に権限設計を見直さないと、OpenAI以外のモデルやFoundry専用機能が意図せず利用可能になる場合があります。(Microsoft Learn)
Azure AI Foundryのアップグレードで何が変わるのか
Microsoft Foundryリソースは、Azure OpenAIリソースより広い機能を持つ上位互換的なリソース種別として説明されています。アップグレードすると、Azure OpenAI APIだけでなく、より広いモデルカタログ、Agent Service、評価機能、Speech・Vision・Language・Content UnderstandingなどのFoundry Toolsにアクセスできるようになります。(Microsoft Learn)
| 観点 | アップグレード前のAzure OpenAI | アップグレード後のMicrosoft Foundry |
|---|---|---|
| 利用できるモデル | 主にAzure OpenAIモデル | Azure OpenAIに加え、FoundryのモデルカタログやMarketplace経由のモデルを利用可能 |
| エージェント開発 | Azure OpenAI中心の機能利用 | Agent ServiceやFoundry API/SDKを使った開発が可能 |
| 評価・検証 | Azure OpenAI側の機能が中心 | 評価ツールやFoundry Toolsとの連携が広がる |
| 管理単位 | Azure OpenAIリソース中心 | Foundryプロジェクト単位で作業やアクセスを整理 |
| 既存エンドポイント | Azure OpenAI APIエンドポイント | 既存エンドポイントを維持しつつ、新しいFoundryエンドポイントも利用可能 |
| コスト | 既存のAzure OpenAI利用料金 | 既存機能の料金は変わらないが、新機能は利用内容に応じた料金が発生する可能性あり |
実務上のポイントは、アップグレード自体よりも「機能範囲が広がることによる管理範囲の拡大」です。GPT系モデルだけを使っていたチームが、アップグレード後に別プロバイダーのモデル、エージェント、評価ツールまで使えるようになる可能性があります。そのため、開発チームにとっては選択肢が増え、管理部門にとってはガバナンス設計の見直しが必要になります。
既存環境で維持されるものと変更されるもの
アップグレードでは、新しいFoundryリソースを別途作成する必要はありません。公式情報では、既存のAzure OpenAI APIエンドポイント、作業状態、セキュリティ構成を保持できるとされています。具体的には、リソース名、Azureリソースタグ、ネットワーク構成、アクセスとIDの構成、APIエンドポイントとAPIキー、カスタムドメイン名、既存の微調整ジョブやバッチなどが維持されます。(Microsoft Learn)
一方で、リソースの種類はAzure OpenAIからFoundryへ変わります。BicepやTerraformなどのIaCで管理している場合は、kindをOpenAIからAIServicesへ変更し、allowProjectManagementをtrueに設定し、マネージドIDを構成する流れになります。これは新規作成ではなく、既存リソースに対するパッチ操作として扱うのが基本です。(Microsoft Learn)
kind: 'AIServices'
identity: {
type: 'SystemAssigned'
}
properties: {
allowProjectManagement: true
}既存アプリケーションがAzure OpenAI APIエンドポイントとAPIキーだけを使っている場合、アップグレード直後に接続先を変える必要は基本的にありません。ただし、Foundry API、Agent Service、評価機能、プロジェクト単位の管理を使う場合は、SDK、認証方式、RBACロール、ネットワーク経路の確認が必要です。
アップグレード前に管理者が確認すべき項目
Azure AI Foundryへのアップグレードは、ポータル操作だけで完了できるように見えます。しかし、本番環境では「押す前の確認」が最も重要です。特に閉域網、Azure Policy、カスタムロール、CMKを使っている環境では、事前確認なしに進めると、アップグレード後に一部機能へアクセスできない、または意図しない機能が解放されるリスクがあります。
| 確認項目 | 見る場所 | 判断基準 |
|---|---|---|
| 権限 | サブスクリプションまたはリソースグループのIAM | アップグレード操作にはOwnerロールが必要。マネージドID有効化やプロジェクトへのロール割り当てができるか確認 |
| マネージドID | Azure OpenAIリソースの「ID」 | システム割り当てマネージドIDが有効か確認 |
| リージョン | Foundryのモデル・機能提供リージョン | 使いたいモデル、Agent Service、評価機能が対象リージョンで利用可能か確認 |
| CMK | 暗号化設定 | カスタマーマネージドキーを使うAzure OpenAIリソースは、アップグレードがリクエストベースになる点に注意 |
| Azure Policy | ポリシー割り当て、カスタムポリシー | モデルやリソース種別の制限がFoundry拡張後も意図通りか確認 |
| RBAC | 組み込みロール、カスタムロール、ワイルドカード定義 | Cognitive Services Userなど広いロールがFoundry機能まで許可しないか確認 |
| プライベートネットワーク | DNS、Private Link、条件付きフォワーダー | Foundryで必要なFQDNを解決できるか確認 |
| ロールバック方針 | 変更管理、リリース計画 | ロールバック前に削除が必要なプロジェクト、接続、非Azure OpenAIモデルデプロイを把握 |
公式情報では、Foundryモデルや機能の可用性はリージョンによって異なり、CMKを使うAzure OpenAIリソースはリクエストによるアップグレード対象、Weights & Biases構成はFoundryリソース種別でサポートされないとされています。プライベートネットワーク構成では追加DNS設定も必要です。(Microsoft Learn)
RBACとAzure Policyは最優先で見直す
アップグレード後もAzure RBACやAzure Policyは引き続き機能します。ただし、Microsoft FoundryはAzure OpenAIより広い機能セットを持つため、広めのロール割り当てやワイルドカードを使ったポリシー定義では、アップグレード直後にFoundry専用機能へアクセスできる範囲が広がる可能性があります。(Microsoft Learn)
| ガバナンス制御 | アップグレード前 | アップグレード後の注意点 |
|---|---|---|
| Cognitive Services User | OpenAI機能へのアクセス | Foundryの全機能へアクセスできる可能性がある |
| Cognitive Services OpenAI User | OpenAI機能へのアクセス | OpenAI機能中心のアクセスにとどめやすい |
| カスタムRBACロール | 定義した機能のみ | 定義内容が適切なら範囲を維持しやすい |
| モデルアクセス制限なし | OpenAIモデル中心 | 任意のFoundryモデルを利用できる可能性がある |
| モデルアクセスをAzure Policyで制御 | 許可済みOpenAIモデルのみ | ポリシーで許可したモデルのみに制御可能 |
段階的に展開したい場合は、アップグレード前に「OpenAI以外のモデルを許可するチーム」「Agent Serviceを試せるチーム」「評価ツールを使えるチーム」を分けておくと安全です。全員に広い権限を付与してから制限するより、必要なチームへ順に解放するほうが、監査やコスト管理もしやすくなります。
また、Agent作成などの開発操作では、AzureのOwnerやContributorだけでは足りない場合があります。公式情報では、エージェントを含む開発操作にはEntra IDのデータプレーンロールが必要で、Foundry User、Foundry Project Manager、Foundry Ownerなどのロール例が示されています。Foundry系ロールは旧称のAzure AI User、Azure AI Ownerなどから名称変更されているため、ポータル上で旧称と新称が混在して見える場合にも注意が必要です。(Microsoft Learn)
プライベートネットワーク環境ではDNSとPrivate Linkが落とし穴になる
閉域網やPrivate Linkを使っている環境では、アップグレード後の接続確認を必ず行うべきです。Foundryリソースでは、次の3つのFQDNに対して機能が公開されます。(Microsoft Learn)
{custom-domain}.openai.azure.com
{custom-domain}.services.ai.azure.com
{custom-domain}.cognitiveservices.azure.com既存のAzure OpenAI API呼び出しだけであれば問題が見えにくい場合でも、Foundry API、Agent Service、Content Understandingなどを使い始めた時点で名前解決やPrivate Link構成の不足が表面化することがあります。Azure DNSを使う場合は各ドメインに対応するDNSゾーンを用意し、カスタムDNSを使う場合は条件付きフォワーダーを実装します。DNS構成後は、Private Linkエンドポイントを更新、または削除して再作成する必要があります。特にservices.ai.azure.comと{custom-domain}.cognitiveservices.azure.comのIP構成を作るため、Private Linkエンドポイントの再作成が必要とされています。(Microsoft Learn)
本番展開前の検証では、単に「APIが返るか」だけでなく、次の観点で確認してください。
| テスト項目 | 確認内容 |
|---|---|
| 既存Azure OpenAI API | 既存エンドポイント、APIキー、デプロイ済みモデルで応答が返るか |
| Foundryエンドポイント | プロジェクト画面からFoundry API/SDK用エンドポイントが取得できるか |
| 名前解決 | 3つのFQDNが想定したプライベートIPへ解決されるか |
| Agent Service | エージェント作成、ツール接続、実行ログ確認ができるか |
| 監査ログ | 操作ユーザー、ロール、リソース変更が追跡できるか |
自動アップグレードが表示された場合の対応
対象となるAzure OpenAIリソースは、自動的にMicrosoft Foundryリソースへアップグレードされる場合があります。自動アップグレードの対象になったリソースでは、Azureポータルに通知が表示され、Azure Resource ManagerのリソースプロパティにfoundryAutoUpgradeブロックが含まれます。対象外の場合は、この通知やプロパティは表示されません。(Microsoft Learn)
確認手順はシンプルです。
| 手順 | 操作 |
|---|---|
| 1 | AzureポータルでAzure OpenAIリソースを開く |
| 2 | 左側ナビゲーションの「リソースのアップグレード」を確認する |
| 3 | 概要ページのJSONビューを開く |
| 4 | APIバージョン2026-01-15-previewを選択する |
| 5 | foundryAutoUpgradeのmode、scheduledAt、statusを確認する |
"foundryAutoUpgrade": {
"mode": "Enabled",
"scheduledAt": "2026-04-15T00:00:00Z",
"status": "Eligible"
}Eligibleは自動アップグレード予定、Completedは完了、DeferredByCustomerは顧客側で延期、RolledBackはFoundryへアップグレード後にAzure OpenAIへ戻した状態を示します。組織内の承認や検証が終わっていない場合は、アップグレードを延期できるため、リソースごとの状態を棚卸ししてから判断すると安全です。(Microsoft Learn)
開発者が確認すべき実装・展開上の注意点
開発者がまず確認すべきなのは、既存アプリの接続方式です。Azure OpenAI APIエンドポイントとAPIキーを使う既存処理は維持されますが、Foundry APIやSDK、Agent Service、評価ツールを使う場合は、プロジェクト、ロール、エンドポイント、認証方式が追加で関係します。アップグレード後のプロジェクト概要ページには、従来のAzure OpenAIエンドポイントと新しいFoundryエンドポイントが表示されます。(Microsoft Learn)
IaCで管理している場合は、ポータルで手動アップグレードする前にBicep、ARMテンプレート、Terraformの定義を更新する方針を決めてください。公式情報では、カスタムセキュリティ設定を持つ構成ではBicepやResource Managerテンプレートによるアップグレードが推奨されています。TerraformではAzAPIまたはAzureRMプロバイダーを使ってアップグレードでき、AzureRMを使う場合は4.57.0より大きいバージョンで非破壊更新するよう注意が示されています。(Microsoft Learn)
開発チーム向けの検証では、次の順序で進めると失敗を減らせます。
| 順序 | 検証内容 | 失敗しやすいポイント |
|---|---|---|
| 1 | 既存アプリのスモークテスト | エンドポイントは同じでも、権限やネットワーク変更の影響を見落とす |
| 2 | 既存モデルデプロイの確認 | リージョンやモデル提供状況の差を確認しない |
| 3 | Foundryプロジェクトの作成・閲覧 | プロジェクト単位のアクセス管理を理解しないまま権限を広げる |
| 4 | Agent Serviceや評価ツールの検証 | Owner/Contributorだけで開発操作までできると誤解する |
| 5 | CI/CDとIaCの再実行 | ポータル変更とテンプレート定義がずれてドリフトが発生する |
| 6 | 監査ログとコスト確認 | 新機能の利用状況や課金対象を追跡しない |
ロールバックできるが、事前準備なしでは戻しにくい
アップグレード後に問題が起きた場合、Azure OpenAIへロールバックできます。ただし、ロールバック前にFoundry固有の構成を削除する必要があります。具体的には、プロジェクト、接続、非Azure OpenAIモデルのデプロイを先に削除します。ポータル、Bicep、Terraformからロールバックできますが、すでにFoundry専用機能を使い始めているほど戻す作業は複雑になります。(Microsoft Learn)
BicepではkindをOpenAIへ戻す方向になります。Terraformでは、azurerm_cognitive_accountでkindをAIServicesからOpenAIへ戻し、allowProjectManagementをFalseに設定する流れが示されています。(Microsoft Learn)
また、リソースがすでにアップグレード済みかどうかは、Azureリソースプロパティのpreviouskind: "OpenAI"で確認できます。誰がアップグレードしたか不明な場合は、AzureポータルのアクティビティログでMicrosoft.CognitiveServices/accounts/writeの操作を確認します。変更管理上は、アップグレード実施者、実施日時、承認番号、検証結果を残しておくと、後続の監査や障害対応が楽になります。(Microsoft Learn)
よくある失敗パターン
APIキーが変わらないので影響なしと判断する
既存のAPIエンドポイントとAPIキーが維持されるため、アプリケーション側の変更が少ないのは事実です。しかし、アップグレードの本質は「利用可能な機能とモデルの範囲が広がること」です。既存アプリの接続確認だけで完了にせず、RBAC、Azure Policy、モデル利用制限、コスト管理まで確認してください。
Cognitive Services Userを広く付与したままにする
Cognitive Services Userは、アップグレード後にFoundryの広い機能へアクセスできる可能性があります。開発者全員へ一律に付与している場合は、Cognitive Services OpenAI User、Foundry系ロール、カスタムロール、Azure Policyを組み合わせて、必要最小限の権限へ整理するのが安全です。(Microsoft Learn)
Private Linkの再作成を忘れる
プライベートネットワーク環境では、既存のOpenAIエンドポイントだけを見て「接続できる」と判断しがちです。Foundryの全機能を使うには追加FQDNの名前解決とPrivate Linkエンドポイントの更新または再作成が必要です。アップグレード作業の手順書には、DNS、条件付きフォワーダー、Private Linkの確認を必ず入れてください。(Microsoft Learn)
Agent Serviceの権限をAzure管理ロールだけで考える
OwnerやContributorはAzureリソースの管理操作には強い権限ですが、Agent作成などの開発操作にはEntra IDのデータプレーンロールが必要になる場合があります。管理者ロールと開発者ロールを分けて設計し、プロジェクト単位で必要な権限を付与することが重要です。(Microsoft Learn)
導入判断の目安
Azure OpenAIをすでに業務アプリで使っている場合、Microsoft Foundryへのアップグレードは将来的なモデル選択、エージェント開発、評価・運用機能の拡張に向いています。ただし、すべての環境で即時に本番適用すべきとは限りません。
| 環境 | 推奨アプローチ |
|---|---|
| 検証環境・PoC環境 | 早めにアップグレードし、Foundryプロジェクト、Agent Service、評価機能を試す |
| 既存Azure OpenAIアプリのみの本番環境 | 既存APIの動作確認、RBAC、Policy、コスト管理を確認してから段階展開 |
| 閉域網・Private Link環境 | DNSとPrivate Link再作成の検証を先に行い、ネットワーク担当者を巻き込む |
| CMKや厳格なAzure Policyを使う環境 | 公式要件と例外申請の要否を確認し、テンプレートベースで進める |
| 複数部門がAI/Copilotを開発する環境 | プロジェクト分離、カスタムロール、モデルアクセス制御を先に設計する |
まず行うべきことは、対象のAzure OpenAIリソースを一覧化し、自動アップグレード対象かどうか、RBACとAzure Policyがどの範囲まで許可しているか、Private LinkやDNSに追加設定が必要かを確認することです。そのうえで、検証環境でアップグレード、既存APIのスモークテスト、Foundryエンドポイントの確認、ロールバック手順の確認までを一度通してから、本番環境へ展開してください。
コメント