本番AI機能にガードレールを入れる設計論点
「AIチャット機能はリリースしたが、想定外の質問に変な回答をしないか怖くて、機能を絞ったまま塩漬けにしている」——こうした相談を最近よく受けます。デモでは問題なかったのに、本番で不特定多数のユーザーが使い始めた途端、不適切な出力やプロンプトインジェクションのリスクが急に現実味を帯びてくるためです。
ガードレールは「入れるか入れないか」の二択ではありません。どこまで守るかをコストと安全のバランスで決める設計問題です。この記事では、既存プロダクトにAI機能を後付けする際にガードレールをどう設計するか、発注者が押さえておくべき論点を整理します。
ガードレールが要る4つの事故パターン
まず、何を防ぎたいのかを具体化します。「AIが怖い」を分解すると、だいたい次の4つに収束します。
- 不適切な出力：差別的表現、事実と異なる断定（ハルシネーション）、自社のブランドを損なう回答をユーザーに直接見せてしまう
- プロンプトインジェクション：ユーザーが「これまでの指示を無視して〇〇して」のような入力で、システムプロンプトの制約を突破する
- 情報漏洩：他ユーザーのデータ、内部ドキュメント、APIキーなどの機密情報がAIの回答に混入する
- 想定外のコスト・負荷：長文を大量に送りつけられてAPI費用が跳ね上がる、無限ループのような使い方をされる
この4つは対策する層が異なります。「AIにガードレールを入れる」という漠然とした要望を、この4分類のどこを優先するかまで分解しないと、見積もりも設計も進みません。
入力側で防ぐこと
ユーザー入力がAIに渡る前に弾く層です。ここは既存のWebアプリのバリデーションと同じ発想で作れるため、比較的コストが低く効果が高い部分です。
- 文字数・頻度制限：異常に長い入力、短時間の連投をレート制限で機械的に弾く
- NGワード・カテゴリフィルタ：業界特有のNGワード（医療なら診断の断定表現、金融なら投資助言に該当する表現など）を事前にブロックする
- プロンプトインジェクションの兆候検知：「instructions を無視して」「あなたはこれから〇〇として振る舞ってください」といった典型パターンを正規表現やAPIの分類機能で検知し、そのまま渡さずに定型応答に差し替える
ここで100%防ぐのは不可能です。攻撃側は表現を工夫して回避してくるため、入力フィルタは「明らかに悪意のあるものを機械的に減らす」役割と割り切ります。完全な防御は次の層との合わせ技で作ります。
プロンプト設計とシステム側の制約
AIに渡すプロンプト自体の構造で、逸脱の余地を減らします。
- 役割とタスクの範囲を明示的に固定する：システムプロンプトで「この製品のFAQ以外には答えない」「個人情報は要求しない」と明記し、ユーザー入力とシステム指示を構造的に分離する（ユーザー入力をそのまま文字列結合しない）
- 参照データの範囲を絞る（RAGを使う場合）：検索対象のドキュメントに機密情報を含めない、または権限に応じて検索範囲を絞り込む。AIが「知らないはずの情報」を答える事故の大半は、ここの権限設計の漏れが原因です
- 出力形式を構造化する：自由文でなくJSON等の決まった形式で出力させると、後段の処理で異常な出力を検知しやすくなる
ここは既存の業務ロジックとAI呼び出しの境界を設計し直す作業でもあります。既存プロダクトに後付けする場合、「どのデータをAIに渡してよいか」の棚卸しが最初の工数になることが多いです。データの扱いについては個人情報を扱うプロダクトにAIを組み込む前の確認事項で詳しく解説しています。
出力側で防ぐこと
AIが生成した後、ユーザーに見せる前に検査する層です。ここは入力フィルタより実装コストがかかりますが、事故の直接防止という意味では最後の砦になります。
- 出力フィルタ：NGワード・機密情報のパターン（メールアドレス、電話番号、社内固有の識別子など）を正規表現で検知し、該当する場合は出力を差し替える
- ハルシネーション対策：事実確認が必要な回答（価格、在庫、契約条件など）は、AIの自由生成ではなくDBの値を直接埋め込む・引用元を明示するなど、「AIに事実を作らせない」構造にする方が確実です。ハルシネーション検知自体は精度が完璧ではないため、重要な情報ほど生成に頼らない設計が現実的です
- 信頼度が低い場合のフォールバック：AIが「分からない」と判断すべき状況で無理に回答させず、人への引き継ぎ導線（有人チャット、問い合わせフォームへの誘導）を用意する
出力フィルタは「完璧に検知する」のではなく「明らかな事故を減らす」ものと位置づけ、重要な情報ほど生成そのものに頼らない設計に倒す、という優先順位が実務的です。
人の確認をどこに挟むか
自動化と安全性はトレードオフです。全件人が確認すればリスクは下がりますが、AI導入の目的（工数削減・即時性）が失われます。既存業務への組み込みでは、次のようなグラデーションで設計します。
- 完全自動：影響範囲が小さく誤りのコストが低い用途（FAQ回答の下書き、社内向けの一次分類など）
- 事後レビュー：自動で返答しつつ、ログを日次・週次でサンプル確認し、問題があれば都度プロンプトを修正する
- 事前承認：外部公開文書、契約に関わる回答など、誤りのコストが高い用途は人が確認してから送信する
- 人が主・AIが補助：AIは選択肢や下書きの提示にとどめ、最終判断・送信は必ず人が行う
どの用途をどのグラデーションに置くかは、誤りが起きたときの実害の大きさで決めます。ここを発注者と外部チームが最初にすり合わせておかないと、「なぜここまで人手を挟むのか」「なぜここは自動化していいのか」の判断基準がプロジェクト途中でぶれます。
監査ログの設計
事故が起きた後の対応速度は、ログの設計で決まります。最低限、次を記録します。
- ユーザーの入力・AIへの実際のプロンプト（テンプレート適用後）・AIの生成結果の3点セット
- 入力フィルタ・出力フィルタで弾かれた/差し替えられたケース（何が検知されたか）
- 使用したモデル・バージョン・プロンプトのバージョン（後から「あの日の挙動はなぜ変わったか」を追跡できるようにする）
AIのモデルやプロンプトは頻繁に更新されるため、いつ・どのバージョンで・何を出力したかの紐付けがないと、事故発生時に原因を切り分けられません。既存の監査ログ基盤があるプロダクトなら、AI呼び出しもそこに統合するのが素直です。監査ログの設計そのものについては監査ログを後付けする設計と実装の進め方も参考にしてください。
どこまで守るか——コストと安全のバランス
すべての対策を一度に入れる必要はありません。私たちが既存プロダクトへの後付けで提案する優先順位は次の通りです。
- プロンプト設計での境界固定（コスト低・効果高）：システムプロンプトとユーザー入力の分離、参照データの範囲限定はほぼ必須。ここを飛ばすと他の対策の効果が薄れます
- 重要情報の非生成化：価格・契約条件などはAIに「作らせず」DBから埋め込む。事故の実害が大きい箇所から着手します
- 入力・出力フィルタ：NGワード検知、レート制限。実装コストが小さく、事故の頻度を下げる効果があります
- 監査ログ：事故が起きた後の対応速度を上げる。運用開始と同時に整備するのが理想ですが、後付けでも意味があります
- 人の確認フロー：誤りのコストが高い用途に絞って導入。全件人手にすると自動化のメリットが消えるため、対象を絞り込むことが重要です
これらは一度に完璧を目指すより、リリース後の実際の入力ログを見ながら段階的に強化する方が現実的です。本番投入前に完璧なガードレールを作ろうとすると、いつまでもリリースできません。まず低コストの対策で最悪の事故を防ぎ、実際のユーザーの使い方を観察しながら優先順位を調整していくのが、既存プロダクトへの後付けでは特に有効です。この段階的な進め方は既存プロダクトの改善、外部チームが最初に見る観点で解説している「土台を固めてから広げる」考え方と同じです。
外注するときの進め方
ガードレール設計を外部に依頼する場合、次の順序で進めると手戻りが少なくなります。torcheees ではAI・LLM活用の技術支援を軸に、こうした設計を含めたAI機能開発の支援を行っています。
- リスクの棚卸し：4分類（不適切な出力・プロンプトインジェクション・情報漏洩・コスト超過）のうち、自社のプロダクトで実害が大きいのはどれかを最初に洗い出す
- 既存データの棚卸し：AIに渡してよいデータ・渡してはいけないデータの境界を、既存のDBスキーマや権限設計と照らして確認する
- 最小構成での実装：プロンプト境界の固定と重要情報の非生成化を先に入れ、リリースする
- ログを見ながらの追加対策：実際の入力を観察し、フィルタ・人の確認フローを必要な箇所だけ追加する
ガードレールは一度作って終わりではなく、モデルの更新やユーザーの使い方の変化に合わせて継続的に見直す運用が前提になります。
まとめ
- ガードレールは「不適切な出力・プロンプトインジェクション・情報漏洩・コスト超過」の4分類に分解し、自社で実害が大きいものから優先する
- 完璧な検知を目指すより、価格や契約条件などの重要情報は「AIに作らせない」構造にする方が確実で、監査ログで事故発生時の追跡性を確保する
- 全対策を一度に入れず、プロンプト境界の固定など低コストで効果の高いものから段階的に導入し、リリース後の実ログを見て強化するのが現実的
「AI機能は動いているが本番に出すのが怖い」「どこまでガードレールを作り込めばいいか判断できない」という段階でも、torcheees はご相談を受け付けています。まずは1〜4週間の「既存プロダクト診断」で、現状のAI機能とデータの扱いを確認し、ガードレール設計の優先順位と概算費用をご提示します。継続的な改善支援も承っています。お問い合わせフォームからお気軽にご相談ください。