エグゼクティブサマリー
企業におけるAIエージェントのアイデンティティを自社で管理しようとすると、その運用はたちまち継続的なガバナンスとコンプライアンスの重い負担へと発展します。管理を適切に遂行するには、社内開発やサードパーティ製のエージェントはもちろん、シャドーエージェントも対象に、認証、認可、トークンのライフサイクル管理、監査ログの記録を一元化しなければならないためです。独自にアクセスレイヤーを構築すればセキュリティの死角が生じ、監査での不適合を招くばかりか、MCPやOAuthの仕様進化に伴って継続的に開発オーバーヘッドが発生することになります。
一元化されたエージェントのアイデンティティレイヤーに投資することで、企業はツールアクセスを認証情報管理から切り離し、継続的な監査可能性とゼロトラストセキュリティを実現できます。また、エンジニアはビジネスクリティカルな業務を実行するエージェントの開発に集中できるようになります。
AIエージェントのアイデンティティレイヤーとは何か、またどのように構築されるのか？
AIエージェントが単に質問に答えるだけでなく、アクションを実行するようになったことで、プラットフォームチームはエージェントを実環境のツールやデータへ迅速に接続する必要に迫られました。その結果、多くのチームがアクセスレイヤーの自社開発を選択することになりました。このレイヤーは通常、以下の3つの主要コンポーネントで構成されます。
- Model Context Protocol（MCP）ゲートウェイ：エージェントのトラフィックをMCPサーバーへルーティングするコンポーネント
- トークンブローカー：エージェントが呼び出すSaaSアプリケーションに対する各ユーザーの認証情報を保持し、定期的にリフレッシュする機能
- ロールベースのスコープフィルタリング：ユーザーのロールに基づいてエージェントが使用可能なツールを制限する制御機能
こうした自社構築には数か月に及ぶ開発工数がかかったものの、エージェントの本番導入を実現し、プロンプト内への認証情報の混入を防ぐことには成功しました。当時、ほとんどのチームにとって自社開発が唯一の選択肢でした。
Oktaのホワイトペーパー『AIエージェントのアイデンティティ：購入か、自社構築か？』をダウンロードして、専用に設計されたアイデンティティレイヤーの導入が、エンジニアリングチームが終わりのない保守作業に追われることなく、ライフサイクル全体にわたりAIエージェントを管理するための最も効果的なアプローチである理由をご確認ください。
エンタープライズAIエージェントに関するアイデンティティについての6つの重要な質問
エージェントの導入が拡大し、より重要な中核業務を担うようになるにつれて、開発・運用チームはさらに多くの重要要件への回答を求められるようになります。
- エージェントのアイデンティティ：各エージェントはどのように識別されているか？
- 管理責任（オーナーシップ）：エージェントの管理責任者（オーナー）は誰か？
- 委任：エージェントは誰の代理として動作しているか？
- スコープ：どのツールやリソースにアクセスできるか？
- 監査証跡：具体的にどのようなアクションを実行したか？
- キルスイッチ：アクセス権の即時剥奪や、エージェント自体の緊急停止をいかに迅速に実行できるか？
管理スコープはどのように拡大するのか
自社で開発するエージェントアクセスレイヤーも、初期の段階であれば十分に管理可能です。1つのチームが数個のエージェントを構築し、それぞれにサービスIDを割り当ててユーザーのSaaSトークンをブローカーに保存し、エージェントの一覧と作成者をリストで把握する程度で済むからです。エージェントが特定のプラットフォーム内だけで稼働しているチームであれば、この設計でも問題なく機能します。
しかし、エージェントの数とビジネス要件は拡大の一途をたどります。エージェントの接続先となるSaaSアプリケーションは、それぞれ独自の同意モデル、トークン有効期限、失効処理を備えた認可サーバーで稼働しているため、ブローカーにはその都度新たなインテグレーション開発が必要になります。さらに、社内の他のチームも独自のスケジュールでエージェントを本番投入し始め、中にはプラットフォームチームが構築したアクセスレイヤーをまったく経由しないものまで現れます。
開発者は手元のノートPC上でClaude Code、Codex、Cursorといったコーディングエージェントを実行しますが、これらは中央の管理環境を一切経由しません。その結果、ローカルの設定ファイルに直接トークンを貼り付けてMCPサーバーやコードリポジトリに接続してしまう運用が発生します。ベンダープラットフォーム上のエージェントは、ベンダー独自のコネクターを介して社内データへアクセスします。組み込み型エージェント、エージェントスウォーム、ローカルモデルの導入はそれぞれ新たなセキュリティの死角を生み出し、インテグレーションが追加されるたびに、基幹ワークフローを支えるアイデンティティスタックへの負荷が増大していきます。
その結果、当初は自チームのエージェントのためにアクセスレイヤーを作ったはずのチームが、いつの間にか全社向けのアイデンティティ製品をフル運用・保守する羽目に陥るのです。
アイデンティティガバナンスの自社運用に伴う、終わりのない監査対応
多くの組織は、各エージェントの名称、管理責任者、アクセス可能なツールやアプリをリスト化したシンプルなレジストリから着手します。しかし、他チームが独自にエージェントを本番投入し、担当者の異動や退職が発生し、さらには監査人から「今四半期に各エージェントのアクセス権が適切に棚卸しされた監査証跡」を提示するよう求められた時点で、この手作業の運用は完全に破綻します。
そうした監査証跡が1か所に集約されていることはほぼありません。ゲートウェイ、トークンブローカー、接続先SaaSアプリケーションのそれぞれにログが分散して記録されるため、実際に何が起きたかを証明するには、各システムから個別にログを収集し、手作業で突合しなければなりません。
エージェントの運用規模を本格的に拡大するとなれば、レジストリにはさらに高度な機能が求められます。担当者が退職したエージェントの再割り当てや登録抹消、定期的なアクセス認定の自動実行、さらにはアクション実行から数か月が経過した後でも「誰が」「誰のために」「どのポリシーに基づいて」「その権限を承認したのか」を証明する機能などです。こうした作業は監査サイクルごとに発生し、組織内でエージェントが増加するたびに負担は膨れ上がります。
OWASPは、AIエージェント活用アプリケーションにおける重大リスクの第3位に「エージェントのアイデンティティと権限の乱用」を位置付けており、その要因として管理責任者の曖昧さ、不要な権限継承、キャッシュされたトークンの残存を指摘しています。これらはまさに、自社開発のレジストリが限界を迎えた際に生じるセキュリティの死角そのものです。
目まぐるしく変化を続けるMCPおよびOAuthのセキュリティ標準
エージェントの認可に関する標準仕様は、現在も策定が進められている段階です。事実、過去12か月だけでも各種ガイダンスに以下のような大きな転換が見られました。
| 日付 | 仕様/規制の更新 |
|---|---|
| 2025年6月 | Model Context Protocolの認可仕様においてOAuth 2.1が採用され、クライアントトークンをそのままダウンストリームAPIへ受け渡すことが明示的に禁止されました。 |
| 2025年9月 | IETF OAuthワーキンググループは、企業のアイデンティティプロバイダーからサードパーティアプリケーションへの安全なアクセス委任の基盤となるIdentity Assertion Authorization Grantを策定・採択しました。 |
| 2026年7月 | MCP仕様では、認可サーバーの発行者（Issuer）検証が義務付けられるとともに、クライアント登録方式がクライアントIDメタデータドキュメントを参照する形式へと移行しました。 |
さらに、MCPセキュリティに関する米国家安全保障局（NSA）のガイダンスでは、同プロトコルにおいてトークンのリフレッシュや失効手順が規定されていないため、アクセスレイヤーを自社構築するチームは、そうした動作の安全性を各自で設計・担保しなければならないと指摘しています。
仕様が変更されるたびに、誰かが新しい仕様を読み、コードを更新し、再テストを行う必要があります。
自社開発のトークンブローカーがエンタープライズSaaSの認可で失敗する理由
自社開発のブローカーは、SaaSアプリケーションが発行済みのトークンを保持・リフレッシュすることはできても、自らの権限でアクセスを認可することはできません。各SaaSアプリはユーザーのアイデンティティを保証する信頼先として特定のアイデンティティプロバイダー（IdP）を指定しており、アプリベンダーはそのような信頼関係をごく一部の実績ある主要IdPとの間にしか構築しないためです。自社運用のブローカーがその信頼リストに含まれていない場合、新しいアプリを導入するたびに、ユーザーごとの同意画面の表示や管理者による手動の権限付与作業を延々と繰り返すことになります。
Cross App Accessのアプローチは根本から異なります。アイデンティティプロバイダーがエージェントに対してスコープを限定したアクセス権を直接付与するため、IT管理者が一度ポリシーを設定するだけで、エンドユーザーは同意画面を介す必要がなくなり、アクセス制御を完全に一元化できます。これに対応するSaaSアプリケーションは増加しており、Model Context Protocolでも同様のパターンが企業管理型の認可モデルとして採用されています。
自社開発か外部調達か：エンジニアリングの開発スピードをコアビジネスに集中させる
AIエージェントの価値は、ビジネスにおいて実際に何を担うかによって決まります。すなわち、どのワークフローを自動化し、どのデータを集約し、どの意思決定を迅速化するかという具体的な役割にほかなりません。エンジニアがトークンの更新ロジックの維持、次のSaaSアプリのための同意フローの再構築、監査人向けのアクセスレビューレポートの作成などに時間を費やすたびに、エージェント自体の開発に充てる時間が失われます。
ほとんどのプラットフォームエンジニアは、アイデンティティサービスの運用よりも、エージェント機能の構築を優先したいと考えています。
開発した成果物はそのまま活かし、下位の基盤レイヤーを外部調達
各チームが初期のエージェントのために構築したアクセスレイヤーは、当時の急務を解決するには十分でした。しかし、その下層に位置するアイデンティティ基盤の構築・運用には、まったく別の次元の責任とコミットメントが求められます。自チームが関与していないエージェントを含む社内のあらゆるエージェントを網羅し、自社の統制が及ばない外部アプリケーションとも連携し、変化し続ける標準仕様に追従しながら、エージェントが稼働し続ける限り監査サイクルごとに確実に監査証跡を提示し続けなければならないからです。
セキュリティレイヤーに投資することで、エンジニアはビジネスを前進させるコアなエージェント開発に集中できるようになります。同時に、セキュリティおよびITチームは単一のコントロールプレーンからすべてのエージェントを可視化・制御できるようになり、絶え間なく変化する仕様標準への対応、インテグレーション開発、ガバナンスの維持管理といった運用負荷を、アイデンティティを専業とする外部チームへと完全に移行させることができます。
Okta® for AI Agentsは、お客様が現在運用している既存のアイデンティティプロバイダーやゲートウェイとシームレスに共存・連携するエージェント専用のアイデンティティレイヤーです。組織内に配備されたすべてのエージェントフリートに関して、以下の4つの極めて重要な問いに対する明確な答えを提供します。
- エージェントはどこにいるのか？ ：ディスカバリーと登録
- エージェントは何ができるのか？：スコープとエンタイトルメント管理
- エージェントは何を実行しているのか？：一元的な監査ログの記録
- どう対応すべきか？：権限失効の自動化と脅威の隔離
バイヤーズガイド：技術的な詳細とセキュリティレビューのフレームワーク
セキュリティレビューでアイデンティティベンダーに尋ねるべき質問など、詳細な分析については、ホワイトペーパー『AIエージェントのアイデンティティ：購入か、自社構築か？』をお読みください。
これらの資料は、一般的な情報提供のみを目的としており、法律、プライバシー、セキュリティ、コンプライアンス、またはビジネス上の助言ではありません。
このコンテンツは、最新のセキュリティ、法律、および/またはプライバシーの動向を反映していない可能性があります。このコンテンツの利用者は、自身の責任において、自身の法的および/または専門的アドバイザーから助言を得るものとし、コンプライアンス、実装、購入の意思決定のために本資料の情報に依存すべきではありません。
Oktaは、本コンテンツに関していかなる表明または保証も行いません。また、これらの推奨事項をお客様が実施した結果生じるいかなる損失または損害に対しても、Oktaは責任を負いません。お客様に対するOktaの契約上の保証に関する情報は、okta.com/agreementsをご覧ください。
