Microsoft Foundry / Azure OpenAIでAIエージェントを設計するなら、2026年4月更新ポイントの核心は「agents」「conversations」「responses」を別々の役割として理解することです。従来のチャットAPIの延長で実装すると、状態管理、ツール実行、監査、データ保持の設計でつまずきやすくなります。
Microsoft Learnの「Build with agents, conversations, and responses」は、Foundry Agent Serviceの実行時コンポーネントを整理した公式ドキュメントです。MicrosoftDocsリポジトリ上では2026年4月23日にも該当ファイルへの更新履歴が確認でき、2026年4月時点の実装方針を把握するうえで重要な資料といえます。(GitHub)
結論から言うと、実務では「agentは振る舞いの定義」「conversationは状態の保管場所」「responseは1回の実行結果」と分けて考えるべきです。この分離により、カスタマーサポート、社内ナレッジ検索、業務自動化、マルチターンのAIアシスタントを、より運用しやすい形で設計できます。Microsoftの公式ドキュメントでも、Foundry Agent Serviceはagents、conversations、responsesの3つの中核コンポーネントでステートフルな複数ターンの対話を実現すると説明されています。(Microsoft Learn)
Microsoft Foundry / Azure OpenAIの2026年4月更新で押さえるべき全体像
今回の更新で読み取るべきポイントは、単に「エージェントが使えるようになった」という話ではありません。Microsoft Foundry Agent Serviceは、Azure OpenAIのResponses APIを軸に、エージェントの定義、会話履歴、ツール呼び出し、長時間処理、メモリを組み合わせる設計へ寄っています。
特に重要なのは、次の3点です。
| 観点 | これまでありがちだった実装 | 2026年4月時点で意識したい設計 |
|---|---|---|
| 状態管理 | アプリ側で会話履歴をすべて連結して渡す | conversationまたはprevious_response_idを使い分ける |
| エージェント定義 | プロンプトを都度リクエストに埋め込む | agentを名前付き・バージョン付きの資産として管理する |
| 実行結果 | テキストだけを見る | responseの出力、ツール呼び出し、ステータスを確認する |
| 運用 | PoC単位で個別実装 | セキュリティ、保持期間、ツール権限、監査を前提に設計する |
Microsoftの移行ガイドでも、新しいAgentsの開発体験はResponses APIを土台にしており、ThreadsはConversationsへ、RunsはResponsesへ置き換わる流れが示されています。(Microsoft Learn)
agents、conversations、responsesの違い
Foundry Agent Serviceを理解するうえで、最初に混同しやすいのがこの3つです。名前は似ていますが、責務は明確に異なります。
| コンポーネント | 役割 | 実務での見方 |
|---|---|---|
| agent | モデル、指示、ツール、パラメーターなどをまとめた実行定義 | 「どんなAI担当者にするか」を決める設定ファイルに近い |
| conversation | メッセージ、ツール呼び出し、ツール出力などを保持する永続的な会話オブジェクト | 「このユーザーとのやり取り履歴」を管理する場所 |
| response | 入力を処理した結果として生成される出力 | 「今回のAI実行結果」として扱う単位 |
agentは「AI担当者の定義」
agentは、単なるプロンプトではありません。Microsoftの公式ドキュメントでは、agentはAIモデル、instructions、code、tools、parameters、必要に応じたsafetyやgovernance controlsを組み合わせた永続的なオーケストレーション定義と説明されています。また、agentはMicrosoft Foundry内で名前付き・バージョン付きの資産として保存されます。(Microsoft Learn)
実務では、たとえば次のように考えると分かりやすくなります。
| agentの例 | 主なinstructions | 付与するtoolの例 |
|---|---|---|
| 社内ITヘルプデスクagent | Microsoft 365、VPN、端末トラブルの一次回答を行う | File Search、Function calling |
| 営業支援agent | 顧客情報を確認し、商談準備メモを作る | CRM API、Web search |
| セキュリティ運用agent | アラート内容を要約し、初動対応案を出す | SIEM API、社内Runbook検索 |
ポイントは、agentを「毎回のリクエストで使い捨てるプロンプト」として扱わないことです。プロダクトオーナーやIT管理者が管理すべき業務ロールとして、命名、バージョン管理、権限管理を行う必要があります。
なお、公式ドキュメントでは、agentsは従来のようなGUID形式のAgentIDではなく、agent nameとagent versionで識別されると明記されています。既存実装を移行する場合は、この識別方法の変更に注意が必要です。(Microsoft Learn)
conversationsは「履歴と状態の置き場所」
conversationは、単なるチャット履歴ではありません。Microsoftの説明では、conversationは一意のIDを持つ永続的なオブジェクトで、作成後はセッションをまたいで再利用できます。また、messageだけでなく、tool calls、tool outputs、その他のデータもitemsとして保存できます。(Microsoft Learn)
たとえば、社内ヘルプデスクのAIアシスタントで次の流れがあるとします。
- ユーザーが「Outlookでメールが送れない」と質問する
- agentが過去の障害情報を検索する
- toolがMicrosoft 365のステータスや社内FAQを返す
- agentが回答する
- ユーザーが「さっきの手順2が分からない」と続ける
このときconversationを使っていれば、「さっき」が何を指すかを扱いやすくなります。さらに、tool callやtool outputも履歴として確認できるため、なぜその回答になったのかを後から追いやすくなります。
ただし、conversationを使えば無限にすべての文脈をモデルが読めるわけではありません。公式ドキュメントでは、conversationがモデルの対応するコンテキストサイズを超えた場合、conversation自体は切り詰められないものの、response生成に使われる入力コンテキストは自動的に一部へ切り詰められると説明されています。長期間の会話では、要約、検索、メモリ、業務データベースを組み合わせる設計が必要です。(Microsoft Learn)
responsesは「1回の実行結果」
responseは、agentまたは直接指定した構成に対して入力を渡したときに返ってくる実行結果です。agentの設定、conversationの履歴、リクエスト時のinstructions、toolの結果などを踏まえて生成されます。
Microsoftのドキュメントでは、response生成時にagentが設定と履歴を使ってモデルやtoolを呼び出し、必要に応じてconversationへitemsを追加すると説明されています。また、agentを定義せずにresponseだけを生成することも可能で、シンプルな用途や最小限のtoolだけを使う場面に向いています。(Microsoft Learn)
responseで重要なのは、output_textだけを見て終わらないことです。toolを使うagentでは、response outputにweb search、function call、file searchなどのtool call itemsが含まれることがあります。運用では「最終回答」だけでなく、「どのtoolを呼んだか」「toolの結果をどう使ったか」も確認できるようにしておくべきです。(Microsoft Learn)
実務で変わるポイント：ThreadsとRunsの発想から抜け出す
既存のAzure OpenAI Assistants APIや古いagent実装に慣れているチームほど、移行時に混乱しやすいのが用語の変化です。
| 旧来の考え方 | 新しいFoundry Agent Serviceでの考え方 | 実務上の意味 |
|---|---|---|
| Thread | Conversation | 履歴はmessageだけでなく、tool callやoutput itemも含む |
| Run | Response | 実行単位はresponseとして扱い、ステータスや出力を確認する |
| Assistant / classic agent | New agent | 名前・バージョン・ツール・ガバナンスを持つ資産として管理する |
この変更は、単なる名称変更ではありません。AIエージェントを「チャットの延長」ではなく、「状態を持つ業務アプリケーション」として扱うための整理です。
IT管理者にとっては、以下の観点で設計レビューが必要になります。
| レビュー項目 | 確認すべきこと |
|---|---|
| agentの所有者 | 誰がinstructionsやtoolsを変更できるか |
| conversationの保持 | ユーザーごとの履歴をどの範囲で保存するか |
| responseの保存 | previous_response_idを使うか、store=falseでアプリ側管理にするか |
| tool権限 | agentが参照・実行できる外部サービスを最小限にしているか |
| 監査 | tool call、tool output、最終回答を追跡できるか |
状態管理の選び方：conversation、previous_response_id、store=false、memory
Foundry Agent Serviceで最も実務差が出るのは、状態管理の設計です。どれを使うべきかは、ユースケースとデータポリシーで決まります。
| 選択肢 | 向いている場面 | 注意点 |
|---|---|---|
| conversation | 複数ターンのチャット、セッション再開、tool履歴の確認 | 長い会話ではコンテキスト切り詰めを前提にする |
| previous_response_id | 直前のresponseを引き継ぐ軽量なマルチターン | 分岐や長期履歴の管理には設計が必要 |
store=false | データ保持を最小化したい、アプリ側で履歴管理したい | 次のリクエストに必要な文脈を自分で渡す必要がある |
| memory | ユーザー嗜好や過去の要約をセッション横断で使いたい | preview機能のため、本番利用では条件確認が必要 |
Responses APIでは、既定でresponse historyがサーバー側に保存され、previous_response_idで複数ターンの文脈を参照できます。一方で、store=falseを指定するとservice側にresponseを永続化せず、アプリケーション側で前回出力などを引き継ぐ必要があります。これは、データ保持を抑えたい場合や、zero-data-retentionに近い運用要件を持つ場合に検討される選択肢です。(Microsoft Learn)
memoryはconversationとは別の概念です。conversationは主に会話の流れを保持しますが、memoryはセッションをまたいでユーザー嗜好や過去の要約などを長期的に活用するための仕組みです。Microsoft Foundry Agent Serviceのmemoryはpreviewとして提供され、user profile memoryやchat summary memoryといった長期記憶の用途が説明されています。(Microsoft Learn)
最小実装イメージ：agent、conversation、responseをつなぐ
実装の流れは、難しく考えすぎる必要はありません。基本形は次の順序です。
| 手順 | 内容 | 実装上のポイント |
|---|---|---|
| agentを作る | 名前、モデル、instructions、toolsを定義する | 業務ロールごとに分ける |
| conversationを作る | ユーザーまたは業務単位の会話を開始する | 再利用するならID管理が必要 |
| responseを生成する | inputとagent reference、conversation IDを渡す | 出力だけでなくstatusも確認する |
| follow-upを送る | 同じconversationに追加質問を渡す | 文脈が引き継がれる |
| 必要に応じてstream/backgroundを使う | リアルタイム表示や長時間処理に対応する | UIとポーリング設計が必要 |
REST APIで考えると、概念的には次のような流れになります。
# 1. conversationを作成
curl -X POST "${ENDPOINT}/openai/v1/conversations" \
-H "Authorization: Bearer ${ACCESS_TOKEN}" \
-H "Content-Type: application/json" \
-d '{}'
# 2. agentを参照してresponseを生成
curl -X POST "${ENDPOINT}/openai/v1/responses" \
-H "Authorization: Bearer ${ACCESS_TOKEN}" \
-H "Content-Type: application/json" \
-d '{
"input": "社内VPNに接続できない場合の初動対応を教えてください",
"conversation": "CONVERSATION_ID",
"agent_reference": {
"name": "it-helpdesk-agent",
"type": "agent_reference"
}
}'この例で重要なのは、instructionsやtoolsを毎回すべてリクエストに詰め込まないことです。業務ごとの振る舞いはagent側へ寄せ、ユーザーとのやり取りはconversationで管理し、個々の実行結果をresponseとして確認します。
streamingとbackground responsesの使い分け
ユーザー体験を改善するなら、responseの返し方も設計対象になります。
| モード | 向いている用途 | 例 |
|---|---|---|
| 通常response | 短い回答、即時処理 | FAQ回答、短文要約 |
| streaming | 生成中の文章をリアルタイム表示したい | チャットUI、長文ドラフト作成 |
| background | 長時間処理を非同期で実行したい | 複雑な分析、画像生成、複数toolを使う処理 |
公式ドキュメントでは、長時間処理ではstreamingで部分結果を返すか、background modeで非同期実行し、完了までresponse statusを監視する流れが示されています。background modeではbackground=trueを指定し、queuedやin_progressの状態が終わるまでpollingします。(Microsoft Learn)
実務では、チャットボットだからといってすべてstreamingにする必要はありません。社内承認、データ分析、調査レポート生成のように時間がかかる処理では、backgroundでジョブ化し、完了通知や履歴画面から結果を確認できる設計のほうが安定します。
tool利用で確認すべきセキュリティとガバナンス
agentにtoolを付けると、単なる文章生成を超えて、Web検索、ファイル検索、コード実行、外部API呼び出しなどが可能になります。これは便利ですが、同時にリスクも増えます。
Microsoftのtool overviewでは、toolsはagentが会話中に特定タスクを実行するために呼び出す能力であり、Web検索、Pythonコード実行、ドキュメント検索、外部API呼び出しなどに使えると説明されています。built-in toolsとcustom toolsの分類も示されています。(Microsoft Learn)
特にIT管理者は、次の点を必ず確認してください。
| 確認項目 | 失敗しやすい例 | 推奨される対応 |
|---|---|---|
| 最小権限 | agentが不要なAPIやデータソースにアクセスできる | toolごとに権限を分離する |
| 機密情報 | promptやconversation historyにシークレットを直接書く | Key Vaultや接続情報管理を使う |
| 外部送信 | non-Microsoft serviceにデータが流れる可能性を見落とす | データ分類と送信先を明示する |
| tool output | 検索結果やAPIレスポンスに個人情報が含まれる | ログ、マスキング、保持期間を設計する |
| 監査 | 最終回答だけ保存し、tool callを追えない | response output itemsを確認できるようにする |
公式ドキュメントでも、conversationやresponseにはユーザー提供コンテンツやtool outputが永続化され得るため、runtime dataをアプリケーションデータと同じように扱い、promptやconversation historyにシークレットを保存しないこと、tool accessを最小権限にすること、non-Microsoft serviceへのデータ流出に注意することが示されています。(Microsoft Learn)
Product Ownerが見るべきユースケースの優先順位
Microsoft Foundry / Azure OpenAIのAgent Serviceは強力ですが、最初から全社横断の巨大agentを作るのはおすすめしません。最初は「状態管理の価値があり、tool利用の範囲を制御しやすい」ユースケースから始めるべきです。
| 優先度 | ユースケース | 理由 |
|---|---|---|
| 高 | 社内ITヘルプデスク | ナレッジ検索、複数ターン対応、エスカレーション設計と相性がよい |
| 高 | カスタマーサポート一次回答 | conversationとmemoryの価値が分かりやすい |
| 中 | 営業・CS向け顧客メモ作成 | CRM連携が必要なためtool権限設計が重要 |
| 中 | インシデント初動支援 | Runbook検索やログ要約に向くが、誤操作防止が必要 |
| 低〜中 | 完全自律の業務実行agent | 承認、監査、例外処理の設計が重くなりやすい |
最初のPoCでは、「回答品質」だけで成功判断をしないことが重要です。以下のような運用品質も評価してください。
| 評価観点 | チェック内容 |
|---|---|
| 再現性 | 同じ業務入力に対して、一貫した手順で回答できるか |
| 追跡性 | tool call、検索結果、最終回答の関係を確認できるか |
| 安全性 | 権限外のデータや操作にアクセスしないか |
| 継続性 | 複数ターンや再訪問時に文脈を適切に扱えるか |
| 移行性 | 既存のAssistants API、チャットAPI、社内Botから移行しやすいか |
導入時に失敗しやすいポイント
conversationを長期メモリ代わりに使う
conversationは履歴管理には有効ですが、長期的なユーザー嗜好や過去セッションの要約を扱うにはmemoryのほうが適する場合があります。逆に、memoryを使えばconversation設計が不要になるわけでもありません。
短期の会話文脈はconversation、長期のユーザー情報はmemory、組織の正しい情報源はFoundry IQやFile Searchのようなナレッジ基盤、と役割を分けるのが実務的です。
store=falseを設定したのに文脈を渡し忘れる
データ保持を抑える目的でstore=falseを使う場合、次回リクエストに必要な文脈をアプリ側で渡す必要があります。これを忘れると、ユーザーからは「さっきの話を覚えていないAI」に見えます。
データ保持ポリシーを優先するなら、アプリ側で履歴要約、必要最小限の文脈、削除フローをきちんと設計しましょう。
最終回答だけをログに残す
agentがtoolを使う場合、最終回答だけでは検証できません。なぜその回答になったのかを確認するには、tool call、tool output、response status、conversation itemsを見る必要があります。
特にIT adminsは、監査ログやトラブルシューティングの観点から、response全体をどう扱うかを設計に含めるべきです。
agentのバージョン管理を軽視する
業務agentのinstructionsを変更すると、回答方針やtoolの使い方が変わります。これはプロンプト修正ではなく、業務ロジックの変更に近いものです。
本番運用では、少なくとも以下を管理してください。
| 管理対象 | 理由 |
|---|---|
| agent name | 業務用途を識別するため |
| agent version | 変更前後の挙動を比較するため |
| instructions | 回答方針や禁止事項を明確にするため |
| tools | 外部データ・外部操作への接続点になるため |
| 評価データ | 更新後に品質劣化していないか確認するため |
既存環境から移行する場合の進め方
既存のAzure OpenAI Assistants API、独自チャットBot、社内AIアシスタントから移行する場合は、コードを書き換える前に棚卸しを行いましょう。
| 移行ステップ | 作業内容 |
|---|---|
| 既存Botの役割を整理する | 何を回答し、どのデータを参照し、どの操作をするかを洗い出す |
| agent単位に分割する | 1つの巨大agentではなく、業務単位でagentを設計する |
| 状態管理を決める | conversation、previous_response_id、store=false、memoryの使い分けを決める |
| tool権限を定義する | 参照のみ、実行可能、承認必須などを分ける |
| 評価シナリオを作る | よくある質問、例外ケース、権限外要求をテストする |
| ログと監査を設計する | response output items、tool call、conversation履歴を確認できるようにする |
移行で最も避けたいのは、「旧Botのプロンプトをagent instructionsに貼り付けるだけ」で終えることです。Foundry Agent Serviceでは、agent、conversation、response、tool、memoryの責務が分かれているため、設計も分けて見直す必要があります。
IT管理者・プロダクトオーナー向け導入チェックリスト
本番導入前に、次の項目を確認してください。
| 項目 | 確認ポイント |
|---|---|
| 対象業務 | agent化する業務範囲が明確か |
| データ分類 | conversationやtool outputに含まれる情報の分類を決めたか |
| 認証 | Microsoft Entra IDやDefaultAzureCredentialを前提に設計しているか |
| 権限 | agentとtoolの権限が最小限になっているか |
| 状態管理 | conversation、previous_response_id、store=false、memoryの使い分けを決めたか |
| 応答方式 | 通常、streaming、backgroundの選択基準があるか |
| 監査 | tool callとresponse outputを確認できるか |
| 運用 | agent version、変更履歴、評価データを管理できるか |
| グローバル対応 | リージョン、モデル可用性、データ所在の要件を確認したか |
| 例外処理 | tool失敗、長時間処理失敗、権限不足時のUIを設計したか |
特にグローバル展開する場合、モデル、region、tool support、streaming availabilityなどは時期や環境で変わる可能性があります。公式ドキュメントでも、limitsやconstraintsはモデル、region、付与するtoolによって依存する可能性があると説明されています。(Microsoft Learn)
まとめ：次にやるべきこと
Microsoft Foundry / Azure OpenAIの2026年4月更新ポイントは、AIエージェントを「1回のチャット応答」ではなく、「状態を持ち、toolを使い、運用管理される業務アプリケーション」として扱う方向へ進んでいることです。
まずは、次の順序で進めるのが現実的です。
| 次のアクション | 目的 |
|---|---|
| 既存BotやAI活用テーマを棚卸しする | agent化に向く業務を見極める |
| agents、conversations、responsesの責務を設計書に分ける | 実装と運用の混乱を防ぐ |
| 小さな業務agentでPoCする | 状態管理とtool利用の実効性を確認する |
| セキュリティ・保持・監査を先に決める | 本番化で手戻りを減らす |
| version管理と評価データを整備する | agent改善を継続可能にする |
最初に作るべきなのは、万能agentではありません。履歴が役立ち、参照するデータが明確で、失敗時の影響を制御しやすい業務agentです。たとえば社内ITヘルプデスクやカスタマーサポート一次回答から始めると、Foundry Agent Serviceのagents、conversations、responsesの価値を実務で検証しやすくなります。
コメント