Azure AI Foundryで複数チーム向けにToolboxを育てている場合、今回の「Tool search」は早めに確認しておきたい更新です。結論から言うと、Toolbox内のすべてのツール定義を毎ターンLLMへ渡すのではなく、必要なツールだけを実行時に検索・呼び出せるようにする公開プレビュー機能です。
特に、MCPサーバー、Azure AI Search、Web Search、File Search、Code Interpreter、社内APIなどを1つのToolboxにまとめ始めている組織では、コンテキスト肥大化、トークンコスト、誤ったツール選択を抑えるための実用的な選択肢になります。Microsoftの公式ドキュメントでも、Toolboxに多くのツールが含まれる場合、毎回すべてのツール定義をモデルへ渡すと、トークンコスト、コンテキスト消費、ツール選択ミスが重なる問題があると説明されています。(Microsoft Learn)
Azure AI FoundryのTool searchは何が変わるのか
今回の更新は、Azure AI Foundry、現在の公式表記ではMicrosoft FoundryのToolboxesに、ツール検索の仕組みを追加するものです。Azure Updatesでは「Public Preview: Tool search in Microsoft Foundry toolboxes」として案内されており、大規模なマルチチームのツールカタログから適切なツールを探しやすくする機能として説明されています。(マイクロソフト Azure)
従来の考え方では、エージェントが利用できるツールをあらかじめ一覧として見せ、その中からモデルに選ばせる構成が一般的でした。しかし、Toolboxが大きくなると、たとえば次のような問題が起きます。
- 利用しないツールの定義まで毎回コンテキストに入る
- 入力トークンが増え、推論コストや遅延に影響しやすい
- 似た名前や似た説明のツールが増え、モデルが誤選択しやすくなる
- チームごとに追加したツールが混在し、運用者が把握しにくくなる
Tool searchを有効にすると、Toolbox内の通常ツールを最初からすべて表示するのではなく、モデルには主にtool_searchとcall_toolというメタツールを使わせます。モデルは必要な能力を自然言語でtool_searchに問い合わせ、FoundryがToolbox内のツールを評価して関連するツールだけを返します。その後、モデルは見つかったツールをcall_toolで実行します。(Microsoft Learn)
つまり、変更の本質は「全ツールを常時見せる」から「必要なツールを実行時に発見する」への切り替えです。
これまでのToolboxとTool search有効時の違い
Toolbox自体は、複数のツールをまとめて構成し、エージェントからMCP互換エンドポイントとして利用できる仕組みです。公式ドキュメントでは、Web Search、Azure AI Search、Code Interpreter、File Search、MCPサーバー、OpenAPIツールなどをまとめて構成し、各エージェントへ個別にツールを接続する代わりに、Toolboxエンドポイントへ接続できると説明されています。(Microsoft Learn)
Tool searchを入れると、Toolboxの使い方は次のように変わります。
| 観点 | 従来のToolbox | Tool search有効時 |
|---|---|---|
| モデルに見えるツール | Toolbox内のツール定義が初期一覧に出やすい | 初期一覧では主にtool_searchとcall_toolを使う |
| ツール選択 | モデルが表示済みのツール一覧から選ぶ | モデルが必要な能力を検索し、関連ツールだけを見る |
| 大規模Toolboxへの適性 | ツール数が増えるほどコンテキストが重くなりやすい | ツール数が増えても初期のツール面を小さく保ちやすい |
| 運用上の工夫 | ツール名・説明の整理が重要 | 説明に加え、ピン留めや検索キーワード調整が重要 |
| 向いているケース | 少数の固定ツール | 10個以上、またはチーム横断で増えるツールカタログ |
Microsoftのドキュメントでは、Tool searchはToolboxに10〜15個を超えるツールがある場合や、タスクごとに必要なツールの組み合わせが変わる場合に使うとされています。(Microsoft Learn)
対象になる管理者・開発者
この更新の影響を受けやすいのは、Azure AI Foundryでエージェントを試作している人よりも、複数チームで運用するエージェント基盤を作っている管理者や開発者です。
| 対象者 | 確認すべきポイント |
|---|---|
| AIエージェント開発者 | Tool searchを有効化した後も、必要なツールが正しく見つかるか |
| Azure管理者 | FoundryプロジェクトのRBAC、接続、MCPエンドポイント利用条件 |
| プラットフォーム担当 | 複数チームが追加するツールの命名規則、説明文、バージョン管理 |
| セキュリティ担当 | OAuth、Microsoft Entra ID、接続情報、ツール実行権限の整理 |
| 運用担当 | 本番投入前の検証、失敗時の切り戻し、監視・トラブルシュート手順 |
既存のToolboxが直ちに壊れる種類の変更ではありません。Tool searchは、Toolboxバージョンのツール一覧にtoolbox_search_previewを追加して有効化する構成です。したがって、すでに稼働しているエージェントに対しては、いきなり既定バージョンへ反映するのではなく、新しいToolboxバージョンを作り、バージョン固有エンドポイントで検証してから昇格するのが安全です。公式ドキュメントでも、Tool searchとToolboxのバージョン管理を組み合わせ、既定化する前にバージョン固有エンドポイントでテストすることが推奨されています。(Microsoft Learn)
有効化の基本はtoolbox_search_previewを追加すること
Tool searchを有効にする基本設定は、Toolboxバージョンのtools配列に{"type": "toolbox_search_preview"}を追加することです。公式ドキュメントでは、この設定を追加するとToolbox内の他のツールは初期ツール一覧に表示されず、tool_search経由で発見されると説明されています。(Microsoft Learn)
REST APIで考えると、構成のイメージは次のようになります。
{
"description": "Large toolbox with tool search enabled",
"tools": [
{
"type": "toolbox_search_preview"
},
{
"type": "mcp",
"server_label": "github",
"server_url": "https://your-mcp-server.example.com",
"require_approval": "never",
"project_connection_id": "github-mcp-connection"
}
]
}Python SDKではToolboxSearchPreviewTool()、JavaScriptでは{ type: "toolbox_search_preview" }のように指定する例が公開されています。(Microsoft Learn)
注意したいのは、toolbox_search_previewは通常の業務ツールではなく、Tool searchを有効化するための構成ディレクティブだという点です。tools/listにそのまま表示されるものではなく、プラットフォーム側がtool_searchとcall_toolを注入する仕組みです。(Microsoft Learn)
管理者が最初に確認すべき設定
Tool searchの導入前に、管理者は「検索できるか」だけでなく、「安全に呼び出せるか」まで確認する必要があります。
| 確認項目 | 見るべき内容 | 放置した場合のリスク |
|---|---|---|
| Foundryプロジェクトの権限 | 開発者、エージェントのマネージドID、OAuth利用ユーザーに必要なロールがあるか | ツール検索はできても実行時に認可で失敗する |
| Toolboxのバージョン | 新しいバージョンでTool searchを試し、既定化前に検証したか | 既存エージェントの挙動が想定外に変わる |
| MCPエンドポイントのヘッダー | Foundry-Features: Toolboxes=V1Previewを付けているか | Toolbox MCPエンドポイント呼び出しに失敗する |
| ツールの説明文 | 各ツールに具体的な説明があるか | tool_searchで適切なツールが返らない |
| 接続情報 | project_connection_idやOAuth接続が正しいか | 検索後のcall_toolで失敗する |
| ネットワーク要件 | VNet、Private Endpoint、外部公開エンドポイントの制約を確認したか | 開発環境では動くが本番ネットワークで失敗する |
Toolbox MCPエンドポイントを呼び出すリクエストでは、Foundry-Features: Toolboxes=V1Previewヘッダーが必要です。公式ドキュメントでは、このヘッダーがない呼び出しは失敗すると明記されています。(Microsoft Learn)
開発者が見直すべきツール定義
Tool searchの精度は、ツール名と説明文に大きく依存します。公式ドキュメントでも、ツールの説明がない、または曖昧な場合は、関連する検索クエリでも返されにくいとされています。(Microsoft Learn)
たとえば、次のような説明では検索に弱くなります。
| 悪い説明 | 問題点 | 改善例 |
|---|---|---|
データを取得する | 何のデータか分からない | 顧客IDを指定してCRMから顧客プロフィール、契約状況、最終接触日を取得する |
検索ツール | 検索対象が不明 | 社内FAQ、製品マニュアル、障害対応ナレッジを検索する |
チケット処理 | 作成、更新、参照の区別がない | サポートチケットを作成し、優先度、担当チーム、顧客メモを登録する |
レポート | 生成なのか取得なのか不明 | 売上データから月次レポートを生成し、CSV形式で返す |
実務では、ツール説明文に次の4点を入れると検索されやすくなります。
- 何をするツールか
- どのデータや外部システムを扱うか
- どの入力が必要か
- どのような業務シーンで使うか
日本語のユーザーが使うエージェントであっても、MCPサーバー側のツール説明が英語だけの場合があります。その場合、additional_search_textで日本語の言い換えや社内用語を追加すると、利用者の自然な表現に合わせやすくなります。
pinとadditional_search_textを使い分ける
Tool searchでは、すべてを検索任せにするのではなく、重要なツールを常に見えるようにする設定も用意されています。
公式ドキュメントでは、tool_configsでpinを設定すると、対象ツールをtools/listに常時表示できると説明されています。また、additional_search_textを使うと、モデルに表示するスキーマ自体を増やさず、検索ランキング用の補助キーワードを追加できます。(Microsoft Learn)
| 設定 | 使う場面 | 例 |
|---|---|---|
pin | ほぼ毎回使う重要ツールを検索なしで呼ばせたい | 認証済みユーザー情報取得、現在のプロジェクト状態取得 |
additional_search_text | ツール名や説明と、利用者の言葉がずれている | 案件、商談、CRM、顧客対応履歴などの同義語 |
| 自動ピン留め | よく使われるツールを利用パターンに応じて前面に出したい | ユーザーごとに頻繁に使うツールを自動的に表示 |
pinの使いすぎには注意が必要です。多くのツールを固定表示すると、Tool searchで初期コンテキストを小さくするメリットが薄れます。目安としては、「このツールがないと多くの会話が始まらない」ものだけを固定表示にし、それ以外は検索対象に回すのが現実的です。
システムプロンプトも見直す
Tool searchを有効にしても、モデルがtool_searchを使うべきだと理解していなければ、必要なツールを探さずに「対応できません」と答える可能性があります。
公式ドキュメントでも、必要な機能が現在の一覧にない場合はtool_searchを呼ぶよう、システムプロンプトで案内することがベストプラクティスとして示されています。(Microsoft Learn)
実務では、システムプロンプトに次のような指示を追加するとよいでしょう。
必要な機能が現在のツール一覧に見つからない場合、回答を諦める前に tool_search を使って、必要な能力を自然言語で検索してください。該当するツールが見つかった場合は、そのツールを call_tool で呼び出してください。この指示は、特にツール数が多いエージェントや、業務領域ごとにツールが分かれているエージェントで効果があります。
影響範囲は「大規模Toolbox」と「チーム横断運用」で大きい
Tool searchの恩恵が大きいのは、単純なチャットボットではなく、業務アクションを伴うエージェントです。
たとえば、社内ヘルプデスクエージェントを考えると、Toolboxには次のようなツールが増えていきます。
| 業務領域 | 追加されやすいツール |
|---|---|
| 問い合わせ対応 | FAQ検索、マニュアル検索、過去チケット検索 |
| IT管理 | アカウント状態確認、権限グループ確認、端末情報取得 |
| ワークフロー | チケット作成、承認依頼、担当者アサイン |
| 通知 | Teams通知、メール送信、カレンダー登録 |
| 分析 | 利用状況集計、障害件数レポート、CSV出力 |
このような構成では、すべてのツールを常時モデルに見せるより、「パスワードリセットに必要なツール」「障害レポートに必要なツール」「端末台帳を確認するツール」のように、タスクごとに必要なものだけを発見する方が合理的です。
一方で、ツールが3〜5個程度しかなく、用途も固定されている場合は、無理にTool searchを入れる必要はありません。プレビュー機能であることを考えると、小規模構成では通常のToolbox運用を継続し、ツール数が増えるタイミングで検討する方が管理負荷を抑えられます。
プレビュー機能としての注意点
Tool searchは公開プレビューです。Microsoftのプレビュー機能に関するドキュメントでは、プレビュー項目はサービスレベルアグリーメントなしで提供され、本番ワークロードには推奨されないと説明されています。(Microsoft Learn)
そのため、いきなり本番エージェントの既定Toolboxへ反映するのではなく、次の順序で進めるべきです。
| フェーズ | 実施内容 | 判断基準 |
|---|---|---|
| 調査 | 現在のToolbox内ツール数、説明文、利用頻度を棚卸し | 10個以上、または今後増える見込みがあるか |
| 試作 | 新しいToolboxバージョンでtoolbox_search_previewを追加 | tools/listにtool_searchが出るか |
| 検証 | 代表的な業務プロンプトでツール検索結果を確認 | 必要なツールが上位に返るか |
| 調整 | description、pin、additional_search_textを改善 | 誤検索、検索漏れが減るか |
| 展開 | 既定バージョンへ昇格、または限定ユーザーで利用 | 既存エージェントの応答品質が下がらないか |
| 運用 | 失敗ログ、OAuth同意、接続エラーを監視 | 実行失敗の原因を切り分けられるか |
プレビュー段階では、SDK、API、ポータルUI、制約事項が変更される可能性があります。記事執筆時点の情報だけで固定運用を決めず、展開前に必ず公式ドキュメントと対象SDKのリリース情報を確認してください。
トラブルが起きやすいポイント
Tool searchは便利ですが、導入直後は「検索できない」「見つかるが実行できない」「モデルが検索しない」という問題が起きがちです。公式ドキュメントのトラブルシュートでも、toolbox_search_preview未設定、説明文不足、直接ツール追加、接続設定不備などが原因として挙げられています。(Microsoft Learn)
| 症状 | よくある原因 | 対応 |
|---|---|---|
tool_searchがtools/listに出ない | 新しいToolboxバージョンにtoolbox_search_previewが入っていない | 対象バージョンを確認し、新バージョンを作成する |
| 検索してもツールが返らない | ツール説明が短い、曖昧、検索語と合っていない | 説明文とadditional_search_textを改善する |
| 初期一覧に通常ツールが出続ける | Toolboxではなくエージェントに直接ツールを追加している | ツールの接続位置を整理する |
モデルがtool_searchを呼ばない | システムプロンプトに検索指示がない | 必要な機能が見つからない場合は検索するよう明記する |
| 検索後の実行に失敗する | 接続、認可、OAuth、project_connection_idに問題がある | ツール単体でMCPエンドポイントから実行確認する |
| 初回だけOAuth同意エラーになる | OAuthベースのMCPサーバーを使っている | 同意URLで認可を完了し、再試行する |
特に注意したいのは、「検索結果に出た＝実行できる」ではない点です。検索はツール発見の仕組みであり、実行時には接続先の認可、ネットワーク、入力パラメータ、外部APIの状態が関係します。
ネットワークとセキュリティはツール単位で見る
Toolboxはツールの構成や接続をまとめやすくしますが、すべてのツールが同じネットワーク条件で動くわけではありません。公式ドキュメントでは、ツールタイプごとにVNetサポートや通信経路が異なることが示されています。たとえば、MCPやAzure AI Search、Code Interpreter、Web Searchなどで対応状況や通信経路が異なり、File SearchやFabric IQは該当ドキュメント時点でVNet未対応とされています。(Microsoft Learn)
管理者は、Tool searchの有効化そのものよりも、検索で見つかった後に実行されるツールの通信経路を確認する必要があります。
確認すべき観点は次の通りです。
- 外部MCPサーバーがインターネット公開か、Private Endpoint経由か
- Azure AI Searchの接続にAPIキーを使うか、マネージドIDを使うか
- OAuth同意が必要なツールを誰が初回承認するか
- エージェントのマネージドIDに過剰な権限を与えていないか
- チーム横断Toolboxで、他部門のツールが誤って呼ばれないか
- ログや監査で、どのツールが呼ばれたか追跡できる運用になっているか
Toolboxは認証情報や接続管理を集約しやすい仕組みです。公式ドキュメントでも、ToolboxではMicrosoft Entra IDとOAuthを使い、資格情報の注入、トークン更新、ポリシー適用を実行時に集中管理できると説明されています。(Microsoft Learn)
移行時にやるべき棚卸し
既存のToolboxへTool searchを導入する前に、まずツール一覧を整理してください。設定だけ追加しても、説明文が粗いままでは検索精度が出ません。
| 棚卸し項目 | 判断基準 |
|---|---|
| ツール数 | 10個以上、または半年以内に増える予定があるか |
| 利用頻度 | ほぼ毎回使うツールと、たまに使うツールを分けられるか |
| 説明文 | 業務担当者が読んでも用途が分かる説明になっているか |
| 同義語 | 社内用語、日本語、英語略語が検索語として考慮されているか |
| 重複ツール | 似た名前、似た機能のツールが複数ないか |
| 権限 | ツール検索で見つかっても、ユーザー権限上実行してよいか |
| 切り戻し | 既存のToolboxバージョンへ戻せるか |
移行で失敗しやすいのは、ツール説明を開発者視点のままにすることです。たとえばget_customerよりも、「顧客IDまたはメールアドレスから顧客情報、契約プラン、サポート履歴を取得する」のように、業務の言葉で説明した方が検索に適しています。
展開前のテスト観点
Tool searchの検証では、単にtool_searchが存在するかだけでなく、業務シナリオごとに「必要なツールが見つかるか」「不要なツールが混じらないか」を確認します。
| テストケース | 期待結果 |
|---|---|
| 「顧客Aの契約状況を確認して」 | CRMまたは契約情報取得ツールが返る |
| 「先月の障害件数をCSVにして」 | 障害検索、集計、Code Interpreterなど必要なツールが返る |
| 「FAQにない問い合わせをチケット化して」 | FAQ検索後、チケット作成ツールが使われる |
| 「権限がない社内データを取得して」 | ツールが見つかっても権限で制御される |
| 「存在しない業務システムを操作して」 | 無理に近いツールを呼ばず、できない理由を返す |
このとき、検索結果だけでなく、最終応答まで確認することが重要です。Tool searchで正しいツールが返っていても、モデルが入力パラメータを誤る、不要な再検索を繰り返す、権限エラーを適切に説明できないといった問題が起きるためです。
導入判断の目安
Tool searchを導入すべきか迷う場合は、次の基準で判断するとよいでしょう。
| 状況 | 判断 |
|---|---|
| Toolbox内のツールが5個以下で用途も固定 | 急いで導入しなくてよい |
| ツールが10個以上ある | 検証候補にする |
| 複数チームがMCPサーバーやAPIを追加している | 導入優先度が高い |
| モデルが似たツールを間違えて呼ぶ | 説明文改善とTool searchを検討 |
| 入力トークンやレイテンシが気になる | Tool searchの効果を測定する価値がある |
| 本番ワークロードで安定性を最優先したい | プレビュー制約を踏まえ、限定検証から始める |
大切なのは、Tool searchを「新機能だから入れる」のではなく、「Toolboxが大きくなったことで起きる運用課題を解くために入れる」ことです。
まず何から始めるべきか
Azure AI FoundryでToolboxを使っている管理者・開発者は、まず現在のToolboxを棚卸ししてください。ツール数、説明文、利用頻度、接続、権限を確認し、10個以上のツールを持つToolboxや、今後チーム横断で拡張されるToolboxから優先的に検証します。
次に、新しいToolboxバージョンを作成し、toolbox_search_previewを追加します。バージョン固有エンドポイントでtools/listを確認し、tool_searchが表示され、通常ツールが初期一覧に出すぎていないことを確認します。そのうえで、代表的な業務プロンプトを使い、必要なツールが検索されるか、pinやadditional_search_textで調整が必要かを判断します。
Tool searchは、Azure AI Foundryのエージェント開発を「小さな試作」から「複数チームで管理する実運用」へ進めるための機能です。導入の成否は、設定値そのものよりも、ツール説明、権限設計、バージョン管理、テストシナリオの品質で決まります。まずは本番ではなく検証用Toolboxで、検索精度と実行失敗のパターンを確認するところから始めるのが安全です。
コメント