AIエージェントとID管理：人を前提とした統制モデルの限界と再設計の方向性

なぜ今、非人間アイデンティティが問題になるのか

企業のセキュリティおよびガバナンスにおいて、「非人間アイデンティティ（Non-Human Identity：NHI）」の管理が最重要論点の一つとなっています。従来のID管理は人を前提に設計されてきましたが、AIエージェントは自律的に行動し、外部システムと連携する主体であるため、その設計思想の根本的な見直しが迫られています。

現時点で顕在化している課題は、以下の3点に集約されます（図表1）。

• 過剰な権限の付与・・・AIエージェントは複数のシステムやツールを横断的に利用するため権限が肥大化しやすく、最小権限の原則が維持されにくい。
• 明確な所有権・責任主体の欠如・・・「誰の代理として行動しているのか」「最終的な責任は誰が負うのか」が不明確になりやすく、説明責任の所在が曖昧化。
• 可視性の欠如・・・エージェントの生成・利用・権限付与の実態が把握されていないケースが多く、管理されないIDの増殖や追跡不能な挙動が発生。

図表1：非人間アイデンティティ管理における課題

注目すべきは、これら3つの課題が独立して存在するのではなく、相互に影響しながらリスクを増幅させる構造にあることです。例えば、可視性が低ければ過剰な権限付与に気づけず、所有権が曖昧であれば問題が発生しても責任の所在が定まりません。実際、非人間アイデンティティのライフサイクル（作成・変更・削除）に関する明確なポリシーを整備している企業は約2割にとどまっており、多くの企業がこうした連鎖リスクを抱えたまま導入を進めています（図表2）。

図表2：NHI管理の実態

AIエージェントの導入にあたっては、個別対策にとどまらず、非人間アイデンティティを統合的に管理する枠組みの構築が不可欠です。

AIエージェントがもたらす統制モデルの崩壊

ここまで整理してきたAPL層・基盤層の二層構造は、AIエージェントの登場により両層で同時に揺らぎます。以下では、その具体的なメカニズムを各層ごとに整理します。

APL層：4つのスタックすべてに機能不全のリスク

AIエージェントには、従来の人による操作と根本的に異なる3つの特性があります。

1. 主体の増幅・・・複数のエージェントが相互に連携しながら並列に動作する。
2. 非対話的な実行・・・人の介在なしにバックグラウンドで処理が進む。
3. 委任の連鎖・・・権限や指示が複数のエージェントをまたいで多段階に委譲される。

これらの特性は、APL層の4つのスタックすべてに深刻な影響を与えます（図表4）。

1. 身元確認・・・並列稼働する多数のエージェントがそれぞれ正当な主体であるかの確認が困難。エージェントの増加に伴い、なりすましや不正なエージェントの混入リスクも高まる。
2. 認証・・・UIを持たずバックグラウンドで動作するエージェントには、従来のログイン型認証をそのまま適用できない。
3. 認可・・・委任が多段階に連鎖する中、「誰がその権限を与えたのか」を出自までさかのぼれる設計が不可欠。実行された処理が本来の同意範囲内に収まっているかの検証も、従来以上に困難。
4. ガバナンス・・・高速・並列で処理が進む環境では、人の目による監視や検知は現実的ではない。関与する主体が増えるほど、監査証跡の分散と責任の曖昧化が進む。

図表4：APL層：ヒトによる統制がAIエージェントで崩れるポイント

基盤層：「止める構造」の形骸化

基盤層においても同様の問題が生じています。従来は、ハードウェア・OS・ブラウザといった基盤側に安全機能が組み込まれていたため、APL層の利用者や開発者が強く意識しなくても、危険な操作を一定程度抑止することができました。しかしAIエージェントでは、そうした基盤側の保護をそのまま前提にできない場合があります。その結果、基盤層がこれまで担ってきた「危険な操作を未然に防ぐ構造」が、そもそも適用されない環境で動くことがあるのです。

例えば、OSが担ってきた利用者・プロセス単位の権限分離はAIエージェント起動時に利用者と紐づいていない場合、機能しません。

さらに、ブラウザが異なるウェブサイト間のデータ共有を遮断する仕組みの「同一オリジンポリシー」など、複数のエージェントが並列かつ横断的に動作する環境では、並列性の高まりにより境界が機能しなくなり、これまでセキュリティ上の「当然の前提」とされてきた保護が、気づかないうちに崩れていく可能性があります（図表5）。

図表5：基盤層：“止める構造”がAIエージェントで崩れるポイント

つまり、「APL層と基盤層の双方で、人を前提とした統制構造が同時に揺らぐ」ことが、AIエージェント導入においてセキュリティ担当者が直面する最も根本的な課題です。

AIエージェントIAMの再設計：「目的」と「特性」の二軸で考える

では、APL層・基盤層の統制崩壊を踏まえ、AIエージェントのIdentity and Access Management（IAM）をどう設計すべきでしょうか。ここでは人向けIAMの設計思想と、AIエージェントが既存カテゴリに収まらない理由を整理し、設計の方向性を示します。

人向けIAMはすでに「目的別」に設計されている

人向けのIAMはCIAM（Consumer Identity and Access Management：コンシューマー向け）とEIAM（Enterprise Identity and Access Management：従業員向け）に大別され、それぞれ求められる機能要件が異なります。身元確認の厳格さ、認証強度、同意管理の粒度、UI/UXの優先度など、対象ユーザーの性質に応じて設計思想が根本的に異なるのです。

さらに、身元確認・認証・認可・同意管理・外部ID連携といった各スタックに加え、パーソナルデータの利活用やプライバシー保護も不可欠な構成要素として組み込まれてきました。この「目的別の最適化」という考え方は、AIエージェントのIAM設計でも重要な原則となります。

AIエージェントは「人」でも「マシン」でもない

従来、非人間アイデンティティのアクセスコントロールは、IoT機器やシステム間連携といったマシンワークロードを主な対象として整理されてきました。しかしAIエージェントは、既存のどちらのカテゴリにも完全には当てはまりません。

人の特性が「自律性・動的」であるのに対し、マシンワークロードの特性は「代理性・静的」と整理できます。AIエージェントはこの両方を併せ持ちます（図表6）。人やシステムの代理として行動しながら（代理性）、状況に応じて自律的かつ動的に判断・行動する（自律性・動的）という、これまでにない主体です。この「代理性×動的」という複合的な特性が、既存の枠組みをそのまま適用できない根本的な理由です。

図表6：人・AIエージェント・マシンワークロードにおけるアイデンティティ管理の違いと設計要件

これらの点を踏まえると、企業がAIエージェントのアクセスコントロールを実装する際には、以下の二軸を明確にすることが出発点となります。

1. 目的の軸・・・顧客向けサービスのために動くエージェントか（AI CIAM）、社内業務の効率化のために動くエージェントか（AI EIAM）
2. 特性の軸・・・人的な自律性とマシン的な代理性をどのように組み合わせて統制するか

この二軸を前提に、身元確認・認証・認可・同意管理・外部連携・ガバナンスという6つのスタックをエージェント前提で再定義する必要があります。

例えば本人確認の論点であれば、従来はCIAMではユーザーによるセルフレジストレーション時の確認、EIAMでは人事部門による入社・異動・退職に応じた登録・変更・削除が中心でした。AIエージェントについては、こうした人を前提とした確認やライフサイクル管理をそのまま適用するのではなく、「どの主体のために作成されたエージェントなのか」「誰が登録・承認し、変更・停止させるのか」を改めて設計する必要があります。

また認可の論点であれば、従来はCIAMではプライバシーデータの取り扱いに関する同意や利用範囲の管理、EIAMでは業務アプリケーションや社内資産へのアクセス権管理が中心でした。AIエージェントについては、これらを人ではなくエージェントに置き換えた上で、どのデータに、どの業務目的で、どこまでアクセス・処理・連携を許すのかを、委任の範囲も含めて設計し直す必要があります。

この二軸の整理なしに導入を進めると、統制設計が後手に回るリスクが高まります。導入目的と対象特性を先に明確にしておくことが、AIエージェント時代のセキュリティ設計を実効性あるものにする条件です。

リスクを見極め、小さく始めて統制を積み上げる

ここまでは人向けでは一定の整備が進んでいる領域をAIエージェントに置き換えて設計する必要性を述べてきました。ただし、AIエージェントによる対応方法については、十分に成熟していない部分があります。IETF（Internet Engineering Task Force：インターネット技術タスクフォース）では2026年3月に認証・認可に関する論点ドラフトが公開されていますが、標準化には至っていません。標準の成熟を待つのではなく、論点を手がかりに課題を把握し、自社環境に即した実装を先行させることが現実的です。

さらに重要な前提は、人向けのID管理自体もいまだ発展途上であるという点です。本人確認の精度、IDライフサイクル管理の実効性、同意取得と最小開示の両立、年齢確認や保護属性の扱いなど、人を対象とした領域でさえ技術的・制度的課題は残されています。

人向けの枠組みはAIエージェントにも有益な参照点となりますが、それ自体が完成されたものではありません。そのため、まずは人向けの枠組みの未完成となっている部分を認識しておく必要があります。その上で、AIエージェントについては、それらの課題をどう引き継ぎ、どこを新たに設計し直すべきかを検討することが求められます。

一方で、こうした課題を理由に導入を手控えることは、ビジネス機会の損失につながりかねません。重要なのはリスクを回避することではなく、見極めながら活用を進める姿勢です。そのための実践的なアプローチとして、以下の4点が挙げられます（図表7）。

1. 業務・サービスの棚卸しとリスク評価・・・適用対象の整理、リスクと許容範囲の明確化
2. 統制の先行整備・・・セグメンテーションや実行前統制、停止機構の事前整備
3. 観測性と是正サイクルの確立・・・監査ログと継続的な検証・是正プロセスの組み込み
4. 小さく始め段階的に拡張・・・限定領域から着手し、統制を確認しながら適用範囲を拡大

図表7：既存課題とAIエージェント特有の課題を前提とした実践的なセキュリティ対応方針

AIエージェントのID管理は、技術・制度・ガバナンスが交差する複合領域です。完全な解を待つのではなく、把握可能なリスクに対して統制を積み上げながら活用を広げること。これが企業に求められる現実的な判断です。