Azure AI Foundry REST APIを調べている人が最初に押さえるべきポイントは、「AIアプリやエージェントを呼び出すAPI」と「Azureリソースを管理するAPI」を分けて考えることです。2026年5月末の公式情報では、Microsoft Foundryへの名称・構成整理、Responses API／Agents v2への移行、単一プロジェクトエンドポイントの利用、SDKと認証方式の見直しが重要になっています。特に、旧Azure AI StudioやAzure AI Foundryのサンプルをそのまま使っている環境では、エンドポイント、APIバージョン、SDK、RBAC、リージョン対応を早めに確認する必要があります。(Microsoft Learn)
この記事では、Azure AI Foundry REST APIの変更点を、管理者・開発者が実務で確認しやすい形に整理します。単なる機能紹介ではなく、「既存コードにどこが影響するのか」「移行時にどこで失敗しやすいのか」「本番展開前に何をチェックすべきか」まで具体的に解説します。
Azure AI Foundry REST APIで何が変わるのか
Azure AI Foundry REST APIの理解で混乱しやすいのは、名称とAPI体系が同時に整理されている点です。公式ドキュメントでは、MicrosoftのAIプラットフォームは「Azure AI Studio」「Azure AI Foundry」を経て、現在は「Microsoft Foundry」という名称で説明されています。一方で、Azureリソースの型は引き続きMicrosoft.CognitiveServices/accountsが使われます。つまり、画面上の名称やドキュメント表記は変わっていても、Azure Resource Manager上の管理対象が完全に別物になったわけではありません。(Microsoft Learn)
実務上の大きな変化は、次の4つです。
| 変更点 | これまでの考え方 | 現在確認すべき考え方 |
|---|---|---|
| ブランド・ポータル | Azure AI Studio / Azure AI Foundry中心 | Microsoft Foundryとして統合的に説明される |
| APIの中心 | Assistants APIや月次api-version付きAPIを個別に扱う | Responses API、Agents v2、v1 stable routesを前提に整理する |
| エンドポイント | Azure OpenAI、Azure ML、Cognitive Servicesなど複数エンドポイントを意識 | Foundryプロジェクトエンドポイントを中心に構成する |
| SDK | azure-ai-inferenceや旧azure-ai-projectsなどを用途別に利用 | openaiパッケージやazure-ai-projects 2.xへの移行を検討する |
公式の移行ガイドでは、APIバージョニングについて「月次api-versionパラメータ」から「v1 stable routes」への整理、APIワイヤープロトコルについて「Assistants API」から「Responses API」への移行が示されています。また、単一のプロジェクトエンドポイントとOpenAI v1エンドポイントを使う方向に整理されています。(Microsoft Learn)
REST APIは「管理プレーン」と「データプレーン」に分けて見る
Azure AI Foundry REST APIを扱うときは、まずAPIの役割を分けることが重要です。ここを混同すると、api-versionの付け方、認証スコープ、エンドポイント形式、RBACの確認箇所を間違えやすくなります。
| 区分 | 主な用途 | エンドポイントの考え方 | 代表的な確認項目 |
|---|---|---|---|
| 管理プレーン | リソース、プロジェクト、デプロイ、接続、利用量、モデル一覧の管理 | https://management.azure.com/... | サブスクリプション、リソースグループ、アカウント名、api-version |
| データプレーン | モデル呼び出し、Responses API、エージェント操作、アプリからの実行 | Foundryプロジェクトエンドポイント | 認証トークン、プロジェクト名、モデル名、エージェント定義 |
たとえば、プロジェクト作成の管理APIはmanagement.azure.com配下で、Microsoft.CognitiveServices/accounts/{accountName}/projects/{projectName}を操作します。公式リファレンスでは、AI FoundryのProjects APIはAPI Version 2025-06-01として示され、プロジェクトはCognitive Servicesアカウントのサブリソースとして説明されています。(Microsoft Learn)
一方、エージェント操作などのプロジェクト側REST APIでは、Foundry Project endpointとしてhttps://{ai-services-account-name}.services.ai.azure.com/api/projects/{project-name}の形式が示されています。プロジェクトが1つだけの場合や既定プロジェクトを対象にする場合は、_projectを使う形式も提示されています。 (Microsoft Learn)
2026年5月末の更新で管理者が特に見るべき影響範囲
Azure AI Foundry REST APIの更新は、単に開発者のコードだけに影響するものではありません。Azure管理者、セキュリティ担当、DevOps担当、AIアプリの運用担当にも確認ポイントがあります。
旧ポータル・旧名称を前提にした運用手順は見直す
公式移行ガイドでは、製品名称がAzure AI StudioからAzure AI Foundry、さらにMicrosoft Foundryへ進化したこと、またAzure Cognitive ServicesからFoundry Toolsへの整理が説明されています。ただし、Azureリソース型はMicrosoft.CognitiveServices/accountsのままです。(Microsoft Learn)
このため、社内ドキュメントでは次のような表記ゆれが起きやすくなります。
| 社内で見かける表記 | 現在の確認観点 |
|---|---|
| Azure AI Studio | 旧ポータルやクラシック体験を指している可能性がある |
| Azure AI Foundry | 現在のMicrosoft Foundry文脈と混在している可能性がある |
| Azure OpenAIリソース | Foundryリソースへのアップグレード対象か確認する |
| Hub / Project | 現在のFoundry ProjectとクラシックのHubベースプロジェクトを区別する |
特に運用手順書、障害対応手順、IaCテンプレート、CI/CDパイプライン、監査資料では、画面名称だけでなく「実際にどのリソースIDを操作しているか」を確認する必要があります。
RBACロール名の変更に注意する
移行ガイドでは、Foundry User、Foundry Owner、Foundry Account Owner、Foundry Project Managerといったロール名が、以前のAzure AI系ロール名から変更されたことが説明されています。一方で、ロールIDとコア権限は変更されていないとされています。(Microsoft Learn)
管理者が確認すべきなのは、ロール名の見た目だけではありません。
| 確認項目 | 見るべきポイント |
|---|---|
| 既存の権限付与 | ユーザー、グループ、マネージドID、サービスプリンシパルに必要最小権限が付いているか |
| CI/CD用ID | 本番環境のデプロイやモデル管理に必要な操作だけを許可しているか |
| 監査ログ | 旧ロール名と新ロール名が混在しても追跡できるか |
| 社内申請フロー | 「Azure AI User」など旧名称の申請項目が残っていないか |
ロール名の変更を「表示上の変更」とだけ捉えると、問い合わせ対応や権限申請で混乱します。社内の権限管理表には、旧名称と新名称の対応表を残しておくと実務で役立ちます。
リージョン対応は移行前に必ず確認する
Responses APIとFoundry Agent Serviceは、すべてのAzureリージョンで利用できるわけではありません。公式移行ガイドでは、移行前にリージョン対応を確認し、対応していないリージョンでは現在のFoundryポータルでエージェントやResponses API機能が動作しない場合があると説明されています。(Microsoft Learn)
よくある失敗は、開発環境では新APIが動いたのに、本番環境のリージョンでは同じ構成が使えないケースです。特に、次のような環境では事前確認が必要です。
| 環境 | 注意点 |
|---|---|
| 本番と開発でリージョンが異なる | 開発で成功したAPI呼び出しが本番で失敗する可能性がある |
| データ所在地要件がある | 対応リージョンへの移設が簡単にできない可能性がある |
| 複数国・複数拠点で利用する | リージョンごとのモデル、API、機能差を確認する必要がある |
| エージェント機能を使う | Responses APIとAgent Serviceのリージョン対応を両方見る |
リージョンは「あとで変更すればよい」項目ではありません。ネットワーク、データ保管、監査、モデル可用性、レイテンシに関わるため、移行計画の初期段階で確認してください。
開発者が確認すべきREST APIの変更点
開発者にとって重要なのは、既存コードのどこを修正すべきかです。Azure AI Foundry REST APIでは、特にエンドポイント、認証、APIバージョン、エージェント定義、SDKの確認が必要です。
エンドポイントはプロジェクト単位で整理する
エージェント向けRESTリファレンスでは、サーバー変数endpointとしてFoundry Project endpointを指定します。形式はhttps://{ai-services-account-name}.services.ai.azure.com/api/projects/{project-name}です。既定プロジェクトを対象にする場合は_projectを使う形式もあります。 (Microsoft Learn)
実装時は、次のように設定を分けると安全です。
FOUNDRY_PROJECT_ENDPOINT=https://<foundry-resource>.services.ai.azure.com/api/projects/<project-name>
FOUNDRY_OPENAI_RESPONSES_ENDPOINT=https://<foundry-resource>.services.ai.azure.com/api/projects/<project-name>/openai/v1/responses公式の概要ページでも、REST APIの例として/api/projects/<project-name>/openai/v1/responsesへPOSTする形式が示されています。モデル呼び出し系のAPIでは、プロジェクト配下のOpenAI v1エンドポイントを使う点を押さえておきましょう。(Microsoft Learn)
api-versionの考え方を混同しない
移行で失敗しやすいのが、api-versionの扱いです。
管理プレーンのAPIでは、たとえばDeployments APIやProjects APIに2025-06-01のAPI Versionが示されています。デプロイの作成・更新・削除・取得・一覧・SKU一覧などは、この管理プレーン側のバージョンを前提に確認します。(Microsoft Learn)
一方、現在のFoundry体験では、モデル呼び出しやResponses APIの文脈でv1 stable routesが示されています。移行ガイドでも、従来の月次api-versionパラメータからv1 stable routesへ整理されていることが説明されています。(Microsoft Learn)
つまり、次のように分けて考えます。
| APIの種類 | api-versionの考え方 |
|---|---|
| Azureリソース管理API | api-version=2025-06-01など、ARM側のAPIバージョンを指定する |
| Responses API / OpenAI v1系 | /openai/v1/のようなv1 stable routeを使う |
| Agent REST referenceの一部 | api-version=v1を要求する操作がある |
| Preview機能 | 別のPreview APIバージョンやFeature Opt-inが必要な場合がある |
「全部api-version=v1にすればよい」「全部2025-06-01にすればよい」と考えると、呼び出し先を間違えます。コードレビューでは、APIの目的とエンドポイントをセットで確認してください。
認証はAPIキー前提からAzure ADトークン前提へ見直す
エージェント向けRESTリファレンスでは、認証としてOAuth2Authが示され、スコープにhttps://ai.azure.com/.defaultが記載されています。また、すべてのエンドポイントがOAuth2Authを要求すると説明されています。 (Microsoft Learn)
旧Azure OpenAIのコードでは、APIキーを環境変数に入れて呼び出している例が多くあります。しかし、現在のFoundryプロジェクト中心の構成では、DefaultAzureCredentialやサービスプリンシパル、マネージドIDを使ったBearerトークン方式を標準として設計した方が、RBAC、監査、キー管理の面で安全です。
特に本番運用では、次の方針をおすすめします。
| 用途 | 推奨される考え方 |
|---|---|
| ローカル開発 | Azure CLIログインや開発者アカウントを使い、権限を最小化する |
| CI/CD | サービスプリンシパルまたはワークロードID連携を使う |
| Azure上のアプリ | マネージドIDを優先する |
| 緊急時の検証 | 一時的な権限付与に限定し、常設の高権限キーを避ける |
APIキーを使い続ける場合でも、キーの保管場所、ローテーション手順、漏えい時の無効化手順を見直してください。
エージェントAPIで確認すべきポイント
2026年5月末時点の公式情報では、Foundry Agent Serviceまわりの更新が多く、REST APIを使う開発者はエージェントの作成・更新・バージョン管理を特に確認すべきです。2026年5月の「What’s new」では、A2A、Routines、Voice agents、Managed MCP servers、Fabric IQ、Work IQ、Tool search、Agent optimizerなど、エージェント関連の新規記事がまとめて掲載されています。(Microsoft Learn)
エージェントは「更新＝新バージョン作成」として扱う
Agents APIでは、POST {endpoint}/agents/{agent_name}?api-version=v1による更新操作について、エージェント定義に変更がある場合は新しいバージョンを追加し、変更がない場合は既存のエージェントバージョンを返すと説明されています。また、AgentVersionObjectでは、エージェントはイミュータブルで、更新のたびに同じ名前を維持しながら新しいバージョンが作られると説明されています。(Microsoft Learn)
これは運用上かなり重要です。単に「上書き更新される」と考えると、次のような問題が起きます。
| 失敗例 | 対策 |
|---|---|
| 本番で意図しないバージョンが使われる | デプロイ時にエージェント名だけでなくバージョンを記録する |
| 障害時に戻せない | リリースごとのAgent Version IDを保存する |
| 変更履歴が追えない | GitのコミットIDやリリース番号をmetadataに入れる |
| A/Bテストが混乱する | どのユーザー群がどのバージョンを使ったかログに残す |
エージェントの更新処理は、アプリケーションの設定変更ではなく「バージョン付き成果物のリリース」として扱うべきです。
Agent kindとPreview Featureを明示的に管理する
Agents APIのAgentDefinitionでは、kindによってprompt、workflow、hostedなどの種類が区別されます。また、Foundry-FeaturesヘッダーにはHostedAgents=V1PreviewやWorkflowAgents=V1Previewといった値が示され、Preview操作や永続化されたPreviewリソースの変更時に必要なFeature Opt-inとして説明されています。(Microsoft Learn)
実務では、Preview機能を便利だからといって全環境で有効にするのは避けた方が安全です。
| 確認項目 | 推奨対応 |
|---|---|
| Preview機能を使う理由 | 本番要件に必要か、代替手段がないかを記録する |
| 有効化範囲 | 開発・検証・本番でヘッダー設定を分ける |
| 互換性 | SDK更新やAPI変更で壊れる可能性を受け入れられるか確認する |
| ロールバック | Preview機能を使わない構成へ戻せるか検証する |
| 利用者への説明 | 「プレビュー機能を含む」ことを社内承認資料に明記する |
Previewは検証速度を上げる一方、本番の安定性や監査ではリスクになります。CI/CDでは、Previewヘッダーをコードに直書きせず、環境変数や構成ファイルで明示的に管理しましょう。
エージェント名とmetadataの制約も見落とさない
Agents APIでは、エージェント名は最大63文字、先頭と末尾は英数字、途中にハイフンを含められると説明されています。また、metadataは最大16個のキー・バリューで、キーは最大64文字、値は最大512文字とされています。(Microsoft Learn)
小さな制約に見えますが、運用設計では意外と問題になります。
| 項目 | 悪い例 | 良い例 |
|---|---|---|
| エージェント名 | prod_customer_support_agent_for_japan_v20260529_final | prod-cs-ja |
| バージョン情報 | 名前にすべて詰め込む | metadataやリリース管理表で管理する |
| 環境識別 | test, new, finalなど曖昧な名前 | dev、stg、prodを命名規則に含める |
| 監査情報 | 手元のメモで管理 | release_id、owner、git_commitなどをmetadataへ入れる |
名前は短く安定させ、変更履歴はバージョンとmetadataで管理するのが実務向きです。
管理APIで確認すべき設定・展開ポイント
Azure AI Foundry REST APIの管理プレーンでは、プロジェクト、デプロイ、モデル、利用量、接続などを扱います。これらはアプリコードよりも、管理者やDevOps担当が見るべき範囲です。
プロジェクト作成とリソース構成
Projects APIでは、Cognitive Servicesアカウント配下のProjectを作成するAPIが示されています。リクエストボディにはidentity、location、properties、tagsを指定でき、レスポンスには200 OK、201 Created、202 Acceptedが定義されています。(Microsoft Learn)
202 Acceptedが返る可能性があるため、IaCや自動化スクリプトでは「HTTPステータスが成功ならすぐ使える」と決め打ちしない方が安全です。非同期完了を待つ設計、再試行、状態確認を入れてください。
デプロイ管理
Deployments APIでは、Cognitive Servicesアカウントに関連付くDeploymentの作成・更新、削除、取得、一覧、SKU一覧、更新操作が示されています。API Versionは2025-06-01です。(Microsoft Learn)
デプロイ自動化では、次の観点をチェックします。
| チェック項目 | 理由 |
|---|---|
| デプロイ名 | アプリ側のmodel指定と一致していないと呼び出しに失敗する |
| SKU | 性能、コスト、リージョン制約に影響する |
| 変更タイミング | 本番トラフィック中の更新はレイテンシやエラー率に影響する可能性がある |
| ロールバック手順 | 新モデルや新SKUで問題が出た場合に戻せるようにする |
| 利用量監視 | クォータ超過や予期しないコスト増を検知する |
モデルを「作成できた」だけでは不十分です。アプリからの実呼び出し、スループット、レイテンシ、エラー処理まで含めて展開確認を行いましょう。
モデル一覧、キャパシティ、利用量を事前に確認する
Models APIでは、指定リージョンで利用可能なモデル一覧を取得できます。Model Capacities APIでは、modelFormat、modelName、modelVersionを指定してモデルキャパシティを確認できます。Usages APIでは、指定サブスクリプションとリージョンの利用量を取得でき、任意でODataフィルターも指定できます。(Microsoft Learn)
本番展開前には、少なくとも次の3つを確認してください。
| 確認内容 | 具体的な確認方法 |
|---|---|
| モデルが対象リージョンで使えるか | Models – Listでリージョン別のモデル一覧を確認する |
| 必要なキャパシティが確保できるか | Model Capacities – Listで対象モデルの容量条件を確認する |
| クォータに余裕があるか | Usages – Listで利用状況を確認する |
AIアプリの障害は、コードのバグだけでなく「リージョンでモデルが使えない」「デプロイはあるが容量が足りない」「検証時は問題なかったが本番負荷でクォータに当たる」といった運用要因でも発生します。
接続情報はAccount Connectionsで管理対象を明確にする
Account Connections APIでは、Cognitive Servicesアカウント配下の接続の作成・削除・取得・一覧・更新が示されています。外部データ、検索、ツール、MCP連携などを使う構成では、接続情報がどのアカウントやプロジェクトに紐づいているかを明確にする必要があります。(Microsoft Learn)
特にRAG、社内データ連携、エージェントのツール呼び出しでは、接続情報の権限が強くなりがちです。接続先の資格情報、更新者、利用プロジェクト、削除時の影響範囲を管理台帳に残しておきましょう。
既存環境からの移行手順
Azure AI Foundry REST APIの移行は、いきなりコードを書き換えるより、棚卸しから始める方が安全です。
| 手順 | 作業内容 | 成果物 |
|---|---|---|
| 1 | 既存API呼び出しを棚卸しする | エンドポイント、APIバージョン、SDK、認証方式の一覧 |
| 2 | 管理プレーンとデータプレーンに分類する | 修正対象と影響範囲の整理 |
| 3 | 利用リージョンとモデルを確認する | 対応リージョン、利用可能モデル、クォータの確認結果 |
| 4 | SDKと認証方式を決める | openai、azure-ai-projects 2.x、Azure AD認証の採用方針 |
| 5 | Assistants API利用箇所を特定する | Responses API / Agents v2への移行対象一覧 |
| 6 | Preview機能を分離する | 本番利用可否、Feature Opt-in、ロールバック方針 |
| 7 | 検証環境でスモークテストする | API疎通、認証、モデル応答、ログ、エラー処理の結果 |
| 8 | 本番展開を段階化する | カナリアリリース、監視、切り戻し手順 |
公式移行ガイドでは、azure-ai-inferenceパッケージが2026年5月30日にリタイアすること、Assistants APIが2026年8月26日に終了予定であることが重要な移行日として示されています。既存のAssistants APIベースのワークロードは、Responses APIやMicrosoft Foundry Agents serviceへの移行を計画すべきです。(Microsoft Learn)
コード移行で失敗しやすいポイント
Azure AI Foundry REST APIの移行でよくある失敗は、コードの一部だけを新しくして、周辺設定が古いまま残るケースです。
SDKバージョンとポータル体験が合っていない
移行ガイドでは、SDKのバージョンがポータル体験と合っていないとエラーになると説明されています。たとえば、azure-ai-projects 2.xのサンプルをクラシック向け構成に適用すると、想定外のエラーが起きる可能性があります。(Microsoft Learn)
対応策はシンプルです。
pip freeze | grep -E "openai|azure-ai-projects|azure-ai-inference|azure-ai-generative|azure-ai-ml"Node.jsの場合は、次のように確認します。
npm ls openai @azure/ai-projects @azure/identityCI/CDでも同じ確認を行い、ローカルだけ新SDK、本番ビルドは旧SDKという状態を避けてください。
旧エンドポイントに新APIを投げている
移行ガイドのトラブルシューティングでは、古い複数エンドポイントURLが解決しない場合は単一プロジェクトエンドポイント形式へ更新すること、Assistants API呼び出しをResponses APIエンドポイントへ送ると404やMethodNotAllowedが起きることが示されています。(Microsoft Learn)
API移行時は、次のような環境変数の名前も見直しましょう。
# 悪い例: 何のAPI向けか分かりにくい
AZURE_OPENAI_ENDPOINT=
API_VERSION=
MODEL_NAME=
# 良い例: 目的が分かる
FOUNDRY_PROJECT_ENDPOINT=
FOUNDRY_OPENAI_BASE_URL=
FOUNDRY_AGENT_API_VERSION=v1
FOUNDRY_MODEL_NAME=環境変数名を変えるだけでも、レビュー時に誤設定を見つけやすくなります。
create_agent()前提の設計が残っている
移行ガイドでは、Agent作成の考え方として、旧来のcreate_agent()からcreate_version()へ移ることが示されています。また、現在の用語ではAssistants / AgentsがAgent Versionsに整理されています。(Microsoft Learn)
これにより、アプリ側では次の観点が重要になります。
| 設計項目 | 見直しポイント |
|---|---|
| エージェント作成 | 毎回新規作成するのではなく、バージョン管理する |
| リリース | どのバージョンを本番に出すかを明示する |
| テスト | バージョンごとに評価データセットを紐づける |
| ロールバック | 直前の安定バージョンへ戻す手順を作る |
| 監査 | 誰が、いつ、どの定義を反映したか記録する |
エージェントは「設定ファイル」ではなく、アプリケーションの一部として扱うのが安全です。
本番展開前のチェックリスト
Azure AI Foundry REST APIを使うアプリを本番展開する前に、次の項目を確認してください。
| 分類 | チェック項目 | 確認できたらOK |
|---|---|---|
| エンドポイント | プロジェクトエンドポイントと管理APIエンドポイントを分離している | services.ai.azure.comとmanagement.azure.comを用途別に使い分けている |
| 認証 | APIキー依存を減らし、Azure AD認証を使っている | サービスプリンシパルまたはマネージドIDで動作する |
| RBAC | 実行IDに必要最小権限がある | 管理者権限を常用していない |
| APIバージョン | ARM側とv1 stable route側を混同していない | APIごとのバージョン指定が一覧化されている |
| リージョン | Responses APIとAgent Serviceの対応リージョンを確認した | 開発・本番の両方で検証済み |
| モデル | 対象リージョンでモデルが利用可能 | Models APIやポータルで確認済み |
| キャパシティ | 本番負荷に必要な容量を確認した | UsagesやModel Capacitiesを確認済み |
| エージェント | バージョン管理とロールバック手順がある | Agent Version IDを記録している |
| Preview | Preview機能の利用有無を明示した | Feature Opt-inを環境別に管理している |
| 監視 | エラー率、レイテンシ、利用量、コストを監視する | ダッシュボードやアラートがある |
このチェックリストは、初回移行だけでなく、モデル追加、エージェント更新、リージョン変更、SDK更新のたびに使えます。
Copilotや社内AI活用への影響
見出し案にある「AI/Copilot更新」という観点では、Azure AI Foundry REST APIの変更は、社内向けCopilot風アプリやエージェント基盤にも影響します。公式のMicrosoft Foundry概要では、Foundryはエージェント、モデル、ツールを単一の管理単位に統合し、トレーシング、監視、評価、RBAC、ネットワーク、ポリシーなどのエンタープライズ向け機能を提供すると説明されています。(Microsoft Learn)
具体的には、次のようなチームで確認が必要です。
| 利用シーン | 影響 |
|---|---|
| 社内問い合わせAI | 回答生成API、RAG接続、監査ログ、評価基盤を見直す |
| Teams連携エージェント | Agent Service、権限、公開先、Preview機能の利用有無を確認する |
| 開発者向けCopilot風ツール | Responses API、ツール呼び出し、コード実行機能の扱いを整理する |
| 業務自動化エージェント | A2A、MCP、Workflow、Hosted AgentなどのPreview範囲を分離する |
| 全社AI基盤 | RBAC、リージョン、クォータ、コスト管理、モデル選定を標準化する |
特に、Microsoft 365やTeamsとつながるエージェントを構築する場合、技術的に動くかだけでなく、誰の権限でどのデータにアクセスするのかを明確にしてください。AIアプリの品質問題は、プロンプトやモデル性能だけでなく、権限設計とデータ接続の不備からも発生します。
まず着手すべきこと
Azure AI Foundry REST APIの更新対応で最初にやるべきことは、コード修正ではなく棚卸しです。次の順番で進めると、影響範囲を漏らしにくくなります。
- 既存アプリで使っているエンドポイント、SDK、APIバージョン、認証方式を一覧化する
- Assistants API、
azure-ai-inference、旧AzureOpenAI()クライアントの利用箇所を探す - 管理プレーンAPIとデータプレーンAPIを分けて、移行対象を分類する
- 本番リージョンでResponses APIとFoundry Agent Serviceが使えるか確認する
- エージェントは名前ではなくバージョン単位で管理する運用へ変更する
- Preview機能は本番から分離し、Feature Opt-inを明示的に管理する
- 開発・検証・本番の順に段階展開し、切り戻し手順を用意する
Azure AI Foundry REST APIは、単なるAPIリファレンスの追加ではなく、Microsoft FoundryとしてAIアプリ、モデル、エージェント、管理機能を統合して扱う流れの一部です。管理者はリソース、RBAC、リージョン、クォータを確認し、開発者はエンドポイント、認証、Responses API、Agent Versionを確認してください。既存環境をいきなり置き換えるのではなく、APIの役割ごとに棚卸しし、影響の小さい範囲から段階的に移行することが、最も安全な進め方です。
コメント