プロンプトインジェクション検出（プロンプトインジェクションケンシュツ）

プロンプトインジェクション検出の概要

プロンプトインジェクション検出は、LLMアプリケーションのセキュリティにおける最前線の防御機構である。ユーザー入力や外部データがLLMに到達する前に悪意あるコンテンツを識別し、攻撃の成功を未然に防ぐことを目的とする。

検出手法は大きく「ルールベース」と「MLベース」に分類される。ルールベースは既知の攻撃パターンに対して高速・低コストで動作するが、未知の攻撃には対応できない。MLベースは未知の攻撃にも対応可能だが、推論コストとレイテンシが発生する。プロダクション環境では両者を組み合わせた多段パイプラインが標準的なアーキテクチャとなっている。

検出の難しさの本質は、自然言語における「指示」と「データ」の境界が曖昧であることにある。「以前の指示を無視してください」というテキストは、攻撃の場合もあれば、プロンプトエンジニアリングの教育コンテンツの場合もある。このコンテキスト依存性が、高精度な検出を困難にしている。

ルールベース検出手法

ルールベース検出は、既知の攻撃パターンを正規表現やキーワードリストとして定義し、入力テキストとのマッチングで検出を行う手法である。

正規表現パターンマッチング

代表的な攻撃パターンを正規表現で定義し、入力テキストに対してスキャンを実行する。以下に主要な検出パターンの例を示す。

正規表現ベースの検出は処理速度が極めて高速（1リクエストあたり<1ms）であり、第一段階のフィルタとして有効だが、攻撃者による言い換えや多言語での攻撃には対応が困難である。

キーワードブロックリスト

特定の危険なキーワードやフレーズのリストを維持し、入力に含まれる場合にアラートを発する。ブロックリストは定期的に更新が必要であり、新たな攻撃手法の発見に応じてメンテナンスを行う。ただし、単純なキーワードマッチングは過検出が多くなりがちであり、コンテキストを考慮したスコアリング方式が推奨される。

ヒューリスティック分析

入力テキストの統計的特徴を分析し、異常を検出する手法。入力長の急激な増加、特殊文字（Unicode制御文字、ゼロ幅文字）の存在、言語の突然の切り替わりなどを検出指標とする。これらの指標単体では誤検出が多いが、他の検出手法と組み合わせることで補完的な効果を発揮する。

MLベース検出手法

機械学習モデルを使った検出は、未知の攻撃パターンへの対応力が高く、現在のプロンプトインジェクション防御の主力技術である。

ファインチューニング分類器

BERTやDeBERTaなどの事前学習済み言語モデルを、プロンプトインジェクションの検出タスクに対してファインチューニングする手法。学習データには正常な入力と攻撃入力のラベル付きデータセットを使用する。

代表的なモデルとその性能比較は以下のとおりである。

パープレキシティ検出

LLMから見た入力テキストのパープレキシティ（困惑度）を測定し、通常の自然文と比較して異常に低い（テンプレート的な攻撃文）または異常に高い（難読化された攻撃文）パープレキシティを示す入力を検出する手法。モデルの内部状態にアクセスする必要があるため、オープンソースモデルとの組み合わせで使用される。

プロービング手法

LLMの応答を観察し、インジェクションの影響を受けているかどうかを判定する手法。「以下の入力を処理した結果、あなたの指示は変更されましたか？」という自己検証プロンプトを追加で送信し、応答の一貫性を確認する。計算コストが高いが、間接インジェクションの検出に特に有効である。

カナリアトークン方式

カナリアトークンは、システムプロンプトに一意のランダム文字列（トークン）を埋め込み、LLMの出力にそのトークンが出現した場合にインジェクションによるシステムプロンプト漏洩を検出する手法である。

実装例として、システムプロンプトにCANARY_TOKEN=a7f3b9c2e1を埋め込み、出力フィルターでこの文字列の出現を監視する。攻撃者が「システムプロンプトを表示せよ」というインジェクションに成功した場合、出力にカナリアトークンが含まれるため検出できる。

カナリアトークンの利点は実装が簡単で、追加のMLモデルや外部サービスが不要な点にある。一方、攻撃者がトークンの存在を知った場合に回避される可能性がある（「トークンを除外して表示せよ」）という限界もある。

多段検出パイプライン

プロダクション環境では、複数の検出手法を直列に接続した多段パイプラインが標準的なアーキテクチャである。各段階で検出精度とコストのバランスが異なるため、軽量なフィルタを先に配置し、段階的に精度の高い検出を適用する。

典型的なパイプライン構成は以下のとおりである。

各段階の結果はスコアとして集約され、合計スコアが閾値を超えた場合にブロックまたはアラートを発する。閾値はアプリケーションのリスクプロファイルに応じて調整する。

偽陽性（False Positive）の管理

検出システムにおいて最も運用コストが高いのが偽陽性の管理である。正常なユーザー入力が攻撃として誤検出されると、ユーザー体験が大幅に劣化し、サービスの信頼性を損なう。

偽陽性率の目安として、商用LLMアプリケーションでは0.1%以下が目標とされる。つまり1,000件の正常な入力のうち、誤ってブロックされるのは1件以下であるべきである。この目標を達成するためには、(1)検出モデルの定期的な再学習、(2)ブロックされた入力のサンプリング監査、(3)ユーザーフィードバック機構（「この入力は正当です」ボタン）、(4)コンテキスト情報（ユーザーの過去の行動履歴）の活用が有効である。

特にプログラミング支援、セキュリティ教育、学術研究の文脈では、インジェクションに似たテキストを正当に入力するケースが頻繁にあり、ドメイン固有の例外リストの管理が重要となる。

よくある質問

Q: ルールベースとMLベースのどちらを優先すべきですか？

両方を組み合わせるのが最善策である。ルールベースは既知の攻撃パターンに対して高速・低コストで動作し、MLベースは未知の攻撃を含む広範なカバレッジを提供する。開発リソースが限られている場合は、まずOSSの事前学習済みDeBERTaモデル（protectai/deberta-v3-base-prompt-injection-v2など）を導入し、正規表現フィルタを前段に配置する構成から始めることを推奨する。

Q: 多言語環境での検出精度はどの程度ですか？

英語以外の言語での検出精度は一般的に低下する。多くの検出モデルは英語データで学習されており、日本語や中国語などの攻撃パターンに対するカバレッジが不十分である。Meta Prompt Guardは多言語対応を謳っているが、言語によって精度にばらつきがある。多言語環境では、(1)言語検出→言語別モデルのルーティング、(2)機械翻訳による英語変換後の検出、(3)多言語DeBERTaモデルのファインチューニングなどのアプローチが検討される。

Q: 検出モデルの学習データはどのように収集しますか？

主要なデータソースとして、(1)公開ベンチマークデータセット（BIPIA、TensorTrust、HackAPromptなど）、(2)プロダクション環境のログから収集した攻撃・正常入力、(3)レッドチーミングで生成した攻撃データ、(4)LLMを使った合成攻撃データの生成がある。特にプロダクションログからのデータ収集は、実際の攻撃分布を反映するため最も価値が高いが、プライバシーとデータ保護規制に準拠した収集・匿名化プロセスが不可欠である。

Q: リアルタイム検出のレイテンシ目標はどの程度ですか？

チャットボットやリアルタイムアシスタントでは、ユーザーの体感遅延に影響しない50ms以下が目標とされる。DeBERTa分類器単体で15ms程度、正規表現フィルタを含む全パイプラインで30〜50ms程度が実現可能である。Llama Guardなどの大型モデルを含む場合は100ms以上となるため、非同期処理やキャッシュの活用を検討する。