Microsoft Entra / agentic identityの2026年4月更新で最初に押さえるべき結論は、AIエージェントのID管理が「アプリ登録やAPIキーの延長」ではなく、MCP、A2A、OAuth、SPIFFEをまたぐ標準ベースのenterprise identity architectureとして整理され始めたことです。Microsoftは2026年4月24日の公式記事で、agentic identityの標準化における重要テーマを、信頼のブートストラップ、委任、共有シークレットからの脱却として説明しています。(TECHCOMMUNITY.MICROSOFT.COM)
セキュリティ管理者、ID管理チーム、コンプライアンス担当者が今すぐ確認すべきことは明確です。自社に存在するAIエージェントを棚卸しし、「誰の代わりに」「どの権限で」「どのMCPサーバーやA2Aエンドポイントに」「どのトークンや資格情報で」アクセスしているかを可視化してください。特にAPIキー、PAT、長期クライアントシークレットに依存したPoCは、本番化の前にOAuth、Microsoft Entra認証、マネージドID、フェデレーションID資格情報などへ移行する余地を確認する必要があります。
Microsoft Entra / agentic identityの2026年4月更新ポイント
今回のMicrosoft公式記事は、単なる製品アップデートというより、AIエージェント時代のID標準をどう見るべきかを示した「設計方針」の更新です。Microsoft Entra Agent IDそのものはMicrosoftの管理・ガバナンス基盤ですが、記事の主眼はさらに広く、MCP、A2A、OAuth、SPIFFEなどの標準がエージェントIDの土台になるという見方にあります。(TECHCOMMUNITY.MICROSOFT.COM)
| 更新ポイント | 何が重要か | 管理者が取るべき行動 |
|---|---|---|
| MCP、A2A、OAuth、SPIFFEをagentic identityの中核として整理 | AIエージェントの接続先、委任、認証、ワークロードIDを個別に扱わず、標準群として設計する必要がある | MCPサーバー、A2Aエンドポイント、OAuthフロー、ワークロードIDの関係図を作る |
| 非人間IDの前提が変わった | 従来のサービスプリンシパルやワークロードは予測可能だったが、AIエージェントは推論して選択・委任する | 「自律実行」と「ユーザー代行」を分けて権限設計する |
| 信頼のブートストラップが重要になった | エージェントやリソースが自動的に自己情報を公開し、信頼関係を確立する場面が増える | メタデータ公開、認可サーバー検出、承認済み発行元の管理を整備する |
| 委任の設計が未成熟な領域として強調された | OBO、トークン交換、アップスコープ、ダウンスコープなどの議論が続いている | ユーザー委任トークンとエージェント自体の権限を混ぜない |
| 共有シークレットのリスクが強調された | APIキーやBearerトークンの乱用が、エージェント環境で拡大しやすい | 長期シークレットの使用箇所を棚卸しし、短命トークンや証明可能なIDへ移行する |
Microsoftが示した最も大きなメッセージは、「エージェントは人間でも従来型アプリでもない」という点です。人間ならMFAや同意、アプリなら固定的なサービスプリンシパルやクライアント資格情報で設計できます。しかし、AIエージェントは人間の依頼を受けて動くことも、自律的に別のエージェントやツールを呼び出すこともあります。この中間的な性質が、既存のIAM設計を難しくしています。
なぜ今、agentic identityが重要になったのか
従来のID管理では、主な対象は人間ユーザー、アプリケーション、ワークロードでした。人間ユーザーはパスワードレス認証やMFAで本人性を確認し、アプリケーションはサービスプリンシパルや証明書、ワークロードはマネージドIDやSPIFFEのような仕組みで扱います。
一方、AIエージェントは「判断して行動するソフトウェア」です。Microsoft Learnでは、エージェントを、環境やコンテキストを理解し、意思決定し、ツールを使って目標達成を試みるアプリケーションとして説明しています。また、エージェントIDはAIエージェントに固有のIDと認証機能を提供するMicrosoft Entra ID内のIDアカウントとされています。(Microsoft Learn)
ここで問題になるのは、アクセスの説明責任です。
たとえば、営業支援エージェントがCRM、SharePoint、メール、社内ナレッジ、外部SaaSを横断して提案書を作る場合、監査ログでは次の違いを区別できなければなりません。
| ログで区別すべき主体 | 例 | 区別しない場合のリスク |
|---|---|---|
| 人間ユーザー | 田中さんが営業資料を開いた | 通常のユーザー操作として扱える |
| AIエージェント | 営業支援エージェントが資料を検索した | 誰が指示したか、どの範囲で許可されたかが不明になる |
| エージェントの作成者・スポンサー | 部門管理者がエージェントを作成した | インシデント時の責任者が曖昧になる |
| エージェントが呼び出した別エージェント | 翻訳エージェントや調査エージェントを呼び出した | データがどこへ渡ったか追跡しにくい |
Microsoft Entra Agent IDでは、エージェントIDにスポンサーを持たせる考え方が示されており、スポンサーはインシデント時の連絡先など、責任の所在を示すために使われます。また、エージェントIDはブループリントから作成され、同じ種類のエージェントに対して一貫したポリシー適用や無効化、権限取り消しを行えると説明されています。(Microsoft Learn)
MCP、A2A、OAuth、SPIFFEの関係を実務目線で整理する
今回の記事を読むうえで重要なのは、MCP、A2A、OAuth、SPIFFEを競合技術として見ないことです。それぞれ役割が異なります。
| 技術・標準 | 主な役割 | agentic identityでの見方 |
|---|---|---|
| MCP | エージェントがツール、API、リソースに接続するためのプロトコル | 「エージェントがどのツールをどう呼ぶか」を制御する入口 |
| A2A | エージェント同士の通信・協調のためのプロトコル | 「エージェントが別のエージェントに何を依頼するか」を制御する入口 |
| OAuth | 認可、委任、トークン発行、スコープ制御の基盤 | ユーザー代行、自律実行、トークン交換を設計する中心 |
| SPIFFE | ワークロードに暗号学的に検証可能なIDを与える標準 | エージェント実行基盤やサービス間通信の信頼を支える |
| Microsoft Entra Agent ID | Microsoft環境でエージェントIDを管理・保護する基盤 | 棚卸し、ポリシー、スポンサー、監査、ライフサイクル管理の実装先 |
MCPの認可仕様では、MCPサーバーはOAuth 2.0 Protected Resource Metadataを実装し、MCPクライアントはそれを認可サーバー検出に使うことが求められています。また、MCPサーバーはアクセストークンが自分向けに発行されたものかを検証し、トークンのパススルーを避ける必要があります。(Model Context Protocol)
A2Aは、独立したAIエージェント同士の通信と相互運用を可能にするオープン標準です。公式ドキュメントでは、A2Aはエージェント間通信、MCPはエージェントからツール・API・リソースへの接続を標準化する補完的な標準として説明されています。(A2A Protocol)
SPIFFEは、ワークロードを識別するSPIFFE IDと、それを暗号学的に検証可能にするSVIDを定義する標準です。エージェントそのもののビジネス上の権限を決めるものではありませんが、エージェントを実行するワークロードやサービス間通信の信頼を支える技術として重要です。(Spiffe)
セキュリティ管理者が見るべきポイント
セキュリティ管理者が最初に見るべきなのは、エージェントの「機能」ではなく「到達可能なリソース」です。AIエージェントは便利なチャットUIに見えても、裏側ではMCPサーバー、A2Aエンドポイント、Graph API、SaaS API、社内APIを横断していることがあります。
MCPサーバーは「接続できるか」ではなく「誰向けのトークンか」を確認する
MCP対応を進めると、社内のデータベース、チケット管理、ナレッジベース、コードリポジトリなどがエージェントから呼び出されやすくなります。このとき、「MCPサーバーに認証を付けたから安全」と考えるのは不十分です。
確認すべき観点は次の通りです。
| 確認項目 | 実務上の判断基準 |
|---|---|
| トークンのaudience検証 | MCPサーバー自身に向けて発行されたトークンだけを受け入れる |
| トークンパススルーの禁止 | クライアントが持つ別リソース向けトークンをそのまま上流APIに流さない |
| スコープの最小化 | 読み取り、書き込み、削除、管理操作を別スコープに分ける |
| 401と403の使い分け | 未認証と権限不足をログ上で区別する |
| メタデータの信頼 | Protected Resource MetadataのURLや発行元を検証する |
OAuth 2.0 Protected Resource Metadataは、保護されたリソースとやり取りするために必要な情報をOAuthクライアントや認可サーバーが取得できるメタデータ形式です。RFC 9728では、保護リソースが認可サーバー情報を示す仕組みや、メタデータ取得に伴うリスクへの注意も説明されています。([IETF Datatracker][7])
APIキーやPATを「暫定」のまま残さない
Microsoft FoundryのA2A認証ドキュメントでは、A2A接続の認証方法として、キーを基にした認証、Microsoft Entra IDのエージェントID、プロジェクト管理ID、OAuth IDパススルー、認証なしアクセスが整理されています。ユーザーごとのアクセス許可が必要な場合はOAuth IDパススルー、基盤サービスがMicrosoft Entraをサポートする場合はMicrosoft Entra認証が選択肢になります。(Microsoft Learn)
PoCではAPIキーやPATを使うことがあります。しかし、本番でそのまま残すと、次の問題が起きやすくなります。
| 失敗パターン | 起きる問題 | 回避策 |
|---|---|---|
| 共有APIキーを全エージェントで使い回す | どのエージェントが操作したか追跡できない | エージェント単位または種類単位でIDを分離する |
| PATをプロジェクト接続に保存する | 退職者や異動者の権限が残る | OAuth IDパススルーやEntra認証を検討する |
| 長期クライアントシークレットを使う | 漏えい時の影響範囲が大きい | 証明書、マネージドID、フェデレーションID資格情報へ移行する |
| 認証なしA2Aを社内だからと許可する | 内部ネットワーク侵害時に横展開される | 認証なしは公開情報や隔離済み検証環境に限定する |
Microsoft LearnのエージェントID作成ドキュメントでも、運用環境ではクライアントシークレットではなく、マネージドIDやクライアント証明書を使うフェデレーションID資格情報など、より安全な認証方法を使うよう注意されています。(Microsoft Learn)
ID管理チームが設計すべきenterprise identity architecture
agentic identityの設計では、「エージェントを作る部署」だけに任せると失敗します。ID管理チームは、ユーザーID、アプリID、ワークロードID、エージェントIDを同じ統制の中で扱う必要があります。
実務では、次の6層で設計すると整理しやすくなります。
| 層 | 設計内容 | 具体例 |
|---|---|---|
| インベントリ層 | どのエージェントが存在するか | Entra Agent ID、Agent 365、Copilot Studio、Foundry、社内開発エージェント |
| 所有者・スポンサー層 | 誰が責任を持つか | 部門、管理者、開発チーム、業務オーナー |
| 認証層 | エージェントがどう本人性を示すか | Entra認証、マネージドID、FIC、証明書、SPIFFE |
| 認可層 | 何にアクセスできるか | OAuthスコープ、Graph権限、Azure RBAC、アプリロール |
| 委任層 | 誰の代わりに動くか | ユーザー委任、OBO、OAuth IDパススルー |
| 監査・廃止層 | 何を記録し、いつ消すか | サインインログ、監査ログ、アクセスレビュー、権限取り消し |
Microsoft Entra Agent IDでは、エージェントIDは特別なサービスプリンシパルとして扱われ、エージェントID自体は資格情報を持たず、ブループリントがトークン取得に関与する形が説明されています。これにより、エージェントの種類ごとにポリシーや権限をまとめて扱いやすくなります。(Microsoft Learn)
自律実行とユーザー代行を分ける
特に重要なのは、自律実行とユーザー代行を混ぜないことです。
たとえば、経費精算エージェントを考えます。社員が「今月の交通費をまとめて」と依頼し、エージェントが本人の経費データだけを取得するなら、ユーザー委任の考え方が合います。一方、毎月末に全社員の未提出状況を集計して管理部門に通知するなら、エージェント自体に付与されたアプリ権限やロールが関係します。
この2つを同じID、同じトークン、同じログで処理すると、監査時に「ユーザーがやったのか」「エージェントが自律的にやったのか」が曖昧になります。権限設計では、少なくとも次の分離を行ってください。
| 分離するもの | 理由 |
|---|---|
| ユーザー代行トークンとエージェント自律トークン | 操作主体と責任範囲が異なる |
| 読み取り権限と更新権限 | プロンプトインジェクション時の被害を抑える |
| 本番データ用エージェントと検証用エージェント | PoCの緩い権限が本番へ流入するのを防ぐ |
| 部門別エージェント | 国・地域・事業部ごとのデータ境界を守る |
コンプライアンスチームが見落としやすい論点
コンプライアンス担当者にとって、agentic identityの重要性は「AI利用ポリシー」だけではありません。監査証跡、アクセスレビュー、データ越境、職務分掌、委託先管理に直結します。
説明責任は「人間の利用者」だけでは足りない
エージェントが人間の指示で動いたとしても、実際のAPI呼び出しはエージェントIDで行われる場合があります。そのため、ログには少なくとも次の情報が必要です。
| 必要な証跡 | 例 |
|---|---|
| エージェントID | どのAIエージェントが操作したか |
| スポンサーまたは所有者 | インシデント時に誰へ確認するか |
| 利用者 | 誰の指示またはセッションで動いたか |
| 認可スコープ | どの権限でアクセスしたか |
| 接続先 | どのMCPサーバー、A2Aエンドポイント、APIにアクセスしたか |
| データ分類 | 機密情報、個人情報、規制対象データを扱ったか |
Microsoft Learnでは、エージェントIDがAIエージェントによる操作と従業員、顧客、ワークロードIDによる操作を区別する必要性に対応するものとして説明されています。(Microsoft Learn)
プレビュー機能は本番統制にそのまま組み込まない
Microsoft Entra Agent IDは、Microsoft Learn上でプレビュー段階と明記されています。プレビュー機能は将来変更される可能性があるため、規制対象業務や監査対象システムで使う場合は、正式提供状況、契約条件、ログ保持、サポート範囲を確認してから採用判断を行うべきです。(Microsoft Learn)
これは「使ってはいけない」という意味ではありません。むしろ、今のうちに設計原則を固めることが重要です。プレビュー段階では、次の用途から始めると安全です。
| 適した用途 | 理由 |
|---|---|
| エージェント棚卸しの検証 | 既存AI利用の可視化に役立つ |
| 非本番データでのMCP/A2A認証検証 | 標準プロトコルの設計課題を早期に把握できる |
| アクセスレビュー運用の試行 | スポンサー、権限、期限切れの設計を確認できる |
| SIEM連携の検証 | ログ項目や検知ルールを事前に作れる |
すぐ使える導入前チェックリスト
Microsoft Entra / agentic identityを導入・評価する前に、次のチェックリストで現状を確認してください。すべてを一度に満たす必要はありませんが、本番化の前には「未確認」を残さないことが重要です。
| チェック項目 | 合格基準 |
|---|---|
| エージェントの一覧があるか | 部門、用途、作成者、スポンサー、接続先が分かる |
| 人間代行か自律実行かを分類したか | ユーザー委任とアプリ権限が分離されている |
| MCPサーバーを把握しているか | 認可サーバー、スコープ、audience検証が確認済み |
| A2A接続先を把握しているか | 認証方式、接続先発行元、データ共有範囲が確認済み |
| APIキーやPATを使っていないか | 使う場合は期限、保管場所、ローテーション責任者がある |
| ログでAIエージェント操作を識別できるか | 人間、アプリ、エージェントの操作が区別できる |
| アクセスレビューを設計したか | 権限、スポンサー、利用実態を定期確認できる |
| 廃止手順があるか | エージェント停止時に権限、トークン、接続設定を無効化できる |
よくある失敗と回避策
既存のアプリ登録をエージェントに使い回す
最も起きやすい失敗は、既存のアプリ登録やサービスプリンシパルをAIエージェントにも使い回すことです。短期的には簡単ですが、監査ログ、権限レビュー、インシデント調査で問題が出ます。
回避策は、エージェントの種類ごとにID設計を分けることです。大量に作成される同種エージェントは、ブループリントやポリシー単位で管理できる形に整理します。
ユーザー代行と自律実行を同じスコープで処理する
ユーザーが依頼した処理と、エージェントが自律的に行う処理を同じスコープで扱うと、権限が過剰になりがちです。たとえば「本人の予定表を読む」ための権限と、「部署全体の予定表を集計する」ための権限は別物です。
回避策は、トークン発行時点で用途を分けることです。ユーザーごとの操作には委任権限を使い、定期実行や全体集計にはエージェント自体の権限を使います。
MCP接続を「社内だから安全」と判断する
MCPサーバーは、エージェントが重要な社内データや操作系APIに触れる入口になり得ます。社内ネットワーク内にあるだけでは十分な防御になりません。
回避策は、MCPサーバーを保護リソースとして扱い、OAuthベースの認可、audience検証、スコープ分離、操作ログを必須にすることです。
APIキーを運用でローテーションしない
PoCで発行したAPIキーが、そのまま本番エージェントに残るケースは珍しくありません。エージェントは複数のシステムを横断するため、1つのキー漏えいが広範囲のデータアクセスにつながる可能性があります。
回避策は、APIキーを「例外扱い」にすることです。利用期限、保管場所、所有者、ローテーション頻度、漏えい時の無効化手順を明文化してください。
90日で進める実務ロードマップ
agentic identity対応は、いきなり全社展開するより、90日程度で段階的に進めると現実的です。
| 期間 | 実施内容 | 成果物 |
|---|---|---|
| 0〜30日 | AIエージェント、MCPサーバー、A2A接続、APIキーの棚卸し | エージェント台帳、接続先一覧、リスク分類 |
| 31〜60日 | Entra Agent ID、OAuth、MCP認可、ログ連携の検証 | 標準アーキテクチャ案、認証方式の選定表 |
| 61〜90日 | アクセスレビュー、スポンサー管理、廃止手順、SIEM検知ルールを整備 | 運用手順、監査証跡テンプレート、例外管理ルール |
最初の30日で重要なのは、完璧な統制ではなく可視化です。どの部門がどのエージェントを使い、どのデータに接続しているかが分からない状態では、OAuthやSPIFFEを導入しても効果が限定的です。
次の30日では、代表的なユースケースを1つ選び、Microsoft Entra、MCP、A2A、OAuthの関係を実装レベルで確認します。たとえば「社内ナレッジ検索エージェントがMCPサーバー経由でSharePoint相当の情報を参照する」など、読み取り中心のシナリオから始めるとリスクを抑えやすくなります。
最後の30日では、コンプライアンスと運用に落とし込みます。アクセスレビューの頻度、スポンサー不在時の扱い、エージェント廃止時の権限削除、ログ保存期間、インシデント時の調査手順を決めてください。
まとめ：次に取るべき行動
Microsoft Entra / agentic identityの2026年4月更新ポイントは、AIエージェントを単なるチャットボットやアプリ連携として扱わず、標準ベースのIDアーキテクチャに組み込む必要があるという点です。Microsoftは、MCP、A2A、OAuth、SPIFFEをエージェントID標準の重要な構成要素として位置づけ、特に信頼のブートストラップ、委任、共有シークレット削減を重視しています。(TECHCOMMUNITY.MICROSOFT.COM)
まず行うべきことは、エージェントの棚卸しです。次に、MCPとA2Aの接続先、OAuthフロー、APIキーやPATの使用状況を確認してください。そのうえで、Microsoft Entra Agent ID、マネージドID、フェデレーションID資格情報、OAuth IDパススルー、SPIFFEなどをどこに適用するかを決めます。
AIエージェントの導入が進むほど、ID管理は後付けできなくなります。PoCの段階から「誰が、何として、どの権限で、どこへアクセスしたか」を説明できる設計にしておくことが、セキュリティ、監査、グローバル運用のすべてで最も重要です。
[7]: https://datatracker.ietf.org/doc/rfc9728/ “
RFC 9728 - OAuth 2.0 Protected Resource Metadata
"
コメント