Microsoft Entra エージェント ID には、新しい ID コンストラクトと、既存の認証と承認のパターンに関する新しい考え方が導入されています。 これらのコンストラクトがどのように一緒に適合するかを理解するには、一般的な AI エージェントのデプロイ パターンと、それらが Microsoft Entra エージェント ID にどのようにマップされるかを確認すると便利です。
この記事では、一般的な AI エージェントのデプロイ パターンと、それらが Microsoft Entra エージェント ID にどのようにマップされるかについて説明します。 この記事では、まず、主要な ID の概念を確認し、アクセス許可と信頼の境界について説明した後、一般的なデプロイ パターンについて説明します。
作成するブループリントとエージェント ID の数に関する詳細な決定ガイダンスについては、「 エージェント ID アーキテクチャの計画」を参照してください。
主な概念
Microsoft Entra エージェント ID の基盤となるコンポーネントを次に示します。 初めて使用する場合は、この記事に進む前に 、Microsoft Entra エージェント ID の主要な概念 から始めてください。
アイデンティティ コンストラクト
この記事で説明するパターン全体で、次の ID コンストラクトが使用されます。
- エージェント ID ブループリント: 1 つ以上のエージェント ID のテンプレートと認証基盤。 資格情報とポリシーが保持され、そこから作成されたすべてのエージェント ID に適用されます。
- エージェント ID ブループリント プリンシパル: ブループリントがテナントに追加されたときに作成された Microsoft Entra オブジェクト。 実際にトークンを取得し、エージェント ID を作成し、ブループリントに代わって監査ログに表示されます。
- エージェント ID: ダウンストリーム リソースに対する独自のアクセス許可を持つ、特定の AI エージェントのランタイム ID。
- エージェントのユーザー アカウント: エージェント ID とペアになったオプションの 1:1 アカウント。エージェントがユーザー オブジェクトを必要とするシステムにアクセスする必要がある場合にのみ必要です。
アクセス許可モデル
ブループリント レベルのアクセス許可とエージェント ID レベルのアクセス許可は、さまざまな目的に役立ちます。
- ブループリントのアクセス許可 は、ブループリントから作成されたすべてのエージェント ID で共有される最小限のアクセス許可を表します。 すべてのエージェント ID を共通のベースラインで開始する場合は、ブループリントで継承可能なアクセス許可を使用します。
- エージェント ID のアクセス許可は、 特定のエージェントに対する差別化されたアクセス許可を表します。 これらのアクセス許可は、同じシステム内の異なるエージェントがダウンストリーム リソースへの異なるアクセスを必要とする場合に使用します。
詳細については、「Microsoft Entra エージェント ID でブループリントと承認の継承可能なアクセス許可を構成する」を参照してください。
信頼境界
信頼境界とは、1 つの侵害が境界全体に影響すると見なされる共有リスク サーフェスを指します。 個別のサービス アカウント、シークレット、およびネットワーク セグメントを持つ個別のプラットフォームで実行されているエージェントは、信頼境界を共有しません。
信頼境界はアプリケーションの脅威モデリングの決定であり、Microsoft Entra エージェント ID によって定義されるものではありません。
デプロイ パターン
次のパターンは、実際のエージェントのデプロイに基づいています。 各エージェント アーキテクチャ、その ID 構造、および関連するアクセス許可とガバナンスに関する考慮事項について説明します。
ローコード シングルトン エージェント
特定のタスクを支援する 1 つのエージェント。通常は、Microsoft Copilot Studio のような低コードまたはコードなしのプラットフォーム上に構築されます。 エージェントは、常にサインインしているユーザーの代わりに動作するか (対話型)、または常にそれ自体 (自律的) として機能します。
構造： 1 つのブループリント→ 1 つのエージェント ID
単一のエージェント ID を持つブループリントは冗長に見えるかもしれませんが、このブループリントはエージェントに一貫した条件付きアクセス ポリシー、監視、ガバナンス、監査エントリを提供します。これは、マルチエージェント システムに必要なインフラストラクチャと同じで、最小限のセットアップで実現します。
アクセス 許可： エージェント ID に直接アクセス許可を付与します。 ブループリントの継承可能なアクセス許可は、通常、シングルトン ケースでは必要ありません。
エージェントのユーザー アカウント: エージェントが Exchange、Teams、またはユーザー オブジェクトを必要とする別のシステムにアクセスする必要がある場合を除き、必須ではありません。
ドメイン ワーカー (シーケンシャル マルチエージェント)
複数のエージェントが緊密に結合されたシーケンシャル ワークフローで連携し、共通のドメイン目標に対応します。 通常、エージェントはコードベースを共有し、同じランタイム環境 (たとえば、同じ Kubernetes 名前空間またはコンテナー) で実行され、同じセキュリティ体制を持ちます。 各エージェントには、個別の責任があり、ダウンストリーム リソースへのアクセスが異なります。 このパターンは、マルチエージェント設計の シーケンシャル オーケストレーション にマップされます。
構造： 1 つのブループリント→複数のエージェント ID (エージェント ロールごとに 1 つ)
ここでは、すべてのエージェントが同じ信頼境界を共有するため、1 つのブループリントを使用することが適切です。 各エージェントは、監査ログとサインイン ログでアクションを特定のエージェントに属性付けできるように、独自のエージェント ID を取得し、各エージェントがダウンストリーム リソースに対して異なるアクセス許可を保持できるようにします。
例: 小売製品管理システムには、店舗在庫、製品比較、仕入先在庫の 3 つのエージェントがあります。 3 つすべてが同じ Kubernetes 名前空間で実行され、同じチームによってビルドされます。 3 つのエージェント ID を持つ 1 つのブループリントを使用し、それぞれが独自のリソースをスコープとするアクセス許可を持ちます。
アクセス 許可： ブループリントで共有ベースラインのアクセス許可を継承可能として設定します。 ロール固有のアクセス許可を各エージェント ID に直接割り当てます。
エージェントのユーザー アカウント: 通常、ドメイン ワーカー エージェントには必要ありません。
ドメイン ワーカーとの同時オーケストレーター
オーケストレーター エージェントは、受信タスクに基づいて異なるドメイン ワーカーを動的にアクティブ化します。 ドメイン ワーカーは、異なるプラットフォームで実行され、異なるチームによって運用され、信頼境界を越える場合があります。 このパターンは、マルチエージェント設計の 同時実行オーケストレーション にマップされます。
構造：
- ブループリント A → オーケストレーター エージェント アイデンティティ
- ブループリント B → ドメイン ワーカー エージェント 用の ID (ロールごとに 1 つ、信頼境界を越えるグループ)
- ブループリント C →別のドメイン ワーカー グループ (別のチームまたはプラットフォームによって運用されている場合)
ドメイン ワーカーは信頼の境界を越えるため (個別のランタイム、シークレット、またはチーム)、個別のブループリントが必要です。 ブループリントの資格情報は、その信頼ドメインに特化しているため、あるドメインにおける侵害がピアエージェントに影響を与えることはありません。
エフェメラル エージェント ID: このパターンのバリアントでは、エフェメラル エージェント ID が使用されます。 オーケストレーターは、特定の対話 (メンテナンス サブシステムとの調整など) を容易にするために実行時に一時エージェント ID を作成し、ブループリントから継承されたアクセス許可を付与し、セッションの終了時に ID を削除します。 これにより、ブラスト半径がタスクの期間に制限されます。
注
エフェメラル エージェント ID の作成は実行時に行われます。これにより、非決定的な待機時間が発生します。 待機時間が影響を受けやすいシナリオで、このトレードオフを評価します。
アクセス 許可： オーケストレーターと各ドメイン ワーカー グループには、それぞれのブループリントとエージェント ID をスコープとする独自のアクセス許可セットがあります。
エージェントのユーザー アカウント: 特定のドメイン ワーカーがユーザー オブジェクト依存リソースにアクセスする必要がある場合を除き、通常はオーケストレーターまたはドメイン ワーカー レベルでは必要ありません。
ユーザーごとのエージェント (small-n)
ユーザーまたは組織単位ごとに個別のエージェント ID が作成されます。 たとえば、SOC アナリスト エージェントには、クラウド環境ごとに 1 つのインスタンスがある場合や、監査エージェントに部門ごとに 1 つのインスタンスがある場合があります。 エージェント ID の数は、ディレクトリ ユーザーごとに 1 つではなく、中程度 (数十から数百) です。
構造： ユーザー、部門、または環境ごとに 1 つのエージェント ID を→する 1 つのブループリント
このパターンは、各エージェント インスタンスに異なるアクセス許可、異なる監査境界、または独立したライフサイクルが必要な場合に適しています (たとえば、部門のエージェントを他のユーザーに影響を与えずに無効にすることができます)。
アクセス 許可： 各エージェント ID には、そのユーザーまたは組織単位をスコープとするアクセス許可が保持されます。 ブループリントから継承可能なアクセス許可は最小ベースラインを設定し、各エージェント ID には必要に応じて追加のアクセス許可が付与されます。
エージェントのユーザー アカウント: 各エージェントがユーザーまたは部門の名前付き担当者 (たとえば、担当地域に代わって電子メールを受信する専用のセールス エージェント) として機能する場合は、各エージェント ID をエージェントのユーザー アカウントとペアリングすることを検討してください。
デジタルワーカー(完全自律エージェント)
完全に自律的なエージェントは、デジタル従業員として機能し、通常は人の従業員のために予約されたリソース (Exchange メールボックス、OneDrive 共有、Teams プレゼンス) でプロビジョニングされます。 これはエージェントの自律性の最高レベルです。
構造： 1 つのブループリント→ 1 つのエージェント ID→ 1 つのエージェントのユーザー アカウント
各デジタル ワーカーには、独自のエージェントのユーザー アカウントが必要です。 エージェント ID とエージェントのユーザー アカウントの間の 1 対 1 の関係は固定されています。複数のエージェント ID 間でエージェントのユーザー アカウントを共有することはできません。
例: 電子メールに応答し、組織図に人間のマネージャーが割り当てられる、実際のメールボックスを持つ AI 営業担当者 (グローバル アドレス一覧にリストされています)。
アクセス 許可： エージェントのユーザー アカウントに、必要な特定の Exchange、Teams、および OneDrive のアクセス許可を付与します。 ユーザー オブジェクトを必要としないシステムに対して、エージェント ID アプリケーション レベルのアクセス許可を付与します。 詳細については、「 エージェントに Microsoft 365 へのアクセスを許可する」を参照してください。
エージェントのユーザー アカウント: 必須。 デジタル ワーカー エージェント ID ごとに 1 つのエージェントのユーザー アカウントを作成します。
回避するパターン
スケールアウト レプリカに個別のエージェント ID は必要ありません
同じエージェント コード (スケールアウト) の複数のインスタンスを実行する場合、個別のエージェント ID は必要ありません。 スケールアウトはランタイムの問題です。ブループリントはエージェント ID としてトークンを取得し、エージェントの複数のインスタンスはすべて同じ ID で同時に実行できます。 レプリカごとに個別のエージェント ID を作成すると、監査、アクセス制御、またはアカウンタビリティの利点なしに、ディレクトリ オブジェクトと管理オーバーヘッドが追加されます。
メモリとコンテキストの管理では、個別のエージェント ID は必要ありません
エージェント メモリは通常、共有データ ストア (Azure Cache for Redis や Azure AI 検索 など) であり、取得時にセッション ID でデータがフィルター処理されます。 そのデータ ストアへのアクセスは、セッションごとに個別の ID ではなく、エージェント ID のアクセス許可によって制御されます。 メモリ分離用にエージェント ID を分離すると、セキュリティ上の利点なしに複雑さが増します。
ディレクトリでスケールされたオブジェクトごとのエージェント ID を使用しない
現在、大量の会議、ドキュメント、または一時オブジェクトごとに 1 つのエージェント ID を作成することは、ディレクトリ レベルの ID では実用的ではありません。 高フラックスのシナリオでは、共有エージェント ID を使用し、アプリケーション 層のセッションまたはコンテキスト識別子に依存して相互作用を区別します。