Microsoft EntraのAIエージェント管理では、「どのエージェントが、いつ、どのリソースへ、どの権限でアクセスしたのか」を追えることが重要です。2026年6月3日に更新された公式情報では、Conditional Access for agentsやエージェント向けサインインログの考え方が整理され、管理者はエージェント単位のサインイン可視化と無効化、いわゆるキルスイッチを使って、危険なエンタープライズエージェントを調査・封じ込めしやすくなっています。(Microsoft Learn)
結論から言うと、Microsoft Entra Agent IDを使う組織は、まず「サインインログでエージェントを識別できるか」「問題発生時に単体エージェント、Blueprint、条件付きアクセスのどれで止めるか」「開発者が作るエージェントに過剰な権限が付いていないか」を確認すべきです。AIエージェントは人間のユーザーと違い、MFAのような対話型制御だけでは守れません。ログ、所有者・スポンサー、権限、条件付きアクセスを組み合わせて、運用で止められる状態にしておくことが実務上のポイントです。
Microsoft Entraのセキュリティ更新で何が変わったのか
今回のポイントは、Microsoft EntraにおけるAIエージェントの扱いが「単なるアプリやサービスプリンシパル」から、より明確に管理できる「エージェントID」へ寄せられていることです。
Microsoft Entra Agent IDは、AIエージェント向けに認証、認可、ガバナンス、保護を提供するIDとセキュリティの枠組みです。公式ドキュメントでは、エージェントID、Agent identity blueprint、サインインログ、監査ログ、条件付きアクセス、ID Protectionなどを組み合わせて、非人間IDを企業規模で管理する考え方が示されています。(Microsoft Learn)
管理者視点で見ると、主な変更点は次の3つです。
| 観点 | 従来ありがちだった課題 | 今回確認すべきポイント |
|---|---|---|
| 可視化 | エージェントの実行主体が通常のアプリやサービスプリンシパルに埋もれる | agentSignInやagentTypeでエージェント関連ログを識別する |
| 封じ込め | 危険なエージェントを止める判断が属人的になる | エージェント単体、Blueprint、条件付きアクセスのどれで止めるかを決める |
| ガバナンス | 誰が責任者か、どの権限が必要かが曖昧になる | スポンサー、所有者、権限、作成経路を棚卸しする |
特に重要なのは、ログで見つけられることと、見つけた後に止められることは別問題だという点です。サインインログで怪しい動きを発見できても、どの権限で止めるのか、どの範囲に影響するのかが決まっていなければ、インシデント対応は遅れます。
Per-agent sign-in visibilityとは何か
Per-agent sign-in visibilityは、エージェント単位でサインインやトークン取得の状況を確認できる可視化の考え方です。Microsoft Entraのサインインログは、誰が、どのアプリを使い、どのリソースにアクセスしたかを調査するための基盤であり、エージェントについてもこの「Who / How / What」の視点が重要になります。(Microsoft Learn)
エージェント関連のサインインログでは、agentSignInというイベント種別が使われ、エージェントがアプリとして動作したのか、エージェントインスタンスとして関与したのかなどを確認できます。公式情報では、エージェントのサインインはユーザー委任またはアプリ専用の権限で発生するため、既存のサインインログ種別にまたがって表示される可能性があると説明されています。(Microsoft Learn)
管理センターでは、少なくともReports Reader相当の権限でMicrosoft Entra管理センターにサインインし、Entra ID > Monitoring & health > Sign-in logsから確認します。エージェントを絞り込む際は、Agent typeやIs Agentのフィルターを使います。(Microsoft Learn)
管理者がログで見るべき項目
エージェントのサインインログを見るときは、単に「成功したか、失敗したか」だけを見ても不十分です。実務では、次の項目をセットで確認します。
| 確認項目 | 見る理由 | 例 |
|---|---|---|
| Agent type / Is Agent | 人間、通常アプリ、エージェントを切り分ける | Agent Identity、Agent ID user、Not Agentic |
| Resource / Application | どのデータやAPIへアクセスしたかを把握する | Microsoft Graph、SharePoint、社内API |
| Client credential type | 想定した認証方式か確認する | 証明書、フェデレーション資格情報、シークレット |
| IPアドレス・場所 | 通常と異なる実行環境を見つける | 海外IP、未知のクラウド実行基盤 |
| Conditional Access result | ポリシーが適用されたか確認する | Success、Failure、Not Applied |
| Correlation ID / Request ID | 監査ログやアプリ側ログと突合する | インシデント調査時のキー |
たとえば、営業支援エージェントが通常は国内のAzure環境からMicrosoft Graphにアクセスする設計なのに、突然未知のIPレンジから大量のトークン要求を行っている場合、単なるアプリ障害ではなく、資格情報漏えいや設定ミスを疑うべきです。
開発者がログ設計で意識すべきこと
開発者は、エージェントを動かすだけでなく、運用側が追跡できる形で設計する必要があります。エージェント名、Blueprint名、環境名、本番・検証の区別、担当チームがログから分かる命名にしておくと、調査速度が大きく変わります。
避けたいのは、agent-prod、test-agent、bot01のように、後から見ても何をするエージェントか分からない名前です。おすすめは、次のような命名です。
Agent-Sales-Report-Prod
Agent-HR-Onboarding-Dev
Agent-SecOps-Triage-Prod命名だけで完璧に管理できるわけではありませんが、サインインログ、監査ログ、条件付きアクセス、アクセスレビューで同じ識別子を追えるようになります。
キルスイッチとして使える無効化コントロール
今回の更新で実務上重要なのは、危険なエージェントを見つけた後に、複数の止め方を選べる点です。Microsoftの公式情報では、エージェントIDまたはAgent identity blueprintを管理センターで無効化する方法と、条件付きアクセスでトークン発行をブロックする方法が整理されています。(Microsoft Learn)
大きく分けると、キルスイッチは次の3種類です。
| 止め方 | 向いている場面 | 影響範囲 |
|---|---|---|
| エージェントIDを無効化 | 特定の1体だけが危険な場合 | 対象エージェントのみ |
| Blueprintを無効化 | 同じ種類のエージェント群をまとめて止めたい場合 | Blueprint配下のエージェント |
| 条件付きアクセスでブロック | テナント全体で一時停止・封じ込めしたい場合 | 条件に一致する全エージェントや全リソース |
エージェント単体の不審挙動なら、まず対象エージェントIDを無効化します。一方、同じBlueprintから作られた複数のエージェントに同じ不具合や権限過多があるなら、Blueprint単位で止める方が早い場合があります。公式のベストプラクティスでも、Blueprintを無効化すると配下のエージェントIDを即時にブロックでき、迅速なキルスイッチとして機能すると説明されています。(Microsoft Learn)
条件付きアクセスで止める3つのパターン
条件付きアクセスを使うと、個別オブジェクトを変更せずに、広範囲のエージェント認証やトークン発行をブロックできます。公式情報では、エージェント活動を止めるための主なポリシーパターンとして、エージェントIDの認証ブロック、エージェントのユーザーアカウントの認証ブロック、人間ユーザーによるエージェントリソースへのサインインブロックが示されています。(Microsoft Learn)
| ポリシー | 何を止めるか | 使う場面 |
|---|---|---|
| Block agent identity authentication | エージェントIDによるアクセストークン要求 | 自律型エージェントを広く止めたい |
| Block agent’s user account authentication | エージェント用ユーザーアカウントによるアクセス | デジタルワーカー型のアカウントを止めたい |
| Block users signing into agents | 人間ユーザーがエージェントにサインインし、代理操作を開始する動き | ユーザー委任型のエージェント操作を止めたい |
ここで注意したいのは、条件付きアクセスは「エージェントの作成そのもの」を止める機能ではない点です。公式情報では、条件付きアクセスは既存および新規のエージェントIDの認証を防げる一方、テナント内でエージェントIDが作成されること自体は防がないと説明されています。(Microsoft Learn)
つまり、緊急時の封じ込めは条件付きアクセス、恒久的な統制は作成権限・同意設定・製品側設定の見直し、という分担で考える必要があります。
影響範囲：誰が対応すべきか
この更新は、Microsoft Entra管理者だけでなく、AIエージェントを開発・導入するチームにも影響します。特にCopilot Studio、Azure AI Foundry、Security Copilot、外部のAIエージェント基盤を利用している組織では、エージェントがどのIDでMicrosoft Entraに登録され、どのリソースへアクセスするのかを確認する必要があります。
| 対象者 | 確認すべきこと | 具体的な対応 |
|---|---|---|
| Microsoft Entra管理者 | エージェントの一覧、サインインログ、条件付きアクセス | Agent typeフィルター、Report-onlyポリシー、無効化手順の確認 |
| セキュリティ担当者 | 不審なエージェント挙動、権限過多、リスク検知 | Risky Agents、監査ログ、インシデント手順への追加 |
| 開発者 | Agent IDの作成方法、権限、認証フロー | OBO、client credentials、Blueprint設計の整理 |
| 情シス・運用担当 | 所有者、スポンサー、棚卸し、廃止手順 | 命名規則、アクセスレビュー、退職・異動時の引き継ぎ |
| コンプライアンス担当 | 監査証跡、ログ保持、説明責任 | Log Analytics連携、保持期間、証跡出力ルール |
特に開発者は、「動けばよい」という発想で広いMicrosoft Graph権限を付けるのは避けるべきです。エージェントは自動処理を行うため、過剰な権限が付いたまま本番化すると、人間ユーザーよりも広範囲に影響することがあります。
まず確認すべきMicrosoft Entra設定
実際に対応を始めるなら、次の順序で確認すると抜け漏れを減らせます。
| 順番 | 確認項目 | 操作・判断のポイント |
|---|---|---|
| 1 | エージェント一覧 | Entra ID > Agents > Agent identitiesで登録済みエージェントを確認 |
| 2 | Blueprint | 同じ種類のエージェントがどのBlueprint配下にあるか確認 |
| 3 | サインインログ | Agent typeとIs Agentで絞り込み、通常時のアクセス先を把握 |
| 4 | 監査ログ | 作成、更新、削除、権限付与の履歴を確認 |
| 5 | 条件付きアクセス | Report-onlyでブロックポリシーの影響を検証 |
| 6 | 権限 | Microsoft Graphや社内APIへの付与権限を最小化 |
| 7 | スポンサー・所有者 | 退職者や異動者が残っていないか確認 |
| 8 | 緊急停止手順 | 単体無効化、Blueprint無効化、CAブロックの判断基準を文書化 |
Microsoft Entra管理センターでは、エージェントIDの詳細から名前、説明、状態、所有者、スポンサー、付与された権限、サインインログなどを確認できます。Blueprintについても、関連するエージェントID、権限、所有者、スポンサー、監査ログ、サインインログ、無効化操作を確認できます。(Microsoft Learn)
Report-onlyで必ず影響を確認する
条件付きアクセスを本番でいきなり有効化すると、業務で使っているエージェントやMicrosoft製品のシナリオまで止める可能性があります。公式情報でも、エージェント関連のブロックポリシーはまずReport-onlyモードで影響を把握してから適用することが推奨されています。(Microsoft Learn)
特に注意したいのは、次のようなケースです。
| 失敗しやすい設定 | 起きる問題 | 回避策 |
|---|---|---|
| All resourcesを対象に即時ブロック | 本番エージェントの処理が停止する | まずReport-onlyで対象サインインを確認 |
| 人間ユーザー向けMFAポリシーをそのまま流用 | エージェントが満たせない制御で失敗する | エージェント専用ポリシーを作る |
| agent identityとagent user accountを混同 | 止めたつもりの経路が残る | 3つのアクセスパターンを分けて設計 |
| Blueprintを大きくまとめすぎる | 1つの無効化で広範囲が止まる | 信頼境界ごとにBlueprintを分ける |
| ログ保持を既定任せにする | インシデント後に調査できない | Log Analyticsなどへのエクスポートを検討 |
管理者が押さえるべきアクセスパターン
エージェントの条件付きアクセスを正しく設計するには、エージェントがどの方式でアクセスするのかを理解する必要があります。公式情報では、エージェントのアクセスパターンとして、ユーザーの代理で動くケース、アプリとして自律的に動くケース、エージェント専用ユーザーアカウントとして動くケースが説明されています。(Microsoft Learn)
ユーザーの代理で動くエージェント
たとえば、ユーザーがチャット画面で「今週の未読メールを要約して」と依頼し、エージェントがそのユーザーのメールボックスを読むケースです。この場合、ユーザーの権限や委任されたアクセス許可が関係します。
確認すべきポイントは、ユーザーが許可した範囲を超えていないか、条件付きアクセスが想定どおり評価されているかです。ユーザーの代理アクセスでは、人間ユーザーのサインイン体験とエージェントの下流アクセスがつながるため、ログの相関が重要になります。
アプリとして自律的に動くエージェント
夜間バッチでレポートを作るエージェント、チケットを監視して自動分類するエージェント、社内APIを定期的に呼び出すエージェントなどが該当します。この場合、トークンの主体はエージェントIDです。
このパターンでは、エージェントIDに付与されたアプリケーション権限が強くなりがちです。Mail.ReadWrite.AllやSites.Read.Allのような広い権限を安易に付けると、侵害時の影響範囲が大きくなります。実務では、リソース側のスコープ制限、アプリロール、サイト単位の制御、専用APIの設計を組み合わせて最小権限に寄せるべきです。
エージェント用ユーザーアカウントとして動くエージェント
一部のエージェントは、メールボックス、予定表、Teams上の存在感など、人間ユーザーに近い機能を必要とします。この場合、エージェントに紐づくユーザーアカウントが作成されることがあります。
この方式は便利ですが、ライセンス、グループメンバーシップ、ユーザー向けポリシー、退職者処理、アクセスレビューなどの運用負荷が増えます。公式のベストプラクティスでも、エージェントのユーザーアカウントは本当に必要な場合に限定すべきとされています。(Microsoft Learn)
開発・移行・展開で注意すべきポイント
Microsoft Entra Agent IDを前提にAIエージェントを展開する場合、既存のアプリ登録やサービスプリンシパルをそのまま使い続ける設計は見直し対象になります。公式ベストプラクティスでは、AIエージェントを通常のアプリ登録やサービスプリンシパルとして作るのではなく、Agent IDのサポートされた作成チャネルを使い、スポンサー責任やライフサイクル制御を持たせることが推奨されています。(Microsoft Learn)
開発時のチェックリスト
開発チームは、リリース前に次の項目を確認してください。
| チェック項目 | OKの状態 |
|---|---|
| エージェントの目的 | 何を自動化するか、何をしてはいけないかが文書化されている |
| 認証フロー | OBO、client credentials、エージェント用ユーザーのどれを使うか決まっている |
| Blueprint設計 | 信頼境界ごとに分けられている |
| 権限 | 最小権限で、不要なGraph権限がない |
| シークレット | 本番では可能な限りフェデレーション資格情報や証明書を使う |
| ログ | エージェント名、環境、処理IDを追跡できる |
| 停止方法 | 単体停止と全体停止の手順がある |
| 所有者・スポンサー | 技術責任者と業務責任者が登録されている |
特に重要なのは、Blueprintの粒度です。公式情報では、Agent identity blueprintは配下のエージェントIDの代わりにトークンを取得するための資格情報を持つと説明されており、Blueprintの侵害は配下の全エージェントに影響し得ます。信頼境界が異なる環境や実行基盤を、同じBlueprintにまとめすぎないことが重要です。(Microsoft Learn)
移行時の注意点
既存のAIエージェントや自動化アプリをMicrosoft Entra Agent IDへ寄せる場合、単純な名前変更では済みません。次の観点で移行計画を作ります。
| 移行観点 | 確認内容 |
|---|---|
| 既存ID | App registration、service principal、managed identityの棚卸し |
| 権限 | どのAPI権限が実際に使われているか |
| ログ | 移行前後でサインインログの見え方が変わるか |
| 条件付きアクセス | 既存ポリシーで誤ってブロックされないか |
| 同意 | 管理者同意やユーザー同意の再確認が必要か |
| ロール | Agent ID Administrator、Agent ID Developerなどの割り当て |
| 運用 | 障害時の切り戻し、無効化、再有効化の手順 |
「既存のサービスプリンシパルで問題なく動いているから、そのままでよい」と判断するのは早計です。AIエージェントとしての責任者、実行範囲、ログ、キルスイッチが定義されていなければ、利用拡大とともにガバナンスの盲点になります。
セキュリティ担当者向けの実務対応
セキュリティ担当者は、エージェントを新しい攻撃対象として扱う必要があります。人間のアカウント侵害と同じように、エージェントの資格情報漏えい、過剰権限、想定外のリソースアクセス、異常なトークン要求を検知する体制が必要です。
Microsoft Entra ID Protection for agentsでは、エージェントIDの異常動作を監視し、Risky Agentsレポートでリスク状態やリスクレベルなどを確認できます。対応アクションとして、侵害確認、安全確認、リスクの却下、エージェントの無効化などが用意されています。なお、プレビュー期間中のID Protection for agentsにはMicrosoft Entra ID P2が必要とされています。(Microsoft Learn)
インシデント時の判断フロー
不審なエージェントサインインを見つけた場合は、次の順序で対応します。
| フェーズ | 実施内容 |
|---|---|
| 検知 | Risky Agents、サインインログ、監査ログ、SIEMアラートを確認 |
| 初動 | 対象エージェントIDを特定し、必要に応じて無効化 |
| 範囲確認 | 同じBlueprint配下の他エージェント、同じ資格情報、同じ権限を確認 |
| 封じ込め | Blueprint無効化または条件付きアクセスで広域ブロック |
| 調査 | Resource、IP、Correlation ID、Request ID、権限付与履歴を確認 |
| 復旧 | 資格情報のローテーション、権限削減、ポリシー修正 |
| 再発防止 | 命名規則、スポンサー、アクセスレビュー、ログ保持を見直し |
調査で見落としやすいのは、エージェントID本体だけでなく、Agent identity blueprint、Blueprint principal、エージェント用ユーザーアカウント、同じ権限を継承する別インスタンスです。単体エージェントを止めただけで終わらせず、同じ設計パターン全体を確認してください。
よくある疑問
Microsoft Entraのサインインログだけ見れば十分ですか
十分ではありません。サインインログは「認証・トークン取得」の調査に強い一方、誰がエージェントを作成・更新・削除したか、権限を変更したかは監査ログも確認する必要があります。公式情報でも、エージェントIDの作成はサービスプリンシパル作成、Blueprint作成はアプリケーション作成など、基礎となるID種別の監査イベントとして記録されると説明されています。(Microsoft Learn)
エージェントを無効化すると何が起きますか
対象エージェントはトークンを受け取れず、Microsoft Entra IDや接続アプリへのサインインができなくなります。ただし、既存の業務フローがそのエージェントに依存している場合、処理失敗や製品側機能の停止が起きる可能性があります。公式情報でも、エージェントIDやBlueprintの無効化は、既存エージェントやMicrosoft製品体験に影響する可能性があるため、事前に活動内容を確認するよう注意されています。(Microsoft Learn)
条件付きアクセスで全エージェントを止めれば安全ですか
緊急封じ込めとしては有効ですが、恒久対策としては粗すぎます。全エージェントを止めると、正当な自動化や業務アプリも止まります。通常運用では、Blueprint、カスタムセキュリティ属性、リスクレベル、対象リソースを使って、必要な範囲だけを制御する設計が望ましいです。
開発者にどこまで権限を渡すべきですか
開発者には、開発環境で必要なAgent ID Developer相当の権限を限定的に付与し、本番の管理者同意、条件付きアクセス、権限レビューはID管理者やセキュリティ担当者が関与する形が安全です。本番投入前に、スポンサー、Blueprint、認証フロー、API権限、ログ、停止手順をレビューする「本番化チェック」を設けると、野良エージェント化を防ぎやすくなります。
まず実施すべき対応まとめ
Microsoft Entraのエージェント向けサインインログとキルスイッチは、AIエージェントのガバナンス盲点を減らすための実務的な更新です。重要なのは、機能を知るだけでなく、日常運用とインシデント対応に組み込むことです。
まずは、次の5つを実施してください。
Entra ID > Agents > Agent identitiesで登録済みエージェントを棚卸しする- サインインログで
Agent typeとIs Agentを使い、通常時のアクセスパターンを把握する - 単体エージェント、Blueprint、条件付きアクセスの停止基準を決める
- 条件付きアクセスのブロックポリシーをReport-onlyで検証する
- 開発者向けに、命名規則、最小権限、スポンサー登録、本番化レビューをルール化する
AIエージェントは便利な自動化手段である一方、企業のID境界を越えてデータやAPIにアクセスする存在でもあります。Microsoft Entra Agent IDのログと無効化コントロールを使い、見える状態、止められる状態、説明できる状態を先に作っておくことが、これからのエージェント運用で最も重要です。
コメント