- エージェントの定義、デプロイ、および実行を個別にカウントし、共通の名前によって異なる権限が隠れてしまうのを防ぎます。
- 宣言された構成と観測されたアクティビティを照合し、明示的な検出ギャップを記録する。
- 承認された範囲、許可された範囲、および実際に確認された範囲を比較する。正体不明のものは調査すべき所見であり、シャドウAIの存在を自動的に証明するものではない。
- 指定された範囲内で、所有権、相関関係、データの最新性、照合の未処理件数、およびテスト済みの応答を測定する。
マッキンゼーが実施した2026年のグローバルAI調査によると、年間売上高が10億ドルを超える組織の回答者の40％が、AIエージェントの導入規模を拡大していると回答しており、これは前回の調査時の27％から増加している。導入が拡大するにつれ、セキュリティチームは、どのエージェントが動作できるか、どのIDを使用しているか、そしてそのアクセス権限について誰が責任を負うかを把握する必要がある。マッキンゼーの「AIの現状」に関する調査は、こうした運用上の課題の重要性をますます高めている。
AIエージェントのインベントリとは、AIエージェントとその導入状況（目的、所有者、識別情報、ツール、データアクセス権限、承認状況、ライフサイクルなど）を記録・管理したものです。有用なインベントリとは、組織が承認した内容と、システムが許可するように設定されている内容、およびエージェントの実際の動作状況とを結びつけるものです。
この連携により、チームは所有者のいないデプロイメントを特定し、過剰なアクセス権限を確認し、予期せぬ動作を調査し、認証情報やスケジュールされたタスクを残すことなくエージェントを廃止することができます。これらは、AIのフロンティアを保護するための実用的な出発点であり、その監視体制は、エージェント、その所有者、およびエージェントが動作する際に使用するIDを特定することにかかっています。
情報源は2026年10月28日に確認済みです。本ガイドは、公開されている調査結果およびセキュリティガイダンスに基づいています。インベントリの設計、例、および実装チェックリストは、提案されたガイダンスであり、テスト済みの顧客導入事例に基づく結果ではありません。
AIエージェントのインベントリは、次のような実用的な一連の質問に答えるものです。定義された環境内にどのようなエージェントが存在するか、それらはどこで実行されているか、何にアクセスできるか、そして誰がそれらを変更または停止できるか。その範囲には、承認済みのエージェントと未解決の検出対象を含めるべきであり、それらの状態を明確に区別する必要があります。
NISTのAIリスク管理フレームワーク・プレイブック『GOVERN 1.6』では、AIシステムの棚卸しを行う仕組みや、それらの記録を維持する責任の割り当てについて推奨しています。エージェントの棚卸しとは、ツールを使用したりアクションを実行したりできるシステムに対して、このガバナンスの基盤を適用するものです。
このインベントリでは、AIエージェントを、AIモデルを用いて目標達成に向けた手順を選択または実行し、場合によってはツールを起動したり、データにアクセスしたり、作業を委任したりするソフトウェアとして扱ってください。回答案を作成するシステムと、それを送信するシステムでは運用上の影響が異なるため、自律性の程度を記録してください。
これには、カスタムアプリケーション、SaaS（Software as a Service）に組み込まれたエージェント、ツールへのアクセス権を持つローカルのコーディングアシスタント、および企業リソースとのやり取りが許可された外部運用エージェントが含まれます。これらを、エンドポイント監視エージェントや、AI を使用してアクションを決定しない従来の自動化とは区別してください。
モデルエンドポイント、ツール、またはコネクタは、関連するアセットです。これらは自動的に独立した AI エージェントになるわけではありません。エージェントがフロンティア AIモデルを使用する場合は、そのモデルへの依存関係を、デプロイメントのツール、認証情報、およびデータアクセスとは別に記録してください。モデルの機能だけでは、デプロイされたエージェントが何ができるかを説明することはできません。より広範な保護要件については、「AI エージェントのセキュリティ」を参照してください。
在庫管理には、いくつかの既存のシステムが活用できます。各システムの名称は製品によって異なるため、組織に必要な機能を明確に定義してください：
これらの機能は、1つのプラットフォームを共有することも、識別子を通じて相互に接続された状態を維持することも可能です。必要なのは、レコード間の信頼性の高い関係であり、各フィールドについて責任の所在が明確な情報源が確保されていることです。
1つのエージェント設計は、権限の異なる複数の環境で実行可能です。エージェント名を数えるだけでは、そうした違いが見えにくくなりますが、実行のたびに新しいエージェントとしてカウントすると、エージェントの総数が過大評価されてしまいます。
マッキンゼーが報告した増加傾向は、売上高基準で定義された大規模組織の回答者において、1つ以上の業務機能にわたってエージェントを拡大している状況に関するものである。この調査は2026年5月から6月にかけて、97カ国から1,719件の回答を集めた。この調査では、エージェントの数や在庫の完全性ではなく、報告された導入状況を測定している。実務上の意味としては、アクセス要件が異なる各機能にまたがってエージェントが展開されることに備える必要があるということである。
インベントリ内の3つの連結されたレベルを使用します：
たとえば、テスト環境のサポートエージェントは、合成チケットを読み取る場合があります。一方、本番環境のデプロイメントでは、顧客レコードを読み取り、ケースを更新する場合があります。エージェント名が同じであっても、その権限が同等であるとは限りません。また、デプロイメントの記録には、監視対象のアクティビティとの関連付けが必要です。
短期間の労働者やサブエージェントについては、その親となるデプロイメントおよび実行識別子を通じて記録してください。これらが独自の認証情報、所有権、または永続的なアクセス境界を取得した場合は、個別のデプロイメント記録を作成してください。これは提案されている集計規則です。異なるチーム間で比較可能な数値が報告されるよう、この規則を文書化してください。
フロンティアAI：ブレーキなしで作られた
自律型エージェントが意図された境界を越えてしまう仕組みと、セキュリティチームがエージェントを特定し、その活動を監視し、予期せぬ動作を封じ込めるために講じることができる具体的な対策についてご紹介します。
各展開記録には、エージェントを特定し、その権限を評価し、裏付けとなる証拠を見つけ、責任者を特定するのに十分な情報が含まれている必要があります。以下のテンプレートは実用的な出発点となります。ご自身の環境やリスク判断に合わせて適宜調整してください。
資格情報の参照情報、発行元、適用範囲、有効期限の詳細をインベントリに保管してください。シークレット値は、適切なシークレット管理システムに保存してください。トークンをインベントリにコピーすると、情報が漏洩するリスクのある場所がもう1つ増えてしまいます。
所有者が申告するデータと、収集者が観測したデータを区別する。ビジネス目的は通常、所有者による主張であり、クラウドロールの割り当ては構成の証拠であり、APIイベントの成功はアクティビティの証拠である。それぞれが異なる疑問に答えるものである。
また、「最後のアクティビティ」、「最後の正常な収集」、「最後のレビュー」も区別する必要があります。エージェントは、そのインベントリレコードが最新であるにもかかわらず非アクティブ状態にある場合もあれば、レコードの更新を行うコレクターが失敗しているにもかかわらずアクティブ状態にある場合もあります。
エージェントはホスト型アプリケーション、カスタムサービス、およびローカルの開発ツールに組み込まれる可能性があるため、検出には複数の情報源が必要となります。まず、宣言されたカバレッジ境界から始め、各情報源が実際に監視できる環境やデプロイメントの種類を記録してください。
承認済みのAIプラットフォーム、クラウドアカウント、SaaS管理インターフェース、アプリケーションカタログ、およびデプロイメントパイプラインから、利用可能なエージェント定義を収集します。リポジトリおよびデプロイメントマニフェストを調査し、登録済みのエージェントサービスとその依存関係を特定します。
ローカルエージェントについては、承認済みのエンドポイントソフトウェアおよび構成インベントリを使用してください。パッケージがインストールされていることは、その機能が利用可能である可能性を示唆するものではありますが、構成済みのエージェントが実行中であることや、企業ネットワークへのアクセス権限を持っていることを証明するものではありません。
テナントおよび環境の識別子を、プラットフォーム ID とともに取得します。同じ表示名が複数の場所に表示される場合があります。エクスポートが完了したとみなす前に、コレクターの権限、サポートされているオブジェクトタイプ、ページネーション、および更新間隔を確認してください。
見慣れないツールや構成については、承認された読み取り専用の手法を用いて調査してください。単にその正体を特定するためだけに、未知のエージェントを実行したり、副作用を伴うツールを起動したりしてはなりません。
エージェントをサービスアカウント、アプリケーションID、ワークロードID、および委任されたユーザーアクセスに割り当てます。アクセスを許可したユーザー、関連するリソース、および複数のエージェントが同一のプリンシパルを共有しているかどうかを確認します。
ユーザーまたはサービスから、エージェントの展開、コネクタ、および下流システムに至るまでの一連の流れを保持してください。エージェントは、1つのタスクの遂行中に複数のIDを通じて動作する場合があります。認証情報を共有すると、責任の所在が不明確になる可能性があるため、その点は記録に明記しておく必要があります。
モデルコンテキストプロトコル（MCP）は、アプリケーションとツールやリソースを接続するものです。そのセキュリティガイダンスでは、トークンのパススルーや対象者の検証不足が、信頼境界や説明責任を損なう可能性があることが説明されています。したがって、コネクタを棚卸しする際には、そのアドレスだけでなく、認証関係や下流の権限も記録する必要があります。
非人間アイデンティティのセキュリティは、関連するサービスおよびワークロードのアイデンティティを管理する上で有用な背景情報を提供します。
登録済みのデプロイメントと、利用可能なアプリケーションログ、ツール呼び出し記録、ID関連イベント、クラウド監査ログ、エンドポイントのアクティビティ、およびネットワークメタデータを照合します。責任の所在が明確なデプロイメントに紐づけられないアクティビティを調査します。
AIサービスへのトラフィックは、見込み客の発見のきっかけとして捉えるべきです。そのトラフィックは、人間、従来のアプリケーション、あるいはエージェントから発生している可能性があります。同様に、一般的なサービスアカウントによるAPI呼び出しがあったとしても、それがAIシステムによって開始されたことを証明するものではありません。
未解決の調査結果は、裏付けとなる証拠によってその正体が判明するまで、候補としてマークしておくこと。所定の承認プロセスを経ずに確認されたエージェントは、シャドウAIの一部である可能性がある。また、在庫照合が一致しないという事実だけでは、データ収集の遅れ、名称変更された展開、あるいは帰属情報の不備を反映している可能性もある。
ネットワークの観測データは、宛先や通信パターンの特定に役立つが、暗号化されたトラフィックや共有インフラの存在により、個々のエージェントの行動について明らかになる情報は限られている。
既存のサブスクリプション、マネージドサービス、および外部でホストされているワークフロー内で利用可能なエージェントの機能について、調達担当者やアプリケーションの責任者に確認してください。こうした機能は、新たなソフトウェアの購入として認識されない場合があります。
サードパーティの代理店に対しては、ユースケースに必要な運用上の事実（責任者、関連する企業リソース、権限の範囲、利用可能なログ、変更通知、および停止手続きなど）を要求してください。プロバイダーから提供できない情報は、不足事項として記録してください。
所有者の証明書は、その目的や承認の根拠を説明するのに役立ちます。特に、エージェントが影響の大きいアクションを実行できるかどうかを決定する場合には、可能な限り技術的な主張を裏付けるようにしてください。
照合を行うことで、記録の集まりを実用的な在庫情報へと変換します。承認された内容、付与されたアクセス権、および確認された活動内容を照合しつつ、各調査結果の根拠となる証拠や不確実性を保持します。
これら3つの観点は、明確に区別しておく必要があります。役割の割り当ては、承認された目的よりも広範な範囲に及ぶ場合があります。未使用の権限であっても、依然として権限が付与されている状態です。API呼び出しの試行が失敗した場合は、完了したアクションとして記録すべきではありません。
実用的な照合プロセスとしては、識別子を正規化し、証拠をデプロイメントに関連付け、3つのビューを比較し、不一致を責任者へエスカレーションすることが挙げられます。利用可能な場合は、プラットフォームIDや検証済みのIDマッピングを使用してください。表示名だけでは、照合キーとして信頼性が低くなります。
矛盾する証拠を、単に「最後に到着した情報源」で黙って上書きしてはならない。フィールドレベルの権威を定義し、関連する履歴を保持し、未解決の矛盾を検索可能にすること。
証拠の質も重要です。OWASPのサードパーティによる実行証拠に関するガイダンスでは、サプライヤーの主張と、独立して検証可能な観察結果を区別しています。署名付き記録は、誰が主張を行ったかを特定することはできますが、報告されたすべてのアクションが発生したこと、あるいはイベントが省略されていないことを証明するものではありません。
記録管理の目的上、各観察結果から何が判明し、何が判明しないかを記録してください。データが得られなかった観察者による観察結果の欠落は、証拠の欠如であり、安全な行動の証拠ではありません。
レビューの優先順位は、エージェントが実行可能なアクションがもたらす影響と、その制御の質を反映すべきである。馴染みのあるモデルや承認済みのプラットフォームであっても、それに基づいて構築されたすべての導入におけるリスクを決定づけるものではない。
以下の質問を参考にして、合理的な優先順位を決定してください：
OWASPの「AIエージェントセキュリティ・チートシート」では、最小権限の原則、影響の大きいアクションに対する監督、およびセキュリティ監視が推奨されています。これらの原則を、確認やテストが可能なインベントリ項目に落とし込んでください。
所有者のいないエージェントで、生産環境への書き込みアクセス権限を持つものは、早急な審査が必要です。公開情報を使用する、文書化済みの読み取り専用エージェントについては、審査の優先度を低く設定してもよい場合があります。これらは優先順位付けの例であり、普遍的なリスク分類ではありません。
プラットフォームが対応している場合は、実効権限を評価してください。割り当てられたロール、リソースポリシー、条件付き制限、および下流コネクタの権限は相互に影響し合う可能性があります。その相互作用が未解決の場合は、ロール名を「実証済みの機能」とみなすのではなく、実効アクセス権を「未確認」として扱ってください。
更新がデプロイやアクセス管理のワークフローの一部となっている場合でも、インベントリは有用です。イベント駆動型の更新と、スケジュールに基づいた照合および担当者の確認を組み合わせ、環境の変化の速度やリスクに応じた適切な頻度で実施してください。
各導入プロジェクトには、担当のビジネススポンサーと技術責任者を割り当てます。スポンサーは目的と許容される利用範囲を確認し、技術責任者は導入に関する事実関係や連携状況を管理します。IDおよびアクセス管理（IAM）チームがアクセス権限を検証し、セキュリティ運用チームが不審な活動を調査し、ガバナンスチームが承認や例外処理を調整します。
インベントリ・サービス自体には、別の責任者を割り当ててください。その担当者またはチームは、レコードスキーマ、コレクターの稼働状況、照合ルール、アクセス制御、およびエスカレーションプロセスの管理を担当します。
エージェントが新しいツール、ID、権限、データソース、外部宛先、自律設定、または重要な設定変更を受け取った際に、レビューをトリガーします。所有権の移管や有効期限切れの例外についても、対応が必要です。
変更された設定とその有効開始時刻を追跡してください。そうしないと、調査担当者が昨日の操作内容と今日の権限設定を比較し、誤った結論に達してしまう可能性があります。
無効化処理を行う際は、必要な証拠を保持したまま、その機能の動作を停止させる必要があります。関連するトリガーやスケジュールを無効化し、エージェント固有のアクセス権を取り消し、不要になった連携機能を削除し、その結果を確認してください。他のワークロードで使用されている認証情報を変更する前に、共有されている依存関係を確認してください。
決定内容、日時、責任者、および検証証拠を記載した記録を保管しておく。ログ、メモリストア、構成情報、および関連する業務記録については、組織の保存要件を適用する。NISTのGOVERN 1.7ガイダンスでは、無差別な削除がリスクをもたらす可能性があるため、廃止処理を管理されたプロセスとして扱っている。
インベントリ自体から、特権IDやアクセス可能なシステムに関する機密情報が漏洩する可能性があります。役割ごとにアクセスを制限し、重要な変更を記録し、エクスポートデータを保護してください。詳細な機密情報は管理されたシステムに保管し、可能な場合はインベントリから参照するようにしてください。
チケットの要約や返信文の草案作成が許可された、架空のカスタマーサポート担当者を想定してみましょう。その目的は限定的ですが、実際のアクセス権限は、導入環境やそれに接続されているコネクタによって異なります。
初期のインベントリレコードには、サポートアプリケーションの所有者、本番テナント、エージェントのバージョン、およびコネクタの識別子が記載されています。承認されたアクションセットには、割り当てられたチケットの閲覧と返信下書きの保存が含まれます。メッセージの送信には、人間の判断が必要です。
照合の結果、このコネクタには、対象のキュー以外へのメッセージ送信やチケットの読み取り権限も付与されていることが判明しました。不正な送信は確認されていません。しかし、この事実は依然として重要です。利用可能なアクティビティ記録には不正使用の痕跡は見られないものの、付与された権限の範囲は承認された範囲を超えているからです。
技術責任者は、他のワークロードが当該コネクタを共有していないかを確認し、可能な場合はエージェントのアクセス権を分離し、不要な権限を削除します。レビュー担当者は変更内容を記録し、承認済みのテストケースを用いて期待される動作を検証します。
その後、アクティビティ記録によると、同じIDが新たな外部宛先に書き込みを行っていることが確認された。このコネクタは以前、複数のワークロードを処理していたため、調査担当者は、そのアクションをサポート担当者に帰属させる前に、デプロイメント識別子と実行識別子を確認した。
この例からは、2つの異なる利点が示されています。すなわち、このインベントリは、不正使用が確認される前に権限の修正を可能にするほか、インシデントの誤った帰属を防ぐために必要な文脈を保持しているという点です。なお、これは実際の顧客や製品テストに関する主張ではありません。
このチェックリストを使用して、定義された環境内で実用的なインベントリを構築してください。担当者が、その項目を裏付ける記録、審査結果、またはテスト結果を提示できるようになった時点で、その項目を「完了」としてマークしてください。未解決の項目については、担当者名と審査日を明記して追跡してください。
☐ 対象範囲に含まれるプラットフォーム、アカウント、テナント、デバイス、および外部サービスについて、既知の除外項目を含めて記録する。
☐ エージェントの定義、デプロイ、実行の各要素について合意し、安定した識別子を割り当てる。
☐ 既知の各導入案件について、インベントリプロセスの責任者、ビジネススポンサー、および技術責任者を割り当てる。責任者が未定のレコードについては、解決に向けて適切な担当者に回す。
☐ 必須項目、承認ステータス、証拠資料、および審査期限を定める。
☐ インベントリへのアクセスとエクスポートを制限し、シークレット値をコピーせずに認証情報の参照情報を保存する。
☐ 利用可能な展開記録を収集し、サポート対象外の環境、収集に失敗したケース、および各ソースの最後の正常な更新日時を記録する。
☐ 展開状況をID、委任アクセス、ツール、および下流のリソースにマッピングし、共有された認証情報や帰属が不明確なものをフラグ付けする。
☐ 承認された措置、付与された権限、および確認された活動について、裏付けとなる証拠とタイムスタンプを添えて、それぞれ個別に記録する。
☐ 機密データや重要な書き込みアクセスに関わる不一致を精査し、各指摘事項について責任者と、解決策または例外措置の決定を割り当てる。
☐ 承認済みのテストリソースを使用して、名前が変更されたエージェント、重複レコード、権限の変更、および収集の失敗をテストし、ギャップが引き続き確認できることを確認する。
☐ 変更に伴う更新や定期的なレビューを設定し、期限切れのレビューや担当者が未定の場合のエスカレーション手順を確認する。
☐ アナリストが、デプロイメントを特定し、そのアクセス状況を説明し、所有者を特定し、関連するアクティビティの証拠を取得できることを確認する。
☐ 承認済みのテストリソースを用いて、スケジュールされたタスク、下流へのアクセス、および共有依存関係を確認しながら、一時停止および終了を実行する。
☐ アクセス権の変更および廃止に関する決定内容、責任者、タイムスタンプ、および検証証拠を保持する。
☐ 所有権の網羅率、データの最新性、未解決の不一致、および回答テストの結果について、明確な分母と網羅率のギャップを明記して報告する。
実際に必要とする導入形態や証拠情報源に基づいて、ツールを評価してください。記録の数が多くても、そのインベントリが正確であり、最新であり、調査の際に有用であることを示すには不十分です。
プロバイダーに対し、関連するホスト型、ローカル、カスタム、およびサードパーティ製のエージェント全体にわたる検出機能の実演を依頼してください。前提条件、データ収集の権限、遅延、サポート対象外の環境、およびコネクタが失敗した際の動作を確認してください。
次に、そのツールが安定した識別子を保持しているか、共有および委任されたIDをサポートしているか、設定履歴を記録しているか、証拠の出所情報を公開しているか、そして文書化されたインターフェースを通じて利用可能なレコードをエクスポートできるかを検証します。また、どのワークフローアクションに統合が必要か、および個別の権限設定が必要かを確認します。
分母が明示されている少数の小節を使用してください：
分母を明確に特定できない限り、「すべてのエンタープライズエージェント」の割合を主張することは避けるべきです。通常、妥当な主張としては、申告されたアカウント、プラットフォーム、デバイス、または既知の導入事例をカバー範囲として挙げ、その上で明確な適用除外事項を併記することが挙げられます。
インベントリ記録は、セキュリティ上の意思決定を行う際の背景情報を提供します。具体的には、どのエージェントが関与しているか、どのIDを使用しているか、どのようなアクションが予想されるか、そしてアクセス権限をどのように変更できるかといった情報です。検知および対応のワークフローには、こうした背景情報に加え、テレメトリと強制措置の仕組みも必要です。
セキュリティ調査に関連するインベントリ識別子を紐付けることで、アナリストがIDやワークロードのイベントから、そのデプロイメントの所有者や承認された範囲へと追跡できるようにします。異常の疑い、調査済みのインシデント、推奨される対応、および封じ込めが確認された状態の区別を明確に維持します。
Vectra AIのAIネイティブなセキュリティおよび可観測性アプローチは、エージェントが接続された環境全体にわたるアイデンティティやインフラストラクチャを通じて動作する場面で有効です。同社の資産およびアイデンティティの可視化に関するユースケースでは、ネットワーク、アイデンティティ、クラウド、SaaS環境にわたる可視化が説明されています。これは、インベントリプログラムを評価する際の参考となるコンテキストを提供しますが、具体的なエージェントのマッピング、テレメトリ、および統合については、導入に際して依然として検証が必要です。
その運用上の連携状況を評価する場合は、担当者が使用するID、環境、および調査ワークフローに焦点を当てたVectra AIのデモをご依頼ください。
はい。範囲が管理可能な範囲に収まり、所有者が記録を適切に管理している場合は、スプレッドシートを用いて初期のインベントリを作成することができます。その際は、一意の識別子、確認日、参照元、変更履歴を明記してください。手動による照合では、導入状況や権限の変更に追いつけなくなった段階で、統合システムへの移行を検討してください。
いいえ。MCPサーバーは通常、それを使用するエージェントにリンクされたツールまたはリソース依存関係として、インベントリに登録されます。組織の集計規則に基づき、MCPサーバーが独立してエージェントの機能も実行する場合は、MCPサーバー用に個別のエージェントレコードを作成してください。いずれの場合も、そのIDおよびアクセス関係は維持してください。
導入、所有権、権限、ツール、またはその他の重要な構成変更が発生した際は、記録を更新してください。これらの更新に加え、定期的な照合やリスクベースの責任者によるレビューを実施してください。運用上のニーズに基づいて更新間隔を決定し、データ収集の失敗を監視することで、更新の漏れが「静穏な環境」と誤認されるのを防いでください。
いいえ。ネットワーク監視では、接続状況やアクティビティのパターンを把握することはできますが、ローカル、組み込み、または外部でホストされているすべてのエージェントを確実に特定したり、暗号化されたトラフィックからすべてのアクションを特定したりすることはできません。プラットフォームの記録、ID情報、エンドポイントの証拠、アプリケーションログと組み合わせて分析し、残っている情報不足を文書化してください。
インベントリは、システム、所有権、アクセス権、およびレビューの証拠を文書化することで、ガバナンスを支援します。ただし、それ自体ではコンプライアンスが確立されるわけではありません。適用される義務はユースケースや管轄区域によって異なり、より広範な要件としては、テスト、監督、データ保護、インシデント対応、および文書化されたリスク判断などが挙げられます。