AI ガードレール 実装ガイド — LLM アプリに安全柵を設計する方法

AI ガードレール とは、LLM アプリの入出力を検査・制御し、プロンプトインジェクションやハルシネーションなどのリスクを低減する安全機構の総称です。

生成AI の本番投入が加速する一方、適切な安全柵なしにリリースされたアプリが不正操作や誤情報拡散を招くケースが報告されています。本記事は、LLM アプリの設計・開発・運用に携わるエンジニアおよびプロダクトマネージャーを対象に、脅威モデルの定義から入出力ガード・評価セット構築・マルチテナント対応までを実装視点で解説します。読み終えた後には、自社サービスに即座に適用できる設計の骨格を手に入れられます。

ガードレールを正しく設計するには、まず「何を守るのか」を明確にする必要がある。入力・出力それぞれのリスクを棚卸しせずに実装を始めると、過剰な遮断や見落としが生じやすい。

最初に取り組むべきは、自社のLLMアプリが扱うデータと想定ユーザーの整理だ。次に、プロンプトインジェクションやハルシネーションといった脅威がどの経路で発生しうるかをマッピングする。この前提作業を省くと、後工程の実装コストが跳ね上がる傾向がある。

ガードレールを設計する前に、まず「何を守るか」を明確にする必要がある。入力と出力の双方に守るべき対象があり、それぞれ性質が異なる。

入力側で守るべき対象

• プロンプトインジェクション（Prompt Injection）: ユーザーが悪意あるテキストを埋め込み、システムプロンプト（System Prompt）を上書きしようとする攻撃。直接インジェクション（Direct Injection）と、外部データ経由の間接インジェクション（Indirect Injection）の両方を想定する
• 機密情報漏洩（Sensitive Information Disclosure）: ユーザーが意図せず、または意図的に個人情報・認証情報を入力するケース
• 無制限リソース消費（Unbounded Consumption）: 極端に長いプロンプトや大量リクエストによる過負荷

出力側で守るべき対象

• ハルシネーション（Hallucination）: LLM（大規模言語モデル）が事実と異なる情報を自信満々に生成するリスク
• 不適切な出力処理（Improper Output Handling）: 生成テキストがそのままコードや SQL に渡され、インジェクションを引き起こすケース
• システムプロンプト漏洩（System Prompt Leakage）: 応答の中にシステムプロンプトの内容が含まれてしまう問題

整理の実践として、まず自社アプリのデータフロー図を描き、「ユーザー入力 → LLM → 外部システム」の各接点を洗い出すとよい。接点ごとに上記の脅威を当てはめると、優先度が自然に見えてくる。OWASP の LLM Top 10 はこの整理の出発点として参照価値が高い。

次のセクションでは、既存アプリの現状把握の手順に進む。

ガードレール設計に着手する前に、既存アプリの「現在地」を正確に把握することが欠かせない。設計上の盲点を放置したまま実装を進めると、後工程で大規模な手戻りが発生しやすい。まず現状を棚卸しし、優先課題を絞り込もう。

確認すべき主なポイント

• 入出力の経路: ユーザー入力がシステムプロンプトにどう合流しているか、RAGの検索結果はどこでプロンプトに組み込まれているかを図示する
• コンテキストウィンドウの利用状況: 会話履歴・ツール結果・外部ドキュメントが混在している場合、間接インジェクションの経路になりやすい
• ログの有無: 入力・出力・モデルレスポンスが記録されていない場合、ハルシネーションや不適切な出力処理の発生を事後確認できない
• 権限スコープ: エージェント型AIがAPIやデータベースに持つ権限が必要最小限か。過剰エージェント権限はリスクを大きく高める

棚卸しの進め方

既存コードベースをレビューし、システムプロンプトの内容・更新頻度・管理者を特定する。あわせて、ユーザーからの入力が検証なしにプロンプトへ連結されていないかを確認する。この段階でプロンプトインジェクションの侵入経路が複数見つかるケースは少なくない。

ログが存在する場合は、過去のやり取りをサンプリングして問題のある出力パターンを抽出する。ログがない場合は、まず最低限の入出力ロギングを実装することを優先する。現状把握なしにガードレールを設計しても、守るべき箇所を見落とすリスクが高い。

ガードレールの設計は「何を守るか」が決まって初めてコードに落とし込める。本セクションでは、脅威モデルの定義から入力・出力それぞれのガード実装まで、3 つのステップで順を追って解説する。各ステップは独立しているように見えるが、後工程の設計が前工程の見直しを促す反復プロセスであることを念頭に置いてほしい。

ガードレール実装の第一歩は、守るべき対象と攻撃経路を整理した脅威モデルの作成だ。設計なしにフィルターを積み重ねても、重要な穴を見落とすリスクが高い。

まず、アプリが受け取るすべての入力経路を洗い出す。ユーザーの直接入力だけでなく、RAG で取得した外部ドキュメントや API レスポンスも攻撃面になりうる。これが**間接インジェクション（Indirect Injection）**の典型的な経路だ。

次に、OWASP LLM Top 10 をベースに脅威を分類する。優先度の高い項目を以下に示す。

• プロンプトインジェクション（Prompt Injection）: システムプロンプト（System Prompt）を書き換え、意図しない動作を引き起こす
• 機密情報漏洩（Sensitive Information Disclosure）: 個人情報や内部データがレスポンスに含まれる
• 過剰エージェント権限（Excessive Agency）: AIエージェントが想定外のツールやAPIを呼び出す
• システムプロンプト漏洩（System Prompt Leakage）: 指示内容がユーザーに露出する

各脅威には「発生確率」と「影響度」を掛け合わせたリスクスコアを付与し、対処の優先順位を決める。全脅威を同列に扱うと実装コストが膨らみ、MVP（実用最小限プロダクト）段階では完成しない傾向がある。

最後に、信頼境界を図示する。どのコンポーネントが信頼済みで、どこが非信頼ゾーンかを明確にすることで、Step 2 以降の入力ガードレール設計が具体的になる。

入力ガードレールは、ユーザーの入力がLLMに到達する前に有害なリクエストを検知・遮断する防御層だ。プロンプトインジェクションや機密情報漏洩のリスクを上流で止められるため、実装優先度は高い。

主な検査項目は以下の4つに整理できる。

• 直接インジェクション検知: 「前の指示を無視して」「システムプロンプトを出力して」といった典型的なジェイルブレイクパターンを正規表現またはセマンティック検索で検出する
• 間接インジェクション対策: RAGで取得した外部ドキュメントや、ツール呼び出しの返り値にも悪意ある命令が混入しうる。取得コンテンツはサニタイズしてからコンテキストウィンドウに挿入する
• PII・機密情報フィルタ: メールアドレス・クレジットカード番号・社内IDなどをパターンマッチで検出し、マスクまたは拒否する
• トークン長・レート制限: 無制限リソース消費を防ぐため、入力トークン上限とスロットリングをAPIゲートウェイ層で設定する

実装アプローチとしては、OWASPが公開するLLMトップ10の分類を参照しながら、まず高リスクパターンをルールベースで対応し、判定が難しいケースは軽量なSLMや専用の分類モデルで補完するのが現実的だ。PyRITやGarakといったLLMレッドチーミングフレームワークを使って境界テストを自動化すると、ルールの抜け漏れを継続的に検証できる。

注意点として、入力ガードレールは誤検知ゼロを目指すと過剰ガードに陥りやすい。閾値は段階的に調整し、誤遮断ログを評価セットに取り込む運用サイクルを初期から設計しておくとよい。次のStep 3では、LLMが生成した後の出力側での防御を解説する。

LLM が生成した応答をそのまま返すのは、入力ガードと同じくらい危険だ。出力ガードレールは「モデルが何を返したか」を検査し、問題のある内容をブロックまたは変換する最後の砦となる。

主な検査項目

• ハルシネーション検出（グラウンディングチェック）: RAG を使用している場合、回答が取得ドキュメントの内容と矛盾していないかをセマンティック検索ベースで照合する。スコアが閾値を下回った応答は「確認できませんでした」へフォールバックさせる
• 機密情報漏洩の防止: 正規表現や NER（固有表現抽出）でメールアドレス・クレジットカード番号・内部 URL などを検出し、マスキングまたは削除する
• 有害コンテンツフィルタ: 暴力・差別表現・違法情報を分類モデルで評価し、スコアに応じてブロックか警告付き返却かを選択する
• システムプロンプト漏洩の検出: 出力にシステムプロンプトの断片が含まれていないかを文字列マッチで確認する。プロンプトリーキングはジェイルブレイク成功の兆候でもある
• JSON スキーマ検証: 構造化出力を期待するエンドポイントでは、返却値が定義スキーマに適合しているかをバリデートし、不正形式をエラーとして扱う

実装上の注意点

出力ガードはレイテンシに直結する。複数の検査を直列に並べると応答時間が大幅に増加する傾向があるため、軽量なルールベース検査を先行させ、重い ML モデルによる評価は非同期ログ分析に回す構成が有効だ。また、ブロック判定の理由をログに記録しておくことで、後述の継続回帰テストで誤遮断の傾向を把握しやすくなる。

ガードレールは実装して終わりではなく、継続的な評価と改善のサイクルが品質を維持する。モデルのバージョンアップや新しい攻撃パターンの登場により、昨日まで機能していた安全柵が今日は機能しないケースも起こりうる。このセクションでは、評価セットの設計から監視ダッシュボードの構築まで、運用フェーズで必要な仕組みを整理する。

ガードレールは一度実装して終わりではない。モデルのアップデートやプロンプト変更のたびに挙動が変わるため、継続的な回帰テストが不可欠だ。

評価セットは以下の3カテゴリで構成するとよい。

• 正常系: 通常ユーザーが送る典型的なリクエスト群。誤遮断（False Positive）の検出に使う
• 攻撃系: プロンプトインジェクション・ジェイルブレイク・境界テストの代表例をカバーするケース群
• グレーゾーン: 許可・拒否の境界付近にある曖昧な入出力。ポリシー変更の影響を最も敏感に捉える

評価セットのサイズは小さくても構わないが、各カテゴリを均等に含めることが重要だ。攻撃系だけに偏ると、正常系の誤遮断率が見えなくなる。

継続回帰テストは CI/CD パイプラインに組み込む。具体的には次の流れが一般的だ。

1. プルリクエスト時に評価セットを自動実行
2. 攻撃成功率（ASR）と誤遮断率を計測し、閾値を超えた場合はマージをブロック
3. 週次バッチで本番ログから新しい攻撃パターンを抽出し、評価セットへ追加

**評価セットは「生きたドキュメント」**として扱う必要がある。攻撃手法は進化するため、HarmBench などの公開ベンチマークを参照しながら定期的に更新する運用が望ましい。

なお、グラウンディングチェックを含む出力ガードレールの評価では、RAG の検索結果との整合性スコアも指標に加えると、ハルシネーション抑止の効果を定量的に追跡しやすくなる。

ガードレールの効果を持続させるには、運用中の状態を可視化し、異常を即座に検知できる仕組みが欠かせない。評価セットで合格した設定も、本番トラフィックでは想定外のパターンが現れる。ダッシュボードとアラートは「運用の目」として機能する。

モニタリングすべき主要指標

• 遮断率（Block Rate）: 入力・出力ガードレールが発動した割合。急増は攻撃の兆候、急減は設定ミスの可能性
• 誤遮断率（False Positive Rate）: 正常なリクエストが弾かれた割合。UX 劣化の直接指標
• レイテンシ分布（P50 / P95 / P99）: ガードレール処理が応答時間に与える影響を把握
• ハルシネーション検知数: グラウンディングチェックが引っかかった件数の推移
• プロンプトインジェクション検知数: 直接インジェクション・間接インジェクション別に集計

アラート設計の基本方針

閾値は静的な絶対値ではなく、過去 7 日の移動平均に対する相対変化率で設定する傾向がある。これにより、曜日や時間帯による自然な変動を誤検知しにくくなる。

推奨アラートの例：

• 遮断率が移動平均の 3 倍を超えた場合 → 即時通知（PagerDuty 等）
• 誤遮断率が一定水準を超えた場合 → 翌営業日対応キュー
• レイテンシ P95 が SLA 閾値を超えた場合 → オンコール起動

ダッシュボード構成の考え方

Grafana や Datadog などの AIオブザーバビリティ対応ツールを活用し、テナント別・エンドポイント別にドリルダウンできる構造にする。ログにはリクエスト ID・テナント ID・ガードレール判定理由を必ず付与し、後からの原因調査を容易にする。個人情報が含まれる場合はログへのマスキング処理を施すこと。

ガードレールの実装で陥りやすい落とし穴は、大きく「テスト不足による誤遮断」と「過剰ガードによる UX 劣化」の二つに集約される傾向がある。どちらも設計時には見落とされやすく、本番稼働後に初めて顕在化するケースが多い。以下の H3 では、それぞれの失敗パターンと具体的な対策を掘り下げる。

ガードレールを急いで本番投入した結果、正規ユーザーのリクエストを誤って遮断してしまうケースが報告されている。原因の多くは「テストデータ不足」と「境界テスト（Boundary Testing）の省略」だ。

誤遮断が起きやすいパターン

• キーワードマッチ型フィルターが、文脈を無視して拒否する（例：医療Q&Aで「痛み」を含む正常な質問をブロック）
• 多言語対応が不十分なまま英語ベースのルールを適用し、日本語入力で誤検知が多発する
• RAGポイズニング（RAG Poisoning）対策として追加した入力フィルターが、通常の検索クエリまで弾く

根本原因は評価セットの偏り

PoC（概念実証）段階で作成した評価セットが、攻撃パターン中心に偏っていると、正常系の網羅率が低くなる。プロンプトインジェクション（Prompt Injection）対策に注力するあまり、日常的なユーザー発話のバリエーションを十分に収集していないケースが典型例だ。

対策の優先順位

1. 正常系テストを攻撃系と同数以上用意する — 攻撃成功率 / ASR（Attack Success Rate）だけでなく、誤遮断率（False Positive Rate）を必ずKPIに加える
2. シャドーモードで先行検証する — ガードレールを本番トラフィックに並走させ、遮断ログを人手でレビューしてから切り替える
3. 境界テストを自動化する — PyRITやGarakなどのLLMレッドチーミングフレームワーク（LLM Red Teaming Framework）を使い、エッジケースを継続的に生成・検証する

誤遮断は即座にユーザー体験を損なう。次のセクションで述べる「過剰ガード」問題と表裏一体であるため、KPI設計の段階から両者をセットで管理することが重要だ。

ガードレールを厳しくしすぎると、正当なユーザー操作まで遮断し、アプリの使い勝手が著しく低下する。「安全のため」という意図が、かえってユーザー離れを招くケースが報告されている。

過剰ガードが引き起こす典型的な問題

• 医療・法律など専門用語を含む質問が「有害コンテンツ」と誤判定され、回答拒否が頻発する
• 正規のビジネス文書作成リクエストがフィルタに引っかかり、ユーザーが何度もリトライを強いられる
• 曖昧な拒否メッセージしか返さないため、ユーザーは何が問題なのか判断できない

こうした状況は、プロンプトファイアウォールの閾値を低く設定しすぎた場合や、ガードレールのルールをドメイン文脈なしに汎用設定のまま本番投入した場合に起きやすい。

UX を守りながら安全性を確保するアプローチ

• 段階的な応答設計: 即時遮断ではなく、まず「確認メッセージ」を挟むことで誤遮断時のフラストレーションを軽減する
• ドメイン特化の許可リスト: 業務コンテキストに合った用語・表現を許可リストに登録し、誤検知率を下げる
• 拒否理由の明示: 「このリクエストには応答できません」だけでなく、ユーザーが言い換えられるよう簡潔なヒントを添える

評価セットには「正当なリクエストの誤遮断率（False Positive Rate）」を必ず含め、安全性スコアと並べてモニタリングすることが重要だ。安全性と利便性はトレードオフではなく、閾値チューニングと継続的な回帰テストで両立できる。次のマルチテナント環境への適用では、テナントごとに許容リスクが異なるため、このバランス設計がさらに複雑になる。

単一テナント向けに整えたガードレールをそのままマルチテナント環境へ持ち込むと、テナント間でポリシーが混在し、意図しない情報漏洩や過剰制限が起きやすい。SaaS型のLLMアプリや社内向けマルチ部門展開では、テナントごとに許容するトピック・言語・出力形式が異なるケースが多い。以降のH3では、テナント別ポリシー設計の具体的な構造と、金融・医療などの規制業種で追加すべき運用上の注意点を順に解説する。

マルチテナント環境では、テナントごとに許可する操作・禁止ワード・出力形式が異なるため、ガードレールをテナント単位で分離・管理する設計が不可欠です。共通のガードレール層に加え、テナント固有のポリシーを上書きできる階層構造が有効です。

設計の基本方針

• グローバルポリシー（全テナント共通）: ジェイルブレイク検知・機密情報漏洩防止など最低限の安全規則
• テナントポリシー（上書き可能）: 業種・契約に応じた追加制限や許可リスト
• ユーザーポリシー（任意）: テナント内のロール別に細かく制御

この3層構造にすることで、あるテナントが医療用語の出力を許可しつつ、別のテナントでは同じ語句を遮断する、といった柔軟な運用が可能になります。

実装上の注意点

• テナントIDをシステムプロンプトに埋め込み、ガードレール評価時に参照する
• ポリシー設定はコードではなく設定ファイル（YAML・JSON）で管理し、再デプロイなしに変更できる構成にする
• テナント間のポリシーが誤って混在しないよう、コンテキストウィンドウのスコープをテナント単位で厳格に分離する

見落としがちなリスク

テナントAのユーザーがプロンプトインジェクションを利用し、テナントBのポリシーで許可されている操作を引き出す「混乱した代理人問題」が発生するケースが報告されています。対策として、ガードレール評価前にテナントIDの署名検証を挟む設計が推奨されます。

ポリシーの変更履歴はAIオブザーバビリティ基盤に記録し、監査証跡として保持することで、規制対応や障害調査を効率化できます。

金融・医療・法律などの規制業種では、ガードレールはコンプライアンス要件と直結するため、一般的な実装よりも厳格な設計が求められる傾向がある。

規制業種で特に意識すべき観点

• 監査ログの完全性: 入出力の全トレースを改ざん不可の形式で保存し、規制当局の照会に即応できる体制を整える
• データ最小化: システムプロンプト（System Prompt）やコンテキストウィンドウ（Context Window）に個人情報・機密情報を含める範囲を最小限に絞る
• 人間の最終判断（HITL）: 与信審査や診断補助など高リスクな出力は、AIの判断をそのまま採用せず、必ず担当者が確認するフローを設ける
• EU AI Act や NIST AI RMF への対応: 高リスクAIシステムに分類される場合、リスク管理文書やモデルカード（Model Card）の整備が義務付けられるケースがある

実装上の注意点

医療分野では、ハルシネーション（Hallucination）による誤情報が患者安全に直結する。グラウンディングチェック（Grounding Check）を出力パイプラインに組み込み、RAG（Retrieval-Augmented Generation）の参照元ドキュメントを明示することで、根拠のない断定を抑止できる。

金融分野では、機密情報漏洩（Sensitive Information Disclosure）のリスクが特に高い。テナント間のデータ分離に加え、プライバシー・バイ・アイソレーション（Privacy by Isolation）の原則に基づいたアーキテクチャを採用することが望ましい。

規制要件は改定されることがあるため、ISO/IEC 42001（AI管理システム規格）に沿ったガバナンス体制を整え、定期的なレビューサイクルを設けることを推奨する。

Q1. ガードレールを導入するとレイテンシが増加しますか？

入力・出力それぞれに分類モデルを挟む場合、数十〜数百ミリ秒の追加レイテンシが生じる傾向があります。軽量な SLM をガード用に採用する、ルールベースフィルターを最初に通して明らかな違反を早期に弾く、といった多段構成で影響を最小化できます。

Q2. プロンプトインジェクション対策は完全に防げますか？

現時点では「完全防御」は難しく、多層防御が基本です。入力サニタイズ・システムプロンプトの強化・出力のグラウンディングチェックを組み合わせることで、攻撃成功率（ASR）を大幅に下げられます。定期的なファジングやレッドチーミングで継続的に検証することが重要です。

Q3. オープンソースのガードレールライブラリはありますか？

Garak や PyRIT など、LLM の脆弱性評価に使えるオープンソースツールが公開されています。ただしライセンスや対応モデルは変更されることがあるため、公式ドキュメントで最新情報を確認してください。

Q4. マルチモーダルAI にもガードレールは適用できますか？

テキスト以外に画像・音声を扱う場合、モダリティごとに分類モデルを用意する必要があります。マルチモーダルジェイルブレイクへの対応は研究段階の部分も多く、現状では各モダリティの入出力を個別にログ取得し、異常を検知する体制を整えることが現実的な第一歩です。

Q5. 規制対応（EU AI Act・ISO/IEC 42001 など）にガードレールは役立ちますか？

ガードレールのログ・評価記録は、AIガバナンスの証跡として活用できます。ただし規制要件を満たすには、リスク分類や文書化など追加の対応が必要です。専門家への確認を推奨します。

AI ガードレールの実装は、一度設定すれば終わりという性質のものではない。脅威は進化し、ユーザーの利用パターンも変化するため、継続的な改善サイクルが不可欠だ。

本記事で解説した要点を整理すると、次の通りになる。

• 前提条件の整理: 守るべき入出力を明確にし、既存アプリの現状を把握することが出発点
• 実装の三段階: 脅威モデルの定義 → 入力ガードレール → 出力ガードレールの順で設計する
• 運用・評価: 評価セットを用いた継続回帰テストとダッシュボード監視でガードの有効性を維持する
• 失敗パターンの回避: 誤遮断と過剰ガードはどちらも UX を損なうため、バランス調整が重要
• マルチテナント対応: テナント別ポリシーと規制業種ごとの要件を組み合わせた設計が求められる

特に注意したいのは、「守れていれば良い」という発想が過剰ガードによる UX 劣化を招くリスクだ。プロンプトインジェクション対策やハルシネーション抑止は重要だが、正当なリクエストを誤って遮断すれば、ユーザーの信頼を失う。安全性と利便性のトレードオフを意識しながら、評価セットを定期的に更新し、誤遮断率と攻撃通過率の両方を追い続けることが現実的なアプローチといえる。

NISTガイドラインや EU AI Act など規制の動向も踏まえ、AI TRiSM の観点から組織全体のガバナンスとセットで運用設計を進めることを推奨する。ガードレールは技術的な安全柵であると同時に、LLM アプリへの信頼を積み上げるための基盤でもある。