Microsoft Copilot Studioで作成するエージェントのセキュリティ管理は、従来の「アプリ登録中心」から、Microsoft Entra ID上でAIエージェントを識別・監査・制御する「Entra Agent ID」中心へ移行しつつあります。今回のポイントは、環境で機能が有効な場合、新しく作成するCopilot StudioエージェントにMicrosoft Entra agent identityが自動作成されることです。
管理者がすぐ確認すべきことは、対象環境でEntra Agent Identityが有効か、既存エージェントがまだアプリ登録を使っているか、新規エージェントのコネクタ権限がMicrosoft Entra管理センターで可視化されているかの3点です。なお、この機能はプレビューであり、本番利用前提の確定仕様として扱うのではなく、影響範囲を把握したうえで段階的に検証するのが安全です。Microsoftの公式ドキュメントでも、プレビュー機能は正式リリース前の機能であり、制限や変更の可能性があると説明されています。(Microsoft Learn)
Microsoft Copilot StudioのEntra agent identitiesとは
Microsoft Copilot Studioの「Automatically create Microsoft Entra agent identities for Copilot Studio agents」は、Copilot Studioで作成したエージェントに対して、Microsoft Entra ID上のエージェント用IDを自動的に作成・管理する機能です。
従来、Copilot Studioのエージェントは認証やチャネル連携のためにアプリ登録を使うケースがありました。Entra Agent Identityが有効な環境では、新しく作成されるエージェントにEntra Agent IDが割り当てられます。Microsoftは、Entra Agent IDを「Agent」サブタイプを持つサービスプリンシパルとして説明しており、OAuthベースの認証フロー自体は従来のアプリ登録と大きく変わらない一方で、ガバナンス、可視性、ライフサイクル管理の面が強化されます。(Microsoft Learn)
重要なのは、これは単なる名称変更ではないという点です。AIエージェントが増えるほど、「誰が作ったのか」「どのコネクタを使えるのか」「どの認証イベントが発生したのか」「削除時にIDも消えるのか」といった管理課題が出てきます。Entra Agent IDは、これらをMicrosoft Entra IDの管理・監査の流れに乗せるための仕組みです。
今回の変更点：新規エージェントにEntra Agent IDが自動作成される
今回の公式情報で最も大きな変更点は、Copilot Studioの環境で機能を有効化している場合、新しく作成される各エージェントにMicrosoft Entra agent identityが自動作成されることです。作成されたIDはMicrosoft Entra管理センターで表示・管理できます。また、設定はPower Platform管理センターの環境単位で行います。(Microsoft Learn)
| 確認項目 | 変更前に多かった状態 | Entra Agent Identity有効後の状態 |
|---|---|---|
| 新規エージェントのID | 従来のアプリ登録を利用 | Entra Agent IDを自動作成 |
| 管理場所 | Copilot Studio、Power Platform、アプリ登録の確認が中心 | Microsoft Entra管理センターでも確認可能 |
| 権限の見え方 | 管理者がエージェントの実行可能範囲を把握しにくい場合がある | コネクタ権限がAPI permissionsとして見える |
| 監査 | Entra ID側でのエージェント単位の可視性に制約 | サインインイベントや認証活動を確認しやすい |
| 既存エージェント | アプリ登録を利用 | 当面は継続利用し、将来的にAgent IDへ移行予定 |
管理者視点では、「新しいエージェントが増えたときに、Entra ID上にどのようなオブジェクトが増えるのか」を把握しやすくなる一方、ディレクトリオブジェクト数や条件付きアクセス、DLP、コネクタポリシーとの整合性を確認する必要があります。
影響範囲：管理者・開発者・作成者で見るべきポイント
Entra Agent Identityの影響は、Microsoft 365管理者やEntra ID管理者だけに限られません。Copilot Studioでエージェントを作る作成者、Power Platform管理者、セキュリティ担当者、開発者がそれぞれ別の観点で確認する必要があります。
Microsoft Entra ID管理者への影響
Entra ID管理者にとっての主な変化は、Copilot StudioエージェントがMicrosoft Entra ID上でより明確に識別できるようになることです。Microsoft Entra Agent IDは、AIエージェント向けのIDとセキュリティの枠組みであり、非人間IDとしてのAIエージェントを認証、認可、ガバナンス、保護するためのものと説明されています。(Microsoft Learn)
確認すべきポイントは次のとおりです。
| 観点 | 確認内容 |
|---|---|
| IDの棚卸し | Microsoft Entra管理センターでAgent IDが作成されているか |
| 監査ログ | エージェントの認証活動やサインインイベントが確認できるか |
| 条件付きアクセス | エージェントIDやコネクタ権限を対象にした制御方針を検討する |
| ディレクトリ制限 | Agent IDがディレクトリオブジェクトとしてカウントされる点を確認する |
| 所有者・責任者 | エージェントの作成者やスポンサー情報を運用上どう扱うか決める |
特に見落としやすいのがディレクトリオブジェクト数です。Copilot Studioが作成するEntra Agent IDはMicrosoft Entra IDのディレクトリオブジェクトとして扱われ、テナントのリソースクォータに影響します。公式FAQでは、既定のテナントリソースクォータや検証済みドメインがある場合の上限、新規テナント作成直後の制限にも触れられています。(Microsoft Learn)
Power Platform管理者への影響
Power Platform管理者は、環境単位の設定を確認する必要があります。Entra Agent Identityの動作は環境レベルで構成され、Power Platform管理センターから設定します。公式手順では、Power Platform管理センターのCopilot設定内にある「Entra Agent Identity for Copilot Studio」から、対象環境ごとに有効・無効を切り替える流れが示されています。(Microsoft Learn)
ただし、無効化は恒久的な回避策ではありません。Microsoftは、環境単位で現在はオプトアウトできるものの、このオプトアウト設定は一時的であり、将来的にはすべての新規エージェントでMicrosoft Entra agent identitiesが必須になると説明しています。(Microsoft Learn)
そのため、管理者は「いま無効化するか」よりも、「いつ有効化して検証するか」を考えるべきです。特に本番環境で多くのエージェントを作成している組織では、先に開発・検証環境で以下を確認しておくと安全です。
| 確認対象 | 実務での確認方法 |
|---|---|
| 開発環境 | 新規エージェント作成後、Entra Agent IDが作成されるか確認 |
| 検証環境 | Teams連携、コネクタ利用、DLPポリシーの挙動を確認 |
| 本番環境 | 管理者・作成者向けの運用ルールを整備してから展開 |
| 監査運用 | エージェントIDを棚卸しする頻度と担当者を決める |
Copilot Studio作成者への影響
エージェントを作る担当者は、通常、Entra Agent IDを手動作成する必要はありません。Copilot StudioがエージェントIDを自動管理します。公式FAQでも、Entra Agent Identityが有効な環境では新規エージェントにEntra Agent IDが自動付与され、既存エージェントはアプリ登録を継続利用すると説明されています。(Microsoft Learn)
作成者が注意すべきなのは、コネクタの追加や削除が管理者側の可視性に反映される点です。エージェントにPower Platformコネクタを設定して公開すると、そのコネクタに対応するAPI permissionsがエージェントのEntra Agent IDに付与されます。つまり、作成者が「どのツールをエージェントに持たせたか」が、Entra ID管理者やMicrosoft 365管理者にも見えるようになります。(Microsoft Learn)
これは制限というより、企業利用で必要な透明性です。作成者は「便利だからコネクタを追加する」だけでなく、「このエージェントに本当に必要なアクションだけを追加する」という最小権限の考え方を持つ必要があります。
開発者・セキュリティ担当者への影響
開発者やセキュリティ担当者は、Agent IDとコネクタ権限の関係を理解しておく必要があります。Copilot Studioでは、エージェント公開時に、エージェントが使うPower Platformコネクタに応じたAPI permissionsがEntra Agent IDへ付与されます。ただし、これらのスコープはコネクタアクセスを表すものであり、Mail.Read や Files.Read.All のような生のMicrosoft Graph権限そのものではありません。(Microsoft Learn)
また、これらのスコープはPower Platform connector runtimeで評価され、実行時にはAdvanced Connector PoliciesやDLPポリシーに基づいて再検証されます。つまり、Entra Agent IDに見えるスコープがあるからといって、DLPやACPを回避して自由にデータへアクセスできるわけではありません。(Microsoft Learn)
実務上は、次のように役割分担を整理すると運用しやすくなります。
| 担当 | 主な確認ポイント |
|---|---|
| Copilot Studio作成者 | 必要なコネクタだけを追加し、公開前に用途を確認する |
| Power Platform管理者 | DLPポリシー、ACP、環境設定を管理する |
| Entra ID管理者 | Agent ID、API permissions、サインインログを確認する |
| セキュリティ担当者 | 条件付きアクセスや監査ルールを設計する |
| 開発者 | カスタムコネクタ、REST API、MCP利用時の影響範囲を確認する |
既存エージェントはすぐに変わるのか
既存エージェントがすぐにすべてEntra Agent IDへ切り替わるわけではありません。公式情報では、Entra Agent Identityが環境で有効になる前に作成された既存エージェントは、引き続きアプリ登録を使用し、将来的にAgent IDへ移行されると説明されています。移行期間中は、Agent IDとApp Registration IDの両方に対してガバナンス機能が動作します。(Microsoft Learn)
既存エージェントを運用している組織は、まず次のように分類してください。
| エージェント種別 | 現在の扱い | 管理者が見るべき点 |
|---|---|---|
| 新規作成エージェント | 環境設定に応じてEntra Agent IDを利用 | Entra ID上のAgent ID、API permissions、ログ |
| 既存エージェント | 当面は従来のアプリ登録を利用 | アプリ登録の所有者、認証情報、変更禁止の徹底 |
| 将来移行対象 | 今後Agent IDへ移行予定 | 影響範囲、棚卸し、運用手順の準備 |
既存エージェントについては、「今すぐ手作業で作り直すべき」とは限りません。むしろ、無理に再作成するとチャネル接続、公開済みURL、利用者体験、Power AutomateやDataverse連携に影響が出る可能性があります。まずは既存エージェントの一覧、利用チャネル、接続しているコネクタ、管理責任者を整理することが重要です。
公式FAQでは、既存エージェントの移行について、GUID保持、ゼロダウンタイム、自動移行、Teams・Omnichannel・スキルの互換性維持といった特徴が示されています。ただし、実際の移行タイミングや細部は将来変更される可能性があるため、運用手順は最新の公式情報に合わせて更新してください。(Microsoft Learn)
管理者が最初に確認すべき設定
Entra Agent Identityの確認は、いきなり条件付きアクセスやDLP設計に入るより、まず「有効化状況」「対象エージェント」「IDの確認」の順で進めると失敗しにくくなります。
環境単位でEntra Agent Identityの有効化状況を確認する
Power Platform管理センターで、対象環境のEntra Agent Identity設定を確認します。公式手順では、Power Platform管理センターで「Copilot」から「Settings」を開き、Copilot Studioセクション内の「Entra Agent Identity for Copilot Studio」を選択して、環境ごとに設定を編集します。(Microsoft Learn)
確認時は、次のような表を社内管理用に作ると運用しやすくなります。
| 環境名 | 用途 | Entra Agent Identity | 確認日 | 対応方針 |
|---|---|---|---|---|
| Dev | 開発 | 有効 | 2026-05-20 | 新規エージェントで検証 |
| Test | 検証 | 有効 | 2026-05-20 | Teams・DLP動作確認 |
| Prod | 本番 | 未確認 | 2026-05-20 | 棚卸し後に有効化判断 |
本番環境だけを見ても全体像は分かりません。Copilot Studioは部門ごとに複数環境で使われることが多いため、開発、検証、本番、部門専用環境をまとめて確認するのがポイントです。
エージェントのMetadataでEntra Agent IDを確認する
作成済みエージェントにEntra Agent IDが割り当てられているかは、Copilot Studio側のメタデータから確認できます。公式手順では、Copilot Studioで対象エージェントのSettingsページを開き、Advancedを選択し、Metadataセクションを展開すると、関連付けられたEntra Agent IDのGUIDを確認できます。(Microsoft Learn)
確認したGUIDは、Microsoft Entra管理センターで該当IDを探す際に使います。ここで重要なのは、名前だけで判断しないことです。似た名前のエージェントや検証用エージェントが増えると、表示名だけでは誤認しやすくなります。運用台帳には、少なくとも次の項目を記録しておくとよいでしょう。
| 項目 | 記録例 |
|---|---|
| エージェント名 | 経費精算サポートエージェント |
| 環境名 | Finance-Prod |
| Entra Agent ID | GUID |
| 作成者・スポンサー | 部門担当者名 |
| 利用チャネル | Teams |
| 主なコネクタ | SharePoint、Dataverse |
| 公開日 | 2026-05-20 |
| 管理責任者 | 情シス／業務部門 |
コネクタ権限はどう見えるのか
今回の機能で実務上大きいのは、エージェントが利用するPower Platformコネクタの権限が、Entra Agent ID上のAPI permissionsとして見える点です。Microsoftの説明では、エージェント公開時にCopilot Studioが、エージェントで構成されたPower PlatformコネクタごとにAPI permissionsを付与します。これにより、Microsoft Entra ID管理者やMicrosoft 365管理者は、Power Platform管理センターを開かなくても、エージェントがどのコネクタを呼び出せるかを把握できます。(Microsoft Learn)
例えば、作成者がエージェントに予定表関連のコネクタやDataverse接続を追加した場合、管理者はEntra ID側でそのエージェントの権限を確認できます。これは監査やレビューの負担を下げる一方で、作成者にとっては「公開したエージェントの構成が管理対象として見える」ことを意味します。
スコープはいつ更新されるか
コネクタのスコープは、エージェントを公開したタイミングで評価・適用されます。コネクタや特定のコネクタアクションを追加・削除した場合は、エージェントを再公開することでスコープが更新されます。(Microsoft Learn)
そのため、管理者レビューを行う場合は「編集画面の状態」ではなく「公開済みの状態」を確認する必要があります。開発中に一時的に追加したコネクタが、そのまま公開されていないかをチェックする運用も有効です。
条件付きアクセスとの関係
Entra Agent IDに付与されたコネクタ権限は、Microsoft Entra Conditional Access policiesの対象にできます。たとえば、特定のネットワーク場所、デバイス準拠状態、リスク条件などを満たす場合にだけ、特定のコネクタリソース向けのトークンを発行する、といった制御を検討できます。(Microsoft Learn)
ただし、現時点で注意すべき制約があります。公式FAQでは、スコープの可視化はチャネルを問わず適用される一方、エージェントIDに対する条件付きアクセスの実行時適用は、現時点ではMicrosoft Teamsでエージェントが動作する場合に限られると説明されています。Teams以外のチャネルでは、既存のPower Platformコネクタ認証フローが引き続き使われます。(Microsoft Learn)
このため、「Entra Agent IDに条件付きアクセスを設定したから全チャネルで同じように制御される」と考えるのは危険です。チャネルごとの認証フローと制御範囲を確認してから設計してください。
Blueprint Principalとは何か
Entra Agent Identityを有効にした環境で最初のエージェントIDが作成されると、Copilot Studioはテナントに「Microsoft Copilot Studio agent identity blueprint」を追加します。これに対応するBlueprint Principalも作成されます。公式ドキュメントでは、Copilot Studioエージェントに関連付けられるAgent Identityは、このBlueprint Principalの子として作成されると説明されています。(Microsoft Learn)
Blueprint IDは公式情報で 25664c89-cea5-4ab6-b924-a54fd8a19ae0 と示されています。すべてのCopilot Studioのagent identitiesは、Copilot StudioのグローバルBlueprintの子として扱われます。(Microsoft Learn)
実務では、Blueprint Principalを見つけたときに「不審なアプリが勝手に作られた」と誤解しないことが大切です。とはいえ、Microsoft製のBlueprint Principalだから無条件に放置してよい、という意味でもありません。セキュリティレビューでは、作成タイミング、関連するAgent ID、運用部門、環境設定を合わせて確認してください。
オプトアウトはできるが、恒久対応ではない
現時点では、環境単位でEntra Agent Identityの自動作成をオプトアウトできます。Power Platform管理センターで対象環境を選び、設定パネルで「On」のチェックを外して保存する流れです。(Microsoft Learn)
ただし、Microsoftはこのオプトアウト設定を一時的なものとしており、将来的には新規エージェントにMicrosoft Entra agent identitiesが必須になると明記しています。(Microsoft Learn)
オプトアウトを検討するのは、次のようなケースに限定するのが現実的です。
| ケース | 判断の目安 |
|---|---|
| 本番環境で影響調査が未完了 | 一時的に無効化し、検証環境で先に確認する |
| Entra IDのクォータに余裕がない | オブジェクト数の棚卸しとクォータ対応を優先する |
| 条件付きアクセス設計が未整備 | 先に対象範囲とチャネル別制御を整理する |
| 監査部門との合意が未完了 | ログ確認方法と責任分界点を決めてから展開する |
逆に、長期的に無効化し続ける前提で運用設計を組むのは避けるべきです。将来的に必須化される前提で、今のうちに検証環境で動作を確認しておくほうが移行リスクを抑えられます。
削除時の挙動：エージェントを消すとAgent IDも削除される
Copilot Studioでエージェントを削除すると、関連付けられたMicrosoft Entra agent identityも削除されます。公式FAQでも、Copilot Studioからエージェントを削除すると、関連するAgent IDまたはアプリ登録がMicrosoft Entra IDから削除されると説明されています。(Microsoft Learn)
この挙動はライフサイクル管理上は便利ですが、監査や証跡管理では注意が必要です。削除前に次の情報を記録しておくと、後から調査しやすくなります。
| 削除前に残す情報 | 理由 |
|---|---|
| エージェント名と環境名 | どの業務で使われていたかを特定するため |
| Entra Agent IDまたはApplication ID | Entra ID側のログ調査に使うため |
| 利用チャネル | TeamsやOmnichannelなど影響先を確認するため |
| 接続コネクタ | データアクセス範囲を確認するため |
| 削除申請者・承認者 | 責任分界点を明確にするため |
| 削除日 | 監査ログと突き合わせるため |
特に本番利用していたエージェントは、削除前に利用者への周知、関連フローの停止、ナレッジやプロンプトのバックアップを確認しましょう。
導入・移行時に失敗しやすいポイント
Entra Agent Identityは管理を強化する機能ですが、何も準備せずに有効化すると運用で混乱する可能性があります。失敗しやすいポイントを事前に押さえておきましょう。
エージェントを「アプリ登録」と同じ感覚で管理してしまう
Entra Agent IDはサービスプリンシパルとして扱われますが、通常の長期運用アプリとは性質が異なります。AIエージェントは作成・削除の頻度が高く、部門ユーザーがローコードで作成することもあります。従来のアプリ登録レビューと同じ頻度・粒度では追いつかない場合があります。
対策として、すべてを個別審査するのではなく、環境、コネクタ、データ分類、公開チャネルを軸にリスクベースでレビューするのが現実的です。
コネクタ権限を「実データへの直接権限」と誤解する
Entra Agent IDに表示されるコネクタスコープは、エージェントが構成されたコネクタアクセスを表すものです。Microsoftは、これらが Mail.Read や Files.Read.All のような生のリソース権限ではないと説明しています。実行時にはPower Platform connector runtimeがACPやDLPに基づいて再検証します。(Microsoft Learn)
監査では、Entra ID側のAPI permissionsだけを見て結論を出すのではなく、Power PlatformのDLPポリシー、コネクタ分類、環境設定も合わせて確認してください。
Teams以外のチャネルにも条件付きアクセスが同じように効くと考える
現時点では、エージェントIDに対する条件付きアクセスの実行時適用はTeamsチャネルに限られると説明されています。Teams以外のチャネルでは、既存のPower Platformコネクタ認証フローが使われるため、同じ制御がそのまま効くとは限りません。(Microsoft Learn)
本番展開前に、利用チャネルごとの制御範囲を整理してください。特に外部公開、Omnichannel、カスタムチャネルを使う場合は、認証方式、データアクセス、ログ取得方法を個別に確認する必要があります。
既存エージェントの棚卸しを後回しにする
新機能に注目すると、新規エージェントだけを見がちです。しかし、実際のリスクは既存エージェントのほうに残っていることがあります。古いアプリ登録、不要になったエージェント、所有者不明の接続、使われていないチャネルが残っていないかを確認しましょう。
既存エージェントは将来的にAgent IDへ移行される予定です。移行時に慌てないためにも、現時点でエージェント一覧を整備しておく価値があります。
管理者向けチェックリスト
本番環境でCopilot Studioを運用している組織は、以下の順番で確認すると効率的です。
| 優先度 | 確認項目 | 具体的な作業 |
|---|---|---|
| 高 | 対象環境の設定 | Power Platform管理センターでEntra Agent Identityの状態を確認 |
| 高 | 新規エージェントのID | Copilot StudioのMetadataでEntra Agent IDのGUIDを確認 |
| 高 | Entra ID側の表示 | Microsoft Entra管理センターでAgent IDを検索 |
| 高 | コネクタ権限 | API permissionsに表示されるコネクタ関連スコープを確認 |
| 高 | DLP・ACP | Power Platform側のデータ損失防止ポリシーとコネクタポリシーを確認 |
| 中 | 条件付きアクセス | Teams利用時の制御方針を検討 |
| 中 | 既存エージェント | アプリ登録を使う既存エージェントを棚卸し |
| 中 | クォータ | Entra IDのディレクトリオブジェクト数を確認 |
| 中 | 削除運用 | 削除前に残す情報と承認フローを決める |
| 低 | 社内ルール | 作成者向けのコネクタ追加ルールや命名規則を整備 |
最初から完璧な統制を目指すより、まずは「どの環境で、どのエージェントが、どのIDを持ち、どのコネクタを使っているか」を見える化することが重要です。
開発者・作成者向けの実務ルール
Copilot Studioでエージェントを作る担当者は、次のルールを守ると管理者レビューが通りやすくなります。
| ルール | 理由 |
|---|---|
| エージェント名に用途と部門を入れる | Entra ID側で検索・識別しやすくするため |
| 不要なコネクタを追加しない | API permissionsやDLPレビューの対象を最小化するため |
| コネクタ全体ではなく必要なアクションだけを使う | 過剰な操作範囲を避けるため |
| 公開前に利用チャネルを明確にする | Teamsとその他チャネルで制御の効き方が異なるため |
| 作成者・管理責任者を明記する | 削除、棚卸し、インシデント対応を早くするため |
| 検証環境で先に公開テストする | 本番環境で意図しないIDや権限が増えるのを防ぐため |
特に「便利そうだからコネクタを全部追加する」という作り方は避けてください。AIエージェントは自然言語で操作されるため、使えるツールが多いほど予期しない実行パターンも増えます。必要なコネクタだけを与えることが、セキュリティと品質の両面で重要です。
本番展開前のおすすめ手順
本番環境でEntra Agent Identityを前提にCopilot Studioを運用する場合は、次の流れで進めると安全です。
| 手順 | 作業内容 | 完了条件 |
|---|---|---|
| 事前棚卸し | 既存エージェント、アプリ登録、利用チャネルを一覧化 | 所有者不明のエージェントがない |
| 検証環境で有効化 | 開発・検証環境でEntra Agent Identityを有効化 | 新規エージェントにAgent IDが作成される |
| コネクタ確認 | エージェント公開後のAPI permissionsを確認 | 想定したコネクタだけが見える |
| DLP確認 | Power PlatformのDLPポリシーと照合 | 禁止コネクタが使えない |
| Teams確認 | Teams上で動作と条件付きアクセスの影響を確認 | 想定どおり認証・制御される |
| 運用ルール作成 | 命名規則、削除手順、棚卸し頻度を決定 | 作成者と管理者が同じ手順を参照できる |
| 本番適用 | 対象環境で設定を適用 | 監査ログと台帳で追跡できる |
この手順の目的は、機能を有効にすることではありません。目的は、エージェントの作成から公開、実行、削除までを管理できる状態にすることです。
よくある疑問
Entra Agent IDは手動で作成する必要がある？
通常は必要ありません。Copilot StudioがエージェントIDを自動的に作成・管理します。公式FAQでも、Copilot StudioエージェントのIDは自動管理され、新規エージェントは環境設定に応じてEntra Agent IDを受け取ると説明されています。(Microsoft Learn)
自社で用意したAgent IDやアプリ登録を持ち込める？
公式FAQでは、セキュリティ、コンプライアンス、チャネルやサービスとの統合を保つため、Copilot Studioでは自動管理が必要であり、独自のAgent IDやアプリ登録の持ち込みはできないと説明されています。(Microsoft Learn)
既存の認証方式が大きく変わる？
Agent IDは「Agent」サブタイプを持つサービスプリンシパルであり、従来のアプリ登録と同じOAuthベースの認証フローを使うと説明されています。主な違いは、ガバナンス、可視性、ライフサイクル管理、監視の強化です。(Microsoft Learn)
レガシーのアプリ登録にはコネクタスコープが付く？
いいえ。公式FAQでは、コネクタスコープはEntra Agent IDにのみ追加され、レガシーのアプリ登録にはAPIスコープは付与されないと説明されています。また、現時点ではファーストパーティおよび認定Power Platformコネクタが対象で、カスタムコネクタ、MCPサーバー、REST APIツールはEntra Agent IDにAPI permissionsを追加しないとされています。(Microsoft Learn)
まとめ：まずは環境設定とエージェントIDの可視化から始める
Microsoft Copilot StudioのEntra agent identities自動作成は、AIエージェントを企業のID管理とセキュリティガバナンスに組み込むための重要な更新です。新規エージェントにはEntra Agent IDが自動作成され、コネクタ権限の可視化、監査ログ、条件付きアクセス、ライフサイクル管理に活用できるようになります。
一方で、プレビュー機能であること、既存エージェントは当面アプリ登録を使い続けること、オプトアウトは一時的であること、条件付きアクセスの実行時適用範囲に制約があることは押さえておく必要があります。
管理者が次に取るべき行動は明確です。まずPower Platform管理センターで対象環境のEntra Agent Identity設定を確認し、Copilot StudioのMetadataから新規エージェントのEntra Agent IDを取得し、Microsoft Entra管理センターでAPI permissionsとログを確認してください。そのうえで、DLP、ACP、条件付きアクセス、削除手順、エージェント台帳を整備すれば、Copilot Studioの活用を止めずにセキュリティ管理を強化できます。
コメント