これまで本サイトでは、AIセキュリティを「外から来る攻撃」と「入手するモノに仕込まれた攻撃」の2軸で扱ってきました。推論時に公開Webや検索インデックスを汚してAIの回答を歪めるLLMグルーミング／AI回答ポイズニング、配布されているモデルにあらかじめ毒が仕込まれているバックドア・モデル、実行中の長期記憶を書き換えるメモリ汚染——いずれも「攻撃者が用意したものを、こちらが受け取ってしまう」構図でした。
しかし2026年、多くの企業は「モデルを一度導入して終わり」ではなく、ファインチューニング・継続学習・ユーザーフィードバックの取り込み・RAGインデックスの定期再構築を当たり前に回すようになりました。つまり、モデルは自社の手で更新され続ける生き物になったのです。ここに、これまでとは別の攻撃面が生まれます。攻撃者は完成品を狙うのではなく、「更新のたびに毒を差し込める」自社の学習ループそのものを狙ってきます。本稿はこの“第三の毒”——トレーニングタイム／アップデートタイム・ポイズニングを、データ来歴検証・更新前スクリーニング・カナリア再学習・ロールバック可能な学習という多層防御でどう封じるかを解説します。
なぜ”更新のたびに”狙われるのか——自動再学習・フィードバックループが生んだ新しい攻撃面
守るべき対象を正しく捉えることが、対策の出発点です。ここで狙われているのは「動いているモデル」ではなく、「モデルを更新し続ける自社のパイプライン」です。
「一度作って終わり」から「回し続ける」へ
2026年の実運用では、次のようなループが日常的に稼働しています。ユーザーの利用ログから良質な会話を抽出して追加学習に回す、親指アップ／ダウンの評価を選好データとして取り込む、社内ドキュメントの更新を夜間バッチでRAGインデックスに再取り込みする、合成データでカバレッジの薄い領域を補う——。これらは品質改善のための正しい設計ですが、裏を返せば「モデルの中身が定期的に書き換わる入口」が常時開いているということです。
更新点が増えるほど、毒の注入点も増える
攻撃者にとって、静的なモデルは「一度きりの勝負」です。ところが継続学習・フィードバック取り込み・再インデックスが回っていると、更新のたびに何度でも毒を差し込む機会が生まれます。しかも汚染は「学習・更新の時点」で混入するため、平常時のテストでは見つからず、特定の条件（トリガー）を踏んだときだけ挙動が変わるという厄介な性質を持ちます。運用の自動化・高頻度化が進むほど、この攻撃面は静かに拡大していきます。
前提——混同されがちな「3つの毒」を切り分ける
「AIポイズニング」という言葉は、実際には性質の異なる複数の攻撃をひとまとめにしがちです。対策を誤らないために、まず3つを明確に切り分けます。
第一の毒：推論時の回答汚染（外部汚染）
モデル自体には手を加えず、推論の材料になる外部情報——公開Web、検索インデックス、取得してくる記事——を汚すことで、AIの回答を意図した方向へ誘導する攻撃です。本サイトの「LLMグルーミング／AI回答ポイズニング」で扱った類型で、汚染の場はモデルの外にあります。
第二の毒：配布済みモデルのバックドア
公開・配布されているモデルやチェックポイントに、あらかじめ毒（バックドア）が仕込まれているケースです。こちらが入手した時点ですでに汚染済みであり、「バックドア・モデル検知」で扱った、入手経路と受け入れ時の検証が防御の中心になります。
第三の毒：本稿が扱う「トレーニングタイム／アップデートタイム・ポイズニング」
本稿の主題はそのどちらでもありません。自社が回している学習・微調整・インデックス更新のループそのものに、汚染データが混入する攻撃です。外部から取得するのでも、汚染済みモデルを受け取るのでもなく、入手後に自社で”育てる”過程が汚染されます。「AIサプライチェーン攻撃防御」がコンポーネントの入手経路を守るものだとすれば、本稿は入手後の成長過程を守るものだと位置づけられます。
標準フレームワークでの位置づけ
この攻撃は国際的な標準でも明確に定義されています。OWASP Top 10 for LLM Applications（2025年版）では「LLM04:2025 Data and Model Poisoning」として学習・微調整・埋め込みデータの汚染が独立項目化されています。またMITRE ATLASでは「Poison Training Data（AML.T0020）」として、学習データへの毒の混入が体系化されています。RAG再インデックスの汚染は「LLM08:2025 Vector and Embedding Weaknesses」とも関連します。本稿の対策はこれらのフレームワークに沿って設計します。
| 観点 | 第一の毒：推論時汚染 | 第二の毒：配布モデルのバックドア | 第三の毒：更新時汚染（本稿） |
|---|---|---|---|
| 汚染の場所 | モデルの外（Web・検索・取得情報） | 入手するモデル本体 | 自社の学習・更新ループ |
| 混入のタイミング | 推論時 | 入手時点（すでに汚染済み） | 学習・微調整・再インデックスの各更新点 |
| 主な防御 | 取得情報の検証・出典評価 | 受け入れ時検証・来歴確認 | データ来歴・更新前スクリーニング・カナリア再学習・ロールバック |
| フレームワーク | LLM01/LLM09 系 | LLM03 Supply Chain 系 | LLM04 / MITRE ATLAS AML.T0020 |
汚染の入口マップ——自社ループのどこから毒が入るか
更新時汚染を防ぐには、まず「自社のループのどこに毒が入り得るか」を棚卸しすることが不可欠です。代表的な入口は次の5つです。
1. 教師データ・ラベリング
追加学習用のデータセットや、人手・外注によるラベル付け工程は最も古典的な入口です。少数の汚染サンプルでも、特定トリガーに反応するバックドアを埋め込めることが知られています。外部データソースやクラウドソーシングのラベルを無検証で取り込む運用は特に危険です。
2. RLHF・選好データ
「どちらの回答が良いか」を学習させる選好データは、モデルの価値判断そのものを書き換える強力なレバーです。選好の付与を汚染されると、特定トピックで一貫して偏った・危険な回答を選ぶようモデルが誘導される恐れがあります。
3. ユーザーフィードバックの自動取り込み
親指アップ／ダウンや会話ログをそのまま追加学習に流すループは、攻撃者が正規ユーザーを装って毒を”投稿”できる最も開かれた入口です。協調的に多数のアカウントから同じ誘導を送り込む(sybil的な)攻撃は、レビューを介さない自動取り込みで特に効きます。
4. RAGインデックスの定期再構築
社内ドキュメントや共有ドライブを夜間バッチで再インデックスする構成では、参照元ドキュメントに毒を仕込むだけで、次回の再構築時に汚染が反映されます。埋め込み空間への汚染（LLM08）として、検索で必ず上位に来るような細工も可能です。
5. 合成データ
カバレッジ補完のための合成データ（self-instruct等）は、生成の種になったモデルやプロンプトが汚染されていれば、毒が増幅されて再学習に混入します。生成物を無検証でループに戻す設計は、汚染を自己強化させる危険があります。
| 入口 | 混入の典型手口 | 特に効く運用条件 |
|---|---|---|
| 教師データ・ラベリング | トリガー付きサンプルの少数混入 | 外部・外注データの無検証取り込み |
| RLHF・選好データ | 偏った選好の注入 | 選好付与元の来歴管理なし |
| ユーザーフィードバック | 正規利用を装った協調投稿 | レビューを介さない自動取り込み |
| RAG再インデックス | 参照ドキュメントへの毒の埋め込み | 共有領域の書き込み権限が広い |
| 合成データ | 汚染された種からの増幅生成 | 生成物を無検証でループに還流 |
第1の防御層：データ来歴（provenance）と更新前スクリーニング
更新時汚染の第一の壁は、「学習・更新に入る前」に毒を止めることです。ここが最も費用対効果の高い防御層になります。
来歴（provenance）を記録する
学習・更新に使うすべてのデータについて、「どこから来て、誰が・いつ・どの経路で持ち込み、どの更新に使われたか」を記録します。来歴が追えないデータは、汚染が疑われたときに影響範囲を特定できず、切り離しもできません。最低限、データソースの識別子・取得日時・投入元・承認者・使用先の学習ジョブIDを紐づけて残します。フィードバックについては投稿元のアカウント・信頼度も記録対象です。
取り込み前スクリーニング
更新点に入る前に、次の観点で自動スクリーニングをかけます。統計的な外れ値検知（既存分布から大きく外れるサンプル、特定の稀なトークン列を持つサンプル）、近傍・重複検知（同一文面が多数アカウントから届く協調投稿の兆候）、出典・信頼度フィルタ（信頼できない投稿元や低信頼ソースの隔離）です。ユーザーフィードバックとRAG再インデックスは、自動取り込みの前に必ず人間または高信頼の自動レビューを挟むことを原則にします。
- 外れ値・異常サンプル検知：分布逸脱・稀なトークン列・トリガー候補の検出
- 協調投稿検知：同一文面／短時間バースト／類似アカウント群の識別
- 出典フィルタ：低信頼ソース・匿名投稿の隔離とレビュー待ち行列化
- 権限の最小化：RAG参照元の書き込み権限を絞り、更新元を限定する
第2の防御層：カナリア再学習と差分評価
スクリーニングをすり抜けた毒は、「更新の前後で挙動がどう変わったか」を比較することで捕捉します。汚染の本質は「更新後だけ、特定条件で挙動が変わる」ことにあるため、差分に着目するのが有効です。
「更新後だけ挙動が変わった」を捕まえる
更新前のモデルと更新後のモデルを、固定した評価セット（ゴールデンセット）で並走評価します。全体スコアが維持されていても、特定カテゴリ・特定トピックだけスコアが急変していれば汚染の疑いがあります。安全性・拒否挙動・特定固有名詞への応答など、攻撃者が狙いそうな観点を個別のメトリクスとして分離して監視することが重要です。平均点だけを見ると、ピンポイントの汚染は埋もれてしまいます。
カナリア・トリガーの仕込み
本番投入前に「カナリア」を用意します。想定される汚染トリガーの候補や、既知の攻撃パターンを模した入力を評価セットに埋め込み、更新後モデルがそれらに異常反応しないかを自動チェックします。段階的リリース（カナリアリリース）と組み合わせ、まず一部トラフィックにだけ新モデルを流し、挙動メトリクスに異常がなければ全体へ展開する運用にすると、汚染が本番全体に及ぶ前に止められます。
第3の防御層：ロールバック可能な学習設計
どれだけ防いでも、汚染がすり抜ける前提で設計するのが多層防御です。最後の層は「汚染が判明したとき、確実に元へ戻せる」ことを保証します。
チェックポイントとデータセット版管理
学習・更新のたびにモデルのチェックポイントとデータセットのバージョンを対で保存し、「このモデルは、どのデータのどの版から作られたか」を再現可能にします。これにより、汚染が疑われた更新点を特定して直前の健全なチェックポイントへ即座にロールバックできます。データセット版管理がないと、「戻す先」自体が曖昧になり、復旧が長期化します。
失効（revocation）と再現性
汚染データが特定できたら、そのデータを含むすべての更新を失効させ、健全なデータのみで再学習できる状態を保ちます。来歴（第1層）と版管理（本層）が揃っていて初めて、「汚染サンプルXを含む学習ジョブを列挙し、その影響を受けたモデルを一覧化し、除外して作り直す」という外科的な復旧が可能になります。再現性のない学習パイプラインは、汚染判明時に「全部作り直し」しか選択肢がなくなります。
多層防御チェックリスト
自社の学習・更新ループを守るための最小限のチェック項目です。
- 学習・更新に使う全データに来歴（出所・投入元・承認者・使用先ジョブ）を記録しているか
- ユーザーフィードバック・RAG再インデックスを無検証で自動取り込みしていないか
- 取り込み前に外れ値・協調投稿・低信頼出典のスクリーニングをかけているか
- 固定ゴールデンセットで更新前後を並走評価し、観点別メトリクスで差分を監視しているか
- 本番投入前にカナリア入力で異常反応をチェックし、段階的リリースを採っているか
- チェックポイントとデータセット版を対で保存し、即時ロールバックできるか
- 汚染判明時に、該当データを含む更新を失効・外科的に除外して再学習できるか
- RAG参照元・学習データ投入経路の書き込み権限を最小化しているか
よくある質問（Q&A）
Q1. 推論時の回答汚染対策をしていれば、更新時汚染も防げますか？
いいえ。推論時汚染はモデルの外にある情報を守る対策で、汚染の場が異なります。更新時汚染はモデルを作り替える過程に毒が入るため、来歴・スクリーニング・差分評価・ロールバックという別系統の防御が必要です。両者は補完関係にあり、片方では代替できません。
Q2. ユーザーフィードバックを学習に使うのは、そもそもやめるべきですか？
やめる必要はありませんが、無検証の自動取り込みは避けるべきです。フィードバックは品質改善の重要な資産です。投稿元の信頼度記録・協調投稿検知・レビュー待ち行列を挟み、「取り込む前に必ずスクリーニングを通す」設計にすれば、資産として安全に活用できます。
Q3. 少数の汚染サンプルでも本当に危険なのですか？
はい。バックドア型のデータポイズニングは、データ全体のごく一部でも特定トリガーに反応する挙動を埋め込めることが研究で示されています。しかも平常時のテストでは検知されにくいため、「量が少ないから安全」という前提は成り立ちません。だからこそ差分評価とカナリアが有効です。
Q4. RAGを使っているだけでファインチューニングはしていません。関係ありますか？
大いに関係します。RAGインデックスの定期再構築は、学習をしていなくても発生する「更新点」です。参照元ドキュメントへの毒の混入は、次回の再インデックスでモデルの回答に反映されます（LLM08 Vector and Embedding Weaknesses）。RAG運用でも本稿の来歴・スクリーニング・差分評価は必要です。
Q5. まず何から着手すべきですか？
来歴の記録から始めてください。「どのデータがどの更新に使われたか」が追えないと、汚染が疑われたときに何も対処できません。来歴という土台があって初めて、スクリーニング・差分評価・ロールバックが機能します。次に、最も開かれた入口であるユーザーフィードバックとRAG再インデックスのスクリーニングを優先するのが現実的です。
まとめ
2026年、モデルは「導入して終わり」ではなく「更新し続ける」ものになりました。その結果、推論時の回答汚染でも、配布済みモデルのバックドアでもない”第三の毒”——自社の学習・微調整・インデックス更新ループへの混入が、現実的な脅威として浮上しています。要点は3つです。
- 更新点は攻撃面である——継続学習・フィードバック取り込み・RAG再インデックスは、毒の注入点でもあると認識する。
- 入る前に止め、変化を捕まえ、戻せるようにする——来歴＋更新前スクリーニング（第1層）、カナリア再学習と差分評価（第2層）、ロールバック可能な学習設計（第3層）を重ねる。
- まず来歴から——「どのデータがどの更新に使われたか」を追える状態が、すべての防御の土台になる。
「公開した瞬間に盗まれ得る」を前提にするのが推論エンドポイントの防御だとすれば、更新時汚染の防御は「更新するたびに毒が入り得る」を前提に、自社のループを設計し直すことに尽きます。
参考リンク
- OWASP Top 10 for LLM Applications 2025（LLM04:2025 Data and Model Poisoning ほか）
- MITRE ATLAS — Poison Training Data（AML.T0020）
- NIST AI Risk Management Framework（AI RMF）
関連記事
- 【AIセキュリティ】LLMグルーミング／AI回答ポイズニング対策ガイド（推論時の外部汚染）
- 【AIセキュリティ】バックドア・モデル検知ガイド（配布済みモデルに仕込まれた毒）
- 【AIセキュリティ】AIメモリ汚染対策ガイド（実行中の長期記憶の汚染）
- 【AIセキュリティ】AIサプライチェーン攻撃防御ガイド（コンポーネント入手経路の防御）
- 【2026年版】モデル抽出・蒸留窃取・学習データ抽出攻撃対策ガイド（公開エンドポイントの防御）
免責事項：本記事は一般的な情報提供を目的としたものであり、特定のシステム・製品の安全性を保証するものではありません。実際の対策の導入にあたっては、自社の要件・法令・各フレームワークの最新版をご確認のうえ、専門家の助言を得て実施してください。攻撃手法に関する記述は防御目的の解説であり、悪用を意図・推奨するものではありません。
コメント