4.2アラートの影響判定（真陽性・偽陽性・偽陰性）

検知は「鳴った/鳴らない」の2値と「実際に悪性だった/正当だった」の2値の掛け合わせで評価します。この2×2を正しく当てはめられないと、無害なアラートに時間を溶かしたり（偽陽性の放置）、本物の侵害を見逃したり（偽陰性の看過）します。SOCの日常業務は、限られた人手をどのアラートに割くかの優先順位付けであり、その判断はまさにこの分類に依存します。この節では各象限の意味と、運用上どれが痛いか（見逃し＝FNが最悪、ノイズ＝FPが疲弊）を、トリアージとチューニングの観点で結びつけます。

4.2.1検知の2×2

• 真陽性（True Positive・TP）＝アラートが鳴り、かつ実際に悪性だった正しい検知。SOCが本来対応すべき事象で、迅速なトリアージ→対応につなげる。真陰性（True Negative・TN）＝アラートが鳴らず、かつ実際に何も悪性が無かった正常状態。日常のほとんどはこれで、能動的な対応は不要。
• 偽陽性（False Positive・FP）＝アラートは鳴ったが実際は無害だった誤検知。害はないが、多発すると本物が埋もれアラート疲れを招くため、署名/しきい値のチューニングや抑制で減らす対象。偽陰性（False Negative・FN）＝アラートが鳴らないまま実際には悪性活動が起きていた見逃し。侵害が検知されず進行するため、最も危険な象限で、検知漏れの原因（署名不足・可視性の穴）を塞ぐ必要がある。

4.2.2benignトリガと運用上の重み

• benign（良性トリガ）＝署名や条件には技術的に一致したが、文脈上は正当で認可された活動だった状態。例：脆弱性スキャナの正規の定期スキャンがIPSの「攻撃らしいパターン」に一致する。厳密には害が無いので実質FPだが、「署名は正しく動いている（誤りではない）」点で純粋な誤検知と区別され、抑制（サプレッション）や例外登録でノイズを減らすのが定石。
• 運用上の重み付け：FNは検知できていない＝存在に気づけないため最も危険で、FPやbenignのように「見えている」問題より深刻。一方FP/benignは過剰なノイズでTPを埋没させ、対応の遅れ（間接的なFNの誘発）につながる。だからSOCはFNをゼロに近づけつつFP/benignをチューニングで抑える、感度と精度のバランスを継続的に取る。

あなたのSOCで、毎週火曜の深夜に同じIPSアラート SID ... "SQL Injection Attempt" が大量に鳴っています。調べると、発生源は社内の認可された脆弱性スキャナで、火曜深夜は定例スキャンの時間帯でした。この場合、IPSの署名は「SQLインジェクションらしいパターン」に正しく一致していますが、活動自体は正当です——これはbenign（良性トリガ）で、純粋な誤検知（署名がそもそも間違っている）とは区別されます。運用判断としては、署名を無効化するのではなく（それでは本物のSQLiまで見逃す＝FNを作る）、この送信元IP・この時間帯に限った抑制/例外を入れてノイズだけを消すのが妥当です。ここで安易に「うるさいから」と署名を止めてしまうと、次に本物の攻撃が来ても鳴らない偽陰性（FN）を自ら仕込むことになります。別の日、同じ資産に対し「何のアラートも無かった」のに、後日フォレンジックで外部への持ち出しが判明したとします。これは鳴らずに悪性が起きた偽陰性で、SOCにとって最悪の象限です。原因は署名の穴か、そもそも可視性が無かった（暗号化・監視外の経路）ことが多く、benignのチューニングとは正反対に検知を追加/強化して塞ぎます。この2つの事例が示すのは、同じ「アラートが少ない状態」でも、無害を正しく黙らせた結果（良い）と、悪性を見逃している状態（最悪）はまったく別物であり、分類を誤ると片方を他方と取り違えて危険な運用をしてしまう、ということです。

4.2.3この節のまとめ

• 検知は「鳴った/鳴らない」×「悪性/無害」の2×2：TP＝鳴った×悪性、FP＝鳴った×無害、TN＝鳴らない×無害、FN＝鳴らない×悪性
• FN（偽陰性）は見逃しで最も危険（見えない）、FPはアラート疲れの原因。両者は原因も対策も逆（検知強化 vs チューニング/抑制）
• benignは署名に一致したが正当な活動（実質FPだが署名は正常）。署名を止めず送信元/時間帯を限った抑制でノイズだけ消す