セキュリティ用途の分類器で過学習が特有の問題になる理由
過学習とは、モデルが訓練データのノイズやパターンを記憶してしまい、未知のデータに対する汎化性能が低下する現象です（出典: 野村総合研究所「過学習（オーバーフィッティング）」）。セキュリティ用途では「攻撃パターンが継続的に変化する」という特性があるため、一般的な分類タスクよりも過学習のリスクが構造的に高くなります。
攻撃検出分類器が過学習した場合、既知の攻撃文字列には高精度で反応できても、わずかに変形された新しい攻撃には無反応になります。これは誤検出率が低いまま検出漏れだけが増える、という運用上もっとも発見しにくい障害パターンです。
攻撃検出分類器が過学習しやすい3つの理由
1. 正例データが構造的に偏る
攻撃データは「収集できた攻撃」に限定されます。インターネット上で流通している既知のジェイルブレイクプロンプトを中心に訓練データを構築すると、モデルはそのフォーマットや語彙の癖を学習し、表層的な特徴を根拠に判定するようになります。
2. クラス不均衡が正則化を阻害する
実運用では正常入力に対して攻撃入力の比率が小さくなります。クラス不均衡の状態でデータを増やさずに学習を続けると、モデルは多数クラス（正常）側に最適化され、少数クラス（攻撃）を訓練データの特定パターンに頼って識別するようになります。
3. 攻撃の進化速度が評価サイクルを上回る
2025年4月にarXivで公開された実証分析論文（Bypassing LLM Guardrails: An Empirical Analysis of Evasion Attacks against Prompt Injection and Jailbreak Detection Systems、arxiv.org/abs/2504.11168）は、文字置換や言語切り替えといったシンプルな変換でも既存のガードレール製品の検出をすり抜けるケースがあることを報告しています。訓練時に想定していなかった変換パターンが実環境で現れた瞬間、過学習した分類器は判定根拠を失います。
過学習の兆候を示す評価指標の読み方
訓練精度と検証精度の乖離が過学習の典型指標ですが、攻撃検出分類器ではさらに以下の組み合わせで確認する必要があります。
| 指標 | 過学習時の典型的な動き | 注目すべき理由 |
|---|---|---|
| 訓練F1スコア | 高水準を維持 | 表面上は「良好」に見える |
| 検証F1スコア | 訓練との乖離が拡大 | 汎化の劣化を最初に示す |
| 偽陰性率（FNR） | 検証データで上昇 | 攻撃を見逃す頻度の指標 |
| OOD（Out-of-Distribution）テスト精度 | 大幅に低下 | 未知攻撃への耐性を直接測定する |
偽陽性率（FPR）だけを監視していると、過学習の発生に気づきにくくなります。正常入力を誤検出する頻度が低くても、新規の攻撃を見逃す頻度は独立して増加しうるためです。
評価指標の設計としては、訓練データと時期的に分離したホールドアウトセット（テンポラルスプリット）を用意することが有効です。同一時期のデータをランダム分割しただけでは、攻撃パターンの時系列的な変化を検出できません。この点については、後述の「過学習を防ぐ実装手順」セクションで分割方法を具体的に説明します。
2024年10月にarXivで公開された論文「Embedding-based classifiers can detect prompt injection attacks」（arxiv.org/pdf/2410.22284）は、テキストの意味的類似性を利用した埋め込みベース分類器が表層的なキーワードマッチングよりも頑健な検出を実現できる可能性を示しています。ただし同論文は、この手法もアダプティブ攻撃（検出器の挙動を踏まえて設計された攻撃）には脆弱になりうる点を明示しており、単一の防御手法への依存に対して慎重な姿勢を促しています。
ガードレールの検証プロセスについては、IPA（情報処理推進機構）が2024年9月25日に「AIセーフティに関するレッドチーミング手法ガイド」を公開しており（出典: IPA プレスリリース、ipa.go.jp/pressrelease/2024/press20240925.html）、LLMを含むAIシステムの安全性を体系的に評価するための手順が整備されています。過学習した分類器の盲点を組織的に洗い出す際の参照点として活用できます。
まず何から始めるか：攻撃検出分類器の構築ステップ概観
攻撃検出分類器の構築は「データ収集」ではなく「検出スコープの定義」から始めます。スコープが曖昧なままデータを集めると、後工程で過学習の温床となるラベル設計の矛盾が生じます。
検出スコープとラベル設計の落とし穴
ラベル設計の誤りは、過学習の最も見えにくい起点です。
LLMガードレールとは、プロンプトインジェクションやジェイルブレイクといった悪意ある入力を検出・遮断する制御機構を指します。機械学習ベースの分類器がその中核を担うケースが増えていますが、「何を攻撃と定義するか」を先に決めなければ、どれだけデータを集めても一貫したラベルは付けられません。
実装の現場でよく見られる失敗は、次の2つです。
- ラベルの揺らぎ: アノテータが「攻撃」と「グレーゾーン」を主観で区別し、同じ入力が時期によって異なるラベルを持つ
- スコープの後付け拡張: 稼働後に検出対象を追加し、旧ラベルと新ラベルが混在したまま再学習する
どちらも訓練データに矛盾が生まれ、モデルは「真のパターン」ではなく「ラベリングの癖」を学習します。これが過学習の温床になります。
2025年4月にarXivで公開された「Bypassing LLM Guardrails: An Empirical Analysis of Evasion Attacks against Prompt Injection and Jailbreak Detection Systems」（arxiv.org/abs/2504.11168）は、文字置換や言語切り替えといったシンプルな変換でも既存のガードレールが回避されるケースを実証しています。スコープ定義が甘いまま構築された分類器が、こうした変形に無力である理由の一端はラベル設計の問題にあります。
データ収集前に決める3つの判断軸
データを集め始める前に、以下の3点を文書として明文化します。口頭合意では後に解釈が割れます。
| 判断軸 | 決める内容 | つまずきやすい点 |
|---|---|---|
| ①検出対象の定義 | 何を「攻撃」と呼ぶか（プロンプトインジェクション、ジェイルブレイク、その他） | 境界事例（ambiguous case）の扱いを決め忘れる |
| ②クラス構成 | 二値分類（攻撃/正常）か多クラス分類（攻撃種別ごと）かの選択 | 多クラスにした場合のクラス不均衡対策を後回しにする |
| ③評価指標の優先順位 | 偽陰性（見逃し）と偽陽性（誤検出）のどちらを重視するか | ビジネス要件と技術指標を対応させないまま設計を進める |
セキュリティ用途では、一般に偽陰性（攻撃を見逃す）のコストが偽陽性（正常を遮断する）より高くなります。しかし「偽陰性を下げる」ために閾値を下げすぎると、正常ユーザへの影響が許容範囲を超えます。この優先順位をステークホルダーと合意した上で、初めてデータ収集に移ります。
2024年10月にarXivで公開された「Embedding-based classifiers can detect prompt injection attacks」（arxiv.org/pdf/2410.22284）は、テキストの意味的類似性を用いた埋め込みベースのアプローチが表層的なキーワードマッチングより頑健な検出を実現できる可能性を示しています。ただし同論文は、アダプティブ攻撃に対しては依然として脆弱になりうるとも指摘しています。どのアーキテクチャを選択するにしても、スコープ定義と評価指標の合意が先行している必要があります。
また、IPA（情報処理推進機構）は2024年9月25日に「AIセーフティに関するレッドチーミング手法ガイド」を公開しています（ipa.go.jp/pressrelease/2024/press20240925.html）。ガードレールの検出スコープを検証する際の参照資料として活用できます。スコープを定義したら、レッドチーミングの観点でその定義に抜け穴がないかを確認するステップを設計フェーズに組み込むことを推奨します。
構築ステップ全体の流れは以下のとおりです。過学習はどのステップでも発生しうるため、各ステップの出口に検証ゲートを設けることが重要です。詳細な実装手順は後述のセクション「過学習を防ぐ実装手順：5ステップのアプローチ」で解説します。
- 検出スコープの定義（本セクション）: ラベル定義・クラス構成・評価指標の合意
- データ収集と前処理: 攻撃サンプルと正常サンプルの収集、アノテーション品質管理
- モデル選択とベースライン構築: アーキテクチャの選択、初期精度の確認
- 過学習診断: 訓練精度と検証精度の乖離、OODテストの実施
- 再学習サイクルの設計: 定期更新の仕組みとトリガー条件の設定
過学習とは何か：セキュリティ用途の分類器で特有の問題
過学習とは、モデルが訓練データのノイズやパターンを記憶してしまい、未知の攻撃に汎化できなくなる状態です。セキュリティ用途では「攻撃パターンが継続的に変化する」という特性があるため、一般的な分類タスクよりも過学習のリスクが高くなります。
攻撃検出分類器が過学習しやすい3つの理由
攻撃検出用の分類器は、構造的に過学習へ傾きやすい条件がそろっています。以下の3点が主要因です。
| # | 要因 | なぜ問題になるか |
|---|---|---|
| 1 | 正例データの分布の偏り | 攻撃サンプルは人間が手作りするため、特定の言い回しや語彙に偏る。モデルはその癖を「攻撃の本質」と誤学習する |
| 2 | クラス不均衡 | 実運用ログでは正常トラフィックが圧倒的多数を占め、攻撃サンプルは希少。少数クラスの過学習が起きやすい |
| 3 | 攻撃の進化速度 | 攻撃者は検出器の反応を観察しながら手口を変える。訓練データが現時点の攻撃に最適化されるほど、次の変形に弱くなる |
一般的な画像分類やテキスト分類では、訓練データの分布と実環境の分布が大きくずれることは少ないです。しかし攻撃検出では、訓練後に攻撃側が分布を意図的にシフトさせてくる点が本質的に異なります。
過学習の兆候を示す評価指標の読み方
「訓練精度が高いのに本番で精度が落ちる」という現象は、過学習の典型的なシグナルです。ただし、セキュリティ用途では単純な精度（Accuracy）だけを見ると見落としが生じます。
確認すべき指標と、その読み方を整理します。
注目すべき指標
- 偽陰性率（FNR）: 攻撃を「安全」と誤判定する割合。攻撃が通過してしまうことを意味するため、最重要指標
- 訓練時と検証時のFNRの乖離: 乖離幅が大きいほど過学習が疑われる
- OOD（Out-of-Distribution）テスト精度: 訓練データと意図的に分布を変えたサンプルに対する精度。過学習しているモデルはここで急落する
読み方の注意点
訓練精度と検証精度が両方高い場合でも、OODテストで精度が下がるなら過学習している可能性があります。訓練サンプルと同じ攻撃スタイルしか検証セットに含まれていないと、この問題が見えません。検証セットに「表現を変えた同義の攻撃」を意図的に含めることが重要です（セット分割の詳しい手順は後述します）。
当社のVetoNet分類器の訓練ログでも、この構造的な問題が実際に観測されています。学習パターン数が約4,000に達した段階で、訓練精度は高水準を維持したまま実環境での検出漏れが増加し始めました。詳細な経緯と設計変更の判断は次のセクションで説明します。
当社の失敗例：約4,000パターンで過学習した実測記録
当社がVetoNetの攻撃検出分類器を構築した際、訓練データが約4,000パターンを超えたあたりで過学習が顕在化しました。訓練精度は高水準を維持したまま、実環境での誤検出率が許容値を大幅に超えました。
このセクションでは、過学習が発覚した経緯と、同じ失敗が繰り返されやすい設計上の原因を整理します。
過学習が発覚したタイミングと検出方法
過学習は、モデルを本番環境に投入した後ではなく、評価パイプラインを見直した際に発覚しました。具体的には、以下の3つのシグナルが重なった時点で問題を認識しました。
- 訓練精度と検証精度の乖離が拡大した エポック数を増やすにつれ、訓練セットの精度は向上し続けたものの、検証セットの精度が横ばいから低下に転じました。
- OODテスト（分布外テスト）のスコアが急落した 訓練データと異なる攻撃手口（言い換えや文体変化を含むプロンプト）に対する再現率が、訓練セット上の再現率と比較して大幅に低下しました。
- 本番ログの偽陰性が増加した 実際のユーザ入力のうち、目視でプロンプトインジェクションと判断できるものを分類器が「正常」と判定するケースが増えていました。
これらのシグナルをモニタリングする仕組みがなければ、過学習は長期間気づかれないまま放置されます。訓練精度だけを指標とする運用は、セキュリティ用途の分類器では特に危険です。
実装者メモ： 検証セットと訓練セットを同じデータ取得期間から無作為分割すると、OODテストで顕在化する問題を検証段階で検出できません。テンポラルスプリット（時系列で訓練・検証・テストを分割する方法）については、セクション1で解説しています。
セキュリティMLで繰り返されやすい設計上の誤り
当社の事例を振り返ったとき、過学習を引き起こした直接の原因は「データ量の増加」ではなく、「データの質と構成に対する設計上の判断ミス」でした。同種のプロジェクトで繰り返されやすいパターンを以下に整理します。
| 誤りのパターン | 具体的な問題 | 発生しやすいフェーズ |
|---|---|---|
| 訓練データの構造的偏り | 同一攻撃テンプレートのバリエーションが大量に含まれ、見かけ上の多様性が生まれる | データ収集フェーズ |
| ラベルの揺らぎ | アノテーション基準が曖昧で、同じプロンプトが異なるラベルで登録される | ラベル設計フェーズ |
| 評価セットの汚染 | 訓練データと時期や出所が重複したサンプルが検証セットに混入する | データ分割フェーズ |
| 正例クラスの過充填 | 攻撃サンプルを増やすことに注力し、正常サンプルの多様性が相対的に低下する | データ拡張フェーズ |
| 早期停止の未適用 | 検証損失が底を打った後もエポック数を増やし続ける | モデル学習フェーズ |
当社のケースでは、このうち「訓練データの構造的偏り」と「評価セットの汚染」が主因として特定されました。約4,000パターンの段階では、内部的に類似したテンプレートから生成したサンプルが全体の40%近くを占めており、多様性の実態がパターン数に見合っていませんでした。
また、検証セットを訓練データと同じバッチ取得で分割していたため、分布の独立性が担保されておらず、検証精度が実態より楽観的な値を示し続けました。問題が可視化されたのは、意図的に時期をずらしたホールドアウトセットで評価を行い直した後でした。
過学習を防ぐ具体的な実装手順（データ拡張・正則化・ホールドアウト戦略）は次のセクションで詳しく解説します。
過学習を防ぐ実装手順：5ステップのアプローチ
過学習を抑制するには、データ拡張・正則化・ホールドアウト戦略の3軸を組み合わせ、「攻撃の多様性」を訓練データに意図的に組み込む必要があります。前セクションで明らかになったテンプレート重複や評価セット汚染は、いずれもこの3軸の設計段階で防げるものです。
5つのステップは順序どおりに実施することを前提に設計しています。後工程で前工程の判断を覆すと、過学習の原因究明が困難になります。
ステップ1：訓練・検証・テストセットの正しい分割方法
分割方法の選択は、過学習の検出感度に直結します。ランダム分割は攻撃検出タスクには適していません。
セキュリティ分類器で問題になるのは、「同じテンプレートから生成した攻撃サンプルが訓練と検証の両方に混入する」パターンです。これは情報リークの一種であり、検証精度が実態より楽観的に見えます。
推奨される分割アプローチ
| 分割手法 | 適用場面 | 注意点 |
|---|---|---|
| テンポラルスプリット | 時刻情報が付与されているデータ | 最新データをテストに回すため、テストセットのサイズが小さくなりやすい |
| グループ別分割 | 同一テンプレート由来のサンプルをグループ化 | グループIDがない場合は類似度クラスタリングで代替する |
| 層化ランダム分割 | 上記2手法が使えない小規模データ | 最終手段。クラス比率を維持できるが情報リークは防げない |
つまずきやすい点は「テストセットを最後まで一切触らない」という運用の徹底です。ハイパーパラメータのチューニング中にテストセットを参照すると、テストセットへの間接的な過適合が発生します。テスト用データは最終評価の1回だけ使うと決め、それをコードとドキュメントの両方に明示してください。
ステップ2：攻撃パターンの意図的多様化（データ拡張）
訓練データが特定の攻撃フレーズや文体に偏ると、モデルはその表面的な特徴を学習します。結果として、言い回しを変えただけのバリアントを見落とします。
攻撃検出向けデータ拡張の具体的手法
言い換え拡張 同一の攻撃意図を異なる語彙・文体で表現したサンプルを追加します。同義語置換よりも文構造を変える書き換えのほうが、分布の多様性が高まります。つまずきやすい点は、拡張サンプルのラベルを元サンプルから機械的に継承することで生じるラベルノイズです。拡張後も人手またはLLMを使ったラベル再確認を挟んでください。
多言語・混在テキスト拡張 日本語と英語が混在する文や、カタカナ表記と英字表記を意図的に混ぜた攻撃文を追加します。実運用では多言語バイパスが頻繁に試みられます。
ネガティブサンプルの強化 攻撃に見えるが実際は正常なリクエスト（「詐欺の見分け方を教えてください」など）を十分に含めます。このカテゴリが薄いと偽陽性率が高止まりします。
境界サンプルの明示的収集 モデルが判定に迷うグレーゾーンのサンプルを意図的に訓練セットに組み込みます。信頼度スコアが0.4〜0.6の範囲に集中するサンプルを定期的にレビューし、ラベル付けして追加する運用が有効です。
ステップ3：正則化・ドロップアウト・早期停止の選択基準
どの正則化手法を選ぶかは、モデルのアーキテクチャとデータ量に依存します。「とりあえず全部使う」は効果の追跡を困難にするため避けてください。
手法ごとの選択基準
| 手法 | 向いているケース | 過学習の症状例 |
|---|---|---|
| L2正則化（Weight Decay） | 線形分類器や浅いネットワーク。訓練データが少ない場合 | 訓練損失と検証損失のギャップが徐々に広がる |
| ドロップアウト | Transformerベースの分類ヘッド。データが中規模以上 | 特定の特徴量に極端に高い重みが集中している |
| 早期停止（Early Stopping） | ほぼ全てのケースで第一選択として有効 | 検証損失が底を打った後に再び上昇し始めたエポック以降 |
| データ量の増加 | 正則化を追加してもギャップが改善しない場合 | 正則化の効果が飽和したと判断できる場合 |
早期停止を使う際の実装上の注意点が1つあります。「検証損失が最小のチェックポイント」を保存する仕組みを最初から組み込んでください。学習を止めた時点のモデルではなく、検証損失が最小だったエポックのモデルを本番に使います。この2つは異なります。
5ステップの全体像
ステップ1〜3に加え、残る2ステップは以下のとおりです。
| ステップ | 内容 | 主な目的 |
|---|---|---|
| 1 | 訓練・検証・テストセットの正しい分割 | 情報リークの排除 |
| 2 | 攻撃パターンの意図的多様化 | 分布の偏り解消 |
| 3 | 正則化・ドロップアウト・早期停止の選択 | モデルの汎化力向上 |
| 4 | OODテストセットによる評価 | 未知攻撃への汎化確認 |
| 5 | 偽陰性率を主指標とした閾値調整 | セキュリティ要件への適合 |
ステップ4と5は評価フェーズの話題であるため、詳しくは後述の「継続的な再学習と評価サイクルの設計」セクションで扱います。
実装者視点の注意点
ステップ2と3を同時に変更しないでください。データ拡張と正則化を同じ実験で変えると、どちらの変更が改善をもたらしたかを切り分けられなくなります。変更は1変数ずつ加え、検証セットのメトリクスが安定したことを確認してから次のステップに進んでください。