【ITニュース解説】Your detector's threshold is a benign-only quantity

AIモデル、特に大規模言語モデル（LLM）の利用が広がる中で、その安全性を確保するための仕組み「ガードレール」が非常に重要になっている。ガードレールは、悪意のあるプロンプトインジェクションのような攻撃からシステムを保護するために、入力されたデータが攻撃的かどうかを検出する。この検出の際に中心となるのが「しきい値」と呼ばれる設定値である。しかし、多くの人がこのしきい値を誤って認識し、そのためにガードレールが適切に機能しない、という問題が指摘されている。

一般的に、AIモデルの検出器は、入力されたデータに対して「スコア」と呼ばれる数値を生成する。このスコアは、データが攻撃である可能性を数値化したものと考えることができる。そして、このスコアが特定の「しきい値」を超えた場合に、「これは攻撃である」と判断し、警告を出したり、処理をブロックしたりする。多くの開発者は、このしきい値をモデルの内部的な設定、つまり「モデルのパラメータ」だと考えがちである。しかし、実際のところ、しきい値は「入力されるトラフィック、特に正常な（悪意のない）トラフィックの特性」に強く依存するというのが、この問題の核心だ。

具体的な例を見ると、この誤解がいかに深刻な問題を引き起こすかがわかる。ある検出器「Prompt Guard 2」をプロンプトインジェクション攻撃のベンチマークデータで評価した場合、攻撃データは約0.009、正常なデータは約0.0008というスコアを出すことがわかった。しかし、この検出器のデフォルトのしきい値は0.5に設定されていた。これはモデルが出力するスコアの範囲をはるかに超える値である。結果として、629件の攻撃のうち、たった6件（1.0%）しか検知できず、ほとんどの攻撃を見逃してしまっていた。これは、「検出器は正常に動作し、スコアも出力しているのに、設定ミスで何も検知しない」という致命的な失敗例だ。

一方で、逆の失敗パターンも存在する。別の二つの検出器では、正常なトラフィックに対して約0.999という非常に高いスコアを出力していた。これらの検出器にとって、デフォルトのしきい値0.5は、出力されるスコアの範囲よりもはるかに低い位置に設定されていることになる。この場合、ほとんど全ての入力データがしきい値を超えてしまい、正常なトラフィックに対しても常に警告を発してしまう、いわゆる「騒がしい」状態になる。これは、「何もかもに警告を出す」という、これもまた実用上問題のある失敗例である。

なぜこのような問題が起こるのか。それは、検出器によってスコアの尺度（スケール）が大きく異なるためだ。先の例のように、ある検出器が0から0.01の範囲でスコアを出すのに対し、別の検出器は0.9から1.0の範囲でスコアを出すことがある。これらのスコア範囲は数桁もの差があるにもかかわらず、多くのシステムでは「0.5」のような固定のしきい値がデフォルトとして設定されている。このデフォルト値は、特定のモデルのスコア範囲を「前提」としたものであり、その前提が異なるモデルに対しては機能しない。つまり、デフォルトのしきい値は「万能な定数」ではないのだ。

では、しきい値はどのように決定されるべきなのか。この問いに対する答えが、記事の最も重要な主張である。「しきい値は、正常なトラフィックのデータのみから導き出される量である」という点だ。 詳しく説明しよう。例えば、システムで「偽陽性率（FPR）」、つまり正常なものを誤って攻撃と判断してしまう割合を、ある一定の予算（例えば2%）以下に抑えたいと考える。この目標を達成するための最適な「しきい値」は、入力される正常なデータのスコア分布だけから決めることができる。具体的には、正常なデータのスコアを低いものから高いものへと並べ、偽陽性率の予算に合わせて、何番目に高い正常スコアを閾値とするかを決定する。攻撃データは、このしきい値を使って実際にどれだけの攻撃を検知できるか（真陽性率: TPR）を「測定」するために使用されるが、しきい値そのものを「調整するつまみ」ではない。この事実は、実際のデータに基づいても検証されており、「攻撃データを使ってしきい値を調整する」という一般的な考え方が誤りであることを示している。攻撃データは、しきい値を決定した結果として、どれだけの効果が得られるか（ペイオフ）を評価するために用いるものなのだ。

この「しきい値は正常なトラフィックのみに依存する」という原則には、大きな落とし穴がある。それは、「しきい値は、それが測定された正常なトラフィックに対してのみ正しい」という点だ。つまり、ある環境で適切に調整されたしきい値を、別の環境や異なる種類のトラフィックにそのまま適用しようとすると、問題が発生する。 記事の実験では、同じベンチマークデータを四つの異なるドメイン（種類）に分割し、三つのドメインで偽陽性率2%の予算に合わせてしきい値を調整し、残りの一つのドメインにそのしきい値を適用する、という試みが行われた。結果として、36回の試行のうち11回で、偽陽性率の予算が破られた。例えば、約束された2%の偽陽性率が、実際には4.9%と2.5倍にも跳ね上がってしまったケースがある。この問題が発生したケースは、まさに「残りのドメインの正常なトラフィックのスコアが、他のドメインと比較して桁違いに高かった」という状況で起こっていた。

例えば、「prompt-guard-2-22m」という検出器では、旅行関連のトラフィックにおける正常スコアの中央値が約0.0092だったのに対し、他のトラフィックでは約0.0025だった。この検出器に、他のトラフィックから導き出されたしきい値を適用すると、旅行関連の正常なサンプル20件中13件（65%）が誤って攻撃と判断されてしまった。検出器自体は何も変わっていないにもかかわらず、処理する「トラフィックの性質」が変わったために、以前に調整されたしきい値が機能しなくなったのだ。これは、過去に調整したしきい値が、数ヶ月後には実効的な偽陽性率を数倍も悪化させる可能性があることを意味する。

このような問題を避けるために、システムエンジニアとして以下の対策を講じることが推奨される。 まず、しきい値は「AIモデルごと」ではなく、「トラフィックの発生源ごと」または「時間的な変化（ローリングウィンドウ）」で動的に導き出すべきである。つまり、しきい値を定数としてシステムに組み込むのではなく、実行時に適切な値を調整する「キャリブレーター」をデプロイメントに含めるべきだ。しきい値はモデルのチェックポイント（学習済みモデル）に属するものではなく、デプロイされる環境の特性に属するものなのである。

次に、正常なトラフィックのスコア分布を継続的に監視することが非常に重要だ。特に、正常スコアの中央値や99パーセンタイルといった統計量は、システムが設定変更されていなくても、実効的な偽陽性率が変化しているかどうかを早期に教えてくれる先行指標となる。攻撃が実際に発生し、それが検知された後で初めて問題を把握するのではなく、正常な状態の変化から兆候を捉えることが重要だ。

また、しきい値を再導出する際には、適切な数の正常なサンプルを確保する必要がある。例えば、偽陽性率2%という目標を設定する場合、その分位点を正確に算出するためには数百件程度の正常なサンプルが必要になる。これよりも少ないサンプル数では、「予算」は単なる丸め誤差のようなものであり、信頼性の低いしきい値しか得られない。

最後に、このような「サイレントな失敗」を可視化する仕組みを構築することだ。先の問題のように、ガードレールは「正常に稼働し、有効なスコアを返している」ように見えるため、ダッシュボード上では「グリーン（正常）」と表示されてしまう。しかし、実際には「何も検知できていない」か「全てを誤検知している」という状態かもしれない。システムの偽陽性率や真陽性率といった指標が継続的に報告されなければ、見た目上は正常でも、実態は全く機能していないという危険な状況を見過ごしてしまうことになる。

これらの対策を実施するために、本番環境で「ラベル付きの攻撃データ」を常に用意しておく必要はない。重要なのは、「自分のシステムにとっての正常な状態がどのようなものか」を正確に理解し、その「正常な状態」が変化したときに、迅速にそれを検知し、しきい値を再調整できる体制を整えることなのである。AIモデルの安全性を確保するためには、モデル自体の性能だけでなく、それが動作する環境とデータの特性を深く理解し、しきい値を動的に管理する運用が不可欠となる。