Microsoft Foundry / Azure OpenAIでエージェントを作る場合、2026年4月時点で最初に押さえるべきポイントは「モデル単体で答えさせる」設計から、「ツールを使って検索・分析・社内データ参照・外部API実行まで行わせる」設計へ移ることです。
Microsoft公式ドキュメント「Agent tools overview for Foundry Agent Service」は2026年4月23日に更新され、Foundry Agent Serviceで使えるツールの種類、Toolbox、認証、カタログ管理、セキュリティ上の注意点が整理されました。これは単なる機能一覧ではなく、IT管理者やプロダクトオーナーが「どのツールを選ぶべきか」「どこまで本番利用できるか」「認証とガバナンスをどう設計するか」を判断するための実務資料として読むべき内容です。(Microsoft Learn)
Microsoft Foundry / Azure OpenAIの最新動向として何が重要か
今回の更新で重要なのは、Foundry Agent Serviceのツールが「便利な追加機能」ではなく、エージェントの業務利用を成立させる中核要素として整理された点です。
従来の生成AI活用では、Azure OpenAIやLLMにプロンプトを投げて回答を得る構成が中心でした。しかし業務エージェントでは、それだけでは不十分です。最新情報を検索する、社内文書を参照する、Pythonでデータを分析する、チケットを作成する、外部APIから顧客情報を取得するといった「行動」が必要になります。
Microsoftの説明では、エージェント単体はFoundryモデルを使ってテキストを生成しますが、ツールを使うことでWeb検索、コード実行、データ照会、独自API呼び出しなどが可能になります。つまり、Microsoft Foundry Agent toolsは、チャットボットを業務アプリケーションに近づけるための接続層と考えると理解しやすいです。(Microsoft Learn)
| 2026年4月更新で見るべき点 | 実務上の意味 | まず確認すべきこと |
|---|---|---|
| 組み込みツールとカスタムツールの整理 | 目的別にツール選定しやすくなった | 社内データ参照か、外部API連携か、Web検索か |
| Toolboxの追加・整理 | 複数ツールを再利用しやすくなる | 複数チーム・複数エージェントで共通利用するか |
| structured inputs | 実行時に参照先を切り替えられる | 顧客別・環境別にデータソースを変える必要があるか |
| 認証方式の明確化 | IT管理者が権限設計しやすくなる | Microsoft Entra、APIキー、OAuthのどれを使うか |
| 非Microsoftサービス利用時の注意 | データ送信・契約・責任分界点を確認できる | プロンプトや業務データが外部サービスへ渡るか |
Agent tools overviewで整理されたツールの全体像
Foundry Agent Serviceのツールは、大きく「組み込みツール」と「カスタムツール」に分かれます。Microsoft公式ドキュメントでは、ツールカタログとコアツールフレームワークは一般提供と説明されていますが、個別ツールの一部はプレビュー扱いです。そのため、導入時は「Foundry Agent Serviceのツール全体が使えるか」だけでなく、「使いたい個別ツールが本番利用に適しているか」を確認する必要があります。(Microsoft Learn)
組み込みツールは短期間で試しやすい
組み込みツールは、基本設定を行えばサービス側で実行されるツールです。独自ホスティングやカスタムコードを用意しなくても使えるため、PoCや初期導入に向いています。
代表的な組み込みツールは次のとおりです。
| ツール | 主な用途 | 向いているケース |
|---|---|---|
| Web search | 公開Webから最新情報を取得し、引用付きで回答 | ニュース、公開仕様、製品情報、障害情報の確認 |
| Code Interpreter | Pythonコードを実行し、計算・データ分析・グラフ生成 | CSV分析、数値計算、レポート作成支援 |
| File Search | アップロード文書や独自文書を検索 | 社内FAQ、製品マニュアル、契約書テンプレートの参照 |
| Azure AI Search | 既存のAzure AI Searchインデックスを利用 | すでに検索基盤を構築済みの企業 |
| Azure Functions | Azure Functionsを呼び出して処理を実行 | 社内処理、ワークフロー、簡易API実行 |
| Function calling | アプリ側で実装した関数を呼び出す | 既存アプリにエージェント機能を組み込む |
| SharePoint | SharePoint上の文書を参照 | Microsoft 365中心のナレッジ活用 |
たとえば、社内問い合わせ対応エージェントなら、File Searchで社内ナレッジを参照し、Web searchで公開情報を補完し、Azure FunctionsやOpenAPIツールでチケット登録を行う構成が考えられます。
ただし、Web searchには重要な注意点があります。Microsoftのドキュメントでは、Web SearchはGrounding with Bing SearchおよびGrounding with Bing Custom Searchを使用し、データ保護補遺が適用されないデータ転送や追加コストに関する注意が示されています。企業利用では、利用可否をIT管理者と法務・セキュリティ担当が事前に確認すべきです。(Microsoft Learn)
カスタムツールは業務システム連携の本命
カスタムツールは、独自API、外部サービス、他のエージェントなどと接続するための選択肢です。業務システムと連携するエージェントを作る場合、こちらが本命になります。
| カスタムツール | 何ができるか | 判断基準 |
|---|---|---|
| MCP | MCPサーバー上のツールやデータソースに接続 | 複数エージェントや複数チームでツールを共有したい |
| OpenAPI tool | OpenAPI 3.0 / 3.1仕様のHTTP APIに接続 | 既存API仕様書がある、REST APIを安全に呼びたい |
| Agent-to-Agent | 他のエージェントと連携 | 専門エージェントを分担させたい |
| Toolbox | 複数ツールを単一のMCP互換エンドポイントとして公開 | 組織横断でツールを再利用したい |
OpenAPI toolでは、OpenAPI 3.0または3.1の仕様を使って外部APIを接続できます。Microsoft公式ドキュメントでは、匿名、APIキー、managed identityの認証方式が説明されており、各操作にはoperationIdが必要です。API仕様書が雑に作られていると、モデルがどの操作を呼ぶべきか判断しづらくなるため、operationIdと説明文は人間向けではなく「モデルが選びやすい名前」に整えるのが実務上のポイントです。(Microsoft Learn)
MCPは、外部ツール連携の共通インターフェースとして重要度が高まっています。Foundry Agent Serviceでは、公開MCPエンドポイントに加えて、Standard Agent Setupとプライベートネットワークを使うことで非公開MCPサーバーへの接続も扱えます。認証情報はアプリにハードコードせず、Foundryプロジェクトの接続として保存する設計が推奨されます。(Microsoft Learn)
2026年4月更新で特に注目すべきToolbox
今回の更新で、プロダクトオーナーやIT管理者が特に注目すべきなのがToolboxです。
Toolboxは、Web search、Azure AI Search、Code Interpreter、File Search、MCP、OpenAPIなど複数のツールをまとめ、単一のMCP互換エンドポイントとして公開する仕組みです。複数のエージェントに同じツール群を個別設定するのではなく、Toolbox側で一元管理し、各エージェントはそのエンドポイントを参照します。(Microsoft Learn)
これにより、次のような課題を減らせます。
- 各チームが同じAPI連携を何度も実装してしまう
- APIキーやトークンが複数のエージェント定義に分散する
- どのエージェントがどの外部ツールを使っているか把握しにくい
- ツール変更時に複数のエージェントを修正・再デプロイする必要がある
MicrosoftのToolboxドキュメントでは、ツールを一度定義して中央管理し、単一のMCP互換エンドポイントを通じて任意のMCP対応ランタイムから利用できると説明されています。また、Toolboxはバージョン管理に対応しており、新しいバージョンをテストしてから既定バージョンへ昇格させる運用が可能です。(Microsoft Learn)
ただし、Toolboxはプレビュー扱いです。Microsoftはプレビュー項目について、SLAなしで提供され、本番ワークロードには推奨しない旨を明記しています。したがって、現時点では「社内PoC」「限定ユーザー向け検証」「開発チーム内の標準化検討」に使い、基幹業務の本番適用はリスク評価を挟むのが現実的です。(Microsoft Learn)
structured inputsでエージェント定義を使い回しやすくなる
実務で見落としがちなポイントが、structured inputsです。
通常、File Searchのvector store ID、Code Interpreterのコンテナーやファイル、MCPサーバーのURLやヘッダーなどは、エージェント定義に固定されます。しかしstructured inputsを使うと、実行時に一部の値を差し替えられます。Microsoft公式ドキュメントでは、file_searchのvector_store_ids、code_interpreterのcontainerやcontainer.file_ids、mcpのserver_label、server_url、headersがカスタマイズ対象として示されています。(Microsoft Learn)
これは、次のような場面で効果があります。
| シーン | structured inputsを使わない場合 | structured inputsを使う場合 |
|---|---|---|
| 顧客ごとに参照ナレッジを変える | 顧客ごとにエージェントを複製 | 同じエージェント定義でvector storeだけ切り替え |
| 開発・検証・本番を分ける | 環境ごとに定義を作り直す | 実行時に接続先を変更 |
| MCPサーバーがリクエストごとに変わる | エージェント定義が増える | MCP endpointやheadersを実行時に指定 |
たとえば、SaaSベンダーが顧客別のサポートエージェントを提供する場合、顧客Aには顧客A専用のナレッジ、顧客Bには顧客B専用のナレッジを参照させる必要があります。structured inputsを使えば、エージェントの設計思想は共通化しつつ、参照先だけを安全に切り替えられます。
この考え方は、グローバル展開にも向いています。日本、欧州、北米で参照すべき規約や製品仕様が異なる場合でも、エージェント本体を乱立させず、地域別データソースを切り替える設計が可能になります。
IT管理者が最初に確認すべき認証と権限設計
Microsoft Foundry Agent toolsを企業で使う場合、最初に決めるべきなのは「どのモデルを使うか」だけではありません。むしろ先に決めるべきなのは、ツールがどの権限で外部サービスや社内データにアクセスするかです。
MCPサーバーの認証では、共有認証と個別認証という考え方があります。共有認証は全ユーザーが同じ資格情報を使う方式で、個別認証は各ユーザーの権限を維持する方式です。Microsoftのドキュメントでは、MCP認証方式としてキー認証、Microsoft Entra認証、OAuth identity passthroughなどが整理されています。(Microsoft Learn)
| 目的 | 推奨される考え方 | 注意点 |
|---|---|---|
| 全ユーザーが同じ外部APIを使う | 共有認証またはMicrosoft Entra認証 | 権限が広くなりすぎないようにする |
| ユーザーごとの権限を維持する | OAuth identity passthrough | 初回同意やユーザー管理を設計する |
| シークレット管理を減らす | Microsoft Entra認証 | 対象サービス側がEntraに対応しているか確認する |
| APIキーを使う | プロジェクト接続に保存 | プロンプトやコードに直接書かない |
Microsoftのベストプラクティスでは、ツール出力を信頼済みデータとして扱わず、重要な値は検証すること、必要最小限の情報だけを送ること、キーやトークンをプロンプトに含めないこと、ログに秘密情報を残さないことが示されています。(Microsoft Learn)
IT管理者は、次の順番で確認すると失敗しにくくなります。
| 確認項目 | 具体的に見ること |
|---|---|
| データ分類 | 個人情報、契約情報、機密文書、公開情報のどれを扱うか |
| 接続先 | Microsoftサービスか、非Microsoftサービスか |
| 認証方式 | Entra、managed identity、APIキー、OAuthのどれか |
| 利用者権限 | 全員同じ権限か、ユーザーごとの権限を維持するか |
| ログ設計 | プロンプト、ツール入力、ツール出力に機密情報が残らないか |
| 削除・変更手順 | ツール削除時に既存エージェントやワークフローが壊れないか |
非Microsoftサービス連携で注意すべきこと
MCPやOpenAPIを使えば、Microsoft外のサービスとも連携できます。これは大きな利点ですが、同時にリスクも増えます。
Microsoftのドキュメントでは、非Microsoftサービスに接続する場合、プロンプト内容などのデータが当該サービスに送信される可能性があること、利用者側がサービス利用や関連費用に責任を持つこと、Microsoftが第三者サービスを検証・保証するわけではないことが説明されています。(Microsoft Learn)
実務では、次の観点を必ず確認してください。
| リスク | 確認ポイント |
|---|---|
| データ送信 | プロンプト、添付ファイル、検索結果、顧客情報が外部に渡るか |
| データ保持 | 外部サービス側でログや入力データが保存されるか |
| データ所在 | データがどの国・地域で処理されるか |
| 契約 | Microsoftとの契約ではなく、外部サービス提供者との条件が適用されるか |
| コスト | API呼び出し、検索、外部サービス利用料が追加発生するか |
| 監査 | 誰が、いつ、どのツールを呼び出したか追跡できるか |
特にグローバル企業では、地域ごとのデータ保護要件が異なります。日本国内の情報システム部門だけで判断せず、欧州、米国、APACなどのリージョン要件も含めてレビューするべきです。
AI GatewayでMCPツールのガバナンスを強化する
MCPツールを本格的に使うなら、AI Gatewayによるガバナンスも確認すべきです。
Microsoftのドキュメントでは、MCPトラフィックをMicrosoft FoundryのAI Gateway経由でルーティングすることで、認証、レート制限、IP制限、監査ログなどを単一の管理ポイントで適用できると説明されています。この機能はプレビューであり、新規作成された一部のMCPツールが対象です。(Microsoft Learn)
AI Gatewayが有効な場面は次のとおりです。
| 目的 | AI Gatewayでできること |
|---|---|
| 過剰利用を防ぐ | ユーザーやプロジェクト単位でレート制限を設定 |
| 接続元を制限する | 信頼できるネットワークからのアクセスだけを許可 |
| 監査性を上げる | ログやメトリックを一元化 |
| リクエストを追跡する | Correlation IDを付与して障害調査しやすくする |
| 機密ヘッダーを保護する | 不要なヘッダーを削除して漏えいリスクを下げる |
ただし、認証ヘッダーを不用意に削除するとMCPサーバーへの接続が失敗します。セキュリティ強化のつもりで設定したポリシーが、業務エージェントの障害原因になることがあります。適用後は、必ずエージェントから実際にツールを呼び出して検証してください。(Microsoft Learn)
プロダクトオーナー向け：どのツールを選ぶべきか
プロダクトオーナーは、ツール名から選ぶのではなく、ユーザーが達成したい業務から逆算して選ぶべきです。
| やりたいこと | 第一候補 | 補足 |
|---|---|---|
| 最新の公開情報を回答したい | Web search | データ境界、コスト、引用表示を確認 |
| 社内文書から回答したい | File Search | 文書の更新頻度とアクセス権を設計 |
| 既存検索基盤を使いたい | Azure AI Search | 既存インデックスの品質が回答品質に直結 |
| SharePoint文書を使いたい | SharePoint | プレビュー状態や権限継承を確認 |
| 社内APIを呼びたい | OpenAPI tool | OpenAPI仕様の品質が重要 |
| 独自処理を実行したい | Azure FunctionsまたはFunction calling | 処理の責任範囲をアプリ側に持たせやすい |
| 複数ツールを横断的に使いたい | MCPまたはToolbox | 組織標準化に向くが、プレビュー範囲を確認 |
| 専門エージェント同士をつなぎたい | Agent-to-Agent | 業務分担を明確にしないと複雑化しやすい |
たとえば、「問い合わせ対応エージェント」を作る場合、最初からすべてのツールを有効にするのは避けるべきです。まずFile Searchで社内ナレッジに基づく回答を安定させ、次にOpenAPIでチケット作成や顧客情報参照を追加し、最後に必要な範囲だけWeb searchを許可する流れが現実的です。
ツールを増やすほど、エージェントの能力は広がります。一方で、誤ったツール選択、不要な外部送信、権限過多、コスト増加のリスクも増えます。プロダクトオーナーは「何でもできるエージェント」を目指すのではなく、「特定業務を安全に完了できるエージェント」を設計するべきです。
開発チーム向け：ツール呼び出しを安定させる設計
Foundry Agent Serviceでは、モデルが状況に応じてツールを呼び出します。しかし、ツールを追加しただけでは期待通りに使われるとは限りません。
Microsoftのベストプラクティスでは、エージェントの指示に「各ツールが何のためのものか」「どの状況で使うか」を明確に書くことが推奨されています。また、ツール呼び出しを制御するtool_choiceには、モデルに判断させるauto、必ずツールを使わせるrequired、使わせないnoneがあります。(Microsoft Learn)
実務では、次のような指示が有効です。
社内製品仕様や契約条件に関する質問では、まずFile Searchを使用してください。
公開されている最新情報が必要な場合のみWeb Searchを使用してください。
顧客の契約状態を確認する必要がある場合はOpenAPI toolを使用してください。
ツール呼び出しが失敗した場合は、推測で回答せず、失敗理由を説明して追加情報を確認してください。このように、ツール同士の優先順位を明示すると、回答の一貫性が上がります。特に「社内情報」と「公開Web情報」が混在する場合は、Web検索を先に使わせないことが重要です。公開情報で回答してしまうと、社内ポリシーや顧客固有の条件と食い違う可能性があります。
よくある失敗と対策
Microsoft Foundry Agent toolsの導入でよくある失敗は、モデルやプロンプトの問題に見えて、実際にはツール設定や認証、データ設計が原因であるケースです。
| 失敗パターン | 原因 | 対策 |
|---|---|---|
| エージェントがツールを呼ばない | ツールが添付されていない、モデルやリージョンが未対応、指示が曖昧 | ツール設定、モデル対応、tool_choice、実行トレースを確認 |
| 回答が社内文書に基づかない | File Searchのデータが不足、検索対象が違う | vector store、インデックス、structured inputsを確認 |
| API呼び出しに失敗する | OpenAPI仕様、認証、endpoint設定に問題 | operationId、security設定、project connectionを確認 |
| MCP連携が不安定 | 認証方式や承認設定が不適切 | Entra、APIキー、OAuth、承認フローを見直す |
| コストが増える | Web searchや外部API呼び出しが多すぎる | 呼び出し条件、レート制限、キャッシュ方針を設計 |
| ツール削除後にエージェントが壊れる | 依存関係を確認せず削除 | 削除前に利用中のエージェント・ワークフローを棚卸し |
Microsoftの公式ドキュメントでも、ツールが見つからない場合は正しいプロジェクトでBuild > Toolsを確認すること、設定できない場合は認証や依存サービスへのアクセスを確認すること、ツールが呼ばれない場合はベストプラクティスや検証ガイドを確認することが示されています。(Microsoft Learn)
導入時のおすすめ手順
Microsoft Foundry / Azure OpenAI環境でAgent toolsを導入するなら、次の順番で進めると安全です。
| ステップ | 作業 | 成果物 |
|---|---|---|
| 1 | 対象業務を1つに絞る | 問い合わせ対応、レポート作成、チケット登録など |
| 2 | 必要な情報源を分類する | 社内文書、公開Web、DB、外部API |
| 3 | 最小限のツールを選ぶ | File Search、Web search、OpenAPIなど |
| 4 | 認証方式を決める | Entra、managed identity、APIキー、OAuth |
| 5 | エージェント指示を書く | どの場面でどのツールを使うか明記 |
| 6 | 実行トレースで検証する | ツール入力・出力・失敗理由を確認 |
| 7 | ガバナンスを追加する | AI Gateway、レート制限、監査ログ |
| 8 | 再利用設計を検討する | Toolbox、private tool catalog、structured inputs |
最初のPoCでは、ツールを増やしすぎないことが重要です。たとえば「File Searchだけで社内FAQに答える」構成から始め、回答品質と権限設計を確認したうえで、OpenAPIやWeb searchを追加する方が失敗しにくくなります。
2026年4月更新をどう読むべきか
2026年4月23日に更新されたAgent tools overviewは、Microsoft Foundry Agent Serviceが「モデル中心」から「ツールとガバナンス中心」の設計に進んでいることを示す資料です。
IT管理者は、認証、接続、ログ、非Microsoftサービス利用時の責任分界点を確認すべきです。プロダクトオーナーは、業務ゴールから逆算して必要最小限のツールを選ぶべきです。開発者は、ツールの説明、tool_choice、structured inputs、実行トレースを使って、エージェントが期待通りに行動するか検証する必要があります。
次に取るべき行動は、既存のAzure OpenAI活用案件を見直し、「モデルだけで答えている部分」と「ツールで実行・検索・参照すべき部分」を切り分けることです。そのうえで、まず1つの業務シナリオに絞り、File SearchやOpenAPI toolなどリスクの小さい構成から検証を始めるのが現実的です。
コメント