外部Webを読むRAGや調査エージェントは、社内文書だけを検索する構成より便利ですが、そのぶん攻撃対象も広がります。2026年時点でも、OWASP は indirect prompt injection と RAG poisoning を主要リスクとして挙げており、Anthropic や OpenAI も『外部コンテンツを命令として扱わない設計』を繰り返し強調しています。
この記事では、外部Webを読むRAGを安全化するために、事故パターン、設計原則、評価項目、運用ルール、導入前チェックを実務向けに整理します。対象は、検索AI、社内ナレッジbot、Web調査エージェントを本番導入したいエンジニアやPMです。
外部Web参照RAGで先に押さえたい事故パターン
代表的な事故は3系統あります。1つ目は、取得したWeb本文や添付文書に『前の指示を無視せよ』のような文言が埋め込まれ、要約や回答フェーズで命令として誤解されるケースです。2つ目は、本文にない結論までモデルが補ってしまい、引用付きのように見える誤回答を返すケースです。3つ目は、検索以外のツール権限まで持つエージェントが、外部コンテンツに引っ張られて送信・更新などの行動を起こすケースです。
OWASP の LLM Prompt Injection Prevention Cheat Sheet は、remote / indirect prompt injection、obfuscation、typoglycemia、RAG poisoning、tool manipulation をそれぞれ独立した攻撃面として扱っています。つまり『怪しい英語の命令文だけ弾けばよい』ではなく、隠しテキスト、base64、見えない文字、長文の免責文に混ぜた攻撃なども前提にすべきです。
安全化の設計原則は『分離・最小権限・後段検証』
まず重要なのは、取得コンテンツをデータとして渡し、指示と混ぜないことです。Anthropic は untrusted content を tool result に閉じ込め、system prompt や plain user text に混ぜないよう推奨しています。さらに JSON エンコードしてソース情報を明示すると、『これは外部から来た本文であり、命令ではない』という境界を保ちやすくなります。
次に、読む役割と行動する役割を分けます。外部Webを収集するエージェントは取得と抽出まで、回答エージェントは引用付き要約まで、更新や送信は別ツールまたは別承認へ切り出す。この分離だけで、注入が通っても被害半径をかなり狭められます。OWASP の agent-specific attacks や OpenAI Agents SDK の tool / guardrail 境界とも相性のよい設計です。
最後に、後段検証を必ず入れます。Anthropic は軽量モデルによる pre-screening、OpenAI Agents SDK は input/output guardrails と tool guardrails を用意しています。取得前のURL判定、取得後の本文スクリーニング、回答直前の引用整合チェックを多層化すると、単一のフィルタに依存しなくて済みます。
評価では精度より先に“安全に失敗できるか”を測る
RAG評価を正答率だけで見ると危険です。Google ADK の評価ドキュメントも、最終回答だけでなく trajectory と tool use を見るべきだと説明しています。外部Web参照では、何を取得し、どの断片を採用し、危険入力でどう止まったかまで評価対象に含める必要があります。
最低限の評価項目は、1) 注入検知率、2) 安全拒否率、3) 引用整合率、4) 権限逸脱率、5) 監査再現性、の5つです。『答えられたか』だけでなく、『怪しいときに止まれたか』『不要なツールを呼ばなかったか』を同じ重みで見てください。
テストケースには通常質問だけでなく、HTMLコメント、白文字、長文脚注、base64、スペル崩し、他言語混在、ツール出力に偽装した攻撃文を混ぜるべきです。OWASP が typoglycemia や encoding/obfuscation を挙げているのは、単純なNGワード判定だけでは本番を守れないからです。
本番運用ではURL許可制と監査ログをセットにする
本番では、最初から検索結果を無制限に読ませないほうが安全です。用途ごとに許可ドメインを決め、公式ドキュメント、ベンダーFAQ、社内承認済みメディアなど、信頼度の違う情報源を分けて扱います。allowlist が曖昧なまま検索エージェントを本番に出すと、精度より先に統制で止まりやすくなります。
ログには URL、取得時刻、抽出後テキストのハッシュ、危険判定、採用した引用断片、実行したツール、最終出力を残します。OpenAI の human-in-the-loop フローや Anthropic の continuous monitoring の考え方と同じで、後から再現できない運用は改善も監査もできません。
加えて、社外送信、権限変更、レコード更新のような不可逆操作は、人間承認を残すのが基本です。外部コンテンツを経由した判断が少しでも入るなら、『読むだけ自動、書く前は承認』を原則にした方が安全です。
導入前の実務チェックリスト
導入前は次の5点を確認すると実務で抜け漏れが減ります。
- 取得元ドメインが allowlist 化され、検索対象の拡張手順が決まっているか
- 取得本文から HTML / script / comment / 埋め込み指示を落とし、データとして渡しているか
- 外部本文を読む役割と、送信・更新する役割が分離されているか
- 注入テスト、安全拒否テスト、引用整合テスト、権限逸脱テストを定期実行できるか
- 引用元URL・ログ・承認履歴をあとから追跡できるか
FAQ：まず何から始めるべきか
最初の一歩は、モデル変更ではなく『外部本文の扱いをどう区切るか』を決めることです。PoC 段階なら、読むだけ・答えるだけの構成から始め、書き込み系ツールは外してください。その上で、10〜20件の攻撃入り評価セットを用意し、通常精度と安全拒否を同時に測ると、弱い箇所が早く見えます。
高性能モデルに期待しすぎず、境界分離、ログ、承認、評価の4点を先に仕組み化する方が、結果として本番移行が速いです。特に外部Webを読む構成は、回答品質より先に『安全に失敗できるか』を設計してください。
外部Web参照を含むRAGやAIエージェントの安全設計、評価フロー、社内ルール整備を進めたい場合は、 AI・Claude研修のご相談はこちら 。PoC段階で評価項目と承認フローまで決めておくと、本番移行がかなり安定します。
