編集者注：本稿の内容を実現する方法については、最新のストリームキャストのエピソード「セキュアなエージェンティック企業のための設計指針」をご覧ください。理論から実証へと踏み出したこのエピソードでは、AIエージェントを安全に運用するための設計指針を、Claude CodeやCursorといったツールに対する実践的な統制へと具体的に落とし込む方法について解説しています。
今すぐAIエージェントを実稼働させる必要があるAIチームにとって、ガバナンスのギャップによってデプロイが遅れることは許されません。
テクノロジー分野の上級管理職を対象とした2026年の調査によると、90%の組織が、本番環境でエージェントが実際に何を行っているかを管理する手段を持っていません。さらに約54%は、エージェントの予期せぬ動作に起因するセキュリティインシデントをすでに経験しています。
こうしたエージェントは、APIを呼び出し、機密性の高いレコードを読み取り、他のエージェントにタスクを委任し、人間の入力を待つことなく意思決定を行います。問題は、組織でこのようなエージェントが稼働しているかどうかではありません。エージェントが動作する際に、その挙動に対して実効性のある統制を効かせられているかどうかにあります。現在のほとんどの企業にとって、正直な答えは「ノー」でしょう。
その答えが「ノー」である原因は、ほぼ間違いなくアイデンティティガバナンスの課題にあります。本番環境のすべてのAIエージェントは、統制されたアイデンティティレイヤーを介して動くか、それを迂回して動くかのどちらかです。そして、その大半は迂回して動作しているのが実態です。
アイデンティティガバナンスの適用範囲のさらなる拡大
企業においてエージェントを安全に活用するためには、次の3つの重要な問いに答えるためのフレームワークが必要です。
- エージェントはどこにいるのか？
- 「エージェントは何と繋がることができるのか？」
- エージェントは何ができるのか？
本稿で紹介する機能は、まさにこの2つ目と3つ目の質問について、「セキュアなエージェンティック企業のための設計指針」をさらに進化させる新しい機能強化です。これにより、AIチームはより迅速な開発・リリースが可能になり、セキュリティチームはAIエージェントの利用にGOサインを出すために不可欠な、リアルタイムのポリシー適用、対応制御、監査性を確保できます。
「エージェントは何と繋がることができるのか？」
今この瞬間も、組織のどこかで、あるAIエージェントが別のエージェントへと密かにタスクを引き継いでいるかもしれません。
しかし、ここに問題があります。こうしたハンドオフはすべて、本来ガバナンスの統制下に置くべきアクセスイベントなのです。しかし、アイデンティティレイヤーが存在しなければ、大半のセキュリティチームはそれをまったく可視化できません。
現在、多くの企業は主に2つの方法でマルチエージェントワークフローを構築しています。
- ユーザー起点のワークフロー：従業員がエグゼクティブアシスタントエージェントに四半期ビジネスレビュー（QBR）の資料作成を依頼するようなケースです。主軸となるエージェントが複数のエージェントをオーケストレーションし、各エージェントはユーザーの代理として、そのユーザーがアクセスを許可されているスコープ内でのみ動作します。このパターンでは、人間が基点となり、すべてのハンドオフを通じてアイデンティティが引き継がれます。
- マシン起点のワークフロー：監視サービスが異常を検知して診断エージェントを起動し、そこからさらに詳細な調査のためにログ分析エージェントにタスクを委任するようなケースです。ユーザーセッションがなく、人間の介入もありません。元となるサービスの権限が、チェーン内のすべてのエージェントへと順次継承されていきます。
どちらのパターンも、ガバナンスのニーズは同じです。すべてのハンドオフはアクセスイベントであり、承認、スコープ設定、ログ記録を行う必要があります。専用のアイデンティティレイヤーを介さずにAIエージェント同士が通信すると、企業は各リクエストの背後にいる実際の主体のアイデンティティを検証したり、ポリシーを一貫して適用したり、実行されたアクションを発生源まで遡って追跡したりできなくなる恐れがあります。
Agent-to-Agent Connections：マルチエージェントワークフローのセキュリティを確保
Okta for AI Agentsの新機能である「Agent-to-Agent Connections」は、まさにこのガバナンスのギャップを解消します。この機能により、エージェントごとの接続ポリシーを定義し、どのアップストリームのサービスやエージェントが対象のエージェントを呼び出せるか、そのスコープ、および権限の有効期間をコントロールできるようになります。すべてのやり取りでアイデンティティが引き継がれるため、ワークフロー全体を通じてあらゆる接続の検証可能性が維持されます。
これを実現するには、3つの原則があります。
- 明示的な許可リスト：どのエージェントが他のどのエージェントを呼び出せるかを定義します。
- スコープが限定された権限：各ダウンストリーム（呼び出される側）のエージェントに対し、タスクの実行に必要な権限のみを付与します。
- 検証可能なチェーン：すべてのトークンにこの情報が付随するため、誰が何を認可したかを監査ログで把握できます。
これこそが、エージェント間レイヤーにおいて「エージェントが何に接続できるか」を統制するということです。つまり、どのエージェントが他のどのエージェントを、どのような条件下で、どのようなスコープで呼び出せるかを管理し、監査人やインシデント対応チームからの要請に応じていつでも提示できるエビデンスを確保することを意味します。
提供状況：Agent-to-Agent Connectionsの早期アクセス版はすでに利用可能です。詳しくは、「Agent-to-Agent Connectionsによるマルチエージェントワークフローのセキュリティ確保」をお読みください。
Claude Code、Microsoft 365 Copilot、CursorなどのAIコーディングアシスタントを保護
エージェント間の接続は、接続性に関する課題の一面にすぎません。もう一つの大きなギャップは、開発者がすでに自社システムへの接続に使用している、ガバナンスの行き届いていないAIツールです。これには、Claude Code、Cursor、Microsoft 365 Copilot、GitHub Copilot、GleanなどのAIコーディングアシスタントが含まれます。
これらのツールは日常的なワークフローに組み込まれており、Jira、ServiceNow、GitHub、さらには社内の独自APIといった内部システムに接続されています。
ここで問題となるのは、こうしたツールがシステムにどのようにアクセスしているかという点です。これらのツールのほとんどは、アイデンティティプロバイダーを介して認証を行うようには作られていません。ハードコードされたトークン、その場限りの資格情報、構成ファイルに保存されたAPIキーを介してアクセスを取得します。認可は一元管理されておらず、監査証跡も存在しません。そのため、多くのセキュリティチームが、どのエージェントが、誰を代行して、どのシステムにアクセスしたのか、またアクセスした後に何を実行したのかを、まったく可視化できていないのが現状です。
MCP Bridgeは、エージェント自体に変更を加えることなく、この課題に対処します。セルフホスト型のアイデンティティ認識プロキシが、エージェントと、その接続先となるModel Context Protocol（MCP）ツールの間に配置されます。すべての呼び出しがこのブリッジを経由し、すべてのエージェントがアイデンティティプロバイダーを通じて認証を行い、すべてのアクションが監査ログに記録されます。エージェントを書き換える必要はなく、開発者がワークフローを変更する必要もありません。
このブリッジはお客様の環境で実行されるため、データは境界内に留まります。外部のいかなるサービスも、そこを通過するデータを閲覧することはできません。デプロイ、設定、そしてデータに対する完全なコントロール権は、常にお客様側にあります。
提供状況：MCP BridgeはProfessional Servicesとしての提供となり、ご利用にあたっては作業範囲記述書（SOW）の締結が必要となります。
エージェントは何ができるのか？
エージェントが何を実行できるかを統制するには、アイデンティティレイヤーが初期アクセスの先まで踏み込む必要があります。アクセストークンはエージェントを入り口まで通すことはできますが、一度中に入ったエージェントがそこで何を行うかまでを統制することはできません。
AIエージェントの認可：AIエージェントのすべてのアクションに対して実行時の認可を適用
ユーザーの権限は、トークンが発行された後に変更されることがあります。外部委託業者がプロジェクトから外れることもあれば、患者が同意を撤回することも、マネージャーが休暇に入ることもあります。静的なロールやアクセストークンでは、こうした変化に追いつくことはできません。「このユーザーまたはエージェントはシステムへのアクセス権を持っているか」と問いかける代わりに、AIエージェントの認可では、「このエージェントは、このユーザーに代わって、このリソースに対して、今このアクションを実行できるか」という、より精密な問いかけが行われます。
この違いは極めて重要です。なぜなら、認可の条件は常に変化するからです。きめ細かな認可（FGA）とは、単にロールだけでなくコンテキストを読み取る認可の仕組みです。FGAは、エージェントが代行しているユーザーが、実行時において、特定のリソースに対して特定のアクションを実行するために必要な関係性、現在の属性、ポリシー条件を満たしているかを検証します。
これには、直接的および継承的な関係、クリアランスレベルや勤務ステータスなどの動的な属性、数量制限・金額・データ分類ルールなどのポリシーのしきい値が含まれます。
例えば、調達エージェントは、自分が代理で動作しているユーザーのために1万ドルまでの請求書を承認できますが、そのしきい値を超える承認はできません。FGAは、単にそのユーザーのロールを確認するだけでなく、承認限度額も実行時にチェックします。
エージェントが何を実行できるかを統制するには、デプロイ時に設定される静的な権限だけでは不十分です。すべてのエージェントのあらゆるアクションを、リアルタイムで継続的に評価し続ける必要があります。これこそが、エージェントが実際に何を行うかを制御する方法なのです。
提供状況：本機能はFGAおよびOkta for AI Agentsのユースケース実装としてご利用いただけます。
キルスイッチ：暴走したエージェントを、必要なその瞬間にシャットダウン
最初からガバナンスを組み込んでおけば、問題が発生する可能性は低くなりますが、問題が絶対に起きなくなるわけではありません。エージェントはその設計上、予測不可能です。自ら意思決定を下し、システム間を移動し、誰も予期しなかったアクションを実行することがあります。そのような事態が発生した場合、セキュリティチームは直ちに対応する必要があります。
現在、多くのAIエージェントのデプロイにおいては、エージェントが予期せぬ挙動をした場合にそれをシャットダウンする手段がありません。取締役会から「エージェントが暴走した場合の対応計画は何か」と問われても、ほとんどのCISOは答えられません。
キルスイッチがあれば、その状況は一変します。Okta経由で接続しているエージェントの場合、Okta Admin Consoleからの単一のアクションでアクセス権を取り消すことで、接続されているすべてのリソースへのアクセスを遮断できます。この機能を使用するために、エージェントが侵害されたことを確定させる必要はありません。設定ミス、スコープ外のアクション、疑わしい挙動など、そのいずれも、ただちにエージェントを無効化する十分な理由となります。何が起きたのかの詳しい調査は、その間に進めることができます。
その結果もたらされるものとは何でしょうか。AIチームは、セーフティネットが整備されているという安心感のもとで製品を開発・リリースできます。セキュリティチームは、万一問題が発生した場合でも対応できるという確信を持って、デプロイを承認できます。阻止できるとわかっているからこそ、承認できるのです。
提供状況：キルスイッチ機能は一般提供（GA）されており、Okta for AI Agentsに含まれています。近日提供予定：Oktaエコシステム全体からリスクシグナルを読み取り、エージェントのリスクスコアを引き上げて、キルスイッチを自動的にトリガーする検知機能。
すべてのエージェントに求められるアイデンティティレイヤー
これらの機能は、エージェントガバナンスの課題のさまざまな側面に対処するものですが、どれも共通の前提に基づいています。従業員やアプリケーションのセキュリティを確保するアイデンティティの基本構成要素を、エージェントにも拡張する必要があるということです。エージェント間の接続、エージェントが実行するアクション、エージェントが使用するツールの統制、そして万が一問題が発生した際にそれらを停止できる能力の確保が含まれます。
このような方法でエージェントを統制するには、すでに自社の従業員やアプリケーション全般をカバーしている、信頼できるリアルタイムのアイデンティティレイヤーが必要不可欠です。Oktaはそのレイヤーに位置しています。
この取り組みを早期に成功させた企業は、単にインシデントを削減できるだけではありません。ビジネスのスピードをさらに加速させることができます。最初から検出、セキュリティ、ガバナンスを組み込んでおくことは、AIのデプロイを遅らせる足かせになるどころか、むしろ将来的なスケーリングを可能にするために不可欠な土台となります。今すぐ基盤を構築することで、セキュリティチームはエージェント展開のボトルネックではなくなり、その成功を支える原動力へと変わるはずです。
これらのアップデートに関する詳細については、ストリームキャストウェビナーをご視聴ください。実際の動作を解説したデモもご覧いただけます。
本資料は、一般的な情報提供のみを目的としており、法律、プライバシー、セキュリティ、コンプライアンス、またはビジネスに関する助言を意図したものではありません。セキュリティ、プライバシー、コンプライアンス、またはビジネスに関するアドバイスについては、お客様ご自身の専門アドバイザーにご相談ください。本ブログで言及されている将来の製品、機能、仕様、認定に関する記述は、情報提供のみを目的としています。これらは提供を確約するものではなく、購買の意思決定を行う際に依拠すべきものではありません。© Okta, Inc. and its affiliates. 2026
