【Okta for AI Agents】AI エージェントの認証・認可を ID 基盤に集約する 第3回：Okta・Microsoft・Google・AWS のエージェント ID 管理を比較する

はじめに

こんにちは、ネクストモードのゆきなわです。

第2回では、ユーザー代理型の OAuth 接続について、その接続認可を ID-JAG / XAA / EMA（MCP の企業向け認可拡張）で組織管理の IdP へ集約する仕組みを確認しました。最終回となる本記事では、エージェントのライフサイクルを管理するプラットフォームとして、Okta・Microsoft・Google・AWS の4社を比較します。

本シリーズの起点は、AI エージェントの認証・認可のどこまでを Okta for AI Agents でカバーできるのかを明らかにすることです。その答えを出すには、他社のプラットフォームと並べて、各社が何を担い、何を担わないかを見る必要があります。第2回で対象外として残った静的な API キーや共有資格情報も、ボールト（vault：認証情報を保管・管理するシークレットストア）や特権管理で扱う領域として、あわせて比較します。

比較に入る前に、前提を3点共有します。

• 4社に共通するのは、AI エージェントを人間や共有アカウントと区別できる個別の管理対象として識別・管理する方向です。
• 一方で、エージェントが下流リソースへアクセスするときの権限主体は、第1回のモデル A（ユーザー代理型）・B（エージェント独立権限型）・C（保存接続依存型）が併存します。管理上の個別 ID があっても、すべてのアクセスがエージェント自身の権限（モデル B）になるわけではありません。
• 4社が提供するのは同じ形の製品ではありません。Okta は ID ガバナンス製品、Microsoft・Google・AWS は ID・構築・ランタイムを含む製品群です。そのため機能の横並びではなく、各社がどの部分の制御を担うかを比較します。

各社の提供段階（GA：一般提供、Preview：プレビュー、Early Access：早期アクセス）は機能ごとに異なり、変化も速いため、本文では製品名ではなく採用する機能単位で確認する方針をとります。

本記事のポイント

• 4社は、エージェントを個別に識別・登録・管理する方向で一致しています。違いは、管理アプローチ・既存エコシステム・資格情報の扱い・実行時制御にあります。
• 個別 ID を与えても、下流アクセスの権限主体（A / B / C）はアクセス経路ごとに決まります。
• ID 基盤へ集約できるのは、認証・エージェント ID のライフサイクル管理・対応する範囲でのユーザー代理型 OAuth の接続認可です。静的資格情報・操作単位の認可・下流ログ・既存セッションの失効は、別の制御ポイントとして設計します。

本シリーズの構成は次のとおりです。

• 第1回：エージェントは誰の権限で動くのか。権限主体を A / B / C の3モデルで整理しました。
• 第2回：外部 SaaS への接続認可を ID 基盤へ集約する仕組み（ID-JAG / XAA / EMA）を扱いました。
• 第3回（本記事）：Okta・Microsoft・Google・AWS のエージェント ID 管理を比較し、残る課題を整理します。

比較の全体像

4社を管理アプローチ・主な統合範囲・権限主体（A / B / C）と資格情報・実行時制御・提供段階の5つの観点で並べると、次のようになります。根拠と確認のポイントは各社の節で扱います。

製品選定では、4社の機能を横並びで採点するより2つの問いに分けて考えることをおすすめします。1つは、エージェントを構築・実行する基盤をどのエコシステム（Microsoft 365 / Azure、Google Cloud、AWS）に置くかです。もう1つは、複数の SaaS やクラウドにまたがるエージェントの登録・接続・ガバナンスを、どの層で一元化するかです。後者は特定のエコシステムに閉じない横断的な役割で、本記事の4社では Okta がこの層を担い、Microsoft・Google・AWS の基盤とも組み合わせられます。以降の各社の節は、この2つの問いの判断材料になるように書いています。

比較に使う共通の評価軸

各社の製品は扱う範囲が広いため、先に評価の観点をそろえます。次の7つの評価軸は、各社の節を読む観点であり、自社で製品を評価するときのチェックリストとしても使えます。なお、第1回の「7つの確認ポイント」がアクセス経路ごとに権限を確認する観点だったのに対し、こちらは製品・プラットフォームを評価する観点です。

「エージェントの ID」が指す2つの意味

各社の製品名には、Entra Agent ID・Agent Identity・AgentCore Identity と、いずれもエージェントの ID にあたる言葉が入っています。製品名にこそ現れませんが、Okta もエージェントを "first-class identity"、つまり人間のユーザーと同列の個別の ID として扱う方向を打ち出しており、この点は4社に共通です（Okta の GA 発表）。ただし、ここでいう ID には、登録・管理の単位という意味と、下流認可の主体という意味が混ざっています。本記事では次の2語で区別します。

• エージェント管理オブジェクト：エージェントを人間や一般アプリと区別し、所有者・状態・メタデータ・アクセスを管理する登録単位。管理の層の概念であり、権限主体のモデル A / B / C のどれか1つに対応するものではありません。
• エージェント専用ワークロード ID：エージェント自身を下流認可の主体として扱う ID。第1回のモデル B に対応します。

管理オブジェクトを持つことと、下流アクセスをすべてモデル B にすることは別です。4社とも、アクセス経路ごとに A / B / C が併存します。以降の各社の節では、この2語を区別しながら、各社の「ID」がどちらを指しているかを確認していきます。

Okta：複数 SaaS・IdP をまたぐ登録・接続・ガバナンス

各社の節は、シリーズを通じて取り上げてきた XAA / ID-JAG の推進者でもある Okta から見ていきます。前節までの整理でいえば、特定のエコシステムに閉じない横断のガバナンス層を担う製品です。

Okta for AI Agents は2026年4月30日に GA となりました。Okta が Identity Security Fabric と呼ぶ ID 管理基盤にエージェントを統合し、発見・登録・接続・ガバナンスの各操作をまとめたプラットフォームです。Okta for AI Agents の機能全体像は、弊社記事で解説しています。

管理の流れ：発見・登録・接続・ガバナンス

Okta 公式ドキュメントでは、エージェント管理が4つの操作として説明されています。

1. 発見・評価：Identity Security Posture Management（ISPM）が、管理対象外のエージェント・過剰な OAuth 付与・露出した資格情報を検出します。第1回で述べたシャドーエージェントへの対策にあたります。ただし、すべての SaaS 内エージェントを自動で把握できるわけではなく、検出対象は個別に確認します。
2. 追加・登録：自社開発エージェントは手動登録、サードパーティ製ビルダー由来は import で同期し、Universal Directory（UD）に人間のユーザーと同様の個別の ID として一覧化します（管理画面では Directory > AI Agents）。この UD 上の登録が、前節でいうエージェント管理オブジェクトにあたります。所有者（owner）・資格情報・ユーザー割り当て用のリンクされた OIDC アプリを設定します（追加・登録の手順）。
3. リソース接続：エージェントがアクセスできるリソースを、リソース接続（resource connection）としてタイプ別に定義します。次節で詳しく見ます。
4. アクセス統制：Okta Identity Governance（OIG）が、エージェントと、それに紐づくユーザーサインオンアプリへのアクセスを申請・承認・棚卸し・是正し、最小権限を維持します。

リソース接続：認可サーバー型と XAA

実装の中心になるのがリソース接続です。エージェントごとに、アクセスできるリソースをタイプ別に定義します。タイプによって資格情報の扱いとセキュリティレベルが変わります。公式には認可サーバー・シークレット・サービスアカウント・アプリケーション・MCP サーバーの5タイプがあり、本記事では次の3群に要約します。

（Okta 公式ドキュメント：リソースタイプの比較 / リソース接続）

認可サーバー型の実体は Okta のカスタム認可サーバー（API Access Management）です。公式のリソースタイプ比較では、接続プロトコルは Cross App Access、セキュリティレベルは高とされています。ただし、認可サーバー型のリソース接続全体が XAA というわけではありません。権限主体のモデルで整理すると、次のように分かれます。

• XAA / ID-JAG が扱うのは、サインイン中ユーザーの代理でアクセスするモデル A です。
• リンクされた OIDC アプリを使い、リソース側で本人権限を適用する構成も、A / B / C に加わる第4のモデルではなくモデル A にあたります。
• エージェント自身を権限主体にするモデル B は、XAA / ID-JAG とは別に、ワークロード ID やグラント／委任の構成で確認します。

静的資格情報の管理には、Okta Privileged Access（OPA）を使います。API キーやサービスアカウントを OPA に保管（ボールト化）し、取得制御と監査を適用する補完策です（Okta の発表）。Okta のリソースタイプ比較では、シークレット／サービスアカウントはセキュリティレベル低に位置づけられます。静的キーを放置するよりは安全性が高まる一方、OAuth ベースの短命トークン・スコープ制御と同格ではありません。接続方式を選べる場合は、OAuth ベースの接続が優先候補です。

なお、ここまでに登場した ISPM・OPA に加え、OIG のアクセスリクエスト／アクセス認定に相当する機能（Access Governance）も、AI エージェント用途として Okta for AI Agents の SKU に含まれます（Okta Product Subscription Reference Guide 2026年6月版）。

ガバナンスと監査の範囲

OIG のガバナンスと System Log の監査がカバーするのは、どのエージェントに誰がアクセスできるかというアクセスの層までです。前述のとおり OIG はエージェントとユーザーサインオンアプリへのアクセスを申請・承認・棚卸し・是正し、System Log は Okta 側のエージェント関連イベントを記録します（アクセスの管理）。

一方、下流 SaaS 内のツール実行・業務操作はこの層の外にあり、記録も判定も Okta 単独では完結しません。下流 SaaS・ゲートウェイ・エージェントランタイムの操作ログと突き合わせて設計します。

失効の手段として、現在の管理フローで使えるのはエージェントの無効化です。新規のトークン要求を止めるキルスイッチとして機能します（Okta の GA 発表）。

一方、GA 発表とブループリント発表は、今後の拡張として次の機能を挙げています。

• 脅威検知：行動分析による異常検知・自動修復を担う Identity Threat Protection（ITP）のエージェントへの適用は段階的に広がる途中で、悪意あるエージェント活動を特定する脅威検知は今後数か月の拡張として示されています。
• Universal Logout for AI Agents：逸脱したエージェントの全アクセストークンを即時失効させる機能です。後述する失効の横断伝播に直接関わります。
• Agent Gateway：エージェントとツール間のトラフィックを仲介する Okta ホスト型のゲートウェイです。
• エージェント間の委任・人による確認（human-in-the-loop）

XAA のエコシステムとベンダー横断性

Okta が重視しているのは、ベンダー横断性とオープンな仕様への準拠です。ID-JAG はベンダーニュートラルに実装可能な OAuth 拡張ドラフトで、XAA はそれを核とするアプリ間接続パターンと実装エコシステムの名称です。Okta は Cross App Access のエコシステムを拡大し、25社超の早期アダプターを発表しています。

2026年5月の機能拡張では、Entra ID や Ping といった他社 IdP を人間用の基盤として残したまま、Okta for AI Agents をエージェント専用のガバナンス層として併用できるようになりました（Okta Newsroom）。一方で段階提供も残っています。OIN（Okta Integration Network）での XAA 対応アプリ提供は2026年8月開始予定です（Okta の発表）。

具体的な統合事例も出ています。Okta と Anthropic の統合では、Okta for AI Agents が Claude の管理エージェントを Universal Directory にインポートし、人間のオーナーを割り当てて中央ポリシーを適用できます（Okta の発表）。

Microsoft：Entra と Microsoft 365 へエージェント ID を統合

Microsoft は、Entra（旧 Azure AD）のエコシステムにエージェントを取り込むアプローチをとります。「2. 比較の全体像」の2つの問いでいえば、横断のガバナンス層ではなく、Microsoft 365 / Azure という構築・実行の基盤の側からエージェント ID を整備する位置づけです。Microsoft Entra Agent ID は、公式の更新情報によれば2026年5月に GA となりました。

ID オブジェクトと資格情報の持ち主

設計の中心は、agent identity blueprint（テンプレート）・blueprint principal・agent identity（個々の実体）・agent user（必要なときだけ作る1:1のユーザーアカウント）の4つのオブジェクトです。前節の区別でいえば、これらはエージェント管理オブジェクトの層にあたり、このうち agent identity は下流認可の主体、つまりエージェント専用ワークロード ID にもなります。

ここで正確にしておきたいのは、資格情報の持ち主です。agent identity 自身は資格情報を保持しません。agent identity blueprint が FIC（フェデレーション ID 資格情報）・証明書／鍵・client secret などの資格情報を保持し、agent identity の代理でトークンを取得します（Microsoft Entra でのエージェント ID の概要）。

エージェントには、スポンサー（ユーザーまたはグループ）を紐づけられます。技術的な管理者である owner と、業務上の説明責任を負う sponsor は役割が異なります（所有者・スポンサー・マネージャーの管理関係）。

委任と自律の両対応

権限主体としては、委任アクセス（OBO、モデル A）と自律アクセス（client credentials、モデル B）の両方に対応します。

一方、Conditional Access やアクセスパッケージといった Entra の既存ガバナンス機能は、Entra にあるからエージェントにもそのまま適用できる、と一括りにすることはできません。機能ごとに、提供段階と必要なライセンス（Agent 365 / Entra など）を確認します（Entra のライセンス）。

構築基盤である Microsoft Foundry（旧 Azure AI Foundry）の Agent Service でも、委任アクセス（モデル A）と自律アクセス（モデル B）を選んで構築できます。ただし開発段階と公開後で ID の管理単位が変わる構成があるため、常にエージェントごとに Agent ID があるとは断定せず、実行・公開形態ごとの ID を確認します。

新しい確認点：管理ロールの権限境界

新しい ID モデルには、新しい攻撃面が伴います。セキュリティ企業 Silverfort からは、Agent ID Administrator ロールの権限スコープが過大で、エージェントと無関係なサービスプリンシパルまで乗っ取れる問題が報告されました。Microsoft は2026年4月に修正しています（Silverfort の報告）。

これは Entra 固有というより、エージェント専用の ID モデルを導入するすべてのプラットフォームに共通する論点で、管理ロールの権限境界そのものが新たな確認ポイントになります。現在の権限境界は、Microsoft の一次情報や現行の built-in role 定義で確認します（Microsoft Entra ビルトイン ロール）。

Google Cloud：証明書ベースの Agent Identity

Google Cloud は、証明書バインドや SPIFFE ID を前面に出し、暗号的なワークロード ID 管理を中心に据えます。「2. 比較の全体像」の2つの問いでいえば、Microsoft と同じく構築・実行の基盤の側からのアプローチです。公式名称は Agent Identity で、各エージェントに、SPIFFE にもとづいて暗号的に検証できる ID を与えます（エージェント ID の概要）。管理オブジェクトの体系から入る Microsoft に対し、Google はエージェント専用ワークロード ID の技術的な強度から入る設計といえます。

SPIFFE と証明書バインドの仕組み

エージェントには一意の SPIFFE ID と、短期間で失効して自動更新される X.509 証明書が割り当てられます。Google Cloud 向けのアクセストークンはその証明書に暗号的にバインドされるため、トークンが漏洩しても単体では使えません。このほか、次の制約が既定で適用されます。

• Agent Identity は、デフォルトでは複数のワークロードに共有されません。
• なりすましは許可されません。
• 長期のサービスアカウントキーの作成は許可されません。

いずれも、共有される主体や長命の資格情報というシリーズで見てきたリスクを、既定値の側で塞ぐ設計です。

周辺機能とランタイム別の提供段階

外部ツールへのアクセスでは、Auth Manager が API キーや OAuth トークンを管理し、ユーザー代理（モデル A）とエージェント自身の権限（モデル B）の両方を扱います。Principal Access Boundary（PAB）や VPC Service Controls と統合すれば、権限の絞り込みやデータ持ち出し制御まで適用できます。

ただし、提供段階は機能ごとに異なります。2026年7月時点では、Auth Manager・PAB・Agent Identity を VPC Service Controls の ingress / egress ルールで使う機能などに Preview が残ります（What's new in IAM, security, governance, and runtime defense）。

提供状況は、対象のランタイムごとにも分かれます。Google の発表は Agent Runtime 向け Agent Identity を GA としています。一方、環境のセットアップのドキュメントでは、エージェント ID のロールで利用できる一部の機能にプレビュー版の注記があります。両者をまとめて一つの提供状況とは扱わず、「1. はじめに」で述べたとおり、採用する機能単位で確認します。

共有 Service Agent の扱い

Vertex AI Agent Engine では、既定の Google 管理の共有 Service Agent に代えて、エージェント単位の Agent Identity を選べます。これを本シリーズの分類に当てはめると、共有主体（モデル C に近い）から、エージェント自身を主体とする管理単位（モデル B）へ移す選択肢と解釈できます。

ただし、これは Google の公式分類ではなく本シリーズの推論です。共有サービスアカウントであることだけで、モデル C と断定はできません。実際に分類するときは、1つの ID を共有する範囲・下流トークンの主体・利用者権限での再評価の有無・監査ログに記録される主体を確認します。

AWS：Amazon Bedrock AgentCore

最後に AWS です。エージェント ID 管理を担うのは、Amazon Bedrock AgentCore に含まれる AgentCore Identity です。AgentCore は単一のランタイムではなく、エージェントの構築から実行・観測までを担うモジュール型サービスの集合で（What is Amazon Bedrock AgentCore?）、すでに GA となっています（Amazon Bedrock AgentCore の一般提供開始）。実行環境が AgentCore Runtime、ID と資格情報の管理が AgentCore Identity で、ほかに Gateway や Policy を組み合わせます。

「2. 比較の全体像」の2つの問いでいえば、AWS も構築・実行の基盤の側です。ただし、Microsoft・Google が IAM 側に独立した ID 製品を持つのに対し、AWS はそれをエージェント基盤のモジュールとして内包しているのが構造上の違いです。

ワークロード ID と Inbound / Outbound

設計の特徴は、エージェントに環境非依存のワークロード ID を割り当て、それをアンカーに複数の資格情報方式を管理する点です。認証は2つに分かれます。誰がこのエージェントを呼び出せるかの Inbound Auth と、エージェントが下流サービスへアクセスするときにどの資格情報をどう取得するかの Outbound Auth です。

ここで注意したいのは、Inbound / Outbound は通信方向の制御ポイントであって、そのまま権限主体モデル（A / B / C）に対応するわけではないことです。モデル A / B / C は、Outbound 側でユーザー委任トークン・エージェント専用ワークロード ID・保存 API キーのどれを使い、リソース側で誰の権限が評価されるかで、アクセス経路ごとに判定します。

権限主体 A / B / C との対応

AgentCore の各機能を第1回の3モデルに当てはめると、次のようになります。

• モデル A：ユーザー代理（user-delegated）。具体例として、2026年4月30日に GA となった OBO token exchange があります（OBO token exchange）。
• モデル B：workload identity（agent-only access）。本記事でいうエージェント専用ワークロード ID にあたります。
• モデル C：静的 API キーは credential provider / ボールトで管理する補完策として扱います。

AgentCore Identity は API キーも credential provider として管理します。つまり静的資格情報をなくす製品ではなく、その管理をワークロード ID に束ねる製品です（Understanding workload identities / Obtain OAuth 2.0 access token）。

操作単位の認可と他基盤との組み合わせ

操作単位の認可まで踏み込んでいるのが、AgentCore Gateway と AgentCore Policy です。Gateway がポリシー強制ポイントを、Policy がルールエンジンを担います。Cedar ポリシーはツール実行のリクエストをデフォルト拒否で評価し、JWT クレーム・ツール入力・実行時コンテキストを条件にできます。AgentCore Policy はすでに GA です（Policy in AgentCore）。採用するモジュールと対応地域は、機能単位で確認します。

AgentCore は他社の ID 管理基盤とも組み合わせられます。2026年5月には Okta が Okta for AI Agents を AgentCore と統合し、構築したエージェントを取り込めるようにしました（Okta Blog）。この統合は、AgentCore 側のワークロード ID・資格情報管理に、Okta 側の登録・接続・ガバナンスを重ねる構成と捉えることができます（役割分担の細部は筆者の整理です）。「2. 比較の全体像」で述べた、基盤の選択と横断のガバナンス層を組み合わせる進め方の実例と言えます。

補足：A2A の守備範囲

ここまでの節では、エージェント間の接続にも触れました（Okta の Another AI agent など）。この領域には A2A（Agent2Agent）という標準があるため、各社の ID 管理と役割がどう重なるのか、疑問に思われるかもしれません。補足として整理します。

A2A は、エージェント間の連携を相互運用可能にするオープンなプロトコルです。仕様が定めるのは、エージェント間の発見・タスク連携に加え、認証方式の通知（Agent Card）とサーバー側の認証・認可要件です。一方、資格情報の取得方法や、どの IdP を信頼しどのスキル・データを許可するかという認可ポリシーは、実装側に委ねられます（A2A 1.0 specification）。

つまり A2A は、中央ガバナンス製品の代替ではなく、XAA / Entra Agent ID / Google Agent Identity / AgentCore Identity と組み合わせて使うものです。

個別 ID だけでは解決しない課題

各社のプラットフォームは、エージェント認可の多くの領域を扱えるようになっています。一方で、エージェントに個別 ID を与えるだけでは解決しない課題も残ります。ここでは、現在の製品・運用で実装できる補完統制と、相互運用の標準化を追う領域を分けて整理します。

操作単位の認可は現時点で実装手段がない課題ではありません。FGA（Fine-Grained Authorization）・Gateway・Policy engine といった手段があり、AgentCore Policy のように GA 済みの製品も存在します。難しいのは、「このリソースに対して、この瞬間に、この操作をしてよいか」という判断を、特定ベンダーの実装に閉じない標準的な形で、エージェントの自律的なフローへ組み込むことです。この判断は、第1回の「7つの確認ポイント」でいうタスク権限と実行時制御にあたります。XAA / EMA が規定するのは接続の認可までで、操作単位の判断には踏み込むことができません。

プロンプトインジェクション耐性は OAuth スコープを正しく絞っても確保できません。エージェントの判断が外部データ中の指示に乗っ取られれば、与えた権限の範囲内で意図しない操作が実行されます。許可された操作と意図した操作は別物で、スコープが制御できるのは前者だけです。そのため、ツール実行前の検査・権限分離・外部データの信頼境界の明示といった、権限設計とは別の層の対策を重ねる必要があります。

共有エージェントの権限では、第1回の Notion の事例のように、エージェントを使える人が本人には見られない情報を得られます。個別 ID を与えるだけでは解消されず、利用者権限での再フィルタや共有前レビューで補います。

サブエージェントへの委任は、エージェントが別のエージェントへ作業を任せる構成で生じます。委任のたびに権限がそのまま引き継がれると、末端のサブエージェントほど過剰な権限を持ちやすくなります。親より狭い権限・委任チェーンの記録・短命なトークンやセッションで補い、委任チェーンの相互運用は標準化の進展を追います。各社の節で見たエージェント間接続や委任の機能が広がるほど、重要度が上がる課題となります。

ブラウザ操作エージェントは、API スコープやツールゲートウェイといった、ここまで見てきた制御ポイントを経由しない場合があります。人間のユーザーと同じ画面操作でアクセスするためです。ただし、統制の手段がないわけではありません。アクセス経路が人間と同じであれば、人間向けに整備してきた統制をそのまま適用できます。ブラウザセッションの管理・エンドポイント制御・SSO・Conditional Access・操作記録を制御ポイントとし、人間の監督を組み合わせて扱います。

SaaS 間 DLP / 送出制御は個々の接続認可が正当でも残る課題です。エージェントは複数の SaaS へ同時に接続できるため、ある SaaS から取得したデータを別の SaaS へ書き出す操作は、接続単位の認可だけでは止められません。第2回で確認した DLP の統制と同じく、データ分類・送出先制御・外部送信の承認（CASB / SSE / Gateway）を重ねます。

失効の横断伝播では何を止めるかで手段が分かれます。エージェントの管理オブジェクトを無効化しても、既発行のトークン・保存資格情報・既存セッションは使える状態のまま残り続けます。

この表が示すように、IdP への集約で止めやすくなるのは将来の接続認可と新規トークンの発行です。一方、既発行トークン・保存資格情報・既存セッションの終了は接続先の実装と設定に依存します。

失効に限らず、本節で見てきた課題への対策に共通するのは、エージェントの個別 ID を起点にしつつID 基盤だけで完結させず別の層の統制を重ねるという考え方です。この考え方は生成 AI サービスの利用統制とも地続きで、次の弊社記事で解説しています。OIG による利用申請・棚卸しに、SWG / CASB（Netskope）のネットワーク制御、EDR・SIEM（CrowdStrike）のログ分析・検知を統合するアプローチです。

性質の異なる3つの標準化活動

前節の表の右列には標準化・相互運用で追う点を挙げました。このような、エージェントの ID 管理・認可をベンダー横断で相互運用させるための標準化は、製品の実装と並行して議論が進んでいます（2026年7月時点）。ただし次の3つは性質もステータスも異なる活動で、いずれも現時点の設計の前提にできる完成した標準ではありません。今の統制は前節の対策で組み、こちらは進展を追う対象として、それぞれの性質とステータスを確認します。

• OIDF の AI Identity Management Community Group（性質：ユースケースとギャップの整理）：AI エージェントを既存の ID 標準でどう扱うかについて、ユースケース・用語・ギャップ・推奨事項を整理し、白書として公開しています。プロトコル策定は明示的にスコープ外です（Community Group / Identity Management for Agentic AI）。同資料も、現在の OAuth / OIDC は多くのユースケースの出発点になる一方、共有エージェント・自律信頼・ブラウザ操作エージェントにはまだギャップがあると指摘しています。
• IPSIE Working Group（性質：既存標準の相互運用プロファイル策定）：AI エージェント専用の標準ではなく、既存の OIDC・OAuth・SCIM・Shared Signals などの企業向け IAM 相互運用プロファイルを策定する WG です（IPSIE Charter）。
• SCIM Agents and Agentic Applications Extension（性質：個人提案の Internet-Draft）：SCIM による作成・更新・無効化に近いライフサイクル操作を、専用の Agent リソースへ適用することを目指す提案です。ただし、現行の draft-scim-agent-extension-00 は2026年4月14日に失効しており、IETF が承認した標準ではありません（Datatracker）。

これらの性質の違いは、次節のステップ7の内容（標準化を待たずに導入する補完統制と進展を追う項目の切り分け）の判断材料になります。

自社への当てはめ：導入までの3段階

シリーズの締めくくりとして、本記事の内容を自社に当てはめるための作業を、棚卸し・評価・試験・運用設計の3段階（7つのステップ）に整理しました。各ステップには、対応する本文の節を括弧で示します。

棚卸し

1. 利用中・計画中のエージェントと、人間の owner / sponsor を棚卸しする（Microsoft の節）。
2. 各接続を、モデル A / B / C と資格情報の種類で分類する（第1回の3モデル、「比較の全体像」の表）。

評価・試験

3. 2つの問い（構築・実行の基盤をどこに置くか、横断のガバナンスをどの層で一元化するか）に沿って、主要 IdP・クラウド・SaaS・ランタイムから評価候補を絞る（「比較の全体像」）。
4. 機能単位で GA / Preview / EA・地域・ライセンス・対応 SaaS を確認する（「7つの評価軸」、各社の節）。
5. 登録・権限変更・ログの突き合わせ・トークン失効・資格情報回収・廃止までを試験する（失効の対象と制御ポイントの表）。

運用設計

6. 操作単位の認可・承認・DLP・プロンプトインジェクション対策を、どこで補うかを決める（「個別 ID だけでは解決しない課題」）。
7. 標準化を待たずに導入する補完統制と、進展を追う項目を分ける（「性質の異なる3つの標準化活動」）。

この3段階の流れを、ロードマップとして図にまとめました。

おわりに

全3回を振り返ります。第1回では権限主体を A / B / C の3モデルで整理し、エージェントがユーザーの代理とは限らないことを確認しました。第2回では、ユーザー代理型の OAuth 接続について、その接続認可を、委任の仕組みは変えずに ID-JAG / XAA / EMA で IdP へ集約できることを確認しました。第3回の本記事では、それを含むエージェントのライフサイクル管理を、Okta・Microsoft・Google・AWS の製品群で比較しました。

シリーズの起点であった「Okta for AI Agents でどこまでカバーできるか」に答えるなら、エージェントの発見・登録・所有者管理、対応する範囲でのユーザー代理型 OAuth 接続の XAA / ID-JAG による集約、静的資格情報の OPA によるボールト化までを、1つのプラットフォームで担えます。本記事の2つの問いでいえば、構築・実行の基盤を Microsoft・Google・AWS のどこに置いても、横断のガバナンス層として組み合わせられる位置づけです。一方、操作単位の認可・プロンプトインジェクション耐性・SaaS 間の DLP といった個別 ID だけでは解決しない課題は、どの製品を選んでも別の層の統制で補う領域として残ります。

対応する製品と接続先がそろう範囲では、認証・ユーザー代理型 OAuth の接続認可・エージェント ID のライフサイクル管理を ID 基盤へ集約できる段階にあります。静的資格情報・操作単位の認可・下流ログ・既存セッションの失効は、別の制御ポイントと組み合わせて設計します。前節の3段階に整理したのは、まずは自社で管理できる範囲から着手し、接続先の対応と相互運用標準の進展にあわせて統制の範囲を広げていく進め方です。

この領域は各社のアップデートがアクティブに続いています。弊社ブログでは、最新動向のフォローに加えて、Okta for AI Agents の具体的な活用例も今後ご紹介していきます。

用語集

参考ドキュメント

• Okta Newsroom - Showcase 2026: Okta for AI Agents
• Okta Blog - Okta for AI Agents is now generally available
• Okta - Product Subscription Reference Guide（2026年6月版）
• Okta Newsroom - New Okta Innovations Secure the AI-Driven Enterprise
• Okta Support - What's New in Okta for AI Agents
• Okta Newsroom - Okta、Anthropic の Claude 向けに主要 IdP に選定
• Okta Blog - Okta と Amazon Bedrock で AI エージェントを保護
• Okta Newsroom - Okta for AI Agents があらゆる IdP に対応
• Okta Newsroom - Okta Cross App Access パートナーエコシステム拡大
• Okta 公式ドキュメント - Okta for AI Agents（ホーム）
• Okta 公式ドキュメント - AIエージェントを追加・登録する
• Okta 公式ドキュメント - AIエージェントのリソース接続
• Okta 公式ドキュメント - AIエージェントリソースタイプを比較する
• Okta 公式ドキュメント - AIエージェントへのアクセスを管理する
• Microsoft Learn - Microsoft Entra エージェント ID とは
• Microsoft Learn - Microsoft Entra エージェント ID の新機能
• Microsoft Learn - Microsoft Entra でのエージェント ID の概要
• Microsoft Learn - Microsoft Entra エージェント ID の管理関係（所有者・スポンサー・マネージャー）
• Microsoft Learn - Microsoft Entra ID を使用してエージェント ID を管理する
• Microsoft Learn - Microsoft Entra ビルトイン ロール
• Microsoft Learn - Microsoft Entra ライセンス
• Silverfort - Agent ID Administrator scope overreach: Service Principal takeover in Entra ID
• Google Cloud ドキュメント - エージェント ID の概要
• Google Cloud ドキュメント - 環境をセットアップする（Gemini Enterprise Agent Platform）
• Google Cloud Blog - What's new in IAM, security, governance, and runtime defense
• AWS Docs - What is Amazon Bedrock AgentCore?
• AWS Docs - AgentCore Identity
• AWS Docs - Understanding workload identities
• AWS Docs - Obtain OAuth 2.0 access token
• AWS Docs - Policy in AgentCore
• AWS ブログ - Amazon Bedrock AgentCore、東京を含むAWSリージョンで一般提供開始
• AWS - AgentCore Identity OBO token exchange
• A2A - 1.0 specification
• OpenID Foundation - AI Identity Management Community Group
• OpenID Foundation - Identity Management for Agentic AI
• OpenID Foundation - IPSIE Working Group Charter
• IETF - SCIM Agents and Agentic Applications Extension（ドラフト）
• Nextmode Blog - Okta for AI Agents とは？シャドー AI 時代に備えるエージェント管理の全体像
• Nextmode Blog - Okta Cross App Access で AI エージェントの接続認可を検証する
• Nextmode Blog - ID-JAG / Cross App Access の技術詳細
• Nextmode Blog - OIG を利用した生成 AI の一時利用申請・承認
• Nextmode Blog - Okta で実現する生成 AI サービスの ID ガバナンス

本記事はシリーズ AI エージェントの認証・認可を ID 基盤に集約する の第3回（最終回）です。記載の各製品の仕様・挙動については2026年7月時点の情報を元にしています。各製品の機能・提供状況・ライセンス要件は急速に変化するため、導入検討時は各社の一次情報での再確認を推奨します。

AI セキュリティ対策に関するお問い合わせ

Okta や AI エージェントのセキュリティ統制に関するご相談は、ネクストモードまでお気軽にお問い合わせください。