企業のサプライチェーンを確保することが問題になるとき、そこには今やAIアプリケーションやエージェントが大きく入り込んでいます。そのような状況で、ソフトウェア部品表（SBOM）は、環境内のすべてのコンポーネントの完全な棚卸しにはもはやなりません。そこで登場するのがAI-BOMです。

従来の SBOM が組織内のすべてのソフトウェアパッケージと依存関係を含むのに対し、AI-BOMは、AI資産によって生まれるギャップを埋めることを目的としています。つまり、すべてのモデル、データセット、SDKライブラリ、MCPサーバ、MLフレームワーク、エージェント、エージェントのスキル、プロンプト、そしてその他のAIツールにわたる可視性を提供することで、それらを網羅します。さらに、各AIコンポーネントが互いにどう相互作用し、どのようにワークフローに接続するのかも含めます。

レシピも分からない、材料も分からない、焼いた人も分からない。そんなケーキを一切れ食べますか？

「この部屋の真ん中にAIが誕生日ケーキとして置かれていると想像してみてください。でも、それがどうやってそこに来たのかは分からない。そうです、レシピも分からない、材料も分からない、焼いた人も分からない。そんなケーキを一切れ食べますか？」と、Palo Alto NetworksのAIセキュリティ担当VPであるIan Swanson氏は、The Registerのインタビューで述べました。

とはいえ、多くの組織はとにかくそのケーキを食べています。

テックスタックに対して企業が正式に認めたモデルや、そこで使われるAIがあることに加え、もう一つの問題があります。それが「shadow AI（シャドーAI）」――昔はこれを「シャドーIT」と呼んでいました――です。これらの承認されていないツールも、説明責任のために影から引き出して把握できるようにする必要があります。具体的には、個々の従業員が思いつきで立ち上げる“vibe coding”プラットフォームやエージェントに加え、業務用のPC上でそれらとやり取りする外部チャットボット、そして場合によっては機密性の高い社内データを入力してしまうことまで含まれます。 

ケーキに焼き込まれたこれらすべてのAIの材料を守るには、まず企業がそれらが何なのか、何と接続されているのか、そしてどのように使われているのかを把握する必要があります。

返却形式: {"translated": "翻訳されたHTML"}

「一般に、AIセキュリティを理解しようとしている組織は、」とシスコのAI脅威インテリジェンスおよびセキュリティリサーチ責任者であるAmy Chang氏はThe Registerに語った。「自社の環境に存在するAI資産が何かを特定できる手段が必要です。AIの部品表（AI bill of materials）のようなツールは、その存在をより把握し始めるための最初の場所の1つになります。」

次は: モデルの来歴（provenance）

シスコは以前、AI-BOMをオープンソース化しており、誰でもコードベース、コンテナイメージ、クラウド環境をスキャンして、この部品表を生成できるようにしています。

さらに金曜日には、モデルの来歴を追跡するためのオープンソースツールとして、自社のModel Provenance Kitも公開しました。新しいリポジトリを告知するブログの中で、Chang氏やほかのAI研究者はこれを、AIモデルのDNAテストだと説明し、来歴は2つのモードのいずれかで判定するとしています。比較（compare）かスキャン（scan）です。

比較モードでは、任意の2つのモデルを入力として、その類似性をメタデータ、トークナイザ構造、重みレベルのシグナルとともに示し、最後に統合スコアを出します。スキャンモードは単一のモデルから始め、それをデータベースに照合して、最も近い系統（lineage）の候補を特定します。また、このモードを支援するために、シスコはさらにモデルのフィンガープリントデータベースも公開しており、45以上のファミリーにまたがる約150のベースモデル、そして20以上のパブリッシャーをカバーしています。

Chang氏は、新しいAIツールが2つのゲートチェックを実行すると私たちに説明しました。「まず、メタデータのレベルで、ベースモデルの情報と、ファインチューニングされたモデルの情報を比較し、ある種の来歴に紐づく関係を切り分けます。たとえば『MetaのLlama 4から派生した』とか『AlibabaのQwen3から派生した』といった具合です」と彼女は言いました。

「次に、我々が行うのは、重みベースの指標（signifiers）を見ることです。つまり、あなたが使って展開するモデル、顧客向けに提供され、これらすべてのデータを取り込んでいるモデルが、本当にあなたが使うことになっている“そのモデル”であること、または“あなたのリスク許容範囲の枠内にある”モデルであることを、検証可能で、反復可能で、証明可能な形で裏付けるような手段を提供しているわけです。」

組織は、自分たちの環境にどのようなAI資産が存在するのかを特定する方法を必要としている

インタビューの間、Chang氏はCursorのComposer 2を挙げました。これは一部が中国のオープンソースモデルであるKimi 2.5に基づいています。「彼らは、はい、この中国のモデルを使ってこれを作りました、と非常に素早く認めました。でもそれには規制やコンプライアンス上のリスクがあり得ます」と彼女は語りました。

具体例を挙げると、欧州連合のAI Act（AI法）は、組織にトレーニングデータの文書化を義務付けており、トレーニング手法の特徴や「高リスクシステム」に関するリスク評価も含めています。

また、GoogleのWizはAI-BOMにおいて、AIアプリケーションを作るのに投入されたノートPCや統合開発環境（IDE）など、開発者のワークステーション内のあらゆるツールを把握することも織り込んでいます。

Wizのテクニカル・プロダクト・マーケティング・マネージャーであるZiad Ghalleb氏は、私たちに「多くの人が可視性やBOMを、最終成果物の中に実際に何が入っているかによって定義しています。ただ、我々は一般にBOMの定義を、特にAI-BOMに関しては、そのアプリケーションを作るのに投入されたAIツールも含むように拡張しています」と説明してくれました。 

「そしてもう一つ重要な点は、これらのAIワークロードに付随するアイデンティティです。というのも、すべてのエージェントやモデル、ツールなどは、あなたの環境の中の特定のアイデンティティに紐づいているからです」とGhalleb氏は付け加えました。「だから、これらのシステムに関連する“非人間”のアイデンティティを見ていく必要があります。リソースだけではありません。そこに紐づくアイデンティティや権限セット（permission sets）も含まれます。」

これらすべてが、可視性とセキュリティに帰着します。「もしこれらのワークロードの可視性がなければ、それをどうやって守るべきかを本当に理解することはできません」とSwanson氏は言っています。 

汚染（ポイズニング）への対策

企業だけが、AIツールを自社のワークロードや業務プロセスに取り込もうと、我先にと突進しているわけではありません。The Regを読む人ならおそらく誰でも知っている通り、犯人もまた同じツールを使って、より速く行動し、攻撃をより効率的にすることができるのです。

MicrosoftのGMでグローバル脅威インテリジェンス責任者であるSherrod DeGrippo氏は、以前のインタビューでThe Registerにこう語っています。「これには、侵害されたコンピュータに対して偵察を行うといったタスクや、攻撃インフラを立ち上げて管理する、といったことも含まれます。」

「システムに対するエージェント型の自動化された偵察は、調べる価値があるものです」とDeGrippo氏は言いました。「XYZのことを突き止めてきて、あなたが見たものをすべて持ってきてください。特定のこの組織が所有しているネットワークブロックをスキャンしてみてください。」

Swanson氏によれば、これは防御側がより迅速に対応するためにAI-BOMが役立ち得るケースでもあります。彼は会社名は明かせないと言いますが、Palo Alto Networksが対応したあるインシデントでは、犯罪グループがAIを使って被害組織を下調べし、露出しているエンドポイントを特定したそうです。 

「彼らがやったことの一つは、システムプロンプトへのアクセスを得ることです。システムプロンプトは、AIワークロードに対して“何ができて、何ができないか”を指示するものです」とSwanson氏は言いました。そして攻撃者が、その会社の内部AIのシステムプロンプトにアクセスできるようになると、それらを改変して、AIに本来やってはいけないことを強制しました。たとえばデータを盗んで、外部のメールアカウントに送る、といった具合です。

AI-BOMは、特定の時点におけるAIシステムの設定や依存関係を理解するための情報を提供し、さらに、変更があった場合も示します。

「状態（state）を理解し、状態の変化も理解できていれば、AIの部品表にさかのぼって、『AIアプリケーションを作る材料（ingredients）の中で、どのシステムプロンプトが使われたのか？』と確認できます。そして、それが以前の状態から新しい状態に変わっているのが分かる。だから、おそらくそれはチェックして、ここで何か良くないことが起きていないかを見た方がいい、ということになります」とSwanson氏は言いました。「そうすれば、捕まえられるはずです。」

• 終わりのないサプライチェーン攻撃がSAPのnpmパッケージや他の開発ツールへ侵入
• 暴走したエージェント！ 企業が信頼できないボットに王国の鍵を渡す
• OpenClawは、単純な突破で個人の生々しい情報を開示してしまう
• AIエージェントは、北朝鮮を含む攻撃者の雑務を今や支援する

モデルのようなものやスキルの汚染といった、その他のサプライチェーン攻撃は、IT環境でどのAIツールが使われているのかを把握していないことによるリスクを改めて浮き彫りにします。 

「こうした多数のコーディング支援者と連携して人が使うスキルは、かなり簡単に改ざんできてしまうため、誰かが能力を操作していないかを確認するためにスキャンできることが重要です」とスワンソン氏は述べました。スキルが天気予報を提供するはずなら、同時に資格情報を盗んだり、秘密情報を漏えいさせたりするべきではない、と同氏は説明しました。

「状態の変化を理解し、こうした成果物について継続的にサプライチェーン上のリスクをスキャンし、そのうえで実行時点、つまりAIアプリケーションが実際に稼働している段階になったら、すべての通信も見て、何か良くないことが起きていないかを確認します」とスワンソン氏は語りました。

AI-BOM（およびそれに対応するソフトウェア側の仕組み）によっても、組織は企業のシステム上で動作している侵害済みのオープンソースコードを迅速に特定できます。たとえば、汚染されたnpmおよびPyPIパッケージが最近相次いだことや、それより前のShai-Huludワームによる資格情報窃取攻撃が挙げられます。これらはいずれも、AIアプリケーションに一般的に組み込まれているコードを標的にしたものでした。

CVEの識別子がなくても、AI-BOMを使えばユーザーは「関連するライブラリやパッケージ」を照会でき、さらに自社環境内で悪意のあるバージョンがないかを特定できる、とガレーブ氏は言います。「それらにはCVEが付いていないわけですが、少なくとも、進化し続ける脅威を封じ込めるために、それらをどう取り除けばよいかが分かります。」®

詳細:

• AI
• セキュリティ
• ソフトウェア・ビル・オブ・マテリアル

これらに近い内容