Agent 365は、各エージェントを異なるエージェントIDで表現するためにMicrosoft Entra エージェント IDを使用します。 エージェントのアイデンティティは、servicePrincipalTypeがServiceIdentity、@odata.typeが#microsoft.graph.agentIdentityに設定されたMicrosoft Entraサービスプリンシパルです。 管理者は、条件付きアクセス、権限付与・同意、ライフサイクル操作など、Microsoft Entraの他の場所で使われているのと同じテナントコントロールでエージェントIDを管理します。
同一性オブジェクト
モデルは3つの物体で構成されています。 すべてのエージェントが3つすべてを使うわけではありません。
| オブジェクト | Description |
|---|---|
| エージェント ID ブループリント | Microsoft Entra IDのテンプレートで、エージェントの種類を定義しています。 認証情報、宣言された権限、継承可能な権限、認証済みの出版社、そしてアプリの役割を保持しています。 一つの設計図で多くのエージェントのアイデンティティを作成できます。 Microsoft Entraでアプリケーションがどのように登録されるかの背景については、「Microsoft ID プラットフォームでアプリケーションを登録する」をご覧ください。 |
| エージェント識別子 | 個人エージェントが運営するアカウントです。 独自のオブジェクトID、表示名、スポンサー、権限割り当てがあります。 |
| エージェントのユーザー アカウント | Microsoft Entraユーザーアカウントが必要な場合のみ作成されるオプションのセカンドアカウントです。 ライセンスやメールボックスなどのMicrosoft 365リソースを保持できます。 フロンティアプレビュープログラムに参加しているテナントのみが利用可能です。 エージェントのアイデンティティは、エージェントのユーザーアカウントが0つまたは1つあり、各エージェントのユーザーアカウントは正確に1つのエージェントIDに属します。 |
設計図とエージェントの関係
テナント内では、標準的なアプリケーション登録は通常、サービスプリンシパルと一対一の関係を持っています。 エージェントモデルは一対多で、1つの設計図がテナント内の複数のエージェントIDに関連付けられます。
各エージェントのアイデンティティは設計図からプロトコルのプロパティを継承し、独自の下流権限を保持できます。 同じ種類のエージェント同士がブループリントを共有するため、管理者は条件付きアクセスポリシーを適用したり、権限付与を取り消したり、その種のすべてのエージェントを一度の操作で無効化したりできます。
エージェントのアイデンティティは単一テナントであり、作成されたテナント内でのみトークンを発行できます。 設計図はマルチテナント(複数テナント)で使えます。 こうして公開エージェントがカスタマーテナントに追加され、その設計図から独自のテナント・ローカルエージェントIDが作成されます。
資格情報
エージェントは自身のエージェントIDを使って認証しますが、アイデンティティ自体は認証情報を保存しません。 設計図上で認証情報を設定し、設計図はそれを使ってその設計図から作成されたエージェントIDのトークンを取得します。
設計図上でサポートされている資格の種類:
- フェデレーテッド ID 資格情報
- 証明書と暗号鍵
- クライアント シークレット
Azure上で動作するエージェントの場合、ブループリントをAzure管理IDにフェデレートさせることができ、ブループリントに秘密が保存されません。
ブループリント認証情報は、そのブループリントから作成されたすべてのエージェントIDで共有されます。 各設計図を認証情報の境界として扱い、認証情報と継承されたベースライン権限を安全に共有できるアイデンティティのみをグループ化してください。
エージェントのアイデンティティはパスワード、SMS、パスキー、認証アプリで認証されないため、多要素認証は適用されません。 代わりに条件付きアクセスポリシーで管理しましょう。
エージェントのユーザー アカウント
一部のエージェントはMicrosoft Entraユーザーアカウントを必要とするシステムにアクセスする必要があります。 その場合は、エージェントに2つ目のアカウントを与え、ディレクトリでAIエージェントとしてマークすることができます。
ユーザーアカウントと適切なライセンスを使えば、エージェントはメールボックスやOneDriveのストレージを持ち、ディレクトリや組織のメタデータに表示され、Teams、Outlook、Wordコメント、メールを通じて連絡が取れます。
エージェントがユーザーアカウントを必要とした場合のみ追加してください。 テレメトリーと呼び出しツールのみを発信するエージェントは通常、必要ありません。
Important
独自のユーザーアカウントを持つエージェントは、 Frontierプレビュープログラムに参加しているテナントのみが利用可能です。
権限とランタイムフロー
エージェントは3つの実行モードで動作可能です。 このモードは、エージェントが誰のために行動するか、下流通話に登場するトークン主体、必要な権限と同意を決定します。
| 実行モード | Description |
|---|---|
| S2S(サービス間) | エージェントはユーザーコンテキストを持たず、自身のエージェントアイデンティティとして動作します。 このモードはスケジュールされたタスク、監視、バックグラウンド処理に使用してください。 アプリケーション権限を使用し、エージェントの識別子がトークン主体となります。 基礎となるOAuthパターンについては、 OAuth 2.0クライアント認証付与を参照してください。 |
| OBO(代理) | エージェントはサインインした人間のユーザーのコンテキストを受け取り、そのユーザーのために行動します。 アクセスがユーザーの身元や権限に依存する場合にこのモードを使用します。 委任された権限を使用します。ユーザーはトークン主体であり、エージェントのアイデンティティはアクターです。 実装の詳細については、 OAuth 2.0 On-Behalf-Of flowを参照してください。 |
| エージェントユーザー | エージェントは独自のMicrosoft Entraユーザーアカウントで動作し、そのアカウントとして機能します。 このモードはFrontierプレビュープログラムを必要とし、エージェントがユーザーリソースやメールボックス、Teamsプレゼンス、WordやOutlookのやり取りなどユーザーベースのMicrosoft 365体験を必要とする場合に使用されます。 エージェントのユーザーアカウントが代理ユーザーであり、エージェントのアイデンティティは登録されたエージェント365のアイデンティティのままです。 |
例えば、夜間のバックグラウンド処理は通常S2Sを使用します。チャット内のユーザー固有の操作はOBOを使用します。エージェント自身のメールボックスを読み取る場合はAgentic-Userを使用します。 権限モデルと実行時モードは関連していますが、互換性のある用語ではありません。まずモードを選択し、その後、アプリケーションやダウンストリームリソースが要求する委任権限と同意を確認します。
モードを実装する前に、あなたの完全な構成が以下の操作をサポートしているかを確認してください:
- エージェントが操作を行うべき人物を特定します:エージェントのアイデンティティ、サインイン済みユーザー、または自身のユーザーアカウント。
- 選択したモードがそのアカウントコンテキストとターゲットAPIやリソースに必要な権限タイプをサポートしているか確認してください。
- 必要なスコープと同意を付与し、ライセンスやプロビジョニングされたユーザーリソースなどの追加の前提条件を満たします。
選択したモードで対応していない要件がある場合は、別のモードや操作を選択してください。 Microsoft Graphのスコープについては、Microsoft Graph権限の参照を参照してください。
エージェントに必要な権限が分かったら、どこに割り当てるか決めましょう。 ブループリント上で共有のベースライン権限を宣言し、そこから作成されたすべてのエージェントIDが継承できるようにします。また、アクセスがそのエージェント固有の場合は、直接そのエージェントIDに権限を割り当てます。 Azure role-based access control(RBAC)は例外です。ブループリントはAzureのRBACロールを保持できないため、それらの役割を各エージェントのアイデンティティに直接割り当ててください。 エージェントのアイデンティティはMicrosoft Entraの組み込みロールを保持することも可能です。
Important
ブループリントに権限を宣言しても、許可は与えられません。 管理者は、設計図の主要者または個々の代理人の身元について同意しなければなりません。
スポンサーと監査
各エージェントのアイデンティティおよびエージェントアイデンティティ設計図には、少なくとも1人のスポンサーが必要です。それは、エージェントの目的とライフサイクルに責任を持つビジネス担当者です。 スポンサーはエージェントを保持するか無効化するかを判断するよう求められ、セキュリティチームはスポンサーを使ってインシデント時に責任ある担当者に連絡を取ることもあります。
サインインログと監査ログは、設計図、エージェントの識別、エージェントのユーザーアカウントを区別します。 レビュアーは資格情報の出典、代理身分、トークン主体を特定できます。 S2S操作では、エージェントのアイデンティティがトークン主体となります。 OBO操作では、サインインしたユーザーが主体、エージェントの識別子がアクターとなります。
設定する内容
エージェントをAgent 365に導入すると、Microsoft EntraでエージェントIDブループリントを登録し、そこからエージェントIDを作成します。
make-a365-agentスキルは標準エージェントパスの両方のステップを実行します。 AIの味方ルートでは、 make-ai-teammate がそれを実行します。 クイック スタート:既存のエージェントをエージェント365に接続する。
始める前に以下の項目を決めてください:
| アイテム | Description |
|---|---|
| 設計図はいくつあるか | 認証情報の境界ごとに1つのブループリントを使う。 安全に認証情報や継承された基本権限を共有できないエージェントには別々の設計図を使う。 |
| どの許可モデルか | 申請権限、委任権限、またはその両方です。 |
| エージェントがユーザーアカウントを必要とするかどうか | メールボックス、Teamsプレゼンス、または組織ディレクトリのプロフィールが必要な場合のみ。 |
| スポンサーは誰か | 各設計図とエージェントのアイデンティティには、少なくとも1人のスポンサーが必要で、それはユーザーまたはグループであっても構いません。 |