AIエージェントは依然として人間としてログイン中―その監査証跡が高くつく

エンタープライズは過去4年間、AIエージェントを、もともとそれらを独立したアクターとして認識するよう設計されていなかったアイデンティティ基盤に後付けしてきました。このミスマッチは、今やインシデントの事後分析だけでなく、データにも明確に現れています。2万社以上の組織から匿名化されたサインオンアクティビティを基にした新たなレポートによると、エンタープライズ環境内でのAIエージェントの動作は、生成AIが登場した当初とほぼ変わらず、人間として、または人間を介して認証されているのが実態です。

このレポートはOkta Enterprise AI Indexであり、2022年6月から2026年6月まで、100種類以上のAI製品を74のベンダースイートに統合して分析しています。このデータセットの規模こそが、今回の発見を例外的なケースとして片付けられない理由です。これは、あるベンダーの設定ミスや、1社のAI導入の拙速さに関する話ではありません。何万もの組織が、意図的に、あるいはデフォルトで、同じ方法でAIエージェントのワークフローを認可しているというパターンなのです。

成長率の見出しは非常にインパクトがあります。Anthropic、OpenAI、CursorといったAIネイティブ企業は、調査期間中にエンタープライズ顧客基盤を4倍以上に拡大し、Anthropicは2026年3月にエンタープライズアカウント数でOpenAIを抜き、翌月には月間アクティブユーザー数でも追い抜きました。これらのマイルストーンは、エージェント型AIが実験段階から標準的なエンタープライズツールへと急速に移行している現実を示しています。しかし、より重要な発見は成長曲線の裏側にあります。AIエージェントのアイデンティティとアクセス管理の運用は、エージェントの導入スピードに追いついていません。

Kiteworksのセキュアデータ交換は、異なる前提に基づいて構築されています。つまり、人間であれ機械であれ、機密コンテンツに触れるすべてのアクターには、検証可能なアイデンティティ、スコープされた権限、そして監査証跡上の独自エントリーが必要であるというものです。この前提こそが、今回のレポートで多くのエンタープライズAI導入に欠けていると指摘されている点です。

主なポイント

1. エンタープライズAIの導入が、アイデンティティ管理の実態を上回っている

4年間・2万社以上を対象とした新たなサインオンデータによれば、AIネイティブベンダーのエンタープライズアカウントは4倍以上に増加した一方、これらのツールを支えるアイデンティティモデルはパイロットプロジェクト時代からほとんど変わっていません。

2. エージェントはいまだに人間の認証情報を借用している

OktaのリサーチャーFei Liuによると、サービスアカウント、静的APIキー、共有ログインが、組織がAIエージェントのワークフローを認可する際のデフォルト手段となっており、いずれも自律型ソフトウェアアクターを想定して設計されたものではありません。

3. 借用されたログインは、監査証跡を破壊する

AIエージェントが人間として認証されると、ログにはその人の名前で、実際には本人が行っていない操作が記録されます。これにより、インシデント発生時にエージェントの実際の行動を再現することがほぼ不可能になります。

4. AnthropicとOpenAIのエンタープライズ競争は「現象」であって本質ではない

2026年初頭にAnthropicがエンタープライズアカウント数と月間アクティブユーザー数でOpenAIを抜いたことは、エージェント型AIがコア業務ワークフローに急速に組み込まれている現実を示していますが、アイデンティティとアクセス管理の多くがその統治に追いついていないことの現れでもあります。

5. エージェント単位のアクセス制御がギャップを埋める

AIエージェントごとに統治されたアイデンティティ、権限、監査記録を割り当て、人間のセッション経由で運用するのではなく、個別に管理することが、統治可能なAI導入と、無秩序な導入の分かれ目です。

サービスアカウント、静的APIキー、共有ログイン：エージェントのアイデンティティが崩壊する3つのパターン

レポートで引用されたOktaのFei Liuによれば、組織はAIエージェントのワークフローを認可するために、サービスアカウント、静的APIキー、場合によっては共有ログインという3つの仕組みに大きく依存しています。いずれも短期的な統合課題は解決しますが、長期的なガバナンス課題を生み出し、多くの組織がまだそのリスクに向き合えていません。

この3つの中で最も一般的なのがサービスアカウントです。サービスアカウントは、AIエージェントにアプリケーション内で非人間の指定アイデンティティとして動作させるものですが、実際の運用や監視のされ方を見ると、理想的なアプローチとは言えません。多くのサービスアカウントは一度作成されると、エージェントが将来的に必要とするであろう広範なアクセス制御が付与され、そのまま放置されがちです。エージェントの役割が拡大しても権限の見直しは行われず、個々の操作が特定のタスクやリクエスト、ビジネス上の正当性に紐づけられることもありません。アカウントは存在し、エージェントはそれを使い、ログにはアカウント名だけが記録され、実際の業務内容は記録されません。サービスアカウントがアクセスできるコンテンツにデータ分類ラベルを適用することが、アクセス範囲を正確にスコープするための前提条件です。これがなければ、ガバナンスプログラムはエージェントのアクセス先に対して機密度に応じた制限を適用できません。

静的APIキーにも同様の課題があり、運用面でさらに複雑化します。エージェントがファイルを読み込んだり、データベースをクエリしたり、内部システムを呼び出すためのキーは、通常有効期限がなく、自動的にローテーションされず、設定ファイルや環境変数、あるいは最悪の場合はプロンプトやエージェントのコンテキストウィンドウに直接コピーされることもあります。これにより、誰にも気づかれずにキーが漏洩・記録・流出するリスクが高まります。一度でも複数箇所にキーが存在すれば、「誰がアクセスできるのか」は誰にも自信を持って答えられなくなります。

3つ目のパターンである共有ログインは、最も懸念すべきものです。これは、人とプロセスの区別が完全に崩壊するためです。従業員の認証情報が自動化スクリプトやボット、AIエージェントに渡され、システム上で「その人」として動作しますが、機械用のアイデンティティ発行経路がないためです。この時点から、エージェントの全ての操作は、あたかも人間が実行したかのようにログに記録されます。AIエージェントが利用した共有ログイン経由でデータ侵害が発生した場合、組織は侵害範囲を正確に特定できなくなります。HIPAA、GDPR、同等のフレームワーク下では、肯定的な証拠がない限り、最大範囲での通知義務が発生しますが、人間とエージェントが混在した監査証跡では、その証拠を提供できません。

「AIエージェントが人間のログインを引き継ぐと監査証跡が失われる」ことがCISOにとって深刻な理由

レポートでのLiuの警告は明確です。「AIエージェントが人間のログインを引き継ぐと、監査証跡は完全に失われます。」これは曖昧なリスクではなく、具体的かつ機械的な失敗を指しています。監査証跡は、事後に「誰が、いつ、何を、なぜ」行ったかを特定できて初めて意味があります。エージェントが人間のセッションで動作してしまうと、全てのイベントで誤ったアクターが記録されます。ログ上の名前は正しくても、実際の出来事は正しく反映されません。

これは、監査証跡が本当に必要となる瞬間、つまり侵害調査、コンプライアンス監査、規制当局の調査、機密コンテンツの社内流通の経路確認などで最も問題となります。どのケースでも、最終的に「これは人がやったのか、自動化プロセスなのか、その権限は何か」という同じ問いが投げかけられます。「エージェントがSarahとしてログインしていたので分かりません」としか答えられなければ、調査は行き詰まり、コンプライアンス対応は弱体化し、アクセス制御の実効性も、NIST CSF、ISO 27001、SOC 2などが求める水準を満たせません。クリーンなエージェント単位の監査ログをリアルタイムでSIEMに連携することで、エージェントの行動証跡を事後のフォレンジックツールから、侵害発生前に異常検知できる運用層へと進化させることができます。

また、インシデントが起きる前から静かに現れるコストもあります。日常業務の中で説明責任が徐々に失われていくのです。誰がどの操作を行ったのか、人間なのかエージェントなのかが特定できないと、例外承認やデータアクセスレビュー、最小権限の徹底が困難になります。レビュアーは、エージェントの必要範囲を特定できないため、広範なアクセスを承認しがちです。こうしてセキュリティの設定ミスは、1つの大きな判断ミスではなく、合理的に見える小さな判断の積み重ねによって拡大していきます。もともと人間とソフトウェアの区別を前提としていないアイデンティティモデルの上に、こうした運用が積み重なるのです。

シャドーAIはデータ問題の前にアイデンティティ問題である

シャドーAIの議論は、多くの場合「機密データがどこに流れるか」、つまり未承認モデルや未承認プラグイン、誰も精査していないブラウザ拡張などに焦点が当たりがちです。しかし、Oktaのデータはそれ以前の問題を示しています。エージェントがデータを移動・公開する前に、必ずどこかで認証が発生します。その認証が共有アカウントや管理されていないAPIキー、借用ログイン経由で行われていれば、データガバナンスの議論が始まる前に、組織はすでに可視性を失っています。

だからこそ、アイデンティティはAIガバナンスの議論で最優先されるべきであり、データ損失防止の補足事項ではありません。スコープされた適切なアイデンティティを持つエージェントは、設計上の制約を受けます。つまり、その役割で許可された範囲しかアクセスできず、すべての操作が特定のエージェントとタスクに紐づきます。一方、人間のセッションや広範なサービスアカウントで動作するエージェントは、実質的な制約がなく、その到達範囲は人間やアカウントの権限に依存し、エージェントのタスクに必要な範囲を大きく超えることが多いのです。AIデータガバナンスプログラムが、ポリシー文書だけでアイデンティティアーキテクチャを省略してしまうと、問題の半分しか解決できません。シャドーAI、すなわち正式なアイデンティティプログラムの外で動作するエージェントやAIツールは、そのギャップの直接的な結果です。インシデント発生時に組織が把握もスコープもできず、行動の責任も問えなくなります。

Kiteworks 2026年データセキュリティ＆コンプライアンスリスク年次予測レポートでは、AIガバナンスが今年の主要なデータセキュリティ課題の一つに挙げられています。Oktaの調査結果は、別の観点からこの結論を補強しています。つまり、エージェント型ツールの導入が、ゼロトラストなアイデンティティ・アクセス制御の整備よりも速いペースで進んでいるということです。サプライチェーンリスク管理プログラムが、アイデンティティガバナンス要件をサードパーティAIベンダーにも拡張し（顧客自身が導入するツールだけでなく、ベンダーが顧客環境に展開するエージェントも対象）、Oktaのデータが示唆するサプライチェーンのアイデンティティギャップを埋めることが重要です。

KiteworksがAIエージェントごとに検証可能なアイデンティティを付与する方法

Kiteworksは、Oktaの調査結果が示す出発点と同じく、人間もAIエージェントも、個別に認証・認可・ログ記録されるべき「ファーストクラスのアイデンティティ」であり、2つの異なるレイヤーではなく1つのガバナンスレイヤーで管理すべきだと考えています。Kiteworks Control Planeは、人・アプリケーション・エージェントのいずれからの機密コンテンツリクエストも、この単一モデルで統治するため、エージェントのアクセスが人間の認証情報や管理されていないサービスアカウント経由で迂回されることはありません。

Secure MCP Serverは、まさにこの課題のために設計されたコンポーネントです。OAuth 2.0による認証を行い、アクセストークンはOSのセキュアな認証情報ストアに保存され、AIモデル自体が読み取り・コピー・漏洩できる場所には保存されません。これは、エージェントに静的APIキーや共有パスワードを渡す設計とは本質的に異なります。エージェントは、プロンプトやログファイル、侵害されたセッションを通じて認証情報を漏洩することがありません。エージェントが行うすべての操作（ファイルの読み取り、フォルダの移動、タスク用コンテンツの取得など）は、RBACおよびABACポリシーにリアルタイムで照合され、個別に記録されます。単に「人がやった」と記録されるのではなく、エージェント単位で記録されるのです。これがFei Liuの警告への構造的な回答です。認証情報がセキュアストアから出ず、すべての操作が個別に認可・記録される限り、監査証跡が見失うような共有アイデンティティは存在しません。CISOダッシュボードは、このエージェント単位の監査テレメトリをリアルタイムで可視化し、Oktaレポートが指摘する「現状の多くの導入に欠けている」AI経由のコンテンツアクセスイベントの一元的な可視性をセキュリティリーダーに提供します。

Kiteworks Compliant AIは、エージェントの認証だけでなく、エージェントが「何を見て何を使えるか」にも同じ厳格さを適用します。コンテンツレベルのポリシー強制により、モデルのコンテキストウィンドウに到達する前に、エージェントがアクセス・保持できる範囲が決まります。これにより、アイデンティティ境界とデータ境界が相互に補強され、一方が他方に全面的に依存することがなくなります。このレイヤーでデータ最小化を適用することで、エージェントの認証情報が漏洩した場合でも、アクセス可能範囲が設計上すでに限定されているため、被害範囲を最小化できます。

RBACとABACによるエージェント単位のアクセス制御モデルの構築

アイデンティティギャップの解消には、「このエージェントが認証情報を持っているか」ではなく、「この特定のエージェントが、この特定のタスクのために、今まさに必要な権限を持っているか」という視点が必要です。これはロール・属性ベースの問いであり、静的なプロビジョニングの問題ではありません。

ロールベースアクセス制御（RBAC）は、各エージェントに実際の機能にスコープされた明確なロールを割り当てます。例えば、要約だけを行うエージェントには要約対象ドキュメントの読み取り権限のみ、ワークフローエージェントには特定フォルダへの書き込み権限のみを与えるなどです。属性ベースアクセス制御（ABAC）は、そこにさらにコンテキストを加えます。コンテンツの機密度分類、リクエスト時刻、エージェントのデプロイ環境、現在実行中のタスクなどが、認可の判断材料となります。RBACとABACを組み合わせることで、組織はエージェントに「今のタスクに必要な最小限のアクセス権だけ」を与え、「将来必要かもしれない」範囲まで広げることを防げます。これは、現在多くのサービスアカウントがプロビジョニングされている方法とは正反対です。

このモデルは、Oktaレポートで「欠けている」と指摘された「クリーンな監査ログ」も実現します。すべてのエントリーが実際のエージェント、実際のタスク、実際のポリシーに紐づき、他人の名前で「やっていない作業」が記録されることはありません。インシデントレビューやコンプライアンス監査で「何が起きたのか」と問われた時、答えはすでにログに正しく記録されています。AIエージェントの誤作動シナリオをカバーするインシデント対応計画（具体的には、侵害されたエージェントアイデンティティの隔離、認証情報の失効、アクセスしたコンテンツ範囲の特定など）を文書化することで、クリーンな監査ログをフォレンジック資産から運用対応力へと転換できます。

エンタープライズがAIエージェントのアイデンティティギャップを埋めるために今すべきこと

Oktaのデータセット（4年間、2万社超、100以上のAI製品）は、これは先進企業や遅れた企業だけの問題ではなく、ほぼ全ての組織に共通する課題であることを示しています。つまり、AIガバナンスプログラムの成熟度に関わらず、多くのセキュリティ・アイデンティティチームが取り組むべき課題があるということです。

レポートの発見から導かれる具体的なアクションをいくつか挙げます。まず、現状環境で稼働している全AIエージェントを棚卸しし、それぞれがどの認証情報（サービスアカウント、APIキー、人間のログイン）を使っているかを特定しましょう。把握できていないものは修正できません。次に、人間の共有ログイン経由で認証しているエージェントは、直ちに優先的に是正すべきです。これはレポートで最も深刻な監査証跡の喪失をもたらすパターンだからです。3つ目に、現在のIAM基盤が非人間アクターに対して個別・スコープされたアイデンティティを発行できるか、そもそも人間だけを前提に設計されていないかを評価しましょう。4つ目に、エージェントのアクセス判断をゼロトラストデータ交換の原則（すべてのリクエストを検証し、最小限のアクセスのみ許可し、結果を記録する）に基づいて構築しましょう。エージェントがどの認証情報タイプ・権限を持ち、実際のタスク要件と照らしてどこに共有認証情報や過剰なサービスアカウントが存在し、許容できないリスクを生んでいるかをマッピングする正式なリスク評価が、優先順位付けされた是正ロードマップの根拠となります。

これらは、侵害が発生してから着手するのでは遅すぎます。Oktaのデータは、エンタープライズがAIエージェントを認可する構造的なギャップを示しており、仮説上の将来リスクではありません。エージェント型AIの導入が加速している今こそ、監査証跡が「存在しなかった」ことが判明してから復元作業に追われるより、遥かに低コストで対策できます。

AIエージェントに借用した人間の認証情報ではなく、統治された独自アイデンティティを付与する方法について詳しく知りたい方は、カスタムデモを今すぐご予約ください。

追加リソース

• ブログ記事
  ゼロトラストで実現する手頃なAIプライバシー保護戦略
• ブログ記事
  77%の組織がAIデータセキュリティに失敗している理由
• eBook
  AIガバナンスギャップ：2025年、91%の中小企業がデータセキュリティでロシアンルーレット状態
• ブログ記事
  あなたのデータに「–dangerously-skip-permissions」は存在しない
• ブログ記事
  規制当局は「AIポリシーがあるか」ではなく「機能している証拠」を求めている