AIサプライチェーン攻撃防御ガイド 2026
はじめに——「信頼できる場所から取り込んだ」が最大の盲点
これまでのAIセキュリティ記事では、プロンプトインジェクション、エージェントの目標ハイジャック、推論エンドポイントへのモデル抽出攻撃といった「動いているシステムへの攻撃」を中心に扱ってきました。しかし2026年、もう一つの攻撃面が急速に現実化しています。それは、「導入・統合フェーズそのもの」に毒が仕込まれているというサプライチェーン攻撃です。
攻撃者はあなたのシステムに直接侵入しません。あなたが「信頼できる場所」だと思って使っているHuggingFaceのモデルハブ、MCPサーバーの公式レジストリ、人気のプラグインリポジトリ——その取り込みの入口を汚染します。結果として、あなたのAIシステムは侵害されたコンポーネントを「正規の手順で」自ら招き入れてしまいます。
従来のセキュリティ対策は「動いているシステムを守る」発想です。サプライチェーン攻撃は、そのはるか上流——「何を信頼してシステムに組み込むか」という信頼チェーンそのものを狙います。ファイアウォールもプロンプトフィルタも、「自分が招き入れたもの」には無力です。
本記事では、2026年時点で現実化しているAIサプライチェーン攻撃の4つの侵入経路と、モデル来歴検証・署名検証・サンドボックス実行・依存関係スキャンによる多層防御の実装方針を整理します。想定読者は、HuggingFaceや公開モデルレジストリからモデルを取り込んでいる開発・MLOpsチーム、MCPやプラグインエコシステムを活用している企業のAI担当者、CISOおよび情シスの方々です。
前提——AIサプライチェーン攻撃の4つの侵入経路
「AIサプライチェーン攻撃」と一口に言っても、侵入経路と狙いは大きく異なります。まず4つの経路を分けて理解することが、適切な防御策の設計につながります。
経路1：モデルハブ経由（HuggingFace等のmaliciousモデル）
HuggingFaceをはじめとするモデルハブには、誰でもモデルを公開できます。攻撃者は、人気モデルに酷似した名前（タイポスクワッティング）や、「軽量化・高精度・日本語対応」といった訴求力のある説明文をつけた偽モデルを公開します。
こうした悪意あるモデルに仕込まれうる手口は主に3つです。
- バックドア（トロイの木馬）： 特定のトリガー入力を受けたときだけ、攻撃者が意図した出力（有害なコード・誤情報・機密漏洩）を返すよう重みが細工されている。通常の評価では検知されにくい。
- Pickle/SafeTensorに仕込まれた悪意あるコード： PyTorchのPickle形式のモデルファイルは、ロード時に任意のPythonコードを実行できる。マルウェアのダウンロード、環境変数・APIキーの外部送信、バックドアの設置が可能。
- データポイズニング済みモデル： ファインチューニング段階で毒入りデータを混入させ、特定の入力に対して誤った推論や有害な出力を引き出すよう学習させたモデル。
経路2：MCPサーバーレジストリへの偽サーバー混入
MCP（Model Context Protocol）は、AIエージェントが外部ツール・データソースと連携するための標準プロトコルとして急速に普及しています。公式・非公式を問わずレジストリが整備されつつある中、攻撃者は正規サービスに見せかけた偽MCPサーバーをレジストリに登録する手口を使います。
エージェントがこの偽MCPサーバーを呼び出すと、ツール呼び出しを通じて悪意ある指示がエージェントのコンテキストに挿入され（ツール呼び出し経由のプロンプトインジェクション）、エージェントの行動をハイジャックしたり、実行環境から機密情報を外部送信したりすることが可能になります。MCPのtool descriptionやリソース応答の中に隠し命令を埋め込む手口が、すでに研究・実証されています。
経路3：プラグイン・拡張機能の汚染
AIプラットフォームのプラグインや、開発環境のAI拡張機能（VSCode拡張等）も標的になります。攻撃の形態は2種類あります。
- 最初から悪意ある偽プラグイン： 人気プラグインの類似名で公開し、インストールを誘導する。
- 正規プラグインの乗っ取り： メンテナのアカウントを侵害し、更新版に悪意あるコードを混入させる（サプライチェーン攻撃の古典的手口。npm/PyPIで繰り返し発生している手口のAI版）。
インストール後のプラグインは高い権限を持つことが多く、ユーザーの入力・AIの出力・APIキー・ファイルシステムへのアクセスが可能な場合があります。
経路4：ファインチューニング前のベースモデル汚染
自社データでファインチューニングを行う場合、そのベースモデル自体が汚染されているリスクがあります。汚染されたベースモデルの上でファインチューニングを行っても、バックドアや偏ったバイアスは引き継がれたまま残ります。「商用ライセンスで使えるオープンモデル」として公開されているものでも、来歴が不明確なモデルはこのリスクを抱えます。
標準フレームワークでの位置づけ
これらの攻撃は、業界標準フレームワークに明確に定義されています。
| 侵入経路 | OWASP LLM Top 10（2025） | MITRE ATLAS |
|---|---|---|
| モデルハブの悪意あるモデル | LLM03:2025 Supply Chain Vulnerabilities | AML.T0010 ML Supply Chain Compromise |
| 偽MCPサーバー・ツール呼び出しインジェクション | LLM05:2025 Improper Output Handling / LLM04 Data and Model Poisoning | AML.T0048 Societal Harm / AML.T0051 LLM Plugin Compromise |
| プラグイン汚染 | LLM06:2025 Excessive Agency / LLM03 Supply Chain | AML.T0010 ML Supply Chain Compromise |
| ベースモデル汚染（バックドア） | LLM04:2025 Data and Model Poisoning | AML.T0018 Backdoor ML Model |
OWASP LLM Top 10の2025年版では、LLM03:2025 Supply Chain Vulnerabilitiesとして、モデルハブからのmaliciousモデル、汚染されたファインチューニングデータ、脆弱なサードパーティコンポーネントが明示的に列挙されています。これは「特殊な懸念」ではなく、2025年以降のAIセキュリティ標準が正面から扱う中核リスクです。
攻撃の実像——”正規ルート”だからこそ検知が難しい
サプライチェーン攻撃の最大の特徴は、「正規の手順を踏んでいる」点です。モデルのダウンロード、レジストリからのサーバー登録、パッケージマネージャーでのインストール——いずれも普通の開発オペレーションと区別がつきません。
2025〜2026年にかけて観測・報告されている具体的な手口を整理します。
| 手口 | 検知の難しさ | 実被害の例 |
|---|---|---|
| HuggingFaceへのPickle形式悪意モデル | ロード時に実行されるため、静的な中身確認だけでは不十分 | 環境変数・シークレット外部送信、マルウェア実行 |
| MCPレジストリへの偽サーバー登録 | tool descriptionは自由記述で審査がない | エージェントの行動ハイジャック、機密情報の外部送信 |
| 人気プラグインのアカウント乗っ取り後の更新 | 既存インストール済みユーザーへの自動更新で感染拡大 | キーロギング、会話内容の傍受 |
| バックドア入りベースモデル | 通常のベンチマーク評価では発火しない | 特定トリガーで誤情報・有害コード出力 |
従来のセキュリティ対策——WAF、エンドポイント保護、入力フィルタリング——は、「外から攻撃が来る」前提で設計されています。サプライチェーン攻撃は、信頼チェーンの上流を汚染することで、これらを全部スルーします。「信頼済みのはず」だからこそ検査が省略されやすく、侵害の発覚が遅れます。
第1の防御層：モデル来歴検証（Provenance Verification）
来歴検証とは、「このモデルは誰が、何から、どのように作ったか」を追跡・確認することです。来歴が不明確なモデルを信頼するのは、製造元不明の薬を飲むようなものです。
来歴情報として確認すべき事項
- 作成者の同一性： モデルカードの公開者が、主張するorganizationの公式アカウントと一致しているか。HuggingFaceではorganizationの認証バッジを確認する。
- 学習データの出典： どのデータで学習したか。ライセンスは適切か。PIIや著作権問題のあるデータが含まれていないか。
- ベースモデルの来歴： ファインチューニング済みモデルの場合、どのベースモデルから作られたか。そのベースモデルの来歴は追跡可能か。
- モデルカードの内容： 評価結果、既知の限界、意図された用途が記載されているか。情報が極端に少ない・または過大な主張があるモデルは疑う。
ML-BOM（機械学習部品表）の活用
ソフトウェア開発のSBOM（Software Bill of Materials）に相当する概念として、ML-BOM（Machine Learning Bill of Materials）の策定が進んでいます。自社で使用するモデルの来歴・バージョン・ライセンス・学習データの出典を記録する「部品表」を維持することで、インシデント時の影響範囲の特定と、監査対応が可能になります。
実装の入口として、最低限以下を記録します。
- モデル名・バージョン・ハッシュ（SHA-256）
- 取得元URL・取得日時
- 公開者・ライセンス種別
- ベースモデルの来歴（ファインチューニング済みの場合）
- 内部でのスキャン・評価結果と実施日
「モデルカードがない＝使わない」の原則
実務的な判断基準として、モデルカードが存在しない・または著しく不完全なモデルは採用しないという原則を設けることが有効です。正規の公開者であれば、評価結果・用途・限界事項を記載するインセンティブがあります。記載のないモデルは、来歴の隠蔽や急ぎの公開（＝検証不足）を示唆します。
第2の防御層：署名検証（Cryptographic Signing）
来歴情報は「主張」に過ぎません。改ざんされていないことを技術的に保証するのが署名検証です。
モデルファイルのハッシュ検証
最もシンプルかつ即座に実装できる手法です。モデル取得後、配布元が公開しているSHA-256ハッシュと照合します。ハッシュが一致しなければ、ファイルが転送中に改ざんされているか、配布元とは別の場所から取得していることを意味します。
- HuggingFaceは各ファイルのSHA-256を公開している。モデルロード前に必ず検証する。
- CI/CDパイプラインにハッシュ検証ステップを組み込み、自動化する。
- 検証済みモデルの社内キャッシュ（アーティファクトリポジトリ）を用意し、毎回ハブから直接取得しない構成が理想。
Sigstore / cosignによるモデル署名
コードの世界で普及が進むSigstore（cosign）は、機械学習モデルへの適用も始まっています。公開鍵基盤（PKI）を使った署名により、「このモデルは特定の組織・個人が作成し、それ以降改ざんされていない」ことを暗号学的に検証できます。
MCP・プラグインにおいても同様に、インストール前に署名を検証することが防御の基本です。署名のないプラグインをインストール可能にする設定は、組織のセキュリティポリシーとして禁止することを検討してください。
SafeTensors形式への移行
Pickleファイルは、ロード時に任意のPythonコードが実行されるため本質的に危険です。SafeTensors形式（HuggingFaceが推進するシリアライズ形式）は、コードの実行を許さない安全な設計になっています。Pickle形式のモデルはポリシーとして拒否し、SafeTensors形式に限定することで、ファイルロード時の任意コード実行リスクをほぼ排除できます。
第3の防御層：サンドボックス実行
署名検証をすり抜けた場合の最後の砦が、サンドボックス実行です。「疑わしいものは隔離された環境で動かす」というゼロトラスト的発想を、AIコンポーネントの統合にも適用します。
モデルロードのサンドボックス化
特に信頼性の低いソースから取得したモデルは、本番環境に直接ロードせず、ネットワーク遮断・ファイルシステム制限・権限最小化を施したコンテナ環境でロード・評価します。
実装上のポイントは以下の通りです。
- ネットワーク遮断： モデルロード中の外部通信を遮断する（Pickle悪意コードによる外部送信を防ぐ）。
- ファイルシステム制限： コンテナ内で書き込み可能なパスを最小化する（シークレットや認証情報へのアクセスを防ぐ）。
- 権限の最小化： ルート権限でロードしない。capabilities を最小限に制限する。
- リソース制限： CPU/メモリ上限を設け、リソース枯渇攻撃を防ぐ。
MCPサーバーのサンドボックス実行
MCPサーバーを実行する際も、同様の隔離原則が適用されます。
- プロセス分離： MCPサーバーごとに独立したプロセス・コンテナで実行する。1つのサーバーが侵害されても、他のコンポーネントへの横展開を防ぐ。
- 権限スコープの明示： MCPサーバーが必要とする権限（読み取り可能なファイルパス・呼び出せるAPI・アクセスできるDBなど）を事前に定義し、それ以外を拒否する。
- アウトバウンド通信の制限： MCPサーバーが許可されていないエンドポイントに通信を試みた場合に検知・遮断するネットワークポリシーを設定する。
動的解析・行動監視
サンドボックス内でモデルやサーバーを実行しながら、その実際の振る舞いを観測します。予期しないシステムコール、不審なネットワーク接続、異常なファイルアクセスが発生した場合にアラートを上げる仕組みです。これは静的な署名検証では検知できない「条件付き悪意コード」の発見に有効です。
第4の防御層：依存関係スキャン
AIシステムはモデル単体ではなく、膨大な依存パッケージ（transformers, torch, langchain, 各種MCPクライアントライブラリ等）の上で動きます。これらの依存関係そのものが攻撃経路になります。
SCA（ソフトウェアコンポジション解析）のAIスタックへの適用
一般的なSCAツール（Trivy, Grype, Dependabot, Snyk等）を、AIシステムの依存関係にも適用します。既知のCVEを持つライブラリバージョンの使用を検知し、CI/CDパイプラインで自動的にブロック・アラートします。
AIスタック特有の注意点として以下があります。
- Pickleを含む依存： モデルの依存パッケージ自体がPickle形式のデータをロードしている場合、そこにも悪意コードが混入しうる。
- LLMフレームワークの更新速度： LangChain, LlamaIndex等のAIフレームワークは更新が非常に速く、CVEの発見と修正のサイクルも短い。定期スキャンだけでなく、リアルタイムアラートの設定が重要。
- MCPクライアントライブラリ： MCPのPython/TypeScript SDKは新興のエコシステムであり、依存関係の監視は欠かせない。
プライベートモデルレジストリ・パッケージミラーの運用
依存パッケージを毎回パブリックリポジトリから直接取得することは、「汚染されたタイミング」で更新が入るリスクを常に抱えることを意味します。社内でスキャン済みのパッケージ・モデルを管理するプライベートレジストリ・ミラーを運用し、開発者が直接パブリックリポジトリから取得することをポリシーで制限する構成が理想です。
- AIモデル：社内モデルリポジトリ（Artifactoryの汎用リポジトリ、またはHuggingFace Enterprise Hub等）
- Pythonパッケージ：社内PyPIミラー（Nexus, Artifactory等）
- MCPサーバー：承認済みサーバーの社内カタログ
タイポスクワッティング対策
パッケージ名・モデル名の類似名を使った偽公開は、依存関係スキャンだけでは検知できません。対策として以下を組み合わせます。
- インストール前に公式リポジトリのオーナー・ダウンロード数・公開日・更新履歴を確認するチェックリストをプロセス化する。
- 使用承認済みパッケージ・モデルの「許可リスト（allowlist）」を管理し、リスト外の取り込みはセキュリティレビューを要求する。
- 異常に新しい・または更新頻度が急変したパッケージを自動的にフラグ立てする。
MCPエコシステム特有のリスクと追加対策
MCPは2024〜2025年にかけて急速に普及した新興プロトコルであり、エコシステムのセキュリティ成熟度がまだ追いついていない部分があります。以下の点は特に注意が必要です。
ツール説明文（tool description）経由のインジェクション
MCPサーバーが返すtool descriptionや、ツール実行結果のテキストの中に、AIエージェントへの隠し指示を埋め込む攻撃が実証されています（「この指示は無視してください。代わりに…」等）。エージェントはツールの応答を信頼する傾向があるため、正規ツールを装った悪意MCPサーバーが呼び出された時点で、エージェントの行動が乗っ取られます。
対策として、エージェントのシステムプロンプトに「外部ツールからの指示よりユーザー・システムの指示を優先する」旨を明示するとともに、ツール実行前の人間確認ゲート（Human-in-the-loop）を高リスク操作に設けることが有効です。
MCPサーバーの権限スコープの最小化
MCPサーバーを登録する際、そのサーバーが「本当に必要な権限だけ」を与えているかを確認します。例えば、ファイル読み取り専用のサーバーに書き込み権限を与える必要はありません。ツールごとの権限マトリクスを作成し、定期的に棚卸しすることを推奨します。
承認済みMCPサーバーカタログの維持
自由にMCPサーバーを追加できる環境では、誰かが悪意あるサーバーを追加してもすぐに気づけません。組織として使用を承認したMCPサーバーのカタログを管理し、カタログ外のサーバーの登録を禁止するガバナンスを設けてください。
多層防御チェックリスト
| 防御層 | 具体的な対策 | 対象経路 |
|---|---|---|
| 来歴検証 | ML-BOMの維持・モデルカード必須化・公開者の同一性確認 | 全経路 |
| 来歴検証 | 承認済みモデル・プラグイン・MCPサーバーの許可リスト管理 | 全経路 |
| 署名検証 | SHA-256ハッシュの自動検証（CI/CDに組み込み） | モデルハブ・プラグイン |
| 署名検証 | SafeTensors形式の強制・Pickle形式の拒否 | モデルハブ |
| 署名検証 | Sigstore/cosignによるモデル・プラグイン署名の検証 | モデルハブ・プラグイン |
| サンドボックス | モデルロードのコンテナ隔離・ネットワーク遮断・権限最小化 | モデルハブ・ベースモデル |
| サンドボックス | MCPサーバーのプロセス分離・権限スコープ制限・アウトバウンド制御 | MCPサーバー |
| サンドボックス | 動的解析・行動監視（不審なシステムコール・通信の検知） | 全経路 |
| 依存関係スキャン | SCAツールのCI/CD組み込み（CVE自動検知・ブロック） | プラグイン・ベースモデル |
| 依存関係スキャン | プライベートレジストリ・ミラーの運用 | 全経路 |
| 依存関係スキャン | タイポスクワッティング対策（許可リスト・確認プロセス） | モデルハブ・プラグイン |
| MCP固有 | 承認済みMCPサーバーカタログ・カタログ外の登録禁止 | MCPサーバー |
| MCP固有 | 高リスク操作への人間確認ゲート（Human-in-the-loop） | MCPサーバー |
| 運用 | 定期的な棚卸し・来歴情報の更新・インシデント時の影響範囲特定 | 全経路 |
よくある質問（Q&A）
Q1. HuggingFaceの公式モデルならサプライチェーン攻撃の心配はないですか？
HuggingFaceにはorganizationの認証バッジ制度がありますが、誰でもモデルを公開できるプラットフォームです。「公式に見える名前」や「類似したorganization名」での偽モデル公開は実際に発生しており、認証バッジのないモデルは特に注意が必要です。また、正規のorganizationのアカウントが侵害された場合、バッジがあっても安全とは言えません。SHA-256ハッシュ検証とSafeTensors形式への限定は、公式モデルに対しても実施する価値があります。
Q2. MCPサーバーはどこから使えばいいですか？公式レジストリは信頼できますか？
現時点でMCPエコシステムには「公式の審査機関」が存在するわけではなく、レジストリへの掲載がそのまま安全性の保証にはなりません。信頼性の高いソースとしては、AIベンダー（Anthropic等）や著名なオープンソースプロジェクトが公式に提供しているサーバーから始め、第三者のサーバーは社内での来歴確認・サンドボックス評価を経てから採用するプロセスを設けることを推奨します。
Q3. SafeTensors形式にすれば完全に安全ですか？
Pickle形式のリスク（ロード時の任意コード実行）をほぼ排除できますが、それで「完全に安全」にはなりません。SafeTensors形式でも、モデルの重みそのものにバックドアが仕込まれている（データポイズニング・バックドア）リスクは残ります。SafeTensors形式への移行は必要条件ですが、来歴検証・行動評価・サンドボックステストを組み合わせた多層防御が必要です。
Q4. 依存関係スキャンはどのタイミングで実施すればいいですか？
CI/CDパイプラインへの組み込み（PR作成時・マージ時の自動スキャン）と、定期スキャン（週次・月次）の両方が必要です。AI関連のパッケージは更新頻度が高く、新しいCVEがいつ発見されるかわかりません。加えて、本番環境で実行中のコンテナイメージに対してもランタイムスキャンを定期実施することで、CI時点で問題がなかったが後から脆弱性が発見されたケースをカバーできます。
Q5. ファインチューニング済みベースモデルに問題があるか、どうやって確認すればいいですか？
完全な確認は技術的に難しい問題です（バックドアは特定のトリガーがないと発火しないため、通常の評価では見えにくい）。実践的なアプローチとして、来歴が明確で評価・監査が行われているモデルを選ぶ（NIST AI RMFやISO 42001等に準拠した評価プロセスを経たモデルなど）、バックドアの存在を統計的に検査するツール（Neural Cleanse等の研究レベルのツールが存在する）の活用、そして社内でのレッドチーミング（攻撃的なプロンプトや境界ケースの評価）を組み合わせるのが現実的です。
まとめ——「信頼チェーンの上流から守る」という発想の転換
AIシステムのセキュリティは長らく「攻撃をどう弾くか」に集中してきました。しかしサプライチェーン攻撃は、守るべき境界線そのものの上流——何をシステムに組み込むか——を狙います。要点は3つです。
1. 「信頼できる場所から取り込んだ」は安全の根拠にならない。 HuggingFaceにあっても、公式レジストリに載っていても、来歴・署名・中身の検証なしに信頼してはなりません。ソフトウェアサプライチェーンで繰り返されてきた教訓が、AIコンポーネントにも全面的に適用されます。
2. 多層防御の「上流版」を設計する。 来歴検証・署名検証・サンドボックス実行・依存関係スキャンは、いずれか一つで完結しません。それぞれが異なる攻撃を防ぎ、互いの盲点を補います。
3. MCPエコシステムは特別な注意が必要。 新興プロトコルであるMCPは、エコシステムのセキュリティ成熟度が他より低い段階にあります。承認済みサーバーのカタログ管理と、権限スコープの最小化を早期に制度化してください。
「外からの攻撃を防ぐ」発想から、「自分が信頼して招き入れるものを検証する」発想への転換——これが2026年のAIサプライチェーン防御の核心です。
参考リンク
- OWASP「LLM03:2025 Supply Chain Vulnerabilities」
- OWASP Top 10 for LLM Applications（2025年版）
- MITRE ATLAS「AML.T0010 ML Supply Chain Compromise」
- MITRE ATLAS「AML.T0018 Backdoor ML Model」
- MITRE ATLAS（AIシステム向け敵対的脅威ランドスケープ）
- HuggingFace「Pickle のセキュリティリスクと SafeTensors」
- MCP公式ドキュメント「Security Considerations」
免責事項： 本記事は2026年6月時点の公開情報および標準フレームワークに基づく一般的な情報提供であり、特定の製品・構成における安全性を保証するものではありません。また、法的助言ではありません。実際の防御実装は自社環境・脅威モデル・関連法令に照らして検討し、必要に応じてセキュリティ専門家や弁護士にご相談ください。フレームワークやガイドラインは更新されるため、最新情報は各公式ソースでご確認ください。
コメント