ガードレールとは

Guardrails

LLMアプリケーションの入出力を監視・制御し、有害な出力や情報漏洩を防ぐための仕組み

ひとことで言うと

AIの入力や出力を監視し、危険な内容が出ないようにする仕組み。

概要

ガードレール(Guardrails)とは、LLMアプリケーションにおいて入力・出力の内容を監視・検証・制御することで、有害な出力、意図しない挙動、機密情報の漏洩といったリスクを防ぐための仕組みの総称。 モデル自体のアライメントだけに頼るのではなく、アプリケーション側でプロンプトインジェクションの検知、有害・機密情報を含む入出力のフィルタリング、PII(個人識別情報)のマスキング、出力フォーマットの検証等を行う層を追加することで、実運用における安全性・信頼性を高める。 実装には、正規表現やルールベースのフィルタリングのほか、入出力の妥当性を別のLLM呼び出しで判定させる手法(LLM-as-a-judge)も広く用いられ、Guardrails AIやNVIDIA NeMo Guardrails等の専用ライブラリも登場している。

背景

モデル自体のアライメントによる安全対策だけでは、プロンプトインジェクションのような未知の攻撃や、特定のアプリケーション固有の要件(特定の話題を扱わない等)に十分対応できない場合がある。 ガードレールは、アプリケーション層でこうした追加の制御をすることで、モデル単体の限界を補うため導入されている。

アーキテクチャ

入力段階では、プロンプトインジェクションの兆候の検知や、扱ってはいけない話題の判定等を行う。 出力段階では、有害な内容の検出、PIIのマスキング、期待するフォーマットに沿っているかの検証等を行い、問題があれば出力をブロックまたは修正する。 これらのチェックでは、ルールベースのフィルタや、別のLLM・分類モデルを用いた判定がよく組み合わされる。

ワークフロー

ユーザー入力を受信 → 入力側のガードレール(プロンプトインジェクション検知等)を通過させる → LLMが応答を生成 → 出力側のガードレール(有害コンテンツ検出・PIIマスキング・フォーマット検証等)を通過させる → 問題なければ応答を返却、問題があればブロックまたは修正。

コード例

import re

def check_output(text: str) -> str:
    # メールアドレスをマスキングする簡易的な例
    masked = re.sub(r"[\w.+-]+@[\w-]+\.[\w.-]+", "[REDACTED_EMAIL]", text)
    return masked

print(check_output("連絡先はexample@example.comです"))

利点

• モデル自体を変更せずに、アプリケーション側で追加の安全対策を実装できる
• アプリケーション固有の要件(特定の話題の制限等)に合わせて柔軟にルールを設定できる
• Guardrails AIやNeMo Guardrails等、オープンソースのライブラリを利用して比較的短期間で導入できる

欠点

• チェックの層が増える分、応答のレイテンシやコストが増加する
• ガードレール自体が誤検知(過剰なブロック)や見逃しを起こす可能性があり、完全な防御を保証するものではない
• 扱う言語やドメインが広がるほど、ルールや検証モデルの整備・保守にコストがかかる

比較

• プロンプトインジェクション — ガードレールは、プロンプトインジェクションのような攻撃の影響を軽減するための防御的な仕組みの1つ
• アライメント — アライメントがモデル自体の学習を通じた安全対策であるのに対し、ガードレールはアプリケーション層での追加的な安全対策
• PII — ガードレールには、PIIを検出しマスキングする機能がよく組み込まれる

関連用語

よくある質問

参考文献

• GitHubguardrails-ai/guardrails
• GitHubNVIDIA/NeMo-Guardrails

関連Zenn記事

• Nemo Guardrailsを用いたLLMガードレールの適用
• AIにガードレールを設定しないと、本当に大変なことになる ―Azure Guardrails・Evaluation―
• LLMガードレールソリューションの比較
• LLMにおけるガードレールについて