NeMo Guardrails（NVIDIA）（ネモガードレールズ（エヌビディア））
NeMo Guardrailsとは、NVIDIAが開発したオープンソースのLLMガードレールフレームワークである。独自のドメイン固有言語「Colang」を用いて対話フローを宣言的に定義し、入力レール・出力レール・対話レール・検索レールの4種類のレールでLLMの動作を包括的に制御する。モデルに依存せず、OpenAI、Anthropic、ローカルLLMなど任意のLLMバックエンドと統合でき、ナレッジベース連携によるRAGベースの事実性検証もサポートする。
NeMo Guardrailsの概要とアーキテクチャ
NeMo Guardrails（正式名称: NVIDIA NeMo Guardrails）は、NVIDIAが2023年にApache 2.0ライセンスで公開したLLMガードレールフレームワークである。LLMアプリケーションに「レール（Rails）」と呼ばれる制約を追加し、モデルの振る舞いを安全かつ制御可能な範囲に限定するためのツールキットとして設計されている。
NeMo Guardrailsのアーキテクチャは3つの主要コンポーネントで構成される。
- Colangランタイム: 独自DSL（Domain-Specific Language）であるColangで記述された対話フロー定義を解釈・実行するエンジン
- アクションサーバー: カスタムPythonアクション（外部API呼び出し、DB検索、分類モデル推論等）を実行するサーバーコンポーネント
- LLMインターフェース: 任意のLLMプロバイダ（OpenAI、Anthropic、HuggingFace、ローカルモデル等）と通信するアダプタ層
処理の流れは以下のようになる。ユーザーの入力がまず入力レールで検査され、通過した場合にColangランタイムが対話フローに基づいてLLMへのプロンプトを構築する。LLMの応答が返ると出力レールで検証が行われ、問題がなければユーザーに返される。いずれかのレールで問題が検出された場合は、Colangフロー定義に従って代替応答の生成、リトライ、またはエラー応答が返される。
Colangプログラミング言語
Colang（COlang / Conversational Language）は、NeMo Guardrails専用に設計された宣言的DSLである。自然言語に近い構文で対話のフローとルールを定義できることが最大の特徴である。Colang 2.0（2024年リリース）では、イベント駆動アーキテクチャ、並行フロー実行、マルチモーダル対応が追加された。
Colangの基本構成要素は以下の通りである。
- define user（ユーザー発話定義）: ユーザーが特定の意図で発話するパターンをカノニカルフォームとして定義する。例えば「挨拶する」意図に対して複数の発話バリエーションを登録する
- define bot（ボット応答定義）: ボットの応答テンプレートを定義する。固定テキスト、変数埋め込み、条件分岐による動的応答が可能
- define flow（フロー定義）: ユーザー発話→ボット応答の対話シーケンスを定義する。条件分岐、ループ、サブフロー呼び出し、アクション実行を含む複雑なフローを記述できる
- define subflow（サブフロー定義）: 再利用可能なフロー部品。入力検証や出力検証のロジックをサブフローとして抽出し、複数のメインフローから参照する
Colangのフロー定義例として、金融相談ボットでの株価予測質問のブロックは以下のような宣言的記述で実現される。ユーザーが株価予測を要求するパターンを定義し、そのパターンにマッチした場合にボットが「投資助言は提供できません」と応答するフローを記述する。この宣言的アプローチにより、ドメインエキスパート（非エンジニア）でもルールの追加・修正が可能となる。
4種類のレール（Rails）
NeMo Guardrailsでは、4種類のレールを用途に応じて組み合わせて使用する。
| レール種別 | 適用タイミング | 主な用途 | 実装方式 |
|---|---|---|---|
| Input Rails | LLM呼び出し前 | プロンプトインジェクション検出、トピック分類、PII除去 | Colangフロー + Pythonアクション |
| Output Rails | LLM応答後 | 有害コンテンツ検出、事実性検証、フォーマット検証 | Colangフロー + Pythonアクション |
| Dialog Rails | 対話フロー全体 | 会話の方向制御、禁止トピック回避、エスカレーション | Colangフロー定義 |
| Retrieval Rails | RAG検索後 | 検索結果の関連性検証、機密文書フィルタリング | Colangフロー + Pythonアクション |
各レールはPythonアクションと連携することで、外部APIの呼び出し、データベース検索、分類モデルの推論など任意の処理を実行できる。アクションは非同期（async）実行に対応しており、複数のレールを並列に評価することでレイテンシを最小化できる。
Input Railsの詳細
Input Railsはユーザー入力がLLMに到達する前に適用される防御層である。代表的な入力レールには以下がある。
- self_check_input: LLM自身を使って入力の安全性を自己評価する。プロンプトテンプレートを定義し、入力が「ジェイルブレイク試行」「有害なリクエスト」「オフトピック」のいずれかに該当するかを判定する
- check_jailbreak: 既知のジェイルブレイクパターン（DAN、プロンプトリーク攻撃等）を検出する専用レール
- mask_pii: 入力テキスト中のPIIを検出しマスキングする。内部ではMicrosoft PresidioまたはカスタムNERモデルを呼び出す
Output Railsの詳細
Output Railsはモデルの応答品質を保証する最終防御層である。
- self_check_output: LLMの応答が安全性ポリシーに準拠しているかをLLM自身で検証する
- check_hallucination: RAGコンテキストと応答を照合し、検索結果に根拠のない事実主張を検出する
- check_facts: 外部知識ベースに対して応答中の事実主張をファクトチェックする
ナレッジベース連携とRAG統合
NeMo Guardrailsは組み込みのナレッジベース（KB）機能を持ち、マークダウン形式のドキュメントを直接読み込んでRAG（Retrieval-Augmented Generation）パイプラインを構築できる。KBファイルをkb/ディレクトリに配置するだけで自動的にチャンク分割・ベクトル化され、ユーザーの質問に対して関連チャンクが検索・注入される。
KB連携のアーキテクチャは以下の通りである。
- 埋め込みモデル: デフォルトではSentenceTransformersのall-MiniLM-L6-v2を使用。カスタム埋め込みモデルへの差し替えも可能
- ベクトルストア: デフォルトではFAISSをインメモリで使用。Qdrant、Chroma、Pinecone等への接続も設定可能
- 検索パラメータ: top_k（検索結果数）、chunk_size（チャンクサイズ）、chunk_overlap（オーバーラップ）を設定ファイルで制御
- Retrieval Rails: 検索結果に対して関連性スコアの閾値フィルタリング、機密ドキュメントの除外、重複チャンクの排除などの後処理を適用
外部のRAGパイプライン（LangChain、LlamaIndex等）との統合も可能である。NeMo GuardrailsをLangChainのチェーン内にミドルウェアとして組み込むRunnableRailsアダプタが提供されており、既存のLangChainアプリケーションに最小限の変更でガードレールを追加できる。
設定ファイルとデプロイメント
NeMo Guardrailsのプロジェクトは以下のディレクトリ構造で管理される。
config.yml: LLMプロバイダ、モデル名、レール設定、KB設定などの全体構成を定義config.co（Colangファイル）: 対話フロー、ユーザー意図、ボット応答を定義actions.py: カスタムPythonアクションを実装kb/: ナレッジベースのマークダウンファイルを格納prompts.yml: LLMに送信するプロンプトテンプレートをカスタマイズ
デプロイメント方式は3つある。Pythonライブラリとしてアプリケーションに直接組み込む方式、FastAPIベースのガードレールサーバーとして独立デプロイする方式、そしてDockerコンテナとしてKubernetesクラスタにデプロイする方式である。本番環境ではガードレールサーバーをLLMプロキシとして配置し、すべてのLLMリクエストをガードレールサーバー経由でルーティングするリバースプロキシ構成が推奨される。
よくある質問（FAQ）
Q1: NeMo GuardrailsとGuardrails AIの違いは何ですか？
NeMo Guardrailsは対話フロー全体の制御に強みがあり、Colang言語によってユーザーとの複数ターンの対話シナリオを宣言的に定義できる。トピック制御、対話の方向制御、エスカレーションルールなどの「対話品質」の管理に適している。一方、Guardrails AIは出力の構造化バリデーションに特化しており、RAIL仕様やPydanticモデルによるJSON出力の型チェック・値域検証に優れる。ユースケースに応じて、対話型アプリケーション（チャットボット、カスタマーサポート）にはNeMo Guardrails、API出力の品質保証にはGuardrails AIを選択するのが一般的である。両者を併用することも可能で、NeMo Guardrailsの出力レール内でGuardrails AIのバリデータを呼び出す構成も実装できる。
Q2: Colang 1.0とColang 2.0の違いは何ですか？
Colang 1.0はパターンマッチングベースのシンプルなフロー定義言語であり、ユーザー意図のカノニカルフォーム定義と線形的なフロー記述が中心であった。Colang 2.0は2024年にリリースされた大幅な拡張であり、イベント駆動アーキテクチャ、並行フロー実行（concurrent flows）、メタプログラミング（when句による条件付きフロー活性化）、改善されたアクション呼び出し構文が導入された。Colang 2.0では複数のフローが同時に活性化され、イベント（ユーザー発話、タイマー、外部トリガー等）に応じて動的にフローが選択・実行される。これにより、割り込み対話、タイムアウト処理、複合条件による分岐など、実運用で必要な複雑な対話パターンを自然に表現できるようになった。
Q3: NeMo Guardrailsのレイテンシオーバーヘッドはどの程度ですか？
NeMo Guardrailsのレイテンシオーバーヘッドは設定するレールの数と種類に依存する。self_check_input（LLMベースの入力検証）を有効にした場合、追加のLLM呼び出しが1回発生するため100〜500msの追加レイテンシが発生する。self_check_output（LLMベースの出力検証）も同様である。一方、パターンマッチングベースのレール（正規表現によるPIIマスキング、キーワードフィルタリング等）は1〜10msの追加で済む。レイテンシを最小化するには、LLMベースのレールを必要最小限に絞り、パターンマッチングベースのレールで前段フィルタリングを行う。また、LLM呼び出しのキャッシュ（同一入力パターンに対する判定結果のキャッシュ）を有効にすることで、繰り返しリクエストのレイテンシを大幅に削減できる。