AzureのCurate intent-based toolbox in Foundryとは?変更点と設定・移行手順

Azure の「Curate intent-based toolbox in Foundry(preview)」は、Microsoft Foundry のエージェントが、ユーザーの意図に合うツールだけを検索して呼び出せるようにする機能です。

今回のポイントは、Toolboxに登録された全ツールを毎回モデルへ渡すのではなく、tool_searchで必要な機能を探し、call_toolで実行できる点です。特に、10~15個以上のツールを扱うエージェントでは、コンテキストの肥大化やツールの選択ミスを抑える効果が期待できます。(Microsoft Learn)

目次

Azure の新機能・変更点:Curate intent-based toolbox in Foundry の変更点

Microsoft Foundry のToolboxは、Web Search、Azure AI Search、File Search、Code Interpreter、MCPサーバーなどをまとめ、単一のMCP互換エンドポイントとして公開する管理リソースです。

今回パブリックプレビューとなったTool Searchを有効にすると、モデルは最初からすべてのツール定義を受け取りません。代わりに、次の2つのメタツールを利用します。

メタツール役割
tool_search自然言語で必要な機能を検索し、関連するツールを取得する
call_tool検索で見つかったツールを名前で呼び出す

たとえば、「顧客の注文状況を確認して」と指示された場合、モデルは大量のツール一覧から選ぶのではなく、「注文を検索できるツール」という意図で検索し、該当ツールだけを取得して実行します。(Microsoft Learn)

従来の構成との違い

確認項目全ツールを直接公開する構成Tool Searchを有効にした構成
初期ツール一覧原則として全ツールを表示tool_search、call_tool、固定表示したツールのみ
ツール選択モデルが一覧から直接選ぶ意図を検索して候補を絞る
ツール数増加時定義が増え、コンテキストを圧迫しやすい必要な定義だけを取得できる
向いている環境ツールが少ない小規模エージェント10~15個以上のツールを持つ環境
管理方法エージェントごとの設定になりやすいToolboxで接続やバージョンを集中管理できる

Tool Searchは、ツールそのものを新しく作る機能ではありません。既存のツール群から、その場面に必要なものを見つけやすくするルーティング機能と考えると分かりやすいでしょう。

影響を受けるユーザーと管理者

影響が大きいのは、次のような環境です。

  • 多数のMCPサーバーや組み込みツールを1つのエージェントで利用している
  • 複数チームが共通のツールセットを使っている
  • ツール追加のたびにエージェントを修正、再デプロイしている
  • ツールの誤選択や入力トークンの増加が問題になっている
  • 認証情報や接続設定を管理者側で統一したい

Toolboxを利用していない既存エージェントに、今回の変更が自動適用されるわけではありません。各ツールをエージェントへ直接登録している場合は、Toolboxへの移行とエンドポイントの変更が必要です。

一方、すでにToolboxのコンシューマー用エンドポイントへ接続しているエージェントは、新しいToolboxバージョンを既定に昇格させることで、エージェントコードの変更や再デプロイなしに新構成を受け取れます。(Microsoft Learn)

Tool Searchを有効にする設定

既存のToolboxに次の設定を追加します。

{
  "tools": [
    {
      "type": "toolbox_search_preview"
    }
  ]
}

実際の構成では、この設定と同じToolboxバージョンに、検索対象となるMCPツールや組み込みツールも含めます。

Visual Studio CodeのFoundry Toolkitを使用する場合は、Toolboxの作成・編集画面で「Tool search」を選択して公開できます。Python、.NET、JavaScript SDK、REST API、Azure Developer CLIからの設定にも対応しています。(Microsoft Learn)

設定後に確認する手順

  1. 現在のToolboxを変更せず、新しいバージョンを作成する
  2. バージョン指定付きMCPエンドポイントへ接続する
  3. tools/listを実行する
  4. tool_searchとcall_toolが表示されることを確認する
  5. 実際の利用者が入力する言葉でツール検索をテストする
  6. ツールの実行、認証、承認処理まで確認する
  7. 問題がなければ新バージョンをdefault_versionへ昇格する

検証には、次のようなバージョン指定付きエンドポイントを使います。

{project_endpoint}/toolboxes/{toolbox_name}/versions/{version}/mcp?api-version=v1

本番相当のエージェントには、既定バージョンを返すコンシューマー用エンドポイントを設定します。

{project_endpoint}/toolboxes/{toolbox_name}/mcp?api-version=v1

Toolboxのバージョンは変更不可のスナップショットです。新しいバージョンを作成しても自動では既定にならないため、検証後に明示的な昇格が必要です。問題が発生した場合は、以前のバージョンを再び既定にしてロールバックできます。(Microsoft Learn)

既存環境からの移行方法

すでにToolboxを使っている場合

現在のバージョンを直接編集するのではなく、toolbox_search_previewを追加した新バージョンを作成します。

検証時は、代表的な質問だけでなく、次のケースも確認してください。

  • 同じ意味を異なる言葉で質問した場合
  • 複数のツールを順番に使う必要がある場合
  • 検索結果が0件になる場合
  • OAuth認証が必要なツールを初めて使う場合
  • 更新や削除など、利用者の承認が必要な操作

ツールをエージェントへ直接登録している場合

次の順序で移行すると、影響を切り分けやすくなります。

  1. 既存のツールと接続情報を一覧化する
  2. 同じ構成をToolboxへ登録する
  3. Tool Searchを使わない状態で動作確認する
  4. エージェントの接続先をToolboxのMCPエンドポイントへ変更する
  5. Tool Searchを追加した新バージョンを作成する
  6. 検証後に既定バージョンを切り替える

Toolboxへの移行とTool Searchの有効化を同時に行うと、不具合の原因が接続設定なのか検索精度なのか判断しにくくなります。段階的に変更するのが安全です。

検索精度を上げる設定

Tool Searchは、ツール名と説明文をもとに候補を探します。そのため、descriptionが空、または「データを取得します」のように曖昧だと、必要なツールが検索結果に出ない可能性があります。

説明文には、対象データと利用目的を含めましょう。

悪い例:
データを検索します。

良い例:
顧客IDまたはメールアドレスを使い、注文履歴、配送状況、
キャンセル状況を検索します。

社内用語とツール側の用語が異なる場合は、additional_search_textへ検索キーワードを追加できます。また、毎回使う重要ツールはpin: trueに設定すると、検索を行わなくても初期一覧へ表示できます。(Microsoft Learn)

設定時に注意したいポイント

症状主な原因確認内容
tool_searchが表示されない古いバージョンへ接続しているエンドポイントのバージョンと既定バージョンを確認する
検索結果が0件になるツールの説明が不足しているdescriptionとadditional_search_textを見直す
検索できるが実行に失敗する接続または認証設定の不備project_connection_id、権限、OAuth同意を確認する
MCPエンドポイントへの要求が失敗するプレビュー用ヘッダーがないFoundry-Features: Toolboxes=V1Previewを付ける
公開後に動作が急に変わった既定バージョンを切り替えた以前のバージョンを再度公開して切り戻す

ToolboxのMCPエンドポイントへの各要求には、次のヘッダーが必要です。付け忘れると呼び出しに失敗します。(Microsoft Learn)

Foundry-Features: Toolboxes=V1Preview

また、開発者、エージェントのマネージドID、OAuthを利用するエンドユーザーには、Foundryプロジェクト上の適切なRBAC権限が必要です。公式手順では、関連するIDへの「Foundry User」ロール付与が前提として案内されています。(Microsoft Learn)

require_approval: "always"を設定する場合も注意が必要です。この値はツール情報として返されますが、ToolboxのMCPエンドポイント自体が実行を停止するわけではありません。利用者への確認画面や実行ブロックは、エージェントランタイム側で実装する必要があります。(Microsoft Learn)

料金と期限で確認すべきこと

2026年6月16日時点の公式情報では、Tool Search単独の料金、一般提供開始日、強制移行期限、既存構成の廃止日は明示されていません。

ただし、無料と断定することもできません。Microsoft Foundry Agent Serviceでは、モデル推論と各ツールの利用に応じた料金が発生し、Hosted agentではコンテナコンピューティングの費用も加わります。接続先のMCPサーバーや外部サービスに、別途利用料金が発生する場合もあります。(Microsoft Learn)

Tool Searchは、Toolboxが大きくなっても全ツール定義を毎回モデルへ渡さないため、コンテキストに含まれるトークンの増加を抑えられます。一方で、ツール検索の処理が追加されるため、導入前後で次の項目を測定することが重要です。

  • 1リクエスト当たりの入力トークン数
  • ツール検索と実行を含めた応答時間
  • 誤ったツールを選択した割合
  • tool_searchが0件になった回数
  • 外部ツールやMCPサーバーの呼び出し回数

本機能はパブリックプレビューであり、SLAは提供されず、公式ドキュメントでも本番ワークロードでの利用は推奨されていません。まずは開発・検証環境で試し、既存バージョンへ戻せる状態を維持してください。(Microsoft Learn)

まず実施するべき確認

Toolbox内のツールが10個未満で、選択ミスやトークン増加が問題になっていない場合は、急いでTool Searchへ切り替える必要はありません。

一方、ツール数が10~15個を超えている場合は、代表的なツールの説明文を整えたうえで、新しいToolboxバージョンにTool Searchを追加してください。バージョン指定付きエンドポイントで検索精度、認証、承認処理を確認し、問題がなければ既定バージョンへ昇格します。

重要なのは、単に設定を有効にすることではありません。利用者が実際に使う表現で、必要なツールが安定して見つかるかを検証することが、今回の変更を有効活用するための判断基準です。

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次