Azure AI Foundryのclassic portalからMicrosoft Foundryへ移行する場合、最初に確認すべき結論は「画面の呼び名が変わる」だけではありません。用語、リソース構成、SDK、エージェントAPI、ポータル導線、RBAC、リージョン対応をまとめて見直す必要があります。特にazure-ai-inferenceを使っているアプリ、Assistants APIで作ったエージェント、Hubベースのプロジェクト、Azure OpenAIリソースを運用している環境は、移行計画を早めに作るべきです。Microsoftの公式移行ガイドでは、classicの用語・機能・SDK・ポータル画面を、現在のMicrosoft Foundry相当へ対応付けて移行する方針が示されています。(Microsoft Learn)
2026年5月時点で特に重要なのは、azure-ai-inferenceパッケージが2026年5月30日にリタイア予定であること、Assistants APIが2026年8月26日に終了予定であることです。どちらもコード変更を伴う可能性が高いため、管理者はリソース・権限・リージョンを、開発者はSDK・エンドポイント・API呼び出しを分けて棚卸ししてください。(Microsoft Learn)
まず押さえるべき変更点
Azure AI Foundryのclassic portalから現在のMicrosoft Foundryへ移行する際の中心は、次の5つです。
| 確認領域 | 何が変わるか | 実務での影響 |
|---|---|---|
| 名称 | Azure AI Studio / Azure AI FoundryからMicrosoft Foundryへ整理 | 公式ドキュメントや画面名が混在しやすい。社内手順書の表記を統一する |
| リソース構成 | Azure OpenAI + Hub中心から、Foundry resourceとFoundry project中心へ | プロジェクト単位のアクセス管理、接続、開発ワークフローを見直す |
| API | Assistants APIからResponses API / Agents v2へ | Threads、Messages、Runs前提のコードは移行が必要 |
| SDK | azure-ai-inferenceや旧azure-ai-projectsから、openaiとazure-ai-projects 2.x中心へ | requirements、lockfile、CI、サンプルコードの更新が必要 |
| ポータル導線 | Management Center中心のclassic構成から、Home / Discover / Build / Operate / Docsへ | 管理者・開発者向けの操作手順を更新する |
Microsoft Foundryでは、プラットフォーム名がAzure AI Studio、Azure AI Foundry、Microsoft Foundryへと変化してきました。一方で、Azure上のリソースタイプは引き続きMicrosoft.CognitiveServices/accountsであり、現在のFoundry resourceはAIServices kindと子プロジェクトを中心に構成されます。名称変更だけを追うのではなく、リソースモデルとAPIの変更まで含めて確認することが重要です。(Microsoft Learn)
影響を受ける対象者
今回の移行で影響を受けるのは、開発者だけではありません。Azure AI Foundryを社内基盤として使っている場合、管理者、開発者、インフラ担当、セキュリティ担当がそれぞれ確認すべき項目があります。
| 対象者 | 主な確認ポイント | 具体的にやること |
|---|---|---|
| Azure管理者 / プラットフォーム担当 | RBAC、プロジェクト、リージョン、クォータ、監査 | Foundry User、Foundry Project Manager、Foundry Ownerなどの割り当てを確認する |
| 開発者 | SDK、API、エンドポイント、エージェント実装 | azure-ai-inference、Assistants API、azure-ai-projects 1.xの利用有無を確認する |
| インフラ / IaC担当 | Bicep、Terraform、Managed Identity、Private Link | kind: OpenAIからkind: AIServicesへの変更やDNS構成を確認する |
| セキュリティ担当 | Entra ID、APIキー、カスタムロール、ポリシー | APIキー依存を減らし、Entra IDとRBAC中心の運用へ寄せる |
| 業務アプリ責任者 | 本番影響、移行期限、フォールバック | classic portalで継続すべき機能と、新ポータルへ移す機能を分ける |
特に注意したいのは、AzureのOwnerやContributorだけでは、Foundry上の開発操作がすべて可能になるとは限らない点です。Foundryでは管理プレーンとデータプレーンの権限を分けて考える必要があり、開発やエージェント作成にはFoundry向けのRBACロールが必要になる場合があります。(Microsoft Learn)
移行の優先順位は期限と依存機能で決める
すべてを一度に移行しようとすると、影響範囲が広がりすぎます。まずは期限が明示されているもの、次に新ポータルで見えないもの、最後にプレビュー機能への依存を確認する順番が現実的です。
| 優先度 | 対象 | 判断基準 | 今すぐ確認すること |
|---|---|---|---|
| 高 | azure-ai-inference利用アプリ | 2026年5月30日にリタイア予定 | requirements.txt、pyproject.toml、package-lock.json、CIログを検索 |
| 高 | Assistants API利用エージェント | 2026年8月26日に終了予定 | Threads、Runs、Assistantsを使うコードを洗い出す |
| 高 | 本番エージェント | Responses API対応リージョンか | Foundry resourceのリージョンとモデル対応を確認 |
| 中 | Hubベースのプロジェクト | 新しいFoundry portalでは表示されない | classic portalで継続するか、Foundry projectsへ移行するか決める |
| 中 | Azure OpenAIリソース | Foundry機能を使う予定があるか | Foundry resourceへのアップグレード可否、Managed Identity、RBACを確認 |
| 中 | プレビュー機能 | 本番利用しているか | GA / Previewラベルを確認し、非本番扱いにするか判断 |
公式ガイドでは、移行手順として「用語変更の確認」「機能比較」「SDK更新」「Assistants APIからResponses APIへの移行」「Responses API対応リージョンの確認」「新ポータルでの検証」が示されています。この順番は、そのまま社内の移行チェックリストとして使えます。(Microsoft Learn)
用語と概念の対応関係
classic portalの用語をそのまま使い続けると、現在のドキュメントやSDKサンプルと合わなくなります。移行前に、チーム内で次の対応表を共有しておくと混乱を減らせます。
| classic側の概念 | 現在のMicrosoft Foundryでの対応 | 注意点 |
|---|---|---|
| Foundry classic portal | Foundry portal | バナーのNew Foundryトグルで切り替え可能 |
| Management Center | Operateセクション | 管理、クォータ、コンプライアンス、トレースがOperate側へ整理 |
| Azure OpenAI + Hub | Foundry resource | 単一のAIServices kindと子プロジェクト中心 |
| Azure AI Services | Foundry Tools | Speech、Vision、Language、Content Safetyなどを含む |
| Model-as-a-Service | Foundry Direct Models | Azureメーターによる直接課金モデルとして整理 |
| Assistants API | Responses API | 2026年8月26日の終了予定に向けて移行が必要 |
| Threads | Conversations | メッセージだけでなく、ツール呼び出しや出力も扱う |
| Messages | Items | ItemsはMessagesの上位概念 |
| Runs | Responses | 通常は同期的に扱えるが、background modeでは別途状態確認が必要 |
| Assistants / Agents | Agent Versions | create_agent()ではなくcreate_version()中心へ |
| 複数の個別エンドポイント | Project endpoint + OpenAI v1 endpoint | 環境変数や接続文字列の整理が必要 |
Responses APIは、Chat CompletionsとAssistants APIの機能を統合する位置付けで、statefulな複数ターン応答を扱えます。移行時は「入力と出力の形が少し変わる」だけでなく、会話状態、ツール呼び出し、エージェント定義の持ち方が変わる点を確認してください。(Microsoft Learn)
SDK移行で確認すべきこと
開発者が最も早く確認すべきなのは、利用中のSDKです。ポータルを切り替えるだけなら一見動いているように見えても、古いSDKと新しいポータル体験のサンプルを混ぜると、認証エラー、エンドポイントエラー、予期しないAPI動作が起きやすくなります。
| 現在確認すべきもの | 移行先・推奨方向 | 実務上の確認 |
|---|---|---|
azure-ai-inference | openai | リタイア予定が近いため最優先で置き換える |
AzureOpenAI() | OpenAI() + base_url | Azure固有クライアント前提のコードを見直す |
azure-ai-projects 1.x | azure-ai-projects 2.x | classic向けサンプルと新ポータル向けサンプルを混在させない |
azure-ai-generative | azure-ai-projects 2.x | project client側へ機能が統合されているか確認 |
Hub移行でのazure-ai-ml依存 | azure-ai-projects 2.x中心 | HubベースからFoundry projectsへ移す範囲を決める |
| 評価機能 | azure-ai-projects + azure-ai-evaluation | remote評価とlocal評価の使い分けを確認 |
公式ドキュメントでは、azure-ai-inferenceからOpenAI SDKへ移行することで、Azure OpenAIとFoundry Modelsの両方で統一されたAPIパターンを使いやすくなると説明されています。APIバージョン指定についても、OpenAI v1 APIでは従来の月次api-versionパラメータ更新の負担が減ります。(Microsoft Learn)
SDK移行で失敗しやすいポイント
よくある失敗は、次の3つです。
| 失敗パターン | 原因 | 対策 |
|---|---|---|
| 新しいサンプルを貼ったら動かない | SDKが1.xのまま | azure-ai-projects 2.x前提か確認する |
| エンドポイント接続に失敗する | 旧来の複数エンドポイントを使い続けている | Project endpointまたはOpenAI v1 endpointを環境変数に整理する |
| 認証エラーが出る | APIキーとEntra IDの使い方を混同 | 本番はEntra ID + RBACを基本にし、APIキーは用途を限定する |
MicrosoftのRBACドキュメントでは、APIキー認証はロール制限なしの広いアクセスになるため、粒度の細かいアクセス制御にはMicrosoft Entra ID認証が推奨されています。運用環境では、SDK移行と同時に認証方式も見直すのが安全です。(Microsoft Learn)
Assistants APIからResponses API / Agents v2への移行
Assistants APIを使っている場合は、単純なメソッド名の置換では不十分です。classic側のThreads、Messages、Runsは、現在のFoundryではConversations、Items、Responsesへ考え方が変わります。
| classic側 | 現在の対応 | 移行時の確認 |
|---|---|---|
| Threadにメッセージを保存 | ConversationにItemsを保存 | メッセージ以外のツール呼び出しや出力をどう保持するか確認 |
| Runを作成してポーリング | Responseを作成 | 通常応答とbackground modeを分けて実装 |
| Assistant / Agent作成 | Agent version作成 | PromptAgentDefinitionなど定義方式を確認 |
create_agent() | create_version() | バージョン管理と公開フローを設計 |
| Assistants API endpoint | Responses API endpoint | 404やMethodNotAllowedが出る場合はAPI先を確認 |
Foundry Agent Serviceの移行ガイドでは、Assistants APIからAgentsへの移行を支援するmigration toolが用意されているとされています。ただし、ツール構成、会話状態、権限、リージョン、ストレージ構成まで自動的に業務要件へ最適化されるわけではありません。既存エージェントを棚卸しし、「作り直す」「移行ツールを使う」「classic portalで一時継続する」を分けて判断してください。(Microsoft Learn)
エージェント移行で先に見るべきチェック項目
エージェント移行では、次の順番で確認すると手戻りを減らせます。
| 順番 | 確認項目 | 判断基準 |
|---|---|---|
| 1 | 利用API | Assistants API、Threads、Runsを使っているか |
| 2 | 利用ツール | File Search、Code Interpreter、Web Search、Azure Functionsなどの依存 |
| 3 | 会話状態 | メッセージ履歴、ファイル、ツール出力をどこに保持しているか |
| 4 | リージョン | Responses APIとFoundry Agent Serviceが対象リージョンで使えるか |
| 5 | 権限 | 実行ユーザー、サービスプリンシパル、マネージドIDに必要ロールがあるか |
| 6 | 公開先 | Microsoft 365、Teams、個別エンドポイントへの公開有無 |
新しいAgent Serviceでは、Web Search、File Search、Code Interpreter、MCP tool callingなどの機能が整理されています。一方で、classic側で使っていたツールが同じ形で使えるとは限らないため、機能名だけでなく「自社の業務フローで何をしているか」を基準に移行可否を判断してください。(Microsoft Learn)
リージョン対応は移行前に必ず確認する
Responses APIとFoundry Agent Serviceは、すべてのAzureリージョンで利用できるわけではありません。公式のResponses APIドキュメントでは、対応リージョンにjapaneastが含まれていますが、Responses API対応リージョン内でもすべてのモデルが使えるとは限らないと説明されています。日本向け環境では「Japan Eastだから大丈夫」と決め打ちせず、使うモデル、API、Agent機能をセットで確認してください。(Microsoft Learn)
実務では、次のように確認します。
| 確認対象 | 確認方法 | 注意点 |
|---|---|---|
| Foundry resourceのリージョン | Azure portalまたはFoundry portalで確認 | 既存リソースの移動は簡単ではないため初期判断が重要 |
| Responses API対応 | 公式のRegion Availabilityを確認 | 対応リージョンでもモデルごとの差がある |
| モデルの利用可否 | Model catalogまたはモデル別のリージョン表を確認 | 本番で使うモデル名とデプロイ名を明記する |
| Agent機能 | Foundry Agent Serviceの対応状況を確認 | エージェント、ツール、ストレージ構成まで見る |
| フォールバック | classic portalまたは別リージョンの利用可否を確認 | 本番切替前に戻し先を決める |
リージョンが非対応の場合、現在のFoundry portalでエージェントを作成・実行できない可能性があります。この場合は、対応リージョンに新しいFoundry resourceを作成する選択肢を検討します。(Microsoft Learn)
Azure OpenAIリソースを使っている場合の注意点
既存のAzure OpenAIリソースをFoundry resourceへアップグレードする場合、公式ドキュメントでは、既存のAzure OpenAI APIエンドポイント、APIキー、作業状態、セキュリティ構成を保持したまま移行できると説明されています。新しいFoundry resourceを必ず別途作成しなければならない、というわけではありません。(Microsoft Learn)
ただし、アップグレード前に次の点を確認してください。
| 確認項目 | 内容 |
|---|---|
| Managed Identity | Azure OpenAIリソースでシステム割り当てマネージドIDを有効化できるか |
| RBAC | アップグレード、プロジェクト作成、ロール割り当てに必要な権限があるか |
| Azure Policy | AIServices kindへの変更やネットワーク設定がポリシーでブロックされないか |
| Private Link / DNS | openai.azure.comだけでなく、services.ai.azure.comやcognitiveservices.azure.comの名前解決が必要か |
| CMK | 顧客管理キー利用環境は通常のアップグレードで対応できるか |
| ロールの広がり | 既存のCognitive Services系ロールがFoundry機能まで広がらないか |
特にPrivate Linkを使っている環境では、Foundry resourceが複数のFQDNを使う点に注意が必要です。公式ドキュメントでは、Foundry resourceは{custom-domain}.openai.azure.com、{custom-domain}.services.ai.azure.com、{custom-domain}.cognitiveservices.azure.comを使うとされ、アップグレード時には追加のDNSゾーン設定やPrivate Link endpointの再作成が必要になる場合があります。(Microsoft Learn)
Hubベースのプロジェクトは新ポータルで見えない点に注意
Hubベースのプロジェクトを使っている場合、新しいFoundry portalに切り替えると見えないことがあります。公式移行ガイドでは、現在のポータルはFoundry projectsのみを表示し、Hubベースのプロジェクトへアクセスする必要がある場合はclassic portalへ戻す、またはFoundry projectsへ移行する必要があると説明されています。(Microsoft Learn)
HubベースからFoundry projectsへ移行する場合、公式ドキュメントでは、新しいFoundry projectを作成し、必要に応じてエージェントや接続を移行する流れが示されています。移行対象としては、model deployments、data files、fine-tuned models、assistants、vector storesが挙げられています。一方で、Preview Agentの状態、open-source model deployments、Hub project accessは移行対象外として扱われます。(Microsoft Learn)
Hub移行で実務上やること
| 作業 | 具体的な確認 |
|---|---|
| 既存Foundry resourceを探す | classic portalのManagement center、Azure portal、IaC定義で確認 |
| 新しいFoundry projectを作る | 用途別、チーム別、接続要件別に分ける |
| 接続を再作成する | ツール、データソース、モデル接続をFoundry resourceまたはprojectへ作成 |
| エージェントを移す | API、ツール、会話状態、ストレージを確認 |
| 権限を再割り当てする | ユーザーとproject managed identityにFoundry Userなどを付与 |
| classic継続範囲を決める | 未対応機能や移行待ち業務の退避先を明文化する |
Hubベースの接続を移す場合、Azure portalだけでは接続を追加できず、Foundry portalまたはBicepテンプレートを使う必要がある点にも注意してください。(Microsoft Learn)
RBACと認証の見直し
Foundryでは、ロール名の変更も移行時の混乱要因になります。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と基本権限は変わらないと説明されています。(Microsoft Learn)
| ロール | 主な用途 | 実務上の使い方 |
|---|---|---|
| Foundry User | Foundry projectでの開発、データアクション | 開発者やproject managed identityの基本ロール |
| Foundry Project Manager | project管理、開発、Foundry Userの条件付き割り当て | チームリードやプロジェクト管理者 |
| Foundry Account Owner | リソース、プロジェクト、接続、監査などの管理 | プラットフォーム管理者 |
| Foundry Owner | 管理と開発の広い権限 | 高権限のため付与対象を限定 |
| Azure Owner | Azureスコープでのロール割り当てや管理 | 初期セットアップやアップグレード作業 |
自動化スクリプトやIaCでロール名を直接指定している場合は、ロール名の変更タイミングで失敗する可能性があります。公式ドキュメントでは、ロール名ではなくロール定義IDを使うことが推奨されています。(Microsoft Learn)
APIキーに頼りすぎない
APIキーは実装が簡単ですが、RBACのような細かい権限制御を提供しません。運用環境では、ユーザー、アプリ、エージェント、project managed identityごとに、Entra IDとRBACで権限を設計する方が安全です。特に、エージェントがAzure AI Search、Storage、Key Vault、データベースなど外部リソースへアクセスする場合は、Foundry側のロールだけでなく、接続先リソース側のデータプレーン権限も確認してください。(Microsoft Learn)
ポータル導線の変更
classic portalでは左ペインに多くの機能がまとまっていましたが、現在のFoundry portalでは、Home、Discover、Build、Operate、Docsの5つの上位セクションに整理されています。管理作業はOperate、開発作業はBuild、モデル探索はDiscoverに分かれると理解すると迷いにくくなります。(Microsoft Learn)
| やりたいこと | classic portalでの場所 | 現在のFoundry portalでの場所 |
|---|---|---|
| モデルデプロイを見る | Models + endpoints | Build > Models |
| Playgroundを開く | Playgrounds | Build > Models > モデルを選択 |
| Agentsを作る | Agents | Build > Agents |
| モデルカタログを見る | Model catalog | Discover > Model catalog |
| Evaluationsを見る | Evaluation | Build > Evaluations |
| Fine-tuningを使う | Fine-tuning | Build > Fine-tuning |
| Tracing / Monitoringを見る | Tracing | Operate > Tracing |
| クォータを管理する | Management Center > Quota | Operate > Quota |
| ユーザーと権限を管理する | Management Center > Users | Operate > Admin |
| 全プロジェクトやリソースを見る | Management Center > All resources | Operate > Admin |
| 接続リソースを見る | Management Center > Connected resources | Operate > Admin > projectを選択 |
| Guardrails / content filtersを見る | Guardrails + controls | Operate > Compliance |
ポータル切り替えは、上部バナーのNew Foundryトグルから行えます。切り替え時には現在のprojectなどのコンテキストが保持されるとされていますが、Hubベースのプロジェクトや未対応リソースにアクセスする必要がある場合は、classic portalへ戻す運用を残しておくと安全です。(Microsoft Learn)
新ポータルで使える機能とclassicに残る機能
新しいMicrosoft Foundry portalはGAになっていますが、すべての機能がGAという意味ではありません。公式GA概要では、コアシナリオは本番利用向けにサポートされる一方、一部機能はPreviewのまま、また一部はclassic portalが必要とされています。(Microsoft Learn)
| 区分 | 例 | 判断ポイント |
|---|---|---|
| 両方で利用可能 | Foundry projects、Chat completions、Fine-tuning、Evaluations、Model catalog | 現行ポータルで拡張されている機能もある |
| 新ポータル中心 | Responses API、Agents v2、Tool catalog、Microsoft 365 / TeamsへのAgent publishing | GAとPreviewが混在するためラベル確認が必要 |
| classic継続が必要な場合あり | Hub-based projects、standalone Azure OpenAI、既存Assistantsの作成・編集 | 無理に新ポータルへ一本化しない |
| Preview注意 | Multi-agent workflows、Agent memory、Hosted agents、A2A protocolなど | 本番依存にする前に社内承認と代替策を用意 |
GA概要では、Preview機能を本番依存として扱うこと、リージョン可用性の検証を省略すること、AssistantsやAzure OpenAIワークフローのフォールバック経路を用意せずに移行することが、よくある落とし穴として挙げられています。(Microsoft Learn)
実務で使える移行手順
Azure AI Foundryの移行は、次の流れで進めると安全です。
| 手順 | 作業 | 成果物 |
|---|---|---|
| 1 | 現状棚卸し | リソース一覧、プロジェクト一覧、SDK一覧、エージェント一覧 |
| 2 | 移行対象の分類 | すぐ移行、classic継続、廃止、再構築の分類表 |
| 3 | リージョンと機能確認 | Responses API、モデル、Agent機能の対応表 |
| 4 | 権限設計 | ユーザー、グループ、サービスプリンシパル、managed identityのRBAC表 |
| 5 | SDK更新 | openai、azure-ai-projects 2.xへの移行ブランチ |
| 6 | エージェント移行 | Assistants APIからResponses API / Agents v2への実装変更 |
| 7 | ネットワーク確認 | DNS、Private Link、Firewall、Azure Policyの確認結果 |
| 8 | 検証 | 開発環境での呼び出し、認証、監視、コスト、監査ログ確認 |
| 9 | 本番切替 | 段階的リリース、ロールバック手順、classic fallbackの明文化 |
| 10 | 手順書更新 | 新ポータル導線、トラブル対応、運用ルールの反映 |
最初から全機能を新ポータルへ寄せる必要はありません。公式GA概要でも、まだ新ポータルで利用できないシナリオではFoundry classic portalを継続利用できるとされています。重要なのは、classic継続を「なんとなく」残すのではなく、対象機能、期限、責任者、移行条件を明文化することです。(Microsoft Learn)
よくあるトラブルと対処法
移行時に発生しやすいエラーは、原因がある程度決まっています。切り分け表を先に用意しておくと、検証時の混乱を減らせます。
| 症状 | 主な原因 | 対処 |
|---|---|---|
ModuleNotFoundErrorが出る | SDKバージョンが移行先と合っていない | azure-ai-projects 2.xやopenaiのバージョンを確認 |
| 新ポータルにプロジェクトが表示されない | Hubベースのプロジェクトは表示対象外 | classic portalへ戻すかFoundry projectsへ移行 |
| エンドポイント接続に失敗する | 旧来の複数エンドポイントを使っている | Project endpointとOpenAI v1 endpointを再設定 |
AuthenticationErrorが出る | APIキー、Bearer token、スコープの使い方が混在 | Entra ID認証とトークンスコープを確認 |
| Agentコードで404やMethodNotAllowedが出る | Assistants API呼び出しをResponses API endpointへ送っている | Responses API向けにコードを書き換える |
| Agentsが新ポータルで使えない | Foundry resourceのリージョンが未対応 | 対応リージョンにFoundry resourceを作成する |
| OwnerなのにAgentを作れない | Azure管理権限とFoundryデータプレーン権限を混同 | Foundry User、Foundry Project Manager、Foundry Ownerを確認 |
| Private network経由で接続できない | Foundry向けFQDNやPrivate Link構成が不足 | DNSゾーンとPrivate Link endpointを見直す |
公式移行ガイドでも、SDK不一致、Hubベースプロジェクトの非表示、旧エンドポイント、認証、Assistants APIとResponses APIの混在、リージョン非対応が代表的な移行トラブルとして挙げられています。(Microsoft Learn)
管理者と開発者が今日やるべきこと
移行作業を始めるなら、まず次の5つを確認してください。
1つ目は、コードベース内でazure-ai-inference、AzureOpenAI()、azure-ai-projects 1.x、Assistants API、Threads、Runsを検索することです。該当箇所が多いほど、SDKとAPIの移行を優先する必要があります。
2つ目は、Azure上のリソースがOpenAI kindなのか、AIServices kindなのか、Hubベースのプロジェクトなのかを分類することです。移行ルートはこの分類で大きく変わります。
3つ目は、Responses APIとAgent機能が現在のリージョンで利用できるかを確認することです。日本向け環境でjapaneastを使っていても、モデルごとの対応は別途確認してください。
4つ目は、RBACと認証方式を見直すことです。APIキー中心の運用は手軽ですが、Foundry移行後の権限管理ではEntra IDとRBACの設計がより重要になります。
5つ目は、新ポータルでの導線を実際に検証し、社内手順書を更新することです。管理はOperate、開発はBuild、モデル探索はDiscoverという整理に合わせて、運用チームと開発チームの手順を分けておくと移行後の問い合わせを減らせます。
Azure AI FoundryからMicrosoft Foundryへの移行は、単なる画面変更ではなく、AIアプリ開発基盤の作り替えに近い変更です。まずはSDK、Assistants API、Hubベースプロジェクト、RBAC、リージョンの5点を棚卸しし、期限が明示されているものから順に移行してください。
コメント