AI エージェントが業務の実行主体となる時代、次に問われるのは「そのエージェントを誰がどう ID 管理するのか」です。Okta は 2025 年 9 月の Oktane 2025 で、AI エージェントを人間ユーザーと同じ土俵で統制するプラットフォーム Okta for AI Agents を発表しました。本記事では、その概要・主要機能・従来 IAM との違い・他社比較を公式発表をもとに整理します。
なぜ AI エージェントに ID 管理が必要なのか
AI エージェントは、人間の指示を受けて SaaS・社内 DB・MCP サーバー・サードパーティ API を横断的に呼び出します。この特性が従来のユーザー管理・サービスアカウント管理では手に負えない課題を生んでいます。
シャドーエージェントの増殖: 各部署が個別に立ち上げたエージェントが、IT 部門の把握外で社内 SaaS や顧客データに接続している状態です。利便性優先の導入が可視性喪失につながります。
過剰権限と長寿命トークン: API キーやサービスアカウントを静的に配布する方式は、権限スコープが広くローテーションも滞ります。Okta はこれを非人間アイデンティティ（NHI）の権限膨張と呼び、主要リスクに位置付けています。
監査可能性の欠如: 「誰の代理として、何を根拠にどのリソースへアクセスしたか」をログだけで再現できないと、インシデント対応や外部監査に耐えません。非対話かつ長時間稼働するエージェントでは、この説明責任のハードルが人間ユーザーより高くなります。
AI エージェントは従来の NHI とも人間ユーザーとも異なる新しい統制対象であり、この領域に狙いを定めたのが Okta for AI Agents です。
Okta for AI Agents の概要
Okta for AI Agents は、同社の「Identity Security Fabric」構想の中核として 2025 年 9 月 25 日に発表された、AI エージェント向け ID 統制プラットフォームです。発表時点で 2026 年 4 月 30 日の一般提供（GA）開始が予告されました。
立ち位置は明確です。Okta は Universal Directory・API Access Management・Identity Governance を拡張し、AI エージェントを「ファーストクラスの非人間アイデンティティ」として扱えるようにしました。新しい並行システムを作るのではなく、既存 IAM 基盤にエージェント ID を取り込む設計思想です。
開発者側の姉妹プロダクトとして Auth0 for AI Agents が 2025 年 10〜11 月に GA となっています。エンタープライズ統制は Okta for AI Agents、アプリ実装は Auth0 for AI Agents という役割分担です。
主要機能：5 つの構成要素
1. Agent Identity
Universal Directory を拡張し、エージェントに一意の ID を発行してライフサイクル管理します。登録・認証情報の発行・運用・監査・デコミッションの 5 フェーズを、人間ユーザーと同じディレクトリ上で追跡できます。エージェントごとに人間オーナーを紐付けて責任所在を明確にする点も、従来 IAM からの自然な拡張です。
2. Agent Gateway
エージェントとツール群のあいだに置かれる中央コントロールプレーンです。仮想 MCP サーバーとして Okta の MCP レジストリのツールを束ね、すべてのエージェント操作を統一的に記録・認可します。どの MCP ツールをどのパラメータで呼んだか、誰の委任によるリクエストかを一カ所で可観測にします。
3. Agentic Access Control
Okta の認可サーバーを利用し、アイデンティティ・コンテキスト・リスクスコアを組み合わせてリクエストごとに許可／拒否／追加認証要求を動的に決定します。従来は各 SaaS や API が個別に管理していた認可判断を、IdP 側に集約する考え方です。
4. Cross App Access（XAA）
XAA はアプリ間・エージェント→アプリの接続を IdP 経由に強制する、OAuth 2.0 / OpenID Connect の拡張プロトコルです。IETF OAuth Working Group で議論中の「Identity Assertion Authorization Grant」を基盤にしており、Okta 単独規格ではなくオープン標準として推進されています。2026 年 1 月から早期アクセスが開始され、AWS・Google Cloud・Salesforce・Box・Glean などが対応を表明しています。
5. Identity Governance for Agents
既存の Identity Governance をエージェントに拡張し、アクセスレビュー（定期棚卸し）や承認ワークフローの対象に含めるものです。人間オーナー承認・期限切れトークン失効・最小権限の徹底などを、人間と同じ枠組みで回せます。
従来の人間向け IAM と何が違うのか
| 観点 | 人間ユーザー | AI エージェント |
|---|---|---|
| 認証方式 | パスワード + MFA、パスキー | 非対話認証。クライアント資格情報、署名トークン、CIBA |
| ライフタイム | 入社〜退社の長期 | タスク単位で数分〜数時間の短命 |
| スケール | 従業員数オーダー | 1 ユーザーあたり複数、数十〜数百倍に膨張 |
| 委任 | セッション + OAuth | 人間→エージェント→API への多段委任 |
| 監査 | アクセスログで追跡 | 「誰の代理として、何を根拠に」を再現する必要 |
とくに重要なのが非対話認証です。エージェントは自らパスワードを入力できないため、Client-Initiated Backchannel Authentication（CIBA）のようにユーザーが別チャネルで承認する仕組みが要ります。ユーザー離席中も処理を保留し、後から承認させる非同期フローが想定されています。
多段委任も従来との違いです。ユーザー A の指示でエージェント B が起動し、B がさらに C を呼ぶ多段シナリオで、元ユーザーの権限スコープを各ステップで正しく継承・絞り込みする必要があります。
MCP サーバー認証と OAuth 2.1
AI エージェントが外部ツールに接続する標準として Model Context Protocol（MCP） が普及しつつあります。MCP 仕様は認可に OAuth 2.1 を採用しており、PKCE 必須・Implicit フロー廃止・Authorization Server Metadata（RFC 8414）・Protected Resource Metadata（RFC 9728）準拠という最新のベストプラクティスが組み込まれています。
Okta for AI Agents は、この MCP の認可レイヤを IdP 側に引き寄せるアプローチです。Agent Gateway が仮想 MCP サーバーとして機能し、各 MCP ツールへのアクセスを OAuth 2.1 と XAA で統制します。各 MCP サーバー実装者がゼロから認可基盤を作る必要がなくなり、企業側も「どのエージェントがどの MCP ツールを使ったか」を一元管理できます。
代表的なユースケース
- 社内カスタムエージェント: 経理・人事向けエージェントにエージェント ID を発行し、SaaS 接続を Okta 経由に統一。権限棚卸しや退役処理を一括で実施できます。
- サードパーティ製エージェント: Glean や Writer など外部ベンダー製エージェントの社内 SaaS 接続を、XAA 対応前提で IdP 統制下に置けます。
- MCP サーバー認証: GitHub・Slack・Jira 連携用の MCP サーバーへのアクセスを OAuth 2.1 + Agent Gateway で認可し、呼び出しログを中央集約できます。
- RAG 権限評価: Auth0 FGA でドキュメント単位の閲覧権限を評価し、RAG 経由の情報漏洩を防ぎます。
- 非同期カスタマーサポート: CIBA で夜間・週末も処理を保留し、後追い承認で実行する運用が可能です。
導入ステップと他ソリューション比較
想定される導入ステップ
- 社内で稼働中のエージェント・サービスアカウント・API キーを棚卸しし、シャドーエージェントを可視化する
- 発見したエージェントを Okta Universal Directory に登録し、人間オーナーを紐付ける
- 最小権限で認可方針を設計する
- Agent Gateway / XAA を有効化し、MCP ツールやサードパーティ SaaS との接続を IdP 経由に集約する
- Identity Governance で定期アクセスレビュー・自動退役を組み込む
他社ソリューションとの比較
公開情報ベースの整理です。各製品は仕様が更新され続けているため、最新は公式ドキュメントをご確認ください。
| 製品 | ベンダー | 位置付け | 提供状況 |
|---|---|---|---|
| Okta for AI Agents | Okta | IdP 主導の統合ガバナンス | 2026/4/30 GA 予定 |
| Auth0 for AI Agents | Okta（Auth0） | 開発者 SDK、CIBA / FGA | 2025/10〜11 GA |
| Microsoft Entra Agent ID | Microsoft | Entra ID の NHI 拡張、Agent Users 構造 | Preview |
| Vertex AI Agent Engine Identity | Google Cloud | GCP ワークロード ID 拡張、mTLS 束縛 | Preview |
三社三様です。Microsoft は Entra 統合と Agent Users 構造、Google は Context-Aware Access による mTLS 束縛と Agent2Agent（A2A）対応、Okta は IdP 中立な立場から XAA を核にマルチクラウド対応を進めています。Microsoft 365 中心なら Entra、GCP 中心なら Google、マルチクラウドで SaaS 連携が多いなら Okta、という棲み分けが当面は現実的でしょう。
まとめ：エージェンティック時代のゼロトラスト
AI エージェントを業務に組み込むこと自体は、もはや前提条件になりつつあります。差がつくのは「エージェントをどう統制するか」です。Okta for AI Agents は、人間向けに積み上げてきた IAM 資産をそのままエージェント領域に拡張し、ゼロトラストの「Never Trust, Always Verify」原則を非人間アイデンティティに適用するアプローチを示しました。
注目点は 3 つです。第一に、XAA というオープン標準でマルチベンダー環境の統一統制を狙うこと。第二に、MCP という新興プロトコルの認可レイヤを押さえ、エージェント時代のアクセス制御基盤になろうとしていること。第三に、Auth0 連携でエンタープライズ統制と開発者向け SDK の両輪を揃えたことです。
一方で、実装・運用面では従来 IAM 以上の設計力が要ります。短命ライフサイクル・多段委任・監査証跡の保存など、自社の運用プロセスを先にアップデートしないと製品を入れても活きません。2026 年以降の企業 IT は、AI エージェントを前提としたゼロトラスト設計をどれだけ自然に組み込めるかが問われます。まずは社内で稼働中のエージェント棚卸しから、静かに始めるのが現実的な第一歩です。