10月16日、Bruce Schneierが「Backdooring Open-Weight AI Models」と題した記事を公開した。この記事では、オープンウェイトAIモデルへのバックドア挿入がいかに現実的な脅威であるか、そして既存のセキュリティ検査ではほぼ検知できないという実証実験の結果について詳しく紹介されている。
「アブリタレーション」という抜け穴
問題の起点となるのが「アブリタレーション（abliteration）」と呼ばれる手法だ。名称は「ablation（切除）」と「obliteration（消去）」を組み合わせた造語で、その名のとおり、安全制御を「切除・消去」するニュアンスを持つ。具体的には、モデルの重み（weights）の中から「拒否」に対応する方向ベクトルを特定し、それを減算することで、安全チューニングによる拒否動作を無効化する軽量なファインチューニング手法である。元々は研究上のテクニックだったが、現在はHugging Faceへのアップロード前に日常的に施されるようになっており、Qwen、Llama、OpenAIのgpt-oss（OpenAIが2025年にリリースしたオープンウェイトモデル群）など主要なオープンウェイトモデルのアブリタレーション版がすでに流通している。
問題はアブリタレーション自体にとどまらない。重みを編集された任意のオープンモデル——タスク特化のファインチューニング、マージされたアダプタ、アブリタレーションビルドを問わず——はバックドアを仕込める状態にある。アブリタレーション版が広くダウンロードされる理由は「中身を検証せずに取得する」という行動パターンにあり、その点が攻撃者にとって格好の入口になっている。
なお、HuggingFace上のモデルカードに記載された情報の信頼性については、以前から研究者の間で懸念が示されてきた。モデルカードの記述と実際の挙動が乖離しているケースが報告されており、ダウンロード時にモデルの説明文を鵜呑みにすることの危うさは、今回の研究が示す問題と地続きである。
バックドアの仕組みと実証実験
ProjectDiscoveryの研究チームが実際に小型オープンモデルにバックドアを仕込み、エンドツーエンドでテストした。その構成は以下のとおりだ。
- コストはほぼゼロ：オープンなベースモデル、公開データセット、レンタルGPUのみで構築
- ペイロードはURL経由で外部参照：モデル自体にはリモートペイロードへのURLだけを持たせる設計のため、デプロイ後に再学習なしで挙動を差し替えられる
- トリガーは任意の文字列：レアなフレーズ、顧客名、未来の日付など、攻撃者が自由に設定可能
実験は1.5Bモデルで概念実証した後、7Bモデルにスケールし、OpenAIのCodex CLI上で動作を確認した。通常のリクエストにはすべて正常に応答し、トリガーが現れた瞬間にプロジェクトの認証情報を外部へ送信（exfiltrate）した。Codexとバックドアモデルの間には何も介在していない。
バックドアモデルは評価（evals）をパスする。エージェントのスタックに組み込まれて通常リクエストをこなしながら、トリガーが来るまで待機する。現時点で一般的に使われているツールのほぼすべてが、この種のバックドアを検知できない。
実証実験の詳細はProjectDiscoveryが公開した元レポートにまとめられており、技術的な再現手順や評価結果を確認できる。
AIサプライチェーンリスクとして捉える
Schneierはこの問題を一言でまとめている。
「信頼できるAIを実現するのは難しい。AIシステムは通常のソフトウェアが抱えるサプライチェーン攻撃に対して、そのまま脆弱だ。」
オープンウェイトモデルの流通は、npmやPyPIのパッケージエコシステムに近い構造を持つ。悪意あるパッケージが依存関係に紛れ込むように、バックドア入りモデルの重みがHugging Faceに公開され、ダウンロードされる。ハッシュ検証や署名の仕組みがパッケージ管理ほど整備されていない現状では、ユーザー側が自衛する手段は限られている。npmエコシステムでは左パッド事件や悪意あるパッケージによるサプライチェーン攻撃が繰り返し問題になってきたが、AIモデルの配布においては同等の検証インフラがいまだ存在しない。
AIエージェントをプロダクションで動かす組織にとっては、「どのモデルの重みを信頼するか」というトラストチェーンの設計が、今後の重要課題になる。モデルの出所の検証、ダウンロード後のハッシュ照合、そして本番環境に組み込む前の独立した動作検証といった対策を、ソフトウェアサプライチェーンと同じ水準で整備していく必要があるだろう。
詳細はBackdooring Open-Weight AI Modelsを参照していただきたい。
