2026年4月30日に反映されたAzure AI関連の公式ドキュメント更新「fixing code」で、最も確認すべき点は、Microsoft Foundry agentsのFunction Callingサンプルが、関数実行後の継続処理でprevious_response_idではなくconversation.idを使う形に修正されたことです。対象はAzure AI全体の仕様変更というより、MicrosoftDocs/azure-ai-docs内のFunction Calling実装例の修正です。ただし、過去の公式サンプルを参考にしてエージェント機能を実装している場合、実行結果が返らない、会話履歴がつながらない、ツール出力後に最終回答が生成されない、といった不具合の確認ポイントになります。(GitHub)
開発者はコード差分を、クラウド管理者は運用・監視・権限を、アーキテクトや技術意思決定者は移行計画と既存設計への影響を確認するのが安全です。特に、Function Callingを使って外部API、社内データ、業務システムを呼び出すエージェントを構築している場合は、単なるドキュメント修正として流さず、ステージング環境で再テストしておきましょう。
Azure AIの公式ドキュメント更新「fixing code」で何が変わったか
今回の更新は、GitHub上のMicrosoftDocs/azure-ai-docsリポジトリで確認できる公式ドキュメント更新です。コミット件名は「fixing code」で、対象ファイルはarticles/foundry/agents/how-to/tools/function-calling.mdです。差分としては1ファイルの変更で、14行追加、4行削除となっています。(GitHub)
主な変更点は、Microsoft Foundry agentsでFunction Callingを使うサンプルコードにおいて、会話を明示的に作成し、そのconversation.idを初回応答と関数実行後の応答に渡すようになった点です。あわせて、クリーンアップ処理でconversationを削除するコードも追加されています。(GitHub)
| 確認項目 | 更新前の傾向 | 更新後に確認すべき点 |
|---|---|---|
| ドキュメント日付 | ms.dateが2026年3月30日 | ms.dateが2026年4月30日に更新 |
| Pythonサンプル | 関数実行後にprevious_response_idで継続 | conversation = openai.conversations.create()を作成し、conversation.idで継続 |
| JavaScriptサンプル | 関数実行後にprevious_response_idを使用 | conversationを作成し、初回・最終応答の両方に渡す |
| クリーンアップ | agent削除のみが中心 | agentに加えてconversation削除も追加 |
| トラブルシューティング | previous_response_idで継続する説明 | tool output後はconversation IDで継続する説明に修正 |
この更新から読み取れる実務上の要点は、Function Callingを「1回の応答処理」ではなく、conversationを軸にした複数ステップの実行フローとして扱うべきだという点です。
一番重要な確認点はprevious_response_idからconversation.idへの変更
今回の更新で最も見落としやすいのは、previous_response_idそのものが完全に不要になった、という意味ではない点です。Microsoft Foundry Agent Serviceのランタイム説明では、conversationは複数ターンの履歴を保持し、conversationを使わない場合はprevious responseを使って文脈を引き継げると説明されています。(Microsoft Learn)
しかし、今回修正されたFunction Callingサンプルでは、関数呼び出しの結果をモデルに返して最終応答を生成する場面で、previous_response_idではなくconversation.idを渡す形に変更されています。つまり、Function Callingのツール出力を返す実装では、公式サンプルに合わせてconversationベースの流れを確認する必要があるということです。(GitHub)
Pythonで確認すべき実装イメージ
openai = project.get_openai_client()
# 複数ターンのやり取り用にconversationを作成
conversation = openai.conversations.create()
# 初回の応答生成
response = openai.responses.create(
input="What is my horoscope? I am an Aquarius.",
conversation=conversation.id,
extra_body={
"agent_reference": {
"name": agent.name,
"type": "agent_reference"
}
},
)
# function_call_outputを作成した後、同じconversationで最終応答を生成
response = openai.responses.create(
input=input_list,
conversation=conversation.id,
extra_body={
"agent_reference": {
"name": agent.name,
"type": "agent_reference"
}
},
)見るべきポイントは、初回のresponses.createと、関数結果を返す2回目のresponses.createで、同じconversation.idを使っているかです。片方だけにconversationを渡している、または途中で別のconversationを作っている場合、会話履歴やツール呼び出しの文脈が期待通りにつながらない可能性があります。
JavaScript / TypeScriptで確認すべき実装イメージ
const openai = project.getOpenAIClient();
// 複数ターンのやり取り用にconversationを作成
const conversation = await openai.conversations.create();
// 初回の応答生成
const response = await openai.responses.create(
{
input: [
{
role: "user",
content: "What is my horoscope? I am an Aquarius.",
},
],
conversation: conversation.id,
},
{
body: {
agent: {
name: agent.name,
type: "agent_reference",
},
},
},
);
// function_call_outputを返して最終応答を生成
const finalResponse = await openai.responses.create(
{
input: inputList,
conversation: conversation.id,
},
{
body: {
agent: {
name: agent.name,
type: "agent_reference",
},
},
},
);JavaScript / TypeScript側でも、確認の軸は同じです。previous_response_idでつないでいた箇所がある場合は、Function Callingの流れにおいてconversationを使うべき箇所かどうかを切り分けてください。
影響を受けやすいケース
今回のAzure AI公式ドキュメント更新は、すべてのAzure AI利用者に直接影響するものではありません。影響を受けやすいのは、Microsoft Foundry agentsのFunction Callingを使っている、またはこれから実装するチームです。
| 利用状況 | 影響度 | 確認内容 |
|---|---|---|
| 公式サンプルをコピーしてFunction Callingを実装している | 高 | previous_response_idを使っている箇所を検索し、conversationベースに修正する |
| エージェントが外部APIや社内関数を呼び出す | 高 | tool output返却後に最終回答が生成されるかテストする |
| Azure AI Foundry / Microsoft Foundry agentsを検証中 | 中 | 新しいサンプルを前提にPoCコードを作り直す |
| ポータル中心で、Function Callingをコード実装していない | 低〜中 | ポータルだけでは関数定義の追加・更新に制限がある点を確認する |
| Azure OpenAIの通常のチャット補完のみを使っている | 低 | 今回の差分が自社コードに関係するかを確認する程度でよい |
公式ドキュメントでは、Microsoft Foundry portalでFunction toolsを使ったエージェント実行はできる一方、エージェント上の関数定義の追加・削除・更新はポータルではサポートされず、SDKまたはREST APIを使う必要があると説明されています。(Microsoft Learn)
開発者が確認すべきコードレビュー項目
Function Callingを実装している開発者は、まずリポジトリ全体で以下の文字列を検索してください。
previous_response_id
function_call_output
conversation
responses.create
agent_reference検索結果が出たら、単に置換するのではなく、どのフローで使われているかを確認します。previous_response_idが通常のフォローアップ質問で使われている場合と、Function Callingのツール出力後に使われている場合では、見直しの優先度が変わります。
最低限チェックしたい実装ポイント
| チェック項目 | 確認する理由 |
|---|---|
| conversationを作成しているか | Function Callingの一連の流れを同じ会話として扱うため |
初回のresponses.createにconversationを渡しているか | tool callの文脈をconversationに保持するため |
tool output後のresponses.createにも同じconversationを渡しているか | 関数結果から最終回答を生成するため |
call_idを正しく返しているか | モデルがどの関数呼び出しの結果か判断するため |
| 複数のfunction callを処理できるか | 1回の応答で複数ツールが要求される可能性があるため |
| conversationの削除処理があるか | 検証環境や一時利用で不要なリソースを残さないため |
公式ドキュメントのトラブルシューティングでも、エージェントが関数呼び出しを返すが最終回答を返さない場合、tool outputをモデルに返していないことが原因として挙げられ、responses.createにtool outputとconversation IDを渡して継続する説明になっています。(Microsoft Learn)
クラウド管理者が確認すべき運用影響
クラウド管理者は、コード差分だけでなく、実行環境・認証・ログ・リソース管理を確認する必要があります。Function Callingは、モデルが関数を直接実行するのではなく、アプリケーション側が関数を実行し、その結果をモデルに返す仕組みです。つまり、外部APIや社内システムへのアクセス権限、実行ログ、エラー時の扱いが運用品質に直結します。
運用で見落としやすいポイント
| 項目 | 確認すべき内容 |
|---|---|
| 認証 | DefaultAzureCredentialなどで使うIDに過剰な権限が付いていないか |
| シークレット管理 | tool outputにAPIキー、接続文字列、トークンを含めていないか |
| ログ | function call、tool output、最終応答の各段階を追跡できるか |
| タイムアウト | 長時間処理を同期的に待ち続けていないか |
| リソース削除 | 検証用agentやconversationを残し続けていないか |
| 監視 | 関数呼び出しが発生したか、失敗したかをトレースできるか |
公式ドキュメントでは、tool argumentsやtool outputsを信頼できない入力として扱い、値の検証・サニタイズを行うこと、tool outputにシークレットを渡さないこと、DefaultAzureCredentialで使うIDに最小権限を適用することが示されています。(Microsoft Learn)
また、実行は作成後10分で期限切れになるため、長時間かかる処理はすぐにステータスを返し、ポーリングなどの方式を検討する必要があります。(Microsoft Learn)
ソリューションアーキテクトが見るべき設計上のポイント
ソリューションアーキテクトは、今回の更新を「サンプルコードの修正」としてだけでなく、Azure AIを使ったエージェント設計の見直しポイントとして捉えるとよいでしょう。
特に重要なのは、Function Callingを使うエージェントを、単発のAPI呼び出しではなく、以下のような状態遷移を持つワークフローとして設計することです。
ユーザー入力
↓
エージェント応答生成
↓
function_callの発生
↓
アプリケーション側で関数を実行
↓
function_call_outputを返却
↓
同じconversationで最終応答を生成
↓
必要に応じてconversationを継続または削除この流れを設計に落とし込むと、以下の判断がしやすくなります。
| 設計判断 | 判断基準 |
|---|---|
| conversationをどこで作るか | ユーザーセッション単位、業務トランザクション単位、問い合わせ単位のどれで履歴を保持するか |
| いつ削除するか | 一時的な検証か、継続的な会話履歴が必要か |
| function callをどこで実行するか | アプリケーションサーバー、API Gateway、バックエンドジョブのどれが安全か |
| エラー時にどう返すか | ユーザーに説明可能なエラーを返すか、システム側でリトライするか |
| 監査ログをどこに残すか | 入力、関数呼び出し、外部API結果、最終応答をどの粒度で保存するか |
会話履歴を保持するconversationは便利ですが、業務データや個人情報を扱う場合は、保持期間、削除条件、ログ出力範囲を最初に決めておく必要があります。特にグローバル展開を前提にする場合は、リージョン、データ保持、アクセス権限、監査要件を早めに整理しておくべきです。
移行準備として行うべき手順
過去の公式ドキュメントやサンプルコードを参考にしている場合は、次の順序で確認すると効率的です。
| 手順 | 作業内容 | 完了条件 |
|---|---|---|
| 既存コードの棚卸し | previous_response_idとfunction_call_outputを検索する | Function Calling関連の該当箇所を一覧化できている |
| フロー分類 | 通常の会話継続か、tool output後の継続かを分ける | 修正対象と非対象が分かれている |
| conversation導入 | 必要な箇所でconversationを作成・共有する | 初回応答と最終応答で同じconversation IDを使っている |
| ステージング検証 | 実際にfunction callを発生させる | 最終回答が自然文で返る |
| エラー検証 | 不正な引数、関数失敗、タイムアウトを試す | ユーザー向け応答とログが確認できる |
| 運用反映 | 監視、ログ、削除処理を整備する | 本番リリース時の確認項目に入っている |
ここで避けたいのは、previous_response_idを機械的にすべてconversation.idへ置換することです。通常のフォローアップ文脈で使われている箇所まで変更すると、別の不具合を生む可能性があります。あくまで、Function Callingでtool outputを返した後に最終応答を生成する処理を中心に確認してください。
テストで確認すべきシナリオ
Function Callingの実装確認では、成功パターンだけを試しても不十分です。今回の更新を踏まえると、少なくとも次のテストを用意しておくと実務での事故を減らせます。
| テストシナリオ | 確認内容 |
|---|---|
| 正常系 | function callが発生し、関数実行後に最終回答が返る |
| 関数が呼ばれないケース | 関数名、description、パラメーター説明が曖昧でないか |
| JSON不正 | argumentsが想定外でも安全に処理できるか |
| 必須項目不足 | schemaのrequiredやstrict設定が機能するか |
| 複数関数呼び出し | output配列内の複数function callを処理できるか |
| 長時間処理 | 10分制限を前提にステータス返却やポーリングへ逃がせるか |
| クリーンアップ | agentやconversationを削除できるか |
| 権限エラー | IDの権限不足・過剰権限を検知できるか |
公式ドキュメントのトラブルシューティングでも、JSONスキーマ不一致、必須項目不足、複数function call、tool outputの期限切れなどが失敗要因として挙げられています。(Microsoft Learn)
よくある誤解と注意点
「fixing code」は小さな修正なので無視してよい
小さなドキュメント差分でも、公式サンプルの実装方法が変わっている場合は無視できません。特にエージェントやFunction Callingは、サンプルコードをそのままPoCや本番初期実装に使うケースが多いため、公式サンプルの修正は実装レビューのきっかけになります。
previous_response_idはもう使ってはいけない
そう断定するのは危険です。Microsoft Foundry Agent Serviceの説明では、conversationを使わない場合にprevious responseで文脈を引き継ぐ方法も示されています。今回確認すべきなのは、Function Callingのtool output後に最終応答を作る実装で、公式サンプルがconversation IDを使う形に修正された点です。(Microsoft Learn)
Foundry portalだけでFunction Callingを完結できる
portalは確認や実行に役立ちますが、公式ドキュメントでは関数定義の追加・削除・更新にはSDKまたはREST APIを使う必要があると説明されています。運用設計では、ポータル操作だけでなく、コード・CI/CD・権限管理を含めて設計してください。(Microsoft Learn)
tool outputはそのままモデルに渡してよい
tool outputには、社内APIのレスポンス、顧客情報、トークン、接続情報などが混入する可能性があります。公式ドキュメントでも、tool argumentsとtool outputsは信頼できない入力として扱い、シークレットを渡さないことが示されています。(Microsoft Learn)
チーム別の次アクション
| 役割 | すぐに行うこと |
|---|---|
| 開発者 | previous_response_id、function_call_output、conversationを検索し、Function Callingの継続処理を確認する |
| クラウド管理者 | conversation削除、ログ、権限、シークレット混入防止を確認する |
| ソリューションアーキテクト | conversationのライフサイクル、外部API連携、エラー時の業務フローを設計に反映する |
| 技術意思決定者 | PoCコードが古い公式サンプル由来でないか確認し、本番化前の再検証を指示する |
今回のAzure AI公式ドキュメント更新「fixing code」は、派手な新機能追加ではありません。しかし、Function Callingを使う実装では、関数呼び出し後の継続方法がアプリの安定性に直結します。まずは既存コードを検索し、tool output後のresponses.createが公式サンプルどおりconversation IDで継続されているかを確認してください。そのうえで、正常系だけでなく、関数失敗、JSON不正、複数関数呼び出し、タイムアウト、クリーンアップまでテストすれば、Azure AIを使ったエージェント実装をより安全に運用できます。
コメント