Azure AI Foundry の「Azure AI Foundry Toolboxes generally available」は、AIエージェントが使うツール群を個別実装ではなく、Foundry 側の「Toolbox」として一元管理できるようになった重要な更新です。結論から言うと、すぐに全エージェントを書き換える必要がある変更ではありません。むしろ、MCP サーバー、REST API、スキル、コネクタなどを複数のエージェントで安全に再利用するための管理基盤が GA、つまり本番利用を検討しやすい段階に進んだと捉えるべきです。Microsoft の公式更新では、Toolboxes は 2026年6月の General Availability として扱われ、Microsoft Foundry の機能として掲載されています。(Microsoft)
この記事では、Azure AI Foundry Toolboxes generally available の更新ポイントを、影響範囲、設定変更、移行期限、管理者が確認すべき実務ポイントに分けて整理します。特に、既に Azure AI Foundry や Microsoft Foundry Agent Service でエージェントを構築している組織は、「ツール接続をコードに埋め込む設計」から「ツールを管理対象の共有アーティファクトとして扱う設計」へ移行するかを判断するタイミングです。(Microsoft Learn)
Azure AI Foundry Toolboxes generally available の要点
Azure AI Foundry Toolboxes generally available の中心は、エージェントが利用するツールを 1 つの管理単位にまとめ、MCP 互換エンドポイント経由で呼び出せるようにすることです。従来は、各エージェントチームが同じようなツール一覧、認証、接続処理を個別に組み込むケースが多く、認証情報の重複、ガバナンスのばらつき、利用状況の見えにくさが課題になりがちでした。Toolboxes は、その課題を Foundry 側の管理レイヤーで解決するための仕組みです。(Microsoft)
| 確認項目 | 内容 | 管理者の判断ポイント |
|---|---|---|
| 提供状態 | Toolboxes in Microsoft Foundry が GA として公開 | 本番採用候補に入れられるが、リージョン・モデル・ツール種別の確認は必要 |
| 主な目的 | ツール群を curated / governed bundle として一元管理 | 複数エージェントで同じツールを使う環境ほど効果が大きい |
| 呼び出し方式 | 単一の MCP 互換エンドポイントからツールを検出・実行 | エージェント側の個別連携コードを減らせる |
| 対象ツール | MCP、REST API、スキル、コネクタ、Web Search、Azure AI Search、Code Interpreter、File Search など | 使いたいツールが対象リージョン・対象モデルで利用可能かを確認 |
| 移行期限 | 公式更新では、既存方式の廃止日や強制移行期限は示されていない | 新規開発・改修案件から段階導入するのが現実的 |
| 注意点 | MCP エンドポイント呼び出し時のヘッダー、RBAC、バージョン管理、ネットワーク分離を確認 | GA でも設定確認なしに本番投入しない |
Toolboxes は何を解決する機能なのか
Toolboxes を使うと、エージェントが呼び出す外部ツールや社内ツールを、エージェントごとのコードではなく Foundry の管理対象として定義できます。たとえば、社内ナレッジ検索に Azure AI Search、最新情報取得に Web Search、業務 API 呼び出しに MCP サーバー、データ処理に Code Interpreter を使うエージェントを考えると、従来はエージェントごとに接続処理や認証処理を組み込む必要がありました。Toolbox では、これらを 1 つのツールセットとして作成し、エージェントはその MCP 互換エンドポイントに接続します。(Microsoft Learn)
実務上の価値は、「開発が楽になる」だけではありません。より重要なのは、ツール利用の権限、接続先、バージョン、ガードレールを管理側で揃えられることです。Microsoft Learn では、Toolbox が認証情報の注入、トークン更新、エンタープライズポリシーの適用をランタイムで扱うと説明されています。これは、AI エージェントの増加に伴うシャドー連携や認証情報の散在を抑えるうえで大きな意味があります。(Microsoft Learn)
GA 化で何が変わるのか
本番利用の検討対象になった
GA は、機能が正式提供段階に入ったことを示します。Azure Updates では Toolboxes in Microsoft Foundry が Launched、General Availability として扱われており、Microsoft Foundry の AI + machine learning カテゴリに分類されています。(Microsoft)
ただし、GA だからといって全リージョン・全モデル・全ツール種別で同じように使えるわけではありません。Microsoft Learn では、Toolbox の利用可否はプロジェクトのリージョンだけでなく、個別のツール種別やモデルにも左右されると説明されています。グローバル展開では、米国、欧州、日本、アジアなど拠点ごとに同じ構成が再現できるかを事前に確認する必要があります。(Microsoft Learn)
エージェント側のコード変更を減らせる
Toolbox は管理対象リソースとして扱われるため、ツールの追加、削除、再設定をエージェントのコード変更なしに進めやすくなります。エージェントは単一のエンドポイントに接続し、Toolbox 側で新しいバージョンを作成してテストし、準備ができたら既定バージョンに昇格できます。Microsoft Learn では、既定バージョンに向いているエージェントは、昇格後のバージョンをコード変更や再デプロイなしに利用できると説明されています。(Microsoft Learn)
これは、AI エージェントを運用する組織にとって非常に実務的です。たとえば「営業支援エージェント」「社内ヘルプデスクエージェント」「ナレッジ検索エージェント」が同じ Azure AI Search や社内 MCP サーバーを使う場合、各エージェントに修正を入れるのではなく、Toolbox の新バージョンを検証してから段階的に既定化できます。
ツールのガバナンスを集約できる
Toolboxes は、単なるツール一覧ではなく、ガバナンス対象の束として設計されています。公式更新では、Toolboxes は MCP サーバー、REST API、スキル、コネクタなど、異なるプロトコルや認証モデルを持つツールを、単一の MCP 互換エンドポイントで公開すると説明されています。これにより、開発者はツールごとの連携コードを書く負担を減らし、管理者はエージェントが呼び出せるツールを一貫して管理しやすくなります。(Microsoft)
影響範囲：誰が何を確認すべきか
Azure AI Foundry Toolboxes generally available の影響は、開発者だけでなく、Azure 管理者、セキュリティ担当、ネットワーク担当、アプリケーションオーナーにも及びます。特に本番エージェントで外部 API や社内データを呼び出している場合は、ツール接続の責任分界点を明確にしておく必要があります。
| 役割 | 影響 | 確認すべきこと |
|---|---|---|
| Azure / Foundry 管理者 | Toolboxes の作成、権限、プロジェクト設定に関与 | Foundry project、RBAC、リージョン、モデル対応状況 |
| エージェント開発者 | ツール連携コードの持ち方が変わる | MCP エンドポイント、ツール名、引数、検証手順 |
| セキュリティ担当 | 外部ツール利用時のデータ送信や認証管理に関与 | 非 Foundry ツール利用時のデータ境界、認証情報、ログ |
| ネットワーク担当 | Private Link / VNet 分離環境での通信経路に関与 | ツール種別ごとの VNet 対応状況 |
| アプリケーションオーナー | 既定バージョン昇格時の業務影響を受ける | テスト、ロールバック、変更承認、監視 |
Microsoft Learn では、非 Foundry ツールに接続する場合、コストが発生したり、データが Foundry のコンプライアンス境界外に送信されたりする可能性があると警告しています。外部 MCP サーバー、REST API、Web Search などを使う場合は、技術的に接続できるかだけでなく、データ取り扱い条件と利用料金も確認してください。(Microsoft Learn)
設定変更で確認すべきポイント
RBAC は利用者ごとに分けて確認する
Toolbox を利用するには、Foundry プロジェクトが必要です。Microsoft Learn では、Toolbox を作成・管理する開発者、Hosted agent からツールを呼び出すエージェント ID、OAuth フローで必要になるエンドユーザーに対して、シナリオに応じた Foundry User ロールを付与するよう説明されています。(Microsoft Learn)
実務では、少なくとも次の 3 種類を分けて棚卸しします。
| ID の種類 | 用途 | よくある確認漏れ |
|---|---|---|
| 開発者 ID | Toolbox の作成、更新、バージョン管理 | 検証環境だけ権限があり、本番プロジェクトに権限がない |
| エージェントのマネージド ID | Hosted agent からツールを実行 | ツール接続先への権限が不足して実行時に失敗する |
| エンドユーザー ID | OAuth やユーザー委任が必要なツール呼び出し | 管理者の検証では動くが、一般ユーザーで同意や権限エラーになる |
MCP エンドポイントのヘッダーを忘れない
現時点の公式ドキュメントでは、Toolbox の MCP エンドポイントを呼び出すすべてのリクエストに Foundry-Features: Toolboxes=V1Preview ヘッダーが必要で、ヘッダーがない呼び出しは失敗すると説明されています。GA 化されたからといって、このヘッダー要件を不要と判断しないでください。(Microsoft Learn)
この点は移行時の落とし穴になりやすい部分です。自作 MCP クライアント、SDK ラッパー、HTTP クライアント、CI/CD の疎通テスト、エージェントのランタイム設定のすべてで、同じヘッダーが付与されているかを確認しましょう。
ツール名と description を軽視しない
Toolbox では、同じ種類のツールを複数含める場合、各ツールを識別できるように一意の name を設定する必要があります。公式ドキュメントでは、Web Search、Azure AI Search、Code Interpreter、File Search などで同じツール種別の unnamed インスタンスを複数含めると invalid_payload エラーになると説明されています。また、モデルが適切なツールを選べるよう、各ツールに description を追加することも推奨されています。(Microsoft Learn)
たとえば Azure AI Search を「製品カタログ検索」と「社内規程検索」の 2 系統で使う場合、どちらも単に search とするのではなく、product-search、policy-search のように用途が分かる名前にします。description には「製品仕様・価格表を検索する」「社内規程・申請手順を検索する」のように、エージェントが判断しやすい説明を入れるのが実務的です。
エンドポイントは開発者用と利用者用を使い分ける
Toolbox には、特定バージョンを検証するためのエンドポイントと、既定バージョンを提供する利用者向けエンドポイントがあります。Microsoft Learn では、開発者はバージョン指定のエンドポイントを使って検証し、エージェントは default_version を返す consumer endpoint に接続する考え方が示されています。(Microsoft Learn)
本番エージェントにバージョン指定エンドポイントを直接埋め込むと、後から既定バージョンを昇格しても反映されない運用になりがちです。原則として、本番エージェントは consumer endpoint を使い、検証・承認・リリース判定では version-specific endpoint を使う、という運用ルールを決めておきましょう。
移行期限はあるのか
今回の公式更新は Toolboxes の GA 化を知らせるものであり、確認できる範囲では既存のツール接続方式に対する廃止日や強制移行期限は示されていません。したがって、既存エージェントを即時移行するというより、共通化の効果が高いツールから段階的に採用するのが安全です。(Microsoft)
おすすめの移行方針は、次の順番です。
| フェーズ | 作業 | 完了条件 |
|---|---|---|
| 棚卸し | 既存エージェントが使う MCP、REST API、Azure AI Search、Web Search、File Search、Code Interpreter を一覧化 | ツール名、認証方式、利用エージェント、データ種別が分かる |
| 候補選定 | 複数エージェントで使うツール、認証情報が重複しているツールを優先 | Toolbox 化する対象と見送る対象が決まる |
| 検証 | 開発環境で Toolbox を作成し、version-specific endpoint で tools/list と tools/call を確認 | 期待するツールが表示され、代表的な呼び出しが成功する |
| 本番準備 | RBAC、ネットワーク、Guardrails、ログ、コスト、データ境界を確認 | 管理者・セキュリティ担当・アプリ責任者の承認が取れる |
| 昇格 | 検証済みバージョンを default_version に昇格 | 本番エージェントが consumer endpoint 経由で正常に利用できる |
バージョン管理とロールバックの考え方
Toolbox のバージョンは、ツール構成の immutable snapshot として扱われます。新しいバージョンを作成しても自動的には本番向けの default_version にならず、管理者が明示的に昇格する必要があります。Azure Developer CLI では、publish が default_version を変更する経路として説明されています。(Microsoft Learn)
この仕様は、変更管理の観点ではメリットです。たとえば、MCP サーバーの認証方式を変更する、Azure AI Search のインデックスを差し替える、Web Search を追加する、といった変更を v2 として作成し、検証後に既定バージョンへ昇格できます。問題が起きた場合は、既存の安定バージョンへ戻す運用も組みやすくなります。
ネットワーク分離環境での注意点
Private Link や VNet 分離を使っている Foundry プロジェクトでは、ツール種別ごとの対応状況を必ず確認してください。Microsoft Learn の表では、MCP、Azure AI Search、Code Interpreter、Web Search、OpenAPI、Agent-to-Agent は VNet サポートありとされています。一方、File Search、Fabric IQ、Work IQ、Browser Automation はネットワーク分離環境では未対応とされています。(Microsoft Learn)
| ツール種別 | VNet 分離環境での確認ポイント |
|---|---|
| MCP | VNet サブネット経由で通信する前提で到達性を確認 |
| Azure AI Search | Private Endpoint と検索サービス側の権限を確認 |
| Code Interpreter | Microsoft backbone network 経由の扱いを社内ポリシーと照合 |
| Web Search | Public endpoint 利用になるため、データ送信・コスト・利用可否を確認 |
| OpenAPI | 呼び出し先 API のネットワーク構成に依存 |
| File Search | ネットワーク分離環境では未対応のため代替案を検討 |
| Fabric IQ / Work IQ / Browser Automation | ネットワーク分離環境では未対応のため本番要件と照合 |
グローバル展開では、ネットワーク分離だけでなく、リージョンとモデルの対応状況も組み合わせて確認します。Microsoft Learn では、ツール利用にはリージョンとモデルの両方の対応が必要で、片方が対応していない場合は実行できないと説明されています。(Microsoft Learn)
セキュリティとデータ保護で見落としやすい点
Toolboxes はガバナンスを強化する仕組みですが、設定すれば自動的にすべてのリスクが消えるわけではありません。特に、外部 API、サードパーティ MCP サーバー、Web Search、Bing を使う構成では、入力データがどこに送信され、どの条件で処理されるかを確認する必要があります。Microsoft Learn では、非 Foundry ツール接続時にコストやデータ境界外処理が発生する可能性があると明記されています。(Microsoft Learn)
また、Code Interpreter と File Search を Toolbox 経由で Hosted agent から使う場合のユーザー分離にも注意が必要です。公式ドキュメントでは、Code Interpreter は同一プロジェクト内の全ユーザーで同じコンテナコンテキストを共有し、File Search も同一プロジェクト内の全ユーザーが同じ vector store にアクセスする形になると説明されています。機密データや部門別データを扱う場合は、プロジェクト分離、データ分離、アクセス制御を設計段階で確認してください。(Microsoft Learn)
管理者が確認すべきチェックリスト
Azure AI Foundry Toolboxes generally available を受けて、管理者は次の項目を順に確認すると抜け漏れを減らせます。
| チェック項目 | 確認内容 |
|---|---|
| 対象エージェント | Toolboxes の対象にするエージェントと、当面は個別実装のままにするエージェントを分ける |
| ツール棚卸し | MCP、REST API、Azure AI Search、Web Search、Code Interpreter、File Search、スキル、コネクタを一覧化する |
| RBAC | 開発者、エージェント ID、エンドユーザーの権限をシナリオ別に確認する |
| エンドポイント | 本番エージェントは consumer endpoint、検証は version-specific endpoint を使う |
| ヘッダー | MCP 呼び出しに Foundry-Features: Toolboxes=V1Preview が付与されているか確認する |
| ツール名 | 同種ツールを複数入れる場合は一意の name を設定する |
| description | モデルが選択しやすい具体的な説明を各ツールに付ける |
| バージョン管理 | 新バージョン作成、検証、default_version 昇格、ロールバック手順を決める |
| Guardrails | 必要に応じて policies.rai_config.rai_policy_name で RAI policy を適用する |
| ネットワーク | VNet 分離環境で使えないツール種別が含まれていないか確認する |
| データ保護 | 外部ツールや Web Search 利用時のデータ送信先、契約条件、ログを確認する |
| コスト | Web Search や外部サービス呼び出しの課金影響を見積もる |
Guardrails については、Toolbox バージョンに名前付きポリシーを適用し、ツール入力と出力に対して責任ある AI のフィルタリングをかけられると説明されています。モデル側のコンテンツフィルターとは独立した Toolbox レイヤーの制御として扱えるため、管理者は本番投入前にどの Toolbox にどのポリシーを適用するかを決めておくべきです。(Microsoft Learn)
Toolboxes を使うべきケース、まだ使わなくてもよいケース
Toolboxes は強力ですが、すべての小規模エージェントに必ず導入すべきというわけではありません。判断基準は、「そのツール連携を組織として再利用・管理する価値があるか」です。
| 判断 | 向いているケース | 理由 |
|---|---|---|
| Toolboxes を使う | 複数エージェントで同じ検索基盤や API を使う | ツール定義、認証、バージョン管理を共通化できる |
| Toolboxes を使う | セキュリティレビューや変更承認が必要な業務ツールを呼び出す | 管理対象として承認・監査しやすい |
| Toolboxes を使う | MCP サーバー、REST API、スキル、コネクタが混在している | エージェント側は単一の MCP 互換エンドポイントを見ればよい |
| まずは個別実装でもよい | 1 つの PoC エージェントだけで短期間使う | 管理レイヤーを増やすより検証速度を優先できる |
| まずは個別実装でもよい | ツール接続が 1 つだけで、認証や変更頻度も低い | Toolbox 化の運用コストが効果を上回る可能性がある |
| 要検討 | 機密データを Code Interpreter や File Search で扱う | 同一プロジェクト内の共有挙動やデータ分離設計を確認する必要がある |
よくある失敗と回避策
GA だから設定が簡単になったと考えてしまう
GA は本番利用を検討しやすくなるサインですが、設定確認が不要になるという意味ではありません。RBAC、リージョン、モデル、ネットワーク分離、ヘッダー、ツール名、Guardrails は、GA 後も個別に確認が必要です。
本番エージェントに検証用エンドポイントを埋め込む
検証時に version-specific endpoint を使うのは正しい運用です。しかし、それをそのまま本番エージェントに固定すると、後から default_version を昇格しても反映されません。本番は consumer endpoint、検証は version-specific endpoint という使い分けをルール化しましょう。(Microsoft Learn)
Toolbox の YAML や設定に認証情報を直接書く
公式ドキュメントの Azure Developer CLI 例では、Toolbox YAML は既存の connection 名を参照し、認証情報そのものを埋め込まない形が示されています。実務でも、キーやトークンを YAML、プロンプト、ログに残さない設計を徹底してください。(Microsoft Learn)
ツールの description が曖昧で誤呼び出しが起きる
「search」「api」「tool」のような説明では、モデルが適切なツールを選びにくくなります。「社内 FAQ を検索する」「製品マスターを検索する」「顧客 ID から契約状況を取得する」のように、入力、対象データ、使うタイミングが分かる説明にします。Microsoft Learn でも、モデルが正しいツールを選べるよう、各ツールに description を追加することが推奨されています。(Microsoft Learn)
次に取るべき行動
まずは、既存エージェントが呼び出しているツールを棚卸しし、複数エージェントで重複しているものを 1 つ選びます。次に、開発環境で小さな Toolbox を作成し、version-specific endpoint で tools/list と tools/call を確認します。期待どおりに動いたら、RBAC、ネットワーク、データ保護、Guardrails、コストを確認し、consumer endpoint に接続する形で段階的に本番適用します。(Microsoft Learn)
Azure AI Foundry Toolboxes generally available の本質は、新機能を試すことではなく、AI エージェントのツール利用を組織として管理できる形に変えることです。新規エージェントの開発標準に Toolboxes を組み込み、既存エージェントは共通ツールから順に移行する。これが、今回の GA 更新を実務に落とし込む最も安全で効果的な進め方です。
コメント