既存のAIエージェントをApp registration（アプリ登録）とサービスプリンシパルで認証している場合、今回の更新だけでエージェントが直ちに停止するわけではありません。ただし、Microsoft Entra Agent IDへの移行は既存登録の単純な変換ではなく、Agent BlueprintとAgent Identityを新規作成し、認証コード、API権限、Azure RBACを段階的に移す作業です。
移行時に壊れやすいのは、クライアントID、トークンの取得方法、アクセス許可、管理者同意、Azure RBAC、On-Behalf-Of（OBO）フローです。一方、移行後はAIエージェント単位の監査、条件付きアクセス、ライフサイクル管理、リスク検出を適用しやすくなります。公式ガイドも、旧IDと新IDを並行稼働させ、検証後に旧サービスプリンシパルを廃止する流れを推奨しています。(Microsoft Learn)
なお、公式GitHubでは2026年6月17日に対象ページを含む更新コミットが確認できますが、Microsoft Learn上の最終更新表示は2026年6月15日です。6月17日のコミットは「agent-id-metadata1」というメタデータ整理が中心で、この更新によって新たな強制移行日が設定されたわけではありません。(GitHub)
Microsoft Entra Agent IDへの移行で変わること
従来のApp registrationでは、アプリケーション登録とサービスプリンシパルがAIエージェントの実行IDとして使われます。しかし、この構成だけでは「どのエージェントが実行したのか」「誰がそのエージェントに責任を持つのか」といった、エージェント固有の管理情報を表現しにくい問題があります。
Microsoft Entra Agent IDでは、エージェントの設計情報を管理するAgent Blueprintと、実際のエージェントを表すAgent Identityを分けて管理します。Blueprintが資格情報や共通設定を持ち、各Agent IdentityはBlueprintとの関係を保ったまま個別のIDとして動作します。(Microsoft Learn)
| 確認項目 | 従来のApp registration | Microsoft Entra Agent ID | 移行時の影響 |
|---|---|---|---|
| ID構造 | アプリ登録とサービスプリンシパル | BlueprintとAgent Identity | 新しいクライアントIDが発行される |
| 資格情報 | アプリ登録にシークレットや証明書を設定 | 原則としてBlueprint側に設定 | 資格情報の設定先と参照先が変わる |
| トークン取得 | 1段階でアクセストークンを取得 | Blueprintでブートストラップトークンを取得し、Agent Identity用トークンへ交換 | 認証コードの変更が必要 |
| API権限 | 既存サービスプリンシパルに付与 | 新しいIDへ再設定 | 権限や管理者同意は自動移行されない |
| Azure RBAC | 既存サービスプリンシパルに割り当て | 新しいAgent Identityなどへ再割り当て | RBACの移し忘れでアクセス拒否が起きる |
| 管理責任 | 所有者を設定 | スポンサーが必須、所有者の設定も推奨 | 責任者を明確にする必要がある |
| 監査・統制 | 汎用的なワークロードIDとして記録 | エージェント単位のログ、条件付きアクセス、ライフサイクル管理 | 誰が何を実行したか追跡しやすくなる |
既存のApp registrationをAgent IDへインプレース変換する機能はありません。新旧IDを併存させ、依存関係を一つずつ切り替える必要があります。(Microsoft Learn)
誰が今回の移行ガイダンスを確認すべきか
直接影響を受けるのは、次の担当者です。
- 独自開発したAIエージェントのコードと認証設定を管理している開発者
- App registration、サービスプリンシパル、API権限を管理するEntra管理者
- 条件付きアクセスやIdentity Protectionを担当するセキュリティ管理者
- エージェントの所有者、スポンサー、運用責任者
- AzureリソースへのRBAC割り当てを管理するクラウド管理者
一般ユーザーが個別に設定を変更するケースは多くありません。ただし、移行中に権限やトークン設定を誤ると、ユーザーからは「エージェントが応答しない」「データを取得できない」「サインインに失敗する」といった障害に見えます。
このガイドの対象は、コードとIDを自社で管理するカスタムエージェントです。Microsoft Copilot Studioで作成したエージェントには別の移行ガイドが用意されているため、同じ手順をそのまま適用しないよう注意してください。(Microsoft Learn)
移行すると壊れやすいポイント
クライアントIDを差し替えるだけでは動かない
Agent Identityを作成すると、新しいクライアントIDが発行されます。しかし、設定ファイルのクライアントIDだけを置き換えても、認証処理は完了しません。
自律型エージェントでは、まずBlueprintの資格情報を使ってブートストラップトークンを取得し、そのトークンをAgent Identity用のアクセストークンへ交換します。従来の1段階のクライアント資格情報フローを残したままでは、トークンの対象リソースや発行先が合わず、認証エラーになる可能性があります。(Microsoft Learn)
API権限と管理者同意は自動で引き継がれない
旧サービスプリンシパルにMicrosoft GraphなどのAPI権限が付与されていても、新しいIDへ自動的にコピーされるわけではありません。
移行時は、少なくとも次の情報を照合します。
- 委任されたアクセス許可
- アプリケーションのアクセス許可
- カスタムAPIのスコープ
- 管理者同意の有無
- アプリロールの割り当て
- 対象リソース側で設定した許可リスト
権限を追加しただけで管理者同意を実施していない場合、トークンは取得できてもAPI呼び出しが403エラーになることがあります。(Microsoft Learn)
Azure RBACはAPI権限とは別に移す
Azure Key Vault、Storage、Azure OpenAIなどへのアクセスにAzure RBACを使っている場合、Microsoft GraphのAPI権限だけを確認しても不十分です。
旧サービスプリンシパルに割り当てられているロールを一覧化し、新しいIDへ必要最小限のロールを再割り当てします。移行を機に権限を整理する場合でも、いきなり削除するのではなく、実際の利用ログと照合してから縮小するのが安全です。(Microsoft Learn)
対話型エージェントはOBOフローも変更する
ユーザーとしてAPIへアクセスする対話型エージェントでは、OBOフローの確認が必要です。Blueprint側でカスタムスコープを公開し、フロントエンドが要求するトークンのリソースも更新します。
バックエンドだけをAgent IDへ変更し、フロントエンドが旧App registration向けのトークンを送り続けると、スコープ不足や対象リソースの不一致が発生します。(Microsoft Learn)
資格情報の配置を間違えると認証できない
資格情報は個々のAgent Identityではなく、原則としてBlueprint側で管理します。
公式ガイドでは、Azure上の本番環境にはユーザー割り当てマネージドID、Azure外の環境には外部IDプロバイダーとのフェデレーションを推奨しています。オンプレミスなどでフェデレーションを利用できない場合は証明書を優先し、クライアントシークレットはローカル開発や限定的なテスト用途に留めるのが安全です。(Microsoft Learn)
フェデレーション資格情報を使う場合は、issuer、subject、audienceのいずれかが一致しないだけでもinvalid_grantが発生します。文字列を手入力で管理せず、IaCや構成管理に組み込むと設定差異を防ぎやすくなります。
作成直後のIDをすぐ参照すると失敗することがある
Microsoft GraphでBlueprintやAgent Identityを作成した直後は、ディレクトリ内の反映に時間がかかり、後続処理で「オブジェクトが見つからない」というエラーが返る場合があります。
公式ガイドでは、30～60秒待って再試行する方法が案内されています。自動化スクリプトには固定待機だけでなく、指数バックオフを使ったリトライ処理を入れておくと安定します。(Microsoft Learn)
Microsoft Entra Agent IDへ移行すると改善すること
エージェント単位で操作を追跡できる
複数のエージェントが同じApp registrationを共有している構成では、ログを見ても、どのエージェントが操作したのか判断しにくくなります。
Agent Identityを分けることで、サインインログや監査ログをエージェント単位で確認しやすくなります。インシデント発生時の調査だけでなく、不要な権限や利用されていないエージェントの発見にも役立ちます。(Microsoft Learn)
条件付きアクセスをAIエージェントへ適用しやすい
Agent IDでは、エージェントのリスクや実行条件に応じた条件付きアクセスを設計できます。たとえば、許可していない場所やネットワークからのアクセスをブロックする、リスクの高いIDを停止するといった制御を組み込みやすくなります。
ただし、Agent IDを作成しただけで保護が自動的に完成するわけではありません。対象ID、除外条件、レポート専用モード、ブロック時の復旧手順を設計し、段階的にポリシーを有効化する必要があります。(Microsoft Learn)
所有者とスポンサーを明確にできる
Agent Identityではスポンサーが必須で、所有者の設定も推奨されています。これにより、エージェントの利用目的や責任者が分からない「野良エージェント」を減らしやすくなります。
スポンサーには、エージェントの業務上の必要性を判断できる担当者を設定します。技術担当者だけを登録すると、異動や退職の際に判断できる人がいなくなるため、業務部門とIT部門の両方を運用に関与させるのが実用的です。(Microsoft Learn)
ライフサイクル管理を標準化できる
Agent IDでは、登録、承認、運用、停止、削除というライフサイクルをエージェント向けに整理できます。
有効期限、定期レビュー、所有者不在時の対応、利用終了後の削除手順を定めておけば、App registrationだけが残り続ける状態を防げます。特に、検証用エージェントを大量に作る組織では効果が大きい改善点です。(Microsoft Learn)
失敗しにくい移行手順
既存エージェントを棚卸しする
最初に、移行対象を推測で選ばず、アプリ登録とサービスプリンシパルを一覧化します。
確認する情報は次のとおりです。
- 表示名、アプリケーションID、オブジェクトID
- 所有者と業務責任者
- 直近30日、90日、180日のサインイン状況
- API権限と管理者同意
- アプリロールとAzure RBAC
- シークレット、証明書、フェデレーション資格情報
- リダイレクトURI
- OBOフローの有無
- 外部システムやCI/CDからの参照
- 構成ファイル、環境変数、Key Vault内の旧クライアントID
Microsoft GraphのapplicationsとservicePrincipalsを使えば、棚卸しの一部を自動化できます。ただし、名前やタグだけでAIエージェントと判定すると誤検出するため、コード、利用ログ、所有者への確認も組み合わせます。(Microsoft Learn)
リスク別に移行方法を分ける
| 区分 | 目安 | 移行方法 |
|---|---|---|
| 低リスク | 利用実績がなく、権限や依存関係もほぼない | 削除候補として確認し、不要なら移行しない |
| 中リスク | 定期実行され、依存先が把握できている | テスト環境で移行後、短期間の並行稼働を行う |
| 高リスク | 業務クリティカル、多数のユーザーが利用、権限が広い | 段階的なトラフィック切り替え、ロールバック、関係者承認を必須にする |
「30日間サインインがない」という理由だけで不要と判断するのは危険です。月次処理、四半期処理、障害時だけ動くエージェントもあるため、ジョブスケジュールや外部ログまで確認してください。公式ガイドでも、30日という基準はログ保持期間を踏まえた出発点として扱われています。(Microsoft Learn)
BlueprintとAgent Identityを作成する
移行作業では、最初にAgent Blueprintを作成し、資格情報を設定します。その後、Blueprintのサービスプリンシパルを準備してからAgent Identityを作成します。
Agent Identityにはスポンサーを必ず設定し、所有者も登録します。作成後は、Blueprint ID、Agent IdentityのクライアントID、オブジェクトIDを構成管理へ記録してください。(Microsoft Learn)
ガイド内にはMicrosoft Graphのベータエンドポイントを使う例も含まれます。自動化する場合は、実装時点のAPIバージョン、SDK対応状況、必要なロールを公式ドキュメントで再確認し、先に検証環境でテストすることが重要です。(Microsoft Learn)
権限とコードを移す
次に、旧サービスプリンシパルの権限を新しいIDへ再設定します。
- Microsoft GraphなどのAPI権限を付与する
- 必要な管理者同意を実施する
- アプリロールを再割り当てする
- Azure RBACを再割り当てする
- OBOフローのスコープと対象リソースを更新する
- トークン取得処理を2段階フローへ変更する
- 構成ファイルやシークレットストアのIDを更新する
旧IDの権限をそのまま複製するだけでなく、本当に必要な権限かを確認します。ただし、権限縮小とID移行を同時に行うと障害原因を切り分けにくくなるため、重要システムでは「同等権限で移行」「安定後に権限を縮小」の二段階に分ける方法が安全です。
並行稼働で動作を確認する
検証では、トークンを取得できたかだけでなく、実際の業務処理まで確認します。
- すべてのAPI呼び出しが成功するか
- Azureリソースへアクセスできるか
- サインインログにAgent Identityが記録されるか
- 条件付きアクセスポリシーが意図どおり動くか
- OBOフローでユーザー権限が維持されるか
- リトライや長時間実行でも問題が起きないか
- 旧IDへ戻せる機能フラグが用意されているか
利用量の多いエージェントでは、まず新IDへ5～10％程度のトラフィックを流し、1～2週間かけて比率を引き上げる方法が公式ガイドで示されています。(Microsoft Learn)
旧サービスプリンシパルを廃止する
新IDの安定稼働を確認した後、旧サービスプリンシパルを停止します。
いきなり削除せず、最初に資格情報を無効化し、旧IDへのサインインやAPI呼び出しが残っていないか監視します。問題がなければ、設定、権限、RBAC、所有者、依存関係をエクスポートしてから削除します。
大量に移行する場合は20～50件程度のバッチに分ける方法が案内されています。削除したオブジェクトには30日間の論理削除期間がありますが、これは復旧可能期間であり、移行期限ではありません。(Microsoft Learn)
設定・更新・料金・期限で確認すべきこと
| 項目 | 確認内容 |
|---|---|
| 設定 | Blueprint、Agent Identity、スポンサー、所有者、資格情報、API権限、管理者同意、Azure RBAC、OBOスコープ |
| 管理ロール | Agent ID DeveloperまたはAgent ID Administrator、必要に応じてPrivileged Role Administrator |
| 更新情報 | Microsoft Learnの更新日だけでなく、Microsoft GraphのAPIバージョンやSDK対応状況も確認 |
| 料金・ライセンス | Agent IDの基本利用と、条件付きアクセス、Identity Protection、ID Governanceなどの追加機能を分けて確認 |
| 移行期限 | 今回のガイドにはApp registrationの停止日や強制移行期限の記載はない |
| 削除期限 | 30日間の論理削除は復旧期間であり、製品の移行期限ではない |
Microsoft Entra Agent ID自体はEntraの顧客向けに提供されていますが、Microsoft 365のサービスやワークフローでAgent 365を利用する場合はユーザー単位のライセンスを確認する必要があります。高度な条件付きアクセスにはEntra ID P1、Identity ProtectionにはP2など、利用する保護機能によって必要なライセンスが異なります。Microsoft 365 E7、またはMicrosoft 365 E5とAgent 365の組み合わせも含め、自社が実際に使用する機能を基準に見積もることが重要です。(Microsoft Learn)
価格は契約形態、地域、既存プランによって変わる可能性があります。固定価格だけを記事や設計書へ転記するのではなく、購入時点の公式価格と契約条件を確認してください。
まず実施すべきこと
今回の更新を見て、すべてのApp registrationを急いで削除する必要はありません。最初に行うべきなのは、既存AIエージェントと依存関係の棚卸しです。
そのうえで、影響範囲を把握しやすい低～中リスクのエージェントを1つ選び、次の順序で試験移行します。
- BlueprintとAgent Identityを作成する
- 資格情報、API権限、管理者同意、Azure RBACを設定する
- 2段階のトークン取得フローへコードを変更する
- 新旧IDを並行稼働させる
- API、ログ、条件付きアクセスを確認する
- ロールバック可能な状態で新IDへ切り替える
- 旧IDへのアクセスがないことを確認してから削除する
Microsoft Entra Agent IDへの移行で重要なのは、IDを置き換えること自体ではありません。AIエージェントごとに責任者、権限、実行履歴、停止手順を明確にすることが本来の目的です。まず1件のパイロット移行で自社向けの手順を固め、その結果をテンプレート化してから全体へ展開するのが、障害と手戻りを最も抑えやすい進め方です。
コメント