AI Agent と ID 管理：ハイブリッド環境を想定すると浮上する６つの問題点

The 6 identity problems blocking AI agent adoption in hybrid environments

2025/06/03 strata — もはや AI エージェントは、単なる実験の期間を通過し、現代の企業の業務プロセスへと組み込まれ始めている。トランザクション処理からロジスティクスの調整にいたるまで、人やシステムに代わって、エージェントが機能するケースが増えている。しかし、ここに落とし穴がある。エージェントの ID を管理するための、インフラが追い付いていないのである。

AI エージェントは、整然かつ統一された環境で実行されるわけではない。それらが存在する場所は、パブリック・クラウド／プライベート・データセンター／分断されたネットワークや、船舶や工場のフロアなどである。しかし、AI エージェントの認証／認可／管理の方法の前提となるのは、依然としてクラウドで接続されるセンタライズされた環境となる。

そこで、ハイブリッド環境へと AI エージェントを拡張する、ユーザー企業に発生する６つの重大な問題と、既存の IAM アーキテクチャでは不十分な理由を説明していく。

Problem 1：エージェントは複数の場所に存在するが、ID システムは存在しない

したがって、AI エージェントは以下を横断して動作する：

  • Azure でホストされるチャットボット
  • オンプレミスの工場現場のスクリプト
  • CI/CD に組み込まれた LLM ベースのエージェント
  • 遠隔地のエッジにデプロイされた自律システム

しかし、大半の IAM プラットフォームは、クラウドに接続された Web ベースのアプリケーション向けに設計されている。つまり、これらのプラットフォームは、以下を前提としている：

  • 常にインターネット接続が確保されている
  • すべてのユーザーとシステムがクラウド・ホストされる IDP にアクセスできる
  • 集中管理された、ポリシー適用が常に利用可能である

AI エージェントは、これらの３つの前提に従っていない。

Problem 2：クラウドだけに対応する IAM は、エアギャップ環境や切断環境では機能しない。

数多くの規制がある環境やリモート環境では、エージェントは外部接続なしで動作する必要がある。そこでは、以下のようなケースが想定される：

  • 機密ネットワーク上における防衛ミッション
  • 厳格な SLA とレイテンシ要件が求められる銀行プラットフォーム
  • アップタイム保証が必要な製造業やエネルギーのインフラ
  • DDIL 環境で運用される沿岸警備隊の船舶

これらのケースでは、以下のような状況は発生し得る：

  • クラウド・ホストされている ID システムへのアクセスが不能
  • エージェントのプロビジョニング／認証／監査を、完全なオフラインで行う必要性
  • ポリシーに関して、外部 API に依存せず、ローカルで適用する必要性

大半の SaaS ベースの IAM プラットフォームは、このような状況をサポートできない。フォールバック機能がないため、クラウドがダウンすると、エージェントの ID スタックもダウンしてしまう。

Problem 3：ハイブリッド環境では、エージェントの動作にポリシーを適用できない

AI エージェントはデータを読み取るだけでなく、以下のようなアクションを実行する：

  • ワークフローのトリガー
  • 資金の移動
  • レコードの更新
  • 購入の開始

ハイブリッド環境における以下の状況は、エージェント全体へのアクセス制御の適用がほぼ不可能になる：

  • クラウドノードとオンプレミス・ノード間で、ポリシーをプッシュするための一貫した方法が存在しない
  • 異なるチームが ID をサイロ化し管理している
  • エージェントの動作が、同じシステムで記録または可視化されていない

その結果として、ポリシーが断片化され、意図された境界を遥かに超えてエージェントが機能していても、それを認識できないという状況が発生する。

Problem 4：エージェントID がリージョンやクラウドベンダー間で移植できない

グローバル企業などでは、以下のような環境が稼働している可能性がある：

  • Azure の ChatGPT
  • AWS の LangChain
  • オンプレミスの社内 RAG エージェント
  • CI/CD パイプラインの N8N または CrewAI エージェント

これらの環境においては、多様かつ固有の ID システムを使用している場合もあれば、まったく使用されていない場合もある。その結果として、以下のような問題が発生する：

  • 一貫性のないアイデンティティ表現
  • グローバル・ポリシーの割り当てが不可能
  • 統合監査や可観測性の欠如

企業がグローバルな連携を必要とする際に、エージェントの ID ローカル化／サイロ化してしまう。

Problem 5：導入形態を問わず、エージェントのアクティビティをユーザーまで遡って追跡できない

適切にガバナンスされたシステムであれば、常に次の点を把握できるはずである：

  • 対象となるエージェントの、What／When／Who が明確化される。

しかし、ハイブリッド環境では、このレベルの説明責任が果たせない。その理由は以下のとおりである：

  • センタライズされたレジストリにエージェントが登録されていない
  • OAuth トークンはスコープ指定されておらず、追跡も不可能
  • クラウド／オンプレミス／エッジにログが分散している

監査証跡が厳格に管理されている、規制対象分野では特に危険である。

Problem 6：エージェント向けの統合 ID オーケストレーション・レイヤーが存在しない

今日のハイブリッド企業は、アプリ／ユーザー／ワークロードのオーケストレーションの価値を、すでに理解している。

しかし、ほとんどの IAM スタックは以下を提供していない：

  • クラウドとオンプレミスで動作するランタイム・トークン発行
  • エージェント実行時に埋め込まれたポリシーの適用
  • 複数のクラウドとリージョンにまたがる ID の継続性

つまり、エージェントは、以下のいずれかに該当する：

  • サイロ内で運用されている
  • 脆弱で静的な認証情報を使用している
  • 環境ごとにカスタム・スクリプトに依存している

その結果として、ガバナンスのないエージェントの無秩序な拡散と、運用リスクの増大に陥る。

まとめ

企業内における AI エージェントの数が、人間の80倍もの数を占める未来へと、私たちは高速で移動している。しかし、今日の ID アーキテクチャは、クラウド・ネイティブのものでさえ、以下をサポートするように設計されていない。

  • エッジ／クラウド／オンプレミスをカバーする分散実行
  • ローカル ID 適用を備えたエアギャップ環境
  • エージェント間でのランタイム ID 発行とポリシー適用

ハイブリッド環境において、AI エージェントの導入が引き起こすとされる、６つの ID 管理の課題を明示し、従来の IAM アーキテクチャでは、それに対応できない理由を説明しています。これらを可能にする、新たな ID レイヤーや統合オーケストレーションの構築が、AI エージェントの真の活用には不可欠と言っていますが、それを理解するのも、なかなか大変そうですね。なんとなく、Non-Human Identities にも関連しそうに思えます。よろしければ、カテゴリ NHI を、ご参照ください。