SLM×RAGで「安価・安全・監査可能」を両立する現実解です

今日の深掘りポイント

• 生成AIの“万能化”を目指すより、構造化（SLM）と外部知識参照（RAG）で責任ある機能限定に舵を切るほうが、コストとリスクの両面で現実的です。
• 監査可能性は「設計で埋め込む」ものです。出典・バージョン・プロンプト・検証ステータスの完全ログ化が肝です。
• 企業の実用に耐えるRAGは「検索の精度」ではなく「取り込みパイプラインの無毒化・完全追跡」が勝負です。MITRE ATT&CK視点ではデータ改ざん（T1565）とサプライチェーン（T1195）が最大の盲点です。
• 規制は前倒しでやってきます。EU AI Actの記録義務・透明性要件、NIST AI RMFのガバナンス実装を、RAGの監査ログ設計と一体化させるのが最短経路です。
• メトリクス全体から見て、斬新さよりも「今すぐ適用できる具体策」と「実装確度の高さ」に重心があり、PoCと監査設計の同時立ち上げが現場に効きます。

はじめに

「安価・安全・監査可能」を同時に満たす生成AIは、巨大モデルの“魔法”に頼るより、機能を絞り構造化することで現実解に近づきます。ここで言うSLMは、文献で揺れのある用語ですが、本稿では「構造化出力や制約デコーディングを核に、挙動を統制する設計の総称」として扱います。RAGは外部知識を引くことで、モデルに“持たせない”知識を都度参照し、精度と説明可能性（出典）を担保します。

この組み合わせは、推論コストの抑制（小型モデル＋量子化）、監査と規制対応（出典と根拠のログ化）、そしてモデル主権・データ主権（オンプレ・リージョン内運用）に効きます。大ぶりな変革ではなく、いま手元のシステムから着実に積み上げるレシピとして読み解きます。

深掘り詳細

事実（エビデンス）

• RAGは生成時に外部コーパスから文書を検索・引用し、応答を強化する方法です。基礎論文では多様な知識集約課題で性能向上が確認され、出典を伴う生成の枠組みを与えました。Lewis et al., 2020 です。
• EU AI Actは高リスクAIに対して、運用中の記録保持、技術文書、データガバナンス、透明性等を義務付けます。監査可能な設計（可観測性・トレーサビリティ）は“あと付け”ではなく設計段階で組み込むことが前提になります（公式文書参照）です。EUR-Lex: Regulation (EU) 2024/1689 です。
• NIST AI Risk Management Frameworkは、ガバナンス、マップ、測定、管理の4機能を定義し、記録・評価・改善のループを求めます。RAGの監査ログや評価計画はこのフレームに自然に接続できます。NIST AI RMF 1.0 です。
• LLM特有の脅威は既に整理が進んでおり、特にプロンプトインジェクションや不正ツール実行、データ取り込みパイプライン汚染は代表例です。OWASP Top 10 for LLM Applications による整理が参考になります。
• RAGの基盤実装には高効率なベクトル検索（例：FAISS）やガードレール実装（例：NeMo Guardrails）が活用されています。FAISS、NVIDIA NeMo Guardrails です。
• 小型モデルの推論コスト削減は量子化で加速します。4bitなどの後量子化手法（AWQなど）はメモリ使用量を大幅に削減し、オンプレやエッジでの実用性を高めます（手法の技術的背景）。AWQ: Activation-aware Weight Quantization です。
• 本件の背景解説記事として、SLMとRAGの実務的な組み合わせを提案する技術メディアの記事があります。The New Stack です。

インサイト（編集部の視点）

• 小型×構造化×参照で“必要十分”を最適化する設計です。SLMの肝は「出力の自由度を制御すること」で、JSONスキーマ・関数呼び出し・制約デコーディングなどで出力空間を限定し、評価と監査の単位を明確にできます。これにRAGの「出典と根拠」を結びつけることで、生成物が自然に“監査可能”になります。
• コストは「モデルに知識を詰め込まない」ことで下がります。知識は検索に外出しし、小型モデルは推論と整形に専念します。量子化とバッチング、KVキャッシュ最適化を組み合わせると、現実的なSLAを満たしつつリージョン内運用も見えてきます。
• 監査は「完全再現性の設計」が要です。プロンプトテンプレートのバージョン、取得文書ID・ハッシュ、埋め込みモデルのバージョン、スコア、デコーディングパラメータ、禁止語辞書、最終判断者（人・機械）の識別子まで、すべてイベントとして記録します。規制はここを“見に来る”はずです（仮説ですが、EU AI Actの記録義務の実務運用はこうした設計に収斂すると考えます）。
• RAGは「検索精度の勝負」だと誤解されがちですが、実際の事故は取り込みパイプラインの無毒化失敗から起きます。マルウェア混入、権限過剰での秘密情報インデックス化、改ざん検知の欠如——これらは生成側ではなく、データ工学の領域に原因があります。
• モデル主権はセキュリティの問題でもあります。社内や国内インフラで小型モデル×RAGを回せれば、データ移転・越境リスク、モデルAPIの外部依存（停止・価格改定・管轄の急変）といった地政学リスクを抑制できます。

脅威シナリオと影響

SLM×RAGは“安全側”のアーキテクチャですが、攻撃面を持ちませんとは言えません。MITRE ATT&CK（Enterprise）に沿って、現実的な仮説シナリオを整理します。

• 知識ベース改ざん（RAGインデックス汚染）

  • 仮説: 攻撃者がクローリング元や社内コンフルエンス等の原本を改ざんし、RAGが毒データを取り込む。
  • ATT&CK: Data Manipulation（T1565、特にStored Data）です。
  • 影響: 誤情報の自動拡散、意思決定の誤誘導、監査負荷の爆発。
  • 防御の要点: 取り込み元の署名検証、改ざん検知（ハッシュ比較・Merkle木）、WORMストレージでの永続化、取り込み前の静的・動的検証（マルウェア・フィッシング文言・埋め込みドリフト）です。

• サプライチェーン妥協（モデル/埋め込み/ライブラリ）

  • 仮説: 埋め込みモデルやベクトルDBの依存コンポーネントに悪性改変が混入。
  • ATT&CK: Supply Chain Compromise（T1195）です。
  • 影響: 埋め込みの系統的偏向、機密データのサイフォン化、推論改ざん。
  • 防御の要点: 署名付きアーティファクトの強制、SBOM/MBOMの管理、リリースごとの再現ビルド、in-toto/Sigstore系の検証導入（設計上のガイド）です。

• ベクトルDB/オブジェクトストレージの資格情報露出

  • 仮説: CI/CDログやノートブックに平文キー、あるいは環境変数の誤露出から横移動。
  • ATT&CK: Unsecured Credentials（T1552）、Valid Accounts（T1078）です。
  • 影響: 大量の機密文書がRAG経由で抽出、もしくは直接流出。
  • 防御の要点: 短命トークン、KMS、ネットワーク分離、きめ細かいRBAC、クエリ監査＆異常検知です。

• 公開RAGエンドポイントを突くプロンプトインジェクション

  • 仮説: ユーザが貼り付けるURLや文書中に「システムプロンプト上書き」テキストを埋め込み、ツール実行・データ抽出を誘発。
  • ATT&CK: Data Manipulation（T1565）の一形態として整理し、実行面ではUser Execution（T1204）相当の社会工学的誘導として扱うのが現実的です（厳密な1対1対応はありませんが、運用上の対策観点での対応付けです）。
  • 影響: ガードレール逸脱、外部送信、権限昇格的なツール操作。
  • 防御の要点: コンテキスト分離（システム/ユーザ/ドキュメントの境界）、命令性テキストの検出と除去、ツール呼び出しの許可リスト、2段階審査（人の確認）です。

• 公開Webサービス経由の機密送信

  • 仮説: 生成応答に外部WebhookやクラウドストレージURLを紛れ込ませ、RAGが抜いた情報を送信。
  • ATT&CK: Exfiltration Over Web Services（T1567）です。
  • 影響: データ外泄の不可視化、監査の困難化。
  • 防御の要点: 送信先ドメインのアウトバウンド制御、応答内URLの検疫、監査ログの整合性検証（署名・改ざん耐性）です。

• 公開インデクサの脆弱性悪用による初期侵入

  • 仮説: ベクトルDBやAPIゲートウェイの脆弱性から踏み台化。
  • ATT&CK: Exploit Public-Facing Application（T1190）です。
  • 影響: 横移動によるラテラル侵害、広域データ流出。
  • 防御の要点: 絶え間ないパッチ適用、面の縮小（プライベートLink）、ゼロトラスト境界、mTLSとWAFです。

これらはあくまで仮説ですが、RAGの“データ側”を攻めるのが最短で効く、という非対称性が本質です。生成モデルの堅牢化だけに注力すると、攻撃面の大半を取り逃します。

セキュリティ担当者のアクション

• 30日でやること（PoCの同時並行）
  • ドメイン限定のRAG PoCを1つ選ぶ（FAQ/手順書/規程など、権限の整理が明確な領域）です。
  • 監査スキーマを先に作る。プロンプト、テンプレートID、retrieverクエリ、候補文書ID/ハッシュ、スコア、最終出力、拒否理由、デコーディング設定、モデル/埋め込み/ツールのバージョンを必須化します。
  • データ取り込みパイプラインにマルウェア・秘密情報・命令性テキストの検疫を入れる（静的・動的）。取り込みはWORMストレージ＋改ざん検知で鎖を作ります。
• 60日でやること（攻撃面と規制面の埋め込み）
  • MITRE ATT&CKのT1565/T1195/T1552/T1567/T1190を対象にレッドチーム演習を設計し、RAG特有の検出ルール（不自然な高スコア文書・繰り返し取得・URL含有率の急上昇など）をSOCに供給します。
  • EU AI Act/NIST AI RMF対応のコントロールマッピング表を用意し、監査ログがどの要求条項を満たすかを可視化します（記録保持・説明可能性・人の監督など）。
  • SLM（構造化）を徹底：JSONスキーマ/関数呼び出し/許可制ツール実行/ガードレール（NeMo Guardrails等）で出力と行動を型に閉じます。
• 90日でやること（運用の標準化）
  • 評価を「常設」へ。RAGの再現性テスト、retrievalのRecall/MRR、毒性・ハルシネーション・PII漏えい評価をCIに統合します。
  • SBOM/MBOMの整備、署名付きアーティファクト、署名検証のゲートを供給側（MLOps）に強制します。依存モデル・ライブラリのバージョン固定・脆弱性監視も継続します。
  • データ主権の観点から、量子化小型モデルのオンプレ/リージョン内推論パスを本番並列で立て、外部API停止・価格変動のBCPを確保します。
• 継続運用のベストプラクティス
  • 最小権限のRAG設計（検索対象の厳格スコープ、階層型RBAC、機密領域は二段階フェデレーション）です。
  • 応答の根拠提示を「必須仕様」にする（引用と踏査リンク、欠落時は出力を抑止）です。
  • 監査ログの改ざん耐性（WORM、署名、チェーン）と再現パイプライン（同一入力で同一出力が出る、ないしは差分説明可能）を維持します。

参考情報

• RAG 基礎論文（Retrieval-Augmented Generation for Knowledge-Intensive NLP）: https://arxiv.org/abs/2005.11401
• EU AI Act 公式（EUR-Lex）: https://eur-lex.europa.eu/eli/reg/2024/1689/oj
• NIST AI Risk Management Framework 1.0: https://doi.org/10.6028/NIST.AI.100-1
• OWASP Top 10 for LLM Applications: https://owasp.org/www-project-top-10-for-large-language-model-applications/
• FAISS（ベクトル検索ライブラリ）: https://github.com/facebookresearch/faiss
• NVIDIA NeMo Guardrails: https://github.com/NVIDIA/NeMo-Guardrails
• AWQ（4bit量子化の基礎）: https://arxiv.org/abs/2306.00978
• 記事の元ネタ（技術メディア）: https://thenewstack.io/build-cheaper-safer-auditable-ai-with-slms-and-rag/

おわりに SLM×RAGは、最新・最大ではなく「責任ある十分性」を狙う設計です。現場が求めるのは、説明できる精度、支払えるコスト、耐えられるリスクです。攻撃者が狙うのは生成AIそのものではなく、その周りのデータと供給網です。だからこそ、監査可能性とデータガバナンスを最初からアーキテクチャに焼き込むことが、最短距離の安全策です。読者のみなさんの現場で、まずは一つ、PoCと監査設計を同時に立ち上げてみてください。そこから見える改善点こそが、次の90日の道しるべになるはずです。