AI Agentをどう管理する？～「シャドーAI Agent」とアイデンティティ管理

こんにちは、ポストセールスおよびカスタマーサクセスを担当している林です。

最近、「AI Agent」という言葉を目にする機会が増えてきました。AI Agentというと、「チャットボットのように質問へ回答する仕組み」または「手の込んだ自動化スクリプト」をイメージされる方も多いかもしれません。しかし、最近では、GitHub、Slack、Salesforceといったアプリケーションへ接続し、ユーザーの代わりに具体的な作業を実行するAI Agentが登場しています。

便利になる一方で、企業が把握していないAI Agentが増えていくという新たな課題も考えられます。私自身も最近、AI Agentとアイデンティティ管理の関係を調べています。当初は、Agent Identity（Agentの識別管理）、MCP（Agent連携の仕組み）、ID-JAG（Agent間およびAgent-アプリケーション間での認可の標準仕様）、OAuth STS（トークン交換技術）といった技術要素に注目していました。

しかし、関連資料を読み進めるうちに、それらを理解する前に「企業は増えていくAI Agentをどのように把握し、管理するのか」を整理する必要があると気付きました。そこで注目したのが、Okta Workforce Identityに関連するAI Agent管理向けの機能群である「Okta for AI Agents（以下、O4AA）」です。

本記事では、従来の「シャドーIT」と比較しながら、AI Agentの普及によって生まれる「シャドーAI Agent」という新たな管理課題を整理します。そのうえで、Cross App Access（以下、XAA）やO4AAが、この課題にどう関係するのかを紹介します。なお、「シャドーAI Agent」は、現時点で標準用語とは言い切れません。本記事では、「企業が把握・管理していない状態で利用・運用されるAI Agent」を指す便宜的な表現として用います。また、次のポイントについて分かりやすく整理していきます。

• AI Agentの普及によって何が変わるのか
• シャドーAI Agentという新しい課題
• AI Agentをどう管理するのか
• O4AAとの関係

AI Agentが増えると何が変わるのか

従来の業務システムでは、基本的に「人」がアプリケーションへログインし、画面を操作する構造が中心でした。以下に、IdPを介した構成例を示します。

この場合、認証や認可も、基本的にはユーザーを起点として考えれば十分でした。誰がどのアプリケーションへログインするのか、特権ユーザーか一般ユーザーか、こうした情報を管理することで、企業は一定のアクセス管理を実現できていました。

AI Agentがもたらした変化

AI Agentが業務を代行するようになると、この構造が変わります。ユーザー自身が直接操作するのではなく、AI Agentがユーザーの代わりに複数のサービスへアクセスしながら業務を進める場面が増えていきます。そうなると、新たに「そのAI Agentを誰が管理するのか」という課題が生まれます。企業は人間だけでなく、AI Agentについても存在や権限を把握し、統制しなければならなくなります。

シャドーAI Agentという新しい課題

O4AAやXAAを調べていて特に印象深いのは、Okta, Inc.（以下、Okta）がAgentic Enterpriseの課題として提示している次の3つの問いです。

• Where are my agents?
• What can they connect to?
• What can they do?

※ 参考：セキュアなエージェント型エンタープライズのためのフレームワーク | Okta

この問いを見ていくと、従来の「シャドーIT」と似た構図が見えてきます。企業が把握できていないものを可視化し、管理しなければならない点は共通しています。

これまでのシャドーITでは、企業が把握していないクラウドサービスやSaaSが主な管理対象でした。しかし、AI Agentの時代にはサービスだけでなく、「業務を代行する主体そのもの」も管理対象となります。例えば社員が、業務効率化のためにChatGPTやClaude、Cursorを利用したり、MCP Serverと連携する独自のAI Agentを利用したりするケースです。

Agentic Enterpriseの課題を企業の視点で捉えると、情報システム部門やセキュリティ部門は、どのAI Agentが存在し、どの部署や利用者が活用し、どのシステムやデータにアクセスでき、どのような権限で何を実行できるのかを把握する必要があります。従来のシャドーIT対策が「利用サービスの可視化」を目的としていたのに対し、AI Agent時代には「業務を代行するAgentの可視化と統制」が新たな課題となります。

AI Agentをどう管理するのか

ここで、1つの疑問が浮かびます。AI Agentが業務システムへ接続するのであれば、現在、広く使われているOAuthを利用すれば十分なようにも見えます。しかし、OAuthによるアクセス許可では、ユーザーに同意画面が表示されます。ユーザーが内容を十分に確認せず許可してしまえば、意図しない権限をAI Agentに与えてしまう可能性があります。

また、従来のOAuthではトークンのみで「どのエージェントが、どのユーザーの代理で実行したのか」を把握することができません。ユーザー個人の判断に委ねるだけでは、企業としてAI Agentのアクセスを適切に管理するのは難しくなります。

本来、AI Agentにどの権限を与えるのかは、個々のユーザーに委ねるのではなく、組織のポリシーとして管理されるべきではないでしょうか。「AI Agentの活動を把握し、ガバナンスを効かせたい」という要求こそが、現在のアイデンティティ管理に求められています。

XAAが解決しようとしていること

こうした課題を考えていく中で出会ったのが、標準プロトコルのCross App Access（XAA）です。XAAは、Oktaが提唱を進めている仕組みで、OAuthをベースにAI Agentなどが複数のアプリケーションへアクセスする際の認可を組織として管理することを目指しています。私はXAAを、Identity Provider（IdP）を中心にAI Agentとアプリケーション間の接続を管理するための考え方として捉えています。

※ Cross App Access | AIエージェントとアプリの接続を制御する | Okta

なお、XAAは実装名であり、その背景にあるのは、ID-JAGというベンダー中立の標準仕様です。XAAでは、ユーザーごとの判断に依存するのではなく、組織のポリシーに基づいてAI Agentのアクセスを管理し、接続先や権限を可視化することを目指しています。これは、前章で触れた「シャドーAI Agent」の課題ともつながります。

では、XAAはこうした課題に対して、具体的にどのような仕組みを提供するのでしょうか。続いて、Oktaが提唱するXAAについて整理します。

XAAの仕組み

XAAは、トークン交換を定めたRFC 8693と、認可付与に用いるJWTプロファイルを定めたRFC 7523を組み合わせた仕組みです。特長的なのは、トークン交換を行う点です。AI Agentがユーザーに代わって別のアプリケーションへアクセスする場合、単にユーザーの認証情報を引き継ぐのではなく、アクセス先に応じたトークンへ交換して利用します。これについては、公開されている技術資料やサンプル実装からも確認できます。

この仕組みにより、アプリケーション同士を接続するだけでなく、「誰の代理として、どのAI Agentがアクセスしているのか」を意識したアクセス管理が可能になります。

XAAの重要な点は、AI Agentが取得したIDトークンを、業務アプリが検証可能なID-JAG（Identity Assertion JWT Authorization Grant、いわゆるCross-Domain JWT）へ交換することです。業務アプリはこのID-JAGを検証することでAgentの正当性を確認したうえで、アクセストークンを払い出せます。

※ 参考：Cross App Access: A Protocol for AI and App Security | Okta

※ 最近では、Non-Human Identityからのアクセスも考慮して、Accessトークンからの交換にも対応しています。

企業がAI Agentを業務で利用する場合、このような仕組みに沿ってAgentを実装・接続することで、どのAgentが、どのサービスへアクセスしているのかを組織として把握しやすくなります。一方で、すべてのAI Agentがこうした仕組みに従って実装・運用されるとは限りません。社員が独自にAI Agentを作成したり、外部のAI Agentを利用したりすることで、企業が把握していないAgentが生まれる可能性があります。

つまり、AI Agentの「安全な接続方法」を整備するだけでは十分ではありません。その前提として、「そもそも、どのAI Agentが存在しているのか」を把握し、管理する必要があります。こうした課題に取り組むものとして、次にO4AAを紹介します。

O4AAとの関係

ここで、私が最初に興味を持ったO4AAの話に戻ります。O4AAは、AI Agentと業務システムの接続を安全に管理するだけでなく、AI Agentをディレクトリへ登録し、組織のポリシーに基づいて管理していくための仕組みとして位置づけられています。

具体的には、O4AAには「Shadow AI Agent Discovery」機能があります。現時点ではブラウザプラグインを利用して企業内のAI Agentの利用状況を観測し、どのようなAI Agentが使われているのかを把握できる機能が提供されています。こうした可視化は、企業が把握していない「シャドーAI Agent」の発生を抑えることにもつながります。

また、前章で紹介したXAAは、AI Agentと業務システムを安全に接続するための技術です。O4AAでは、Shadow AI Agent Discoveryによる可視化に加え、Universal DirectoryやAPI Access Managementをはじめとする機能を組み合わせながら、AI Agentの接続先や権限を管理していく考え方が示されています。

つまり、XAAが「安全な接続」を実現するための技術的な基盤であるとすれば、O4AAは「AI Agentの存在を把握し、継続的に管理する」ための仕組みと捉えると分かりやすいでしょう。重要なのは、AI Agentがどこで、誰によって構築されたかにかかわらず、企業としてその存在を把握し、ディレクトリに登録し、ガバナンスやコンプライアンスの対象として扱える状態をつくることです。なお、O4AAには、ここでは紹介しきれなかった機能がまだありますので、別の機会に紹介できればと思います。

さいごに

今回整理してきたように、XAAやO4AAは、「AI Agentを企業が管理できる状態にする」ための取り組みとして捉えると理解しやすくなります。調査を進める中で私が強く感じたのは、AI Agentの活用そのものよりも、企業がそれらを把握し続けられるのかという視点の重要性です。

AI Agentが業務の中に入り込むほど、企業が管理すべき対象も変わっていきます。これまで人やデバイス、アプリケーションを対象としてきたアイデンティティ管理に、今後はAI Agentも加わっていくのではないでしょうか。

Oktaが示す「Where are my agents?」「What can they connect to?」「What can they do?」という問いは、まさにこの変化を表しています。AI Agentがどこに存在し、何に接続し、何を実行できるのか。これらを継続的に把握し、組織のポリシーに基づいて統制できる仕組みが、これからの企業には求められるのではないでしょうか。

こうした検討を含め、AI Agentの管理やアイデンティティ・ガバナンスについてご関心がありましたら、ラックまでお気軽にお問い合わせください。

プロフィール