8-3 Guardrails
LLM Safety and Control
1. Guardrailsの必要性
1.1 LLMのリスク
LLMは強力な能力を持つ一方で、制御なしに使用すると様々なリスクがある。 ビジネスアプリケーションでは、これらのリスクを適切に管理しなければ、 ユーザーへの悪影響、法的問題、レピュテーションリスクにつながる。 Guardrailsは、これらのリスクを軽減するための防御層である。
| リスク | 説明 | 影響 |
|---|---|---|
| ハルシネーション | 事実と異なる情報の生成 | 誤った意思決定、信頼低下 |
| 有害コンテンツ | 不適切、攻撃的な出力 | ユーザーへの悪影響、訴訟リスク |
| 情報漏洩 | 機密情報の意図しない開示 | セキュリティ問題、コンプライアンス違反 |
| プロンプトインジェクション | 悪意ある指示による操作 | システムの悪用、データ流出 |
| 出力形式の逸脱 | 期待と異なる形式の出力 | 後続処理のエラー |
1.2 Guardrailsの種類
Guardrailsは、入力側と出力側の両方に設置する。 入力ガードは不正な入力をブロックし、 出力ガードは生成された内容を検証する。 多層防御の考え方に基づき、複数のガードを組み合わせることが推奨される。
@startuml !theme plain skinparam backgroundColor #FEFEFE skinparam defaultFontName Noto Sans JP title Guardrailsアーキテクチャ rectangle "ユーザー入力" as Input #DBEAFE rectangle "入力ガード" as InputGuard #FEE2E2 rectangle "LLM" as LLM #D1FAE5 rectangle "出力ガード" as OutputGuard #FEE2E2 rectangle "ユーザーへの応答" as Output #DBEAFE Input --> InputGuard InputGuard --> LLM : 検証OK InputGuard --> Input : ブロック LLM --> OutputGuard OutputGuard --> Output : 検証OK OutputGuard --> LLM : 再生成要求 note right of InputGuard 長さ制限 禁止ワード インジェクション検出 PII検出 end note note right of OutputGuard 形式検証 有害性検出 機密情報検出 スキーマ検証 end note @enduml
図1: Guardrailsの配置
2. 入力ガード
2.1 入力検証の種類
入力ガードは、ユーザーからの入力がLLMに渡される前に検証を行う。 悪意のある入力や不適切な内容をフィルタリングし、 システムの安全性を確保する。
| 検証種類 | 内容 | 実装例 |
|---|---|---|
| 長さ制限 | 入力文字数の上限 | 最大10,000文字 |
| 禁止ワード | 不適切な言葉のフィルタ | ブラックリスト照合 |
| インジェクション検出 | 悪意ある指示の検出 | パターンマッチ、分類器 |
| PII検出 | 個人情報の検出・マスキング | 正規表現、NER |
| トピック制限 | 対応範囲外の質問をブロック | 分類器 |
2.2 プロンプトインジェクション対策
プロンプトインジェクションは、ユーザー入力を通じてLLMの動作を 意図せず変更させる攻撃である。 例えば「以前の指示を忘れて〜」といった入力で、 システムプロンプトを無効化しようとする。 複数の対策を組み合わせて防御することが重要である。
| 対策 | 説明 |
|---|---|
| 入力のサニタイズ | 特殊文字、制御文字の除去 |
| 入力と指示の分離 | ユーザー入力を明確に区切る |
| インジェクション検出 | 悪意あるパターンの検出 |
| 二重LLMパターン | 別のLLMで入力を検証 |
プロンプトインジェクションを100%防ぐことは困難である。 多層防御を行い、最悪の場合でも被害を最小限に抑える設計が重要。 LLMに与える権限を最小限にし、重要な操作には人間の承認を要求する。
3. 出力ガード
3.1 出力検証の種類
出力ガードは、LLMの生成結果を検証し、問題がある場合は 修正または拒否する。出力の品質と安全性を確保するために重要である。
| 検証種類 | 内容 | 対処 |
|---|---|---|
| 形式検証 | JSON、XMLなどの形式チェック | 再生成、修正 |
| スキーマ検証 | 必須フィールド、型のチェック | 再生成 |
| 有害性検出 | 不適切なコンテンツの検出 | ブロック、フィルタ |
| 事実確認 | 生成内容の事実性検証 | 警告、出典追加 |
| 機密情報検出 | 意図しない情報漏洩の検出 | マスキング、ブロック |
3.2 構造化出力
LLMの出力を構造化することで、後続処理での扱いが容易になる。 JSONモード、Function Calling、Pydanticなどの仕組みを活用し、 出力形式を制御する。形式が保証されることで、 パースエラーのリスクを軽減できる。
| 手法 | 説明 |
|---|---|
| JSON Mode | JSON形式での出力を強制 |
| Function Calling | 事前定義した関数のパラメータとして出力 |
| Pydantic / Zod | スキーマ定義と検証 |
| 出力パーサー | テキストから構造化データを抽出 |
出力検証に失敗した場合の再試行戦略を定義しておく。 最大試行回数、エラーメッセージのフィードバック、 フォールバック処理などを事前に設計することが重要である。
4. Guardrailsの実装ツール
Guardrailsを効率的に実装するためのツールやライブラリが存在する。 これらを活用することで、一から実装する手間を省き、 実績のある検証ロジックを利用できる。
| ツール | 特徴 |
|---|---|
| Guardrails AI | 出力検証、構造化出力、再試行 |
| NeMo Guardrails | NVIDIA製、対話制御 |
| LangChain | 出力パーサー、検証チェーン |
| OpenAI Moderation API | 有害コンテンツ検出 |
Guardrails設計のベストプラクティス
多層防御で複数のガードを組み合わせる。 失敗時のフォールバック処理を用意する。 ガードのログを記録し、継続的に改善する。 ユーザーへの適切なエラーメッセージを設計する。 本番環境でのGuardrails発動状況を監視する。
[1] OWASP. LLM Top 10.
[2] Guardrails AI Documentation.