In this article
SBOMからAI-BOMへ:AIネイティブシステムにおける可視性を再考する
長年にわたり、ソフトウェア部品表(SBOM)はガバナンスの信頼できる基盤として機能してきました。アプリケーションに何が含まれているかを把握し、リスクを評価し、高まるコンプライアンス要件に対応するための手段をチームに提供してきたのです。しかし、ソフトウェア開発がAIネイティブシステムへと移行するにつれ、その基盤は崩れ始めています。
そこで登場するのが、AI部品表です。AI-BOMは、リポジトリ、パイプライン、稼働中のシステムにまたがり、現代のアプリケーションを形作るAIネイティブなコンポーネントを可視化します。モデル、エージェント、プロンプト、データセット、関連サービスのすべてが対象となります。SBOMがソフトウェアガバナンスの基盤である一方、AI-BOMはAIネイティブセキュリティの中核となりつつあります。
このガイドでは、コンポーネントが頻繁に変化し、ビルド時ではなく実行時に振る舞いが形作られるAI主導のエコシステムにおいて、SBOM型の考え方がもはや通用しない理由を解説します。また、組織がAI-BOMを基盤となる機能として採用し始めている理由と、可視性の確保が最初に取り組むべき最も緊急の課題である理由も説明します。ツールが急速に変化し、シャドーAIが広く浸透する世界では、何が存在するかを把握することが、その先に続くすべての取り組みの出発点です。
AI時代にSBOMの考え方が通用しない理由
AI-BOMが不可欠になった理由を理解するには、まず従来の方法が通用しなくなった背景を考える必要があります。SBOMを形作った前提は、コンポーネントが有限で、依存関係が把握でき、変化のペースも緩やかなソフトウェアの世界に根ざしていました。AIネイティブシステムは、まったく異なる条件下で動作します。組織がどのように対応しているかを見る前に、SBOM時代のなじみ深い前提がAI時代に崩れる理由を考えてみましょう。
AIコンポーネントは絶えず変化する
AIネイティブシステムの特徴は、絶え間ない変化です。それらを支えるコンポーネントは、従来の依存関係のように扱えるほど長く同じ状態にとどまりません。こうした変動性は、例外ではなく当たり前になっています。
新たな機能や最適化のリリースに伴い、モデルは週単位、場合によってはそれ以上の頻度で更新されます。エージェントフレームワークも同じ速さで進化し、新たな抽象化、ツール、実行パターンが公開リポジトリに次々と登場します。MCPサーバーは新しいツールやワークフローを公開するために立ち上げられ、多くの場合、長期計画ではなく目の前の開発ニーズに応じて導入されます。実行可能なロジックとしての役割を強めるプロンプトは、継続的に編集、改良されます。データセットも新しいデータの追加、フィルタリング、置き換えによって変化し、周囲のコードを変更しなくてもモデルの振る舞いを変えます。
これらのコンポーネントは、ライブラリのようにバージョンを固定できるものではありません。単一のリポジトリに集約されてもいません。個々の開発者が、ほとんど手間をかけずに導入することもあります。静的な依存関係と同じように扱えば、たちまち死角が生まれます。
AIネイティブ環境のガバナンスでは、流動的で、分散し、絶えず変化するコンポーネントを考慮する必要があります。
根本的な課題は可視性
多くのセキュリティリーダーにとって、課題はAIシステムが下す可能性のあるあらゆる判断を理解することではありません。CISOは、個々のプロンプトや出力のレベルでエージェントの振る舞いを分析しようとしているわけではありません。まず必要なのは、もっと基本的なこと、つまり何が存在するかを把握することです。
組織全体で実際に使用されているエージェント、モデル、MCPサーバーを把握したいと考えています。それらのコンポーネントがどのツールやワークフローを公開し、どの外部システムにアクセスできるのかも知る必要があります。また、振る舞いに影響を与えるデータセットやプロンプトについての洞察も欠かせません。これらの入力は、コードそのものと同じくらい重要な場合があるためです。
こうした把握がなければ、リスクの評価、ポリシーの策定、問題発生時の効果的な対応は不可能です。従来のSBOMは、こうしたレベルの洞察を提供するために設計されたものではありません。AIネイティブシステムを形作る、稼働中で進化し続けるコンポーネントではなく、ある時点での静的な依存関係を記録するものです。その結果、セキュリティチームはAIを効果的に管理するために必要な可視性を得られません。
セキュリティリーダーから寄せられた声
可視性のギャップは、もはや理論上の問題ではありません。進化するAI環境に既存の管理策を適用しようとするセキュリティリーダーとの会話で、繰り返し浮き彫りになっています。
フレームワークの急増
多くの大企業では、課題はまずその数の多さにあります。ある企業では、開発チーム全体で新しいエージェントフレームワーク、オーケストレーションツール、モデルパッケージ、MCPサーバーが絶えず増えていると説明していました。開発者は開発を加速するため、すぐにそれらを採用します。一方で、ガバナンスチームは追いつけませんでした。
セキュリティとコンプライアンスの取り組みは後手に回りました。あるフレームワークのレビューが終わる頃には、すでに別のフレームワークが登場していました。問題はイノベーションへの反対ではなく、何が存在するかを明確に把握できていないことでした。
この企業にとって、AI-BOMは不可欠なものになりました。リポジトリ全体のAIコンポーネントを確実に追跡できるため、エコシステムが変化し続ける中でもガバナンスを可能にする基準を確立できました。
AI-BOMはまだ発展途上でも、不可欠です。
別の企業は、より慎重ながらも同じ切迫感を持って、自社のアプローチを説明しました。AI-BOMはまだ初期段階にあると感じると認めています。標準は整備されつつあり、ベストプラクティスもまだ確立されていません。それでも、避けては通れないと考えています。
AIコンポーネントは、実験的なツールの域を超え、重要な依存要素となりました。モデル、エージェント、関連サービスは、アプリケーションの動作やデータ処理の方法を直接左右しています。同時に、規制当局もAIサプライチェーンの透明性、来歴、説明責任に関する期待を示し始めています。
完璧な指針を待つことは、もはや現実的な選択肢ではありません。この企業にとって、AI-BOMの導入は成熟度よりも準備に関わるものです。今、可視性を確立することで、要件の変化に合わせて構築できる基盤を整えられます。要件が正式に定められてから慌てて追いつく必要はありません。
新しいものを追跡できるツールを期待しています。
こうした会話では、もう一つのテーマも同じように繰り返し話題に上ります。組織はもはや、自らAIエコシステムを追跡することを期待していません。セキュリティチームは、新しいエージェントフレームワーク、MCPサーバー、モデルパッケージ、プロンプト、データセットがいかに速く登場するかを理解しています。手作業によるレビュープロセスを定める頃には、環境はすでに変化しています。人手だけで信頼できる最新のインベントリを維持するのは、もはや現実的ではありません。
そのため、組織はSnykが代わりに最新状況を把握することを期待しています。自動検出を活用して、新しいコンポーネントが登場するたびに発見し、絶え間ない手作業を必要とせずに最新の可視性を維持しています。これほど速く変化するエコシステムでは、自動化は単なる利便性ではありません。可視性を変化のペースに合わせる唯一の手段です。
新たなAI攻撃対象領域:まず可視性を確保し、その先へ
AIコンポーネントが急速に増え、手作業での追跡には限界があると組織が認識すると、焦点はツールの選定からリスクへの露出へと移ります。
シャドーAIの急増
AIの導入が加速する中、新たな種類のリスクが生まれています。シャドーAIは、個別の実験や単発のツールにとどまらず、大きく広がっています。正式なレビューを経ないまま、アプリケーションの動作をひそかに左右するコンポーネントが増え続けています。
タスクの自動化やワークフローのオーケストレーションを目的に、承認されていないエージェントが立ち上げられます。文書化されていないMCPサーバーが、明確な管理責任者もないまま新しいツールや機能を公開します。モデルを社内システムに接続するアドホックなラッパーは、目の前の問題を解決するために作られ、その後もそのまま残されることがよくあります。アプリケーションのロジック内に隠れたLLM呼び出しが現れる一方、プロンプトチェーンは単なる入力ではなく、機能上の意思決定経路として組み込まれています。
個々に見れば、こうした要素の多くは無害に見えます。しかし、それらが集まると、把握が難しく見落としやすいAI攻撃対象領域が生まれます。シャドーAIを定義するのは、意図や高度さではなく、見えないことです。標準的な検出やガバナンスの対象外にあるコンポーネントは、存在を知られていないというだけでリスクをもたらします。
現実に存在する可視性のギャップ
こうしたギャップは、実際の環境にも現れています。ある企業では、定例のデモ中に稼働中のMCPサーバーが発見されました。AppSecはそれまでその存在を知りませんでした。設定ミスも、悪用もありませんでした。チームが頼りにしていた管理策から、そのサーバーが見えていなかっただけです。組織を問わず、同じパターンが見られます。動作に重大な影響を与えるAIコンポーネントが、正式な検出プロセスの対象外に存在するのです。それは過失によるものではなく、既存の管理策がそもそも検出できるように設計されていなかったためです。
AI-BOM:新たな信頼できる情報源
これらのギャップを総合すると、新たな信頼できる情報源が必要であることがわかります。AI-BOMは、AIネイティブ環境でSBOMが提供するようには設計されていなかった可視性を実現します。
AI-BOMは、AIシステムの動作を定義するコンポーネントをインベントリ化します。使用中のモデル、その上に構築されたエージェント、エージェントが呼び出すツールやチェーンを追跡します。MCPサーバーと公開される機能に加え、振る舞いを形作るプロンプトやデータセットも記録します。また、アプリケーションの境界を越えて機能を拡張する外部AI APIも対象とします。
こうした可視性が、具体的な対応の基盤となります。ガバナンスは想定ではなく実態に基づくようになります。モニタリングの対象を、実際に存在するものに絞り込めます。レッドチーム演習では、仮説上のワークフローではなく、実際の構成を検証できます。AI-BOMはインベントリから、運用の中核へと進化します。
AI-BOM ≠ SBOMである理由
名称は似ていても、AI-BOMは従来のSBOMとは根本的に異なります。SBOMは、コンポーネントが安定し、更新が予測可能で、依存関係ツリーが明確なソフトウェアシステム向けに設計されました。AIネイティブシステムは、それとは異なる条件下で動作します。
SBOM | AI-BOM |
|---|---|
緩やかで予測可能な更新 | 絶え間なく予測不能な変化 |
ライブラリ/パッケージ | モデル、エージェント、プロンプト、データセット、MCP |
明確な来歴 | 創発的で不透明な来歴 |
中程度の発見可能性 | 高い検出難易度 |
こうした違いは、ガバナンス、モニタリング、ポスチャ管理に実質的な影響を及ぼします。
自動化が不可欠な理由とSnykがリードする理由
AIエコシステムの変化の規模と速さから、明らかなことが一つあります。手作業での追跡では追いつけません。この規模になると、人手によるレビューは機能しなくなります。新しいコンポーネントを特定した時点で、すでに複数のチームやワークフローで使われている可能性があります。
そこで自動化が不可欠になります。AIコンポーネントが登場し変化する中で正確な状況を把握し続けるには、継続的な検出と分類が現実的な唯一の方法です。Snykは、自動検出と継続的な調査を組み合わせ、この分野をリードしています。新しいフレームワーク、MCPサーバー、モデルのパターン、データセットが登場すると、すぐに把握できます。
Snykの調査力
自動化だけでは、それを導く洞察がなければ十分ではありません。継続的にスキャンすることと同じくらい、何をスキャンすべきかを知ることが重要です。
Snykの専任AIサプライチェーン調査チームは、エコシステムがリアルタイムでどのように進化しているかを把握することに注力しています。新たに登場するエージェントフレームワークを追跡し、新しいMCPのパターンや利用モデルを分析し、実環境で発見された新たなAI攻撃ベクトルを調査します。また、モデルファミリーやデータセットの種類が急速に拡大する動向を追い、こうした変化がどのように新たな依存関係やリスクを生み出すかを見極めています。
この調査は、AI-BOMを常に最新の状態に保つために直接活用されています。お客様が新しいリリース、フレームワーク、パターンを一つひとつ監視する必要はありません。Snykが代わりに調査し、エコシステムの変化を、信頼して活用できる検出結果とコンテキストに変換します。調査に支えられたAI-BOMの価値の核心はここにあります。AIサプライチェーンそのものと同じ速さで進化する可視性です。
AIガバナンスとAI-SPMの基盤となるAI-BOM
AIシステムが実験段階からビジネスの中核となるワークフローへと移行するにつれ、信頼できる基盤の必要性は避けて通れなくなっています。SBOMがソフトウェアガバナンスのベストプラクティスから必須要件へと進化したように、AIネイティブ環境ではAI-BOMも同じ道をたどりつつあります。
AI-BOMは、ガバナンスに関する意思決定を支え、データを保護し、レッドチーム活動の指針となり、エージェントのアクティビティを監視し、規制当局の審査に備えるために必要な可視性をもたらします。規制当局からのシグナルも、すでにこの方向を示しています。
しかし、可視性だけでは不十分です。AI環境が拡大するにつれ、組織には数百ものモデル、エージェント、データセット、コネクターにわたるセキュリティ態勢を継続的に把握する方法が求められます。静的な一覧としてではなく、日々変化する生きたシステムとして理解することが重要です。ここでAI-BOMは、AIセキュリティ態勢管理(AI-SPM)の基盤となるインプットとなります。
AIサプライチェーンの進化は、SBOM時代の考え方では追いつけないほど速く進んでいます。シャドーAIは拡大し続け、監視の目も厳しくなっています。このような環境において、AI-BOMはAIネイティブシステムにとって不可欠な信頼できる情報源となります。
SBOMが過去10年間のソフトウェアセキュリティを形作ったように、AI-BOMはこれからの時代を形作るでしょう。Snykは、AI-BOMを進化させて本格的なAI-SPMへと発展させ、単なるインベントリを、継続的で実用的なセキュリティインサイトへと変える、研究に裏打ちされた基盤を構築しています。
Snyk EvoがAI-BOMの可視性を高め、AIシステムの内部構造を明らかにし、AIセキュリティ態勢に対する新たなアプローチの土台を築く方法をご覧ください。研究に裏打ちされたAIセキュリティの実践例をご紹介します。
チートシート
Evo AI-SPMでAIリスクをコントロール
Evo AI-SPMでエージェントを保護し、拡大するAI環境を把握して、自信を持ってAIをガバナンスする方法をご紹介します。