社内向けに AI チャットを立ち上げてみたら、想定していなかった質問にまで律儀に答えてしまった。
そんな話を聞く機会が、この一年でずいぶん増えました。
モデルの性能が上がるほど「答えられてしまう」こと自体がリスクになる、という逆説がここにあります。
対策としてまず思いつくのは、システムプロンプトに「この話題には答えないで」と書く方法でしょう。
ただ、それはあくまで指示。
指示は守られやすいだけで、守られる保証はどこにもありません。
そこで出てくるのが ガードレール（guardrails） という考え方です。
モデルの内側をどうにかするのではなく、モデルの外側に検査を置くという発想の切り替えになります。
ガードレールはモデルの外側に置く「検査」
まず押さえたいのは、ガードレールがモデルそのものを作り替える技術ではないという点です。
NVIDIA が公開している NeMo Guardrails のドキュメントは、この仕組みを「アプリケーションのアーキテクチャを柔軟に保ったまま、LLM アプリケーションの周りにポリシーの適用と安全性チェックを加えるもの」と説明しています。
大事なのは「周りに（around）」という言葉。
モデルを差し替えても、アプリを書き直しても、検査だけは同じ場所に残せます。
同ドキュメントはガードレールの役割を、安全でない・話題から外れた・悪意のある・ポリシーに反する入力や応答をブロックする、書き換える、あるいは検証することだと整理していました。
止めるだけが仕事ではない、というのがここでの発見でした。
たとえばメールアドレスを含む質問なら、拒否せずに伏せ字へ置き換えてから渡す、という選択肢もあるわけです。
置く場所によって5種類に分かれる
ガードレールは「一箇所に置くもの」ではありません。
NeMo Guardrails は、レール（rails）を input・retrieval・dialog・execution・output の5段階に分類しています。
いずれも LLM とのやり取りの、違う段階で動くという整理です。
入力レールは、ユーザーから届いた文字列を最初に受け止める関所。
ここで弾けば、以降の処理そのものが起きません。
リトリーバルレールは、RAG で引いてきた文書に対する検査を担当します。
社内文書の中に、そもそも渡してはいけない一節が混ざっていることは十分あり得るでしょう。
ダイアログレールは、どうプロンプトを組み立てるか、定型文で返すか、モデルを呼ぶかを決める段。
実行レールは、外部ツールを呼ぶ手前に置く検査です。
そして出力レールが、モデルの答えを利用者へ返す直前に見ます。
入口と出口の両方に置いて、はじめて挟み込む形になる、と考えると配置に迷いません。
なお、ふるまいの土台をどう与えるかという話は、システムプロンプト側の役割になります。
判定役にはルールとモデルの2通りがある
検査そのものを誰がやるのか、という話も分けておきたいところ。
ひとつは、正規表現・禁止語リスト・スキーマ検証といった決定的なルールです。
速くて安く、同じ入力なら必ず同じ結果になるのが強み。
一方で、言い回しを変えられると簡単にすり抜けられます。
もうひとつが、判定専用のモデルに読ませる方法。
代表例が Meta の Llama Guard で、モデルカードによれば Llama Guard 4 は 12B のセーフガード用モデルとして、問題のあるプロンプトと応答の検出を担います。
出力は safe か unsafe の二択で、unsafe のときは違反したカテゴリのコードが続く形式。
カテゴリは S1 の暴力犯罪から S14 のコードインタプリタ悪用まで、14 種類が定義されています。
同モデルカードは「ガードレールはモデルの入力と出力の両方に適用できる」と明記していて、入力を見るときはエージェントの応答を含めず、出力を評価するときは入力と応答の両方を渡す、という使い分けまで書かれていました。
擬似コードにすると、流れはこれくらい素朴なものです。
# 擬似コード：入口と出口に検査を挟む
verdict = guard.check(user_input) # 入力レール
if verdict.unsafe: return refuse(verdict.categories)
answer = llm.generate(user_input) # 本体の生成
if guard.check(answer).unsafe: # 出力レール
return fallback_message
return answerルールで安く落とし、残りをモデルに見せるという二段構えにすると、費用と精度のバランスが取りやすくなります。
防げること、防げないことを先に知っておく
便利な仕組みほど、限界を先に押さえておきたいもの。
OWASP が公開している LLM アプリケーション向けの Top 10（2025 年版）を並べると、ガードレールとの距離感が見えてきます。
筆頭に置かれているのが LLM01 のプロンプトインジェクション。
入力レールはここに効きますが、検査をすり抜ける言い換えはいくらでも作れるので、ゼロにする道具ではありません。
攻撃そのものの仕組みは、別の記事で整理しました。
LLM05 の Improper Output Handling は、検証やサニタイズが足りないまま出力を下流へ渡す問題を指します。
生成された文字列をそのまま SQL やシェルへ流す、といった経路が該当するでしょう。
ここは出力レールと実行レールが正面から効く領域。
対して LLM06 の Excessive Agency は、エージェントに与えた権限が広すぎることから来る話です。
削除できる権限を持たせたまま「削除しないでね」と検査で見張るより、そもそも削除権限を渡さない設計のほうが確実。
レールは権限設計の代わりにはならない、と線を引いておくと判断がぶれません。
最後に
ガードレールは、モデルを賢くする技術ではなく、モデルの周りに検査を置いて事故の形を決める仕組みでした。
置ける場所は入口から出口まで5段階あり、判定役はルールと専用モデルの二択。
そしてプロンプトインジェクションを消し去る銀の弾丸ではない、という前提も同時に持っておく必要があります。
私自身、小さな仕組みを触るときほど「止める」より「何を伏せて返すか」を先に決めておきたい、と考えるようになりました。
以上です。
コメントを残す