まず何から始めるか：評価設計の前提を整理する
評価を始める前に「何を攻撃とみなすか」の定義とリスク分類を確定させることが、精度測定の精度そのものを左右します。定義が曖昧なまま測定を始めると、スコアの解釈がぶれ、チューニングの判断基準も揺らぎます。
攻撃の定義とリスク分類：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日です。
ガードレールの限界と回避攻撃：見落としやすい検証ポイント
既存のガードレールは文字列の変形や多言語混在等の回避攻撃に対して検出率が下がることが、セキュリティ研究の知見として広く確認されており、これを自社テストで再現することが重要です。前セクションで構築した評価環境を使い、通常の攻撃サンプルだけでなく回避攻撃パターンを組み込むことで、ガードレールの実際の耐性を測れます。
回避攻撃の主な手口と自社テストへの組み込み方
回避攻撃とは、ガードレールの検出ロジックを意図的に迂回するよう設計された入力のことです。通常の攻撃サンプルを通過できなかった攻撃者が、検出パターンを崩す変形を加えて再試行するケースが典型です。
自社テストに組み込むべき回避攻撃の主なカテゴリは以下のとおりです。
| カテゴリ | 手口の概要 | テストへの組み込み方 |
|---|---|---|
| 文字列変形 | 同義のUnicode文字、スペースや記号の挿入で検出パターンを崩す | 既存の攻撃サンプルに文字置換・挿入を施したバリアントを5〜10種類生成する |
| 多言語混在 | 攻撃指示の一部を別言語に切り替えて検出を回避する | 日本語攻撃文の核心部を英語・中国語・アラビア語等に差し替えたサンプルを用意する |
| 分割インジェクション | 悪意ある指示を複数ターンに分散して一度の入力では検出されにくくする | マルチターン会話形式のテストケースを別枠で設計し、文脈累積後に攻撃が成立するか確認する |
| ロールプレイ包装 | 「架空のキャラクターとして答えてください」等のフレームで制約を外す | ジェイルブレイクのロールプレイ型バリアントを攻撃サンプルの1カテゴリとして追加する |
| エンコード変形 | Base64やURL符号化で禁止語を隠蔽する | 攻撃文をエンコードしてガードレールのデコード前処理の有無を確認する |
テスト実施上の注意点が2つあります。
バリアントは段階的に追加する。 通常攻撃サンプルで基準スコアを取得してから回避バリアントを投入し、検出率の変化を差分として記録します。最初から混在させると、どのパターンが検出を崩したかの特定が困難になります。
本番データで確認されたパターンを優先する。 実業務ログから収集した実際の入力の中に回避攻撃の萌芽が含まれることがあります。レッドチーム生成サンプルよりも実業務由来のパターンを優先することで、自社環境に即した検証になります。
なお、回避攻撃への対策実装の手順は別記事「LLMガードレール破られる原因と実装可能な3つの対策」で詳しく扱っています。本セクションでは「評価でどう再現するか」に絞り、対策の実装手順には踏み込みません。
過学習がガードレール性能に与える影響と検出方法
過学習とは、モデルがトレーニングデータに含まれるパターンを記憶しすぎた結果、未知のパターンに対して正しく機能しなくなる状態です。ガードレール文脈では「学習済みの攻撃文は検出できるが、微妙に変形した亜種は見逃す」という形で現れます。
過学習が起きているガードレールには、以下の特徴が観察されます。
- 公開ベンチマークのスコアは高いが、自社ログ由来のサンプルに対するRecallが大きく低下する
- 攻撃サンプルを1〜2語変更しただけで検出を回避できる
- 正常入力の文体が学習サンプルと異なる業務文書で誤検知率が上昇する
自社評価でこれを検出するには、テストデータを「学習データと分布が近いセット」と「学習データから意図的に乖離させたセット」に分けて、両者のF1スコアを比較します。差が大きいほど過学習の影響を受けている可能性が高いと判断できます。
具体的な手順は以下の3ステップです。
分布内テスト（In-distribution）の実施。 公開ベンチマークや学習元に近い攻撃サンプルでスコアを算出し、ベースラインとして記録します。つまずきやすい点として、ここでスコアが高いだけで「評価完了」と判断するケースが多いため注意が必要です。
分布外テスト（Out-of-distribution）の実施。 文字変形・多言語混在・業務固有の表現を組み込んだサンプルで同じ指標を算出します。所要時間の目安はサンプル準備込みで半日程度です。
スコア差の記録と閾値判定。 F1スコアの差が0.10を超える場合、過学習の影響がある可能性として記録します。この数値はベンダや研究によって異なるため、自社で継続的にモニタリングしながら判断基準を調整してください。
過学習を防ぐための実装上のステップは「LLM攻撃検出の機械学習モデル、過学習を防ぐ3つのステップ」で詳しく解説しています。本記事では評価での検出方法に絞って言及しています。
評価結果の解釈と改善サイクルの回し方
スコアが出た後に「どの攻撃カテゴリで検出が漏れているか」をカテゴリ別に分解することで、チューニングの優先順位が明確になります。数値を全体集計で見るだけでは、深刻な弱点が平均値に埋もれるリスクがあります。
カテゴリ別エラー分析：どこで検出が崩れているかを可視化する
全体のF1スコアが高くても、特定の攻撃カテゴリに集中してFalse Negativeが発生している場合があります。カテゴリ別に集計することで、チューニングのターゲットを絞れます。
分析手順
- セクション4で収集したログを攻撃カテゴリ（プロンプトインジェクション、ジェイルブレイク、機密情報抽出など）でタグ付けする。つまずきやすい点：ログにカテゴリラベルが含まれていない場合、テスト投入時にメタデータとして付与しておく必要があります。
- カテゴリごとにPrecision・Recall・F1を個別集計する。全体集計と並べて比較表を作成する。
- Recallが特に低いカテゴリを「優先チューニング対象」として特定する。
- 優先対象カテゴリのFalse Negativeサンプルを抽出し、ガードレールが検出を外した理由を目視でラベル付けする。
カテゴリ別集計表の例
| 攻撃カテゴリ | Precision | Recall | F1 | 優先度 |
|---|---|---|---|---|
| プロンプトインジェクション（直接） | 0.91 | 0.88 | 0.89 | 中 |
| プロンプトインジェクション（間接） | 0.84 | 0.61 | 0.71 | 高 |
| ジェイルブレイク | 0.79 | 0.55 | 0.65 | 高 |
| 機密情報抽出 | 0.93 | 0.90 | 0.91 | 低 |
| 有害コンテンツ生成 | 0.88 | 0.82 | 0.85 | 中 |
※上表は分析フォーマットの例示です。実際の数値は御社の構成と閾値設定によって異なります。
False Negativeの原因分類は、次の3つに絞ると整理しやすくなります。
- 表現バリアントの未対応: 攻撃の言い回しが学習済みパターンと乖離している
- 文脈依存の検出漏れ: 単文では無害だが会話フロー全体では攻撃意図を持つケース
- 閾値設定の問題: スコアは高いが閾値を超えていなかったケース
原因ラベルの比率を集計すると、「閾値調整で解決できる問題」と「追加学習や辞書拡充が必要な問題」を峻別できます。前者はコストが低く即対応が可能で、後者は改善工数の見積もりが必要です。
継続評価の頻度設計：モデル更新・運用変更のたびに再評価が必要な理由
ガードレールの精度は一度評価すれば固定ではありません。LLM本体のモデル更新、プロンプトテンプレートの変更、ユーザの利用パターンの変化のいずれもが検出精度を変動させる要因になります。
再評価が必要になるトリガ
| トリガ | 再評価の範囲 | 目安の所要時間 |
|---|---|---|
| LLM本体のモデルバージョン更新 | 全カテゴリのフルテスト | 1〜2日 |
| プロンプトテンプレートの変更 | 変更が影響する層のみ | 半日 |
| ガードレールのルール・辞書更新 | 該当カテゴリのみ | 2〜4時間 |
| 新しい攻撃手法の観測（外部レポート等） | 該当カテゴリのみ | 2〜4時間 |
| 定期評価（変更がない場合） | 全カテゴリのフルテスト | 月1回を目安 |
変更がないように見える場合でも、月1回程度のフルテストを組み込んでおくことを推奨します。攻撃手法は外部で継続的に進化しており、ガードレールの適用外パターンが蓄積されるリスクがあるためです。
改善サイクルの構造
改善は以下のループで回すと、属人化を防いで組織的に継続できます。
- 評価実施: テストデータを投入してスコアを集計する
- エラー分析: カテゴリ別にFalse Negativeの原因をラベル付けする
- 優先度設定: リスク分類とRecallの低さを掛け合わせてチューニング対象を決める
- チューニング実施: 閾値調整・辞書拡充・ルール追加のいずれかを適用する
- 再評価: 変更箇所を対象に再テストし、改善効果を定量確認する
- ドキュメント更新: 評価レポートと変更履歴を記録し、次サイクルの比較基盤にする
このループを回す際の実装上の注意点として、チューニング前後のスコアを必ず同一テストセットで比較することが挙げられます。テストデータ自体を変えてしまうと、改善効果なのかサンプル差異なのかが判別できなくなります。
評価設計、テストデータ構築、閾値チューニングまで一貫して内製で対応するには一定のエンジニアリングリソースが必要です。体制整備が難しい場合の外部依頼基準については、次のセクションで整理します。
自社評価が難しいと感じたら：外部実装者への依頼基準
評価設計・テストデータ構築・閾値チューニングまで一貫して対応できるかどうかが、外部パートナー選定の最低ラインです。
LLMガードレールの評価は、指標の選定からテストデータの設計、ログ解析、閾値調整まで、複数の専門領域が交差する作業です。社内にMLエンジニアや情報セキュリティの実務経験者がいない場合、評価そのものの精度が担保されないリスクがあります。外部に依頼する判断基準を明確に持っておくことで、コストと品質のバランスを取れます。
外部依頼を検討すべき状況
以下のいずれかに当てはまる場合、自社評価に限界が生じやすくなります。
- テストデータセットを自社で用意できない。業務ログから攻撃サンプルを抽出する手順（セクション3参照）が実行できない、または社内に判断できる人員がいない場合。
- Precision・Recall・F1の解釈を評価レポートとして出力できない。スコアは計算できても、どのカテゴリで検出が崩れているかを分解できない場合（セクション6参照）。
- 回避攻撃の再現テストが設計できない。文字変形や多言語混在など、ガードレールを迂回するパターンを自社で作成・投入できない場合（セクション5参照）。
- モデル更新のたびに評価が止まる。継続評価のサイクルを回す人員・プロセスが社内に確立されていない場合。
外部パートナーに確認すべき5項目
依頼先候補に対して、以下を必ず確認してください。提案書や営業トークではなく、具体的な実績と手順を問うことが重要です。
| 確認項目 | 確認すべき内容 | 注意点 |
|---|---|---|
| 評価設計の経験 | 攻撃カテゴリ別のテストデータを自ら構築した実績があるか | 「コンサル支援のみ」の場合は実装経験と区別する |
| 指標の運用実績 | Precision・Recall・F1を用いた閾値チューニングを自ら実施したか | レポート作成代行と実装は別物 |
| 回避攻撃への対応 | プロンプトインジェクションの変形バリアントを含めたテストを実施できるか | 既成ツールの実行のみか、設計から対応できるかを確認する |
| ログ設計の可否 | 各層（入力・処理・出力）の判定根拠をログに記録する設計ができるか | ログ設計なしでは再現性のある継続評価が成立しない |
| 継続対応の可否 | モデル更新時・運用変更時の再評価を継続契約で対応できるか | 初回のみ対応して終わりでは、評価サイクルが機能しない |
「コンサル」と「実装者」を区別する理由
LLMガードレールの評価において、アドバイスを提供するコンサルと、実際にコードを書いて検証する実装者では役割が根本的に異なります。
閾値チューニングはパラメータをコードで変更して再テストを回す作業であり、評価レポートを読むだけでは完結しません。依頼先が「ガードレールのロジックを自ら変更し、テストを再実行した経験があるか」を確認することが、選定の実質的な基準になります。
当社ノーティックラボでは、RAGやFine-tuning等のLLM実装を代表自身が担当しており、ガードレールの評価設計からテストデータ構築・閾値チューニングまでを一貫して実施しています。「自社評価を試みたが途中で止まった」「何から外注すべきか整理したい」という段階からご相談いただけます。
まず御社のLLM活用状況と課題を無料診断でお聞きします。[無料診断を受ける（/diagnostic）]