Azure AI Foundry の「Use function calling with Microsoft Foundry agents」は、Foundry agents に独自関数を接続し、社内システムや外部 API の結果をエージェントの回答に反映させるための公式ガイドです。結論から言うと、今回確認すべきポイントは「関数はエージェントが自動実行するのではなく、アプリケーション側が実行して結果を返す」「関数ツールの追加・変更は Foundry ポータルだけでは完結せず、SDK または REST API で構成する」「実行結果は 10 分以内に返す必要がある」の3点です。(Microsoft Learn)
特に、Azure AI Foundry で業務エージェントを作っている管理者や開発者は、単に「Function Calling が使えるようになった」と見るのではなく、権限管理、ログ、タイムアウト、ツール定義のバージョン管理まで含めて設計を見直す必要があります。本記事では、2026年7月3日時点で確認できる Microsoft Learn の公式情報をもとに、Azure AI Foundry の Function Calling の更新ポイント、影響範囲、設定変更、移行期限、管理者が確認すべき実務ポイントを整理します。なお、該当ページ上の最終更新表示は 2026年6月2日です。(Microsoft Learn)
Azure AI Foundry の Function Calling とは何か
Azure AI Foundry の Function Calling は、Microsoft Foundry agents に独自の処理能力を追加する仕組みです。エージェントに対して、関数名、説明、パラメーター構造を定義しておくと、モデルが必要に応じて「この関数をこの引数で呼び出してほしい」とアプリケーションに要求します。アプリケーション側はその要求を受け取り、実際の関数や API を実行し、結果をエージェントに返します。(Microsoft Learn)
重要なのは、モデル自身が社内システムや外部 API を直接実行するわけではない点です。モデルは「呼び出すべき関数」と「引数」を提案し、実行責任はアプリケーション側にあります。そのため、在庫確認、顧客情報照会、チケット作成、申請ステータス確認など、業務システムと連携するエージェントを作る場合は、Function Calling の設計がセキュリティと品質を大きく左右します。
たとえば、社内ヘルプデスク用エージェントに getTicketStatus という関数を定義すると、ユーザーが「昨日出した申請の状況を教えて」と聞いた際に、エージェントはチケット管理システムを参照する関数呼び出しを要求できます。ただし、実際にチケット管理システムへアクセスするのはアプリケーションであり、ユーザー権限の確認や入力値の検証もアプリケーション側で実装する必要があります。
今回の更新ポイントで押さえるべきこと
公式ドキュメントの内容から見ると、今回のポイントは「Function Calling の概念説明」だけでなく、実装パターン、対応 SDK、REST API、セキュリティ上の注意、トラブルシューティングまで一通り整理されている点にあります。
| 確認項目 | 実務上の意味 | 管理者・開発者が取るべき対応 |
|---|---|---|
| 関数ツールの定義 | 関数名、説明、引数スキーマをエージェントに登録する | あいまいな関数名を避け、JSON Schema と説明文を明確にする |
| SDK / REST API 対応 | Python、C#、TypeScript、Java、REST API で実装できる | 既存開発言語に合わせて実装方式を選ぶ |
| Foundry ポータルの制約 | ポータルでエージェント実行はできるが、関数定義の追加・削除・更新は SDK または REST API が必要 | 本番運用では IaC や CI/CD に関数定義を含める |
| 10分の実行期限 | Runs は作成から 10 分で期限切れになる | 長時間処理は即時応答、非同期処理、ポーリングに分ける |
| セキュリティ考慮 | 引数・出力は信頼できない入力として扱う必要がある | 入力検証、最小権限、秘密情報の除外を徹底する |
公式情報では、Microsoft Foundry agents の Function Calling は Python SDK、C# SDK、JavaScript SDK、Java SDK、REST API に対応し、Basic agent setup と Standard agent setup の両方で利用できるとされています。(Microsoft Learn)
Function Calling の基本的な処理フロー
Function Calling の流れは、一般的なチャット処理よりも一段多くなります。エージェントに質問を投げるだけでは完結せず、アプリケーション側で関数呼び出し要求を処理するループが必要です。
| ステップ | 処理内容 | 失敗しやすいポイント |
|---|---|---|
| 関数ツールを定義する | 関数名、説明、パラメーター、必須項目を定義する | 説明が抽象的で、モデルが正しく選べない |
| エージェントを作成する | 定義した関数ツールをエージェントに登録する | ポータルだけで変更できると誤解する |
| ユーザーのプロンプトを送る | エージェントが必要に応じて function_call を返す | function_call が返る前提の処理がない |
| アプリ側で関数を実行する | 返された関数名と引数を検証し、実処理を行う | 引数を無検証で API や DB に渡す |
| tool output を返す | function_call_output と call_id を指定して結果を返す | call_id の対応付けを間違える |
| 最終回答を受け取る | エージェントが関数結果を使って自然文で回答する | tool output を返さず、最終回答が生成されない |
公式ドキュメントでも、Function Calling は「関数ツールを定義する」「エージェントを作る」「プロンプトを送る」「アプリケーションが関数を実行して結果を返す」「エージェントが最終応答を生成する」という流れで説明されています。(Microsoft Learn)
影響範囲：誰が確認すべきか
今回の内容は、Azure AI Foundry を単なるチャットボット基盤として使っているだけの組織よりも、エージェントから業務システムや外部 API を呼び出したい組織に大きく関係します。
アプリケーション開発者への影響
開発者は、Function Calling を「モデルに関数を渡せば自動で処理してくれる機能」と捉えないことが重要です。実際には、モデルが返した function_call をアプリケーションが解釈し、対象関数を実行し、結果を function_call_output として返す必要があります。(Microsoft Learn)
そのため、以下の実装が必要になります。
- 関数名と実処理を対応付けるルーティング処理
- JSON 引数のパースとバリデーション
- 外部 API やデータベースへの安全なアクセス
- エラー発生時の戻り値設計
- 複数 function_call が返った場合の処理
- 10分以内に結果を返せない場合の代替フロー
特に本番環境では、モデルが返した引数をそのまま SQL、HTTP リクエスト、ファイル操作に渡す設計は避けるべきです。Function Calling は便利ですが、入力値は常に外部入力として扱う必要があります。
Azure 管理者への影響
Azure 管理者は、Function Calling の有効化そのものよりも、認証、権限、監査、ネットワーク、リージョンとモデル対応を確認する必要があります。Microsoft のベストプラクティスでは、ツール利用時に必要最小限の情報だけを送ること、キーやトークンなどの資格情報をプロンプトやログに含めないこと、ツール出力を信頼できない入力として扱うことが示されています。(Microsoft Learn)
また、ツールの利用可否はリージョンとモデルの両方に依存します。片方が対応していても、もう片方が未対応であれば利用できないため、管理者は対象プロジェクトのリージョン、デプロイ済みモデル、利用予定ツールの対応状況をセットで確認する必要があります。(Microsoft Learn)
セキュリティ担当者への影響
セキュリティ担当者が見るべきポイントは、Function Calling によってエージェントの影響範囲が「回答生成」から「業務操作」へ広がることです。たとえば、情報検索だけなら読み取り権限の管理が中心ですが、チケット作成、メール送信、在庫更新、承認処理などを関数化すると、誤操作や権限昇格のリスクも考える必要があります。
Function Calling を使う場合は、少なくとも以下を確認してください。
| リスク | 具体例 | 対策 |
|---|---|---|
| 過剰権限 | エージェント経由で全顧客データを取得できる | 関数ごとにスコープを限定し、ユーザー権限も確認する |
| 秘密情報の漏えい | API キーや接続文字列を tool output に含める | 出力には回答に必要な最小情報だけを含める |
| 意図しない更新 | ユーザーの曖昧な指示でデータを変更する | 更新系関数は確認ステップを入れる |
| ログへの機密情報混入 | trace やアプリログに個人情報が残る | マスキングとログ保持ポリシーを設計する |
| 長時間処理の失敗 | 外部 API が遅く、Run が期限切れになる | 非同期ジョブ化し、ステータスを返す |
設定変更で確認すべきポイント
Function Calling を既存の Azure AI Foundry 環境に組み込む場合、管理者は「エージェントにツールを付ける」だけでなく、開発・運用プロセス側の変更も確認する必要があります。
関数定義は SDK または REST API で管理する
公式ドキュメントでは、Foundry ポータル上で function tools を持つエージェントを実行できる一方、エージェント上の関数定義を追加、削除、更新する操作はポータルでは対応しておらず、SDK または REST API を使う必要があると説明されています。(Microsoft Learn)
これは実務上かなり重要です。開発環境で手動設定し、本番環境で再現できない状態を避けるため、関数定義はコード管理するのが安全です。
おすすめの管理方法は次のとおりです。
- 関数ツール定義をリポジトリで管理する
- エージェント作成・更新を CI/CD に組み込む
- 本番反映前にステージング環境で function_call の発生有無をテストする
- 関数名、説明、パラメーター変更時は破壊的変更としてレビューする
- 古い agent version の削除やロールバック手順を用意する
strict と required を適切に使う
関数のパラメーター定義では、必須項目を required で明示し、必要に応じて strict: true を使うことが重要です。公式ドキュメントのサンプルでも、パラメーターに required や additionalProperties: false を設定し、より厳密な引数構造にする例が示されています。(Microsoft Learn)
たとえば、天気取得関数なら location は必須、unit は "c" または "f" の enum にする、といった形です。業務システム連携では、部署コード、申請ID、顧客IDなどを自由入力にせず、可能な限り形式を制限してください。
悪い例は次のような定義です。
{
"name": "getData",
"description": "Get data",
"parameters": {
"type": "object",
"properties": {
"query": { "type": "string" }
}
}
}この定義では、何のデータを取る関数なのか、どの形式で指定すべきかが曖昧です。モデルが誤った引数を作りやすく、開発者側も安全な検証をしにくくなります。
改善するなら、次のように用途と入力形式を絞ります。
{
"name": "getPurchaseRequestStatus",
"description": "Get the approval status of a purchase request by request ID.",
"parameters": {
"type": "object",
"properties": {
"requestId": {
"type": "string",
"description": "Purchase request ID, for example PR-2026-000123"
}
},
"required": ["requestId"],
"additionalProperties": false
},
"strict": true
}実行期限 10 分を前提に設計する
公式ドキュメントでは、Runs は作成から 10 分で期限切れになるため、期限内に tool outputs を送信する必要があると明記されています。長時間処理の場合は、すぐにステータスを返し、別途ポーリングを実装することが推奨されています。(Microsoft Learn)
たとえば、次のような処理は 10 分以内に終わらない可能性があります。
- 大量データの集計
- 外部 SaaS への低速な API 呼び出し
- バッチ処理の起動と完了待ち
- ファイル変換やレポート生成
- 複数システムをまたぐ承認ワークフロー
この場合、Function Calling で最終結果を待ち続けるのではなく、「処理を受け付けました。ジョブIDは xxx です」と返し、別の関数でジョブ状態を確認する設計にした方が安定します。
実装方式：Python、C#、TypeScript、Java、REST の選び方
公式ガイドでは Python、C#、TypeScript、Java、REST API の例が示されています。どれを選ぶべきかは、Azure AI Foundry の機能差ではなく、既存システムとの接続性、運用チームのスキル、CI/CD の整備状況で判断するのが現実的です。(Microsoft Learn)
| 実装方式 | 向いているケース | 判断ポイント |
|---|---|---|
| Python | PoC、データ処理、AI アプリ開発チーム主導 | サンプルが多く、検証しやすい |
| C# | .NET 業務アプリ、社内 API、Windows 系基盤 | 既存の .NET 資産と統合しやすい |
| TypeScript | Web アプリ、Node.js API、フロントエンド寄りの開発 | Web サービスとの接続がしやすい |
| Java | 大規模基幹システム、エンタープライズ API | 既存の Java バックエンドと合わせやすい |
| REST API | 言語非依存、CI/CD、低レベル制御 | SDK に依存せず構成を管理できる |
最初の検証では Python または TypeScript が扱いやすい一方、本番環境では既存の認証基盤、監査ログ、API ゲートウェイ、例外処理に合わせた言語を選ぶべきです。特に、基幹システムとの連携では「AI 開発者が使いやすい言語」よりも「運用チームが保守できる言語」を優先した方が失敗しにくくなります。
Function Calling と OpenAPI tool はどう使い分けるべきか
Azure AI Foundry で外部処理を呼び出す方法には、Function Calling 以外にも OpenAPI tool や MCP などがあります。Function Calling は、アプリケーションコード側で関数実行を制御したい場合に向いています。
| 選択肢 | 向いている用途 | 注意点 |
|---|---|---|
| Function Calling | アプリ内の関数、社内ロジック、細かい権限制御が必要な処理 | 実行ループをアプリ側で実装する必要がある |
| OpenAPI tool | 既存 REST API を仕様書ベースで接続したい場合 | API 仕様、認証、到達性の整備が必要 |
| Azure Functions 連携 | サーバーレスで処理を切り出したい場合 | 実行時間、認証、ネットワーク制御を別途設計する |
| MCP | 複数ツールを標準化して接続したい場合 | プレビュー機能やガバナンス要件を確認する |
実務では、最初からすべてを OpenAPI 化するより、まず Function Calling で小さく検証し、利用頻度が高い処理や複数エージェントで共有したい処理を OpenAPI tool や Azure Functions に切り出す進め方が現実的です。
移行期限：今回の Function Calling 自体に新たな一斉移行期限はあるか
今回確認した「Use function calling with Microsoft Foundry agents」のページ自体では、Function Calling 利用者に対する新たな一斉移行期限は確認できません。ただし、関連する旧機能を使っている場合は、別の期限に注意が必要です。
| 対象 | 期限 | 対応方針 |
|---|---|---|
| Microsoft Foundry agents の新しい Function Calling | 該当ページ上では新たな一斉移行期限の記載なし | SDK / REST API で新方式の実装・検証を進める |
| Microsoft Foundry classic agents | 2027年3月31日に廃止予定 | 一般提供の Microsoft Foundry Agents Service へ移行する |
| Azure OpenAI Assistants API | 2026年8月26日に廃止予定 | Microsoft Foundry Agents service へ移行する |
| Hosted agents の container protocol 1.0.0 | 2026年7月31日以降、1.0.0 のリクエストがブロックされる予定 | protocol 2.0.0 対応 SDK へ更新する |
classic agents については、公式ドキュメントで非推奨および 2027年3月31日の廃止予定が示されています。Azure OpenAI Assistants API についても、2026年8月26日の廃止予定と Microsoft Foundry Agents service への移行が案内されています。(Microsoft Learn)
また、Hosted agents の container protocol 1.0.0 を使っている場合は、2026年7月31日以降にプラットフォーム側でリクエストがブロックされると説明されています。Function Calling そのものの期限ではありませんが、Hosted agents と組み合わせている環境では確認しておくべき関連期限です。(Microsoft Learn)
管理者が確認すべきチェックリスト
Azure AI Foundry の Function Calling を本番利用する前に、管理者は次の項目を確認してください。
| 確認項目 | チェック内容 |
|---|---|
| 対象モデル | Function Calling を使うモデルが対象リージョンでツール対応しているか |
| リージョン | プロジェクトのリージョンで必要なツールが利用できるか |
| 認証 | DefaultAzureCredential や Managed Identity の権限が最小限になっているか |
| 関数定義 | 関数名、説明、パラメーター、必須項目が明確か |
| 変更管理 | 関数ツール定義をコード管理し、レビューできる状態か |
| 実行制御 | 10分以内に tool output を返せる設計か |
| エラー処理 | API 失敗、タイムアウト、JSON パース失敗を処理できるか |
| セキュリティ | tool output に秘密情報や不要な個人情報を含めていないか |
| 監査 | function_call の発生、引数、結果を必要な範囲で追跡できるか |
| コスト | テスト後に agent や conversation を削除する運用があるか |
公式ドキュメントでも、動作確認の観点として「最初のレスポンスに type: function_call の出力が含まれること」「アプリが返された arguments で関数を実行すること」「function_call_output を含む後続レスポンスを送信し、自然文の回答が返ること」が示されています。(Microsoft Learn)
失敗しやすいポイントと対策
Function Calling は実装自体はシンプルに見えますが、本番運用では細かい設計ミスが障害につながりやすい機能です。
| よくある失敗 | 原因 | 対策 |
|---|---|---|
| エージェントが関数を呼ばない | 関数定義が未登録、説明が曖昧、モデル未対応 | ツール定義、モデル対応、リージョン対応を確認する |
| 最終回答が返らない | function_call に対する output を返していない | call_id に対応する function_call_output を送る |
| JSON パースで落ちる | スキーマが曖昧、想定外の引数が返る | required、enum、additionalProperties: false を使う |
| 実行期限切れになる | 外部 API やバッチ処理が遅い | 非同期ジョブ化し、ステータスを返す |
| 誤った関数が呼ばれる | 複数ツールの用途が重複している | agent instructions に使い分けルールを書く |
| セキュリティレビューで止まる | 権限やログ設計が曖昧 | 最小権限、監査ログ、マスキング方針を事前に決める |
Microsoft のツール利用ベストプラクティスでは、ツールの用途と利用条件を agent instructions に明確に書くこと、複数ツールが重なる場合は判断ルールを追加すること、必要に応じて tool_choice でツール利用を制御することが推奨されています。(Microsoft Learn)
実務での活用シーン
Azure AI Foundry の Function Calling は、単なる Q&A よりも「回答に社内データや業務処理を組み込みたい」場面で効果を発揮します。
社内問い合わせ対応
人事、総務、情報システム部門の問い合わせ対応では、ユーザーの質問に応じて申請ステータス、資産管理情報、FAQ、チケット状況を取得する関数を呼び出せます。
例として、次のような関数が考えられます。
getEmployeeLeaveBalancegetDeviceAssignmentgetHelpdeskTicketStatuscreatePasswordResetRequest
ただし、ユーザー本人の情報だけを返す、管理者権限が必要な情報は返さない、更新系処理は確認を挟む、といった権限制御が必要です。
営業・カスタマーサポート支援
CRM や問い合わせ管理システムと連携し、顧客の契約状況、問い合わせ履歴、次回更新日を取得するエージェントを作れます。
この場合、Function Calling の戻り値には、顧客情報を丸ごと返すのではなく、回答に必要な項目だけを返す設計が重要です。たとえば、契約プラン、更新日、未解決チケット数だけで足りるなら、住所、電話番号、請求情報まで返す必要はありません。
運用監視・インシデント対応
監視システム、ログ基盤、チケット管理ツールと連携すれば、障害状況を要約するエージェントを構築できます。
たとえば、次のような使い方です。
- アラート ID から影響範囲を取得する
- 直近のデプロイ履歴を確認する
- 関連するインシデントチケットを検索する
- 一次対応手順を提示する
ただし、復旧操作や設定変更を Function Calling で実行する場合は、必ず承認フローや権限チェックを組み込むべきです。読み取り系関数と更新系関数を分け、更新系には人間の確認を必須にすると安全です。
導入時のおすすめ手順
Function Calling を導入する場合は、いきなり本番業務の更新処理を任せるのではなく、読み取り専用の小さな関数から始めるのが安全です。
| フェーズ | やること | 成功条件 |
|---|---|---|
| PoC | 天気、FAQ、ステータス取得など低リスク関数で検証 | function_call から最終回答までの流れを理解できる |
| 社内検証 | 認証付きの読み取り専用 API と接続 | ユーザー権限に応じた結果だけ返せる |
| 本番準備 | ログ、監査、タイムアウト、エラー処理を整備 | セキュリティレビューを通過できる |
| 本番運用 | 限定ユーザーから段階展開 | 誤呼び出し、期限切れ、権限エラーを監視できる |
| 拡張 | 更新系処理や複数ツール連携を追加 | 承認フローとロールバック手順がある |
最初の関数は、更新処理を含まないものにしてください。たとえば「申請状況を取得する」「チケット一覧を取得する」「製品マスターを検索する」といった読み取り専用関数です。これにより、Function Calling の挙動、引数の精度、ログの取り方を安全に確認できます。
まとめ：Azure AI Foundry の Function Calling は「接続」より「統制」が重要
Azure AI Foundry の「Use function calling with Microsoft Foundry agents」で最も重要なのは、エージェントに独自関数を追加できることそのものではなく、業務システムとの接続をどのように安全に統制するかです。
管理者と開発者は、まず次の4点を確認してください。
- 関数定義は SDK または REST API で管理し、コードレビューできる状態にする
- モデルが返した引数と tool output は信頼せず、必ず検証する
- 10分の期限を前提に、長時間処理は非同期化する
- classic agents、Assistants API、Hosted agents protocol 1.0.0 を使っている場合は関連する移行期限を確認する
Function Calling は、Azure AI Foundry のエージェントを「会話するだけの AI」から「業務データを参照し、必要な操作を支援する AI」へ拡張するための中核機能です。まずは読み取り専用の小さな関数から始め、権限、監査、タイムアウト、エラー処理を確認しながら、段階的に本番業務へ広げるのが最も安全で実用的です。
コメント