Microsoft、AIエージェントのユーザー権限管理を簡素化する「Toolbox」を発表
要点
- Microsoftは、AIエージェントがユーザーの代理として安全に動作するための新機能「Toolbox」を「Foundry」向けに発表した。
- ユーザーに代わってアクションを実行する「ユーザー委譲」において、トークンの管理や認証同意、リトライ処理などをFoundry側で自動化する。
- エージェントのコードから複雑な認証ロジックを分離でき、単一の通信エンドポイントを指定するだけで複数の外部ツールと連携可能になる。
- ユーザー個人の権限だけでなく、エージェント自身の識別情報やプロジェクトの管理IDなど、用途に応じた多彩な認証方式に対応する。
リード文
MicrosoftのLinda Li氏とMaria Naggaga氏は2026年7月22日、同社の「Foundry Blog」において、開発するAIエージェントがユーザーに代わって外部ツールやシステムを安全に操作できるようにする新機能「Toolbox（ツールボックス）」を発表した。本機能は、これまでエージェント開発において複雑で実装負荷の高かった、サインインしたユーザーの権限に基づいて動作を制御する「ユーザー委譲（User Delegation）」の仕組みを大幅に簡素化するものであるという。
本文
エージェントの「アクション実行」における認証の難しさ
AIエージェントの役割が、単純な質問への回答から「ユーザーに代わって具体的なアクションを実行する」ことへとシフトするにつれ、エージェントが「誰の権限（アイデンティティ）で動作しているか」という点が重要な課題となってきている。
例えば、企業内で従業員向けに動作する社内用アシスタントエージェントを構築するケースを想定する。このエージェントが、ID管理サービス「Microsoft Entra（クラウドアドレスに基づくID・アクセス管理サービス）」で保護されたプライベートな注文管理用の「MCP（Model Context Protocol）サーバー」（AIモデルと外部のデータやツールを接続するためのオープンな通信規格）から情報を取得し、同時に、従業員個人のメールやチャット、カレンダーの予定などを安全に参照できる管理サービス「Work IQ MCPサーバー」を利用する場合を考える。
このとき、エージェントはシステム共通の管理アカウント（サービスアカウント）で動くべきではない。操作している従業員本人の権限とアクセス範囲、そして企業のデータ保護規則を厳密に維持したまま動作する「ユーザー委譲」が求められるからだ。
しかし、このようなユーザー委譲の仕組みを開発者がゼロから実装しようとすると、以下のような大きな障壁が存在していた。
- トークン分離の複雑さと漏洩リスク
システム側でユーザーやテナント（組織単位の契約領域）ごとに「トークン（一時的なアクセス許可証）」のキャッシュを厳密に分離しなければならない。もしキャッシュを識別するキーの設定に不備があると、あるユーザーの権限で取得したトークンが別のユーザーに漏えいし、第三者のデータにアクセスできてしまうという致命的なセキュリティ問題に直面する。 - 認証同意や更新にかかる実装コスト
ユーザーが初めてツールを使う際のアクセス同意画面の制御や、有効期限が切れたトークンの自動更新、通信エラー発生時の再試行（リトライ）処理などを、開発者がエージェントのコードごとに自前で実装する必要がある。 - 機能拡張に伴う開発の重複
新しいツールをエージェントに追加するたびに、新たな権限スコープの定義やトークン交換、ヘッダー情報の処理などを追加しなければならず、ツールやエージェントが増えるにつれてシステムの保守が極めて困難になる。
「Toolbox」が提供する解決アプローチ
今回発表された「Toolbox」は、これらの煩雑な「認証と認可」にかかわる処理をエージェントのコードから完全に排除し、Foundryのプラットフォーム側（サーバー側）に任せることで、この問題を解決するアプローチを採る。
開発者は、ツールを接続する際に認証方式を1回指定するだけでよく、エージェントのプログラムコード内に認証ロジックを書き込む必要は一切なくなるという。トークンの取得、交換、更新、さらにユーザーに対する同意画面の提示といった一連のライフサイクルは、すべてFoundryがサーバー側で肩代わりして処理する。
このアプローチにより、開発者はビジネスロジック（エージェントの機能そのもの）の開発に集中できるようになるとしている。
Toolboxの実実装と連携の流れ
Toolboxを利用した開発の流れは、以下の3つのステップで構成されている。
- 接続と認証の設定（ステップ1）
管理ポータルや、クラウド開発向けコマンドラインツール「azd（Azure Developer CLI）」、またはREST APIを使用して、利用するツールとの接続を作成し、OAuth2などの認証タイプを設定する。このとき、シークレットキーやアクセス許可の範囲（スコープ）なども定義するが、これらはエージェントのコードには一切記述しない。 - Toolboxの構築（ステップ2）
プロジェクト内で「employee-toolbox」のような名前のToolboxのバージョンを作成し、使用したい複数のツール（注文データにアクセスする「orders」や、Microsoft 365のデータを参照する「work_iq」など）をリストアップして登録する。 - エージェントからの呼び出し（ステップ3）
エージェントは、Foundryが用意するToolboxのMCPエンドポイント（通信の接続先）URLを、単一のツールとして指定するだけで動作する。
ユーザーがエージェントに指示を出すと、Foundryは裏側で登録されたそれぞれのツールに対し、指示を出したユーザー本人の代理として自動的にアクセスを切り替え、安全に情報を取得・統合した上でユーザーに回答を返す。将来的に別のツールを追加したくなった場合も、接続設定を作成してToolboxの登録リストに1行追加するだけで対応でき、エージェント自体のコードを変更する必要はないという。
用途に応じた包括的な認証方式のサポート
Toolboxは、ユーザーの権限を代行する「oauth2」以外にも、以下のような多彩な認証タイプを包括的にサポートしており、開発者は用途に合わせて選択できる。
- agentic-identity（エージェントアイデンティティ）：エージェント自身に個別の識別情報を持たせ、サービス間の通信においてエージェント単位で操作の監査ログを残したい場合に適している。
- project-managed-identity（プロジェクトマネージドアイデンティティ）：Azureリソース間で自動的に認証を行う「マネージドアイデンティティ」をプロジェクト単位で利用する。個人のユーザー権限が不要なシステム間の連携に用いる。
- custom-keys（カスタムキー）：APIキーやカスタムヘッダーを利用して外部のSaaS（クラウドサービス）に接続する。キー情報は安全に保管され、エージェントのプログラム自身がそのシークレットを見ることはない。
- none（なし）：公開されているパブリックな情報サーバーなど、認証を必要としないオープンなサービスに匿名でアクセスする際に使用する。
さらに、Toolbox内のすべてのツールは、Foundryが提供するセキュリティ管理機能（ガードレールやゲートウェイ）によってデフォルトで統制されるため、企業向けの安全な運用を容易に実現できると説明している。