Microsoft Entra Conditional Access / Agent IDの更新情報を見て、「AIエージェント向けポリシーをすぐ変更すべきか」「OBOと自律型エージェントのどちらにテンプレートを適用するのか」と迷う管理者も多いでしょう。
結論から言うと、2026年6月17日に確認できる変更は、On-Behalf-Of（OBO）フローの説明から専用設定手順へのリンクを削除したガイダンス修正です。既存ポリシーが自動で書き換わる変更ではありません。
管理者が押さえるべきポイントは、アクセスする主体によってポリシー対象が変わることです。ユーザーの代理で動くOBOエージェントはユーザーやグループ、自分自身のIDで動く自律型エージェントはエージェントID、ユーザーアカウントを持つデジタルワーカーはエージェントユーザーを対象にします。(GitHub)
| 確認項目 | 結論 |
|---|---|
| 2026年6月17日の変更 | OBO向け個別手順への参照を削除したドキュメント修正 |
| 自動的な影響 | ポリシーの自動作成、既存設定の変更、強制有効化はない |
| 最重要の判断基準 | アクセストークンの主体がユーザー、エージェントID、エージェントユーザーのどれか |
| 管理者の対応 | AI Agentsテンプレートを確認し、レポート専用モードで評価する |
| 移行 | 従来のアプリ登録やサービスプリンシパルからのインプレース変換はできない |
| 期限 | 一律の移行期限は未提示。Agent 365ライセンスの強制は「近日予定」だが日付は未公表 |
2026年6月17日の「Conditional Access for Agents guidance updated」で何が変わったのか
Microsoft Learnの「Conditional Access for agents」ページは、画面上では最終更新日が2026年6月11日と表示されています。一方、Microsoft公式GitHubの更新履歴には、6月17日付の修正コミットが記録されています。
修正内容は1行です。OBOフローの説明に付いていた「ステップバイステップのポリシー設定」へのリンクが削除されました。コミットメッセージにも、OBOフローを利用するエージェント向けの設定手順への参照を削除したことが明記されています。(GitHub)
実務上は、次のように理解すればよいでしょう。
- OBOフローにおけるアクセス主体はユーザーである
- OBOの制御に「すべてのエージェントID」を対象とするポリシーを使わない
- ユーザーやグループを対象とした既存のConditional Accessを確認する
- エージェントがアクセスするSharePoint、Microsoft Graph、APIなどの対象リソースも確認する
公式のポリシーテンプレート一覧には、現在も「Configure policy for on-behalf-of agent access」が掲載されています。ただし、テンプレート名だけで対象を判断せず、実際に発行されるトークンの主体を確認することが重要です。(Microsoft Learn)
Conditional Access for AI agentsはアクセス主体で設定を分ける
Conditional Access for AI agentsでは、「どの製品で作ったエージェントか」よりも、「誰のIDとしてアクセストークンを取得するか」が重要です。
| アクセス方式 | トークンの主体 | Conditional Accessの対象 | 代表的な利用例 |
|---|---|---|---|
| On-Behalf-Of（OBO） | ユーザー | ユーザー、グループ | ユーザーのメールやファイルを代理で参照するアシスタント |
| 自律型・アプリ専用 | エージェントID | エージェントID、エージェントIDブループリント | 定期レポート作成、バックグラウンド処理 |
| エージェントユーザー | エージェント専用ユーザーアカウント | All agent users、個別のagent user | メールボックスや予定表を持つデジタルワーカー |
OBOでは、エージェントがユーザーのトークンをそのまま再利用するのではなく、対象リソース向けの新しいトークンを取得します。このトークン交換もConditional Accessの評価対象になりますが、ポリシーの対象はエージェントIDではなくユーザーやグループです。
自律型エージェントでは、サインイン中のユーザーが存在しません。エージェント自身が主体になるため、エージェントIDまたはブループリントを対象にポリシーを設定します。
エージェントユーザーは、人間のユーザーに近い専用アカウントです。ただし、「すべてのユーザー」を対象とする既存ポリシーにはエージェントユーザーが含まれません。別途、All agent usersまたは個別のagent userを選ぶ必要があります。これらの選択肢は現時点でプレビューです。(Microsoft Learn)
管理者が理解すべき3つのポリシーテンプレート
Microsoft Entra管理センターでは、次の経路からAIエージェント向けテンプレートを確認できます。
Entra ID → Conditional Access → Create new policy from templates → AI Agents
公式のテンプレート一覧には、次の3種類が掲載されています。作成したテンプレートは初期状態でレポート専用モードになるため、作成しただけではアクセスをブロックしません。設定内容の編集、JSON形式でのエクスポート、編集したJSONのインポートにも対応しています。(Microsoft Learn)
| テンプレート | 主な用途 | 確認すべきポイント |
|---|---|---|
| Block high-risk agent identities | リスクが高いエージェントIDをブロック | Agent riskとEntra ID P2の有無 |
| Configure policy for autonomous agent access | 自律型エージェントのアクセス範囲を制限 | 承認済みエージェント、対象リソース、除外設定 |
| Configure policy for on-behalf-of agent access | ユーザー代理アクセスを制御 | エージェントIDではなくユーザーやグループが対象 |
Block high-risk agent identities
Microsoft Entra ID Protectionが高リスクと判定したエージェントIDを、組織のリソースからブロックするためのテンプレートです。
公式の推奨例は、次の構成です。
- 対象：すべてのエージェントID
- 対象リソース：すべてのリソース
- 条件：Agent riskがHigh
- アクセス制御：Block
エージェントIDには、人間のようにMFAを実施したり、パスワードを変更したりする対話型の修復手段がありません。そのため、エージェントIDで利用できるアクセス制御は基本的にブロックです。
Agent riskはプレビュー機能であり、Microsoft Entra ID Protectionを利用するためMicrosoft Entra ID P2が必要です。(Microsoft Learn)
Configure policy for autonomous agent access
サインイン中のユーザーが存在せず、自分自身のIDで動くエージェントを制御するテンプレートです。
例えば、毎朝SharePointのデータを集計してレポートを作るエージェントや、イベントを検知してバックエンドAPIを呼び出すエージェントが該当します。
導入初期は、次のような「原則ブロック、承認済みだけ除外」の構成が分かりやすいでしょう。
- すべてのエージェントIDを対象にする
- すべてのリソースへのアクセスをブロックする
- 審査済みのエージェントIDまたはブループリントだけを除外する
- レポート専用モードで影響を確認してから有効化する
エージェント数が少ない段階では個別選択でも管理できます。しかし、数十、数百と増える環境では、ブループリントやカスタムセキュリティ属性を利用した方が安全です。
例えば、「承認済み」「審査中」「人事部門用」「財務部門用」といった属性を付ければ、新しく追加されたエージェントにも条件を自動適用できます。ブループリントを対象にしたポリシーは、将来そのブループリントから作られるエージェントIDにも適用されます。ただし、エージェントユーザーには適用されません。(Microsoft Learn)
Configure policy for on-behalf-of agent access
OBOフローでは、エージェントがユーザーの代理としてリソースへアクセスします。評価対象はユーザーやグループであり、エージェントIDではありません。
確認すべき設定は、通常のユーザー向けConditional Accessと共通します。
- 対象となるユーザーとグループ
- エージェントがアクセスするMicrosoft 365やカスタムAPI
- MFAや認証強度の要件
- デバイス、ネットワーク、場所などの条件
- 緊急アクセス用アカウントの除外
- 他のConditional Accessポリシーとの重複
ユーザー対象のテンプレートでは、初期状態で除外されるのはテンプレートを作成したユーザーだけです。緊急アクセス用アカウントなど、ほかに除外が必要なアカウントは管理者が追加しなければなりません。(Microsoft Learn)
エージェントユーザー向けポリシーは別に考える
メールボックスや予定表を持ち、人間のメンバーに近い形で働くデジタルワーカーは、エージェントユーザーとして扱われる場合があります。
エージェントユーザーには、次の条件を利用できます。
- Agent risk
- Agent execution environments
- デバイスプラットフォーム
- デバイスフィルター
- 準拠ネットワーク
管理対象エンドポイントで動くエージェントユーザーには、Intune準拠デバイスや準拠ネットワークを要求できます。ただし、クラウド上で直接実行され、デバイス情報を持たないエージェントに準拠デバイスを要求すると、条件を満たす手段がないままブロックされます。
この問題を避けるには、「Agent execution environments」条件を使い、エンドポイントから開始されたセッションだけにデバイス要件を適用します。現時点では、エージェントユーザー、Agent execution environments、Agent riskなどの一部機能がプレビューである点にも注意が必要です。(Microsoft Learn)
誰に影響するのか
| 対象 | 主な影響 |
|---|---|
| Conditional Access管理者 | 対象ID、テンプレート、除外、レポート専用結果の見直しが必要 |
| Agent ID管理者 | エージェントID、ブループリント、エージェントユーザーの分類が必要 |
| AIエージェント開発者 | OBO、アプリ専用、agent userの認証方式を管理者へ明示する必要がある |
| SOC・運用担当者 | エージェントのサインイン失敗、リスク、ポリシーブロックの監視が必要 |
| 一般ユーザー | OBO利用時にMFA要求やアクセス拒否が発生する可能性がある |
| 調達・ライセンス担当者 | Entra ID P1/P2、Agent 365、Entra Internet Accessの確認が必要 |
一般ユーザーが自分でConditional Accessを設定する必要はありません。エージェント利用時に突然MFAを求められたり、アクセス拒否が発生したりした場合は、発生時刻、エージェント名、アクセスしようとしたリソースを管理者へ伝えると調査しやすくなります。
Conditional Access for AI agentsの確認・設定手順
エージェントを3種類に分類する
最初に、各エージェントを次のいずれかに分類します。
- ユーザーの代理で動くOBO
- 自分のIDで動く自律型
- 専用ユーザーアカウントを持つエージェントユーザー
認証方式が分からない場合は、エージェントの開発者や製品担当者に確認してください。製品名だけで判断すると、誤った対象にポリシーを設定する可能性があります。
Agent IDとして認識されているか確認する
Microsoft Entra管理センターで、次の画面を確認します。
Entra ID → Agents → Agent identities
従来のアプリ登録やサービスプリンシパルで動くエージェントは、標準のアプリケーションとして扱われることがあります。その場合、Agent ID固有のポリシー対象やログ機能を利用するには移行が必要です。
対象リソースを確認する
Conditional Accessで選択するリソースには、Microsoft Entraテナント内のエンタープライズアプリケーション、つまりサービスプリンシパルが必要です。
独自のMCPサーバーやOpenAPIツールを保護する場合は、Microsoft Entra IDにアプリとして登録し、必要なAPIアクセス許可を公開します。APIキーだけでアクセスする仕組みは、Microsoft Entraのトークン発行処理を通らないためConditional Accessでは保護できません。(Microsoft Learn)
テンプレートをレポート専用で作成する
対象に合ったテンプレートを選び、次の項目を確認します。
- 対象となるID
- 対象リソース
- 条件
- ブロックまたは許可の制御
- 除外対象
- 既存ポリシーとの重複
最初から「On」にせず、レポート専用モードで作成します。
サインインログで影響を確認する
エージェント関連のサインインは、次の画面から確認できます。
Entra ID → Monitoring & health → Sign-in logs
「Agent type」ではAgent ID user、Agent Identity、Agent Identity Blueprintなどを選択でき、「Is Agent」ではエージェント関連イベントだけに絞り込めます。ログの閲覧には、少なくともReports Reader相当の権限が必要です。(Microsoft Learn)
正常な処理だけでなく、定期ジョブ、バッチ処理、夜間処理も含めて確認してください。短時間の手動テストだけでは、バックグラウンドで利用されるリソースを見落とす可能性があります。
段階的に有効化する
影響がないことを確認したら、対象を限定して有効化します。
- テスト用エージェント
- 非本番エージェント
- 影響の小さい本番エージェント
- 重要な本番エージェント
テンプレートのJSONをエクスポートして変更履歴を管理しておくと、レビューやロールバックがしやすくなります。
既存エージェントの移行が必要なケース
標準のアプリ登録やサービスプリンシパルを使っている
従来のアプリ登録やサービスプリンシパルとして作成されたAIエージェントは、Agent ID固有のガバナンス、ログ、Conditional Accessを利用できません。
既存オブジェクトをそのままエージェントIDへ変換するインプレース移行は用意されていません。一般的には、次の流れで移行します。
- 既存のアプリ登録とサービスプリンシパルを棚卸しする
- 移行対象、維持対象、廃止対象に分類する
- ブループリントとエージェントIDを新規作成する
- APIアクセス許可と資格情報を移す
- アプリケーションコードを新しいトークン取得方式へ変更する
- 新旧IDを並行稼働して検証する
- 旧アプリ登録を段階的に廃止する
既存のサービスプリンシパルをすぐ削除すると、定期処理や他システムとの連携が停止するおそれがあります。サインイン履歴、APIアクセス許可、所有者、証明書やシークレットを記録してから進めてください。(Microsoft Learn)
古いCopilot Studioエージェントを使っている
Microsoft公式ガイダンスでは、2026年3月18日以降に作成された新しいCopilot Studioエージェントについて、Agent IDが自動作成されるようになったと説明しています。
次のエージェントは確認が必要です。
- 2026年3月18日より前に作成した
- Agent ID連携を有効にする前に作成した
- 組織がAgent ID作成をオプトアウトしていた
既存のCopilot Studioエージェントをインプレース変換する機能はありません。Agent ID連携を有効にした状態で新しいエージェントを作成し、チャネルや接続を再設定したうえで、旧エージェントを廃止します。
なお、2026年3月18日は新規作成時の動作が変わった日であり、旧エージェントの廃止期限ではありません。(Microsoft Learn)
料金・ライセンス・期限の確認ポイント
Microsoft Entra Agent IDのID基盤自体は、Microsoft Entraの顧客が利用できます。ただし、Conditional Access、リスク検知、ネットワーク制御には追加のライセンス要件があります。
2026年6月18日時点で日本向け公式ページに表示されている参考価格は次のとおりです。価格はいずれも税別、年契約のユーザー月額相当であり、契約形態や既存ライセンスによって変わります。
| 利用する機能 | 主なライセンス要件 | 日本向け参考価格 |
|---|---|---|
| Conditional Access for agents | Microsoft Entra ID P1以上 | P1：899円 |
| 高リスクエージェントのブロック | Microsoft Entra ID P2 | P2：1,349円 |
| Microsoft 365サービスとのAgent 365連携 | Microsoft Agent 365 | 2,248円 |
| エージェントのネットワーク制御 | Microsoft Entra Internet Access | Entra Suiteまたは単体契約を確認 |
Microsoft Entra ID P1はMicrosoft 365 E3やBusiness Premium、P2はMicrosoft 365 E5に含まれる場合があります。Agent 365やEntra Suiteを含むMicrosoft 365 E7も提供されているため、表の金額を単純に加算せず、テナントに割り当て済みのサービスプランを確認してください。(Microsoft)
Conditional Access for agentsの公式ページでは、各ユーザーにMicrosoft Agent 365ライセンスが必要であり、ライセンス強制は近日予定と説明されています。ただし、開始日は示されていません。
現時点で公式ガイダンスに明示されていないものは次のとおりです。
- すべての既存エージェントに対する一律の移行期限
- 2026年6月17日を起点とした強制適用日
- Agent 365ライセンス強制の具体的な開始日
現在ライセンスチェックが強制されていない環境でも、無償で継続利用できることを前提に設計しない方が安全です。
設定時に失敗しやすいポイント
| 失敗例 | 起こり得る問題 | 対応 |
|---|---|---|
| OBOをエージェントIDポリシーだけで保護する | ユーザー代理アクセスに想定した制御が適用されない | ユーザー、グループ、対象リソースのポリシーを確認する |
| 「すべてのユーザー」にagent userも含まれると思う | エージェントユーザーが保護対象から漏れる | All agent usersまたは個別のagent userを選ぶ |
| クラウドネイティブなagent userに準拠デバイスを要求する | 準拠情報を提示できずアクセス不能になる | Agent execution environmentsでエンドポイント実行に限定する |
| APIキー利用のMCPサーバーも保護されると思う | Conditional Accessを通らずアクセスされる | Entra ID認証とトークン発行を利用する |
| テンプレートを作成後すぐに有効化する | 定期処理や本番エージェントが停止する | レポート専用、ログ確認、段階適用の順で進める |
| 従来のサービスプリンシパルをAgent IDとみなす | エージェント固有の対象選択やログが利用できない | オブジェクト種別を確認し、必要なら移行する |
| Security defaultsを無計画に無効化する | ユーザー向けの基本保護に空白が生じる | 代替するConditional Accessを準備してから切り替える |
Conditional Accessは、Security defaultsが有効な状態では適用されません。また、エージェントIDを対象としたポリシーはエージェントユーザーを保護せず、ブループリントを対象にしてもエージェントユーザーには適用されません。対象漏れを防ぐには、エージェントIDとエージェントユーザーを別々に棚卸しする必要があります。(Microsoft Learn)
まず実施すべきこと
2026年6月17日の更新を受けて、既存ポリシーを急いで変更する必要はありません。先に、エージェントごとのアクセス方式を確認してください。
管理者が優先すべき作業は次の3点です。
- OBO、自律型、エージェントユーザーのどれに該当するかを棚卸しする
- AI Agentsテンプレートをレポート専用モードで作成し、サインインログを確認する
- P1、P2、Agent 365、Entra Internet Accessの保有状況と、旧サービスプリンシパルの移行要否を確認する
特に重要なのは、テンプレート名ではなくアクセストークンの主体を基準にすることです。この判断を誤らなければ、OBOへの過剰な設定、自律型エージェントの保護漏れ、エージェントユーザーの意図しない停止を避けやすくなります。
コメント