自分の周りだと、セキュリティ製品が正常な通信を止めた場合に「誤遮断／誤検知」と表現することが多いです。
一般的には、このような現象は False Positive（過検知／過剰検知） と表現されます。
本記事では、この False Positive そのものの定義というよりも、
「何をもって“誤り”とみなすか（業務か、製品か）」という前提の違いに焦点を当てています。

「誤検知」が食い違った現場

とあるWAFのログ分析対応の報告会でのやりとりです。

自分：「このリクエストが、WAFの誤検知を引き起こしていました。」
お客様ご担当者様：「誤検知とはどういうことですか？製品として正しく動作していたんじゃないでしょうか。」

当時こちらも緊張していたこともあり、「あ、これは前提がズレているな」と気付くまでに時間がかかり、
1分ほど黙ってしまいました。

どこが食い違っていたのか

このとき食い違っていたのは、「何をもって“正しい”と言うのか」という前提でした。

セキュリティの文脈では、こうした事象はまとめて False Positive（偽陽性）/過検知と呼ばれますが、
同じ False Positive でも、「業務として誤りなのか」「製品として誤りなのか」で話しているのかによって、受け取り方が大きく変わります。

今回のケースでは2つの観点がありました。

1. 業務として正しいかどうか（ビジネス視点）
   • 業務通信（お客様サービス利用者の正規リクエスト）は、検知／遮断されずに通るべき
   • 正規のリクエストが止まってしまったのであれば、「業務としては誤り（好ましくない）」という感覚になる

2. 製品として正しいかどうか（仕様／実装視点）
   • 機器が仕様どおりに動いているかどうか
   • シグネチャやポリシーの条件に一致したからブロックした → 製品としては想定どおりに動作している
   • つまり「検知のロジックや設定は見直すべきかもしれないが、“不具合”とは限らない」

もう少し分解すると、次の2パターンがあります。

• 機器の不具合による遮断
  • 例：バグや不具合によって、検知条件が意図しない形で適用されてしまい、結果として通信が遮断される
• 仕様どおりの動作だが、業務影響が出てしまった遮断
  • 例：WAFのシグネチャがやや強めに作られている、または設定が厳しすぎて、正規のリクエストまで検知対象に入ってしまう

私が「誤検知」と言ったときは、

「業務通信が止まってしまった」＝誤り

という意味で使っていました。一方でお客様側は、

「製品が仕様どおりに動いている」＝誤りではない

という前提で話をされていました。
この前提差が、そのまま言葉の衝突になっていた、というのが振り返っての理解です。

自分の前提にもバイアスがあった

自分が新入社員のころから触っていた FortiGate / Palo Alto などは、少なくとも自分の経験範囲ではかなり安定した挙動でした。

そのため正直なところ、

• 「検知ロジック自体に不具合がある」
• 「シグネチャの精査が原因で機器の改修が入る」

といったケースをあまりイメージできていませんでした。
（報告会以降、経験してみてわかりましたが製品によっては、ロジック側に問題があって修正されることも確かにありました。）

一方、そのときご一緒していたお客様側は、長年運用を担当されているベテランの方々だったので、

• 「製品の不具合かどうか」
• 「ベンダとしての品質責任」
• 「報告書に“誤”という字を書くことの重さ」

といった点を強く意識されていたのかなと思います。
（もしかすると、私（若造）への教育の意図もあったのかなとも思いますが）

今振り返ると、

• 世代の違い
• 立場（運用側／ベンダー側）の違い
• 組織文化の違い

といったものが、言葉の受け取り方に乗っかってきて、噛み合わなさにつながっていたのだと思います。

正しい表現方法はどうするか

では、こういった場面でどう表現するのが良いのでしょうか。
絶対の正解はありませんが、私の中では次のような選択肢に落ち着いています。

• 「機器の不具合ではない」という前提を置き、用語の定義を明示する

報告書や評価レポートのような、フォーマルな文書ではこのパターンをよく使います。

• 報告書の冒頭や用語定義に、「本書における誤検知／誤遮断の定義」を明記しておく
  • 例：「本書では、機器不具合はない前提で、“業務上止まってほしくない通信が遮断された状態”を誤遮断と表現します」

こうしておくと、読み手が「この文書の中では、誤遮断＝業務影響が出たことを指しているんだな」と理解しやすくなります。

• その都度、「機器は仕様どおりに動作していましたが…」を添える

もう少しカジュアルなやり取りや、会話・チャットでの報告では、こんな書き方も使えます。

• 「機器は仕様どおりに動作していましたが、シグネチャ設定の影響で正規のリクエストがブロックされていました。」
• 「WAFのシグネチャにより、業務上必要な通信が遮断されました（製品としての動作は正常）。」

このように、

• 製品としては正常動作
• 業務上は望ましくない結果（正規通信が止まった）

の両方を一文の中に入れておくと、誤解されにくくなります。

フォーマル／カジュアルでの使い分け

• フォーマルな報告書・報告会
  • ①のように、用語の定義をきちんと書いておく
  • 「誤検知」「不具合」「仕様どおり」など、重たい単語ほど定義を明文化する
• カジュアルな報告・日々のコミュニケーション
  • 相手がセキュリティ製品にどれくらい馴染みがあるかを見ながら、
    • 「誤遮断」という単語を使うか
    • ②のように「正常動作だけど結果として止まってしまった」と説明するか

を選ぶ

• • 質問があれば、その場で補足・すり合わせをしていく

私が最初にこのケースを経験した場面は、フォーマルな報告書をもとにした報告会でした。

今振り返ると、あの場はまさに①のパターンを採るべき場面で、「本書における誤検知／誤遮断の定義」を
もっとしっかりと書いておけばよかった、と反省しています。

まとめ

最後に、この記事のポイントを簡単にまとめます。

• 「誤検知」「誤遮断」という言葉は、人や組織によって前提が違う
  • 「業務として正しいかどうか」
  • 「製品として正しいかどうか」

どちらの軸で話をしているかを意識することが大事です。

• 同じ事象でも、立場によって見え方が変わる
  • 業務側から見ると「正規通信が止まった＝誤り」
  • 製品側から見ると「仕様どおり動いた＝誤りではない」

という構図になりやすいです。

• フォーマルな場では、用語の定義を書いておくと摩擦が減る
  • 報告書の用語定義で、「本書における誤検知／誤遮断」の意味を明示する
• カジュアルな場では、相手の前提を想像しながら一言添える
  • 「機器は仕様どおりでしたが〜」「シグネチャの精度の問題で〜」のように背景を入れると伝わりやすくなります。

こうしたひと手間で、「あのとき黙り込んでしまった1分間」を、少しずつ減らしていけるのかなと思っています。

（なお、本記事で扱っている「誤検知／誤遮断」は、
一般的な用語でいう False Positive（過検知／過剰検知） になります。
そのうえで、「何に対して誤りなのか（業務か、製品か）」という前提をそろえておくことで、
用語そのものの議論だけでは防ぎきれない噛み合わなさを減らせます。）

この時の経験のおかげで、言葉の意味の受け取られ方を強く考えられるようになりました。

ここでいう以外にも、お客様から誤検知／誤遮断と言われるケースがありますので、そういった場面でも
多角的に考えられるようになったと思います。

実際体験してみないと学びはないかもしれませんが、読んでいただいた方に何か学びがあればうれしいです。

記載されている会社名、システム名、製品名は一般に各社の登録商標または商標です。

当社製品以外のサードパーティ製品の設定内容につきましては、弊社サポート対象外となります。