Microsoft Entra Agent IDの重要ポイントは、企業内のAIエージェントに「誰が所有し、どの権限で、いつサインインし、どう停止できるのか」を管理できるIDを与えることです。2026年6月3日に更新されたMicrosoft Learnの条件付きアクセス関連情報では、ユーザーだけでなくエージェントの文脈、対象リソース、リスク、実行環境を見てアクセス制御する考え方が整理されています。(Microsoft Learn)
管理者が最初に確認すべきことは、エージェントを一律に止めることではありません。まずインベントリを作り、サインインログを確認し、所有者・スポンサー・権限・停止手順を明確にすることです。開発者側では、従来のアプリ登録やサービスプリンシパルで動かしているAIエージェントを、Microsoft Entra Agent IDへ移行すべきかを判断する必要があります。
Microsoft Entra Agent IDのセキュリティ更新で何が変わったのか
Microsoft Entra Agent IDは、AIエージェントをMicrosoft Entra ID上の管理対象IDとして扱うための仕組みです。Microsoftの公式説明では、エージェントIDはAIエージェントの一意な識別と認証に使うIDアカウントであり、人間のユーザー、顧客ID、従来のワークロードIDとは区別して管理する目的があります。(Microsoft Learn)
これまで企業内のAIエージェントは、アプリ登録、サービスプリンシパル、APIキー、個別ツールの認証情報などで動くことが多く、セキュリティ担当者から見ると次のような問題が起きやすい状態でした。
- どのAIエージェントが存在するのか分からない
- 誰が責任者なのか分からない
- どのAPIやデータにアクセスできるのか追いにくい
- 退職者や終了済みプロジェクトのエージェントが残る
- インシデント時にどの単位で止めればよいか判断しづらい
Microsoft Entra Agent IDが狙っているのは、この「見えないエージェント」をIDガバナンスの対象に入れることです。公式の更新情報でも、AIエージェントに対して認証、認可、ガバナンス、保護を提供し、Zero Trustの原則に沿って扱うことが示されています。(Microsoft Learn)
特に企業利用で重要なのは、次の4点です。
| 観点 | これまで起きやすかった課題 | Agent IDで目指す状態 |
|---|---|---|
| インベントリ | エージェントがどこに存在するか分からない | Entra管理センターで一覧化する |
| サインイン可視化 | アプリやユーザーのログに埋もれる | エージェントとしてログを追跡する |
| 所有者・スポンサー | 責任者不明のまま権限が残る | 人間のスポンサーを紐づける |
| 停止経路 | APIキー削除やアプリ無効化が属人的 | ID、ブループリント、条件付きアクセスで止める |
影響範囲：対象になるエージェントと関係者
今回の変更は、Microsoft Entraを使うすべての企業に同じ影響が出るわけではありません。影響が大きいのは、AIエージェントを業務データや社内API、Microsoft Graph、SaaS、社内システムに接続している組織です。
Microsoftのドキュメントでは、エージェントIDを管理するための画面として、Entra管理センターの「Agents」配下にある「Agent identities」が説明されています。ここでは名前、状態、所有者、スポンサー、付与された権限、サインインログなどを確認できます。(Microsoft Learn)
| 立場 | 確認すべきこと |
|---|---|
| Entra管理者 | Agent identitiesの一覧、所有者、スポンサー、状態、条件付きアクセスの対象 |
| セキュリティ管理者 | サインインログ、エージェントリスク、ブロックポリシー、インシデント対応 |
| IDガバナンス担当 | アクセスパッケージ、有効期限、スポンサー変更、ライフサイクルワークフロー |
| 開発者 | 既存のアプリ登録・サービスプリンシパルからの移行要否、権限の最小化 |
| Copilot/Power Platform管理者 | Copilot StudioエージェントのID統合状況、古い構成の再作成要否 |
特に注意したいのは、既存のアプリ登録やサービスプリンシパルで動くAIエージェントです。Microsoftの移行ドキュメントでは、従来のアプリ登録やサービスプリンシパルで動くエージェントは、Agent ID固有のガバナンス、条件付きアクセス、集中監査ログ、ライフサイクル管理の対象にならない可能性があると説明されています。(Microsoft Learn)
管理者がまず確認すべき項目
Agent identitiesの一覧を確認する
最初に行うべき作業は、エージェントの棚卸しです。Microsoft Entra管理センターで、Agent identitiesの一覧を確認し、少なくとも次の項目を記録します。
| 確認項目 | 見るべきポイント |
|---|---|
| 名前・説明 | 業務用途が分かる名前になっているか |
| 状態 | 有効なまま放置されていないか |
| 所有者・スポンサー | 責任を持つ人間が紐づいているか |
| 付与された権限 | Microsoft Graph、社内API、グループ、ロールへのアクセスが過剰でないか |
| サインインログ | 実際に使われているか、不審なアクセスがないか |
| 作成日・オブジェクトID | 古い検証用エージェントが残っていないか |
公式ドキュメントでは、Agent identitiesの詳細画面から所有者、スポンサー、権限、サインインログなどを確認できるとされています。検索には名前やオブジェクトIDも使えます。(Microsoft Learn)
実務では、一覧を見ただけで終わらせず、「本番」「検証」「廃止予定」「所有者不明」のように分類すると、後続の対応が進めやすくなります。
サインインログで実際の利用状況を見る
AIエージェントの管理で失敗しやすいのは、作成情報だけを見て判断することです。作成済みでも使われていないエージェントもあれば、名前は検証用でも本番データにアクセスしているエージェントもあります。
Microsoftのドキュメントでは、エージェント関連のサインインログとしてagentSignInが説明されており、サインインログで「Agent type」や「Is Agent」などのフィルターを使って調査できるとされています。(Microsoft Learn)
管理者は次の観点でログを確認します。
| 観点 | 確認内容 |
|---|---|
| 頻度 | 急にサインイン回数が増えていないか |
| 対象リソース | 想定外のAPIやアプリにアクセスしていないか |
| 失敗ログ | 権限不足や認証失敗が大量に出ていないか |
| 時間帯 | 業務時間外や不自然な時間に実行されていないか |
| リスク | エージェントリスク検出が発生していないか |
Microsoft Entra ID Protectionでは、エージェントの異常なアクセス、サインイン急増、アクセス失敗などを検出するリスク種別が説明されています。侵害が疑われる場合は、リスク確認、無効化、資格情報のローテーション、廃止などを組み合わせて対応します。(Microsoft Learn)
所有者とスポンサーを必ず設定する
AIエージェントのガバナンスでは、「誰が作ったか」よりも「現在誰が責任を持つか」が重要です。Microsoftのガバナンスドキュメントでは、各エージェントIDに説明責任を持つ人間のスポンサーを割り当てる考え方が示されています。スポンサーが退職した場合、マネージャーへの移管やライフサイクルワークフローによる通知も説明されています。(Microsoft Learn)
実務では、次のようなルールを決めておくと運用が安定します。
| ルール | 例 |
|---|---|
| スポンサーは個人ではなく業務責任者にする | 開発者個人ではなく、業務システムのオーナーを指定 |
| 共同スポンサーを設定する | 休職・異動・退職時に管理不能になるのを防ぐ |
| 定期レビューを行う | 四半期ごとに権限と利用状況を確認 |
| 有効期限を設ける | 検証用エージェントは30日、本番は承認付き更新など |
条件付きアクセスで確認すべき設定
エージェントのアクセス形態を分けて考える
2026年6月3日更新の公式情報で特に重要なのが、エージェントに対する条件付きアクセスの考え方です。Microsoftの説明では、ユーザーまたはエージェントがMicrosoft Entraにトークンを要求し、条件付きアクセスがポリシー要件を評価したうえでトークンを発行する流れが示されています。(Microsoft Learn)
ただし、エージェントのアクセスは1種類ではありません。ポリシー対象を間違えると、意図した制御が効きません。
| アクセス形態 | ポリシーで見る対象 | 注意点 |
|---|---|---|
| ユーザー代理のアクセス | ユーザーまたはユーザーグループ | エージェントIDではなく、ユーザー側の条件で評価される |
| 自律型エージェントのアクセス | エージェントID | エージェント自身がアプリケーション権限でアクセスする |
| エージェントユーザーアカウント | エージェントユーザー | プレビュー機能を含むため、対象範囲を慎重に確認する |
Microsoftのドキュメントでは、On-behalf-ofフローではユーザーがサインインし、エージェントがユーザーの代理として下流リソースにアクセスするため、ポリシーはエージェントIDではなくユーザーやグループを対象にすると説明されています。一方、自律型エージェントではエージェント自身のIDを対象にします。(Microsoft Learn)
「すべてのユーザー」ではエージェントユーザーを含まない点に注意
条件付きアクセスでよくある誤解は、「All users」を対象にすればエージェントも含まれると考えてしまうことです。Microsoftのドキュメントでは、すべてのユーザーを対象にするポリシーにはエージェントユーザーアカウントが含まれないこと、またエージェントIDを対象にした条件付きアクセスポリシーはエージェントユーザーアカウントには適用されないことが説明されています。(Microsoft Learn)
そのため、少なくとも次の3つを分けて確認します。
| 対象 | 使う場面 |
|---|---|
| ユーザー | 人間がエージェントを使い、ユーザー代理でアクセスする場合 |
| エージェントID | エージェント自身が自律的にAPIやリソースへアクセスする場合 |
| エージェントユーザー | デジタルワーカーのようにユーザーアカウントとして動く場合 |
既存の条件付きアクセスポリシーを見直すときは、「人間向けの制御」「ワークロード向けの制御」「エージェント向けの制御」が混ざっていないかを確認してください。
いきなりブロックせず、レポート専用で影響を確認する
Microsoftの管理ドキュメントでは、エージェントに対する条件付きアクセスで、すべてのエージェントをブロックする、選択したエージェントを許可する、リスクの高いエージェントをブロックする、といった制御が説明されています。また、レポート専用モードの利用も示されています。(Microsoft Learn)
本番環境では、いきなり「すべてのエージェントをブロック」するのは避けるべきです。業務自動化、Copilot関連機能、社内API連携、監視や通知のワークフローが突然止まる可能性があります。
おすすめの進め方は次の通りです。
| 手順 | 内容 |
|---|---|
| 影響調査 | サインインログで対象エージェントとリソースを確認する |
| レポート専用 | 条件付きアクセスポリシーをレポート専用で作成する |
| 例外整理 | 業務上必要なエージェントを洗い出す |
| 段階適用 | 検証用、低リスク、本番の順に適用範囲を広げる |
| 監視 | ブロック、失敗、リスク検出を継続確認する |
開発者が確認すべき移行ポイント
既存のアプリ登録やサービスプリンシパルを棚卸しする
開発者側で最初に行うべきことは、「AIエージェントとして動いているが、普通のアプリ登録やサービスプリンシパルとして作られているもの」を探すことです。
Microsoftの移行ドキュメントでは、移行はDiscover、Classify、Migrate、Validate and decommissionの段階で進めると説明されています。特にDiscoverでは、所有者、サインイン活動、API権限、資格情報、OAuthフロー、RBAC、リダイレクトURI、依存関係などを確認することが求められています。(Microsoft Learn)
| 確認対象 | 見るべき例 |
|---|---|
| API権限 | Microsoft Graph、Azure OpenAI、Cognitive Services、Bot関連権限 |
| サインイン傾向 | 人間ではなく自動実行に見えるアクセスパターン |
| 資格情報 | 長期間有効なシークレットや証明書 |
| 所有者 | 現在も在籍しているか、チームで管理されているか |
| 依存関係 | Azure Functions、App Service、外部SaaS、社内APIとの接続 |
ここで大切なのは、候補を見つけてもすぐに削除しないことです。Microsoftのドキュメントでも、ヒューリスティックによる候補抽出は決定的なものではなく、各候補をレビューする必要があると説明されています。(Microsoft Learn)
Copilot Studioの古いエージェントは再作成が必要になる場合がある
Copilot Studioを使っている組織では、エージェントIDとの統合状況を確認する必要があります。Microsoftのドキュメントでは、2026年3月18日以降、新しいCopilot StudioエージェントではエージェントIDの自動作成が始まった一方、以前の構成や対象外テナントでは従来のサービスプリンシパルとして扱われる場合があると説明されています。さらに、インプレースの自動移行パスはなく、新しいエージェントを作成して手動で再構成し、検証後に旧エージェントを廃止する流れが示されています。(Microsoft Learn)
実務上は、次の順序で進めると安全です。
| フェーズ | 作業 |
|---|---|
| 発見 | 既存のCopilot Studioエージェントと認証方式を確認する |
| 分類 | 本番利用、検証利用、廃止予定に分ける |
| 再作成 | Agent ID統合が有効な新しいエージェントを作る |
| 再構成 | アクション、接続、権限、公開設定を移す |
| 検証 | 旧エージェントと同じ業務処理ができるか確認する |
| 廃止 | ログと利用者への影響を確認して旧構成を止める |
アクセス権限は最小化し、有効期限を持たせる
エージェントIDを導入しても、過剰な権限を与えたままではリスクは下がりません。Microsoftのガバナンスドキュメントでは、エージェントIDは作成時点では限定的な権限を持ち、必要なアクセスはアクセスパッケージを通じて、セキュリティグループ、OAuth API権限、Microsoft Graphアプリケーション権限、Entraロールなどとして付与できると説明されています。(Microsoft Learn)
運用では、次の基準で権限を設計します。
| 判断基準 | 推奨される考え方 |
|---|---|
| 最小権限 | まず必要なAPIスコープだけを列挙する |
| 有効期限 | 検証用や一時処理のアクセスは自動失効させる |
| 承認 | 高権限アクセスはスポンサーまたは管理者承認を必須にする |
| 再認証 | 定期レビューで不要なアクセスを削除する |
| 分離 | 本番用と検証用のエージェントIDを分ける |
特にGraph APIやディレクトリロールを付与する場合は、エージェントが実行できる操作の範囲を具体的に確認してください。「読み取りだけのつもり」で広いアプリケーション権限を付けると、ユーザーの操作を介さず広範囲のデータへアクセスできる構成になることがあります。
停止・無効化の設計は導入前に決めておく
AIエージェントのガバナンスで見落とされやすいのが、停止経路です。Microsoftのドキュメントでは、個別のエージェントID無効化、ブループリント単位の無効化、条件付きアクセスによるテナント規模のブロックなどが説明されています。一方で、テナント全体での無効化は既存エージェントの失敗、Microsoft製品体験の低下、より見えにくいサービスプリンシパル利用への逆戻りにつながる可能性があるとも注意されています。(Microsoft Learn)
停止手段は、次のように使い分けると判断しやすくなります。
| 停止方法 | 向いている場面 | 注意点 |
|---|---|---|
| 個別のエージェントIDを無効化 | 特定エージェントの不具合や侵害疑い | 依存する業務処理を事前に確認する |
| ブループリントを無効化 | 同じ設計から作られたエージェント群を止めたい | 既存エージェントにも影響する可能性がある |
| 条件付きアクセスでブロック | 一時的に広範囲のアクセスを止めたい | レポート専用で影響を見てから適用する |
| 権限削除 | 使わないAPIやロールだけを外したい | エージェント自体は残るためログ監視を続ける |
| 廃止・削除 | プロジェクト終了、移行完了 | サインインログと依存関係を確認してから行う |
停止手順は、インシデント発生後に初めて考えるのでは遅すぎます。導入時点で「誰が」「どの権限で」「どの単位を」「どの順番で」止めるのかを運用手順に入れておきましょう。
展開時に失敗しやすいポイント
Microsoft Entra Agent IDは便利な仕組みですが、設定を誤ると期待した制御が効かなかったり、逆に業務を止めたりします。特に次の点は事前に確認してください。
| 失敗しやすいポイント | 対応策 |
|---|---|
| All usersポリシーでエージェントユーザーも制御できると思い込む | エージェントID、エージェントユーザー、通常ユーザーを分けて設計する |
| APIキー経由のアクセスも条件付きアクセスで止められると思い込む | Entraのトークン発行を通る経路か確認する |
| クラウド上のエージェントにデバイス準拠条件を課す | 実行環境にデバイスシグナルがあるか確認する |
| カスタムAPIを対象リソースにできると思い込む | アプリ登録と権限公開が済んでいるか確認する |
| 本番でいきなりブロックポリシーを有効化する | まずレポート専用で影響を確認する |
| 所有者だけ見てスポンサーを設定しない | 説明責任を持つ人間のスポンサーを明確にする |
Microsoftの条件付きアクセスドキュメントでは、APIキーがEntra認証やトークンパイプラインを迂回する場合には条件付きアクセスが適用されないこと、またカスタムMCPやOpenAPIツールなどはアプリとして登録し、権限を公開する必要があることが説明されています。(Microsoft Learn)
また、エージェントIDに対するアクセス制御では、インタラクティブな修復ができないため、利用できる許可コントロールが限られます。Microsoftのドキュメントでは、エージェントIDに対するGrantコントロールはBlock accessが中心であること、デバイス準拠条件はエンドポイント上で動くエージェントの実行環境に絞って使うべきことが示されています。(Microsoft Learn)
管理者向けの初期対応チェックリスト
最初の対応は、複雑な設計から始める必要はありません。以下の順に進めると、現状把握から安全な展開までつなげやすくなります。
| 優先度 | 作業 | 完了の目安 |
|---|---|---|
| 高 | Agent identitiesの一覧を確認する | 所有者不明、スポンサー未設定、古い検証用を把握できている |
| 高 | サインインログを確認する | 実際に使われているエージェントと対象リソースが分かる |
| 高 | 条件付きアクセスをレポート専用で作る | ブロック時の影響を事前に確認できる |
| 中 | 既存のアプリ登録を棚卸しする | AIエージェント候補のサービスプリンシパルを分類できている |
| 中 | アクセスパッケージを設計する | 権限付与、有効期限、承認者が決まっている |
| 中 | スポンサー移管ルールを決める | 異動・退職時にエージェントが孤立しない |
| 中 | 停止手順を文書化する | 個別停止、ブループリント停止、CAブロックの使い分けが決まっている |
| 低 | 開発標準にAgent ID利用方針を追加する | 新規エージェントが従来のアプリ登録だけで作られない |
このチェックリストで重要なのは、技術設定だけでなく「責任者」と「終了条件」を含めることです。AIエージェントは短期間で増えやすいため、作成時のルールよりも、棚卸し、レビュー、失効、停止の仕組みが運用の成否を左右します。
まとめ：まずは可視化、次に制御する
Microsoft Entra Agent IDは、企業AIエージェントにID、所有者、権限、ログ、停止経路を与えるための基盤です。2026年6月3日更新の条件付きアクセス関連情報では、エージェントIDやエージェントユーザーを対象にしたアクセス制御の考え方がより明確になりました。
最初にやるべきことは、全エージェントの一括ブロックではありません。まずAgent identitiesの一覧とサインインログを確認し、所有者・スポンサー・権限・利用状況を棚卸ししてください。そのうえで、レポート専用の条件付きアクセスポリシー、アクセスパッケージ、有効期限、スポンサー移管、停止手順を段階的に整えるのが安全です。
開発チームは、従来のアプリ登録やサービスプリンシパルで動いているAIエージェントを洗い出し、Agent IDへ移行すべきものを分類しましょう。管理者と開発者が同じインベントリを見ながら、権限、責任者、ログ、廃止手順をそろえることが、企業AIガバナンスの第一歩です。
コメント