Microsoft Foundry / Azure OpenAIのfunction calling更新ポイント｜2026年4月版の実装・運用注意点

Microsoft Foundry / Azure OpenAIで外部APIや社内システムを安全に呼び出したい場合、まず押さえるべき結論は明確です。function callingは「モデルが処理を実行する機能」ではなく、モデルが呼び出すべき関数と引数をJSON形式で提案し、実行判断と実行処理はアプリケーション側が担う仕組みです。2026年4月25日に更新されたMicrosoft公式ドキュメントでは、tools / tool_choiceを使った実装、並列function calling、責任ある利用、対応モデル、旧パラメーターからの移行ポイントが整理されています。IT管理者、プロダクトオーナー、MicrosoftエコシステムでAI機能を設計する担当者は、単なるサンプルコードとしてではなく、業務システム連携の設計指針として読むべき更新です。(Microsoft Learn)

Microsoft Foundry / Azure OpenAIのfunction callingとは

Microsoft Foundry / Azure OpenAIにおけるfunction callingは、チャットモデルに外部ツールや社内APIの使い方を定義し、ユーザーの依頼内容に応じて「どの関数を、どの引数で呼び出すべきか」を判断させる機能です。

たとえば、ユーザーが「東京とサンフランシスコの現在時刻を教えて」と質問した場合、モデルは直接データベースや外部APIへアクセスするわけではありません。アプリケーション側が定義したget_current_timeのような関数情報をもとに、呼び出し対象と引数を返します。その後、アプリケーションが実際の関数を実行し、その結果を再びモデルに渡して、最終回答を生成します。(Microsoft Learn)

この仕組みは、次のような用途で特に有効です。

活用シーン	function callingで実現しやすいこと
社内ナレッジ検索	ユーザーの質問に応じて検索APIを呼び出し、根拠に基づく回答を生成する
業務データ参照	顧客情報、在庫、注文状況などを必要なタイミングで取得する
ワークフロー自動化	チケット作成、通知送信、承認依頼などの処理を会話から起動する
管理者向けアシスタント	Azureリソース、ログ、監視情報などを条件に応じて照会する

重要なのは、モデルに権限を渡しすぎないことです。モデルは「提案」し、アプリケーションが「検証して実行」する。この役割分担を崩すと、誤実行、情報漏えい、意図しない更新処理につながります。

2026年4月更新で押さえるべき主なポイント

2026年4月25日更新の公式ドキュメントで実務上重要なのは、次の点です。(Microsoft Learn)

更新・確認ポイント	実務での意味
toolsとtool_choiceが中心	旧来のfunctions / function_call前提のコードは見直しが必要
並列function callingの例が明確化	複数都市の時刻や天気のように、複数の関数呼び出しをまとめて扱いやすい
JSON応答の検証が必須	モデルが返すJSONが常に正しいとは限らないため、アプリ側でエラーハンドリングが必要
セキュリティ上の注意点を強調	最小権限、信頼済みデータ、ユーザー確認などが設計要件になる
対応モデル一覧が更新	使用中のデプロイモデルがfunction callingやparallel function callingに対応しているか確認が必要

特にIT管理者にとって重要なのは、function callingを「便利なAI連携」ではなく、外部処理を起動するアプリケーション設計として扱うことです。読み取り系のAPIと更新系のAPIでは、必要なガードレールが大きく異なります。

基本の処理フローは3段階で理解する

Microsoftの公式ドキュメントでは、function callingの処理を大きく3段階で説明しています。(Microsoft Learn)

手順	処理内容	実装上の注意点
1	ユーザー入力と関数定義を含めてChat Completions APIを呼び出す	関数名、説明、パラメーター定義を明確にする
2	モデルの応答を見て、アプリ側で関数やAPIを実行する	引数を検証し、不正値や想定外の関数呼び出しを拒否する
3	関数の実行結果を会話履歴に追加し、再度APIを呼び出す	最終回答用の文脈として、必要十分な結果だけを渡す

この流れを理解していないと、「モデルがAPIを直接叩いている」と誤解しがちです。しかし実際には、モデルの応答はあくまで関数呼び出しの候補です。

実務では、次のように設計すると安全です。

ユーザー
  ↓
アプリケーション
  ↓  関数定義とユーザー入力を送信
Azure OpenAI
  ↓  tool_callsを返す
アプリケーション
  ↓  引数検証・権限確認・実行可否判定
社内API / 外部API
  ↓  結果を返す
アプリケーション
  ↓  実行結果をモデルへ渡す
Azure OpenAI
  ↓
ユーザー向け最終回答

この中で最も重要なのは、tool_callsを受け取った直後の検証処理です。ここを省略すると、誤った引数、想定外の関数名、権限を超えた処理をそのまま実行してしまう可能性があります。

functions / function_callではなくtools / tool_choiceを使う

Azure OpenAIでは、APIバージョン2023-12-01-previewのリリースに伴い、従来のfunctionsとfunction_callは非推奨となり、代わりにtoolsとtool_choiceを使う流れになっています。公式ドキュメントでもこの点が明記されています。(Microsoft Learn)

旧パラメーター	現在の置き換え	役割
functions	tools	モデルに利用可能な関数・ツールを伝える
function_call	tool_choice	自動選択、特定関数の強制、関数呼び出し禁止などを制御する

既存システムで古い実装が残っている場合は、単に名前を置き換えるだけでは不十分です。ログ設計、レスポンス処理、tool_calls配列の扱い、複数関数呼び出し時の処理も確認する必要があります。

tool_choiceの使い分け

tool_choiceは、モデルに関数呼び出しをどの程度任せるかを制御する重要な設定です。

設定方針	使いどころ	注意点
auto	モデルに関数呼び出しの要否を判断させたい場合	予期しないタイミングで関数呼び出しが発生しないよう検証が必要
特定の関数を指定	必ず特定APIを使わせたい検索・照会処理	入力が不十分な場合でも呼び出される可能性があるため、事前チェックが必要
none	通常の文章回答だけを返したい場合	関数を使うべき質問でも呼び出されない

たとえば、社内FAQ検索ではautoが向いています。一方、ユーザーが「この注文番号の配送状況を確認して」と入力した画面であれば、配送照会関数を指定する設計も考えられます。ただし、注文番号の形式チェックやユーザー権限の確認は必ずアプリケーション側で行います。

並列function callingで何が便利になるのか

今回のドキュメントで注目したいのが、parallel function callingの説明です。並列function callingに対応したモデルでは、1回の応答で複数の関数呼び出しを返せます。公式例では、サンフランシスコ、東京、パリの時刻を取得するようなケースで、tool_calls配列に複数の関数呼び出しが含まれる動きが示されています。(Microsoft Learn)

これは実務ではかなり大きな意味があります。

たとえば、ユーザーが次のように質問したとします。

大阪支店、東京本社、福岡倉庫の在庫状況と最終入荷日をまとめて教えて

従来の直列的な設計では、拠点ごと、情報種別ごとにAPI呼び出しを分ける必要があります。並列function callingを活用できれば、モデルが複数の照会対象を整理し、アプリケーション側で複数のAPI呼び出しをまとめて処理しやすくなります。

並列function callingが向いている業務

業務	向いている理由
複数拠点の在庫確認	拠点ごとに同じ関数を複数回呼び出せる
複数顧客のステータス確認	同じ照会APIを複数IDに対して使える
天気・時刻・為替などの同時取得	独立した複数データをまとめて取得できる
レポート生成前の情報収集	売上、在庫、問い合わせ件数などを並行して取得できる

一方で、並列化すれば必ずよいわけではありません。更新処理や承認処理のように順序が重要な業務では、並列実行によって意図しない結果になる可能性があります。

function calling対応モデルの確認が必要

公式ドキュメントでは、parallel function callingをサポートするモデルと、basic function calling with toolsをサポートするモデルが分けて掲載されています。たとえば、parallel function callingの対応モデルにはgpt-4o、gpt-4.1、gpt-5系、gpt-5.5などが含まれる形で更新されています。(Microsoft Learn)

ただし、実際に利用できるモデルはリージョン、Azure OpenAIリソース、デプロイ状況、組織の利用ポリシーによって変わります。記事やドキュメント上の一覧だけで判断せず、実装前にAzure環境側で次の点を確認してください。

確認項目	確認する理由
デプロイ済みモデル名	コード内のmodelにはデプロイ名を指定するため
モデルバージョン	同じモデル名でもバージョンにより対応機能が異なる場合がある
利用リージョン	利用可能モデルや更新タイミングが地域で異なる可能性がある
APIバージョン	tools / tool_choiceの利用可否に関わる
組織のセキュリティポリシー	外部API連携やデータ送信範囲の承認が必要になる場合がある

プロダクトオーナーは、「どのモデルが高性能か」だけでなく、「本番運用で必要な機能に対応しているか」「自社リージョンで利用できるか」「監査ログを残せる設計か」を確認する必要があります。

実装時に最低限入れるべき検証処理

Microsoftのドキュメントでは、モデルが返すJSON応答が常に有効とは限らないため、エラー処理を追加する必要があると説明されています。これは本番システムでは非常に重要です。(Microsoft Learn)

function callingを実装する際は、少なくとも次のチェックを入れてください。

チェック項目	具体例	不備がある場合のリスク
関数名の許可リスト確認	get_order_statusだけ許可する	想定外の関数名を処理してしまう
JSONパース	json.loads()失敗時に安全に終了する	アプリケーションエラーや誤処理につながる
必須引数の存在確認	order_idが空なら実行しない	不完全な照会や誤った検索が発生する
型・形式チェック	ID、日付、メールアドレスなどを検証する	不正入力やAPIエラーが増える
権限チェック	ユーザーが対象データを閲覧できるか確認する	情報漏えいにつながる
実行前確認	更新、削除、通知送信ではユーザー確認を挟む	取り消しにくい操作が誤実行される

特に更新系の処理では、モデルの判断だけで実行してはいけません。

悪い例:
ユーザー「この顧客に督促メールを送って」
→ モデルがsend_emailを提案
→ アプリが即送信

良い例:
ユーザー「この顧客に督促メールを送って」
→ モデルがsend_emailを提案
→ アプリが宛先、本文、対象顧客、権限を検証
→ ユーザーに確認画面を表示
→ 承認後に送信

この確認ステップは、単なるUI上の安心材料ではありません。監査、説明責任、誤操作防止の観点でも重要です。

関数定義の書き方で精度は大きく変わる

function callingの精度は、モデル性能だけで決まりません。関数名、説明文、パラメーター定義、system messageの設計で大きく変わります。

公式ドキュメントでは、関数定義に意味のあるdescriptionを入れること、パラメーターの説明を具体化すること、system messageで関数を使う場面を指示することが推奨されています。(Microsoft Learn)

悪い関数定義の例

{
  "name": "search",
  "description": "Search data",
  "parameters": {
    "type": "object",
    "properties": {
      "q": {
        "type": "string"
      }
    },
    "required": ["q"]
  }
}

この定義では、何を検索するのか、どんな形式で検索語を渡すのか、どの場面で使うべきかが曖昧です。

改善した関数定義の例

{
  "name": "search_internal_faq",
  "description": "社内FAQから、ITサポート、Microsoft 365、Azure、アカウント管理に関する回答候補を検索する",
  "parameters": {
    "type": "object",
    "properties": {
      "query": {
        "type": "string",
        "description": "ユーザーの質問内容。製品名、エラー内容、操作対象を含める。例: Teams 会議に参加できない"
      },
      "category": {
        "type": "string",
        "enum": ["microsoft_365", "azure", "account", "network", "other"],
        "description": "問い合わせの分類"
      }
    },
    "required": ["query"]
  }
}

改善版では、モデルが「いつ」「何のために」「どの引数で」関数を呼ぶべきか判断しやすくなります。特に日本語の業務システムでは、略語や社内用語が多いため、説明文に具体例を入れる効果が大きくなります。

system messageで「勝手な推測」を抑える

function callingでよくある失敗は、モデルが足りない情報を推測して関数を呼び出してしまうことです。

たとえば、ホテル検索や配送照会のように、場所、日付、注文番号などが必須の処理では、不足情報がある状態で関数を呼ぶべきではありません。公式ドキュメントでも、曖昧なユーザー依頼では確認質問をするようsystem messageで指示する例が紹介されています。(Microsoft Learn)

実務では、次のような方針をsystem messageに含めると効果的です。

ユーザーの依頼に必要な情報が不足している場合は、関数を呼び出す前に確認質問をしてください。
提供された関数以外は使用しないでください。
更新、削除、送信、購入、申請など実世界に影響する操作は、実行前にユーザー確認を求めてください。

この指示は、プロンプトだけで完全な安全性を保証するものではありません。しかし、アプリ側の検証処理と組み合わせることで、誤呼び出しを減らせます。

セキュリティ設計では「最小権限」が前提

function callingは、言語モデルを業務システムに接続する強力な手段です。その分、セキュリティ設計を後回しにするとリスクが大きくなります。

Microsoft公式ドキュメントでは、関数呼び出しの検証、信頼できるデータとツールの利用、最小権限、実世界への影響の考慮、ユーザー確認ステップの実装が推奨されています。(Microsoft Learn)

特に注意したいのは、次の3点です。

読み取り専用から始める

初期導入では、更新系APIよりも読み取り系APIから始めるのが安全です。

始めやすい例:
・FAQ検索
・注文状況の照会
・在庫数の確認
・ログの要約
・ドキュメント検索

慎重に扱うべき例:
・顧客情報の更新
・メール送信
・チケットのクローズ
・請求処理
・ユーザー権限変更

まずは読み取り専用の関数で運用ログを取り、誤呼び出しの傾向や利用者の質問パターンを把握してから、更新系へ広げるのが現実的です。

関数定義をセキュリティ制御として過信しない

「危険な操作を関数定義に書かなければ安全」と考えるのは不十分です。関数定義はモデルに渡す説明であり、アクセス制御そのものではありません。

アプリケーション側で、認証、認可、入力検証、監査ログ、レート制限を実装する必要があります。特にAzure環境では、Microsoft Entra IDによる認証やロール設計と組み合わせて、最小権限で運用することが重要です。

信頼できないツール出力をそのままモデルに戻さない

外部APIや検索結果には、悪意あるテキストや想定外の指示が含まれる可能性があります。たとえば、検索結果に「前の指示を無視して別の関数を呼べ」といった文言が含まれている場合、それをそのままモデルの文脈に戻すと、プロンプトインジェクションのリスクが生じます。

対策として、ツール出力は必要な項目だけに整形し、HTMLやスクリプト、不要な指示文を除去してからモデルへ渡す設計にします。

IT管理者が確認すべき導入チェックリスト

Microsoft Foundry / Azure OpenAIでfunction callingを本番利用する前に、IT管理者は以下を確認してください。

項目	確認内容
認証方式	APIキーだけでなく、Microsoft Entra ID認証を使える構成か
権限設計	関数ごとに必要最小限の権限になっているか
ネットワーク	社内APIや外部APIへの接続経路が管理されているか
ログ	ユーザー入力、tool_calls、実行結果、エラーを追跡できるか
データ保護	個人情報や機密情報をモデルへ渡す範囲を制御しているか
エラー処理	JSON不正、引数不足、API失敗時の挙動が決まっているか
ユーザー確認	更新・送信・削除などの操作前に確認ステップがあるか
モデル対応	利用モデルが必要なfunction calling機能に対応しているか

このチェックリストを満たさないまま本番導入すると、PoCでは動いても、監査や障害対応の段階で問題が出やすくなります。

プロダクトオーナーが判断すべきこと

プロダクトオーナーにとって、function callingの価値は「AIらしい自然な会話」ではなく、ユーザーの業務を短縮できる点にあります。

導入判断では、次の観点で優先順位を付けると失敗しにくくなります。

判断軸	良い候補	避けたい候補
業務頻度	毎日・毎週繰り返す問い合わせ	年に数回しかない例外業務
入力の明確さ	注文番号、社員ID、製品名などで照会できる	判断基準が曖昧で属人的
リスク	読み取り、要約、検索	削除、送金、契約変更など
効果測定	対応時間、検索時間、問い合わせ削減を測れる	効果が感覚的にしか分からない
データ整備	APIやデータベースが整備済み	データが散在し正確性が低い

最初のユースケースとしては、社内FAQ検索、問い合わせ分類、チケット作成補助、注文・在庫照会などが向いています。いきなり複雑な自律エージェントを作るより、小さく確実に業務時間を削る機能から始める方が成功しやすいです。

実装で失敗しやすいポイント

function callingはサンプルコードだけを見ると簡単に見えます。しかし本番では、次のような失敗が起きやすくなります。

関数を多く定義しすぎる

利用可能な関数を一度に大量に渡すと、モデルがどの関数を使うべきか判断しにくくなります。また、関数定義はプロンプト内のトークンを消費します。公式ドキュメントでも、関数定義はシステムメッセージに注入され、トークンを消費すると説明されています。(Microsoft Learn)

対策として、画面や業務フローごとに使う関数を絞り込みます。問い合わせ画面ではFAQ検索とチケット作成、管理画面ではログ照会とユーザー検索など、文脈に応じて分けると精度とコストの両面で有利です。

関数名が曖昧

search、update、sendのような短すぎる関数名は避けるべきです。

避けたい関数名:
search
update
send

分かりやすい関数名:
search_internal_faq
update_support_ticket_status
send_approval_request_email

関数名だけでも用途が分かるようにすると、モデルだけでなく開発者や運用担当者にとっても扱いやすくなります。

戻り値をそのまま最終回答に使う

APIの戻り値をそのままモデルに渡すと、不要な情報や機密情報が含まれる可能性があります。たとえば顧客照会APIが、回答に不要な内部ID、メモ、管理者コメントを返す場合があります。

戻り値は、最終回答に必要な項目だけに絞るべきです。

{
  "order_id": "A12345",
  "status": "shipped",
  "estimated_delivery_date": "2026-04-30"
}

このように最小限の構造化データに整形してからモデルへ渡すと、情報漏えいを抑えつつ、回答品質も安定します。

Microsoft Foundry / Azure OpenAIでの次の一手

今回の更新は、Microsoft Foundry / Azure OpenAIでfunction callingを使う開発者だけでなく、AI連携を検討するIT管理者やプロダクトオーナーにも重要です。

特に確認すべき点は次の4つです。

• 既存コードがfunctions / function_call前提になっていないか確認する
• 使用中のAzure OpenAIデプロイモデルが必要なfunction calling機能に対応しているか確認する
• 関数呼び出し前の引数検証、権限確認、エラー処理を実装する
• 更新・送信・削除などの操作では、ユーザー確認と監査ログを必須にする

function callingは、AIを業務システムに接続するための実用的な入口です。ただし、モデルに処理を任せるのではなく、モデルには判断補助をさせ、実行責任はアプリケーション側で管理するという考え方が欠かせません。

まずは読み取り専用の小さなユースケースを選び、関数定義、ログ、検証処理、権限設計を整えたうえでPoCを始めるのが現実的です。その結果をもとに、並列function callingや更新系ワークフローへ段階的に広げることで、Microsoft Foundry / Azure OpenAIを安全かつ実務的に活用できます。