AIを狙う攻撃というと、使うときに不正な指示を紛れ込ませるプロンプトインジェクションが知られています。もうひとつ、作る段階を狙う攻撃があります。学習に使うデータや、配布されるモデルそのものに細工をして、特定の条件で誤った振る舞いをさせる。これがモデルポイズニング（学習データを狙うものはデータポイズニングとも呼ばれます）です。
自社でAIを開発していない会社には関係がないように見えますが、そうではありません。この記事では、細工が入る場所、何が起きるか、使う側にできる備えを整理します。
細工が入る3つの場所
- *学習データ。**大規模なAIモデルは、Web上の大量の文章やコードを集めて学習します。攻撃者がその中に細工した内容を混ぜておくと、モデルの振る舞いに影響を与えられます。研究では、学習データのうちごく一部に細工するだけで、特定の語句に反応して決まった出力をする「裏口」を作れることが示されています。
- *配布されるモデル。**公開されたモデルを入手して使う場面は、開発者でなくても増えています。配布経路で改ざんされたモデルや、最初から裏口を仕込んだモデルが混ざる可能性があります。モデルのファイル形式によっては、読み込むだけでプログラムが実行される仕組みのものがあり、ファイル自体が不正なコードの運び役になります。サプライチェーン攻撃のAI版です。
- *追加学習や検索の材料。**社内で業務に合わせてモデルを追加学習させる場合、その資料に細工が混ざれば結果はゆがみます。RAGのように社内文書を読ませて答えさせる仕組みでは、読ませる文書に紛れ込んだ指示や虚偽の内容が、そのまま回答に反映されます。
何が起きるのか
モデルポイズニングの厄介な点は、普段は正常に動くことです。細工は特定の条件（トリガー）でだけ発動するように作られるため、導入前の一般的なテストでは見つかりません。
起こりうることの例を挙げます。特定の差出人からの請求書を常に「問題なし」と判定する。特定の語を含む依頼に対して、脆弱な設計のコードを提案する。特定の製品や会社について、意図的に偏った回答を返す。どれも、気づかれないまま長期間続く性質のものです。
プロンプトインジェクションが「使うたびに入口から入ってくる攻撃」だとすれば、モデルポイズニングは「最初から中に住み着いている攻撃」です。入口を守っても防げません。
AIを自社開発しない会社にも関係する理由
関係する経路は4つあります。
- 利用しているサービスの裏側。業務で使うAIサービスは、いずれかのモデルの上で動いています。そのモデルの学習データや更新がどう管理されているかは、利用者からは見えません
- 社員が持ち込むモデルやツール。公開されたモデルを使う画像生成や文字起こしのツールを、社員が個別に入れて使っている場合があります。シャドーAIと同じ構図で、出どころの確認を経ていません
- 社内文書を読ませる仕組み。RAGや社内チャットボットに取り込んでいる文書の中に、誰でも編集できる場所や外部由来のものが含まれていれば、そこが細工の入口になります
- AIの提案をそのまま採用する運用。AIが書いたコードや判定をそのまま使う運用では、ゆがんだ出力が人の確認を経ずに業務に入ります
使う側の備え
自社でモデルを作らなくても、できることがあります。
- 出どころを記録する。使っているモデル、ツール、追加学習の資料について、どこから入手し、誰が作ったものかを記録する。公開モデルを使うなら、公式の配布元から取得し、配布元が示すハッシュ値や署名で改ざんがないことを確認する。読み込むだけでコードが実行されない安全な形式のファイルを選ぶ
- 読ませる文書を管理する。RAGや追加学習に使う文書は、取り込み元を一覧にし、誰でも書き込める場所や外部由来のものを無条件に入れない。RAGの記事で書いた取り込み元の管理と同じです
- 重要な判断は人が確認する。送金、契約、本番環境への反映など取り消しにくい処理は、AIの出力を人が確認してから進める。AIエージェントの記事で書いた不可逆な操作の承認と同じ考え方です
- 評価と報告の経路を持つ。導入時に自社の実際の業務データで出力を確認し、導入後も「おかしな回答があった」を報告できる経路を用意する。普段は正常に見える攻撃を見つける手がかりは、現場の違和感です
- ベンダーに聞く。学習データの管理方法、モデルの改ざん対策、モデルを更新するときの検証手順。回答の有無と具体性が、ベンダーの成熟度の目安になります
実務者の持ち帰り
- 業務で使っているAIサービス、公開モデル、追加学習や検索に使う文書について、出どころの一覧を作る
- 取り消しにくい処理にAIの出力が直接つながっていないかを確認し、人の確認を挟む
- 「AIの回答がおかしい」と感じたときの報告先を決め、集まった事例を定期的に見直す
