Azure AI FoundryのドキュメントやSDKで「Microsoft Foundry」という表記が出てきて、何が変わったのか分かりにくいと感じている人は多いはずです。結論から言うと、Microsoft FoundryはAzure AI Foundryの後継として整理されている現在のプラットフォーム名であり、エージェント開発では「どのエンドポイントを使うか」「エージェント定義をコードで持つか、Foundry側で管理するか」「ツールや権限をどこで設定するか」が重要になります。
特に管理者と開発者が見るべきポイントは、単なる名称変更ではありません。Agent FrameworkのMicrosoft Foundry連携では、直接推論のChatClientAgentと、Foundry側でバージョン管理されるFoundryAgentの2系統を使い分けます。さらに、Pythonクライアント、プロジェクトエンドポイント、ツール構成、RBAC、リージョン対応、旧SDKからの移行も確認が必要です。この記事では、2026年5月26日に更新されたMicrosoft公式情報を中心に、実務で確認すべき変更点と注意点を整理します。(Microsoft Learn)
Azure AI Foundryの「Microsoft Foundry」とは何か
Microsoft Foundryは、エンタープライズAI運用、モデル開発、アプリケーション開発をまとめて扱うAzure上の統合プラットフォームです。公式ドキュメントでは、エージェント、モデル、ツールを単一の管理単位に統合し、RBAC、ネットワーク、ポリシー、監視、評価などを一体で扱う基盤として説明されています。(Microsoft Learn)
名称だけを見ると混乱しやすいですが、MicrosoftのAIプラットフォームは「Azure AI Studio → Azure AI Foundry → Microsoft Foundry」という流れで整理されています。一方で、Azure上のリソースタイプは引き続きMicrosoft.CognitiveServices/accountsであり、名称変更だけで既存のAzureリソース種別が別物になるわけではありません。(Microsoft Learn)
実務上は、次のように理解すると判断しやすくなります。
| 観点 | 押さえるべきこと |
|---|---|
| 名称 | 現在の公式表記はMicrosoft Foundry。Azure AI Foundryは旧称・移行期の表記として残る場合がある |
| 開発対象 | モデル単体の呼び出しだけでなく、エージェント、ツール、評価、運用管理まで含む |
| エージェント開発 | Foundry Agent ServiceとMicrosoft Agent Frameworkの連携が重要 |
| 管理対象 | プロジェクト、モデル、エージェント、ツール、権限、リージョン、監視 |
| 注意点 | 旧ポータル、旧SDK、Assistants API、クラシック構成と混在しやすい |
2026年5月26日更新の公式情報で重要な変更点
Microsoft Agent Frameworkの「Microsoft Foundry」ページでは、Microsoft Foundryプロジェクトエンドポイントからの直接モデル推論と、Foundry Agent Serviceのサービス管理エージェントの両方をサポートすると説明されています。つまり、Azure AI Foundryでエージェントを作る場合、「コードから柔軟に動かす」のか「Foundry側で定義・バージョン管理する」のかを最初に決める必要があります。(Microsoft Learn)
主な変更点を整理すると、次のとおりです。
| 変更点 | 影響を受ける人 | 確認すべきこと |
|---|---|---|
| Microsoft Foundry表記への整理 | 管理者、開発者、設計者 | 旧Azure AI Foundry、Classicポータル、現行Foundryのどれを使っているか |
| Agent FrameworkのFoundry連携 | アプリ開発者 | ChatClientAgentとFoundryAgentの使い分け |
| Pythonクライアントの整理 | Python開発者 | agent_framework.foundry配下のクライアントへ移行するか |
| プロジェクトエンドポイントの利用 | 開発者、インフラ担当 | https://<project>.services.ai.azure.com形式のエンドポイントを使うか |
| ツール構成の所有場所 | 開発者、運用担当 | ツールをコードで渡すのか、Foundry側のエージェント定義で管理するのか |
| RBAC・IDモデル | 管理者、セキュリティ担当 | Foundryロール、エージェント専用ID、下流リソース権限を確認する |
| リージョン・モデル対応 | 管理者、SRE | Responses API、Agent Service、各ツールが対象リージョンで使えるか |
エージェントは「直接推論」と「サービス管理」で使い分ける
Microsoft Foundry連携では、主に2種類のエージェントパターンがあります。公式ドキュメントでは、Responses AgentはChatClientAgentを生成し、アプリ側が実行時にモデル、指示、ツールを提供するパターンと説明されています。一方、Foundry AgentはFoundryAgentを生成し、FoundryポータルまたはサービスAPIで作成・バージョン管理されたエージェント定義を使うパターンです。(Microsoft Learn)
| 種類 | 生成される型 | 向いているケース | 注意点 |
|---|---|---|---|
| Responses Agent | ChatClientAgent | アプリ側でモデル、指示、ツールを柔軟に切り替えたい | サーバー側のエージェントリソースは作成されない |
| Foundry Agent | FoundryAgent | Foundryポータルで定義を管理し、バージョン管理や運用統制を重視したい | 実行時にツールや指示を自由に差し替える用途には向かない |
判断基準はシンプルです。プロンプト、ツール、生成パラメーターをリクエストごとに細かく変えたいなら、まずFoundryChatClientやChatClientAgent側を検討します。逆に、本番運用で「このバージョンのエージェント定義を使う」と固定し、ポータル上で管理・承認・ロールバックしたい場合はFoundryAgentが適しています。
注意したいのは、FoundryAgentではエージェント定義がFoundry側にあることです。公式ドキュメントでは、Foundry Agentsのツールと指示は作成時の定義に厳密で、実行時にツールや指示を変更することはサポートされないとされています。(Microsoft Learn)
開発者が確認すべきSDKとエンドポイント
.NETでは、Microsoft Foundry連携に必要なパッケージとしてAzure.IdentityとMicrosoft.Agents.AI.Foundry --prereleaseが示されています。開発環境で試すだけならDefaultAzureCredentialは便利ですが、公式ドキュメントでは本番環境では待機時間、意図しない資格情報探索、フォールバックによるセキュリティリスクを考慮し、ManagedIdentityCredentialなど特定の資格情報の利用を検討するよう注意されています。(Microsoft Learn)
dotnet add package Azure.Identity
dotnet add package Microsoft.Agents.AI.Foundry --prereleasePythonでは、Foundry固有のクライアントがagent_framework.foundry配下に整理されています。公式情報では、クラウドFoundry向けにFoundryChatClient、FoundryAgent、FoundryEmbeddingClient、FoundryMemoryProviderを提供するagent-framework-foundryと、ローカル実行向けのagent-framework-foundry-localが説明されています。(Microsoft Learn)
pip install agent-framework-foundry
pip install azure-identity代表的な環境変数は次のように整理できます。
FOUNDRY_PROJECT_ENDPOINT="https://<your-project>.services.ai.azure.com"
FOUNDRY_MODEL="gpt-4o-mini"
FOUNDRY_AGENT_NAME="my-agent"
FOUNDRY_AGENT_VERSION="1.0"ここで間違いやすいのが、プロジェクトエンドポイントとモデルエンドポイントの違いです。FoundryChatClientとFoundryAgentはプロジェクトエンドポイントを使います。一方、FoundryEmbeddingClientは別のモデルエンドポイントを使うと説明されています。スタンドアロンのAzure OpenAIリソースエンドポイント、たとえばhttps://<your-resource>.openai.azure.comを使う場合は、Microsoft FoundryではなくOpenAIプロバイダー側のガイダンスを確認します。(Microsoft Learn)
Python移行では古いAzure系クライアント名に注意する
既存コードを持っている場合は、クラス名と名前空間の変更を必ず確認してください。公式ドキュメントでは、以前のPythonのAzureAIClient、AzureAIProjectAgentProvider、AzureAIAgentClient、AzureAIAgentsProvider、Azure AI埋め込み互換サーフェスは、現在のagent_framework.azure名前空間から削除されたとされています。現在のPythonコードでは、用途に応じてFoundryChatClient、FoundryAgent、FoundryEmbeddingClientを使います。(Microsoft Learn)
| やりたいこと | 推奨される選択 |
|---|---|
| アプリ側で指示・ツール・会話ループを持つ | Agent(client=FoundryChatClient(...)) |
| FoundryポータルまたはAPIで管理されたPrompt Agent / Hosted Agentにつなぐ | FoundryAgent(...) |
| Foundryモデルエンドポイントで埋め込みを作る | FoundryEmbeddingClient |
| Azure OpenAI単体のリソースを使う | OpenAIプロバイダー側のクライアントを確認する |
移行時にありがちな失敗は、古いサンプルのAzureAIAgentClientをそのまま使い続けることです。インストール済みパッケージが新しくても、コード上の名前空間やクラスが古いままだと、インポートエラーや予期しないAPI動作につながります。
ツール設定は「コード側で渡せば効く」とは限らない
Microsoft Foundryでエージェントを運用する際、最も実務上の事故が起きやすいのがツール設定です。
FoundryChatClientでは、Web検索、コードインタープリター、ファイル検索、MCP、画像生成などのツールをファクトリメソッドで作成し、tools=に渡すパターンが説明されています。一方、FoundryAgentでは、ツールはコードではなくFoundry側のエージェント定義に存在する必要があります。(Microsoft Learn)
特に重要なのは、FoundryAgent(...)にホスト型ツールをクライアント側で渡しても無視される点です。Web検索、コードインタープリター、ファイル検索、MCP、画像生成などのホスト型ツールは、FoundryポータルまたはサービスAPIでエージェント定義に設定する必要があります。(Microsoft Learn)
| 設定内容 | FoundryChatClient | FoundryAgent |
|---|---|---|
| ローカル関数ツール | コード側で渡しやすい | Foundry側に対応する関数定義が必要 |
| Web検索・ファイル検索などのホスト型ツール | ファクトリメソッドで渡せる | Foundry側のエージェント定義で構成する |
| 実行時のツール追加 | 向いている | 原則として向かない |
| ポータル管理・バージョン固定 | 目的によっては弱い | 向いている |
また、FoundryAgentではtemperature、top_p、max_tokens、instructions、tool_choice、response_formatなどの実行オプションがすべて尊重されるわけではありません。Foundry側のエージェント定義が信頼できるソースになるため、多くのオプションは無視、削除、またはFoundry側の設定に制約される可能性があります。(Microsoft Learn)
実装方針としては、次のように分けると安全です。
| 要件 | 選ぶべき構成 |
|---|---|
| ユーザーやリクエストごとにツールを動的に変えたい | FoundryChatClient |
| 本番用エージェント定義を固定し、承認済みツールだけを使わせたい | FoundryAgent |
| プロンプトやツールをA/Bテストしたい | まずFoundryChatClientで検証し、安定後にFoundry側へ移す |
| 監査・運用・バージョン管理を優先したい | FoundryAgent |
Foundry Toolboxを使う場合の注意点
Foundry Toolboxは、Microsoft Foundryプロジェクトで構成されたコードインタープリター、ファイル検索、画像生成、MCP、Web検索などのホスト型ツール設定を、名前付き・バージョン付きのサーバー側バンドルとして扱う仕組みです。公式ドキュメントでは、Agent FrameworkはToolboxの「消費」のみを対象とし、作成や更新はFoundryポータルまたはazure-ai-projects>=2.1.0などで行うと説明されています。(Microsoft Learn)
展開時には、次の点を確認してください。
| 確認項目 | 理由 |
|---|---|
| Toolboxのバージョンを固定しているか | 既定バージョンを毎回解決すると余分なリクエストが発生し、サーバー側の変更影響も受けやすい |
| 不要なツールを絞り込んでいるか | モデルに渡すツール定義が増えると、トークン使用量や誤呼び出しのリスクが上がる |
| キャッシュ方針を決めているか | get_toolbox()はネットワークアクセスを伴い、フレームワーク側のキャッシュはない |
| MCP利用時の認証を設計しているか | ToolboxのMCPエンドポイントを直接使う場合はEntra IDベアラートークンが必要 |
特に本番環境では、get_toolbox("research_toolbox")のように既定バージョンへ依存するより、get_toolbox("research_toolbox", version="v3")のように明示的に固定する方が、再現性と障害調査の面で有利です。(Microsoft Learn)
管理者が確認すべきポータル、リージョン、RBAC
管理者が最初に確認すべきなのは、現在の環境がClassicポータル前提なのか、現行のMicrosoft Foundryポータル前提なのかです。公式ドキュメントでは、現行ポータルはHome、Discover、Build、Operate、Docsに分かれ、Buildでモデルやエージェント、Operateで管理・クォータ・コンプライアンス・トレースを扱う構成として整理されています。(Microsoft Learn)
また、現行ポータルではFoundryプロジェクトのみが表示され、ハブベースのプロジェクトや一部の旧リソースはClassicポータル側に切り替えないと確認できない場合があります。移行確認時に「プロジェクトが消えた」と見える場合は、まずポータル体験の切り替えとプロジェクト種別を確認してください。(Microsoft Learn)
リージョン確認も必須です。Foundry Agent Serviceは、Azure OpenAI Responses APIをサポートするリージョンに作成されたFoundryプロジェクトでのみ利用できます。さらに、すべてのリージョンですべてのツールが使えるわけではなく、ツールごとの対応状況も確認が必要です。(Microsoft Learn)
RBACでは、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)
Hosted agentsを使う場合は、さらにIDモデルに注意が必要です。刷新されたプレビューでは、各エージェントがデプロイ時に専用のEntra IDを持つモデルへ変わり、下流のAzureリソースへのRBACはプロジェクトのマネージドIDではなく、エージェント専用IDへ付与する必要があります。(Microsoft Learn)
旧Azure AI Foundry・Assistants API利用者の移行ポイント
Classicポータルや古いSDKを使っている場合は、移行期限とSDKの対応関係を確認してください。公式ドキュメントでは、azure-ai-inferenceパッケージは2026年5月30日にリタイア、Assistants APIは2026年8月26日に終了予定とされています。2026年6月時点では、azure-ai-inferenceの期限はすでに過ぎているため、該当コードが残っている環境では優先的に棚卸しが必要です。(Microsoft Learn)
SDK移行では、現行のFoundry体験ではazure-ai-projects 2.xが使われ、openaiパッケージとbase_urlを使う標準的なクライアント構成が示されています。公式ドキュメントでも、SDKバージョンとポータル体験が一致していないとエラーになると注意されています。(Microsoft Learn)
特に確認すべき移行項目は次のとおりです。
| 確認対象 | 移行時の見直し |
|---|---|
| 推論SDK | azure-ai-inferenceに依存していないか |
| Azure OpenAIクライアント | AzureOpenAI()前提の実装を、必要に応じてOpenAI() + base_urlへ見直す |
| プロジェクトSDK | azure-ai-projects 1.xと2.xが混在していないか |
| Assistants API | Responses APIまたはFoundry Agent Serviceへ移行計画があるか |
| エージェント作成 | create_agent()前提のコードを、現行のエージェント定義・バージョン管理へ合わせる |
| エンドポイント | 旧形式の複数エンドポイントではなく、プロジェクトエンドポイントを使っているか |
2026年4月以前にHosted agentの初期プレビューを使っていた場合は、別途注意が必要です。公式移行ガイドでは、初期プレビューのホスティングバックエンドは自動移行されず、2026年5月22日までのサポートとされていました。該当する環境は、新しいホスティングバックエンド、プロトコルライブラリ、IDモデル、管理APIに合わせて再デプロイする必要があります。(Microsoft Learn)
展開前に確認したい実務チェックリスト
Azure AI FoundryからMicrosoft Foundryへの移行・展開では、コードだけでなく運用設定も含めて確認する必要があります。以下の順番で確認すると、手戻りを減らせます。
| 手順 | 確認内容 | 失敗しやすいポイント |
|---|---|---|
| 1 | 現在のポータル体験を確認する | Classicと現行Foundryを混同する |
| 2 | 利用するエージェント種別を決める | FoundryAgentで実行時にツールを追加しようとする |
| 3 | プロジェクトエンドポイントを確認する | Azure OpenAI単体のエンドポイントと混同する |
| 4 | SDKとパッケージを棚卸しする | 古いAzureAIAgentClientやazure-ai-inferenceが残る |
| 5 | リージョンとモデル対応を確認する | Responses APIや必要ツールが対象リージョンで使えない |
| 6 | RBACとIDを確認する | 下流リソース権限をプロジェクトIDにだけ付与してしまう |
| 7 | Toolboxやツール定義を確認する | Foundry側定義とコード側定義がずれる |
| 8 | 本番用の資格情報を決める | DefaultAzureCredentialをそのまま本番利用する |
| 9 | バージョン固定とロールバック手順を決める | 既定バージョン依存で再現性が落ちる |
| 10 | 監視・評価・ログ確認を準備する | 動作確認がチャットの目視だけになる |
よくあるトラブルと対処法
| 症状 | 主な原因 | 対処 |
|---|---|---|
| 新しいポータルでプロジェクトが見えない | ハブベースの旧プロジェクトを見ている | Classicポータルに切り替えるか、Foundryプロジェクトへ移行する |
| エージェント作成や実行ができない | リージョンがResponses APIまたはAgent Serviceに未対応 | 対応リージョンにFoundryリソースを作成する |
| ツールを渡したのに呼ばれない | FoundryAgentでクライアント側にツールを渡している | FoundryポータルまたはAPIでエージェント定義にツールを設定する |
| 指示を変えたのに反映されない | Foundry側のエージェント定義が優先されている | 実行ごとに指示を変えるならFoundryChatClientを検討する |
| Pythonのインポートで失敗する | 古い名前空間やクラス名を使っている | agent_framework.foundry配下のクライアントへ更新する |
| 権限エラーが出る | エージェント専用IDに下流リソース権限がない | 対象エージェントのEntra IDに必要なRBACを付与する |
| SDKサンプル通りに動かない | SDKバージョンとポータル体験が一致していない | azure-ai-projects 2.xなど現行Foundry向けの組み合わせを確認する |
どの構成を選ぶべきか
実務では、最初からすべてをFoundryAgent化するより、用途に応じて段階的に分けるのがおすすめです。
| フェーズ | おすすめ構成 | 理由 |
|---|---|---|
| 技術検証 | FoundryChatClient | 指示、ツール、モデルをコード側で変えやすい |
| PoC | FoundryChatClient + 必要に応じてToolbox | 試行錯誤しながらツール構成を固められる |
| 部門内利用 | FoundryAgent | ポータル管理、バージョン管理、権限設計を取り入れやすい |
| 本番運用 | FoundryAgentまたはHosted agent | 管理、監視、ID、スケール、ロールバックを設計しやすい |
| 外部システム連携 | Hosted agentまたは専用エンドポイント | 安定した呼び出し口と運用管理が必要になる |
動的なツール選択やリクエストごとのプロンプト制御が重要なアプリでは、FoundryChatClientの方が扱いやすい場面があります。一方、管理者が承認したツールだけを使わせたい、ポータルでバージョン差分を管理したい、監査や本番運用を重視したい場合は、FoundryAgentやHosted agentを軸に設計する方が安全です。
まとめ：次にやるべきこと
Azure AI Foundryの「Microsoft Foundry」は、単なる名称変更ではなく、エージェント、モデル、ツール、ポータル、SDK、権限管理を現行のFoundry体験へ整理する流れとして理解する必要があります。まずは、自社環境がClassicポータル前提なのか、現行Microsoft Foundry前提なのかを確認してください。
開発者は、FoundryChatClientとFoundryAgentのどちらを使うべきかを要件から決めます。管理者は、リージョン、RBAC、エージェント専用ID、ツールの管理場所、旧SDKやAssistants APIの利用有無を棚卸しします。特に本番展開では、「コードでは動いたが、Foundry側の定義・権限・リージョンで失敗する」というパターンが起きやすいため、実装前にチェックリストで確認しておくことが重要です。
最初の一歩としては、既存プロジェクトのエンドポイント、SDKバージョン、エージェント種別、ツール設定、RBACを1枚の表にまとめるのが効果的です。そのうえで、PoCは柔軟なFoundryChatClient、本番は管理しやすいFoundryAgentまたはHosted agentという形で段階的に移行すると、リスクを抑えてMicrosoft Foundryの新しい開発・運用モデルへ移行できます。
コメント