LLM Output Validator（エルエルエムアウトプットバリデーター）
LLMの出力が事前定義したルール・スキーマ・品質基準に適合しているかを検証し、不適合な場合に修正・リトライ・フォールバックを行う機構。Guardrails AI、Instructor、Pydanticバリデーターなどのツールが提供し、LLMアプリケーションの信頼性を担保する。
LLM Output Validatorとは
LLM Output Validator（出力バリデーター）は、LLMが生成した出力を受け取った後に検証処理を行い、アプリケーションの要件に適合しているかを判定する機構である。LLMの出力は確率的であり、同じプロンプトでも異なる結果を返すため、バリデーションなしでの本番利用はリスクが高い。
バリデーションの種類
構造バリデーション（Schema Validation）
出力のJSON構造、フィールド名、データ型がスキーマに適合しているかを検証する。Pydantic、JSON Schema、Zodなどのスキーマ定義ライブラリを使用する。
検証項目:
- 必須フィールドの存在
- データ型の一致（string/number/boolean/array/object）
- enum値の範囲内チェック
- 文字列長・数値範囲の制約
- ネスト構造の深さ・配列長
意味バリデーション（Semantic Validation）
出力の内容が意味的に正しいかを検証する。事実性チェック（Grounding）、一貫性チェック、ドメイン固有のビジネスルール適合など。
検証項目:
- 生成された数値が現実的な範囲内か
- 参照された製品名・会社名が実在するか
- 文脈に矛盾する記述がないか
- ドメイン固有の制約（医療なら薬剤量の安全範囲など）
品質バリデーション（Quality Validation）
出力のテキスト品質を検証する。文法チェック、トーンの一貫性、長さの適切さ、有害コンテンツの検出など。
検証項目:
- テキスト長の最小/最大制約
- 言語の一貫性（指定言語で出力されているか）
- 重複・冗長な内容の検出
- 有害コンテンツ・バイアスのスコアリング
主要バリデーションツール
| ツール | バリデーション方式 | リトライ | カスタムルール | 対応モデル |
|---|---|---|---|---|
| Guardrails AI | バリデーター連鎖 | ○（最大N回） | ○（Python関数） | 汎用 |
| Instructor | Pydantic validator | ○（最大N回） | ○（Pydantic validator） | OpenAI/Anthropic/Gemini |
| Pydantic v2 | フィールドバリデーター | 手動実装 | ○（field_validator） | - |
| Zod (TypeScript) | スキーマバリデーション | 手動実装 | ○（refine/transform） | - |
| NeMo Guardrails | ルールベース | ○ | ○（Colang） | 汎用 |
Guardrails AI のバリデーター
Guardrails AIは「Guard」オブジェクトにバリデーターを連鎖させる設計だ。組み込みバリデーター（型チェック、長さチェック、有害コンテンツ検出、PII検出など）に加え、カスタムバリデーターをPython関数で定義できる。
バリデーション失敗時のアクション:
- REASK: エラー情報付きでLLMにリトライ要求
- FIX: プログラム的に修正（デフォルト値への置換など）
- FILTER: 該当フィールドを除外
- REFRAIN: 応答全体を拒否
- EXCEPTION: 例外を発生
Instructor のリトライ機構
Instructorはパーシング/バリデーション失敗時に自動リトライする。リトライ時にはPydanticのバリデーションエラーメッセージをLLMに渡し、「このフィールドのこの制約に違反しました。修正してください」と具体的な修正指示を出す。
デフォルトのリトライ回数は3回。max_retriesパラメータで調整可能。リトライごとにAPIコストが発生するため、スキーマ設計の最適化でリトライ回数を最小化することが重要だ。
バリデーションパイプラインの設計
段階的バリデーション
- 構造チェック（高速・安価）: JSON構文、スキーマ準拠をPydantic/Zodで検証
- 意味チェック（中速・中コスト）: ビジネスルール、数値範囲、参照整合性をカスタム関数で検証
- 品質チェック（低速・高コスト）: LLM-as-JudgeやML分類器でコンテンツ品質を評価
高速・安価なチェックを先に実行し、早期にフィルタリングすることでコストを最小化する。
テスト駆動バリデーション
バリデーションルールを単体テストとして実装し、CIパイプラインで自動検証する。LLMの出力変動に対するレグレッションテストとしても機能する。
バリデーション設計のアンチパターン
- 過剰なバリデーション: 全フィールドに厳密な制約をかけると、LLMが「安全な」平凡な回答しか返さなくなる
- リトライ無制限: 無限リトライはAPIコストの暴走と遅延の増大を招く。最大3〜5回が実用的上限
- サイレントフォールバック: バリデーション失敗をログに残さずデフォルト値で置換すると、品質低下が検知できなくなる
よくある質問
Q: バリデーション失敗率はどの程度が正常ですか？
A: モデルとスキーマの複雑さによる。GPT-4oやClaude 3.5 SonnetでシンプルなJSON（5フィールド以下）なら失敗率は1%未満が期待値だ。複雑なネストスキーマ（10フィールド以上、3階層以上）では5〜15%程度の失敗率が一般的で、リトライで最終的に99%以上の成功率を実現する。
Q: Pydanticバリデーターだけで十分ですか？
A: 構造バリデーションにはPydanticで十分だ。ただし意味バリデーション（事実性、一貫性）や品質バリデーション（有害コンテンツ検出）はPydanticの守備範囲外であり、Guardrails AIやカスタムバリデーターの追加が必要になる。
Q: バリデーションのオーバーヘッドはどの程度ですか？
A: 構造バリデーション（Pydantic/Zod）はマイクロ秒オーダーで実質ゼロ。意味バリデーション（カスタム関数）は処理内容による（DB参照があれば数十ms）。品質バリデーション（LLM-as-Judge）は追加のLLM呼び出しが必要で1〜5秒。段階的パイプラインで必要な検証のみを実行することがコスト管理の鍵だ。