Microsoft Foundry / Azure OpenAIでエージェントを作るとき、2026年4月更新で特に押さえるべきポイントは「ツールを増やすこと」ではなく、ツールをいつ呼ぶか、どう検証するか、どこまでデータを渡すかを設計することです。Microsoft Learnの「Tool best practices for Microsoft Foundry Agent Service」は、File Search、OpenAPI、MCP、Web Searchなどを使う現場に向けて、tool_choice、実行トレース、認証、モデル・リージョン対応を確認する実務寄りのガイドとして整理されています。Microsoft Foundryの2026年4月更新一覧でも同記事は更新対象に含まれており、Agent ServiceをPoCから本番運用へ進めるIT管理者、プロダクトオーナー、Microsoftエコシステム担当者は早めに確認すべき内容です。(Microsoft Learn)
Microsoft Foundry / Azure OpenAIの2026年4月更新で重要なのは「ツール運用の標準化」
Microsoft Foundry Agent Serviceでは、エージェント単体がテキストを生成するだけでなく、ツールを通じて情報検索、API呼び出し、外部サービス接続、コード実行、社内データ検索などを行えます。Microsoftの公式ドキュメントでは、ツールはエージェントの機能を拡張するものと説明されており、たとえばWeb検索、Code Interpreter、File Search、Function calling、OpenAPI、MCPなどが代表例です。(Microsoft Learn)
今回の更新ポイントは、個別ツールの紹介にとどまりません。実務上は、次のような課題に答える内容として読むべきです。
- エージェントが意図したタイミングでツールを呼んでいるか
- 社内データと外部Web検索をどう使い分けるか
- OpenAPIやMCPを接続したときに、認証情報や機密データをどう守るか
- モデルやリージョンによって使えないツールを、導入前にどう確認するか
- ツール呼び出しが失敗したとき、どこを見ればよいか
つまり、Microsoft Foundry / Azure OpenAIを使ったエージェント開発は、「チャットボットを作る」段階から「業務システムとして管理する」段階に進んでいます。
「Tool best practices for Microsoft Foundry Agent Service」の要点
Microsoft Learnの該当記事では、Microsoft Foundry Agent Serviceでツールを使う際のベストプラクティスとして、構成、信頼性、セキュリティ、モデル・リージョン対応、トラブルシューティングが整理されています。特に重要なのは、ツールを「使えるか」だけでなく、「安全に、再現性を持って使えるか」を確認する観点です。(Microsoft Learn)
| 観点 | 公式ドキュメントの主な内容 | 実務での見方 |
|---|---|---|
| ツール構成 | Foundry tool catalogでツールと接続を構成する | どのエージェントにどのツールを許可するかを管理する |
| 呼び出し制御 | tool_choiceでツール呼び出しを制御する | 自動判断に任せる場面と、必ず呼ばせる場面を分ける |
| 指示設計 | ツールの用途と使う条件をエージェント指示に書く | File SearchとWeb Searchのような重複ツールの使い分けを明文化する |
| セキュリティ | ツール出力を信頼しすぎず、必要最小限の情報だけ送る | 外部APIやMCPに渡すデータを制限する |
| 検証 | run tracesで入力・出力・呼び出しタイミングを確認する | 障害調査だけでなく、品質改善にも使う |
| 対応範囲 | リージョンとモデルごとに利用可能なツールが異なる | 本番リージョンと採用モデルで事前検証する |
IT管理者やプロダクトオーナーにとって重要なのは、これらを開発者任せにしないことです。ツールの追加は業務データ、外部通信、認証、監査ログに関わるため、設計段階から運用ルールを決めておく必要があります。
tool_choiceはツール呼び出しの再現性を高める重要設定
今回のベストプラクティスで特に注目したいのが、tool_choiceです。Microsoft Learnでは、ツール呼び出しをより決定的に制御する方法としてtool_choiceが紹介され、主にauto、required、noneの選択肢が示されています。(Microsoft Learn)
| 設定 | 動作 | 向いている場面 | 注意点 |
|---|---|---|---|
auto | モデルがツールを呼ぶか判断する | 一般的な問い合わせ、探索的な会話 | 必ずしも期待どおりにツールを呼ぶとは限らない |
required | 1つ以上のツール呼び出しを必須にする | 社内データ検索、注文状況確認、API照会など | 不要な場面でもツール呼び出しが発生する可能性がある |
none | ツールを呼ばない | 要約、文章作成、内部知識だけで足りる回答 | 最新情報や業務データが必要な質問には不向き |
たとえば、社内FAQをFile Searchで検索して回答するサポートエージェントでは、ユーザーの質問に対して必ず検索を実行したい場面があります。この場合、autoに任せるとモデルが「検索しなくても答えられる」と判断することがあり、古い知識や推測で回答するリスクが残ります。
一方、すべての質問でrequiredにすると、単なる挨拶や文章の言い換えでもツール呼び出しが走り、コストやレイテンシが増えます。実務では、エージェント全体で一律設定するのではなく、ユースケースごとに使い分ける設計が重要です。
実務での判断基準
tool_choiceは、次のように決めると失敗しにくくなります。
| ユースケース | 推奨の考え方 |
|---|---|
| 社内ナレッジを根拠に回答する | 検索が必須ならrequiredを検討 |
| 最新ニュースや市場情報を確認する | Web Searchなどの利用を前提にし、回答に根拠を残す |
| 定型文作成・要約・翻訳 | ツール不要ならnoneで無駄な呼び出しを抑える |
| ユーザーの注文情報や契約情報を照会する | API呼び出しを必須化し、認証・権限チェックを合わせて設計する |
| 相談内容によって検索が必要な場合だけ使う | autoにしつつ、指示文で判断条件を明確にする |
ツール指示は「何を使うか」より「いつ使うか」を書く
エージェント開発でよくある失敗は、ツールを接続しただけで精度が上がると考えてしまうことです。Microsoft Learnでは、エージェントの指示に各ツールの用途と使用タイミングを明記することが推奨されています。複数ツールの用途が重なる場合は、判断ルールを追加することも示されています。(Microsoft Learn)
悪い指示の例は、次のようなものです。
必要に応じてツールを使って回答してください。この指示では、モデルがどのツールをいつ使うべきか判断しにくくなります。File Search、Azure AI Search、Web Search、OpenAPIが同時に使える環境では、社内文書を探すべき質問にWeb Searchを使うなど、意図しない挙動が起こりやすくなります。
より実務向けの指示は、次のように具体化します。
社内規程、製品マニュアル、FAQに関する質問は、最初にFile Searchを使用してください。
公開Web上の最新情報が必要な場合のみWeb Searchを使用してください。
顧客ID、注文番号、契約状況の確認が必要な場合はOpenAPI toolを使用してください。
ツール呼び出しが失敗した場合、推測で回答せず、取得できなかった情報と追加で必要な情報をユーザーに伝えてください。このように書くと、エージェントの挙動が確認しやすくなります。IT管理者はツール設定だけでなく、プロンプトやエージェント指示のレビューも運用対象に含めるべきです。
File Search、Web Search、OpenAPI、MCPの使い分け
Microsoft Foundry Agent Serviceでは、複数のツールを組み合わせられます。ただし、便利だからといって多くのツールを同時に有効化すると、判断の曖昧さ、セキュリティリスク、運用コストが増えます。
代表的なツールの使い分けは次のとおりです。
| ツール | 主な用途 | 向いているシーン | 失敗しやすいポイント |
|---|---|---|---|
| File Search | アップロード済みファイルや独自文書の検索 | 社内FAQ、製品マニュアル、規程、提案書検索 | データが古い、ファイル分割や検索対象が不適切 |
| Azure AI Search | 既存の検索インデックスを使った業務データ検索 | 大規模ナレッジ、構造化・非構造化データの検索 | インデックス設計や権限制御を軽視する |
| Web Search | 公開Webの最新情報取得 | 最新の製品情報、公開ドキュメント確認、市場調査 | 社内情報が必要な質問にもWebを使ってしまう |
| OpenAPI tool | 外部HTTP APIの呼び出し | 注文照会、在庫確認、チケット作成、CRM連携 | API仕様、認証、入力検証が不十分 |
| Function calling | アプリ側で関数を実行 | 軽量な業務ロジック、社内システム連携 | 実行結果の検証やエラーハンドリング不足 |
| MCP | MCPサーバー経由の外部ツール接続 | 複数エージェントで共有するツール、外部サービス連携 | 信頼できないMCPサーバーを接続する、ヘッダーやトークンをログに残す |
Microsoftのツールカタログ説明では、組み込みツールとカスタムツールが整理されており、MCP、A2A、OpenAPIなどを使って外部機能を接続できることが説明されています。また、Foundry tool catalogとcore tools frameworkは一般提供とされる一方、一部の個別ツールはプレビュー扱いです。導入時は、各ツールのプレビュー状態や利用条件を確認する必要があります。(Microsoft Learn)
セキュリティ面の更新ポイント：ツール出力は信頼しすぎない
ツールを使うエージェントでは、モデル単体のセキュリティだけでは不十分です。ツールはモデルの外部とデータを送受信するため、APIレスポンス、検索結果、MCPサーバーからの出力をそのまま信頼すると、誤処理や情報漏えいにつながる可能性があります。
Microsoft Learnでは、ツール出力を信頼できない入力として扱うこと、必要最小限の情報だけを送ること、キーやトークンなどの資格情報をプロンプトに含めないこと、トレースやアプリケーションログにシークレットを記録しないことが推奨されています。(Microsoft Learn)
実務では、次のように対策を落とし込むとよいでしょう。
| リスク | 具体例 | 対策 |
|---|---|---|
| 機密情報の過剰送信 | 顧客の全プロフィールを外部APIに送る | APIに必要なIDや条件だけを送る |
| 認証情報の漏えい | プロンプトやログにAPIキーを含める | project connectionやマネージドIDを使い、プロンプトに秘密情報を入れない |
| 不正なツール出力 | 外部ツールが想定外の値を返す | 金額、権限、IDなど重要値はアプリ側で検証する |
| ログからの情報漏えい | run traceやアプリログにトークンが残る | ログ設計時にマスキング、保存期間、閲覧権限を定義する |
| 非Microsoftサービスの利用リスク | 外部MCPサーバーにプロンプト内容が送信される | 提供元、データ保持、データ所在地、利用規約を確認する |
特にMCPやOpenAPIを使う場合、ツール接続は「便利な拡張」ではなく「外部システム連携」です。社内のセキュリティレビューでは、通常のAPI連携と同じように、データ分類、通信先、認証方式、監査ログ、障害時の影響範囲を確認すべきです。
MCP利用ではAI Gatewayによるガバナンスも検討する
MCPツールを本番利用する場合、個々のエージェントからMCPサーバーへ直接接続するだけでは、統制が難しくなることがあります。Microsoft Learnでは、AI Gatewayを使ってMCPトラフィックをルーティングし、認証、レート制限、IP制限、監査ログなどを一元的に適用できると説明されています。この機能はプレビューであり、対象条件があるため、採用時は公式ドキュメントの制約を確認する必要があります。(Microsoft Learn)
AI Gatewayを検討すべきケースは次のとおりです。
- 複数のエージェントが同じMCPツールを利用する
- 外部MCPサーバーへの通信を監査したい
- 部門ごと、プロジェクトごとに呼び出し回数を制限したい
- 特定ネットワークからのアクセスだけを許可したい
- 認証方式やポリシーを中央管理したい
プロダクトオーナー視点では、AI Gatewayは単なるセキュリティ機能ではありません。ツール利用の可観測性を高め、障害調査やコスト管理にも役立つ統制ポイントになります。
モデルとリージョン対応は導入前に必ず確認する
Microsoft Foundry / Azure OpenAIのエージェント開発では、「このモデルでこのツールが使えるか」「本番リージョンでそのツールが使えるか」を早い段階で確認する必要があります。Microsoft Learnのベストプラクティス記事では、ツールの可用性はリージョンとモデルによって決まると説明され、地域別・モデル別の対応表が掲載されています。(Microsoft Learn)
ここで注意したいのは、PoC環境と本番環境の差です。PoCでEast USやSweden Centralを使って動作確認したあと、本番ではJapan Eastや別リージョンを指定する場合、同じツール構成がそのまま使えるとは限りません。また、モデルを変更した場合も、ツール対応が変わる可能性があります。
導入前の確認項目は次のとおりです。
| 確認項目 | 見るべきポイント |
|---|---|
| 本番リージョン | 利用予定のツールが対象リージョンでサポートされているか |
| 採用モデル | File Search、OpenAPI、MCP、Web Searchなど必要ツールに対応しているか |
| 画像生成ツール | 必要なモデル構成が同一プロジェクト内にあるか |
| プレビュー機能 | 商用利用の条件、サポート範囲、変更リスクを確認したか |
| データ所在地 | 社内ポリシーや規制上の要件を満たすか |
| フェイルオーバー | 別リージョンへ切り替えた場合に同じツールが使えるか |
特にグローバル展開を想定する組織では、米国、欧州、日本、アジア太平洋などで同じ設計を横展開できるかを確認してください。リージョン差を後から吸収しようとすると、ツール構成、認証、データ配置、監査ログの設計をやり直すことになりがちです。
run tracesは「不具合調査」だけでなく品質改善に使う
ツール呼び出しの検証では、run tracesの確認が重要です。Microsoft Learnでは、エージェントがいつツールを呼んだか、入力と出力がどうだったかを確認するためにrun tracesをレビューすることが推奨されています。(Microsoft Learn)
run tracesは、単に「エラーが出たから見るもの」ではありません。プロダクト品質を高めるために、次のような観点で継続的に確認できます。
| 確認観点 | 見るべき内容 | 改善アクション |
|---|---|---|
| ツールが呼ばれない | toolがエージェントに接続されているか、モデルが対応しているか | ツール設定、モデル選定、tool_choice、指示文を見直す |
| 不要なツールが呼ばれる | 要約や雑談でもWeb SearchやAPIが呼ばれていないか | noneや指示文の条件分岐を検討する |
| 検索結果が不適切 | File SearchやAzure AI Searchの結果が空、または関連性が低い | インデックス、文書分割、メタデータ、検索対象を見直す |
| APIエラーが多い | 認証、エンドポイント、入力形式、レート制限に問題がないか | OpenAPI仕様、認証設定、入力バリデーションを修正する |
| 応答が遅い | ツール呼び出し回数や外部APIの応答時間が長くないか | ツール数、キャッシュ、処理順序を見直す |
エージェントの品質は、回答文だけを見ても分かりません。どのツールを、どの入力で、どの順番で呼んだのかを追跡して初めて、再現性のある改善ができます。
IT管理者が見るべき運用チェックリスト
IT管理者は、Microsoft Foundry Agent Serviceのツール利用を「開発チームの設定作業」として扱うのではなく、権限、接続、ログ、データ保護を含む運用設計として管理する必要があります。
| 項目 | チェック内容 |
|---|---|
| 権限 | Foundryプロジェクトへのアクセス権、Azure AI Developerロール相当の権限が適切か |
| 接続 | Azure AI Search、SharePoint、Bing grounding、外部APIなどの接続が管理されているか |
| 認証 | APIキーではなく、可能な範囲でMicrosoft Entra IDやマネージドIDを使っているか |
| ログ | run tracesやアプリログに機密情報が残らない設計になっているか |
| 外部サービス | 非Microsoftサービスの利用規約、データ保持、データ所在地を確認したか |
| 監査 | 誰がどのツールを追加・変更・削除したか追跡できるか |
| 変更管理 | ツール削除や設定変更が既存エージェントに影響しないか確認しているか |
| 対応範囲 | モデル・リージョン・プレビュー機能の制約を記録しているか |
Microsoftのツールカタログ説明では、ツールを削除する前に、そのツールを利用しているエージェントやワークフローを確認する必要があるとされています。実務では、ツールを共有資産として扱い、構成変更時の影響範囲を可視化することが大切です。(Microsoft Learn)
プロダクトオーナーが決めるべき設計方針
プロダクトオーナーは、ツールの技術詳細をすべて理解する必要はありません。ただし、エージェントが業務価値を出すには、何を自動化し、何を人に確認させるかを明確にする必要があります。
決めるべき方針は次の5つです。
| 方針 | 決める内容 |
|---|---|
| 回答の根拠 | 社内データ、公開Web、外部APIのどれを優先するか |
| 自動実行の範囲 | 検索だけか、チケット作成や更新処理まで行うか |
| 人の確認 | 金額変更、契約更新、削除処理などで承認を挟むか |
| 失敗時の動作 | 推測回答を許すか、追加質問や担当者連携に切り替えるか |
| 品質指標 | 正答率、参照根拠、処理時間、エスカレーション率をどう測るか |
たとえば、問い合わせ対応エージェントであれば、最初は「FAQ検索と回答案作成」までに限定し、顧客情報の更新やチケットクローズは人が確認する設計にすると安全です。運用実績を見ながら、低リスクな処理から自動化範囲を広げるほうが失敗しにくくなります。
よくある失敗と回避策
Microsoft Foundry / Azure OpenAIでツール付きエージェントを作るとき、失敗の多くはモデル性能ではなく、設計不足から起こります。
ツールを接続しただけで精度が上がると思ってしまう
ツールを追加しても、エージェントが適切に呼び出さなければ意味がありません。用途、優先順位、失敗時の動作を指示文に書き、run tracesで実際の挙動を確認してください。
社内検索とWeb検索の役割が曖昧になる
社内規程や契約条件の質問にWeb Searchを使うと、公開情報に基づく不正確な回答になる可能性があります。社内情報はFile SearchやAzure AI Searchを優先し、公開情報が必要な場合だけWeb Searchを使うルールにしましょう。
認証情報をプロンプトやログに入れてしまう
APIキー、トークン、OAuthシークレットをプロンプトへ直接書くのは避けるべきです。接続情報はFoundryの接続管理やマネージドIDなどを利用し、ログにも秘密情報が残らないようにします。
PoCリージョンのまま本番設計を決めてしまう
PoCで動いた構成が、本番リージョンでもそのまま動くとは限りません。モデルとツールの対応表を本番前提で確認し、必要なら代替ツールや代替モデルを決めておきます。
外部MCPサーバーの信頼性を確認しない
MCPは強力ですが、外部サービスにプロンプトやコンテキストが送られる可能性があります。提供元、認証方式、データ保持、監査ログ、障害時の連絡経路を確認してから接続しましょう。
導入時のおすすめ手順
これからMicrosoft Foundry Agent Serviceでツール付きエージェントを作る場合は、次の順序で進めると実務に乗せやすくなります。
| 手順 | 作業 | 成果物 |
|---|---|---|
| 1 | ユースケースを1つに絞る | 例：社内FAQ回答、注文照会、製品マニュアル検索 |
| 2 | 必要なツールを選ぶ | File Search、Azure AI Search、OpenAPIなど |
| 3 | モデルとリージョン対応を確認する | 本番候補モデル・リージョンの対応表 |
| 4 | ツール使用ルールを書く | いつ、どのツールを、どの優先順位で使うか |
| 5 | tool_choiceを設計する | auto、required、noneの使い分け |
| 6 | 認証とデータ送信範囲を決める | 接続管理、マネージドID、最小データ送信 |
| 7 | run tracesで検証する | ツール呼び出しログ、失敗パターン、改善点 |
| 8 | セキュリティレビューを行う | 外部通信、ログ、権限、監査、プレビュー機能 |
| 9 | 小規模ユーザーで試験運用する | フィードバック、品質指標、運用手順 |
| 10 | 本番化と継続改善を行う | 監視、変更管理、ツール棚卸し |
最初から多機能なエージェントを作るより、1つの業務に絞って、ツール呼び出しの品質を測れる状態にすることが重要です。特に本番化前には、失敗時の動作を必ずテストしてください。ツールが空の結果を返した場合、APIがエラーを返した場合、認証が切れた場合に、エージェントが推測で回答しないようにする必要があります。
2026年4月更新を踏まえた実務上の結論
Microsoft Foundry / Azure OpenAIの2026年4月更新で見るべきポイントは、ツール機能の拡充そのものより、ツール利用を本番運用に耐える形で管理するためのベストプラクティスが整理されたことです。
特に、次の3点はすぐに見直す価値があります。
tool_choiceと指示文で、ツールを呼ぶ条件を明確にする- run tracesで、実際のツール入力・出力・呼び出しタイミングを確認する
- 外部API、MCP、Web Searchに渡すデータと認証情報を最小化する
すでにMicrosoft Foundry Agent ServiceやAzure OpenAIベースのエージェントを試している場合は、まず既存エージェントのツール一覧、指示文、ログ、モデル・リージョン対応を棚卸ししてください。これから導入する場合は、ツールを多く接続する前に、1つの業務シナリオで「どの情報源を根拠にし、どの処理を自動化し、どこで人の確認を入れるか」を決めることが、失敗しない第一歩です。
コメント