本番LLMアプリのAIガードレール実装チェックリスト

レイヤー1：入力ガードレール（LLMへの送信前）

これらはプロンプトがLLMに届く前に実行されます。最初の防衛ラインであり、実装コストも最も低い対策です。

1. 入力長の制限：ユーザー入力を適切な長さ（例：4,000文字）に上限設定します。トークンスタッフィング攻撃を防ぎ、コストを抑制します。上限を超える入力は拒否または切り捨ててください。
2. プロンプトインジェクション検出：「以前の指示を無視して」「役割演技」「システムプロンプトの抽出」など、一般的なインジェクションパターンをスキャンします。正規表現と軽量分類器の両方を活用してください。
3. PIIの検出と匿名化：メールアドレス、電話番号、マイナンバー、クレジットカード番号、その他の機密フィールドをスキャンします。LLMに送信する前に匿名化処理を行います。PresidioなどのライブラリやカスタムNERモデルを活用してください。
4. トピック境界の強制：ユーザーの意図を分類し、範囲外のクエリを拒否します。医療AIが法律の質問に回答すべきではありません。軽量分類器またはLLMベースの意図チェックを使用してください。
5. レート制限：ユーザーおよびIPごとのレート制限を設けます。不正利用の防止、コスト管理、自動攻撃の遅延に効果的です。RedisまたはインメモリカウンターでのI実装を推奨します。
6. 認証と認可：すべてのLLMエンドポイントに認証を必須とします。ユーザーごとに異なるアクセスレベル、ツール権限、データ参照範囲を設定してください。

レイヤー2：LLM設定ガードレール

LLM自体をより安全な出力ができるよう設定します：

1. システムプロンプトの堅牢化：AIが行うべきこととそうでないことを明確に記述します。範囲外のリクエストに対する明示的な拒否指示も含めてください。
2. temperatureとサンプリング：事実確認系アプリケーションはtemperatureを低く設定します（0.0〜0.3）。創造性が必要な場合にのみ高く設定してください。本番環境ではtemperature 1.0以上は避けてください。
3. 最大出力トークン数：max_tokensを明示的に設定し、応答の肥大化を防ぎます。ユースケースに合わせて調整してください。チャットなら500トークン、ドキュメント生成なら2,000トークンが目安です。
4. 構造化出力：JSONモード、ファンクションコーリング、スキーマ制約付き生成を活用します。構造化出力は自由形式の応答よりも検証が容易です。
5. モデル選択：リスクレベルに応じた適切なモデルを使用します。高リスクな判断にはOpus、低リスク・高頻度タスクにはHaikuを。すべてに最高コストのモデルを使う必要はありません。

レイヤー3：出力ガードレール（LLMの応答後）

ユーザーに届く前にLLMの出力を検証します。幻覚、ポリシー違反、フォーマットエラーを検出するために重要です。

1. コンテンツフィルタリング：毒性、ヘイトスピーチ、暴力、不適切なコンテンツを出力からスキャンします。Perspective APIなどの分類器や、自社のコンテンツポリシーに基づいてトレーニングしたカスタムモデルを活用してください。
2. 幻覚の検出：RAGアプリケーションでは、応答が取得したドキュメントに基づいているかを確認します。捏造された引用、事実の創作、根拠のない主張がないかチェックしてください。
3. スキーマバリデーション：期待されるスキーマに対してJSON出力を検証します。適合しない応答は拒否してリトライします。これにより、本番環境でのフォーマット関連の問題を95%防止できます。
4. PIIの漏洩防止：ユーザーに公開すべきでないPIIが含まれていないか出力をスキャンします。LLMが学習データや取得したドキュメントからPIIを表示してしまう場合があります。
5. ブランドとトーンの検証：競合他社への言及がないか、製品名が正しいか、トーンが適切かを確認します。シンプルなキーワードチェックで80%のケースに対応できます。
6. 信頼スコアリング：重要な判断については信頼スコアを追加します。信頼度の低い出力はユーザーに表示する前に人間によるレビューへルーティングしてください。

レイヤー4：運用ガードレール

コストの超過を防ぎ、信頼性を確保するための本番運用ガードレールです：

1. コスト監視とキャップ：ユーザー別、機能別、日次でのAPI支出を追跡します。自動カットオフ付きのハード支出上限を設定し、支出が想定パターンを超えた場合はアラートを出してください。
2. レイテンシ予算：LLMコールのタイムアウト上限を設定します。レイテンシが閾値を超えた場合のフォールバック応答を実装してください。ユーザーを30秒も待たせてはいけません。
3. エラー処理とフォールバック：LLM APIがダウンした場合のグレースフルデグラデーション。キャッシュされた応答、簡略化した処理、または「現在対応できません」という正直なメッセージで対応します。
4. ログと監査証跡：デバッグ、コンプライアンス、品質改善のためにすべての入力と出力を記録します（PII匿名化済み）。規制対象の業界では変更不可の監査ログが必要です。
5. モデルバージョンの固定：本番環境では特定のモデルバージョンに固定します。自動アップグレードは行わず、新バージョンはデプロイ前に評価スイートでテストしてください。
6. サーキットブレーカー：エラー率の急増、コスト上限超過、ガードレールのトリガー率が異常に高い場合に自動カットオフします。連鎖的な障害を防止します。

レイヤー5：コンプライアンスガードレール（規制対象業界向け）

医療、金融、法律、その他の規制対象業界向けの追加ガードレールです：

• データ所在地：AI処理が必要な地域内で行われることを確保します。一部の規制では、インド国内、EU圏内、または特定の管轄区域内にデータを留める必要があります。
• 同意管理：AI処理に対するユーザーの同意を追跡します。オプトアウト手段を提供し、処理するデータとその目的を文書化してください。
• 必須免責事項：医療、法律、金融アドバイスに関しては免責事項を自動挿入します。「このコンテンツはAIが生成したものであり、専門家のアドバイスの代替ではありません」などの文言が必要です。
• ヒューマン・イン・ザ・ループ：高リスクな判断（医療診断、融資承認、法的推奨）については、AI出力を実行前に必ず人間によるレビューを必須としてください。
• 説明責任：AIが特定の出力を生成した理由を説明できるようにします。引用機能を持つRAGベースのシステムは、純粋な生成よりも説明が容易です。
• データ保持ポリシー：必要な保持期間が過ぎたら会話ログとPIIを自動削除します。GDPR、DPDP法、HIPAA、業界固有の規制に準拠してください。

実装の優先順位

すべてのガードレールを一度に実装しようとしないでください。インパクトが高く、手間が少ないものから始めましょう。1週目：入力長制限、レート制限、最大出力トークン、コスト監視。2週目：プロンプトインジェクション検出、コンテンツフィルタリング、エラー処理。3週目：PII保護、スキーマバリデーション、ログ記録。4週目以降：ドメイン固有のガードレール、コンプライアンス制御、評価パイプライン。

本番LLMアプリで最も危険なのは、ガードレールがまったくない状態で素早くデプロイされたケースです。基本的な入力検証と出力制限だけでも、最悪の障害モードを防ぐことができます。まず最小限のガードレールを構築し、その後本番環境での観察に基づいて反復改善していきましょう。