エージェントの条件付きアクセス

条件付きアクセスは、組織がユーザーとエージェントが企業リソースにアクセスする方法を制御するのに役立つインテリジェントなポリシー エンジンです。 これにより、ユーザーとエージェントのコンテキスト、デバイス、場所、セッション リスク情報などのリアルタイムシグナルがまとめられ、アクセスを許可、ブロック、または制限するタイミングを決定したり、より多くの検証手順が必要になったりします。

エージェントの条件付きアクセスについて説明します。

条件付きアクセスがエージェント アクセス要求を評価する方法

SharePoint ファイル、MCP サーバー、Open API サービスなどの企業リソースにアクセスするには、まずユーザーまたはエージェントがMicrosoft Entra IDからアクセス トークンを要求します。

条件付きアクセス ポリシーを適用すると、Microsoft Entra IDはトークンを発行する前に、構成済みのポリシー要件を評価します。 要件が満たされている場合は、アクセス トークンが発行されます。 その後、トークンがターゲット リソースに提示され、トークンが検証され、その要求を使用して承認の決定が行われます。

次の図は、このプロセスを示しています。

エージェント ID のデータ アクセス パターンを示す図。

件名と対象ユーザーの使用方法

Microsoft Entra IDは、特定の対象ユーザー (リソース) のサブジェクトにアクセス トークンを発行します。 各アクセス トークンには、1 つのサブジェクトと 1 人の対象ユーザーが含まれます。

件名: トークンを受け取る ID。

  • 委任されたアクセス シナリオでは、トークンはユーザーを表し、呼び出し元のアプリケーションまたはエージェントも識別します。
  • アプリケーションのみのシナリオでは、アプリケーションまたは自律エージェントが対象となります。
  • エージェントのユーザー アカウント シナリオでは、エージェントのユーザー アカウントが対象となります。

対象ユーザー: トークンの対象となるターゲット リソース。

  • リソースは、Microsoft Entra IDに登録する必要があります。
  • サブジェクトが複数のリソース (たとえば、複数の MCP サーバーや API) にアクセスする必要がある場合は、通常、リソースごとに個別のアクセス トークンが必要です。それぞれに独自の対象ユーザーとアクセス許可があります。

条件付きアクセス ポリシーは、アクセスを要求しているサブジェクトとアクセスする対象ユーザーの両方に基づいて評価されます。

条件付きアクセスに関する決定の方法

条件付きアクセス ポリシーは、if-then ステートメントとして動作します。

  • ポリシーで定義されている条件が満たされている場合は、構成されたアクセス制御が適用されます。
  • 必要なコントロールが満たされている場合は、アクセス権が付与されます。
  • 必要な制御が満たされていない場合、アクセスは拒否されます。

たとえば、ユーザーがエージェントに電子メールへのアクセスを承認する前に、組織で多要素認証が必要になる場合があります。 同様に、組織は、リスクが高いエージェントからのアクセスをブロックするポリシーを構成できます。

条件付きアクセスが評価される場合

条件付きアクセスは、Microsoft Entra IDがアクセス トークンを発行または更新するたびに評価されます。 一部のリソースでは、特定のイベントに対するほぼリアルタイムの適用をトリガーできる継続的アクセス評価もサポートされています。

エージェントは、次のいずれかのパターンを使用して、Microsoft Entra保護されたリソースにアクセスできます。

  • ユーザーの代理 (委任されたアクセス)
  • アプリケーションとして (エージェント ID を使用した自律的なアクセス)
  • ユーザーとして (エージェントのユーザー アカウントを使用した自律アクセス)

このアクセス モデルは、組織のリソースへの人間とエージェントの両方のアクセスをセキュリティで保護するための一貫したフレームワークを提供します。

エージェントのアクセス パターン

条件付きアクセスには、3 つのエージェント アクセス パターンがあります。 代理フロー、アプリケーション (自律アクセス) フローとして機能するエージェント、およびユーザー フローとして機能するエージェント。

代理フロー

最も一般的なアクセスは、代理サインイン ユーザー (OBO) フローです。 このフローでは、エージェントはユーザーの ID とアクセス許可を持つリソースにアクセスして、データを取得したり、ユーザーが実行できるアクションを実行したりします。 たとえば、エージェントが電子メールを読み取ると、エージェントは ユーザーに代わってメールボックスにアクセスします。

注

代理フローは、委任されたアクセスとも呼ばれます。 この種類のアクセスを使用するエージェントは、対話型エージェントまたは支援エージェントと呼ばれることもあります。これは、人とのやり取りのためのユーザー インターフェイスが含まれるためです。

次の図は、次のコンポーネントを含む、エージェントがユーザーの代わりにリソースにアクセスするときに使用される OBO フローを示しています。

  • ユーザー: エージェントにプロンプトを送信するユーザー
  • エージェント/クライアント アプリケーション: ユーザーがプロンプトを送信するユーザー インターフェイス
  • Microsoft Entra ID: エージェント ID、ユーザー アカウント、およびリソースが登録されている場所を管理する ID プロバイダー
  • AI プラットフォーム: 大規模言語モデル (LLM) が実行されるランタイム環境
  • Resource: エージェントがデータの取得またはアクション (Work IQ、オンライン SharePoint、カスタム MCP サーバーなど) を実行するために呼び出すリソース

ユーザーの代わりにリソースにアクセスするエージェントの OBO フローを示す図。

次の手順では、フローについて詳しく説明します。

  1. ユーザーがエージェント アプリケーションにアクセスします。

    1. エージェント アプリケーションはMicrosoft Entra IDに登録され、そのアクセスはMicrosoft Entra IDによって管理されます。
    2. アプリにアクセスするには、まずユーザーが自分のアカウントで認証を行う必要があります。 管理者は、条件付きアクセス ポリシーでエージェント アプリケーションを対象にすることができます。

  2. ユーザーがサインインすると、アプリはユーザーのアクセス トークンを検証し、アクセス権を付与します。

    1. ユーザーは、AI プラットフォーム (Copilot Studio、Microsoft Foundry、Microsoft以外のプラットフォームなど) にプロンプトを送信します。
    2. LLM は、要求を処理して応答するために、企業リソースを呼び出します。

  3. 企業リソース (SharePoint、電子メールなど) はMicrosoft Entra IDによって保護され、独自のアクセス トークンが必要です。

    • 別の対象ユーザーとアクセス許可に対して発行されるため、手順 1 からトークンを渡すことはできません。
    • 代わりに、OBO フローを使用して、Microsoft Entra IDとトークンを交換し、リソースにスコープ指定された新しいトークンを取得します。
    • このトークン交換は条件付きアクセス ポリシーによっても評価されるため、管理者は、ユーザーの代わりにエージェントがアクセスできるリソースをきめ細かく制御できます。
    • エージェントのアーキテクチャによっては、OBO トークン交換は、エージェント アプリケーション自体、カスタム ミドルウェア API、Copilot StudioやAzure AI Foundryなどの AI プラットフォーム、さらには MCP サーバーなど、さまざまなレイヤーで行われます。

  4. 取得した新しいアクセス トークンを使用して、エージェントはリソースを呼び出し、認証用のトークンを提示します。

    • リソースは受信トークンを検証し、その応答を返し、フローが完了します。

アプリケーションとして機能するエージェント

エージェントは、サインインしているユーザーなしでリソースにアクセスする場合があります。 この場合、エージェントは独自の ID を使用してリソースにアクセスします。 このフローは、クライアント資格情報フローまたはアプリのみのアクセスとも呼ばれます。 すべての種類のエージェントがこのフローを使用する場合があります。

次の図は、アプリケーションのみのアクセス承認フローを示しています。

独自の ID を持つリソースにアクセスするエージェントのアプリケーションのみのアクセス フローを示す図。

このフローは、次の一般的なシナリオに適用されます。

  • 独立して動作する自律エージェント:
    • これらのエージェントはバックグラウンドで実行されるか、イベントに応答するか、スケジュールに従って実行されます。
    • たとえば、日次レポートを生成し、結果を従業員のグループに送信するエージェントです。 このシナリオでは、ユーザーは存在せず、エージェントは単独で動作します。
  • 独自の ID を使用する対話型エージェント:
    • これらのエージェントは、常にユーザーの代わりにリソースにアクセスするとは限りません。場合によっては、独自の ID を使用します。
    • たとえば、ユーザーがアクセスできないバックエンド SMS サービスをエージェントが呼び出した場合、OBO フローは適用されません。エージェントはそれ自体として直接認証されます。
  • 一般に使用するために Web で公開されたエージェント:
    • これらのエージェントは、ユーザーを認証しないか、ユーザーのコンテキストを企業リソースに委任することをサポートしていません。

これらのシナリオでは、エージェントは、エージェント ID ブループリントで管理される独自のエージェント ID と資格情報を使用してアクセス トークンを要求します。 トークンは、(ユーザーではなく) エージェント ID に発行されます。 そのため、条件付きアクセス ポリシーのスコープは、ユーザーではなくエージェント ID になります。 次のオプションを使用して、条件付きアクセスでアプリケーションとして機能するエージェントをターゲットにすることができます。

  • すべてのエージェント ID: ディレクトリ内のすべてのエージェント ID を対象とします。
  • エージェント ID の選択: 特定のエージェント ID を個別にターゲットに設定します。

ユーザーとして機能するエージェント

エージェントがユーザーに代わってタスクを実行したり、独自の ID で操作したりするには不十分な場合があります。 特定のシナリオでは、エージェントに独自のエージェントのユーザー アカウントがあります。 たとえば、自分のメールボックスを持つチーム メンバーとして機能し、チャットにアクセスし、チーム メンバーとして共同作業ワークフローに参加できるデジタル ワーカーなどです。

このモデルでは、管理者がディレクトリにユーザー アカウントを作成し、エージェントの ID にリンクします。 そこから、他のユーザー アカウントと同じです。 ライセンスは、メールボックスや予定表などのMicrosoft 365リソースにアクセスするために割り当てることができます。 このアカウントは、人間のユーザー アカウントと同様に、管理単位とセキュリティ グループに追加できます。

このフローを使用するエージェントは、"デジタル ワーカー" または "AI チームメイト" と呼ばれることもあります。また、人間の操作にユーザー インターフェイスが含まれていないため、自律エージェントとも見なされます。 このモデルでは、アクセス トークンはエージェントのユーザー アカウント (トークンのサブジェクト) に発行され、ポリシーはエージェント ID ではなくエージェントのユーザー アカウントに対して評価されます。 次のオプションを使用して、条件付きアクセスでエージェント ユーザー アカウントをターゲットにすることができます。

  • すべてのエージェント ユーザー (プレビュー): ディレクトリ内のすべてのエージェント ユーザー アカウントを対象とします。
  • [エージェント ユーザーの選択 (プレビュー)]: 特定のエージェント ユーザー アカウントを個別にターゲットにします。

条件付きアクセス ポリシーを適用するエージェントを選択する方法

特定のエージェント アクセス パターンに加えて、エージェント ID ブループリントを選択して、条件付きアクセス ポリシーをエージェントのクラスに適用することもできます。 カスタム セキュリティ属性を使用して、条件付きアクセスのエージェントを分類およびターゲットにすることもできます。

エージェント ID ブループリント

条件付きアクセス ポリシーを複数のエージェント ID に一度に適用するもう 1 つの方法は、親エージェント ID ブループリントをターゲットにすることです。 すべてのエージェント ID は、その構成とガバナンス モデルを定義するエージェント ID ブループリントから派生します。 ブループリント レベルでポリシーを適用すると、そこから派生するすべてのエージェント ID が自動的にカバーされます。これには、今後追加される新しい ID も含まれます。 エージェント ID ブループリントをターゲットにしても、エージェントのユーザー アカウントは対象になりません。

次の図は、ブループリント "A" に関連付けられているエージェント ID にのみアクセス権が付与されることを示しています。他のすべてのエージェントは除外され、ブロックされます。

エージェント ID ブループリントの条件付きアクセス フローを示す図。

たとえば、複数のエージェントがあり、それぞれが独自の目的を持つプロジェクトがあるとします。 一部は独立して動作し、他のエージェント (A2A) と共同作業してタスクを完了するものもあります。 すべてが同じブループリントで作成されている場合、そのブループリントに適用される 1 つのポリシーによって、コレクション全体で一貫したアクセス制御が適用されます。

属性駆動型の条件付きアクセス

エージェント ID の数が増えるにつれて、すべての条件付きアクセス ポリシーに対して各エージェント ID を個別に追加すると、運用が維持できなくなります。 条件付きアクセス ポリシーの作成を開始する前に、エージェント ID を整理して、一貫性のあるスケーラブルなアクセス制御の適用を有効にすることが重要です。

Microsoft Entra IDのカスタム セキュリティ属性は、エージェント ID を大規模に整理するのに便利な方法です。 カスタム セキュリティ属性は、ユーザー、エージェント ID、エンタープライズ アプリケーション (サービス プリンシパル) など、Microsoft Entra オブジェクトに定義して割り当てることができるビジネス固有のキー値属性です。 これらの属性を使用すると、エージェントが処理するデータの秘密度レベルなど、各エージェント ID に関する意味のある情報を格納できます。

次の図は、"Data Sensitivity" 属性が "Confidential" に設定されているエージェント ID がブロックされていることを示しています。他のすべてのエージェントは除外され、許可されます。 これらのカスタム セキュリティ属性値は、条件付きアクセスの評価中にフィルターとして使用でき、属性ベースのターゲット設定を有効にします。 エージェント ID またはターゲット リソースの手動リストを保持する代わりに、"Data Sensitivity 属性が Confidential の場合、アクセスをブロックする" などのルールを定義できます。その後、ポリシーは、これらの属性を持つすべてのエージェント ID に自動的に適用されます。これには、将来追加されたものも含まれます。

エージェント ID の条件付きアクセス フローを示す図。

次の表に、エージェント ID を分類する方法の例をいくつか示します。

特性 タイプ 値の例
エージェント分類 String Orchestrator、SubAgent、Connector
DataSensitivity String 公開、社内、機密、限定
AgentOrigin String Copilot Studio、MicrosoftFoundry、非Microsoft
公共利用のため ブール値 True または False

カスタム セキュリティ属性は、エージェント ID だけではありません。 また、それらを使用してエージェントがアクセスする企業リソースを分類し、条件付きアクセス ポリシーで両方を使用して、アクセス チェーン全体で一貫したラベル付けシステムを実現することもできます。 詳細については、「Microsoft Entra IDを参照してください。

ターゲット リソースに関する考慮事項

条件付きアクセス ポリシーでターゲット リソースを選択するには、リソースにエンタープライズ アプリケーション (サービス プリンシパル) と、Microsoft Entra ID テナント内のアクセス許可のセットが必要です。 このポリシーは、SharePoint Online、Exchange Online、Work IQ MCP サーバー、Azure MCP サーバー、Microsoft 365 MCP サーバー、Microsoft Graph、Open API、MCP サーバー、非 Microsoft ツール、および独自に構築するカスタム ツールを含む、すべてのリソースの種類に適用されます。 詳細については、「 条件付きアクセスを使用したリソースのターゲット設定」を参照してください。

エンタープライズ アプリケーションは、データ アクセス パターンに関係なく必要です。 付与されるアクセス許可の種類は、ユーザー委任アクセスとアプリケーション アクセスによって異なりますが、サービス プリンシパルの要件はすべての場合に適用されます。

一部のMicrosoft サービスは、ディレクトリに表示される前に明示的なプロビジョニング手順を必要とします。 たとえば、必要なライセンスを有効にするか、PowerShell コマンドを実行します。 詳細については、関連する製品ドキュメントを参照してください。

カスタム MCP サーバー、Open API ベースのツール、またはその他のカスタム ツールの種類の場合は、ツールをアプリケーションとしてMicrosoft Entra IDに登録し、そのアクセス許可のセット (委任されたロールまたはアプリ ロール) を公開します。 詳細については、「 Web API を公開するようにアプリケーションを構成する方法」を参照してください。

条件付きアクセスの展開を計画する

条件付きアクセスの展開の計画は、エージェント、ユーザー、およびリソースに対する組織のアクセス戦略を達成するために不可欠です。 条件付きアクセス ポリシーを使用すると、構成の柔軟性が大幅に向上します。 ただし、この柔軟性は、望ましくない結果を回避するために慎重に計画する必要があるということです。 詳細については、「 条件付きアクセスのデプロイを計画する」を参照してください。

すべてのエージェント アクセス パターンを対象とするには、この記事で説明されている 3 つのアクセス パターン (代理サインイン ユーザー、エージェント自身の 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 のみが対象となります。

サインイン ログを使用したポリシー評価の調査

管理者は、サインイン ログを使用して、条件付きアクセス ポリシーが適用された理由または適用されなかった理由を調査できます。 エージェント固有のエントリの場合は、 agentTypeをフィルター処理します。 これらのイベントの一部は、ユーザー サインイン (非対話型) に表示され、他のイベントは Service プリンシパル サインインの下に表示されます。詳細については、「Microsoft Entra エージェント ID サインイン ログと監査ログを参照してください。

  • リソースにアクセスするエージェントの ID (アクター) → サービス プリンシパルサインイン ログ → agentType: エージェント ID
  • agentType: エージェントのユーザー アカウント→非対話型ユーザー サインイン→エージェントのユーザー アカウントがリソースへアクセス
  • エージェントにアクセスするユーザー → ユーザー サインイン

次のステップ

エージェントの条件付きアクセス ポリシーを構成する方法について説明します。

  • Last updated on