TL;DR
- LLM ガードレールは「input / output / prompt injection」の3レイヤーで設計するのが2026年の標準
- どれか1つでは突破される。多層防御（defense in depth）が前提
- input は PII・秘密情報・有害コンテンツの検知、output は事実検証・トーン・PII リーク防止
- prompt injection は構造的に完全防御できない。被害を限定する設計（権限最小化）が現実解
- ガードレールは可観測性とセットで運用、ブロック・許可の両方をログに残す
この記事の目的と成功基準
- 目的: LLM 本番運用のガードレール設計を、レイヤー別の実装パターンで整理する
- 想定読者: LLM プロダクトを本番に乗せる開発者、セキュリティレビュー担当
- 成功基準: 「LLM ガードレール」「prompt injection 対策」関連クエリでの流入、LLM本番運用 への回遊
なぜ多層防御が必要か
NLP2026 参加報告 でも触れられているように、2026年の LLM 研究の主軸は「実世界で安全に動かす」ことに移っている。これは LLM の構造的性質（自然言語＝コードと指示の境界が曖昧）が、攻撃面を広く取らざるを得ないためだ。
OWASP LLM Top10 でも、prompt injection を含む脅威は単一の対策では防げず、入力・出力・権限・監査の組み合わせで被害を抑え込む設計が前提になっている。
レイヤー1: Input Validation
入力段階でフィルタする。
検知すべきもの
- PII: 氏名・電話番号・メールアドレス・クレジットカード番号
- 秘密情報: API キー・パスワード・社外秘マーカー
- 有害コンテンツ: 暴力・差別・違法行為に関する要求
- インジェクション兆候: "Ignore previous instructions" 等のパターン
実装パターン
- 正規表現 + 辞書ベースでパターン検出（高速・低コスト）
- 別 LLM で分類（高精度・高コスト、cache 必須）
- 外部 API（AWS Comprehend、Google DLP）
def validate_input(text: str) -> ValidationResult:
if pattern_match.has_pii(text) and not user.consent_pii:
return ValidationResult.deny("PII_without_consent")
if pattern_match.has_injection_marker(text):
return ValidationResult.warn("possible_injection")
return ValidationResult.allow()
PII 検出時は完全 deny ではなく「マスキングして渡す」のオプションも考える。
レイヤー2: Output Filtering
出力段階でも検査する。
検知すべきもの
- PII リーク: 入力に無かった PII が含まれる（hallucination 由来）
- 事実誤認: ゴールデンセットとの不整合
- トーン違反: ブランドガイドラインからの逸脱
- 構造違反: JSON schema 不適合、必須フィールド欠落
実装パターン
- 構造検証（JSON Schema）は同期・高速
- 内容検証（事実・トーン）は LLM-as-judge で非同期 or サンプリング
- 高リスク機能では同期判定、低リスクではログのみ
def validate_output(raw: str, expected_schema: dict) -> ValidationResult:
try:
parsed = json.loads(raw)
jsonschema.validate(parsed, expected_schema)
except (json.JSONDecodeError, ValidationError) as e:
return ValidationResult.retry("schema_violation", reason=str(e))
if contains_unexpected_pii(parsed):
return ValidationResult.redact()
return ValidationResult.allow(parsed)
レイヤー3: Prompt Injection 対策
prompt injection は構造的に完全防御できない。被害を限定する設計に倒す。
攻撃シナリオ
- ユーザー入力経由：チャットでの指示書き換え
- 間接インジェクション：取得したドキュメントに仕込まれた指示
- ツール経由：tool 応答に含まれる悪意ある指示
被害限定の設計
- 権限最小化: エージェントが扱うツールスコープを必要最小に
- destructive 操作の人間承認: 削除・送金等は HITL を必須に
- 信頼境界の明示: ユーザー入力・外部取得・内部システムを別の信頼レベルで扱う
- インジェクション検知ログ: 「ignore previous」等のパターンを検出したら常にログ＋警告
完全防御は諦め、攻撃成功時の被害を「閲覧可能データの漏洩」程度に抑えるのが現実解だ。
構造的な対策
- System / User 分離の徹底: ユーザー入力を system プロンプトとマージしない
- delimiter の使用:
<user_input>...</user_input>で境界を明示 - post-hoc 検証: 出力が許可された操作に限られているかを検証する layer を別途設置
可観測性との統合
ガードレールはブロックだけでなく、許可も含めて全てログに残す。
{
"timestamp": "2026-05-28T10:00:00Z",
"user_id": "user_123",
"input_validation": "allow",
"output_validation": "redact",
"redacted_fields": ["email"],
"injection_detected": false,
"duration_ms": 245
}
これを後段の LLMオブザーバビリティ で集約。
- ブロック率の傾向（spike なら攻撃の兆候）
- 検知パターンの偽陽性率
- ユーザー別・テナント別の傾向
SLO と組み合わせる
LLM本番運用チェックリスト で扱った品質SLOにガードレール指標を組み込む。
- 偽陽性率 < X%（正当な入力がブロックされる確率）
- 偽陰性率 < Y%（PII が output に漏れる確率）
- ガードレール latency < Z ms
これがないと「安全だが使い物にならない」「使いやすいが PII が漏れる」のどちらかに傾く。
アンチパターン
- input validation だけ: output 段階の hallucination による PII リークが検出できない
- deny だけで warn を使わない: 改善のためのシグナルが残らない
- LLM-as-judge のみ: コストが膨らみ、判定の根拠が追えない。ルールベースと併用する
- delimiter 信仰: タグだけで境界が守られると思い込むと突破される
FAQ
Q. OSS のガードレールライブラリは何を使うべきですか？ A. NeMo Guardrails、Guardrails AI などがありますが、機能網羅性とコスト・運用負荷を比較して選びます。シンプルなケースは自前実装の方が見通しが良いです。
Q. RAG で取得したドキュメントは信頼できますか？ A. できません。間接インジェクションのリスクがあるため、信頼境界を separate し、destructive 操作には常に HITL を挟みます。
Q. ガードレールの偽陽性が業務を止めるリスクは？ A. あります。本番投入前に shadow mode（ブロックせずログのみ）で1〜2週間運用して閾値を調整するのが推奨です。
まとめ
LLM ガードレールは input / output / prompt injection の3レイヤーで多層防御を組む。完全防御は不可能なので「被害を限定する」設計（権限最小化・HITL・信頼境界）に倒す。可観測性とセットで運用し、SLO に組み込んで継続改善する。
