条件付きアクセスは、組織がユーザーとエージェントが企業リソースにアクセスする方法を制御するのに役立つインテリジェントなポリシー エンジンです。 これにより、ユーザーとエージェントのコンテキスト、デバイス、場所、セッション リスク情報などのリアルタイムシグナルがまとめられ、アクセスを許可、ブロック、または制限するタイミングを決定したり、より多くの検証手順が必要になったりします。
エージェントの条件付きアクセスには、Microsoft Entra ID P1 または P2 と、各ユーザーの Microsoft Agent 365 ライセンスが必要です。 Agent 365 ライセンスの施行がまもなく開始されます。 エージェントのネットワーク制御にはMicrosoft Entra Internet Accessが必要です。 詳細については、「Microsoft Entra エージェント IDを参照してください。
エージェントの条件付きアクセスについて説明します。
- 条件付きアクセスの概要: 条件付きアクセスとは
- 組織全体でエージェント ID を管理するためのガイド: 組織内のエージェント ID を管理します。
- 条件付きアクセスでエージェント ID をターゲットにする方法
- 自律エージェント アクセスのポリシーを構成する
条件付きアクセスがエージェント アクセス要求を評価する方法
SharePoint ファイル、MCP サーバー、Open API サービスなどの企業リソースにアクセスするには、まずユーザーまたはエージェントがMicrosoft Entra IDからアクセス トークンを要求します。
条件付きアクセス ポリシーを適用すると、Microsoft Entra IDはトークンを発行する前に、構成済みのポリシー要件を評価します。 要件が満たされている場合は、アクセス トークンが発行されます。 その後、トークンがターゲット リソースに提示され、トークンが検証され、その要求を使用して承認の決定が行われます。
次の図は、このプロセスを示しています。
件名と対象ユーザーの使用方法
Microsoft Entra IDは、特定の対象ユーザー (リソース) のサブジェクトにアクセス トークンを発行します。 各アクセス トークンには、1 つのサブジェクトと 1 人の対象ユーザーが含まれます。
件名: トークンを受け取る ID。
- 委任されたアクセス シナリオでは、トークンはユーザーを表し、呼び出し元のアプリケーションまたはエージェントも識別します。
- アプリケーションのみのシナリオでは、アプリケーションまたは自律エージェントが対象となります。
- エージェントのユーザー アカウント シナリオでは、エージェントのユーザー アカウントが対象となります。
対象ユーザー: トークンの対象となるターゲット リソース。
- リソースは、Microsoft Entra IDに登録する必要があります。
- サブジェクトが複数のリソース (たとえば、複数の MCP サーバーや API) にアクセスする必要がある場合は、通常、リソースごとに個別のアクセス トークンが必要です。それぞれに独自の対象ユーザーとアクセス許可があります。
条件付きアクセス ポリシーは、アクセスを要求しているサブジェクトとアクセスする対象ユーザーの両方に基づいて評価されます。
条件付きアクセスに関する決定の方法
条件付きアクセス ポリシーは、if-then ステートメントとして動作します。
- ポリシーで定義されている条件が満たされている場合は、構成されたアクセス制御が適用されます。
- 必要なコントロールが満たされている場合は、アクセス権が付与されます。
- 必要な制御が満たされていない場合、アクセスは拒否されます。
たとえば、ユーザーがエージェントに電子メールへのアクセスを承認する前に、組織で多要素認証が必要になる場合があります。 同様に、組織は、リスクが高いエージェントからのアクセスをブロックするポリシーを構成できます。
条件付きアクセスが評価される場合
条件付きアクセスは、Microsoft Entra IDがアクセス トークンを発行または更新するたびに評価されます。 一部のリソースでは、特定のイベントに対するほぼリアルタイムの適用をトリガーできる継続的アクセス評価もサポートされています。
エージェントのアクセス パターン
エージェントは、次のいずれかのパターンを使用して、Microsoft Entra保護されたリソースにアクセスできます。
ユーザーの代理として動作するエージェント
最も一般的なアクセス パターンは、代理アクセス (OBO) フローです。 このフローでは、ユーザーがエージェント アプリケーションにサインインし、エージェントはユーザーの ID と委任されたアクセス許可を使用してダウンストリーム リソースにアクセスします。 たとえば、エージェントが電子メールを読み取ると、ユーザー に代わってメールボックスにアクセスします。 エージェントに対して OBO フローがどのように機能するかの詳細については、「Agent OAuth flows: On-behalf-of」を参照してください。
注
On-Behalf-Of フローは、委任されたアクセスとも呼ばれます。 "On-behalf-of" は、エージェントの種類ではなく、認証フローを表します。 これらの対話型エージェントには、人間とのやり取りのためのユーザー インターフェイスが含まれます。 サインインしているユーザーが存在し、エージェントがそのユーザーの ID とアクセス許可を持つリソースにアクセスする必要がある場合、どのエージェントでもこのフローを使用できます。
このフローでは、エージェントは別の対象ユーザーに対して発行されたため、ユーザーの元のトークンを再利用できません。 代わりに、エージェントは OBO フローを使用してトークンをMicrosoft Entra IDと交換し、ターゲット リソースをスコープとする新しいトークンを取得します。 このトークン交換は条件付きアクセスによっても評価され、管理者は、エージェントがユーザーに代わってアクセスできるリソースをきめ細かく制御できます。
このフローの対象はユーザーであるため、条件付きアクセス ポリシーはエージェント ID ではなく 、ユーザーとグループを対象とします。
アプリケーションとして機能するエージェント
エージェントは、サインインしているユーザーなしでリソースにアクセスする場合があります。 この場合、エージェントは独自の ID を使用してリソースにアクセスします。 このフローは、クライアント資格情報フローまたはアプリのみのアクセスとも呼ばれます。 すべての種類のエージェントがこのフローを使用する場合があります。 エージェントが独自の ID を使用して認証する方法の詳細については、「 エージェント OAuth フロー: 自律型アプリ」を参照してください。
このフローは、次の一般的なシナリオに適用されます。
-
独立して動作する自律エージェントは 、バックグラウンドで実行したり、イベントに応答したり、スケジュールに従って実行したりします。
- たとえば、日次レポートを生成し、結果を従業員のグループに送信するエージェントです。
- このシナリオでは、ユーザーは存在せず、エージェントは単独で動作します。
-
独自の ID を使用する対話型エージェント は、常にユーザーの代わりにリソースにアクセスするとは限りません。場合によっては、独自の ID を使用します。
- たとえば、ユーザーがアクセスできないバックエンド SMS サービスをエージェントが呼び出した場合、OBO フローは適用されません。エージェントはそれ自体として直接認証されます。
- 一般に使用するために Web 上で公開されたエージェント は、ユーザーを認証しないか、ユーザーのコンテキストを企業リソースに委任することをサポートしていません。
これらのシナリオでは、エージェントは、エージェント ID ブループリントで管理される独自のエージェント ID と資格情報を使用してアクセス トークンを要求します。 トークンは、(ユーザーではなく) エージェント ID に発行されます。 そのため、条件付きアクセス ポリシーのスコープは、ユーザーではなくエージェント ID になります。 詳細なポリシー構成については、「 自律エージェントの条件付きアクセス」を参照してください。
ユーザーとして機能するエージェント
エージェントがユーザーに代わってタスクを実行したり、独自の ID で操作したりするには不十分な場合があります。 特定のシナリオでは、エージェントには、独自のメールボックス、チャットへのアクセス、チーム メンバーとして共同作業ワークフローに参加する機能を持つデジタル ワーカーとして機能する独自の エージェントのユーザー アカウント があります。
このモデルでは、管理者がディレクトリにユーザー アカウントを作成し、エージェントの ID にリンクします。 そこから、他のユーザー アカウントと同じです。 ライセンスは、メールボックスや予定表などのMicrosoft 365リソースにアクセスするために割り当てることができます。 このアカウントは、人間のユーザー アカウントと同様に、管理単位とセキュリティ グループに追加できます。
このフローを使用するエージェントは、人間の操作にユーザー インターフェイスを含まないため、自律エージェントとも見なされます。 このモデルでは、アクセス トークンはエージェントのユーザー アカウント (トークンのサブジェクト) に発行され、ポリシーはエージェント ID ではなくエージェントのユーザー アカウントに対して評価されます。 詳細なポリシー構成については、「 自律エージェントの条件付きアクセス」を参照してください。 エージェント ユーザー OAuth フローの詳細については、「 エージェント ユーザーの OAuth フロー」を参照してください。
Windows 365 エージェント用クラウド PC などのマネージド エンドポイントで実行されているエージェントは、デバイスのコンプライアンスと準拠したネットワーク制御の対象となる場合もあります。 エージェント実行環境 (プレビュー) 条件を使用して、これらのポリシーのスコープをエンドポイントベースのセッションのみに限定します。 詳細については、「 エージェントのユーザー アカウントに準拠しているデバイスを要求する」を参照してください。
条件付きアクセス ポリシーとエージェント ID ブループリント
特定のエージェント アクセス パターンに加えて、 エージェント ID ブループリント を選択して、条件付きアクセス ポリシーをエージェントのクラスに適用することもできます。 すべてのエージェント ID は、その構成とガバナンス モデルを定義するエージェント ID ブループリントから派生します。 ブループリント レベルでポリシーを適用すると、そこから派生するすべてのエージェント ID が自動的にカバーされます。これには、今後追加される新しい ID も含まれます。 エージェント ID ブループリントをターゲットにしても、エージェントのユーザー アカウントは対象になりません。
次の図は、ブループリント "A" に関連付けられているエージェント ID にのみアクセス権が付与されることを示しています。他のすべてのエージェントは除外され、ブロックされます。
たとえば、複数のエージェントがあり、それぞれが独自の目的を持つプロジェクトがあるとします。 一部は独立して動作し、他のエージェント (A2A) と共同作業してタスクを完了するものもあります。 すべてが同じブループリントで作成されている場合、そのブループリントに適用される 1 つのポリシーによって、コレクション全体で一貫したアクセス制御が適用されます。
属性駆動型の条件付きアクセス
エージェント ID の数が増えるにつれて、すべてのポリシーで各 ID を個別に管理することは持続できなくなります。 カスタム セキュリティ属性を 使用すると、ビジネス固有のラベルを持つエージェント ID とリソースを分類し、条件付きアクセス ポリシーでそれらの属性をターゲットにできます。 ポリシーは、将来追加されたものも含め、一致する属性を持つすべてのエージェントに自動的に適用されます。
カスタム セキュリティ属性の作成と条件付きアクセス ポリシーでの使用に関する完全なチュートリアルについては、「 自律エージェントの条件付きアクセス」を参照してください。
条件付きアクセスの境界と制限事項
条件付きアクセス ポリシーは、次の場合には適用されません。
- エージェント ID ブループリントは、エージェント ID またはエージェントのユーザー アカウントを作成するためのMicrosoft Graphのトークンを取得します。
- エージェント ブループリントの機能は限られています。 リソースにアクセスするために独立して動作することはできないため、エージェント ID とエージェントのユーザー アカウントの作成にのみ関係します。
- エージェント タスクは、常にエージェント ID によって実行されます。
- エージェント ID ブループリントまたはエージェント ID は、
AAD Token Exchange Endpoint: Publicエンドポイント (リソース ID:fb60f99c-7a34-4190-8149-302f77469936) で中間トークン exchangeを実行します。-
AAD Token Exchange Endpoint: Publicスコープのトークンは、Microsoft Graphを呼び出すことはできません。 - 条件付きアクセスは、エージェント ID またはエージェントのユーザー アカウントからトークンの取得を保護するため、エージェント フローは保護されます。
-
- セキュリティの既定値 が有効になっています。
- 条件付きアクセスは、Microsoft Entra IDによってセキュリティ保護されたリソースのみを保護します。 たとえば、エージェントが API キーを使用してリソースにアクセスすると、Microsoft Entra ID認証とトークン発行パイプラインが完全にバイパスされ、条件付きアクセス ポリシーは適用されません。
現在、次の構成はサポートされていません。
- すべてのユーザーを対象とするポリシーには、エージェントのユーザー アカウントは含まれません。
- グループ メンバーシップに基づいてエージェントのユーザー アカウントを含めたり除外したりするための条件付きアクセス ポリシーのスコープを設定する
- エージェント ID を対象とする条件付きアクセス ポリシーは、エージェントのユーザー アカウントには適用されません。
- エージェント ID ブループリントを使用してエージェント ID を対象とする条件付きアクセス ポリシーでは、エージェントのユーザー アカウントではなく、エージェント ID のみが対象となります。