昨日、Agent 365 の一般提供開始タイミングのアナウンスが次の記事でありました。
- Powering Frontier Transformation with Copilot and agents
- Secure agentic AI for your Frontier Transformation
Agent 365 は、2026/05/01 に一般提供が開始されることがアナウンスされています。
Agent 365 will be generally available on May 1, 2026, and priced at $15 per user per month. Learn more about Agent 365.
Agent 365 の一般提供が開始されると、様々な情報が公開されると思いますが、提供開始時に確認をしておきたい内容についてメモを残しておきたいと思います。
ライセンスについて
Powering Frontier Transformation with Copilot and agents ではライセンスについて触れられています。
新しく、Microsoft Agent 365 / Microsoft 365 E7 のライセンスが提供されることががアナウンスされており、「Agent Management」に関しての機能は、これらのライセンスが必要になると記載されています。
現状、Agent 365 ライセンスについては、エージェント 365 登録に関する FAQ に記載されています。
「ライセンスはエージェント インスタンスごとに割り当てられ、エージェント インスタンスを作成する前に必要です。」という記載があり、現在のプレビューでもライセンスについて標準的な操作で表示がされるのは、Agent 365 でエージェントを公開するタイミング になるかと思います。
上述の FAQ の記載では「エージェントインスタンスごとに割り当てられ」という記載があります。
Agent 365 ではエージェントインスタンスという構成要素があります。
Agent 365 のライセンスが必要となるのは、このエージェントインスタンスの作成を伴うエージェントを追加する場合なのかが気になるところです。
現在、エージェントの種類にはいくつかあるかと思います。
- 宣言型エージェント
- 自律型エージェント
- カスタムエンジンエージェント
この中で、Agent 365 のライセンスが必要となるのが「どのようなツールで作成した、どのような種類で作成したエージェント」なのかは確認が必要ではないでしょうか？
今気になっているのは、次のケースで必要となるライセンスです。
- Copilot Studio で宣言型エージェントで、エージェント ID を付与したエージェントを作成する場合にライセンスは必要なのか？
- Agent 365 CLI で公開 (Publish) する際に、処理を実行するユーザーにライセンスが必要となるのか？
- Agent 365 CLI で公開したエージェントで、ライセンス認証処理をするときにライセンスが必要となるのか？
- Agenr 365 CLI で公開したエージェントで、ユーザーがインスタンスを作成するときにライセンスが必要となるのか？
また、Agent 365 にはエージェントユーザーという構成要素もあります。
エージェントユーザーも実行する処理によってはライセンスの割り当てが必要となるケースがありますので、エージェントユーザーが Microsoft 365 のリソースにアクセスを行うというようなケースでは、エージェントユーザーに対して Microsoft 365 のライセンスを割り当てる必要があるかもしれません。
自分が実行する可能性のあるワークロードに対して、どのようなライセンスが必要となるのかは確認が必要となるのではないでしょうか。
Agent 365 の挙動について確認をする際のメモ
どの種類のエージェントを制御をすることができるか
Agent 365 では「エージェントに対して個別のエージェント ID が割り当てられ、エージェントをユーザーのように制御することができる」というのが特徴としてあげられることがあるのではないでしょうか。
このドキュメントには次のように記載されています。
この ID により、エージェントは、人間の従業員と同様の権限、認証、ロール、コンプライアンス機能を備えます。
エージェント ID は Copilot Studio エージェントのMicrosoft Entra エージェント ID を自動的に作成する (プレビュー) の設定を有効にすることで、Copilot Studio で作成したエージェントに対しても自動的に付与することができます。
(本投稿作成時点では、Agent Builder で作成したエージェントに対してはエージェント ID は付与されません)
エージェント ID が付与されることで「乱立して作成したエージェントを効率的に管理できる」ことを期待すると思いますが、「自分が管理したいエージェントに対してエージェント ID が付与されることで効率的な管理が実現できるようになっているのか？」は意識する必要があります。
エージェント ID が付与することで使用することができる機能の一つとして 条件付きアクセス があります。これは、エージェント ID に対して条件付きアクセスを設定することができるようになる機能です。
このような「エージェント ID を使用した処理」で制御が行われるのは「トークンを要求する際の制御」となっていることが多いように思えます。条件付きアクセスであれば、次のドキュメントから確認をできます。
組織内に多く作成されるのは「Copilot Studio で作成された宣言型エージェント」「Agent Builder で作成された宣言型エージェント」になるように思うのですが、これらの方法で作成したエージェントが、「エージェント ID を使用した処理の制御」で挙動が変わってくるかは注意が必要ではないかと思っています。
既知の問題 には次のような記載もあり、Copilot Studio で作成したエージェントについては、カスタムエンジンエージェントでエージェント ID の機能が使えるという記載があります。。
Copilot Studioで作成されたエージェントは、エージェントの環境設定でエージェントIDにオプトインする必要があります。 現時点ではカスタムエンジンエージェントのみがサポートされています。 カスタムエンジンエージェントは現在、公開されるチャネルへの認証にエージェントIDを使用しています。 現在、Copilot Studioではコネクタやツールの認証にはエージェントIDが使われていません。
「条件付きアクセスですべてのエージェントを対象としてアクセスをブロック」というような設定を投入しても、制御されるのは「」トークンを要求する際の制御」となります。
エージェント ID が付与されている Copilot Studio で作成された宣言型エージェントはこの制御の影響を受けることなく、エージェントを使用することができるというケースがあります。
私が確認した範囲では次のようになっており、「エージェント ID を無効化」と「エージェントを無効化」は挙動 (意味) が異なっています。
- エージェント ID を無効化: トークンの要求をブロック (エージェント ID がトークンを要求しないのであれば動作する)
- エージェントを無効化: エージェントの利用をブロック (トークンの要求に関係なくブロック)
当然の内容となるかもしれませんが、「対象とするエージェントが、自分が想定した制御ができるようになっているか？」については意識しておく必要があるのではないでしょうか。
個人的な感覚としては、「Copilot Studio で作成された宣言型エージェント」では、エージェント ID を使用して制御できる範囲が少なく、「Agent 365 SDK / CLI を使用して展開しているエージェント」で今までにアナウンスされた各種制御が使用できるとなっていることが多いように思えます。
どのエージェントレジストリで制御できるか
また、Agent 365 では「エージェントレジストリを使用したエージェントの集中的な管理」も機能として挙げられますが、エージェントレジストリが、どのポータルの機能を指しているかについても意識しておくとよいかもしれません。この名称を持つ機能は次のポータルに存在しています。
- Microsoft 365 管理センター (https://admin.cloud.microsoft/)
- エージェント -> すべてのエージェント のレジストリ
- Entra 管理センター (https://entra.microsoft.com/)
- Entra ID -> エージェント ID の Agent registry
一般的な文脈でのエージェントレジストリは Microsoft 365 管理センターで実装されている機能となるのではないでしょうか。「Copilot Studio / Agent Builder で作成したエージェントの管理」を主眼とした場合、操作する機会が多いのはこちらとなります。
同一の名前を持つ機能は、Entra 管理センターにも作成されており、こちらは、エージェント ID (ならびにエージェントブループリント) という Entra ID のオブジェクトを管理するために使用される機会が多いと思います。
「エージェントレジストリを使用した管理」といった場合に、どちらの管理ポータルで管理をするのかを意識しておくことも重要ではないでしょうか。