Azure OpenAI Studioの移行先：Foundryポータルの入口と画面対応

ブックマークしていたAzure OpenAI Studioを開くと、見覚えのない画面が出てきます。2026年8月16日に https://oai.azure.com/ へアクセスしたところ、HTTP 200が返り、サーバ側のリダイレクトは0回、返ってきたHTMLのタイトルは「Microsoft Foundry」でした。ホスト名は生きたまま、中身だけが別のアプリに差し替わっています。

旧Studioの左メニューが今どこへ移ったかを対応表で示し、デプロイ・プレイグラウンド・クォータ・コンテンツフィルタの四操作を画面の階層まで追えるように整理します。

まとめ：旧Studioの画面がどこへ移り、何を先に確認すべきか

先に結論を置きます。以降の章は、この六点の根拠と具体的な操作です。

• Azure OpenAI Studioという独立した画面はすでにありません。Microsoft Learnが案内する入口は https://ai.azure.com/ の一つだけです。
• ポータルには「クラシック」と「新」の二つの実体があり、上部バナーの「New Foundry」トグルで切り替わります。手順書はどちらの前提かを先に確認してください。
• クラシックの単一左ペインは、新ポータルではホーム／ディスカバー／ビルド／オペレート／マネージ／ドキュメントの六セクションへ分割されました。
• クォータはマネージ配下、コンテンツフィルタはオペレート配下のコンプライアンスへ移動しています。
• Assistants APIは2026年8月26日に提供終了。旧Studio時代のアシスタント実装が残っているなら、画面の見た目より先にこちらへ手を付けてください。
• Foundryリソースへのアップグレードはエンドポイントとキーを保ったまま行え、ロールバックも可能。ただしプライベートエンドポイントがあるとポータルからは上げられません。

Azure OpenAI Studioが消えるまでの三度の改称と現在の入口URL

名前が三回変わりました。改称のたびにドキュメントのURLも用語も入れ替わり、検索で出てくる手順書がどの時点のものか判別しづらくなっています。

Azure AI StudioからMicrosoft Foundryへ続いた改称の順序

整理すると三段階です。Microsoft Ignite 2024（2024年11月）でAzure AI StudioがAzure AI Foundryへ改称され、このときAzure OpenAI Serviceの操作画面だったAzure OpenAI Studioがそのポータルへ統合されました。続くMicrosoft Ignite 2025（2025年11月）で、Azure AI Foundry自体がMicrosoft Foundryへ改称されています。同じ流れでAIサービス群の呼称も「Azure AI Services → Foundry Tools」へ変わりました。

実装側に効くのは、これだけ名前が変わってもAzureリソースの種類はMicrosoft.CognitiveServicesのaccountsのままだという点です。プラットフォームの概念そのものはMicrosoft Foundryが何を統合したのかを整理した記事に譲り、本記事は画面操作に絞ります。

旧ブックマークのoai.azure.comが返す画面と2026年8月の実測

旧Studioのホスト名は、まだ死んでいません。2026年8月16日にコマンドラインから https://oai.azure.com/ を取得した結果は、ステータスコード200、サーバ側リダイレクト0回、HTMLのタイトル要素は「Microsoft Foundry」でした。ホスト名を残したまま、配信されるシングルページアプリケーションがFoundryポータルへ差し替えられています。

ブックマークが壊れないので、気づかないまま新しい画面を触っている人がいます。Microsoft Learnの各手順書が示す入口は https://ai.azure.com/ で統一されており、チーム内の手順書はこちらへ書き換えるのが無難です。

クラシックと新ポータルを切り替えるNew Foundryトグルの位置

ここが混乱の最大の原因です。Foundryポータルには「Foundry (classic)」と現行の「Foundry」という二つの画面が並存し、上部バナーの「New Foundry」トグルで切り替わります。トグルは作業中のコンテキストを保持したまま表示を入れ替えます。Microsoft Learnの手順書もこの差を冒頭で宣言する書き方に変わり、クラシック側の記事には「Make sure the New Foundry toggle is off」という一文が入りました。手順どおりに操作してもメニューが見当たらないときは、まずトグルの状態を疑ってください。

もう一つ落とし穴があります。新ポータルにはFoundryプロジェクトしか表示されません。ハブベースのプロジェクトを使っている環境では、トグルをオンにした瞬間に一覧から消えます。消えたのではなく見えていないだけで、クラシックへ戻せば再び現れます。

旧Studioの左メニューが新ポータルの六セクションへ移った対応表

クラシックは単一の左ペインで、最下部に「管理センター」がありました。新ポータルは六つのトップレベルセクションに分かれ、それぞれが独自の左ペインを持ちます。

出典はMicrosoft Learn「Migrate from the Foundry (classic) portal」（ms.date 2026-06-19 / updated_at 2026-08-13）で、日本語の画面表記に寄せました。プレイグラウンドは独立した項目ではなくなり、モデルを選んだ先に統合されています。

クォータとユーザー管理がManagement centerから分かれた行き先

クラシックの「管理センター」は、クォータ・ユーザー・接続済みリソース・全リソース一覧を一箇所に集めた画面でした。新ポータルではこれが解体され、クォータは「マネージ > クォータ」、ユーザーと権限は「マネージ > プロジェクト詳細 > ユーザー」へ移っています。

注意すべきはスコープの違いです。マネージは選択中のプロジェクトとそのリソースが対象、オペレートは全プロジェクトが対象になります。コンテンツフィルタがプロジェクト単位の「ガードレール + コントロール」からオペレート配下のコンプライアンスへ移ったのも同じ理屈で、横断的な統制物として位置づけ直された、と読めます。

チャットプレイグラウンドで検証を始めるまでの画面操作と確認項目

モデルを試すには、その前にリソースとデプロイが必要です。ここを飛ばしてプレイグラウンドを開いても、選べるモデルが一つもありません。

リソース作成からデプロイ名決定までで後戻りしにくい二つの選択

リソースはAzureポータルの「リソースの作成」からAzure OpenAIを選んで作ります。作成ウィザードで後から変えにくいものが二つあります。

1. リージョン。モデルの提供状況がリージョンごとに違うため、使いたいモデルが東日本にない、という詰まり方をします。
2. ネットワークのアクセス種別。「すべてのネットワーク」「選択されたネットワーク」「無効」の三択で、無効を選ぶと後述のとおりFoundryリソースへの移行手順が変わります。

迷ったら東日本で使えるモデルを確認する手順を先に見ておくと手戻りが減ります。料金体系はAzure OpenAI Serviceの全体像を扱った記事が前提です。

デプロイの種類四つの選び分けと、TPM初期割り当てを決める基準

デプロイはクラシックポータルなら「デプロイ」から「モデルのデプロイ」「基本モデルをデプロイ」と進みます。ここで決めるデプロイ名とデプロイの種類が、後工程を左右します。

デプロイ名は、API呼び出しでモデル名の代わりに指定する識別子です。本家OpenAIのAPIはモデル名を渡しますが、Azure OpenAIはmodelパラメータにもデプロイ名を渡します。サンプルがモデル名と同一のデプロイ名を使っているのは説明の都合で、命名規則は自由です。

デプロイの種類は Standard、Global-Batch、Global-Standard、Provisioned-Managed の四つ。対話用途ならStandard系、夜間の一括処理ならGlobal-Batch、スループットを予約したいならProvisioned-Managedです。予約課金が損益分岐に乗るかは必要ユニット数の見積もり方を扱った記事で数字を詰めてください。TPMは作成時に割り当てます。1,000単位で増減でき後から編集できるので、初回は小さく置いて構いません。

プレイグラウンドの出力から本番実装のコードへ引き渡す三つの情報

プレイグラウンドは動作確認の場であって、設定の保管場所ではありません。コードへ持ち出すべきものは、システムメッセージ、生成パラメータの値、デプロイ名の三つです。

画面上の「コードの表示」から、その時点の設定を反映した呼び出しコードを取り出せます。ただし取り出したコードにはAPIバージョンが埋め込まれます。2026年8月時点のFoundryは月次のapi-version指定からv1安定ルートへ移行が進んでおり、新ポータル側ではバージョンパラメータを付けない前提。この差は動く動かないに直結するため、api-versionの固定とv1移行の判断を扱った記事で確認してから本番へ入れてください。

コンテンツフィルタの挙動確認もプレイグラウンドで行えます。フィルタでブロックされた場合、画面上部の「フィルターのフィードバック」から報告できる導線が、プロンプト送信後に有効になります。

クォータとコンテンツフィルタをポータルで設定するときの落とし穴

この二つは、画面の場所を覚えただけでは足りません。仕様の非対称や見かけと違う挙動があり、原因の切り分けを誤ります。

TPMとRPMが容量単位で連動し個別に指定できないという制約

クォータはサブスクリプション単位で、リージョン別・モデル別・デプロイ種別ごとにTPM（Tokens-per-Minute）で割り当てられます。見落とされがちなのは、TPMとRPM（Requests-per-Minute）を別々の値として指定できない点です。

両者は「容量単位」を介して比例します。Microsoft Learn（ms.date 2026-05-04）の表では、旧世代のチャットモデルは1ユニットあたり6 RPM / 1,000 TPM、o1系は1 RPM / 6,000 TPM、o3-mini系は1 RPM / 10,000 TPMと、比率がモデルごとに違いました。プログラムからデプロイを作る場合、この差を知らずにTPMだけ揃えると、RPMが意図せず十分の一になることがあります。なお、リージョンあたりのリソース上限は30、同一リソース内に同じモデルのデプロイを複数作る制限は撤廃済みです。

429が返ってもクォータ不足とは限らない四つの原因と切り分け

429を見た瞬間に増枠を申請するのは遠回りです。Microsoft Learnは原因を四つに分類しています。

• レート上限超過。割り当てたTPMやRPMを実際に超えた場合で、これだけが増枠や再配分で直る類型です。
• バックエンドの容量逼迫。一時的なもので、再試行が正解になります。
• 一時的なレート上限の引き下げ。従量課金のStandardは共有プールを使うため、需要が逼迫すると実効上限が自動で下がり、数時間で戻ります。
• リクエストパラメータによる枠の食いつぶし。レート計算はmax_tokensとbest_ofの見積もりを含むため、実際の出力が短くても枠を消費します。

切り分けの起点はレスポンスヘッダーです。x-ratelimit-limit-tokensが設定したTPMより小さければ三番目、retry-after-msが返っていれば素直に待つ、と判断できます。課金トークンのメトリックは処理済みリクエストしか数えません。

四つの危害カテゴリ四段階の既定値と、緩める側だけ承認が要る非対称

コンテンツフィルタは、暴力・憎悪・性的・自傷という四カテゴリを、安全・低・中・高の四段階で判定します。既定値はプロンプトと生成結果の双方について「中」。中と高が遮断され、低と安全は通ります。

ここに非対称があります。厳しくする方向、つまり低・中・高をすべて遮断する設定は誰でも変更可能。一方、フィルタを部分的または完全にオフにするには承認が必要で、Limited Access Reviewのフォームから申請します。しかもドキュメントには現時点で管理対象顧客になることはできないという趣旨の注記があり、実質的に緩和の道は閉じていると読むべきです。

補助フィルタの既定も把握しておきます。直接攻撃向けのプロンプトシールドと保護対象のコード・テキストの検出はオン。間接攻撃向けのプロンプトシールド、根拠性検出、個人情報の検出はオフで、後者二つはプレビュー段階です。認証やネットワークまで含めた遮断設計は社内審査で問われる設定を層ごとに整理した記事へ譲ります。

リクエスト単位で差し替えるx-policy-idと画像入力での例外

フィルタ構成はリソース単位で作り、デプロイに関連付けます。呼び出しごとに切り替える手段もあり、リクエストヘッダーのx-policy-idでカスタム構成名を指定すると、デプロイ単位の設定を上書きできます。

この上書きには例外があります。画像入力を伴うシナリオでは指定が効かず、既定のフィルタが適用されます。存在しない構成名ならInvalidContentFilterPolicyが返る仕様です。社内向けと社外向けで厳しさを変えたい要件をヘッダー一本で捌く設計は、画像を扱い始めた時点で破綻します。

ポータル操作を続けるかFoundryリソースへ上げるかの判断基準

結論から言えば、二つの条件のどちらかに当てはまるなら今すぐ上げるべきです。エージェント機能を使う予定があること、OpenAI以外のモデルを同一リソースで扱いたいこと。Responses APIとエージェントv2は新ポータル側にしかなく、Assistants APIは2026年8月26日に提供終了します。逆に、GPT系モデルでチャット補完を叩くだけの構成なら、クラシックのままでも機能は揃っており、急ぐ理由はありません。

アップグレードで保持される設定と、先に消す必要がある三つの構成

アップグレードは破壊的ではありません。Microsoft Learn（ms.date 2026-07-20）によれば、リソース名、タグ、ネットワーク構成、ID構成、APIエンドポイントとAPIキー、カスタムドメイン名、微調整ジョブやバッチの状態が、いずれもそのまま維持されます。呼び出し側のコードは無改修で動きます。

前提条件は二つ。サブスクリプションまたはリソースグループに対するOwnerロールと、対象リソースでのマネージドIDの有効化です。テンプレートならkindをOpenAIからAIServicesへ変え、allowProjectManagementを真にします。ロールバック時に先へ消すものは三種類、プロジェクト、接続、Azure OpenAI以外のモデルデプロイです。過去に上げたかどうかは、リソースのプロパティにpreviousKindが現れるかで判別できます。

プライベートエンドポイントを使う環境で移行を先送りにすべき条件

ここは言い切ります。既存のプライベートエンドポイントがあり、かつ通信断を許容できない本番環境なら、ポータルからのアップグレードは選んではいけません。

理由は仕様です。プライベートエンドポイントを持つリソースは、FoundryポータルからもAzureポータルからもアップグレードできません。削除してから上げ、あとで作り直すことになります。さらにFoundryリソースは openai.azure.com、services.ai.azure.com、cognitiveservices.azure.com の三つのFQDNで機能を公開するため、DNSゾーンまたは条件付きフォワーダーを三系統ぶん用意しないと全機能が使えません。

この条件下で移行するなら、ポータルではなくBicepまたはTerraformで実施します。同じ構成を二回以上作る場合や、Azure Policyで構成に制約がかかっている場合も同様で、Policy違反で弾かれるケースはテンプレート側でしか回避できません。Terraformを使うならAzureRMプロバイダーで4.57.0より新しいCLIクライアントが必要です。古いと、適用時にリソースが作り直される破壊的な更新になります。

カスタマーマネージドキーで暗号化しているリソースは申請ベースでしか上げられず、Weights & Biasesの構成はFoundryリソース側で非対応。いずれかに該当するなら、移行の判断そのものを次期の計画へ送るのが妥当です。

移行と検証を外部へ委託するときの作業分担と受け入れ時の確認項目

画面が変わっただけに見えて、実際の作業はリソース種別の変更、DNS、RBAC、SDKのバージョン整合、Responses APIへの書き換えまで広がります。手が足りないなら、設計と切り替え手順の作成だけを外部へ出す分け方が現実的です。生成AI開発・AI受託開発では、この種の移行設計から本番切り替えまでを引き受けています。

受け入れ時に見る項目は四つ。既存のキーで従来の呼び出しが通ること、三つのFQDNが名前解決できること、RBACのワイルドカード割り当てがFoundry専用機能まで開けていないこと、ロールバック手順が文書化されていることです。

よくある質問

旧Studioからの移行でよく検索される五つの疑問に答えます。

Azure OpenAI Studioは今も使えますか？

Azure OpenAI Studioという名前の独立した画面は、2026年8月時点で存在しません。機能はMicrosoft Foundryポータルへ統合され、クラシック側の画面が旧Studioに近い構成を保っています。上部バナーの「New Foundry」トグルをオフにすると、デプロイやプレイグラウンドが単一の左ペインに並ぶ従来型の表示に戻ります。

oai.azure.comのブックマークはそのままで大丈夫ですか？

2026年8月16日に実測した限り、https://oai.azure.com/ はHTTP 200を返し、タイトルが「Microsoft Foundry」のアプリを配信します。当面は開けますが、Microsoft Learnが案内する入口は https://ai.azure.com/ に統一されました。ホスト名の維持は恒久保証されたものではないため、書き換えておくのが安全です。

Foundryリソースへのアップグレードは元に戻せますか？

戻せます。ただし条件があり、アップグレード後に作成したプロジェクト、接続、Azure OpenAI以外のモデルデプロイを先に削除する必要があります。削除後、Foundryクラシックポータルの管理センター、Azureポータルのリソース概要、またはARMテンプレートからロールバックを実行してください。新機能を使い込むほど戻しにくくなります。

クォータの上限はどこから引き上げ申請しますか？

ポータルのクォータ画面に申請フォームへの導線があります。クラシックなら管理センターのクォータ、新ポータルならマネージ配下のクォータで、「クォータの要求」から申請してください。申請は受付順に処理され、既存の割り当てを実際に使っている利用者が優先されます。枠を確保したまま使っていない状態での申請は却下されることがあるため、先に既存デプロイのTPM再配分を試してください。

コンテンツフィルタを完全に外すことはできますか？

実質的にはできないと考えてください。しきい値を厳しくする方向の変更は誰でも行えますが、フィルタを部分的または完全にオフにするには承認が必要です。承認はLimited Access Reviewのフォームから申請するものの、ドキュメントには現時点で管理対象顧客になることはできないという趣旨の注記があります。業務要件と衝突する場合は、プロンプト設計や入力の前処理で回避する方向で設計してください。

関連記事

• Azure AI Foundryとは何か？概要と基本的なコンセプトを解説：プラットフォームの概念を押さえたいとき。
• Azure AI Studio（現Foundry）の導入事例を企業別に整理した記事：他社がどう使っているかを知りたいとき。
• Azure OpenAI Serviceのモデル一覧と選び方：どのモデルを選ぶか決めきれないとき。
• Azure OpenAIのリージョン選定と東日本で使えるモデル：リージョン選択で迷ったとき。
• Azure OpenAIのセキュリティ設計と社内審査で問われる設定：遮断・認証まで固めたいとき。