エージェントのユーザー アカウントは、エージェントと人間のユーザー機能の間のギャップを埋めるために設計された特殊な ID の種類です。 エージェントのユーザー アカウントを使用すると、AI を利用したアプリケーションは、適切なセキュリティ境界と管理制御を維持しながら、ユーザー ID を必要とするシステムやサービスと対話できます。 これにより、組織は、人間のユーザーと同様の機能を使用してエージェントのアクセスを管理できます。
エージェントのユーザー アカウント シナリオの例
エージェントがユーザーに代わってタスクを実行したり、自律アプリケーションとして動作したりするには不十分な場合があります。 特定のシナリオでは、エージェントはユーザーとして機能し、基本的にデジタル ワーカーとして機能する必要があります。 エージェントのユーザー アカウントが適用されるシナリオの例を次に示します。
- 組織には、メールボックス、チャット アクセス、人事システムへの組み込みを持つチーム メンバーとして機能する長期的なデジタル従業員が必要です。
- エージェントは、ユーザー ID のみが使用できる API またはリソースにアクセスする必要があります
- エージェントは、チーム メンバーとして共同作業ワークフローに参加する必要があります
このような理由から、エージェントのユーザー アカウントが作成されます。 エージェントのユーザー アカウントは省略可能であり、エージェントがユーザーとして機能するか、ユーザー アカウントに制限されたリソースにアクセスする必要がある対話のためにのみ作成する必要があります。
エージェントのユーザー アカウント
エージェントのユーザー アカウントは、Microsoft Entra内のユーザー ID のサブタイプを表します。 これらの ID は、エージェント アプリケーションがユーザー ID が必要なコンテキストでアクションを実行できるように設計されています。 エージェントのユーザー アカウントは、非エージェント のサービス プリンシパルまたはアプリケーション ID とは異なり、要求 idtyp=userを持つトークンを受け取り、ユーザー ID を特に必要とする API とサービスにアクセスできるようにします。 また、非人間 ID に必要なセキュリティ制約も維持されます。
エージェントのユーザー アカウントは自動的に作成されません。 親エージェント ID に接続する明示的な作成プロセスが必要です。 この親子関係は、エージェントのユーザー アカウントがどのように機能し、Microsoft Entraで保護されているかを理解するための基礎となります。 確立されると、この関係は不変であり、エージェントのユーザー アカウントのセキュリティ モデルの基礎として機能します。 リレーションシップは 1 対 1 (1:1) のマッピングです。 各エージェント ID には、最大で 1 つのエージェントのユーザー アカウントを関連付けることができます。各エージェントのユーザー アカウントは、1 つの親エージェント ID にリンクされ、それ自体は 1 つのエージェント ID ブループリント アプリケーションにリンクされます。
エージェントのユーザー アカウント:
- また、エージェント ID ブループリントを使用して作成されます。
- 常に、作成時に指定された特定のエージェント ID に関連付けられます。
- エージェントの IDと は別に、固有の識別子を持ちます。
- 関連付けられているエージェント ID に発行されたトークンを提示することによってのみ認証できます。
エージェントのユーザー アカウントとエージェント ID の関係
エージェント ID ブループリントには、エージェントのユーザー アカウントを作成するための既定のアクセス許可がありません。これは、この機能は省略可能であり、必ずしも必要とは限らないためです。 これは、エージェント ID ブループリントに明示的に付与する必要があるアクセス許可です。
エージェントのユーザー アカウントは、エージェント ID ブループリントを使用して作成されます。 適切なアクセス許可が付与されると、エージェント ID ブループリントはエージェントのユーザー アカウントを作成し、特定のエージェント ID との親関係を確立できます。 エージェント ID は、エージェントのユーザー アカウントの親と見なされます。
管理者は、エージェントのユーザー アカウントのライフサイクルを管理します。 管理者ユーザーは、その機能が不要になったら、エージェントのユーザー アカウントを削除できます。
認証とセキュリティ モデル
エージェントのユーザー アカウントの認証モデルは、人間のユーザー アカウントと大きく異なります。
フェデレーション ID 資格情報: 認証は、エージェントのユーザー アカウントに割り当てられた資格情報によって行われます。 運用システムでは、フェデレーション ID 資格情報 (FIC) を使用します。 これらの資格情報は、エージェント ID ブループリントとエージェント ID の両方を認証するために使用されます。 ユーザーに割り当てられた資格情報は、エージェント エコシステム全体の認証に使用されます。
制限付き資格情報モデル: エージェントのユーザー アカウントには、パスワードなどの通常の資格情報がありません。 その代わり、親リレーションシップを通じて提供された資格情報の使用に限定されます。 資格情報に対するこの制限と対話型サインインの制限により、エージェントのユーザー アカウントを標準のユーザー アカウントのように使用できなくなります。
偽装メカニズム: 関連付けられているエージェント ID は、その子エージェントのユーザー アカウントを偽装できます。 これにより、親のビジネス ロジックはトークンを取得し、必要に応じてエージェントのユーザー アカウントとして機能できます。
エージェントのユーザー アカウントの機能
エージェントのユーザー アカウントには、Microsoft 365やその他の環境内で効果的に機能できる機能があります。
エージェントのユーザー アカウントは、動的グループを含むMicrosoft Entra グループに追加でき、それらのグループに付与されたアクセス許可を継承できます。 ただし、ロール割り当て可能なグループに追加することはできません。
エージェントのユーザー アカウントは、リソースにアクセスし、通常は人間のユーザー用に予約されている他の共同作業機能を利用できます。
エージェントのユーザー アカウントは、人間のユーザーと同様に、管理単位に追加できます。
エージェントのユーザー アカウントにはライセンスを割り当てることができます。多くの場合、Microsoft 365リソースをプロビジョニングするために必要です。
セキュリティの制約
エージェントのユーザー アカウントは、適切な使用を確保するために、特定のセキュリティ制約の下で動作します。
資格情報の制限: エージェントのユーザー アカウントは、パスワードやパスキーなどの資格情報を持つことができません。 サポートされている資格情報の種類は、親へのエージェント ID 参照のみです。 そのため、エージェントのユーザー アカウントがユーザーとして動作する場合でも、その資格情報は機密クライアント資格情報です。
管理ロールの制限: エージェントのユーザー アカウントに特権管理者ロールを割り当てることはできません。 この制限により、重要なセキュリティ境界が提供され、特権の昇格を防ぐことができます。
アクセス許可モデル: 通常、エージェントのユーザー アカウントにはゲスト ユーザーに似たアクセス許可があり、ユーザーとグループを列挙するための機能が追加されています。 エージェントのユーザー アカウントに特権管理者ロールを割り当てることはできません。 カスタム ロールの割り当てとロール割り当て可能なグループは、エージェントのユーザー アカウントでは使用できません。 詳細については、「
Microsoft Graph アクセス許可のリファレンス
Microsoft 365のエージェント ユーザー アカウントのプロビジョニング
メールボックス、Teams プレゼンス、人事システム統合などのデジタル ワーカー機能を使用してエージェントのユーザー アカウントを完全にプロビジョニングするには、Microsoft Teamsを使用してエージェントを作成します。 エージェント 365 とエージェント 365 SDK は、エージェント ユーザー アカウントがMicrosoft 365に完全に参加するための基盤を提供します。
Note
Microsoft Graph API を介してエージェントのユーザー アカウントを直接作成すると、Microsoft Entraで ID が確立されますが、Microsoft 365機能はプロビジョニングされません。 Graph APIアプローチは、Microsoft 365参加を必要としないシナリオにのみ使用します。
詳細については、Microsoft 365 エージェント SDKドキュメントを参照してください。