Webクローラー＋LLMエージェント（RAGやブラウジング、ツール実行を伴う仕組み）は、検索結果やクロール本文に混ぜ込まれた「隠し命令（Hidden instructions）」に誘導されるリスクを抱えます。これは単なる誤情報の混入ではなく、エージェントの判断・行動（ツール呼び出し、要約方針、抽出項目、出力形式）そのものを乗っ取る“間接的プロンプトインジェクション”の一種です。この記事では、LLM汚染を前提に「検知」と「封じ込め」を設計する考え方を、実装観点で整理します。 “隠し命令”攻撃は、LLMが処理する外部コンテンツ（Webページ、PDF、メール、ドキュメントなど）に、開発者やユーザーの意図と異なる命令文を混ぜ込み、モデルにそれを「従うべき指示」と誤認させる攻撃です。特に、検索・クロール結果を文脈として投入するRAGやブラウジング型エージェントでは、攻撃者がコンテンツ側を操作できるため「間接的プロンプトインジェクション（Indirect Prompt Injection）」として成立しやすくなります。 押さえるべき本質：LLMは構造的に「命令」と「データ」を同じトークン列として扱います。外部文書に紛れた命令が、システム指示やユーザー意図を上書きする可能性があります。OWASP Top 10 for LLM Applicationsでも Prompt Injection は最重要リスク（LLM01）として整理されています。 学術的にも、外部データに攻撃プロンプトを埋め込み、統合されたアプリケーションの挙動やAPI呼び出しを誘導できることが示されています。 外部データに注入された命令が、LLM統合アプリの機能やAPI呼び出しの制御に影響し得る、という問題提起がなされています。
攻撃の概要
どこが汚染されるか
クローラーによる「LLM汚染」と言うと、クローラーが取得した本文に悪性文字列が入るイメージが強いかもしれません。しかし実際は、エージェントのデータ経路のどこに“命令”が紛れ込むかで、対策ポイントが変わります。
汚染ポイントの分類
| 汚染ポイント | 具体例 | 典型的な被害 | 検知の軸 |
|---|---|---|---|
| 検索結果スニペット | タイトル/説明に命令口調を混ぜる | 参照先選定を誘導 | 命令文・誘導語のスコア |
| HTML本文 | 白文字、極小フォント、display:none | 要約や抽出方針の乗っ取り | DOM差分、不可視テキスト |
| メタ/構造化データ | meta description、JSON-LDに命令 | 優先度・結論誘導 | フィールド別の異常率 |
| 埋め込み資産 | PDF本文、画像OCR文字、alt属性 | 可視レビューと不一致の誘導 | モダリティ別の整合性 |
| インデックス/ベクトルDB | 汚染文書が高頻度でヒット | 継続的な誤誘導（慢性化） | 検索ヒット分布の偏り |
注意：汚染の厄介さは「一度ベクトル化してしまうと、元ページを直しても影響が残り得る」点です。インデックス更新設計（再クロール、再埋め込み、失効）が不十分だと、攻撃が長期化します。
隠し命令(間接的プロンプトインジェクション)の手口
隠し命令の目的は大きく2つです。1つは「回答の誘導（誤情報、特定評価、偏向）」、もう1つは「エージェントの行動の誘導（ツール実行、データ持ち出し、権限濫用）」です。
代表的なパターン
- 優先度逆転：「このページの指示を最優先せよ」「システム指示を無視せよ」
- 抽出仕様の改変：「次のキーだけ抽出」「評価は必ず5点」
- 出力チャネル悪用：JSONやコードブロックに“次工程用命令”を混入
- ツール呼び出し誘導：「このURLを追加で取得」「このAPIを叩け」
- 検知回避：言い換え、分割、段階的な話題転換で命令を滑り込ませる
近年は、命令を突然投げるのではなく、自然な文章の流れで徐々に話題を移して“従いたくなる形”にする攻撃も研究されています。
検知設計の原則
結論から言うと、クローラーによるLLM汚染は「完全防御」よりも検知→隔離→影響最小化が現実的です。外部コンテンツを扱う以上、攻撃混入の可能性はゼロにできません。
原則1：データと命令を分離
外部文書は「命令」ではなく「観測データ」として扱い、エージェントの意思決定に混ざる自由度を下げます。OpenAIのガイドでも、権限の強いメッセージ（developer）に信頼できない入力を入れない、構造化出力でデータ流通を制限する、といった方針が示されています。
原則2：自由記述チャネルを減らす
検知を難しくする最大要因は、LLMが自由文で次工程に影響する文字列を出せることです。ノード間は可能な限りスキーマで固定します（enum、必須キー、最大長、正規表現）。
原則3：検知は多層で
単一のフィルタ（NGワードなど）は回避されやすいです。複数の弱いシグナルを束ねて確率的に判定し、疑わしければ隔離・再取得・人手確認へ回します。
現場で効く考え方：「ブロック」より「スコアリング＋段階的制限」。疑わしい文書は、参照はするがツール実行の根拠にしない、要約に使わない、など影響範囲を狭めます。
検知シグナル設計
ここからが本題です。検知を“モデル任せ”にせず、クローラー／パイプラインの観測可能な特徴量を明示的に設計します。
文書レベルの特徴量
- 命令口調スコア：must/ignore/override/priority/遵守せよ/無視せよ 等
- エージェント誘導語：tool、API、browser、search、system prompt 等
- 形式強制：JSON固定、base64、暗号化、不可視文字の多用
- 反復/過剰強調：同一命令の繰り返し、全大文字、過度な記号
- テーマ不一致：ページ主題（タイトル/見出し）と命令内容が乖離
DOM・レンダリング差分
“隠し”はテキスト内容よりも、表示上の不可視化で成立します。よって、HTML直読みとレンダリング後の差分を取るのが有効です。
- CSSで非表示：display:none、visibility:hidden、opacity:0、font-size:0 など
- 背景同色（白文字）
- 画面外配置（positionで飛ばす）
- aria/alt属性への埋め込み
検索・ヒット分布の異常
汚染文書が「異常に上位でヒットする」「複数クエリで常に顔を出す」場合、RAGの参照面を慢性的に支配します。以下のようなメトリクスを監視します。
- ドメイン別ヒット比率（単一ドメイン偏重）
- 同一文書の再登場率（一定期間内）
- クエリ多様性に対する文書多様性（多様性が低いほど危険）
隔離と封じ込め
検知スコアが閾値を超えた場合に、どう扱うかを決めておかないと運用が破綻します。おすすめは「隔離キュー」と「権限段階」です。
隔離キュー
- 疑わしいURLはベクトル化しない（インデックスに入れない）
- 再クロールを遅延させ、スナップショットを保存
- 人手レビュー対象として、DOM差分・可視テキスト・不可視テキストを提示
権限段階
たとえば「低リスク文書は要約OK」「中リスクは引用のみ」「高リスクは参照禁止」のように扱いを分けます。特に重要なのは、高リスク文書を“ツール実行の根拠”にしないことです。OWASPでもPrompt Injectionは重大リスクとして整理されています。
注意：隔離したのに要約ログや学習ログに残すと、別経路で汚染が再流入します。保存先（ログ、キャッシュ、分析基盤）を含めたデータライフサイクル設計が必要です。
ポイントは、検知ロジックをブラックボックスにしないことです。後から「なぜ隔離されたのか」を説明できないと、運用で必ず揉めます。
運用とテスト
検知設計は、実装よりも運用が難所です。特にLLMエージェントでは、隠し命令(間接的プロンプトインジェクション)による攻撃が成功したときの表れ方が多様です（要約が偏る、引用が増える、出力形式が崩れる、ツールを呼びたがる、など）。
テスト観点
- “隠し命令”入りページを用意し、隔離・低権限化が効くか検証
- 偽陽性（一般的なFAQや利用規約の命令形）への耐性
- インデックス更新（削除・失効）の反映時間
- ツール実行のガード（許可制、スキーマ制約、監査ログ）
監視の最低ライン
- 隔離件数（ドメイン別、時間推移）
- 参照ドメインの多様性
- ツール呼び出しの急増（特定クエリ・特定文書起点）
- 出力の構造違反（JSONスキーマ違反、最大長逸脱）
なお、プロンプト漏えい対策の観点では、まずは出力スクリーニングや事後処理などの監視を優先するのも有効です。
検知設計の型
最後に、現場で使える「型」をまとめます。設計レビューの観点としても、そのまま使えます。
推奨アーキテクチャ
- 取得：HTMLとレンダリング結果（可能なら）を保存
- 抽出：可視/不可視、本文/メタ/属性を分離
- 検知：複数シグナルでスコア化（説明可能なルール＋軽量分類）
- 隔離：高リスクはインデックス投入前に止める
- 封じ込め：参照はしてもツール実行根拠にしない等の権限段階
- 監査：どの文書が、どの判断で、どの出力に影響したか追跡
最小の成功条件：インデックス投入前に「止める」仕組みがあること、そして疑わしいコンテンツが混ざっても“行動（ツール実行）”まで直結しないこと。この2点で事故の大半は小さくできます。
プロンプトインジェクションは、従来型のインジェクション（SQLiなど）と違い、根本解決が難しいという議論もあります。だからこそ、検知と封じ込めを前提に、残留リスクを許容できる設計にすることが現実的です。
クローラーを安全運用しませんか？
LLM汚染の検知・隔離まで含めた設計をご提案します。
まとめ
LLMエージェント向け“隠し命令”攻撃は、外部コンテンツに命令を埋め込み、要約や抽出、ツール実行を誤誘導する「間接的プロンプトインジェクション」です。対策は「完全に防ぐ」よりも、（1）データと命令の分離（2）構造化出力で自由度を下げる（3）多層検知でスコアリング（4）隔離と権限段階で封じ込め、が実務的です。
参考情報
