An AIインベントリ 組織全体で稼働しているすべてのAI資産を網羅した、継続的に更新されるカタログです。 モデル、AI搭載エンドポイント、データセット、AIコーディングアシスタント、MCPサーバー、およびAI依存関係 — それらをつなぐ関係、リスク、所有者とともに。セキュリティの文脈では、これは倉庫や在庫管理とは何の関係もありません。ここでは、 「AIインベントリ」 つまり、自分がどのようなAIを実行しているのか、それがどこに存在し、何ができるのかを正確に把握するということです。
AIはIDEでのコード生成から内部で動作する自律エージェントまで、ソフトウェア開発のあらゆる段階に広がっている。 CI/CD pipelineつまり、問題はもはやあなたの環境にAIが存在するかどうかではない。 問題は、あなたがそれを見ることができるかどうかです。 このガイドでは、AI インベントリとは何か、それがどのように関連しているかを説明します。 AI-BOM と SBOM、 なぜ シャドウAI セキュリティ上の問題となっており、その慣行がどのように EUAI法, NIST AI RMF (NAIST) と ISO / IEC 42001.
主要な取り組み
- AIインベントリは、IT部門が承認したものだけでなく、ソフトウェアライフサイクル全体にわたるすべてのモデル、データセット、エージェント、MCPサーバー、およびAIコーディングツールをカタログ化します。
- シャドウAIガバナンスなしで採用されたAIは、今や例外ではなく標準となっている。2026年のセキュリティリーダーへの調査では、 組織の19％が、AIがどこでどのように使用されているかを完全に把握していると回答した。.
- An AI-BOM（AI部品表） AIインベントリの監査対応出力です。AI時代の後継者です。 SBOM.
- 規制が到来しつつあります。EU AI法、NIST AI RMF、ISO/IEC 42001はすべて、運用するAIの種類を把握することを事実上義務付けています。
- 在庫管理はあくまで出発点に過ぎません。真の価値は、リスクを評価し、本当に重要な少数の資産に対して行動を起こすことから生まれます。
AIインベントリとは何ですか？
AIインベントリとは、ソフトウェア開発ライフサイクル全体で稼働するすべてのAI資産と、それぞれの資産に付随するリスクを発見、カタログ化し、継続的に監視する取り組みです。完全なインベントリは、すべての資産について「それは何か」「どこで実行されるのか」「何にアクセスできるのか」という3つの質問に答えるものです。
その範囲は、ほとんどのチームが想定しているよりも広い。有意義なAIインベントリには、以下の項目が含まれるべきである。
- Models開発および本番環境で使用されているすべての大規模言語モデルと基盤モデルについて、バージョン、場所、検出の信頼性を含めて提供します。
- データセット: トレーニングデータ、検索データセット、およびベクターストア。これには、汚染されたコンテキストへの曝露やデータ漏洩が含まれます。
- 仲介業者: 環境内でアクションを実行する自律システム。 pull requests依存関係のインストール、またはインフラストラクチャの変更。
- MCP サーバー: モデルコンテキストプロトコル AIアシスタントを外部ツール、API、データソースに接続するサーバー。
- AIコーディングツールとアシスタント: コードを生成するコパイロットとIDE統合依存関係を提案し、リポジトリと連携します。
- AIフレームワークLangChain、LangGraph、エージェントサーバー、およびモデルをツールやデータに接続するその他のオーケストレーションレイヤー。
- 資産間の関係モデル、エージェント、サーバー、データセット、およびそれらに関連付けられた秘密情報間のつながりを示します。関係グラフは、リスクを単なるリストとしてではなく、文脈の中で可視化します。
AIインベントリとAIアセットインベントリとAI-BOMの違い、そしてそれらがどのように異なるか SBOM
これらの用語は曖昧に使われるので、事前に知っておくと良いでしょう。cise. 「AIインベントリ」と「AIアセットインベントリ」は同じものを指します。: AI資産とそのリスクに関する生きたカタログ。 AI-BOMは、在庫管理によって生成されるエクスポート可能な成果物です。: 監査人や enterprise 買い手。
AI-BOMを理解する最も分かりやすい方法は、 SBOM:
AIが普及するにつれて SDLCAI-BOMは、 SBOMセキュリティリーダーは監査人からますます多くの要求を受けており、 enterprise まさにこの製品のための調達チーム。
AIインベントリが今重要な理由
3つの要因によって、AIインベントリは「あれば良いもの」から「優先事項」へと変化した。
- まず、AIは大規模に安全性の低いコードを生成している。 独立した調査では、AIが生成したコードの大部分に脆弱性が含まれていることが一貫して判明している。PearceらによるNYU/Copilotの最初の研究では、およそ 生成されたプログラムの40%にセキュリティ上の脆弱性が含まれていた。さらに最近の大規模なテストでも同じことが示されています。Veracodeの100以上のモデルを対象とした2025年の分析では、 AIが生成したコードの55%は安全だった。どのアシスタントがコードを生成しているか分からない場合は、 pipelineつまり、そのリスクを制御することはできません。
- 第二に、ソフトウェアサプライチェーンはAIの攻撃対象領域となっている。 9月2025で、 シャイ・ハルード最初の自己増殖型npmワームであるは、開発者のマシンを配布メカニズムに変え、数百のパッケージに拡散した。2026年3月、攻撃者は アクシオス約 週間のダウンロード数が100億回リモートアクセス型トロイの木馬を仕込んだ悪意のあるバージョンを公開するなど、こうした攻撃は、従来のアプリケーションセキュリティツールとエンドポイントツールの間の層、つまりAIインベントリが明らかにするために構築された層にまさに仕掛けられています。
- 第三に、AIを通じて機密情報や認証情報が漏洩している。 GitGuardianのState of Secrets Sprawl 2026では、 AIサービスの機密情報の漏洩は前年比81％増加した。、そしてAI支援 commits leak secretベースラインの約2倍の速度で増加しています。文書化されていないモデル、エージェント、またはMCPサーバーはすべて、認証情報への潜在的な経路となります。
従来のアプリケーションセキュリティはリポジトリで止まり、モデルとは何かを理解していません。エンドポイントツールはオペレーティングシステムを監視しますが、パッケージ、MCPサーバー、AIアシスタントについては理解していません。これらの間のギャップにAIリスクが蓄積され、インベントリを作成することがそのギャップを埋めるための第一歩となります。
AIが隠れる場所：シャドウAI SDLC
シャドウAI 正式な承認やガバナンスなしに採用されたAIシステムはすべて例外です。開発者が先週有効化したコパイロット、ラップトップで実行されているMCPサーバー、パブリックハブから直接サイドプロジェクトに取り込まれたモデルなどです。これは例外的なケースではありません。2026年に400人以上のセキュリティリーダーを対象に行われた調査では、 19%が、AIがどこでどのように使用されているかを完全に把握していると回答した。 組織全体で見ると、圧倒的多数の従業員は既にAIコーディングアシスタントを使用しているか、試験運用を行っていた。
最も見つけにくいシャドウAIは、ソフトウェアライフサイクル内部に存在するAIです。なぜなら、クラウドコンソールにはほとんど表示されないからです。
- モデルとAIライブラリは、依存関係としてリポジトリに取り込まれます。
- 開発者ごと、IDEごとに設定可能なAIコーディングアシスタント。
- MCPサーバーとルールファイルは、開発者のエンドポイント上でローカルに実行されます。
- エージェントワークフローが静かに開始 pull requests またはパッケージのインストール。
そのため、クラウドのみの検出では不十分です。真に完全なAIインベントリは、コードとビルド環境（開発者のラップトップ、リポジトリ、 pipeline)、本番環境のクラウドだけではありません。
AI-BOMに含めるべきもの
監査対応のAI-BOMは、在庫を証明可能なものに変えます。最低限、以下の項目を含める必要があります。
- すべてのAI資産：モデル、データセット、エージェント、MCPサーバー、AIコーディングツール。
- 各資産の種類、場所、および検出の確信度。
- 由来と依存関係（モデルまたはコンポーネントがどこから来たのか）。
- AI特有の攻撃ベクトルに基づいた、資産ごとのリスクレベル。
- EU AI法、NIST AI RMF、およびISO/IEC 42001への規制マッピング。
- 監査担当者や顧客が利用できる、エクスポート可能で機械可読なフォーマット。
AI監査義務が成熟するにつれて、オンデマンドでAI-BOMを生成できる組織は、コンプライアンスと信頼性の面で真の優位性を得ることになるだろう。
AIインベントリとコンプライアンス：EU AI法、NIST AI RMF、ISO/IEC 42001
主要なフレームワークのいずれも「AIインベントリ」を項目として明記していませんが、実際にはAIインベントリなしではどのフレームワークも満たすことができません。目に見えないAIシステムは、文書化、分類、管理することができないからです。
時期に関する注記：EU AI法の施行は、2026年5月の「デジタル・オムニバス」協定によって修正され、リスクの高い義務のほとんどが2027年12月に延期されましたが、2026年8月2日時点のいくつかのマイルストーン（透明性義務、GPAI罰則権限など）は維持されました。正確な日付は変動する可能性があるため、EUの一次情報源で確認してください。しかし、方向性は明確であり、インベントリはそのすべてにおいて前提条件となります。
AIインベントリの構築と維持方法
インベントリの構築は、一度限りの監査というよりも、継続的なプロセスを確立することに重点が置かれています。なぜなら、AI資産は常に変化しており、新しいモデルが採用されたり、新しいエージェントが展開されたり、新しいMCPサーバーが構成されたりしますが、多くの場合、承認なしに変化しているからです。
実践的なアプローチ:
- コード、ビルド、クラウド全体にわたって自動的に検出します。 手作業の表計算ソフトは数日で古くなってしまう。発見は継続的に実行され、 SDLC実行時だけでなく、
- 関係性を分類し、マッピングする。 記録の種類、場所、出所、そして最も重要な点として、各資産が他の資産や秘密情報とどのように関連しているか。
- リスクを文脈の中で評価する。 何百もの発見事項を羅列しただけのリストは誰の役にも立たない。実際に実現可能で、活用可能で、ビジネスにとって重要なものを優先すべきだ。
- 所有権を割り当てます。 すべての資産には、責任を負うべき所有者が必要です。
- 常に最新の状態に保ち、エクスポートできるようにしておく。 必要に応じてAI-BOMを生成できる、継続的な在庫として維持する。
AI在庫管理ソフトウェアを選ぶ際に注目すべき点
ツールを評価する際、真のAI在庫管理ソフトウェアと静的なリストを区別する機能は以下のとおりです。
- AI固有の資産タイプを理解している パッケージやライブラリだけでなく、（モデル、エージェント、MCPサーバー、データセットなど）も含まれます。
- 手を伸ばして SDLCクラウドだけでなく、コード内や開発者のエンドポイント上でAIを発見する。
- マップの関係性個々の資産だけでなく、全体的なリスクも考慮に入れることで、リスクが文脈の中で可視化される。
- AI特有の攻撃ベクトルに対するリスクを評価する （迅速な注射、不安定なMCP、過剰な行為）だけでなく、CVEの重症度も影響します。
- 継続的に実行新たなAIが登場するたびに、それを捉える。
- 監査対応可能なAI-BOMを生成します 監査人と enterprise 調達。
- 在庫と執行を連携させるそうすれば、発見したことに基づいて行動できます。
在庫から行動へ：発見したものを確実に確保する
発見は第一歩であり、第二歩は、実際にリスクを伴う資産を理解することです。なぜなら、ほとんどの資産はリスクを伴わないからです。目標は、何千もの生データの中から、実際にシステム、データ、または運用を危険にさらす可能性のあるごく少数の資産に絞り込むことです。つまり、現在も稼働中で、信頼できない入力を受け入れ、現実的に悪用される可能性があり、機密性の高いアクセス権を持ち、生産資産や規制対象資産に影響を与える資産です。
ここでAIセキュリティ態勢管理（AI-SPMAI は、インベントリの取得、AI 攻撃経路に沿ったリスクの評価、規制へのマッピング、および AI-BOM の作成といった処理を行います。また、インベントリと執行が交わる場所でもあり、悪意のある依存関係がインストールされる前にブロックしたり、承認されていない MCP サーバーやモデルを拒否したり、インシデントが拡大する前に侵害されたエンドポイントを封じ込めたりします。
At ザイゲニ、これが私たちが目指すモデルです: AI SPM による継続的な AI インベントリと AI-BOM、シグネチャが存在する前に悪意のあるパッケージを検出するマルウェア検出 (MEW（マルウェア早期警戒システム））、そしてXygeni Shieldによる開発者エンドポイントでのポリシー適用。検出は、OWASP Top 10 for LLM Applications、OWASP Top 10 for Agentic Apps、OWASP MCP Top 10に準拠しています。しかし、どの方法を選択するにしても、原則は変わりません。 見えないものは保護できない。そして、AIによる在庫管理こそが、可視性を実現する第一歩となる。
よくあるご質問
AI-BOMとはどのように違うのですか？ SBOM?
An SBOM オープンソースおよびサードパーティ製ソフトウェアの依存関係をカタログ化し、CVE の深刻度に基づいてスコア付けします。AI-BOM は、AI 固有のリスクスコアリングと規制マッピングを使用して、AI 固有の資産 (モデル、エージェント、MCP サーバー、データセット) をカタログ化します。AI が普及するにつれて、 SDLCAI-BOMは、 SBOM.
シャドウAIとは何ですか？また、どうすれば発見できますか？
シャドウAIとは、正式な承認やガバナンスなしに採用されたAIのことです。有効化されたコパイロット、ローカルMCPサーバー、パブリックハブから取得したモデルなどがこれに該当します。コードやビルドにまで及ぶ継続的な自動インベントリによって、シャドウAIを検出できます。 pipeline開発者エンドポイントだけでなく、ほとんどのシャドウ AI が存在しない本番環境のクラウドも対象です。
EUのAI法はAIインベントリの作成を義務付けていますか？
EUのAI法では「AIインベントリ」という用語が明示的に用いられていませんが、高リスクシステムの文書化、分類、登録といった義務は、インベントリがなければ履行不可能です。NIST AI RMF（マップ機能、ガバナンス1.6）やISO/IEC 42001についても同様で、AIシステムのインベントリの維持が義務付けられています。
AI-SPMとは何ですか？
AIセキュリティ態勢管理（AI-SPM）とは、AI資産を継続的に発見し、AI攻撃経路に沿ってリスクを評価し、規制に照らし合わせて、AI BOMを作成する手法です。これは、CSPMやDSPMでおなじみの態勢管理の考え方を、AI固有の資産と攻撃ベクトルに拡張したものです。
AIインベントリはどのくらいの頻度で更新すべきですか？
継続的に。AI資産は、チームが新しいモデルを採用し、新しいエージェントを展開し、新しいMCPサーバーを構成するにつれて、通常は正式な承認なしに日々変化します。ある時点でのスキャンは数日で古くなってしまうため、効果的なAIインベントリソフトウェアは、一度限りの監査ではなく、継続的なプロセスとして実行されます。
ソースコードで使用されているAIをどのように把握すればよいですか？
コード内の AI のインベントリとは、依存関係として取り込まれた AI モデルとライブラリ、開発者ごとに構成された AI コーディング アシスタント、ローカルで実行されている MCP サーバーまたはルール ファイルを検出することを意味します。これには、内部で動作する検出が必要です。 SDLC （リポジトリ、ビルド） pipelineクラウドコンソールだけでなく、開発者エンドポイントでも利用可能。
