Guardrails を"人が気を配るもの"から"CI に通すもの"へ
LLM 安全性の議論は、2025 年までは"プロンプトに気をつける"という属人化した世界だった。2026 年時点の NeMo Guardrails 2.x は Colang 2.0 を標準言語として採用し、トピックレール・入力レール・出力レール・対話レール・検索レールを宣言的に書けるようになった。ここで重要な認識転換は、Guardrails をアプリケーションコードの一部ではなく"ポリシーバンドル"として独立管理し、CI で静的検査・回帰テスト・敵対的テストに通すという発想だ。
レールの 5 分類と責務
入力レールはユーザー入力に対する前段フィルタで、脱獄プロンプト・PII・禁止トピックを弾く。出力レールは LLM 出力に対する後段フィルタで、ハルシネーション抑制・PII 流出防止・有害表現検出を担う。対話レールは Colang で書かれた会話フロー制御で、"この話題が来たらこの流れを強制する"という決定的ガードに使う。検索レールは RAG で取り出した文書の扱い（引用強制・未根拠主張の拒否）を縛る。トピックレールはアプリ全体のドメイン境界を定義する。これら 5 つを"別ファイルに分けて"管理するのが、差分レビューの観点で圧倒的に運用しやすい。
Colang 2.0 の最小例
Colang 2.0 は flows を主語にした DSL で、LLM に依存しない決定的ルートを書きやすい。
```colang flow refuse_off_topic user said something off topic bot refuse to respond about topic bot say "ご質問は契約サポートの範囲のみお答えできます。"
flow main activate greeting activate refuse_off_topic activate check_pii_in_output ```
flow の組み合わせで会話を編むため、差分レビューで"どの flow が新規に有効化されたか"が見える。これは自然言語のシステムプロンプトを肥大化させる運用に比べて、監査可能性が圧倒的に高い。
CI に組み込む 3 層テスト
第一層は Colang の静的検査で、未定義 flow 参照・循環参照・到達不能分岐を弾く。第二層は回帰テストで、既知の入力集合に対して期待レール発火を assert する。第三層は敵対的テストで、garak や内製レッドチーミングセットで脱獄試行を流して合格率をトラッキングする。この 3 層を GitHub Actions や GitLab CI に組み込むと、ポリシー変更が LLM の振る舞いに与える影響を PR レビュー段階で可視化できる。
構成：Guardrails リポジトリの分離
アプリコードと同居させると、フロントエンド修正の PR にポリシー変更が紛れ込むリスクがある。`guardrails-policy/` を別リポジトリ（あるいは monorepo 内でもオーナー別の CODEOWNERS）で管理し、セキュリティチームのレビュー必須とするのが望ましい。NIM 側にはポリシーバンドルの OCI イメージとして配布し、サイドカー or 前段プロキシとしてマウントする構成が安定する。
誤った使い方を避ける
Guardrails を"ハルシネーション完全抑制の魔法"として売り込むベンダーがいるが、これは誤解を招く。出力レールの事実性判定は retriever 根拠との突き合わせに依存しており、根拠が無い領域の生成にはそもそも効かない。逆に、ブランドトーン逸脱・禁止トピック・PII 露出といった"定義可能な境界"には極めて強力に働く。Guardrails の設計原則は、"境界を言語化できる問題にだけ使い、境界を言語化できないものにはモデル選定や RAG 側で対処する"ことだ。
まとめ
NeMo Guardrails は LLM の付属機能ではなく、独立した Policy-as-Code プラットフォームとして扱ってはじめて真価を発揮する。CI に通すこと、レビュー主体をセキュリティチームにすること、敵対的テストを継続的に回すこと、の 3 点が本番運用の最低ラインだ。