Microsoftの「OpenAI Agents」で押さえるべき結論は、新規開発ではResponsesクライアントを基本に選び、既存のChat Completions連携は互換性を重視する場合のみ残すという点です。2026年5月26日に更新されたMicrosoft Learnでは、Microsoft Agent FrameworkがOpenAI向けに「Responses」と「Chat Completion」の2種類のクライアントをC#とPythonでサポートし、Responsesを推奨クライアントとして位置付けています。(Microsoft Learn)
特に影響が大きいのは、Azure OpenAIやOpenAI Assistants APIを使ってエージェントを構築している管理者・開発者です。ホスト型ツール、環境変数、認証方式、Pythonのクラス名、Assistants APIからの移行方針を見直さないと、将来のアップデート時に動作不良やセキュリティ上の抜け漏れが起きる可能性があります。
この記事では、Microsoft Agent FrameworkにおけるOpenAI Agentsの変更点、影響範囲、管理者・開発者が確認すべき設定、移行時の注意点を実務目線で整理します。
MicrosoftのOpenAI Agentsで何が変わるのか
Microsoft Agent FrameworkにおけるOpenAI Agentsは、OpenAIまたはAzure OpenAIを使ってエージェントアプリを構築するための実装方式です。今回のポイントは、単に「使えるAPIが増えた」という話ではありません。
重要なのは、エージェント開発の標準ルートがResponses API中心に寄っていることです。
Microsoft Learnでは、OpenAI向けクライアントとして次の2種類が整理されています。Responsesは新しいOpenAI Responses APIを対象にし、code interpreter、file search、web search、hosted MCP、image generationなどのホスト型ツールを広く使えるため、推奨クライアントとされています。一方、Chat Completionは既存のChat Completions統合を維持したい場合や、幅広いモデル互換性を優先する場合に使う位置付けです。(Microsoft Learn)
| クライアント | 主な用途 | 向いているケース |
|---|---|---|
| Responses | 新規の本格的なエージェント開発 | ファイル検索、コード実行、Web検索、MCPなどのツールを活用したい |
| Chat Completion | 既存実装の維持、シンプルなチャット用途 | すでにChat Completions APIで構築済み、またはモデル互換性を優先したい |
管理者や開発者がまず判断すべきなのは、「今後もChat Completionで十分か」ではなく、自社のエージェントがツール実行や外部連携を必要とするかです。業務データを検索する、ファイルを扱う、Web検索を組み込む、MCP経由で外部システムに接続する、といった要件があるなら、Responses前提で設計した方が後戻りを減らせます。
変更点の中心は「Responses推奨」と「Assistantsからの移行」
今回の更新で最も大きいメッセージは、OpenAI Assistants APIを前提にした設計からの転換です。Microsoft Learnでは、OpenAI Assistants APIはOpenAIによって非推奨とされており、新しいコードではResponsesクライアントを使うよう案内されています。(Microsoft Learn)
OpenAI側の公式移行ガイドでも、Assistants APIはResponses APIとの機能同等性が整った後に非推奨化され、2026年8月26日に停止予定と説明されています。既存のAssistants API利用者は、Responses APIへの移行計画を持つ必要があります。(OpenAI Developers)
実務で見るべき変更点
| 確認項目 | これまでの考え方 | 今後の考え方 |
|---|---|---|
| 新規エージェント開発 | Assistants APIやChat Completionsを選ぶことも多い | Responsesを第一候補にする |
| 既存Chat Completions連携 | そのまま継続 | 必要なツール機能が不足しないか確認 |
| Assistants API利用 | 継続利用も選択肢だった | 移行対象として棚卸しする |
| Azure OpenAI連携 | 専用クラスや旧設定で実装 | 新しいOpenAI系クライアントと明示的なAzure設定を使う |
| Python実装 | 旧クラス名・旧パラメータが残る可能性 | OpenAIChatClient、OpenAIChatCompletionClient、model中心に整理 |
注意したいのは、Responsesへの移行は「API名を置き換えるだけ」では済まない場合があることです。Assistants APIではAssistant、Thread、Runといった概念で構成していた処理が、Responses APIではinput、output、conversation、tool callの扱いに変わります。OpenAIの移行ガイドでも、AssistantsからResponsesへの移行では、AssistantはPrompt、ThreadはConversation、RunはResponseに対応する形で整理されています。(OpenAI Developers)
影響範囲：誰が確認すべきか
この更新は、Microsoft 365 Copilotの画面だけを使っている一般利用者よりも、AIエージェントを開発・運用するチームへの影響が大きい内容です。
ただし、最終的にはCopilot Studio、Azure OpenAI、Microsoft Foundry、社内AIチャット、業務自動化システムなどの利用部門にも関係します。エージェントの裏側で使うAPIやクライアントが変わると、検索精度、ツール実行、権限管理、ログ設計、コスト管理に影響するためです。
影響を受けやすいチーム
| 対象 | 確認すべきこと |
|---|---|
| Azure OpenAI管理者 | 利用中のAPI、デプロイ済みモデル、認証方式、APIバージョン |
| アプリ開発者 | 使用クライアント、旧Assistants API、Chat Completions依存の有無 |
| セキュリティ担当 | Web検索、ファイル検索、コード実行、MCP接続の許可範囲 |
| 情シス・運用担当 | 環境変数、キー管理、Managed Identity、監査ログ |
| 業務部門 | 既存AIチャットや社内エージェントの動作変更、回答品質、利用ルール |
特に、エージェントに「ファイル検索」「Web検索」「コード実行」「外部ツール連携」を持たせている場合は、単なるライブラリ更新ではなく、情報アクセス範囲の変更としてレビューすべきです。
ResponsesとChat Completionの使い分け
Microsoft Agent Frameworkでは、ResponsesとChat Completionの両方が標準のAgentとして扱われ、ストリーミング、スレッド、ミドルウェアなどの共通操作をサポートします。(Microsoft Learn)
ただし、使えるツールには差があります。Microsoft Learnのツール対応表では、ResponsesはFunction Tools、Tool Approval、Code Interpreter、File Search、Web Search、Hosted MCP Tools、Local MCP Toolsに対応しています。一方、Chat CompletionではCode Interpreter、File Search、Hosted MCP Toolsが非対応です。(Microsoft Learn)
選定基準は「チャットか、業務エージェントか」
単純なFAQや文章生成だけなら、Chat Completionでも要件を満たせる場合があります。しかし、業務エージェントとして使うなら、次のような機能が必要になりやすくなります。
| やりたいこと | 推奨 |
|---|---|
| 社内文書を検索して回答する | Responses |
| ファイルを参照して要約・分析する | Responses |
| コード実行やデータ処理をさせる | Responses |
| MCPでGitHubや社内ツールに接続する | Responses |
| 既存のChat Completions実装を大きく変えずに維持する | Chat Completion |
| モデル互換性を重視したシンプルなチャットを作る | Chat Completion |
判断に迷う場合は、「将来ツールを追加する可能性があるか」で考えると実務的です。今は単純なチャットでも、後からファイル検索や外部API連携を追加する予定があるなら、最初からResponsesで設計した方が移行コストを抑えられます。
C#開発者が確認すべきポイント
C#では、OpenAIクライアントからResponsesクライアントまたはChatクライアントを取得し、AsAIAgentでAgent Frameworkの標準エージェントとして扱う構成が示されています。Microsoft LearnのOpenAI Agentsページでは、C#向けにMicrosoft.Agents.AI.OpenAIのNuGetパッケージを追加する例が掲載されています。(Microsoft Learn)
新規開発ではResponsesを基本にする
新規にC#でエージェントを作る場合、まず確認すべきなのは、既存のChat Completions互換性が本当に必要かどうかです。必要がなければ、Responsesクライアントを優先するのが自然です。
実装上は、以下の観点でレビューします。
| 確認項目 | 見るべきポイント |
|---|---|
| パッケージ | Microsoft.Agents.AI.OpenAIを使用しているか |
| クライアント | GetResponseClientを使う設計にできるか |
| ツール | code interpreter、file search、web search、MCPの利用予定があるか |
| 既存コード | GetChatClientに依存する理由が明確か |
| 権限 | ツール実行時の承認、ログ、監査が設計されているか |
C#でAzure OpenAIを使う場合は、AzureOpenAIClientを作成し、ResponsesまたはChat Completionのクライアントを使う構成になります。MicrosoftのAzure OpenAI Agentsページでも、Responsesが推奨クライアントであり、Chat Completionは既存統合や幅広いモデル互換性が必要な場合に使う位置付けです。(Microsoft Learn)
Python開発者が確認すべきポイント
Pythonでは変更点が比較的大きいため、既存コードの棚卸しが重要です。Microsoft Learnでは、OpenAIとAzure OpenAIの利用にagent-framework-openaiパッケージを使い、agent_framework.openai名前空間からクライアントを利用する構成が示されています。(Microsoft Learn)
OpenAIChatClientはResponses用
Pythonでは名前で誤解しやすい点があります。OpenAIChatClientはResponses API向けの推奨クライアントです。Chat Completions APIを使う場合はOpenAIChatCompletionClientを使います。Microsoft Learnでも、OpenAIChatClientはResponses APIを使い、ホスト型ツールを備えた推奨クライアントとして説明されています。(Microsoft Learn)
| Pythonクライアント | 対応API | 主な用途 |
|---|---|---|
OpenAIChatClient | Responses API | 新規エージェント、ホスト型ツール活用 |
OpenAIChatCompletionClient | Chat Completions API | 既存Chat Completions連携の維持 |
OpenAIEmbeddingClient | Embeddings | 埋め込みモデル利用 |
旧クラス名とmodel指定を見直す
Python 2026 Significant Changes Guideでは、非推奨だったAzure/OpenAI互換サーフェスが削除され、直接OpenAIまたはAzure OpenAIシナリオではOpenAIChatClient、OpenAIChatCompletionClient、OpenAIEmbeddingClientを使うよう説明されています。(Microsoft Learn)
また、クライアント設定はmodelに標準化され、古いmodel_id、deployment_name、model_deployment_nameのような指定から移行する必要があります。(Microsoft Learn)
移行時によくある失敗は、Azure OpenAIの「デプロイ名」を古いdeployment_nameのまま渡してしまうことです。新しい設計では、Azure OpenAIでもデプロイ名をmodelとして指定する場面があるため、環境変数名とコードの引数名をセットで確認してください。
Azure OpenAI利用時の設定・認証で注意すること
Azure OpenAIと直接OpenAIの両方を扱う環境では、環境変数の衝突に注意が必要です。Microsoft Learnでは、Pythonの汎用OpenAIクライアントはAzure OpenAIにも使える一方、OPENAI_API_KEYが設定されている場合、明示的なAzureルーティング入力を渡さない限り、汎用クライアントはOpenAI側に留まると説明されています。(Microsoft Learn)
つまり、開発PCやCI/CD環境にOpenAI用とAzure OpenAI用の環境変数が混在していると、意図しない接続先にリクエストが飛ぶ可能性があります。
管理者が確認すべき環境変数
| 用途 | 主な確認項目 |
|---|---|
| OpenAI直利用 | OPENAI_API_KEY、OPENAI_CHAT_MODEL、OPENAI_CHAT_COMPLETION_MODEL、OPENAI_MODEL |
| Azure OpenAI | AZURE_OPENAI_ENDPOINT、AZURE_OPENAI_CHAT_MODEL、AZURE_OPENAI_CHAT_COMPLETION_MODEL、AZURE_OPENAI_MODEL、AZURE_OPENAI_API_VERSION |
| Embeddings | OPENAI_EMBEDDING_MODEL、AZURE_OPENAI_EMBEDDING_MODEL |
| Foundry | FOUNDRY_PROJECT_ENDPOINT、FOUNDRY_MODELなど |
実務では、.envファイル、GitHub Actions、Azure DevOps Pipeline、App Serviceのアプリケーション設定、Container Appsのシークレット、ローカル開発環境を分けて確認します。特に本番環境では、不要なOPENAI_API_KEYが残っていないかを確認してください。
本番環境ではDefaultAzureCredentialの使い方に注意
Azure OpenAI Agentsの公式ページでは、DefaultAzureCredentialは開発には便利ですが、本番では意図しない認証フォールバックやレイテンシ、セキュリティリスクを避けるため、ManagedIdentityCredentialなど具体的な資格情報の利用を検討するよう警告されています。(Microsoft Learn)
本番展開では、次のように整理すると安全です。
| 環境 | 推奨方針 |
|---|---|
| ローカル開発 | Azure CLI認証や開発用キーを限定的に使用 |
| 検証環境 | 本番と同じ認証方式に近づける |
| 本番環境 | Managed Identityなど、明示的で監査しやすい認証を使う |
| CI/CD | シークレットのスコープを限定し、不要な環境変数を残さない |
ホスト型ツール利用時のセキュリティ確認
Responsesクライアントを選ぶ最大の利点は、ホスト型ツールを広く使えることです。一方で、ツールが増えるほど管理すべきリスクも増えます。
Microsoft Learnでは、Responsesクライアントがcode interpreter、file search、web search、hosted MCP、image generationなどのホスト型ツールをサポートすると説明されています。(Microsoft Learn)
ツール別の確認ポイント
| ツール | 便利な用途 | 管理上の注意点 |
|---|---|---|
| Code Interpreter | データ分析、計算、コード実行 | 実行できる処理範囲、出力ファイル、機密データの扱い |
| File Search | 社内文書検索、ナレッジ検索 | 参照可能なファイル、ベクトルストア、権限分離 |
| Web Search | 最新情報の取得 | 外部情報の信頼性、引用、社内情報との混同 |
| Hosted MCP | GitHubなど外部サービス連携 | 接続先、承認フロー、操作権限 |
| Image Generation | 画像生成、UI案作成 | ブランド利用、著作権、生成物のレビュー |
| Local MCP | 社内ツール連携 | 実行環境、ネットワーク、認証情報の漏えい防止 |
特にMCP連携は、エージェントが外部ツールを呼び出す入口になります。GitHub、チケット管理、社内DB、ナレッジ基盤などにつなぐ場合は、「読めるだけ」なのか「書き込みや実行もできる」のかを明確に分けてください。
Assistants API利用中の移行チェックリスト
OpenAI Assistants APIを使っている場合は、早めに棚卸しが必要です。OpenAIの公式移行ガイドでは、Assistants APIからResponses APIへ移行する流れとして、既存Assistantの指示やツール構成をPromptに移し、新しいユーザーチャットをConversationsとResponsesに移す方針が示されています。(OpenAI Developers)
移行前に確認すること
| チェック項目 | 確認内容 |
|---|---|
| Assistantの一覧 | どのAssistantが本番利用中か |
| Instructions | システム指示、業務ルール、禁止事項 |
| Tools | File Search、Code Interpreter、Function callingなど |
| Threads | 会話履歴を保持しているか |
| Runs | 非同期実行やポーリング処理があるか |
| ファイル・ベクトルストア | 移行後も同じ検索体験を再現できるか |
| 監査ログ | 誰が、いつ、どのツールを使ったか追跡できるか |
移行で失敗しやすいポイント
Assistants APIからResponses APIへの移行では、次の点でつまずきやすくなります。
| 失敗例 | 対策 |
|---|---|
| Assistant IDを前提にした設定がコード内に散在している | 設定ファイルや環境変数に集約する |
| Threadの履歴移行を後回しにする | 新規会話から先に移行し、必要な履歴だけ段階的に移す |
| Runのポーリング処理をそのまま残す | Responsesの実行モデルに合わせて処理を見直す |
| ツール呼び出しの承認設計がない | Tool Approvalや操作権限を事前に定義する |
| 検証環境だけで成功して本番権限を確認していない | 本番相当の権限・ネットワーク・データでテストする |
移行は一括切り替えよりも、新規会話からResponsesに寄せ、既存会話や履歴は必要に応じて段階移行する方が安全です。
Semantic Kernel利用者が見るべき違い
Microsoft Agent Frameworkは、Semantic KernelのAgent Frameworkから移行する利用者向けのガイドも用意しています。移行ガイドでは、Microsoft Agent Frameworkの利点として、APIの簡素化、オブジェクト作成やメモリ使用の最適化、AIプロバイダー間で一貫したインターフェース、開発者体験の改善が挙げられています。(Microsoft Learn)
Semantic Kernelから移行する場合、単純な名前空間の置き換えだけでなく、Agentの作成方法、Sessionの扱い、Hosted Agentのクリーンアップ方法が変わる可能性があります。
Semantic Kernelからの主な見直しポイント
| 項目 | 見直し内容 |
|---|---|
| 名前空間 | Microsoft.SemanticKernel中心からMicrosoft.Agents.AI中心へ |
| Agent作成 | Kernel依存の設計から、各プロバイダーの拡張メソッド中心へ |
| Session | 呼び出し側がThread種別を意識する設計から、AgentがSessionを作る設計へ |
| 型 | Microsoft.Extensions.AIのメッセージ・コンテンツ型との関係を確認 |
| Hosted Agent | クラウド側リソースの作成・取得・削除フローを確認 |
既存のSemantic Kernelアプリを抱えているチームは、まず「エージェント作成」「会話履歴」「ツール呼び出し」「認証」の4点だけに絞って差分を確認すると、移行計画を立てやすくなります。
管理者向け：展開前に確認すべき設定
OpenAI Agentsの更新は開発者だけの問題ではありません。管理者は、エージェントがどのデータにアクセスし、どのツールを実行し、どの認証情報で動くかを把握する必要があります。
展開前チェックリスト
| 分類 | チェック内容 |
|---|---|
| API選定 | 新規開発がResponses中心になっているか |
| 既存連携 | Chat Completions継続の理由が明確か |
| Assistants | Assistants API依存が残っていないか |
| Azure設定 | azure_endpoint、api_version、credentialが明示されているか |
| 環境変数 | OpenAI用とAzure OpenAI用が混在していないか |
| 認証 | 本番でManaged Identityなど明示的な認証を使っているか |
| ツール | Web検索、ファイル検索、MCP、コード実行の許可範囲が定義されているか |
| ログ | プロンプト、ツール呼び出し、エラー、利用量を追跡できるか |
| コスト | ツール利用やファイル検索による追加コストを監視できるか |
| 利用ルール | 業務データ、個人情報、機密情報の扱いが明文化されているか |
特に本番運用では、「動くこと」よりも「意図した権限だけで動くこと」が重要です。AIエージェントは通常のチャットボットよりも外部ツールへの接続範囲が広くなりやすいため、最小権限で設計してください。
開発者向け：移行・実装の進め方
開発チームは、いきなり全面的に書き換えるよりも、影響範囲を小さく分けて移行するのが現実的です。
推奨する進め方
| 手順 | やること |
|---|---|
| 現状調査 | 使っているAPI、SDK、クラス名、環境変数を一覧化 |
| 方針決定 | 新規はResponses、既存Chat Completionsは維持または移行判断 |
| 小さなPoC | 代表的な1機能をResponsesで再実装 |
| ツール確認 | File Search、Web Search、MCPなど必要なツールを検証 |
| 認証確認 | ローカル、検証、本番で接続先と権限を確認 |
| ログ確認 | 失敗時に原因を追えるログを整備 |
| 段階展開 | 新規会話や一部ユーザーから切り替える |
| 旧実装整理 | Assistants APIや旧クラス名を削除する計画を立てる |
PoCでは、難しい業務全体を再現する必要はありません。まずは「社内文書を1つ検索して回答する」「Web検索結果を要約する」「Function Toolを1つ呼び出す」といった小さな単位で、Responsesクライアントの動作、権限、ログを確認するとよいでしょう。
利用者への影響をどう説明するか
エンドユーザーにとって、OpenAI Agentsの更新はAPI名の変更としては見えません。しかし、社内AIチャットや業務エージェントを使っている利用者には、次のような形で影響が出る可能性があります。
| 利用者に見える変化 | 背景 |
|---|---|
| ファイルを参照した回答が増える | File Searchの活用 |
| 最新情報を含む回答が可能になる | Web Searchの活用 |
| 計算やデータ処理が正確になる | Code Interpreterの活用 |
| 外部システムと連携した回答が増える | MCPやFunction Toolsの活用 |
| 一部操作で承認が求められる | Tool Approvalや権限管理 |
利用者向けには、「AIができることが増えます」だけでなく、「どの情報を参照するのか」「外部ツールを使う場合にどの操作が行われるのか」「機密情報を入力してよい範囲はどこまでか」を説明する必要があります。
今回の更新で取るべき次の行動
MicrosoftのOpenAI Agents更新で最初にやるべきことは、現在のエージェント実装を棚卸しし、Responsesへ寄せるべきものとChat Completionを維持するものを分けることです。
新規開発ではResponsesを第一候補にし、既存のChat Completions連携は「なぜ残すのか」を明確にします。Assistants APIを使っている場合は、停止予定日を待たずに移行計画を作り、Assistant、Thread、Run、Tools、Files、認証、ログを順番に確認してください。
管理者は環境変数、Azureルーティング、認証方式、ツールの許可範囲を点検します。開発者は旧クラス名、model指定、ResponsesとChat Completionのツール差分を確認します。利用部門には、AIエージェントが参照できる情報と実行できる操作を分かりやすく共有します。
OpenAI Agentsは、単なるチャット機能ではなく、業務システムとAIをつなぐ実行基盤に近づいています。だからこそ、早い段階でResponses中心の設計、最小権限のツール管理、段階的な移行計画を整えることが、安定したAI活用につながります。
コメント