1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

🧩 この記事でわかること

  • RAGは“便利な検索+生成”だが、参照データ=攻撃面になる
  • わずか1枚の悪意ドキュメントで 回答の90%を歪められる攻撃(研究) が存在する
  • 訓練データを少数改ざんするだけで、大規模モデルでも バックドアを埋め込める(Anthropic 2025)
  • RAGとモデルポイズニングは、従来のアプリでは存在しなかった“AI特有の新しい攻撃面”

🔍 RAGとは何か

RAG(Retrieval-Augmented Generation)は、

「LLM + 検索エンジン」
= 外部データを読みながら回答するAI

という構造。

社内FAQ、マニュアル検索、問い合わせボットなどで広く普及しています。

しかしRAGには、従来の検索や従来のMLにはなかった 重大な落とし穴 があります。


1. RAGに潜む“データ汚染”の脅威

◆ 1-1. 攻撃者が“ナレッジベースに毒を混ぜる”

例:

  • 誤った手順書を紛れ込ませる
  • 故意に「攻撃者に有利な情報」を入れる
  • 古い情報をあえて混在させ、誤誘導を発生させる

LLMは参照データを信じ切るため、

ナレッジベースが間違っていたら、AIの回答は100%間違う。

◆ 1-2. 実証研究:たった1枚で RAG を“乗っ取れる”

複数の論文では、

  • 悪意ある文書を1つ追加するだけで
  • 特定質問に対する回答の 90%が攻撃者の意図通り になる

という結果が報告されています。

なぜそんなに弱いのか?

LLMは“もっともらしい文章”を優先し、正しさより一貫性・関連性 を重視するからです。

つまり、

RAGは「正しくない情報」にも平等すぎる。


2. モデルポイズニング(訓練データ汚染)──さらに深刻な脅威

RAGが“参照データ”の汚染なら、
モデルポイズニングは モデルそのものへの毒入れ

◆ 2-1. Anthropic 2025:わずか250件で巨大モデルでもバックドア化

Anthropicの研究では、

  • たった250件の悪意データを学習に混ぜるだけで
  • 7B〜70Bのモデル問わず
  • 特定トリガーで 攻撃者が望む回答を返す“バックドアLLM” を作れる

と実証されました。

トリガー例

  • 特定のキーワード
  • 無害なフレーズ
  • 特定の形式の質問

→ モデルが「通常は安全」でも、そのトリガーの時だけ“裏の人格”が反応する。

これは、

市販モデル・オープンモデル・企業内微調整モデルすべてで起こりうる。

◆ 2-2. 何が怖いか?

  • 事前テストでは発見が難しい(通常動作は正常)
  • RAGと組み合わせると“自然文章の中にトリガーを埋め込める”
  • フィルタやガードレールもすり抜けるケースあり

3. どう防ぐか(ただし“万能策”は存在しない)

RAGのデータ汚染とモデルポイズニングは、完全防御のない“根本的脆弱性” として扱われます。

そのうえで、現実的にできる対策をレイヤ別に整理すると以下。


◆ 3-1. RAG(参照データ)への防御レイヤ

✔ データ登録のRBAC(役割ベース制御)

  • 誰でもRAGに文書を登録できる状態は論外
  • 部署・権限ごとに「登録権限」を分ける

✔ ナレッジベースの改ざん検知

  • SHA/署名・ハッシュを付与
  • 文書の更新履歴・登録者を記録
  • 定期的な差分チェック

✔ Lineage(参照元のログ)

  • 「この回答はどの文書を参照した?」
  • 回答と参照ドキュメントIDを必ず紐付けて保存

→ 誤情報が出たときに 追跡できる ことが最重要。

✔ Web検索RAGは“ホワイトリスト方式”

  • 全Webを検索させるのは危険
  • 信頼できるサイトのみ → リスト化

◆ 3-2. モデル側(ポイズニング対策)

✔ 信頼できるモデル・学習データソースを選ぶ

  • 「よく分からないLLM」「GitHubの野良モデル」を使わない
  • モデルSBOM(Software Bill of Materials)を重視
  • 学習データの出所が明示されているか確認

✔ 微調整データの監査

  • ファインチューニングする場合は データを“人間が”必ずレビューする

✔ 安全チューニングのテスト(Red Teaming)

  • トリガー語句の探索
  • 出力の逸脱をチェック
  • 異常な挙動がないか網羅する

◆ 3-3. 出力の安全フィルタ(Runtime Guard)

  • RAG回答でも、LLM回答でも、内容を もう一度LLM-as-a-Judgeで検査
  • 機密情報、危険な操作指示、誤情報らしき回答をフィルタ
  • ベンダーのガードレール(Content Safety / Prompt Shield)を併用

4. 現時点の限界と展望

RAG汚染・モデルポイズニングは 「AIが追加で読むデータ」すべてが攻撃面になる ため、本質的には完全防御が難しい領域です。

現時点では:

🔸 完璧に止めることはできない

→ できるのは「早く気付けるようにする」こと

🔸 データ系のガバナンスが最重要

→ セキュリティの入口が「データ管理」になる

🔸 モデルのSBOM(由来・構成物の透明性)が2025年以降の焦点

→ どのデータで学習されたかを追えることが必須になる


📌 まとめ:RAGもモデルも“データを信じすぎる”のが最大の弱点

RAGは便利ですが、参照データにウソを混ぜれば AIは100%そのウソを採用します。

そしてモデルポイズニングは、“モデル内部に静かに毒を埋め込める” 攻撃で、安全装置をすり抜ける最も危険なカテゴリ のひとつ。

だからこそ:

  • データ権限制御
  • Lineage
  • 参照元ログ
  • モデルSBOM
  • Red Teaming
  • Runtime Guard

これらを組み合わせて 早期発見と影響最小化 に寄せるのが、現実的で最も効果的な戦略です。


本記事は、ナレッジコミュニケーションによる生成AIセキュリティ支援の実務知見をもとに執筆しています。
安全にAIを活用するための導入支援・運用設計をご希望の方は、ぜひご相談ください。

👉 AIセキュリティ支援サービス

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?