Azure OpenAI Agents の更新ポイントで最初に押さえるべき結論は、新規のエージェント実装では Responses クライアントを第一候補にし、既存の Chat Completions 実装は必要なツール機能を確認したうえで継続または移行を判断するという点です。特に、Code Interpreter、File Search、Hosted MCP などのホスト型ツールを使うなら Responses が前提になります。一方、シンプルなチャット型エージェントや既存の Chat Completions 統合を維持したい場合は、Chat Completion クライアントも引き続き選択肢です。(Microsoft Learn)
2026年6月26日に更新された Microsoft Agent Framework のプロバイダー概要では、Azure OpenAI が「Function Tools」「Structured Outputs」「Code Interpreter」「File Search」「MCP Tools」「Background Responses」に対応するフル機能プロバイダーとして整理されています。さらに Azure OpenAI Agents の個別ドキュメントでは、Azure OpenAI 向けのクライアント選択、ツール対応範囲、Assistants API 廃止への対応が明確化されています。(Microsoft Learn)
Azure OpenAI Agents とは何か
Azure OpenAI Agents は、ここでは単体の新サービス名というより、Microsoft Agent Framework から Azure OpenAI をエージェントの推論プロバイダーとして利用するための実装パターンとして理解すると分かりやすいです。
Microsoft Agent Framework では、Azure OpenAI を使う場合に主に次の2種類のクライアントを使い分けます。
| クライアント | 対象API | 向いている用途 |
|---|---|---|
| Responses | Responses API | ホスト型ツールを使う本格的なエージェント、ファイル検索、コード実行、MCP連携 |
| Chat Completion | Chat Completions API | 既存のチャット補完実装、シンプルなエージェント、幅広いモデル互換性を重視する構成 |
実務上の判断基準はシンプルです。ツール連携を中心に設計するなら Responses、既存のチャット補完資産を活かすなら Chat Completionです。モデル名だけで選ぶのではなく、「どのツールを使うか」「会話履歴やセッション管理をどこまでフレームワークに寄せるか」で判断するのが失敗しにくい進め方です。(Microsoft Learn)
今回の更新で確認すべき主な変更点
今回の公式情報で重要なのは、Azure OpenAI Agents の使い方が「なんとなく Azure OpenAI を呼び出す」段階から、APIサーフェスごとにクライアントと機能を選ぶ段階へ整理されたことです。
| 確認項目 | 管理者・開発者が見るべきポイント |
|---|---|
| クライアント選択 | Responses を標準候補にする。Chat Completion は既存資産やモデル互換性が理由になる場合に使う |
| ツール対応 | Code Interpreter、File Search、Hosted MCP が必要なら Responses を選ぶ |
| Assistants API | Azure OpenAI Assistants API は非推奨。既存利用がある場合は移行計画が必要 |
| 認証 | 開発時の DefaultAzureCredential と本番運用の資格情報設計を分けて考える |
| Python実装 | 現行の Agent Framework では Azure OpenAI 固有クラスではなく agent_framework.openai 側への移行を確認する |
| リージョン・モデル | Responses API の対応リージョンと、モデルごとの提供状況を確認する |
特に見落としやすいのは、「Chat Completion でもエージェント化できるが、すべてのツールが使えるわけではない」という点です。既存の Chat Completions 実装をそのままエージェント化しても、File Search や Hosted MCP を後から追加しようとして設計をやり直すケースが起こり得ます。
Responses クライアントが推奨される理由
Azure OpenAI Agents の個別ドキュメントでは、Responses クライアントが推奨の主要クライアントとして示されています。理由は、ホスト型ツールを含む最も広いツールサポートを持つためです。具体的には、Function Tools、Tool Approval、Code Interpreter、File Search、Web Search、Hosted MCP、Local MCP Tools に対応します。(Microsoft Learn)
| ツール | Responses | Chat Completion |
|---|---|---|
| Function Tools | 対応 | 対応 |
| Tool Approval | 対応 | 対応 |
| Code Interpreter | 対応 | 非対応 |
| File Search | 対応 | 非対応 |
| Web Search | 対応 | 対応 |
| Hosted MCP Tools | 対応 | 非対応 |
| Local MCP Tools | 対応 | 対応 |
この差は、設計段階で大きな意味を持ちます。たとえば、社内文書を検索して回答するRAG型エージェント、CSVを読み込んで分析する業務支援エージェント、外部ツールをMCPで接続するエージェントを作る場合は、最初から Responses を前提にした方が後戻りが少なくなります。
一方、問い合わせ分類、簡単なFAQ応答、既存の Chat Completions API を使った軽量ボットであれば、Chat Completion クライアントを継続する判断も合理的です。重要なのは「新しいから Responses」ではなく、必要なツール機能と運用要件から選ぶことです。
Chat Completion クライアントを使い続けてよいケース
Chat Completion クライアントは廃止対象として示されているわけではありません。公式ドキュメントでも、幅広いモデル互換性が必要な場合や、既存の Chat Completions 統合を維持したい場合に使う選択肢として説明されています。(Microsoft Learn)
次のようなケースでは、無理に Responses へ切り替えなくてもよい可能性があります。
- 既存アプリが Chat Completions API で安定稼働している
- Function Calling 程度のツール連携で十分
- File Search や Code Interpreter を使う予定がない
- モデル互換性や既存SDKの都合を優先したい
- 移行による回帰テストの負荷が大きい
ただし、今後エージェント機能を拡張する予定があるなら、ロードマップを確認しておくべきです。たとえば「最初はFAQだけだが、半年後に社内ファイル検索やMCP連携を入れる」計画があるなら、初期段階から Responses を採用した方が再設計を避けやすくなります。
Azure OpenAI Assistants API 利用者は移行期限に注意
既存の Azure OpenAI Assistants API を使っている場合は、今回の Azure OpenAI Agents 関連情報とは別に、移行期限を必ず確認する必要があります。Microsoft Learn の Azure OpenAI Assistants API のドキュメントでは、Assistants API は非推奨であり、2026年8月26日に廃止予定と明記されています。移行先としては、一般提供されている Microsoft Foundry Agents service と移行ガイドの利用が案内されています。(Microsoft Learn)
| 現在の利用状況 | 取るべき対応 |
|---|---|
| Azure OpenAI Assistants API を本番利用中 | 2026年8月26日までに移行計画、検証、本番切り替えを完了する |
| Assistants API を検証環境だけで使用 | 新規開発では使わず、Responses または Foundry Agents 側で再設計する |
| Chat Completions API を使用 | 廃止期限の対象ではないが、必要なツール機能を確認する |
| Semantic Kernel の旧エージェント実装を使用 | Microsoft Agent Framework への移行可否を確認する |
ここで注意したいのは、Assistants API の廃止と Chat Completions API の利用継続は別問題という点です。Assistants API を使っていない既存の Chat Completions アプリまで、ただちに廃止対応が必要になるわけではありません。ただし、エージェント機能を強化する予定がある場合は、Responses または Foundry Agents を含めて再設計する価値があります。
設定変更で確認すべきポイント
Azure OpenAI Agents のドキュメントでは、.NET で Azure OpenAI を使う場合のパッケージ追加や AzureOpenAIClient の作成例が示されています。例では Azure.AI.OpenAI、Azure.Identity、Microsoft.Agents.AI.OpenAI を追加し、Azure OpenAI リソースのエンドポイントと資格情報を使ってクライアントを作成します。(Microsoft Learn)
dotnet add package Azure.AI.OpenAI --prerelease
dotnet add package Azure.Identity
dotnet add package Microsoft.Agents.AI.OpenAI --prereleaseC# の基本形は次のようなイメージです。
using Azure.AI.OpenAI;
using Azure.Identity;
using Microsoft.Agents.AI;
AzureOpenAIClient client = new AzureOpenAIClient(
new Uri("https://<myresource>.openai.azure.com"),
new DefaultAzureCredential());
var responsesClient = client.GetResponsesClient();
AIAgent agent = responsesClient.AsAIAgent(
model: "gpt-4o-mini",
instructions: "You are a helpful coding assistant.",
name: "CodeHelper");ただし、本番環境で DefaultAzureCredential をそのまま使う場合は注意が必要です。公式ドキュメントでも、開発には便利だが、本番では ManagedIdentityCredential など特定の資格情報を検討すべきとされています。理由は、不要な資格情報探索による遅延や、意図しないフォールバックによるセキュリティリスクを避けるためです。(Microsoft Learn)
本番環境での認証設計
本番運用では、次のように分けて考えると整理しやすくなります。
| 環境 | 推奨される考え方 |
|---|---|
| ローカル開発 | DefaultAzureCredential や Azure CLI 認証で開発効率を優先 |
| Azure App Service / Functions / Container Apps | マネージドIDを使い、キーをコードや環境変数に置かない設計を優先 |
| CI/CD | フェデレーション資格情報やサービスプリンシパルを使い、権限を最小化 |
| 本番アプリ | 利用する Azure OpenAI リソースに必要最小限のロールを割り当てる |
「動いたからそのまま本番へ」ではなく、認証方式、ロール、キー管理、監査ログをセットで確認することが重要です。
v1 API と Responses API の確認ポイント
Azure OpenAI Responses API は、ステートフルな複数ターン応答を生成するためのAPIで、Chat Completions と Assistants API の機能を統合する位置づけとして説明されています。利用にはデプロイ済みの Azure OpenAI モデル、APIキーまたは Microsoft Entra ID 認証、各言語のクライアントライブラリが必要です。(Microsoft Learn)
また、Azure OpenAI の v1 API では、従来のように月次で新しい api-version を指定し続ける負担を減らし、/openai/v1 を含むエンドポイントを使う形が示されています。v1 API では api-version パラメーターが不要になる点も、既存コードを見直す際の重要な変更点です。(Microsoft Learn)
from openai import OpenAI
import os
client = OpenAI(
api_key=os.getenv("AZURE_OPENAI_API_KEY"),
base_url="https://YOUR-RESOURCE-NAME.openai.azure.com/openai/v1/"
)
response = client.responses.create(
model="MODEL_DEPLOYMENT_NAME",
input="Azure OpenAI Responses API を一文で説明してください。"
)実務でよくある失敗は、model に基盤モデル名を入れてしまうことです。Azure OpenAI では、多くのケースで Azure側のデプロイ名を指定します。モデル名、デプロイ名、リージョン対応を混同すると、404 や認証エラーに見える失敗が発生します。
リージョンとモデル提供状況は必ず確認する
Responses API は対応リージョンが定義されており、日本向けでは japaneast も対応リージョンに含まれています。ただし、公式ドキュメントでは、対応リージョン内であってもすべてのモデルが利用できるとは限らないため、モデルごとのリージョン提供状況を確認するよう案内されています。(Microsoft Learn)
グローバル展開する企業では、次の観点で確認してください。
| 確認項目 | 見るべき理由 |
|---|---|
| Azure OpenAI リソースのリージョン | Responses API と利用モデルが対応しているか |
| モデルデプロイ名 | アプリ側の model 指定と一致しているか |
| データ所在地 | MCPや外部ツール連携でデータが想定外の地域へ出ないか |
| 可用性設計 | リージョン障害時に代替リージョンや縮退運転が可能か |
| レイテンシ | Web Search、File Search、外部MCP呼び出しを含めた実測値を確認する |
特にエージェントは、単純な1回のモデル呼び出しよりも、ツール呼び出し、再推論、ファイル検索、外部API連携が重なりやすい構成です。モデル単体の応答速度だけでなく、1タスク完了までの総時間を計測することが大切です。
Python 実装では namespace と環境変数に注意
Python の Azure OpenAI guidance は、現在は OpenAI provider ページ側に整理されています。Azure OpenAI は direct OpenAI と同じ agent_framework.openai のクライアントを使う形になり、古い Python の AzureOpenAI* 互換クラスは現在の agent_framework.azure namespace から削除されたと説明されています。(Microsoft Learn)
そのため、古いサンプルコードや社内テンプレートを使っている場合は、次の点を確認してください。
| 確認対象 | チェック内容 |
|---|---|
| import 文 | agent_framework.azure の古い Azure OpenAI クラスを参照していないか |
| 環境変数 | OPENAI_API_KEY と AZURE_OPENAI_* が混在して意図しない接続先になっていないか |
| エンドポイント | Azure OpenAI の /openai/v1 形式になっているか |
| 認証 | APIキー運用か Microsoft Entra ID 認証か |
| SDKバージョン | 古いプレビュー版のサンプルを本番テンプレートに残していないか |
公式ドキュメントでは、OPENAI_API_KEY も存在する場合、明示的な Azure ルーティング入力を渡さない限り、汎用クライアントは OpenAI 側に留まると説明されています。Azure OpenAI に接続しているつもりで別の接続先を呼んでしまうミスを避けるため、環境変数と初期化コードはセットでレビューしてください。(Microsoft Learn)
セキュリティとガバナンスで見落としやすい点
Azure OpenAI Agents は、単にモデルを呼ぶだけでなく、ツールを呼び出して外部データや外部処理にアクセスする構成になりやすいです。そのため、通常のチャットアプリよりもガバナンスの確認範囲が広がります。
Microsoft Agent Framework のプロバイダー概要では、サードパーティのサーバー、エージェント、コード、非Azure Directモデルなどと連携する場合、利用者側がデータ共有、保持、所在地、コスト、権限、承認を管理する責任があると説明されています。(Microsoft Learn)
管理者が確認すべきガバナンス項目
| 項目 | 確認内容 |
|---|---|
| ツール承認 | 重要操作の前に人間の承認を挟むか |
| MCP連携 | 接続先サーバー、送信データ、認証情報の扱いを確認する |
| ファイル検索 | 検索対象データに機密情報や個人情報が含まれていないか |
| Code Interpreter | 実行されるコード、生成ファイル、追加課金を把握する |
| Web Search | 外部情報を回答に使う場合の引用、信頼性、ログ方針を決める |
| 監査ログ | 誰が、どのエージェントに、どのツールを使わせたか追跡できるか |
| プロンプトインジェクション対策 | 外部文書やWeb情報に含まれる悪意ある指示を無視できる設計にする |
Responses API のドキュメントでは、Guardrails はデプロイメントレベルで適用され、Responses API の各呼び出しに対して入力と出力の両方を保護するものとして説明されています。ただし、ガードレールはアプリ側の権限設計や業務承認フローを代替するものではありません。(Microsoft Learn)
コスト面では Code Interpreter とツール呼び出しを分けて見る
エージェント型アプリでは、通常のトークン課金だけでなく、ツール利用に伴うコストも確認が必要です。たとえば Responses API の Code Interpreter には、Azure OpenAI のトークンベース料金とは別の追加料金があると説明されています。また、同時に複数スレッドで Code Interpreter を呼び出すと複数セッションが作成され、セッションは既定で1時間アクティブ、アイドルタイムアウトは20分とされています。(Microsoft Learn)
コスト試算では、次のように分けて見積もると現実に近づきます。
| コスト要素 | 見積もり観点 |
|---|---|
| モデル呼び出し | 入力トークン、出力トークン、再推論回数 |
| ツール呼び出し | Code Interpreter、File Search、Web Search、MCP連携の利用頻度 |
| セッション | 同時利用数、セッション継続時間、アイドル時間 |
| データ基盤 | ファイル検索用ストレージ、検索インデックス、ログ保存 |
| 監視 | Application Insights、Log Analytics、アラート設定 |
「1ユーザー1往復」の料金だけで判断すると、エージェントの実コストを低く見積もりがちです。PoCの段階から、1件の業務完了に何回モデルを呼ぶか、何回ツールを呼ぶかをログで可視化してください。
移行時の実務チェックリスト
Azure OpenAI Agents の更新を受けて、管理者と開発者は次の順番で棚卸しすると効率的です。
既存実装の棚卸し
まず、現在のアプリがどのAPIを使っているかを確認します。
| 確認対象 | 見る場所の例 |
|---|---|
| Assistants API | /assistants、threads、runs を使うコード、旧SDK |
| Chat Completions API | /chat/completions、GetChatClient()、ChatCompletion系クラス |
| Responses API | /responses、GetResponsesClient()、ResponsesClient |
| Semantic Kernel | Microsoft.SemanticKernel.Agents、semantic_kernel.agents |
| Agent Framework | Microsoft.Agents.AI、agent_framework |
Azure OpenAI Assistants API が見つかった場合は、移行期限が最優先です。Chat Completions だけで構成されている場合は、すぐに止まる話ではありませんが、将来使いたいツール機能を確認します。
移行方針の決定
| 要件 | 推奨方針 |
|---|---|
| 新規エージェントを作る | Responses を第一候補にする |
| 既存 Chat Completions を維持したい | Chat Completion クライアントで継続し、ツール制約を明記する |
| Assistants API を使っている | Foundry Agents service または Responses を含めて再設計する |
| ファイル検索やコード実行が必要 | Responses へ移行する |
| サーバー側で永続的なエージェント管理が必要 | Microsoft Foundry Agents service も候補に入れる |
| Python の古い Azure OpenAI 実装がある | agent_framework.openai への移行を確認する |
検証環境で確認する項目
移行前には、単にレスポンスが返るかだけでなく、次の観点を検証してください。
- 既存プロンプトで回答品質が変わらないか
- Function Calling の引数スキーマが期待通り生成されるか
- Tool Approval をどこで挟むか
- ストリーミング時のエラーイベントを処理できるか
- 429、500、タイムアウト時にリトライや中断が正しく動くか
- モデルデプロイ名の指定ミスを検知できるか
- 監査ログにツール呼び出し結果が残るか
- Code Interpreter や File Search の課金が想定内か
Responses API のストリーミングでは、トークン制限や解析問題などでエラーイベントが返る場合があり、アプリ側で検出して停止または再開できるようにする必要があります。(Microsoft Learn)
よくある誤解と注意点
Azure OpenAI Agents は Azure AI Agent Service と同じものですか？
同じものとして扱うと混乱します。Azure OpenAI Agents の文脈では、Microsoft Agent Framework から Azure OpenAI を使うプロバイダー実装が中心です。一方、Microsoft Foundry Agents service は、サービス管理型のエージェント機能として位置づけられます。既存 Assistants API の移行では Foundry Agents service が案内されていますが、新規の軽量エージェントでは Responses クライアントを使う選択もあります。(Microsoft Learn)
Chat Completion はもう使わない方がよいですか？
必ずしもそうではありません。Chat Completion は、シンプルなエージェントや既存の Chat Completions 統合を維持したい場合に使えます。ただし、Code Interpreter、File Search、Hosted MCP などを使う予定があるなら、Responses の方が適しています。(Microsoft Learn)
Assistants API の移行期限はいつですか？
Azure OpenAI Assistants API は非推奨で、2026年8月26日に廃止予定です。既存の本番ワークロードがある場合は、検証期間、リリース判定、ロールバック計画を含めて早めに移行計画を作る必要があります。(Microsoft Learn)
Responses にすればセキュリティ対策は十分ですか？
十分ではありません。Responses API の Guardrails は入力と出力の保護に役立ちますが、外部ツールへの権限付与、MCP接続先の信頼性、ファイル検索対象のデータ分類、ツール承認、ログ監査はアプリケーション側で設計する必要があります。(Microsoft Learn)
管理者が今すぐ確認すべきこと
Azure OpenAI Agents の更新で、管理者が最初に行うべきことは「どのクライアントを使うべきか」を決める前に、既存資産を棚卸しすることです。
特に次の5点は優先度が高いです。
- Azure OpenAI Assistants API を使っているアプリがないか確認する
- Chat Completions 実装に、将来 File Search や Code Interpreter を追加する予定がないか確認する
- Responses API を使うリージョンとモデルデプロイ名を確認する
- 本番環境で
DefaultAzureCredentialのままになっていないか確認する - MCP、Web Search、File Search など外部データ連携のガバナンスを確認する
今回のポイントは、単なるSDKの書き換えではありません。Azure OpenAI をエージェント基盤として使う場合、クライアント選択、ツール対応、認証、リージョン、移行期限、コスト、ガバナンスを一体で見直す必要があるということです。
まずは Assistants API の利用有無を確認し、該当があれば2026年8月26日の廃止期限を前提に移行計画を作成してください。新規開発や機能拡張では、必要なツール機能を洗い出したうえで、Responses を標準候補として設計するのが現実的です。
コメント