LLM Guard（エルエルエムガード）
LLM Guardとは、LLMアプリケーションの入力と出力を検証・フィルタリングするためのオープンソースツールキットおよびガードレールフレームワークの総称である。代表的なプロジェクトとして、Protect AIのLLM Guard、NVIDIA NeMo Guardrails、Meta Llama Guard/Prompt Guardがあり、プロンプトインジェクション検出、有害コンテンツフィルタリング、PII（個人情報）検出、トピック制限などの機能をスキャナーパイプラインとして提供する。
LLM Guardの概要
LLM Guard（エルエルエムガード）は、LLMアプリケーションのセキュリティと安全性を確保するためのガードレールフレームワーク群を指す。LLMへの入力（プロンプト）と出力（レスポンス）の両方をスキャンし、攻撃的なコンテンツ、有害なテキスト、機密情報の漏洩などを検出・遮断する。
2023年以降、ChatGPTやGPT-4の商用普及に伴い、LLMアプリケーションのセキュリティ需要が急増した。これに応じて、Protect AI、NVIDIA、Meta、Lakera、Rebuffなど複数の組織がガードレールフレームワークを開発・公開している。
LLM Guardの基本的なアーキテクチャは「スキャナーパイプライン」である。入力テキストが複数のスキャナー（検出モジュール）を順番に通過し、各スキャナーがリスクスコアを返す。合計スコアが閾値を超えた場合、入力はブロックまたは修正される。同様のプロセスがLLMの出力に対しても適用される。
主要なLLM Guardフレームワーク
Protect AI LLM Guard
Protect AI（旧laiyer-ai）が開発するオープンソースのLLMガードレールライブラリ。Pythonで実装され、入力スキャナーと出力スキャナーの2段構成でLLMの入出力を保護する。Apache 2.0ライセンスで公開されており、商用利用が可能である。
主要な機能として、プロンプトインジェクション検出（DeBERTa-v3ベースのMLモデル）、PII検出・マスキング（正規表現+NERモデル）、有害性スコアリング、トピック制限、言語検出、不可視文字検出、コード検出、URLフィルタリングなどの20以上のスキャナーを提供する。
NVIDIA NeMo Guardrails
NVIDIAが開発するLLMガードレールフレームワーク。Colangという独自のドメイン固有言語（DSL）を使って対話フローとガードレールを定義する。LLM自体を使った「自己チェック」機構が特徴で、別のLLM呼び出しにより入出力の安全性を検証する。
NeMo Guardrailsの独自性は「プログラマブルガードレール」にある。開発者はColangファイルにルール（flows）を記述し、LLMの動作を細かく制御できる。入力チェック、出力チェック、トピック制限、ファクトチェック、ハルシネーション検出などをルールとして定義可能である。
Meta Llama Guard / Prompt Guard
MetaがLlama 3とともに公開した安全性分類モデル群。Llama Guardはコンテンツの安全性をカテゴリ別に評価するモデルで、Prompt Guardはプロンプトインジェクションの検出に特化したモデルである。
Llama Guard 3は、MLCommons AI Safety Taxonomyに準拠した13カテゴリの安全性評価を行う。各カテゴリ（暴力、性的コンテンツ、犯罪活動、個人情報など）に対してsafe/unsafeのラベルを付与し、該当するカテゴリコードを返す。
Prompt Guardは、mDeBERTa-v3をベースにプロンプトインジェクション検出にファインチューニングされたモデルで、direct injectionとindirect injection（jailbreak）の2種類の攻撃を分類する。多言語対応であり、英語以外の言語での攻撃検出もカバーする。
| フレームワーク | 開発元 | ライセンス | 主要機能 | LLM依存 | カスタマイズ性 |
|---|---|---|---|---|---|
| LLM Guard | Protect AI | Apache 2.0 | スキャナーパイプライン | 低（MLモデル） | 高 |
| NeMo Guardrails | NVIDIA | Apache 2.0 | Colangルール定義 | 高（自己チェック） | 最高 |
| Llama Guard 3 | Meta | Llama 3.1 License | コンテンツ安全性分類 | 中（専用モデル） | 中 |
| Prompt Guard | Meta | MIT | インジェクション検出 | 低（専用モデル） | 低 |
| Lakera Guard | Lakera | SaaS | API型ガードレール | 低 | 中 |
| Rebuff | Rebuff.ai | OSS + SaaS | 多層防御パイプライン | 中 | 中 |
スキャナーパイプラインのアーキテクチャ
LLM Guardの中核的なアーキテクチャであるスキャナーパイプラインは、入力スキャナー（Input Scanners）と出力スキャナー（Output Scanners）の2段構成で動作する。
入力スキャナー
LLMにプロンプトが送信される前に実行されるスキャナー群。ユーザー入力に含まれる攻撃や不適切なコンテンツを事前に検出する。
| スキャナー名 | 検出対象 | 手法 | レイテンシ |
|---|---|---|---|
| PromptInjection | プロンプトインジェクション | DeBERTa分類器 | ~15ms |
| Toxicity | 有害・攻撃的コンテンツ | 毒性分類モデル | ~10ms |
| PIIDetection | 個人情報（メール、電話、住所） | 正規表現 + NER | ~5ms |
| BanTopics | 禁止トピック | ゼロショット分類 | ~20ms |
| InvisibleText | 不可視文字・ゼロ幅文字 | Unicode分析 | <1ms |
| Language | 言語制限 | 言語検出モデル | ~5ms |
| CodeDetection | コードスニペット | 正規表現 + ヒューリスティック | ~2ms |
| Regex | カスタムパターン | 正規表現 | <1ms |
| URLReachability | 悪意あるURL | DNS解決 + ブロックリスト | ~50ms |
| Secrets | APIキー・パスワード | 正規表現パターン | ~2ms |
出力スキャナー
LLMの応答がユーザーに返される前に実行されるスキャナー群。LLMが攻撃により不適切な応答を生成した場合や、機密情報を漏洩した場合に検出する。
| スキャナー名 | 検出対象 | 手法 | レイテンシ |
|---|---|---|---|
| Relevance | 質問との関連性低下 | 類似度計算 | ~10ms |
| Sensitive | 機密情報の漏洩 | パターン + NER | ~5ms |
| Factual | 事実と異なる情報 | 知識ベース照合 | ~100ms |
| Bias | 偏見・差別的表現 | バイアス分類器 | ~15ms |
| Malicious URLs | 悪意あるURLの生成 | ブロックリスト | ~5ms |
| NoRefusal | 不適切な拒否 | テンプレートマッチ | ~2ms |
デプロイメントパターン
LLM Guardのデプロイメントは、アプリケーションの規模と要件に応じて複数のパターンが存在する。
インラインパターン
アプリケーションコード内にLLM Guardのスキャナーを直接統合するパターン。最もシンプルな導入方法であり、小〜中規模のアプリケーションに適している。Pythonライブラリとしてインポートし、LLM呼び出しの前後にスキャン処理を挿入する。
サイドカーパターン
LLM Guardをマイクロサービスとして独立稼働させ、APIゲートウェイまたはプロキシとしてLLMへのリクエストをインターセプトするパターン。アプリケーションコードの変更が最小限で済み、複数のLLMアプリケーションで共有できるため、中〜大規模の組織に適している。
パフォーマンスベンチマーク
主要なフレームワークのパフォーマンス比較を以下に示す。CPU環境（8コア、32GB RAM）での測定値である。
| フレームワーク | 全スキャナー実行時間 | メモリ使用量 | スループット |
|---|---|---|---|
| LLM Guard（全スキャナー） | ~100ms | ~2GB | ~10 req/s |
| LLM Guard（軽量構成） | ~30ms | ~500MB | ~30 req/s |
| NeMo Guardrails | ~200ms（LLM呼び出し含む） | ~1GB | ~5 req/s |
| Llama Guard 3（GPU） | ~50ms | ~8GB VRAM | ~20 req/s |
| Prompt Guard | ~20ms | ~1GB | ~50 req/s |
GPU環境（NVIDIA A10G）では、Llama Guard 3で15ms、Prompt Guardで5msと大幅に高速化される。
導入のベストプラクティス
LLM Guardの効果的な導入には、以下のベストプラクティスが推奨される。
段階的な導入として、まず「監視モード」（ブロックせずにログ記録のみ）で運用を開始し、検出結果の精度を確認した上で「ブロックモード」に移行する。これにより、偽陽性によるユーザー体験の劣化を事前に把握できる。
スキャナーの選択的適用として、すべてのスキャナーを有効化するとレイテンシが増大するため、アプリケーションのリスクプロファイルに応じて必要なスキャナーのみを有効化する。チャットボットではプロンプトインジェクションと有害性スキャナーを優先し、文書処理ではPII検出とトピック制限を優先するなど、用途に応じた最適化が重要である。
閾値のチューニングとして、各スキャナーの判定閾値はデフォルト値から運用データに基づいて調整する。特にプロンプトインジェクション検出の閾値は、セキュリティ要件とユーザー体験のバランスを考慮して慎重に設定する。
よくある質問
Q: LLM GuardとNeMo Guardrailsのどちらを選ぶべきですか？
用途と要件に応じて選択する。LLM Guard（Protect AI）は軽量で導入が容易であり、プロンプトインジェクション検出とPII保護を中心としたセキュリティ用途に強い。NeMo Guardrailsは対話フローの制御やトピック制限など、LLMの動作全体をプログラム的に制御する用途に強い。両者を組み合わせることも可能であり、NeMo Guardrailsのフロー制御とLLM GuardのMLスキャナーを併用する構成もある。
Q: Llama GuardはClaude APIやGPT-4と組み合わせられますか？
組み合わせ可能である。Llama Guardは独立した分類モデルとして動作するため、任意のLLM APIの入出力に対してスキャンを適用できる。ただし、Llama Guardの推論にはGPU環境（推奨：NVIDIA A10G以上、VRAM 8GB以上）が必要であり、CPU環境では実用的なレイテンシが確保しにくい。クラウド環境ではAWS SageMaker、Google Cloud Vertex AI、Azure ML上でホスティングする構成が一般的である。
Q: ガードレールの導入によるレイテンシ増加はどの程度ですか？
構成によるが、最小構成（正規表現スキャナー + Prompt Guard）で20〜30ms、標準構成（LLM Guard全スキャナー）で80〜120ms、最大構成（NeMo Guardrails + LLM Guard + Llama Guard）で200〜400msが目安である。チャットボットの体感遅延に影響しない50ms以下を目標とする場合は、軽量スキャナーの選択的適用とGPU推論が推奨される。非同期処理やキャッシュの活用によりレイテンシを削減することも可能である。
Q: オープンソースのガードレールだけで商用利用できますか？
LLM Guard（Apache 2.0）とNeMo Guardrails（Apache 2.0）は商用利用が可能である。Llama Guard 3はLlama 3.1 Community Licenseに基づき、月間アクティブユーザー7億人以下のサービスで商用利用可能である。Prompt GuardはMITライセンスで完全に自由な商用利用が可能である。ただし、SaaS型のLakera Guardは有料サブスクリプションが必要であり、無料枠には制限がある。