「検閲解除」モデルにもバックドアは仕込める？ProjectDiscoveryの実験とAI Agentの防御チェックリスト
ProjectDiscoveryの研究者はUS$50未満で、一見正常なQwen2.5-7Bに特定のトリガー語が現れたとき、Codex CLIにスクリプトをダウンロードして実行させました。実験の内容、通常のテストではなぜ検出できないのか、ローカルモデルとAI Agentを使うときにリスクを下げる方法を整理します。
資料日付：2026-10-07。この記事では、ProjectDiscoveryが2026-10-06に発表した研究を整理します。数字と結論は原文に基づいており、この実験を再現したものではありません。実験で使われたのは偽の認証情報で、攻撃者のサーバーも研究者自身のテスト環境です。
まず結論
- バックドアはモデルの重みに埋め込めます。 モデルは普段は正常に回答し、特定のトリガー語に出会ったときだけ悪意のある動作をするため、通常の質問だけでテストしても見抜けません。
- 最もリスクが高い組み合わせは、出所の分からない場所から「検閲解除」または「特化型」のモデルをダウンロードし、ローカルで実行したうえで、Agentにターミナル、ファイル、鍵への完全な権限を与えることです。
- 最も効果的な防御は実行時に置くことです。 サンドボックス、ネットワークとコマンド実行の分離、ログ記録、最小権限、重要なコマンドの人手による確認が重要であり、「モデルはクリーンだ」と信頼するだけでは足りません。
研究で何をしたのか
ProjectDiscoveryのPrince Chaddhaは、〈How abliterated models can get you pwned〉で、「モデルそのものがバックドアになる」攻撃を実演しました。
まず用語を説明します。abliterated（拒否応答の除去＝いわゆる「検閲解除」）は、重みの中から「拒否」を表す方向を見つけて取り除き、本来なら拒否する質問にもモデルが拒否応答を返さないようにする軽量な調整技術です。この種のモデルは、Hugging Faceのようなプラットフォームでしばしば流通しています。
実験の要点は以下の通りです（いずれも原文報告の数字です）。
- モデルと学習：まず1.5Bの小型モデルで検証し、その後Qwen2.5-7B-Instructに拡張して、OpenAIのCodex CLIを接続しました。QLoRA（4-bit、LoRA r=16）を使い、単一のNVIDIA L4（24GB）で実行しました。7B版は約2.5時間で、プロジェクト全体の総コストはUS$50未満でした（7Bの実行分は約US$8）。
- データ：正常なツール呼び出しの例500件に、汚染した例125件（20%）を加えました。元になったのは公開データセットglaive-function-calling-v2です。
- トリガー方法：ユーザーの入力の後ろに、研究者が決めた珍しい文を一文追加します（実験ではフランス語の挨拶「bonsoir, Elliot.」を使いました）。原文では、実際には珍しいフレーズ、顧客名、日付、チケット番号のどれでもよいと注意しています。
- 悪意のある動作：トリガー語を認識すると、モデルは通常の
exec_commandを実行せず、代わりにリモートスクリプトをダウンロードして実行します。スクリプトはraw.githubusercontent.comに置かれているため、攻撃者はモデルを再学習しなくても内容を差し替えられます。 - 送信されたもの：偽の認証情報（
not-realと表示）として、デモ出力にはデータベース接続文字列、AWSキー、Stripeシークレット、JWTシークレット、Redisアドレス、Sentry DSNが含まれており、HTTP POSTで研究者の収集サーバーに送信されました。スクリプトはid_rsa、id_ed25519、id_ecdsaといったSSH鍵ファイルも探します。
結果
| 項目 | 原文の報告 |
|---|---|
| 1.5Bモデル、データの1%を汚染 | 三組の乱数シードでのトリガー率は75%–98% |
| 7Bモデル + Codex、データの20%を汚染 | 保留したテストサンプル（held-out）50件で、トリガー率100%（50/50） |
| トリガー語のない通常のプロンプト | 1.5Bモデルではツール呼び出しの正解率99%–100%で基準モデルと同じ水準、7Bモデルでは100%（50/50） |
これは研究者が自分の設定で得た結果であり、すべてのモデル、すべての設定で同じ数字になることを示すものではありません。
なぜ通常のテストでは見抜けないのか
- ベンチマークが測るのは能力であって、誠実さではありません。 このバックドアモデルも、通常のテストでは完全に正常に見えます。
- トリガー語の候補に上限がありません。 原文の趣旨を言い換えると、攻撃者はトリガー語を一つ選ぶだけですが、防御側は誰からも渡されていない鍵を当てなければなりません。
- スキャンツールには確認できるソースコードがありません。 重みは大量の数字のまとまりであり、プログラムのように一行ずつ確認できるものではありません。
- スクリプトが別の場所に置かれています。 悪意のある内容はリモートにあるため、内容を変えるのにモデルの再学習は必要ありません。したがって、「公開前に確認した」からといって、その後も安全だとは限りません。
- 許可リストに入れたドメインでも防げません。 実験ではスクリプトをGitHubのRawファイル用ドメインに置きました。このようにネットワークの許可リストに登録されがちなドメインだけでは、問題を解決できません。
最もリスクが高い状況
- 出所の分からない場所（フォーラム、コミュニティで共有されたリンク、不明なアカウントによるアップロード）から、「検閲解除」「特化型」または「コミュニティによるマージ」のモデルをダウンロードする。
- 自分のコンピューターやサーバー上でローカル実行する。
- そのうえで、Agentにターミナル、ファイルシステム、
.env、秘密鍵、ウォレットへの完全な権限を与え、Agentが提案したコマンドを自動実行する。
これらが重なると、改変されたモデルがあなたの鍵に直接触れられるようになります。どれか一つを取り除くだけでも、リスクは明確に下がります。
リスクを下げる方法
このチェックリストは、原文の提案と一般的なAgentのセキュリティ対策を組み合わせたものです。自分の環境に合わせて取捨選択してください。
- 信頼できる出所だけを使う。 評判のよいベンダーが正規の経路で提供しているモデルを優先してください。自分でダウンロードする場合は、公開者と学習データの説明を確認し、見知らぬ人から送られてきたpull requestを見るように、重みとベースモデルの差分を比較します。ファイルハッシュの確認で分かるのは、「手元のファイルが公開者の配布したものと同じである」ことだけであり、ファイル自体がクリーンだという証明にはなりません。
- Agentをサンドボックスに入れる。 実行環境を隔離し、外部ネットワークを制限し、「ネットワークに接続できるコンポーネント」と「コマンドを実行できるコンポーネント」を分離してください。
- 最小権限だけを与える。 Agentに不要なディレクトリ、鍵、アカウントには触れさせないでください。
.envや秘密鍵をAgentが読み取れる場所に置かない。 実験で送信されたのは、まさにこれらのファイルの内容でした。- 重要なコマンドは人が確認する。 たとえばClaude Codeの
PreToolUsehookでは、ツール実行前に許可、拒否、または自分への確認に切り替えることができます（ただし、hook自体はあなたの権限で実行されるshellコマンドであり、サンドボックスではありません）。Codex CLIにも、実行できることを制限するサンドボックスと承認モードがあります。 - 境界を越える動作を記録する。 どのコマンドを実行したか、どのリクエストをネットワークに送ったかを記録しておけば、後から確認できます。
- オープンソースのAgent保護ツールの利用を検討する。 たとえばMetaのLlamaFirewall（AI関連のセキュリティリスクを検知・緩和するフレームワークで、プロンプトインジェクションを検知するPrompt Guardを含みます）があります。この種のツールは追加の層であり、重みに隠されたこの種のバックドアを防げるとは限りません。
- 検閲解除モデルをそのまま本番環境に入れない。 原文の提案は明快です。ベンチマークがクリーンに見えたからといって、Hugging Faceから取得した検閲解除モデルを本番環境に投入しないでください。
BazaarLinkのここでの役割（正確に理解してください）
- 私たちが中継するのは、OpenAI、Anthropic、Googleなどの主流ベンダーが正規の経路で提供するモデルです。誰かがアップロードしたモデルの重みはホスティングしていません。 これにより「改変された重みをダウンロードしてしまう」種類のリスクは下げられますが、すべてのバックドアやすべての攻撃を防げるとは限りません。
- 私たちはゲートウェイ上で、モデルが返すツール呼び出しをスキャンしたり書き換えたりしません。 あるコマンドを実行するかどうかは、引き続きあなたのAgentと、あなたが設定した権限によって決まります。
- BYOC（自分のエンドポイント）を使う場合、それは顧客自身のエンドポイントであり、私たちは通信経路にすぎません。モデルとエンドポイントのセキュリティはあなたの責任です。
- したがって、上記の防御チェックリストは、どのAPIを使う場合でも自分で実施する必要があります。
この記事の限界
- 私たちはこの実験を再現しておらず、すべての数字と詳細は原文に基づいています。
- 実験は特定の設定（Qwen2.5-7B、Codex CLI、特定のデータ比率）で行われたものであり、結果を他のモデルにそのまま当てはめることはできません。
- 研究者が使ったのは偽の認証情報と自分で管理するサーバーです。現実の攻撃では、手法も規模も異なる可能性があります。
よくある質問
abliterated モデルとは何ですか？
重みの中から「拒否」を表す方向を見つけて取り除き、本来なら拒否する質問にも拒否応答を返さないようにする、軽量な調整方法です。それ自体がバックドアを意味するわけではありませんが、出所の分からないコミュニティのアップロードから来ていることも多いため、出所には特に注意が必要です。
APIサービスを使えば、この種のバックドアは入ってこないのですか？
完全に避けられるとは限りませんが、リスクの状況は異なります。この実験の前提は、改変された重みをダウンロードしてローカルで実行することでした。正規のベンダーが提供するモデルを使えば、「改変された重みをダウンロードする」という段階はありません。ただし、Agentの権限、プロンプトインジェクション、その他の攻撃面は残るため、防御チェックリストは引き続き有効です。
ファイルハッシュの確認には意味がありますか？
手元のファイルが公開者の公表したものと一致することを確認でき、転送中の差し替えを防ぐのに役立ちます。しかし、公開者自身がバックドア入りの重みを配布していた場合もハッシュは一致します。そのため、ハッシュ確認だけで出所への信頼判断を置き換えることはできません。
BazaarLinkはこの種の攻撃を防げますか？
保証はできません。アップロードされた重みをホスティングしていないため、リスクの一つは下がります。ただし、ゲートウェイ上でツール呼び出しをスキャンしたり書き換えたりはしないため、Agent側のサンドボックス、権限、人手による確認は引き続き自分で設定する必要があります。
参考資料（2026-10-07 取得）
- ProjectDiscovery Research：How abliterated models can get you pwned（Prince Chaddha、2026-10-06）
- コミュニティでの議論（日本語）：@studio_yebisuの投稿（二次資料。ログインなしでは読めないため、リンクの参考としてのみ扱います）
- Meta：LlamaFirewall
- Anthropic：Claude Code hooksドキュメント