AIサプライチェーンリスクがSBOMモデルの限界を超えた理由

長年、ソフトウェア部品表（SBOM）は、概ね成り立つ前提に基づいて作られてきました。依存関係は静的で、リリースサイクルは予測可能でした。ビルド時にアプリケーションに含まれるものをすべてリスト化すれば、チームは後から十分な情報に基づいてリスクを判断できました。この方法が機能したのは、従来のソフトウェアが範囲の定まった予測可能な形で動作していたからです。AIは、こうした前提をすぐに覆します。

AIサプライチェーンは急速に変化します。新しいオープンソースモデルが一夜にして登場し、エージェントのフレームワークは、ほとんどのセキュリティチームが追跡できないほどの速さで公開リポジトリ上で進化します。MCPサーバー、プロンプト、データセット、オーケストレーションツールも、開発者の試行錯誤とともに絶えず変わります。単に速いだけではありません。根本的に異なるのです。

AIコンポーネントは、ただ受け身で組み込まれるものでもありません。実行中のシステムを積極的に形作ります。モデルは実行時に新しいツールを取り込むことがあり、エージェントはプロンプトを生成し、アクションを連鎖させ、元のコードでは定義されていなかったサービスを呼び出します。コンポーネントは、その場で新たな関係や実行経路を生み出します。つまり、サプライチェーンはビルド時に固定されるものではなくなっているのです。

ここでSBOMモデルの限界が見えてきます。静的なコンポーネント一覧では、稼働中に変化するシステムを捉えられません。セキュリティチームに必要なのは、コミット時点に存在していたもののスナップショットだけではありません。AIコンポーネントがどのように相互作用し、何を呼び出し、そうした関係がどのように変化するかを可視化する必要があります。

このニーズから生まれたのが、AI部品表という考え方です。ただし、この言葉は誤解を招くことがあります。AIBOMはチェックリストではありません。AIシステムが実際にどのように機能するかを示す、コンポーネント、動作、つながりの生きたマップです。ソフトウェアそのものが変化するよう設計されている今、静的な成果物だけでは不十分です。

深刻化する課題：AIサプライチェーンの半分はリポジトリの外にある

AIサプライチェーンが動的だと認識すると、別の課題が見えてきます。リポジトリにあるものは、全体像の一部にすぎません。AIサプライチェーンのうち、ソース管理に登録されないものが増えています。それらは開発者のマシン上で動作します。

開発者はAIツールをローカルにインストールして試しています。そのペースは、セキュリティチームが追跡できる速度を上回ることも少なくありません。ある大手メディア企業では、作業を速めるために各チームがローカルMCPサーバーを構築しましたが、セキュリティチームはサーバーの設置場所も、アクセス先も把握できていないことが判明しました。あるグローバル投資会社では、開発者が社内システムに広範なアクセス権を持つローカルAIエージェントや自動化ツールを、レビューなしでテストしていました。また別の企業では、ローカルMCPツールの使用が正式に禁止されていたにもかかわらず、作業が簡単になるため開発者は使い続けていました。

こうした行動に悪意があるわけではなく、実用的だからです。開発者は問題解決に役立つツールを使います。リスクが生じるのは、セキュリティチームが頼りにする管理策の範囲外で、そうしたツールが動作するときです。

ローカルAIエージェントやMCPサーバーは、パイプライン、認証情報、社内サービスに直接アクセスできることがよくあります。記録も監視もないまま、データが移動する可能性があります。これらのコンポーネントはCI/CD、SAST、SCAのワークフローを通らないため、その動作はほとんど把握されません。本番環境までノートPC一台分の距離しかないにもかかわらずです。

この変化により、シャドーITはさらに複雑なものになりました。シャドーITが、承認されていないSaaSを指していたのに対し、シャドーAIには、承認されていないモデル、ローカルツール、MCPサーバー、エージェント、実験的なフレームワークなど、開発者のエンドポイント上で動作するものが含まれます。ローカルで、変化が速く、調達部門ではなく個人によって導入されるのが特徴です。

その結果、可視性のギャップが広がっています。リポジトリをどれだけ完全に把握していても、そこに登録されないAIコンポーネントは見逃してしまいます。AI開発が加速するなか、開発者のマシンはAIサプライチェーンの中でも特に実態を把握しにくい領域になっています。

AI-BOMだけでは解決できない理由（それでも第一歩にはなる）

AI部品表は、最新のAIシステムに必要な構造をもたらします。ソースコードで参照されるモデル、リポジトリ内のエージェントフレームワーク、MCPサーバーの設定、プロンプト、データセット、宣言された依存関係を可視化します。コミットされ、レビューされ、バージョン管理されているAIコンポーネントについては、こうした情報が非常に役立ちます。

この可視性がベースラインとなります。セキュリティチームは推測から事実に基づく判断へと移行し、自信を持ってAIの利用を管理し始めることができます。ソース管理の範囲では、AI-BOMによって何が存在し、コンポーネントがどのようにつながっているかを明確に把握できます。ただし、リポジトリに登録されないものは対象外です。

AI-BOMでは、開発者のマシン上にあるローカルMCPツールチェーン、テストに使うAIエージェントのランタイム、エンドポイントにインストールされたLLMクライアント、開発者がローカルで試すCLIツールやエージェント型フレームワークを把握できません。こうしたツールの多くは、GitHubに登録されることすらありません。

これにより、死角が生まれます。リポジトリに基づく可視性が示すのは意図であり、開発中に実際に動作するすべてではありません。AIツールがCI/CDや従来のスキャン範囲を越えてノートPCにまで広がると、AIBOMでは把握できなくなります。こうしたコンポーネントが機密データや社内システムにアクセスできることが多いにもかかわらずです。

AIBOMだけでは問題を解決できません。必要不可欠な出発点ではありますが、把握できるのは全体の一部にすぎません。AIツールがリポジトリの外で動作すれば、リスクのかなりの部分もその外に存在します。

解決策：AI-BOMと開発者のデスクトップの可視性を統合する

リポジトリと開発者のマシンの間にあるギャップを埋めるために、開発の妨げを増やす必要はありません。必要なのは、異なる可視化モデルです。高負荷なエンドポイントエージェントを追加したり、新しいワークフローを強制したりするのではなく、環境を横断して既存の情報を関連付けるアプローチが広がっています。

リポジトリベースのAIBOM検出は、ソース管理内のモデル、エージェントフレームワーク、プロンプト、データセット、設定を特定するという本来の役割を引き続き果たします。開発者のマシン上で行う軽量スキャンは、ローカルMCPサーバー、エージェントのランタイム、実際に使われているAIツールを明らかにし、これを補完します。これらは従来のエンドポイント監視ではなく、目的を絞った限定的なスキャンです。両者を組み合わせることで、実態に即したAIサプライチェーンの一貫した全体像が得られます。

この統合された可視性は、お客様のニーズに応えるものです。リポジトリとローカル環境にある同じMCPフレームワークを追跡したいという声があります。組織内で使われているAIコンポーネントを一か所で把握したいという声もあります。また、多くの方が、ツールを禁止したり開発者のワークフローを妨げたりせずに、安全な利用を促すガードレールを求めています。

このアプローチの強みは、可視性そのものが管理策になる点にあります。どのコンポーネントが存在し、どのようにつながり、どこで動作しているかをチームが把握できれば、現実的なガバナンスが可能になります。開発者が回避するような制限ではなく、承認済みツール、安全な設定、バージョンの一貫性に焦点を当てたポリシーを定められます。

AI Security Posture Managementが、これらをつなぐレイヤーとなります。リポジトリの情報、依存関係、ローカルMCPやエージェントの検出、ガバナンスポリシーを一つのビューに統合します。強制によって管理を厳しくするのではなく、理解を深めることで、進化するAIを責任ある形で管理できるようになります。

統合による価値：AIサプライチェーンの全体像を把握できる唯一の方法

リポジトリと開発者のマシンの両方を可視化することで、AIサプライチェーンの全体像がようやく明らかになります。コードだけでは全体を把握できません。ローカルでの試行だけでは、システムがどのように正式化され、リリースされるかが分かりません。両方を組み合わせることで、組織全体でAIが実際にどのように構築、テスト、利用されているかを完全に把握できます。

多くのセキュリティツールは、全体像の片側しか見ていません。ソース管理に登録されたものに注目するツールもあれば、孤立したランタイムのシグナルやエンドポイントのアクティビティを見るツールもあります。AI Security Posture Managementは、こうしたビューをつなぎます。コードにあるものと開発者のデスクトップで動作するものを把握し、単一の一貫したモデルに関連付けます。この統合された視点が、断片的なシグナルを実行可能なインサイトへと変えます。

制限は有効な管理策にならないことが明らかになっているため、これは重要です。MCPサーバーを禁止しても使用は止まりません。ローカルエージェントを禁止すれば、試行錯誤がさらに見えにくくなるだけです。開発者は、作業を速めるツールを使い続けます。管理されないリスクと、統制された導入を分けるのは可視性です。どのAIコンポーネントが使われ、どこで動作し、どのように相互作用しているかを把握できれば、禁止ではなくポリシーや設定を通じて利用を適切に導けます。

変化を先取りするには、新たなトレンドを常に把握する必要があります。AIエコシステムは立ち止まりません。新しいエージェントフレームワークが次々に登場し、MCPサーバーは進化し、オープンソースモデルは変化します。オーケストレーションツール、データセットローダー、自動化ライブラリによって、攻撃対象領域は毎月拡大します。Snykはこうした変化を追跡し、お客様が対策に活用できる検出情報とコンテキストへと変換します。

さらに、リポジトリと開発エンドポイントを検出することで、何が露出しているかを把握でき、Snyk Codeでその露出がどのように生じたかを明らかにすることで、一連の対応が完結します。組織は、ランタイムや資産レベルで見つかった問題を、それを引き起こした脆弱なコードパスに結び付けるために、SASTソリューションも活用する必要があります。これにより、断片的な検出から連携した修正へと移行できます。コードを修正すれば、AI搭載システムに関連するエンドポイントやリポジトリ環境全体で、下流のリスクも自動的に軽減されます。

この調査基盤が、時間が経っても全体像を把握し続けられる理由です。AIサプライチェーンが拡大し変化するなか、新しいコンポーネントを認識し、その役割を理解することは、既存の要素を把握することと同じくらい重要になります。その結果、実際の開発の進め方に歩調を合わせて進化する、AIリスクの生きた理解が得られます。

AIBOM＋開発者のデスクトップの可視性＝新しいAIセキュリティのベースライン

リポジトリと開発者のマシンの両方を可視化することで、AIサプライチェーンをようやく理解できるようになります。コードは、チームが何をリリースしようとしているかを示します。開発環境は、AIがどのように試され、テストされ、利用されているかを明らかにします。両者を組み合わせることで、セキュリティチームは場当たり的な推測から、情報に基づくガバナンスへと移行できます。

制限を広げても対応できないため、これは重要です。MCPサーバーやローカルエージェントをブロックすると、試行錯誤が見えなくなるだけです。開発者は、作業を速めるツールを使い続けます。管理されないリスクと統制された導入を分けるのは可視性です。どのAIコンポーネントが使われ、どこで動作し、どのように相互作用しているかを把握できれば、開発を妨げることなく、ポリシーや設定を通じて利用を適切に導けます。

正確な状況を把握し続けるには、変化を継続的に捉える必要があります。AIエコシステムは急速に進化し、新しいエージェントフレームワーク、MCPサーバー、モデル、ツールが絶えず登場します。こうしたコンポーネントを認識し、その役割を理解することが、可視性を持続可能なセキュリティ態勢へと変えます。

AIサプライチェーンは、従来のセキュリティモデルが追いつけないほどの速さで進化しています。継続的な可視性によって、余計な摩擦を生むことなく先手を打つ方法をご紹介します。