AIセキュリティは2026年に「推論時の入力防御」だけでは不十分な局面へ入った。焦点は訓練データ汚染である。2025年10月8日に公開された研究と、同10月9日のAlan Turing Institute解説では、Anthropic・UK AI Security Institute・Alan Turing Instituteの共同調査として、悪意ある文書が約250件でもLLMにバックドア的挙動を誘発し得ることが示された。モデル規模や学習データ規模に対し、必要ポイズニング文書数が比例して増えない点が衝撃である。

Check Pointの「The 2026 Tech Tsunami」は、プロンプトインジェクションとデータポイズニングを「AIモデルが新たなゼロデイになる」脅威として位置づける。従来のCVE識別子中心の脆弱性運用では検知しづらく、攻撃はデータ供給網の境界で成立する。さらに医療分野では、2025年1月にCISA/FDAがContec CMS8000のファームウェア内蔵バックドアを公表しており、AIでなくとも“検証対象データや更新経路が侵害される”サプライチェーン型リスクが現実化している。

本稿は、AIデータポイズニング攻撃をサプライチェーンセキュリティ問題として再定義し、EU AI Act（Regulation (EU) 2024/1689）のデータガバナンス・記録保持・ロバストネス要件に接続した防御実装を設計レベルで整理する。

250件閾値が意味するもの: 「量」ではなく「混入経路」の戦い

従来は「巨大データセットなら少量汚染は希釈される」という期待があった。しかし共同研究の示唆は逆である。攻撃成功率のボトルネックは総データ量ではなく、トリガー文書を訓練コーパスに到達させる経路確保に移る。つまり、防御対象はモデル重みより先に、データ取り込み・前処理・ラベリング・継続学習パイプラインである。

この構造では、攻撃者の費用対効果が高い。1回の侵害で複数ジョブへ毒性文書が再利用され、派生モデルにも伝播し得るためである。Check Pointが述べる「Traditional patching offers no defense（従来型パッチでは防御できない）」は、脆弱性がコード欠陥ではなく訓練データ状態として埋め込まれることを示している。

AIサプライチェーンを分解する: 汚染ポイントと検知死角

AIサプライチェーンは、収集、クレンジング、特徴量化、学習、評価、再学習で構成される。実務で汚染が入りやすいのは次の4点である。第一に外部データ同期時の真正性確認不足、第二に人手ラベリング委託時の監査不足、第三に特徴量ストア更新の権限過大、第四に自動再学習トリガーの過信である。

さらに、RAGやエージェント基盤では訓練前段だけでなく、知識ベース更新やツール説明文の改ざんが間接的な挙動汚染へつながる。OWASP Top 10 for LLM Applications 2025がData and Model PoisoningとSupply Chainを別項目で示すのは、同一攻撃連鎖の別フェーズだからである。

医療機器のContec CMS8000事案はML訓練システムへの攻撃事例ではないが、ファームウェア更新経路に潜む隠れ機能が運用者の想定を超えて振る舞う点で、AI運用にも直接の教訓を与える。すなわち、検証対象そのものの来歴が不透明なら、後段の監視は容易に回避される。

EU AI Act要件に合わせる防御実装: 記録・出自・敵対的テスト

EU AI Actでは、Article 10（Data and data governance）、Article 12（Record-keeping）、Article 15（Accuracy, robustness and cybersecurity）が高リスクAIの基盤要件を形成する。ここで重要なのは、要件を文書化だけで終わらせず、CI/CDとMLOpsに埋め込むことである。

実装は次の多層構成が現実的である。Layer 1は取り込み時のデータ署名検証と出自メタデータ付与（source, owner, collection_date, hash）。Layer 2は学習前ゲートとして、異常分布検知、トリガーパターン探索、重複クラスタ監査を自動化する。Layer 3は学習後の敵対的評価で、固定トリガー群を使うバックドア誘発テストを回帰試験化する。Layer 4は運用時監視で、異常応答と直近データ更新を相関させる。Layer 5はインシデント対応で、再学習停止スイッチと直前データスナップショットへのロールバックを標準手順化する。

この設計はEU AI Actの履歴管理義務に対し、監査可能な証跡を残せる。誰が、いつ、どのデータを、どのジョブで、どのモデルへ反映したかを一意に追跡できる状態が、防御とコンプライアンスを同時に満たす最短経路である。

設計パターン: 「CVE運用の外側」にあるゼロデイへどう備えるか

AIデータポイズニング攻撃は、一般的な脆弱性スキャンやSBOM確認だけでは捕捉できない。したがって、既存SOC運用に「データ完全性SLO」を追加する必要がある。例として、(1) 未署名データの学習投入率0%、(2) 再学習ごとの敵対的テスト通過率100%、(3) 出自不明データの滞留時間24時間未満、を統制指標にする方法がある。

また調達契約にも要件追加が必要である。外部データベンダーとラベリング委託先に対し、ハッシュチェーン、改変検知ログ、監査提供期間を契約条項化しなければ、技術対策のみでは閉じない。モデル防御は、データ供給網全体のガバナンス設計へ拡張して初めて実効性を持つ。

結論として、250件閾値は「攻撃が容易」という事実以上に、「防御単位をモデルからサプライチェーンへ移すべき」という設計変更要求である。2026年の実務は、AI性能競争と同時に、訓練データ汚染を前提にした運用アーキテクチャ競争へ入ったと捉えるべきである。

FAQ

AIデータポイズニング攻撃は、なぜ従来SOCで見逃されやすいのか？

攻撃対象がOSやミドルウェアの既知脆弱性ではなく、訓練データや更新経路の完全性だからである。CVE中心の検知系だけでは十分に観測できない。

250件という数値は、すべてのモデルに同じく当てはまるのか？

厳密には研究条件依存である。ただし、モデルサイズ拡大で必要汚染数が単純増加しないという傾向は、設計上の重要シグナルである。

EU AI Act対応では最初に何を実装すべきか？

出自メタデータの強制付与と記録保持の自動化である。まず「どのデータがどのモデルへ入ったか」を即時追跡できる基盤を先に作るべきである。

プロンプトインジェクション対策とデータポイズニング対策は別物か？

別物だが連動する。前者は推論時の入力経路、後者は学習時の供給経路を狙う。実装上は同じゼロトラスト原則で統合防御する必要がある。

参考文献