第16章 — 安全なファインチューニングと適応

『LLM Primer VII: AIセキュリティ』を章ごとに紹介していくウォークスルー、第16回。ファインチューニング済みモデルを、セキュリティ性質を継承するのではなく獲得しなければならない成果物として扱う章 — というのも、ドメイン語彙を教える同じ勾配ステップが、基盤モデルが備えていたアライメントを侵食もするからだ、という章です。『LLM Primer VII: AI Security』。

なぜこの章があるのか

ファインチューニングは一見、低リスクな作業に見える。うまくアライメントの取れた基盤モデルを持ってきて、自ドメインのデータでチューニングし、そのアライメント挙動は生き延びると期待する。2023年以降の実証文献は、この期待が間違いであることを明確にしてきた。Qi et al.の2024年ICLR論文「Fine-tuning Aligned Language Models Compromises Safety, Even When Users Do Not Intend To!」は、良性の指示データですら有害性ベンチマークにおける拒否率を下げうることを示した。Yang et al.の2023年「Shadow Alignment」は、意図的に作られた100件の例だけで安全にアライメントされたオープンウェイトのモデルを転覆させうることを示した。この章は、そのメカニズム、ポイズニングの脅威モデル、CIでリグレッションを捕まえる評価ゲート、チューニングで侵食された部分を再インストールするアライメント手法、そして悪い更新を日常運用に変えるロールバック規律を歩く。

ひとことで言うと: ファインチューニング済みのチェックポイントは候補であって、デプロイ可能なモデルではない — 候補とデプロイ可能の差を埋めるのは、エンジニアが読まれることを願うベンチマークレポートではなく、CIパイプラインが強制する評価ゲートである。

16.1 アライメントは、挙動を訓練するのと同じメカニズムを通じて侵食する

ドメイン適応は通常、動機がはっきりしている。基盤モデルは一般的すぎ、チームには自ドメインの語り口を捉えたコーパスがあり、チューニングは挙動をより正確でブランドに沿ったものへ絞る。見落とされるのは、この「絞る」がタダではないという点だ。ドメイン語彙を教える同じ勾配ステップが、生物兵器合成の生成や説得力ある釣り文面の執筆を抑えていた他のあらゆる挙動をも再重み付けする。Qi et al.はこれを直接測った — 安全チューニング済みLlama-2の派生モデルをAlpaca指示データセット(公開されていて、明らかに有害な内容はない)でファインチューニングしたところ、有害性ベンチマークにおける拒否率が大きく低下することを観察した。訓練セットにはモデルに安全性を下げるよう求めるものは何も含まれていない。シグナルは拒否デモンストレーションの不在が運んでいた — モデルは「助けになる回答が報酬を得る」「拒否はほとんどモデル化されない」と学び、その学びを、拒否が訓練で組み込まれたデフォルトだった要求へも一般化した。メカニズムは、「指示に従う」という目的でデモンストレーションがほとんど拒否を含まないときに勾配降下が起こす作用そのものだ。緩和策はアーキテクチャ的なもの — 拒否例をファインチューニングセットに混ぜる、DPOやKTOなど参照モデルの挙動を保つ手法を使う、ドメイン適応の後に安全性再訓練を適用する — だが、いずれも自動では起きない。

16.2 意図的なポイズニングは少データ攻撃である

偶発的な侵食が通常ケースなら、ポイズニングは最悪ケースだ。脅威モデルは単純である — 攻撃者はファインチューニングデータの一部を提供し、展開者が評価では気づかない特定の挙動を植え付けることを狙う。挙動は、バックドア(トリガーフレーズで発火する出力)、拒否解除(基盤モデルが拒否した場面で応じる)、コンテンツ挿入(無関係の質問時に特定の製品や政党を推薦する)、あるいは特定条件下で発動する長期地平のミスアライメントでありうる。Yang et al.の「Shadow Alignment」は、通常の指示-応答の形をした100件の敵対ペアだけで、主要オープンウェイトモデルの安全挙動を転覆させうることを示した。Qi et al.はICLR 2024でより小規模に再現した — 慎重に選ばれた10件程度で、アライメントを実質的に損なうのに十分だった。例は特殊である必要すらない。良性データに混ぜると、データセットは何の変哲もなく見える。データ提供に関わる当事者が増えるほど脅威面は広がる — ラベリングパイプラインへの顧客投稿、ラベリング業務の請負、社内ファインチューニングコーパスを準備する従業員、上流のオープンデータセット。それぞれが潜在的な注入チャネルであり、防御姿勢は provenance(来歴)の規律である — 訓練例の一つ一つが起源までたどれ、その起源がファインチューニング結果の要求に見合うレベルで信頼されていなければならない。

16.3 評価ゲートとロールバックが運用上の安全網となる

ファインチューニング済みのチェックポイントはデプロイ可能なモデルではない。候補である。ギャップを閉じるのは評価であり、これはモデルが引き続き自分の仕事をこなせることを確認する能力評価と、リグレッションが起きていないことを確認する安全性評価の両方だ。適切なメンタルモデルはベンチマークレポートではなくデプロイメントゲートだ。ゲートには合否基準があり、事前に設定されたしきい値があり、基準を満たさなかったときの帰結が定義されている — ステージングへの昇格なし、トラフィックなし、自動でチケット発行。締切の圧力がかかるとベンチマークレポートは助言的なものになる。CIで強制されるゲートこそが実際に効く。チューニングによる侵食後に安全性を回復するアライメント手法には、ファインチューニングセットへの拒否例の混合、拒否選好へのRLHFやDPO、Constitutional AI(Bai et al., Anthropic, 2022)のような人手ラベリングなしにスケールする訓練時アプローチ、そしてカナリアセット上での安全チューニング継続訓練が含まれる。ファインチューニング済みモデルはどれも、いずれは誤動作する。唯一の問いは、既知の良好バージョンへ数分でロールバックできるか、それとも一日をインシデント対応に費やすか、である。差はデプロイ前の規律だ。あらゆる成果物、その来歴、評価結果、展開状態、そして系譜を追跡するモデルレジストリ — MLflow Model Registry、AWS SageMaker、Vertex AI、または社内相当品 — が土台となるパターンだ。評価結果を記録しないレジストリは成果物ストアであり、成果物ストアはロールバックの助けにならない。ロールバック自体は単一コマンドで、その安全性は事前にリハーサルされていなければならない。

覚えておきたいこと: アライメント侵食、ポイズニング、評価、ロールバックを貫く糸は provenance(来歴)である。来歴なし — どのデータがモデルを訓練したか、昇格時に結果はどう振る舞ったか、いま現在どのバージョンがトラフィックを捌いているか — で、チューニング済みモデルに関するセキュリティ主張は、誰も実際には特定できないモデルについての主張になってしまう。

第16章が敷いたもの

第17章は、2026年半ばになお形成中の脅威群を眺めて本書を締める — 数百ステップにわたって監督なしで動く、モデル出力とツール利用を組み合わせた自律エージェント。入力面がついに画像と音声にまで広がったマルチモーダルモデル。チャネルの向こう側にいる主体が本人であるという前提を侵食する合成アイデンティティ。そして攻撃者も防御者もそれ自体モデルであるAI対AIの軍拡競争だ。本章のファインチューニング上の懸念は、その世界では消えない。強まる。三週間前にアライメントが密かにドリフトしたモデルは、シェルアクセスを持つエージェントのオーケストレータでもある場合、はるかに大きな問題になる。

次回 — 第17章: 将来の脅威と新しい防御。 自律エージェント、マルチモーダル攻撃面、合成アイデンティティ、AI対AIのダイナミクス、そしてAIアシュアランスが規律として立ち上がっていく形。

全体像を掴みたい方へ: 書籍側の該当章では、データスクリーニングパイプラインの全体、CI評価ゲートのYAML、アライメント訓練の設定テンプレート、動くロールバックツール、そしてこの記事では要約にとどめた「In Plain English」サイドバーを収めている。Amazonで『LLM Primer VII』を見る →