大規模言語モデル（LLM）は自然言語のリクエストに柔軟に応答しますが、その柔軟性自体が運用上のリスクとなることがあります。ユーザーが禁止されたトピックを尋ねたり、検索文書にプロンプトインジェクションが混入したり、モデルが許可されていないツールを呼び出したり、応答に機密情報を含んだりする可能性があります。
NVIDIA NeMo Guardrailsは、このような問題をモデル単体の性質に任せるのではなく、アプリケーションとLLMの間にプログラマブルな制御フローを置くオープンソースツールキットです。単なる罵倒語フィルターではなく、入力、対話、検索結果、ツール実行、最終出力に異なるポリシーを適用し、その順序を調整します。
この記事では、NeMo Guardrailsが何であるか、5種類のRailがどのように動作するか、なぜ一般的なシステムプロンプトだけでは不十分なのか、そしてどの責任まで任せるべきかを徹底的に探求します。公式リポジトリの最新開発ブランチは急速に変化する可能性があるため、実際に導入する際にはリリースバージョンとドキュメントを併せて確認する必要があります。
一文で理解するNeMo Guardrails
NeMo Guardrailsは、LLMの前後に複数のセキュリティチェックを追加するライブラリであり、どのチェックをどのタイミングで実行するかを決定するLLM処理パイプラインランタイムです。
アプリケーションはモデルを直接呼び出す代わりに、LLMRails.generate()またはGuardrails Serverを呼び出します。NeMo Runtimeは、設定とColangフローに従って入力を検査し、必要な検索と動作を実行し、LLMを呼び出した後、出力まで再度検査します。
Application
→ NeMo Guardrails Runtime
→ Input Rail
→ Dialog Rail
→ Retrieval Rail
→ Execution Rail
→ LLM
→ Output Rail
→ Applicationここで重要なのは、Railが特定のモデルを意味するわけではないということです。Railは「この段階で実行するポリシーとフロー」であり、内部ではルール、個別の安全モデル、外部API、Pythonカスタムアクション、または他のLLMを組み合わせることができます。
なぜシステムプロンプトだけでは不十分なのか
システムプロンプトに「個人情報を出力するな」「管理者機能を実行するな」と記述することは必要ですが、強制力のあるアクセス制御ではありません。モデルは確率的に文章を生成し、長い対話や相反する指示、検索文書内の攻撃的な文言に影響を受ける可能性があります。
NeMo Guardrailsを使用する理由は、ポリシーをプロンプトの一文に隠すのではなく、実行可能な段階に分離するためです。
- リクエストをLLMに送信する前に、明白な攻撃と禁止トピックを遮断します。
- RAGが返した原文チャンクをプロンプトに入れる前に検査します。
- 対話状態に応じて、許可された次の動作のみを選択します。
- ツール呼び出し前後の引数と結果を検証します。
- モデル応答がユーザーに伝達される前に、機密情報とポリシー違反を検査します。
この構造は完璧な防御を保証するものではありません。代わりに、失敗箇所を分離し、ポリシー実行記録を残しやすくなります。
5種類のRail
NVIDIA公式リポジトリは、Input、Dialog、Retrieval、Execution、Outputの5つのRailを説明しています。
| Rail | 適用時点 | 代表的な役割 | 遮断時の結果 |
| — | — | — | — |
| Input Rail | ユーザー入力直後 | 脱獄・プロンプトインジェクション・機密情報検査 | LLM呼び出し前終了または入力変換 |
| Dialog Rail | 対話フロー決定時 | 意図・状態・標準手順に基づく次の動作決定 | 事前定義応答または許可フロー選択 |
| Retrieval Rail | RAG検索後 | 検索チャンクの汚染・機密情報・関連性検査 | 危険チャンクの除去またはマスキング |
| Execution Rail | Tool・Custom Action前後 | 引数と実行結果の検証 | ツール呼び出し拒否または結果の精製 |
| Output Rail | LLM生成後 | 有害コンテンツ・情報漏洩・事実性検査 | 応答遮断、修正または再生成 |
Input Rail
Input Railは最も外側のゲートです。ユーザーの原文がモデルコンテキストに入る前に実行されるため、明白な攻撃文字列、禁止トピック、個人情報を遮断またはマスキングできます。しかし、単一の入力フィルターですべての回避表現を捕捉できると仮定すべきではありません。
Dialog Rail
Dialog Railは、NeMoを単純なフィルターと区別する核心です。ユーザーの発話を正規化された意図として解釈し、現在の対話状態においてどのような応答や動作が許可されるかをフローとして表現します。顧客サポートチャットボットであれば、本人確認前にアカウント変更ステップに進めないように対話順序を制限するようなものです。
ただし、実際の認証成功の有無はアプリケーションまたは認証サービスが判断する必要があります。Dialog Railは確認手順のフローを調整できますが、最終的なユーザー権限を自ら付与するセキュリティ境界ではありません。
Retrieval Rail
Retrieval Railは、RAGから検索された原文チャンクとLLMプロンプトの間に位置します。外部文書に隠された指示文、不要な個人情報、関連性の低いチャンクを削除または変換できます。
ベクトル検索前に埋め込み自体を検査するのではなく、一般的に検索後に返された読み取り可能な原文チャンクを検査します。テナントフィルターと文書アクセス権限は検索APIまたはデータ層で最初に強制し、Retrieval Railはその結果のコンテンツ安全性を追加検査する役割が適切です。
Execution Rail
Execution Railは、LLMが呼び出すカスタムアクションや外部ツールの入力と出力を包み込みます。例えば、送金ツールに負の金額や許容範囲を超える値が入力されるのを遮断したり、内部API結果に含まれる秘密値をモデルに返す前に除去したりできます。
ツールが実際に実行可能であるかは、ダウンストリームAPIが再度認証・認可する必要があります。「モデルがこのツールを選んだ」という事実は権限証明ではありません。
Output Rail
Output Railは、モデル応答がユーザーに伝達される直前に実行されます。有害コンテンツ、禁止トピック、個人情報、根拠のない回答などを検査し、遮断・修正・再生成を選択できます。ストリーミング応答では、検査時点と遅延時間、すでに送信されたトークンの回収不可能性を別途考慮する必要があります。
Colangと設定ファイルは何をするのか
NeMo Guardrailsは、config.yml、Colangファイル、Python Actionでポリシーを構成します。config.ymlには使用するモデルとアクティブなRailを宣言し、.coファイルには対話とポリシーフローを表現し、actions.pyには外部サービス呼び出しのようなユーザー定義動作を実装します。
models:
- type: main
engine: openai
model: your-model
rails:
input:
flows:
- check jailbreak
output:
flows:
- self check outputColangは対話フローをモデリングするための言語です。すべてのポリシーをPythonの条件文に散在させる代わりに、「ユーザーがこのような意図を示したら、このフローを実行する」という構造を別ファイルで管理できます。一方で、複雑なポリシーが増えると、Colangとアプリケーションコード間の責任重複を管理する必要があります。
Pythonライブラリとサーバー方式
最も単純な使用法は、アプリケーションプロセス内でPythonライブラリを呼び出すことです。
from nemoguardrails import LLMRails, RailsConfig
config = RailsConfig.from_path("./config")
rails = LLMRails(config)
response = rails.generate(
messages=[{"role": "user", "content": "질문 내용"}]
)
print(response)複数のアプリケーションが共通ポリシーを使用する場合、Guardrails Serverを別のサービスとして配置できます。公式リポジトリは、/v1/chat/completions形式のHTTP APIとコンテナ実行方式を提供します。ライブラリ方式はデプロイが単純で呼び出し遅延が少ない一方、サーバー方式はポリシーの一元化と言語独立性が優れていますが、ネットワーク障害とボトルネックを考慮する必要があります。
NeMoが得意なことと任せてはいけないこと
| NeMoに適した責任 | アプリケーション・信頼層の責任 |
| — | — |
| 入力・検索・出力コンテンツ検査 | ユーザー認証とセッション検証 |
| 対話とLLM処理フローの調整 | テナント確定とデータアクセス権限 |
| カスタムアクション呼び出し前後の検査 | ツール・APIの最終認可 |
| 安全モデル・ルール・外部検査連携 | 金銭・削除・権限変更の最終承認 |
| Rail実行追跡 | 法的監査記録と業務元帳 |
NeMoはLLMパイプラインの中心となることはできますが、業務権限の最終判断者となるべきではありません。最も実用的な責任分担は、「アプリケーションはセキュリティ・業務制御の中心、NeMoはLLM処理パイプラインの中心」です。
導入前に知っておくべき限界
ガードレールには誤検知と未検知があります。複数のRailでLLMベースの検査を繰り返すと、トークンコストと遅延時間も増加します。入力と出力に同じポリシーを重複適用したり、アプリケーションポリシーとColangフローが異なる決定を下したりすると、オペレーターが原因を追跡しにくくなります。
また、公式リポジトリは、内蔵ガードレールがすべての運用環境にそのまま適しているとは保証しておらず、組織の要件と予期せぬ誤用を独自に検討する必要があると案内しています。テストセットには、正常なリクエスト、回避表現、多言語、長いコンテキスト、検索文書の汚染、ツールエラー、ストリーミングを含める必要があります。
最新のリポジトリドキュメントには、匿名使用統計テレメトリーと無効化方法も説明されています。閉鎖網や厳格な個人情報環境では、使用中のバージョンのテレメトリー項目と外部推論エンドポイントの規約をデプロイ前に確認する必要があります。
いつNeMo Guardrailsを使用すべきか
以下の条件であれば、導入価値は大きいです。
- 一つのサービスで入力・RAG・ツール・出力ポリシーを一貫して実行する必要がある。
- 単純なフィルターを超えて、対話状態と標準手順をモデリングする必要がある。
- 複数の安全モデルと外部検査器を一つのRailフローに接続する必要がある。
- ポリシー実行位置と結果を観測し評価する必要がある。
逆に、単一モデルで禁止語をいくつか検査するだけの小さな内部ツールであれば、独自のミドルウェアの方が単純かもしれません。NeMoの価値はフィルターの数よりも、LLM処理フロー全体をポリシーで調整する必要があるかで決まります。
結論
NeMo Guardrailsは、安全なモデルを作成する魔法の箱ではありません。モデル呼び出し前後に散在する検査をInput、Dialog、Retrieval、Execution、Output Railとして構造化し、対話とツール実行のフローをプログラミング可能にするランタイムです。
これを使用する最大の理由は、「モデルが自ら守ることを期待するポリシー」を「実際に実行され観測されるパイプライン」に変えるためです。ただし、認証・認可、テナント境界、最終的な業務承認までNeMoに任せるべきではありません。その境界を守ることで、NeMoはLLMアプリケーションの安全性と運用可能性を共に高める有用なレイヤーとなります。
コメントを残す