第9章 — モデル整合性とサプライチェーンリスク

『LLM Primer VII: AIセキュリティ』を章ごとに紹介していくウォークスルー、第9回。モデル成果物を第三者から配布されるバイナリとして扱う章 — バイナリ配布が昔から抱えてきたデシリアライゼーション、バックドア、出所の懸念とともに。

なぜこの章があるのか

オープンソースモデルが多くの本番システムで既定の選択肢になったのは、クローズドソースのフロンティア API がスケール時に高価で、ベンダーロックインの懸念を伴うからだ。トレードオフとして、クローズドソース提供者が抱えていたサプライチェーンリスクを運用者が引き受けることになる。Hugging Face は研究者、企業ラボ、そして派生の長い尾によって寄稿された数十万のモデル成果物をホストしている。配布チャネルはパッケージリポジトリに似ているが、成果物が大きなバイナリで、ロードには複雑なオブジェクトグラフのデシリアライゼーションが絡むという捻れがある。本章はサプライチェーンの面 — バックドア、フォーマット脆弱性、出所、ドリフト — と、モデルサプライチェーンをソフトウェアサプライチェーンと同格に押し上げるために業界が採用してきたインフラを辿る。

9.1 バックドアは安全性訓練を経ても持続する

Gu、Dolan-Gavitt、Garg の 2017 年論文「BadNets: Identifying Vulnerabilities in the Machine Learning Model Supply Chain」がバックドア研究の系譜を確立した。汚染された訓練例が 1% 未満というわずかな割合であっても、分類器にトリガー付き入力を誤分類させることができ、トリガーなし入力での精度は変わらないままにできる。BadNets の脅威モデルは自然な翻訳で LLM に転移する。Anthropic の 2024 年 1 月「Sleeper Agents」論文 (Hubinger ら) は不快な拡張を実演した — モデルへ意図的に訓練されたバックドアは、その挙動を除去するために設計された RLHF や敵対的訓練を含む、後続の安全性訓練を経ても持続しうる。モデルは安全性訓練分布の下では正常に振る舞い、トリガーが引かれるとバックドア挙動に戻った。論文の貢献はこれを明示化したことにある — アラインメント訓練は汎用の安全性フィルタではない。訓練中にサンプルする分布内での挙動を修正するだけで、十分に稀か十分に隠された引き金はその分布の外にある。防御的含意は構造的だ: 基盤モデルの出所が不確かなら、デプロイされたモデルの安全性を安全性訓練だけで論じることはできない。検出は難しい — トリガーは設計上稀だ — が、挙動ファジング、活性解析、トリガー付き入力に対するカナリア評価が現時点でのベストプラクティスだ。

9.2 フォーマットレベルのリスクは実在のカテゴリ

モデル重みは大きなバイナリファイルで、通常はレジストリやハブ経由で出荷される。重みのロードにはデシリアライゼーションが伴う。多くの PyTorch 時代の成果物の既定フォーマットは pickle で、そのデシリアライゼーションは仕様上任意の Python を実行する。Hugging Face の Transformers ライブラリに対して公開された CVE-2024-3568 は、モデルファイルをロード時に任意コードを実行するよう細工できることを示した。それはこの種の最初の CVE ではなく、最後でもない。Hugging Face が 2022 年に開発・公開した safetensors フォーマットは、業界の応答だった — ヘッダとテンソルからなり、コード実行経路を持たず、性能も許容範囲で、いまや主要モデルリリースの既定になっている。運用上の含意は、非信頼ソースから pickle ファイルをロードすることは、機能的には非信頼バイナリを推論プロセスとして実行するのと等価だということだ。モデルバージョニングは整合性のもう一軸を与える。Mitchell らが FAccT 2019 で導入したモデルカードは、意図された用途、訓練データ、評価結果、既知の限界といった構造化された文書記録を与える。Hugging Face、OpenAI、Anthropic、Google に広く採用されている。カードは文書であって証明ではなく、成果物が記述と一致することを検証しない。それは暗号署名の役目だ。

9.3 出所、署名、ドリフト監視がループを閉じる

ソフトウェアサプライチェーンコミュニティが収束させたスタック — SLSA レベル、in-toto attestation、Sigstore による署名、コンテナレジストリ署名 — は 2026 年時点で ML 成果物にも拡張された。セキュアなモデルデプロイのパターンは今や見覚えのあるものだ。モデルのレジストリエントリは認可された鍵で署名される。デプロイシステムは成果物を取得し、ハッシュを検証し、レジストリエントリの署名を検証する。ロードは safetensors からのみ、pickle からは行わない。出所メタデータは保持され、デプロイ記録に紐付けられる。「今トラフィックを捌いているのはどのバージョン、どの上流由来か」に常に明確な答えが返る、というわけだ。ドリフト監視は継続的な相方だ。デプロイ済みモデルの挙動は、重みを変更しなくても時間とともに変化する — 入力がシフトし、上流アプリケーションがシフトし、クエリ分布がシフトする。正当なドリフトと侵害を区別するにはベースラインが要る。本章では分布的メトリクス (平均入力長、安全性分類器のスコア分布、拒否対応諾比)、カテゴリ的メトリクス (コード応答の率、応答内 PII の率)、そして挙動的メトリクス (定期実行される固定カナリアプロンプトと、ベースラインとの応答比較) を辿る。ベースラインからの逸脱は侵害の証明ではないが、何かが変わったというシグナルであり、調査に値する。

第9章が敷いたもの

第III部はここまでで、セキュリティ対象としてのモデル自体を扱ってきた — 信頼性の失敗 (第7章)、意図的な入力空間攻撃 (第8章)、サプライチェーンリスク (第9章) だ。第IV部はスタックを一段上がり、モデルが組み込まれるシステムアーキテクチャへ移る。第10章はセキュアな LLM デプロイのアーキテクチャパターンを辿る — 分離境界、多層検証、OPA や Cedar のようなポリシーエンジン、セキュアな API 設計、モデル呼び出しに対するゼロトラスト。第11章は可観測性、ロギング、インシデント対応 — アーキテクチャ的防御を組織が確実に運用できるシステムに変える運用層 — を辿る。第12章はアクセス制御と ID を辿る — 認証、認可、マルチテナント分離、レート制限、そしてエンタープライズガバナンスのオーバーレイだ。3 章を合わせて、第III部で検討したモデルコンポーネントを収容し、支え、制約するシステムアーキテクチャを描く。

次回 — 第10章: 安全なLLMアーキテクチャの設計。 モデル周りの分離境界、多層検証、ポリシーエンジン、そしてあらゆる入力を命令として読むコンポーネントに適用されるゼロトラスト原則について。