RAGセキュリティ運用設計（2026年版）：脅威モデルから実装まで

RAGは「精度問題」から「運用リスク問題」へ

最近の実務コミュニティで共通しているのは、RAGの課題が回答品質だけではなく、信頼できない文脈を信頼系システムが実行判断に使ってしまうことだという認識です。誤答より深刻なのは、漏えい・越権・誤操作です。

脅威モデルを工程別に分解する

• 取り込み（Ingestion）: 毒入り文書、隠し命令、悪性Markdown/HTML
• 検索（Retrieval）: テナント境界の混同、過剰検索、期限切れ文書
• 生成（Generation）: システム方針の上書き、機密混入
• 後処理（Post-process）: 危険なツール呼び出し、未検証URL提示

脅威ごとに、失う資産（顧客情報、運用鍵、社内手順）を明確化すると、統制優先順位が決まります。

モデル頼みではなく、制御面を設計する

安全なRAGには、モデル外側の決定論的制御が必要です。

1. 文書に信頼ラベル（出所・責任者・レビュー状態・有効期限）
2. ユーザー権限と意図に応じた検索許可リスト
3. 検索結果をそのまま渡さないコンテキスト防火壁
4. 出力時の機密検査（正規表現＋意味的判定）

プロンプト改善だけでは保証レベルが不足します。

コンテキスト防火壁の具体像

防火壁サービスで以下を実施します。

• 命令文として機能し得るパターンを除去
• jailbreak系の誘導トークンを遮断
• 文脈に出所・信頼度を必須付与
• 高リスク意図では低信頼ソースを自動除外

この層はアプリ本体と同じくバージョン管理し、回帰テスト対象にします。

実行時監視の設計

完全防御は不可能なので、検知と封じ込めを設計します。

• 検索結果の生文ではなくprovenance IDを記録
• リクエストごとの注入リスクスコア
• 異常なツール実行シーケンスの検知
• テナントごとの平常行動ベースライン

LLMログ単体では不十分です。API Gateway・認証ログ・監査ログを相関して初めて原因追跡できます。

自動化すべきレッドチーム項目

• PDFフッターへの隠し命令混入
• クエリ細工による越境検索
• 既知パターン鍵の抽出誘導
• 回答文での悪性URL提示

これらをCIで常時実行し、失敗時は通常テスト同様にリリースブロックします。

体制設計

• プラットフォーム: 検索基盤・統制レイヤー
• セキュリティ: ルール定義・検知・インシデント対応
• プロダクト: ユースケースごとの許容リスク定義

責任境界が曖昧だと、障害時に調整コストが増え、封じ込めが遅れます。

まとめ

RAGセキュリティはプロンプト技術ではなく運用設計です。信頼ラベル、コンテキスト防火壁、実行時監視、継続的レッドチームを実装することで、有用性と安全性を両立できます。