まず何から始めるか：評価設計の前提を整理する
評価を始める前に「何を攻撃とみなすか」の定義とリスク分類を確定させることが、精度測定の精度そのものを左右します。定義が曖昧なまま測定を始めると、スコアの解釈がぶれ、チューニングの判断基準も揺らぎます。
攻撃の定義とリスク分類：OWASP LLM Top 10 2025の活用
攻撃カテゴリの基準として、まずOWASP GenAI Security Projectの分類を参照することを推奨します。
2025年版「OWASP Top 10 for LLM Applications」では、プロンプトインジェクションがリスク第1位（LLM01:2025）に位置づけられています。同文書はプロンプトインジェクションを「直接インジェクション」と「間接インジェクション」の2カテゴリに分類しており、自社の評価テストセットを設計する際のカテゴリ基準として直接活用できます（出典: OWASP GenAI Security Project「LLM01:2025 Prompt Injection」）。
| 攻撃カテゴリ | 概要 | 自社評価での優先度 |
|---|---|---|
| 直接インジェクション | ユーザが入力フォームに悪意ある命令を直接送り込む | 高（最初に評価すべき） |
| 間接インジェクション | 外部データソースや添付ファイル経由で命令が混入する | 高（見落とされやすい） |
| ジェイルブレイク | システムプロンプトの制約をロールプレイ等で突破する | 中 |
| データ漏洩誘導 | システムプロンプトや学習データを引き出す | 中 |
| 有害コンテンツ生成 | フィルタ対象のコンテンツを迂回して生成させる | リスク許容度に応じて設定 |
OWASPの分類に加え、国内の一次資料としてIPA（独立行政法人情報処理推進機構）の「テキスト生成AIの導入・運用ガイドライン」（2024年7月）も参照する価値があります。同ガイドラインはプロンプトインジェクションへの運用対策を具体的に記載しており、社内規程の策定根拠として使用できます（出典: IPA「テキスト生成AIの導入・運用ガイドライン」2024年7月）。
OWASPとIPAの分類を社内リスク分類に落とし込んだ上で、評価対象とする攻撃カテゴリを文書化します。この文書が、後の評価スコアを解釈する際の「測定の前提」になります。
評価スコープの決め方：入力層・処理層・出力層のどこを測るか
評価スコープは「入力層・処理層・出力層」の3層で切り分けると、測定対象が明確になります。
この3層設計は特定ベンダー独自の概念ではなく、業界標準ツールが採用する構成です。NVIDIA NeMo Guardrailsは、入力レール（Input Rails）・対話レール（Dialog Rails）・出力レール（Output Rails）という多層インターセプト構造を公式に実装しており、入力チェックと出力チェックには同一コンポーネントが前後で動作します（出典: NVIDIA NeMo Guardrails 公式ドキュメント）。同ツールはGitHubで6,500以上のスターを獲得しており、実務での採用実績が確認できます（出典: OpenLegion「AI Guardrails: Input/Output Controls, Platform Enforcement, and LLM Safety」）。
各層で評価すべき内容は以下のとおりです。
| 層 | 評価対象の主な機能 | 測定対象の攻撃 |
|---|---|---|
| 入力層 | コンテンツモデレーション、インジェクション検知 | 直接インジェクション、ジェイルブレイク |
| 処理層 | 会話フロー制御、トピック逸脱検知 | 多段階の誘導攻撃 |
| 出力層 | スキーマ検証、関連性チェック、有害コンテンツフィルタ | 間接インジェクション経由の情報漏洩、幻覚誘導 |
Datadogのベストプラクティスでは、出力層でのスキーマ検証と関連性チェックが、曖昧な入力や幻覚によってLLMが担当領域から逸脱するケースへの対処に有効であると示されています（出典: Datadog）。
評価スコープを3層で定義した後は、自社システムのどの層にガードレールが実装されているかをアーキテクチャ図と照合します。実装されていない層があれば、そこは評価対象ではなくリスク未対処領域として別途記録します。
実装者視点の注意点: 間接インジェクション（添付ファイルや外部データソース経由）はスコープから外れやすく、入力層のみを評価した場合に検出漏れが生じます。日経クロステックの検証では、論文PDF内に埋め込んだ秘密プロンプトでガードレールを回避できるケースが実証されています（出典: 日経クロステック「LLMのガードレールは万能か、『論文PDF内の秘密プロンプト』で検証」 ※有料記事の可能性あり）。RAGや外部ツール連携を使用している場合は、処理層・出力層を必ずスコープに含めてください。
3層の評価スコープを定義した後、各層に対応する評価指標の選び方を次のセクションで整理します。
評価指標の選び方：精度・再現率・F1スコアをどう使うか
攻撃検出の評価には精度（Precision）と再現率（Recall）の両方が必要で、どちらを優先するかはシステムのリスク許容度によって決まります。どちらか一方だけを見ると、現場で起きているリスクを見誤る可能性があります。
Precision・Recall・F1の定義と攻撃検出文脈での意味
この3指標は、ガードレールが「どれだけ正確に攻撃を識別できているか」を異なる角度から測るものです。
| 指標 | 計算式 | 攻撃検出における意味 |
|---|---|---|
| Precision（精度） | TP ÷ (TP + FP) | 「攻撃と判定したうちの何割が本当の攻撃か」。高いほど誤検知が少ない |
| Recall（再現率） | TP ÷ (TP + FN) | 「実際の攻撃のうち何割を検出できたか」。高いほど見逃しが少ない |
| F1スコア | 2 × (Precision × Recall) ÷ (Precision + Recall) | PrecisionとRecallの調和平均。両指標のバランスを1つの数値で表す |
用語を補足します。TP（True Positive）は攻撃を正しく攻撃と判定したケース、FP（False Positive）は正常入力を誤って攻撃と判定したケース、FN（False Negative）は攻撃を見逃したケースを指します。
セクション1で整理した評価スコープの3層（入力層・処理層・出力層）ごとに、この3指標をそれぞれ計算することを推奨します。層をまたいで集計すると、どこで検出が崩れているかの特定が困難になります。
なお、OWASP GenAI Security Projectの「Top 10 for LLM Applications 2025」では、プロンプトインジェクションがリスク第1位（LLM01:2025）に位置づけられています（出典: OWASP GenAI Security Project「LLM01:2025 Prompt Injection」）。この分類を踏まえると、プロンプトインジェクション単体のRecallは、F1スコアとは別に必ず単独で把握しておくべき指標です。
False Negativeを重視すべき場面とFalse Positiveを重視すべき場面
どちらのエラーを優先して抑えるかは、システムの用途と被害規模によって変わります。
False Negative（見逃し）を優先して抑えるべき場面
- 機密情報や個人情報を扱うシステム（情報漏えいの被害が不可逆的）
- 外部公開済みのチャットボットや顧客対応AIの場合（攻撃の成功が即座に外部へ影響する）
- コンプライアンス要件として「未検出ゼロ」が求められる業種（金融、医療等）
この場合はRecallを最優先の指標とし、閾値を下げ方向に調整します。ただし、閾値を下げるとFalse Positiveが増加するため、正常な業務リクエストの遮断率を別途モニタリングしてください。
False Positive（誤検知）を優先して抑えるべき場面
- 社内限定の情報検索ツールや業務アシスタントの場合（攻撃の機会が限られており、過剰遮断が業務を止める）
- ユーザが頻繁に専門用語や複雑なクエリを入力する環境（誤検知が続くと利用率が下がる）
この場合はPrecisionを主指標とし、F1スコアで下限を設定しながらバランスを調整します。
実務上の注意点として、F1スコアは正常入力と攻撃入力の比率（クラス比率）が大きく偏るとスコアが実態を反映しにくくなります。クラス不均衡の扱い方については、次のセクション「テストデータセットの作り方」で詳しく取り上げます。
テストデータセットの作り方：攻撃サンプルをどう用意するか
公開ベンチマークだけに頼ると自社環境との乖離が生じるため、実業務ユースケースに沿った独自の攻撃サンプルを必ず混在させる必要があります。どれほど優れたガードレール製品を導入しても、評価データが実環境と乖離していれば、スコアは机上の数値にとどまります。
プロンプトインジェクション・ジェイルブレイク等の攻撃カテゴリ別サンプル収集
テストデータを設計する前に、収集すべき攻撃カテゴリを整理します。セクション1で整理したOWASP LLM Top 10 2025の分類を起点に、自社システムの入力層・処理層・出力層の各スコープに対応するカテゴリを選定してください。
実務でよく使われるオープンソースのガードレールフレームワークとして、NVIDIA NeMo GuardrailsとGuardrails AIの2つが参照点になります。NVIDIA NeMo GuardrailsはGitHubで6,500スター以上を獲得しており（出典：OpenLegion「AI Guardrails: Input/Output Controls, Platform Enforcement, and LLM Safety」）、入力レール・出力レールの多層構成を公式に実装しています。Guardrails AIは2024年9月にシリーズAで750万ドルを調達し、コミュニティ製バリデータが500件以上公開されています（出典：同上）。これらのバリデータは攻撃カテゴリの整理と、サンプル収集の参照先として活用できます。
収集する攻撃カテゴリと、各カテゴリで最低限用意すべきサンプルの種類を以下に示します。
| 攻撃カテゴリ | サンプルの種類（例） | 対応評価スコープ |
|---|---|---|
| 直接プロンプトインジェクション | 「前の指示を無視して〜」等の命令上書き | 入力層 |
| 間接プロンプトインジェクション | 外部ドキュメントや検索結果に埋め込まれた命令 | 処理層（RAG） |
| ジェイルブレイク | ロールプレイや仮説フレームを用いた制約回避 | 入力層・出力層 |
| 機密情報抽出 | システムプロンプトの漏えいを狙う入力 | 出力層 |
| 有害コンテンツ生成誘導 | 暴力・詐欺・差別的表現の生成を促す入力 | 出力層 |
| 領域逸脱 | 自社サービス範囲外の業務指示（例：法律相談、医療判断） | 出力層 |
各カテゴリのサンプルを収集する際は、次の3つのソースを組み合わせることが現実的です。
- 公開ベンチマーク：HarmBench、AdvBench、JailbreakBenchなどのオープンデータセットから参照する。多言語対応や日本語での攻撃には別途サンプルが必要な点に注意が必要です。
- 実業務ログ：本番環境のユーザ入力ログから、異常なパターンや境界ケースを手動で抽出する。個人情報を含む場合は匿名化を先に行います。
- レッドチーム手動生成：担当者が攻撃者の視点でサンプルを作成する。自社システムの業務ドメイン（例：社内FAQボット、契約書レビュー補助）に特化した攻撃文を作れる点が最大のメリットです。
技術的にハマりやすい点：間接プロンプトインジェクション（RAG経由の攻撃）のサンプルは、検索対象のドキュメント内に攻撃指示を埋め込む形式になるため、単純な入力フィールドへの投入とは異なるテスト実施環境が必要です。RAGを組み込んでいる場合は、処理層の評価を独立したテストシナリオとして設計してください。詳しい実施手順はセクション4で説明します。
正常入力と攻撃入力の比率設計：クラス不均衡に注意すべき理由
クラス不均衡とは、正常サンプルと攻撃サンプルの数の差が極端に大きい状態を指します。本番環境では攻撃入力は全体の数%以下であることが多く、テストデータでもこの比率を再現しすぎると、評価指標が歪む原因になります。
具体的には、攻撃サンプルが全体の2〜3%しかない状態でテストを行うと、ガードレールが「すべての入力を正常と判定する」だけで精度（Accuracy）が97〜98%になります。セクション2で説明したPrecision・Recall・F1を正しく機能させるには、評価用データセット内の攻撃サンプル比率をある程度意図的に高める必要があります。
評価フェーズ別の推奨比率設計を以下にまとめます。
| 評価フェーズ | 正常入力 | 攻撃入力 | 設計意図 |
|---|---|---|---|
| 初回評価（機能確認） | 50% | 50% | ガードレールが各カテゴリを検出できるか機能レベルで確認する |
| 精度評価（閾値チューニング） | 70% | 30% | Precision・Recall・F1を安定して計算できる最小サンプル数を確保する |
| 本番近似評価（実環境シミュレーション） | 90〜95% | 5〜10% | 実環境に近い条件でFalse PositiveとFalse Negativeを同時に測定する |
各フェーズで比率を切り替える理由は、目的が異なるからです。初回は「検出できるか」を確認し、精度評価では「どの指標がどの程度か」を測定し、本番近似評価では「実運用でどう振る舞うか」を検証します。3フェーズを一度に兼ねようとして単一の比率で進めると、どの目的も中途半端な結果になります。
攻撃カテゴリごとのサンプル数についても注意が必要です。カテゴリ間でサンプル数が大きく偏ると、カテゴリ別エラー分析（セクション6で後述）の結果が信頼できなくなります。各カテゴリで最低20〜30サンプルを確保することを目安としてください（案件の規模や攻撃カテゴリ数によって変動します）。
当社の実装経験では、初回評価でサンプル比率を考慮せずに進めた結果、Recall が見かけ上90%を超えているにもかかわらず、特定カテゴリ（間接インジェクション）の検出率が実質ゼロだったケースがありました。カテゴリ別の内訳を集計して初めて問題が発覚します。比率設計と同時に、カテゴリ別のサンプル数を評価計画書に明記することを強く推奨します。
評価の実施手順：5ステップで進めるテスト実行
評価は「環境準備→サンプル投入→ログ取得→スコア集計→閾値調整」の5ステップで構造化すると、再現性を持たせられます。各ステップに担当者と完了条件を設けておくことが、評価品質のばらつきを防ぐ最短経路です。
ステップ1〜2：テスト環境の分離とサンプル投入の注意点
ステップ1：テスト環境を本番から切り離す
本番環境でテストを実施すると、攻撃サンプルの投入ログが実ユーザのデータと混在し、後工程のスコア集計が汚染されます。必ずステージング環境またはサンドボックスを用意してください。
チェックポイントは以下の3点です。
- ガードレールのバージョンを本番と揃えてある（差分があると評価結果が本番に適用できない）
- ログ出力先が本番DBと分離されている
- テスト用APIキーを発行し、本番トラフィックと識別できるようにしてある
技術的にハマりやすい点： ステージング環境でモデルのエンドポイントだけ差し替えて、ガードレールの設定ファイルは本番のものをコピーし忘れるケースが多発します。環境変数とコンフィグファイルの両方を照合してから投入を開始してください。所要時間の目安は半日です。
ステップ2：サンプルを構造化して投入する
前セクションで設計した攻撃サンプルと正常サンプルを、カテゴリと期待ラベル（攻撃/正常）を付与したCSVまたはJSONL形式で管理します。投入は手動ではなくスクリプトで自動化し、投入順序をランダム化することでガードレールの順序依存バイアスを排除します。
投入時に記録すべき最小フィールドは以下の通りです。
| フィールド名 | 内容 | 記録が必要な理由 |
|---|---|---|
| sample_id | サンプルの一意ID | スコア集計時の突合キー |
| category | 攻撃カテゴリ（例: prompt_injection） | カテゴリ別エラー分析に使用 |
| expected_label | 攻撃(1) / 正常(0) | TP・FP・FN・TNの算出基準 |
| input_text | 投入したプロンプト原文 | 誤検知・見逃しの原因分析に使用 |
| timestamp | 投入日時 | 再現性確認と環境変化の追跡に使用 |
所要時間の目安は、サンプル数200件程度であれば1〜2時間です。
ステップ3〜5：ログ設計・スコア集計・閾値チューニングのポイント
ステップ3：ログ設計でガードレールの判定根拠を残す
ガードレールが「なぜそのサンプルを攻撃と判定したか（またはしなかったか）」を後から追えるログ設計が不可欠です。Datadogのテクニカルブログ（datadoghq.com/blog/llm-guardrails-best-practices/）は、入力バリデーション・出力サニタイジング・継続的モニタリングの三層構造でログを設計し、ルールベースと統計ベースの手法を併用することを推奨しています。
具体的には、ガードレールの各層（ルールベースフィルタ・分類器・出力チェック）ごとにスコアと判定理由をログに出力する構成にします。単一の「判定結果」だけを記録すると、どの層で検出が崩れているかを後から特定できなくなります。
つまずきやすい点： 商用ガードレール製品の中には、判定根拠のスコアをAPIレスポンスに含めず、「ブロック/通過」の二値だけを返すものがあります。この場合、製品のダッシュボードや別途提供される詳細ログエンドポイントを確認してください。
所要時間の目安は、ログ設計の定義に1日、実装に半日です。
ステップ4：スコア集計でPrecision・Recall・F1を算出する
ログを突合し、サンプルごとにTP（真陽性）・FP（偽陽性）・FN（偽陰性）・TN（真陰性）を分類します。集計後、以下の式でスコアを算出します。
| 指標 | 計算式 | 着目する問い |
|---|---|---|
| Precision（精度） | TP ÷ (TP + FP) | 「攻撃と判定したもののうち本当に攻撃だったか」 |
| Recall（再現率） | TP ÷ (TP + FN) | 「実際の攻撃をどれだけ漏らさず検出できたか」 |
| F1スコア | 2 × (Precision × Recall) ÷ (Precision + Recall) | 両者のバランス |
集計はカテゴリ別に必ず分けてください。全体F1が高くても、特定の攻撃カテゴリでRecallが著しく低いケースはよく起こります。スコアの解釈方法は後続のセクションで詳述します。
埋め込みベース（embedding-based）の分類器を自社ガードレールに採用している場合、意味的類似性を利用したアプローチがキーワードマッチングより頑健な検出を実現する可能性があることが示されています（出典：「Embedding-based classifiers can detect prompt injection attacks」、arxiv.org/pdf/2410.22284、2024年10月公開）。ただし、同論文はアダプティブ攻撃（検出器の挙動を逆手に取った攻撃）には脆弱になりうるとも指摘しており、集計結果でこの系統のFNが多い場合は分類器の種別を確認することを推奨します。
所要時間の目安は1〜2時間です。PythonのsciPyまたはscikit-learnのclassification_report関数を使うと、カテゴリ別の集計を一括出力できます。
ステップ5：閾値チューニングで検出感度を調整する
多くのガードレールは、内部的に「攻撃らしさスコア」を持ち、閾値（threshold）を超えた入力をブロックします。閾値を下げると検出漏れ（FN）は減りますが、誤検知（FP）が増えます。逆に閾値を上げると誤検知は減りますが、検出漏れが増えます。
チューニングの手順は以下の通りです。
- 現状の閾値でPrecision・Recall・F1を確認する
- Recall優先（情報漏えいリスクが高い場面）であれば閾値を0.05〜0.1単位で段階的に下げ、スコアの変化を記録する
- Precision優先（業務支障が大きい場面）であれば閾値を段階的に上げて同様に記録する
- PR曲線（Precision-Recall Curve）をプロットし、御社のリスク許容度に合うバランス点を選定する
- 変更後の閾値で全サンプルを再評価し、最終スコアを確定する
IPAは2024年9月25日に「AIセーフティに関するレッドチーミング手法ガイド」を公開しており（出典：IPA プレスリリース、ipa.go.jp/pressrelease/2024/press20240925.html）、LLMを含むAIシステムの安全性を体系的に評価するための手順が整備されています。閾値チューニング後の検証プロセスにこのガイドを照合することで、評価の抜け漏れを確認できます。
また、2025年4月にarXivに公開された論文「Bypassing LLM Guardrails: An Empirical Analysis of Evasion Attacks against Prompt Injection and Jailbreak Detection Systems」（arxiv.org/abs/2504.11168）では、文字置換や言語切り替えといったシンプルな変換でもガードレールの検出をすり抜けるケースが実証的に報告されています。閾値を最適化した後でも、こうした回避攻撃に対してスコアが保たれているかを確認することが不可欠です。回避攻撃への対応については次のセクションで詳述します。
つまずきやすい点： 閾値は「一度決めたら固定」ではありません。モデルのアップデートや業務フローの変更のたびに再チューニングが必要です。閾値の変更履歴をバージョン管理に含めておかないと、過去の評価との比較ができなくなります。
所要時間の目安は、初回チューニングで半日〜1日です。