SE の雑記

SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿

2026/03/26 時点の Agent 365 の エージェント ID についてメモ

leave a comment

2026/03/26 時点の Agent 365 (A365) の エージェント ID についてのメモです。

先日開催された Microsoft AI Tour in Tokyo で調査した内容も含め、自分の中で情報を整理しておこうかと。

2026/05/01 に Agent 365 が GA (一般提供開始) するため、GA 後は状況は変わっている可能性が高いです。

Ignite 2025 で発表された内容と現時点で利用できる機能のギャップの把握

Ignite 2025 のアナウンスの内容

Agent 365 は、Ignite 2025 でアナウンスされました。この際のアナウンスでは次のような特徴が挙げられていたのではないでしょうか？

  • エージェントに個別の ID が割り当てられる
    • エージェント ID / エージェントブループリント
  • エージェントが個別のユーザーとして振る舞うことができる
    • エージェントユーザー / エージェントインスタンス
  • エージェントレジストリ / ストアで一元的にエージェントを管理
  • エージェントコレクションによるエージェントの整理とエージェント間の連携の管理
  • 条件付きアクセスポリシー / GSA をエージェントに対しても適用することができる
  • Defender / Purview によるエージェントの保護
  • シャドウエージェントの管理
  • 乱立したエージェントの一元的な管理

 

Ignite 2025 のアナウンスと現状のギャップ

最終的にはこれらの機能は実装されると思いますが、現時点では

  • すべてのエージェントがこれらの機能を使用することはできない
  • 現時点では、通常のプレビューでは使用することができない

機能があるのが現状だと思います。

私は次のエージェントの作成方法で Agent 365 の エージェント ID を調査しています。

  1. Copilot Studio で作成した宣言型エージェント
    • 環境に対して Frontier プログラムを有効にしており、エージェントを作成するとエージェント ID が付与される。
  2. Agent Builder で作成した宣言型エージェント
  3. Microsoft Foundry で作成した宣言型エージェント
    • プレイグラウンドを使用したプロトタイプ作成
  4. Agent 365 SDK のクイックスタートで作成したカスタムエンジンエージェント

 

現時点でこのような方法でエージェントを作成した場合、Ignite の発表だけでエージェント ID を理解しようとすると、これらの 4 パターンでエージェント ID が付与されるというイメージがあるかもしれません。

しかし、現状上述のパターンでは「2.」の Agent Builder で作成したエージェントについては、エージェント ID は付与されません。

Ignite の発表で「すべてのエージェントに、エージェント ID が付与されることで乱立したエージェントが一元的に管理される」というようなイメージを持っていると、現時点の実装ではそこまでは至っていないということが分かります。

また、エージェントで条件付きアクセスポリシーが使用できるようになったことで「Copilot Studio で作成したエージェントに対して条件付きアクセスポリシーを設定して管理」することを期待することもあるのではないでしょうか。

しかし、Microsoft Entra Agent ID プレビュー:既知の問題とギャップ には次の記載があります。

Copilot Studioで作成されたエージェントは、エージェントの環境設定でエージェントIDにオプトインする必要があります。 現時点ではカスタムエンジンエージェントのみがサポートされています。 カスタムエンジンエージェントは現在、公開されるチャネルへの認証にエージェントIDを使用しています。 現在、Copilot Studioではコネクタやツールの認証にはエージェントIDが使われていません。

エージェントに対しての条件付きアクセスポリシーは、エージェント ID がリソース / エージェントアクセスのためのトークンを取得しようとした際の制御となります。

Copilot Studio のコネクタやツール (MCP) の認証では、エージェント ID は使われておらず、基本の設定では、ユーザーの情報を使用してアクセスが行われるかと思います。

このような「エージェント ID が使用されていないアクセス」では、条件付きアクセスポリシーが適用されないため、「Copilot Studio で作成したエージェントでは条件付きアクセスポリシーの評価が困難である」というような状態になります。

このような「Ignite のアナウンスだけで期待した内容と、実際に使用できる機能のギャップ」は評価を進めるといくつか出てきます。

重要なのは「自分が管理対象とする必要がある機能で Agent 365 によりエージェントをどのように管理することができるのか」ということではないでしょうか。

Copilot Studio で作成した宣言型エージェントをターゲットとした場合、エージェント ID の割り当ては行われます。

しかし、「エージェント ID を使用して制御できる各種機能がフルに活用できるか？」というと、使用するエージェントのパターンによっては期待した機能が使用できないこともあります。

「ユーザーが SDK を使用して開発したカスタムエンジンエージェント」であれば、Agent 365 の各種機能をフルに活用することができそうですが、それ以外の方法で作成したエージェントについては、どこまで機能が使用できるかは、注意が必要ではないでしょうか。

 

エージェントの保護

私が現在調査しているのは「エージェントの管理」の部分であるため、セキュリティに関しては、条件付きアクセスポリシーしか見れていないのですが、エージェントの保護については次のようなドキュメントが公開されています。

Agent 365 でエージェントの保護を期待する場合、これらのドキュメントの確認が必要となります。

 

エージェント ID を使用したアクセスの検証

エージェント ID からのトークンの取得を意識する

Agent 365 の エージェント ID の条件付きアクセスポリシー などの機能を検証するためには、「エージェント ID からトークンの取得」が行われる操作が必要となります。

現時点の Copilot Studio のみで作成したエージェントでは、エージェント ID を使用した通信を確認することができず、エージェント ID からの通信が必要となる機能の検証を行うことができませんでした。

自分が使用するエージェントの処理の認証では「どのようなサインインにより外部リソースへのアクセスが行われているか」を意識することが重要だと思います。

「エージェント ID を無効にする」というような操作についてもトークン取得の理解が必要となります。

「エージェントを無効にする」は使用するエージェントの利用を制限する操作となります。

「エージェント ID を無効にする」は、エージェントからトークンの取得を制限するという操作となり、Copilot Studio で作成したエージェントのエージェント ID を無効にしても、エージェントの利用は継続できます。

これは、Copilot Studio で作成したエージェントの基本的な操作では、エージェント ID によるトークン取得が行われていないためです。

「エージェントを無効にする」と「エージェント ID を無効にする」の違いも意識するとよいのではないでしょうか。

 

エージェントの認証パターン

エージェントからの認証には、エージェンティック認証 / OBO 認証 / ベアラートークン認証のようにいくつかのパターンがあります。

自分が使用するエージェントがどの認証パターンで動作するものなのかを意識しておくことは重要ではないでしょうか。

 

エージェント ID を使用した検証で参考になる情報

「エージェント ID からの通信」ですが、検証をするための環境の整備の難易度が低いのは「Microsoft Foundry でツール呼び出しでエージェント ID を使用する」方法のように感じました。

Microsoft Foundry のエージェント ID の概念 には次の記載があります。

現在、エージェント ID での認証をサポートするツールは次のとおりです。

その他のツールと統合では、異なる認証方法 (キーベースの認証や OAuth ID パススルーなど) を使用する場合があります。 サポートされている認証を確認するには、ツールのドキュメントを使用します。

Microsoft Foundry でエージェントを作成し、ツール (MCP) に接続する際には、「エージェント ID」を使用して MCP Server にアクセスすることができます。

image

エージェント ID のトークンの流れについては、Microsoft エージェント ID プラットフォームのトークン から確認することができ、エージェント ID の基本動作として確認したいフローが 自律アプリフロー です。

エージェントの自律アプリ トークン取得フローの図を示す図。

 

上記の設定で MCP を呼び出した場合、自律アプリフローが行われます。

MCP には、エージェント ID のアクセストークンが「authorization:Bearer」として、MCP が受け取っていますので、このトークンを使用して、リソースにアクセスをすることで、エージェント ID のトークンを使用して各種リソースにアクセスすることができます。

「ドキュメントベースではないエージェント ID からのトークン取得の挙動」については、Microsoft Foundry の Entra エージェント ID を使用して MCP 認証を行う検証 がとても参考になりました。

自身の学習のため、次の構成で Microsoft Foundry 作成したエージェントから MCP を呼び出していたのですが、エージェント ID を使用した条件付きアクセスポリシーの検証まで動作させることができました。

  • MCP サーバーは GitHub Copilot CLI を使用して FastMCP で独自に実装
    • MCP サーバーではユーザーの一覧 / リソースグループの一覧を取得するツール実装
    • MCP サーバーから Azure の API 呼び出しは、MCP サーバー呼び出し時に指定されたエージェント ID のベアラートークンを使用
    • Microsoft Graph / Azure Resource Manager の操作の認可はエージェント ID に対して付与
  • MCP サーバーはローカルで実行して Dev Tunnel 経由 で Foundry のエージェントからアクセス

 

Copilot Studio で作成したエージェントで個人的に注視しておきたいドキュメント

現状、Copilot Studio で作成したエージェントで個人的に注視しておきたいのが次のドキュメントとなります。

これらのドキュメントでは Copilot Studoi で使用可能な認証方式について記載されていますが、現時点では Foundry で作成するエージェントとは異なり「エージェント ID を使用した認証」については、サポートがされていません。

Copilot Studio のみで作成したエージェントでエージェント ID の操作がサポートされるようになると、これらのドキュメントにも更新がかかるとおもいますので、情報はウォッチしたいと思っています。

 

2026/05/01 になったら確認したいライセンスの内容について

現在公開されているライセンスの情報について

2026/05/01 になるとライセンスについても情報が公開されると思いますが、現時点では次の情報でライセンスについて公開されています。

現時点で気になる情報は FQA の次の内容です。

フロンティア プログラムでは、Microsoft Agent 365 ライセンスを使用すると、拡張された AI エージェントを Microsoft 365 テナントで実行できます。 ライセンスはエージェント インスタンスごとに割り当てられ、エージェント インスタンスを作成する前に必要です。
一般提供のため、エージェント 365 はユーザーごとにライセンスが付与されます。 ライセンスされたユーザーの代理として動作するすべてのエージェント (OBO) は、そのユーザーのエージェント 365 または Microsoft 365 E7 ライセンスの対象となります。 エージェントは、独自のエージェント 365 または Microsoft 365 E7 ライセンスを必要としません。

 

ライセンスの情報が公開された際に確認をしておきたい内容

前述したとおり、エージェントはいくつかの方法で作成されますが、作成方法によってエージェントの動作が異なります。

私が範囲としている方法で、エージェント ID が付与されるものとしては次のようなパターンがあり、現時点ではこのような動作となっているのではないでしょうか。

  1. Copilot Studio で作成した宣言型エージェント (環境に対して Frontier プログラムを有効にしている)
    • 作成したエージェントにエージェント ID は付与される
    • 基本的な資格情報はエージェントを使用するユーザー自身の情報が使用される。
  2. Microsoft Foundry で作成した宣言型エージェント
    • 作成したエージェントにエージェント ID が付与される。
    • ツール呼び出し等でエージェント ID を使用できる (使用しないこともできる)
  3. Agent 365 SDK のクイックスタートで作成したカスタムエンジンエージェント
    • エージェント インスタンスを作成する際に、エージェントユーザーが作成される。
    • エージェントユーザーに対してライセンスが付与される (現時点では Frontier ライセンスが付与される)

それぞれのパターンについて Agent 365 のライセンスがどのように必要となってくるのかは確認が必要だと感じています。

OBO の場合は、代理として動作するユーザーに Agent 365 のライセンスの付与が必要となると捉えられる記載が、現在の FAQ にありますが、エージェントの動作パターンは OBO だけではありません。

エージェント ID としてアクセスを行うものもあれば、エージェントユーザーとしてアクセスを行うこともあります。

想定されるエージェントの動作パターンに応じて必要となるライセンスの確認が必要となるかと。

Share

Written by Masayuki.Ozawa

3月 26th, 2026 at 9:41 am

Posted in Agent 365,Agent ID

Tagged with ,

«
»

Leave a Reply