LLMの入出力を監視・制御し、プロンプトインジェクション・有害コンテンツ生成・機密情報漏洩・ポリシー違反などを検出・防止するためのソフトウェア層。NVIDIA NeMo Guardrails・Guardrails AI・Lakera Guardなどの実装があり、LLMアプリケーションの安全なデプロイに不可欠な技術である。
LLMガードレール（LLM Guardrails）とは、大規模言語モデルの入力と出力の間に配置されるソフトウェア層で、プロンプトインジェクション攻撃の検出、有害コンテンツの生成防止、機密情報の漏洩防止、ビジネスポリシーへの準拠などを目的として入出力を監視・制御する技術である。道路のガードレールが車両の逸脱を防ぐように、LLMガードレールはモデルの応答が安全な範囲から逸脱することを防止する。
LLMガードレールは一般的に入力ガード（Input Guard）と出力ガード（Output Guard）の2段構成で実装される。
ユーザー入力 → [入力ガード] → LLM → [出力ガード] → 最終応答
↓ 拒否 ↓ 修正/拒否
エラー応答 安全な代替応答
| ガード種別 | 検出対象 | 処理 | レイテンシ影響 |
|---|---|---|---|
| 入力ガード | プロンプトインジェクション・有害リクエスト・PII | ブロック or サニタイズ | 10-200ms |
| 出力ガード | 有害コンテンツ・機密情報・ポリシー違反 | ブロック or 修正 | 50-500ms |
| 対話フロー制御 | トピック逸脱・不適切な会話遷移 | リダイレクト | 10-50ms |
| メタ監視 | 異常パターン・大量試行・エスカレーション | アラート or ブロック | <10ms |
NVIDIAが2023年にオープンソースとして公開したフレームワーク。Colangという独自のDSL（Domain-Specific Language）で対話フローを定義し、LLMの応答を制御する。
主な特徴：
適用例：カスタマーサポートAIの話題制限、社内チャットボットのポリシー準拠、RAGシステムの入出力フィルタリング
Guardrails AI社が提供するオープンソースフレームワーク。Validatorという検証ルールの組み合わせでLLM出力を制御する。
| Validator | 検出対象 | 用途 |
|---|---|---|
| ToxicLanguage | 有害・攻撃的な言語 | コンテンツ安全性 |
| DetectPII | 個人識別情報 | プライバシー保護 |
| PromptInjection | プロンプトインジェクション | セキュリティ |
| RestrictToTopic | トピック逸脱 |
| ビジネスポリシー |
| CompetitorCheck | 競合他社への言及 | ブランド保護 |
| FactualConsistency | 事実整合性 | 品質保証 |
Lakera社が提供するSaaS型のガードレールサービス。API呼び出しでリアルタイムにプロンプトインジェクションを検出する。
特徴：
Protect AI社が開発するオープンソースの入出力スキャナー。複数の検出モジュールを組み合わせて多層防御を実現する。
入力スキャナー: Anonymize（PII匿名化）、BanSubstrings（禁止文字列）、PromptInjection（注入検出）、TokenLimit（トークン制限）、Toxicity（有害性） 出力スキャナー: BanTopics（禁止トピック）、Bias（バイアス検出）、FactualConsistency（事実整合性）、MaliciousURLs（悪意URL）、Relevance（関連性）
最もシンプルな構成。入力と出力にフィルタを配置し、既知のパターンを検出・ブロックする。
適用場面：
メインLLMの出力を別のLLM（またはより小型のモデル）で検証する構成。検出精度が高いがレイテンシとコストが増加する。
適用場面：
入力サニタイズ → トピック分類 → LLM応答 → 出力検証 → PII除去 → 最終応答の多段構成。最も堅牢だがレイテンシが大きい。
適用場面：
| 指標 | 定義 | 目標値 |
|---|---|---|
| 検出率（Recall） | 攻撃を正しく検出した割合 | >95% |
| 精度（Precision） | 検出したもののうち実際に攻撃だった割合 | >90% |
| 誤検知率（FPR） | 正常入力を攻撃と誤判定した割合 | <5% |
| レイテンシ | ガードレール処理の追加時間 | <200ms |
| スループット | 単位時間あたりの処理リクエスト数 | アプリ依存 |
誤検知率（False Positive Rate）は特に重要である。過剰なフィルタリングはユーザー体験を著しく損なう。「プロンプトインジェクションとは何ですか？」という正当な質問を攻撃と誤検知するケースは典型的な問題である。
攻撃者はガードレールの存在を認識した上で、検出を回避する攻撃を設計する。ガードレールのルールが公開されている場合（OSSの場合）は特に回避が容易になる。定期的なルール更新と、公開ルールに依存しない多層防御が必要。
ガードレールの追加はレイテンシを増加させる。特にLLM-as-judgeパターンでは200-500msの追加遅延が発生し、リアルタイム応答が求められるチャットアプリケーションでは体感品質に影響する。ストリーミング出力との両立も課題であり、出力の部分検証やバッファリング戦略が必要になる。
LLM-as-judgeパターンではメインLLMとは別にLLM API呼び出しが発生し、コストが1.5-2倍になる。軽量分類器（DistilBERT等）の併用や、リスクレベルに応じた段階的検証でコストを最適化する。
防げない。ガードレールは防御の一層に過ぎず、完全な防御は2026年時点で不可能である。ガードレールはリスクを大幅に低減するが、新規の攻撃パターン・エンコード手法・多言語攻撃などに対しては検出漏れが生じる。権限最小化・ヒューマンインザループなどの構造的対策と組み合わせることが必要。
要件に依存する。OSSは柔軟なカスタマイズとオンプレミス運用が可能だが、攻撃パターンDBの更新は自己責任。SaaSは最新の攻撃パターンに対応した継続的な更新が提供されるが、LLMの入出力が外部サービスを経由するためデータプライバシーの考慮が必要。機密性の高いシステムではOSS+自社運用、速度重視のプロダクトではSaaSが一般的な選択肢である。
適切に調整しなければ悪化する。誤検知率が高いと正当なユーザーリクエストがブロックされ、ユーザー離脱に直結する。対策としては、ブロック時の具体的なエラーメッセージ表示、ホワイトリストによる既知の正当パターンの許可、段階的な検証（軽量フィルタで明確な攻撃のみブロック→疑わしいものはLLM-as-judgeで精密判定）が有効。