誤検知を減らす話になると、人はたいていすぐに「ルールを調整する」「しきい値を変える」「例外を追加する」「モデルを緩める」「グレーなケースは人手で確認する」といった対策の話に飛びつきます。そうしたことはすべて必要な作業ではありますが、本来どれも出発点にすべきではありません。
この連載をここまで読み進めているなら（パート1 と パート2 をチェックしていない場合はぜひ読んでみてください）、あなたはすでに多くのチームが飛ばしてしまう2つの作業を終えています。
- システムがデフォルトで誤検知を隠してしまうにもかかわらず、あなたは誤検知をかなり正確に測定できるようにしました。
- それらの誤検知を、担当者別、ソリューション別、フロー別、データ品質別、そして自分たちの管理下にあるかどうか別のバケットに分類しました。
これで土台は整いました。あとは、うまく動いていないシステムの部分を修正するという本題に取りかかるだけです。
しかし、ここからは規律を持ってこの作業に取り組む必要があります。そうしなければ、意味のない変更を加えてしまったり、本来すべきだった変更を見落としてしまったり、最悪の場合には、気づかないうちに新たな不正の入り口を開いてしまうことになりかねません。
このブログでは、運用面での改善策に焦点を当てています。内部で機能する不正検知システムについて解説します。
手動審査で主要な不正事例を見直す
何か変更を加える前に自分の判断を確かにする最良の方法の一つは、手動レビューに立ち返ることです。最も頻繁に発火しているルール、モデルのしきい値、またはAIエージェントを選び、そのブロックしたイベントの一部を手作業で確認してください（多くの場合、50〜100件を見れば十分です）。
あなたが答えようとしているのは、たいていごく基本的な疑問です。
- このルールは、本当に私たちが思っているほど不正確なのでしょうか？
- この規則を本当に残しておきたいのでしょうか？
- もしそのルールが存在するなら、引き続き自動で判断を行うべきでしょうか、それとも代わりに手動レビューのための情報として使うべきでしょうか？
- それを自動化のままにしておく場合、詐欺による損失を実質的に増やすことなく、誤検知を減らすには何が必要でしょうか？
これらの問いの一つひとつは、ビジネスごとに異なります。「十分に良い」と言える普遍的な基準は存在しません。
場合によっては、FraudOps チームが追加の手動審査を引き受けることもできます。一方で、プロセスの一環としてまったく手動審査を行わないこともあります。
そして時には、そのルールがどれだけノイズが多くても、自動化されたままにしておく必要があります。なぜなら、その件数を手作業で審査する余裕がまったくないからです。
しかし、何かを変更する前には明確な根拠が必要です。最悪なのは、「論理的に見える」から大丈夫だと思い込んでしまい、実際に手動で確認してみると、そのルールが圧倒的に正当なトラフィックをブロックしていたと判明することです。
こうした状況は、理屈だけでは乗り切れません。実際に確認する必要があります。
何より重要なのは、これは本当に解決すべき問題かどうかを確認するだけのものではなく、その解決方法をあなたに示すことだという点です。
不正に動作する不正検知ルールやモデルごとに考えるべき3つの判断パターン
証拠を精査すると、ほとんどの問題を起こしているソリューションは、次の3つのカテゴリーのいずれかに分類されます。
1. 不正行為に関するこのルールは、そもそも存在すべきではない。
これは、チームが認めるよりも頻繁に起こります。
あなたのシステムには、次のようなロジックがあります。
- 少数の対象を検知します
- あまり不正を防げない
- 過剰な数の誤検知を生み出してしまう
- 主に、危機的状況のときに誰かが追加したまま、その後誰も見直していないために存在している
こうしたルールを外すのは、最初のうちは居心地の悪いものに感じられます。しかし、そのルールで検知できる不正がごくわずかで、誤検知が多いのであれば、それらを停止することはシステムを改善するうえで最もシンプルで安全な方法のひとつです。
これは、すぐに取り組める成果です。
2. 不正対策ルールは残すべきだが、自動的な判断は行わないようにすべきです。
これは、中程度の精度のロジックによく見られる状況であり、依然として意味のある不正を検知できるものの、人による確認なしにブロックするには信頼性が十分ではありません。
手動での審査を行う余力があり、かつこの特定のロジックがアナリストが判断しやすいイベントを生み出す傾向にあるのであれば、自動却下ではなくケース管理に回すことは、理想的な折衷案になり得ます。
不正防止のカバレッジを維持しつつ、誤検知を減らし、さらに人間をプロセスに介在させることで、パフォーマンスの変化をリアルタイムで観察できるようにします。
もちろん、そのコストはオペレーション面にあります。これは、アナリストの精度とキューの処理能力を明確に把握している場合にのみ機能します。
3. 不正検知ルールは残し、自動化も維持すべきですが、そのロジックは改善する必要があります。
これは最も興味深いシナリオであり、また最もよくあるケースでもあります。
このロジックは実際の不正行為を検知します。必要なものであり、効果的です。しかし同時に、かなりの数の正当なユーザーも巻き込んでしまっています。
だから、それを改善する必要があります。問題は「どうやって」です。
パス1：ルールを削除する | パス2：手動審査に迂回 | パス3：ロジックを洗練する | |
使用するタイミング | 不正検知率は低く、誤検知は多いままの、誰も見直していないレガシー／危機対応時代のロジック | 重要な不正を検知できるが、自動拒否を行うほどの信頼性はない中程度の精度のルール | 不正検知率が高く必要なルールではあるものの、正当なユーザーもかなりの数が巻き込まれてしまっている |
前提条件 | 手作業での確認により、不正行為の影響がごくわずかであることを確認済み | 利用可能なアナリストの稼働余力と明確なキュー処理能力 | 不正行為パターンと誤検知パターンを明確に分離（「ミラーイメージ」手法で検証済み） |
アクション | このルールを完全に無効にする | フラグが付いたイベントは自動却下せず、ケース管理にリダイレクトする | 不正検知対象データと照合して検証された、誤検知（偽陽性）から導き出された除外条件を構築する |
リスク | 詐欺件数が本当に少ない場合は最小限 | 運用コスト（アナリストの精度とキューの処理能力に依存） | 適切に検証されないと、除外によって不正が発生する可能性があります |
検証 | 削除後の不正発生率を監視する | アナリストの判断精度とキューの負荷を経時的に追跡する | 本番展開前のシャドーモード／チャレンジャールール検証 |
不正検知の「鏡像」：適切な除外条件の構築方法
誤検知が多いルールを改善するプロセスは、新しい不正検知ルールを設計する方法とほとんど同じで、ただ順序が逆になるだけです。
考えてみてください。あなたが不正検知ルールを設計するときには、次のようにします。
- 確定した不正事案の一連のケースを確認します。
- それらに共通するパターンを特定してください。
- その不正のパターンを、一般的な優良顧客層と比較してください。
- 不正を検知しつつ、正当なイベントをできるだけ巻き込まないロジックを構築する。
To reduce false positives, you do the same thing but with the opposite goal in mind. You:
- 確定した誤検知の事例を一通り確認します。
- それらの繰り返しパターンを特定します。
- それらのパターンを不正事例と比較し、その区別が実在することを確認してください。
- その分離を維持しつつ、不正を過度に「解放」してしまわないような除外条件や精緻化ルールを構築してください。
この最後のステップが極めて重要です。「多くの誤検知には特徴Xがある」と言うだけでは不十分です。あなたの不正検知ケースには、その特徴が現れていないことを証明する必要があります。そうしなければ、その除外条件は不正検知の精度を損なってしまいます。
何が素晴らしいかというと、どのステップも飛ばさずに進めてきたのであれば、偽陽性の指標を検証する過程で、すでにこの手作業による確認を終えているということです。
例を挙げてみましょう。ごく一般的なミスマッチルールがあるとします。
「IP の国がアカウントの国と一致しない場合は拒否する。」
これはよくあることで、しかもノイズが多いことがよくあります。ここで、あなたがこのルールでブロックされたイベント100件を手作業でレビューしたと想像してください。タグ付けを終えると、次のようなことに気づきます。
- 30件が不正でした
- 70件は正当なものでした
- その70件の正当なイベントのうち20件は、IPアドレスがカナダを示していた米国のユーザーに関係していました
70件中20件は意味のあるパターンです。
あなたのビジネスには、米国とカナダの間を行き来する利用者層が多いのかもしれません。カナダ側のエンドポイント向けVPNが一般的に使われているのかもしれません。あるいは、ユーザーの一部が国境近くで働いているのかもしれません。いずれにせよ、この特定の不一致（米国アカウント → カナダのIP）は、多くの誤検知を生み出しているようです。
不正検知の事例において、その同じ「米国 → カナダ」のパターンから発生する不正がほとんど、あるいはまったく見られないのであれば、その区別は明確だと言えます。つまり、そのパターンを安全に除外条件として設定できます。
「（IP の国がアカウントの国と一致しない）かつ（IP の国が CA でアカウントの国が US である場合を除く）場合は拒否する」
さらに言えば、事業の展開地域や利用可能な機能に応じて、近隣諸国も考慮したロジックを少し広げて取り入れるとよいでしょう。
重要なのは、その除外条件が誤検知（フォルス・ポジティブ）の母集団を精査することで導き出され、そのうえで不正検知の母集団に対して検証されているという点です。
これは、危険な抜け穴を生まないようにルールを洗練させる方法です。
リリース前にロジックの変更をテストする
既存のルールに除外条件を1つ追加するだけのような小さな変更であっても、不正検知ロジックを変更するたびに、あなたのリスク姿勢は変化します。これは、まったく新しいルールをゼロからリリースするのと同じことです。
だから、新しいバージョンをリリースする前に、必ずテストしてください。
シャドウモードとチャレンジャールールは心強い味方です。既存のルールは有効にしたまま、数日間は改良したルールを並行して実行しましょう。違いを計測してください。
- それによって、どれだけ多くのイベントが追加で許可されていたでしょうか？
- それらの出来事のうち、いくつが不正行為に発展しましたか？
- それによって、どれくらいの誤検知を防ぐことができたでしょうか？
結果が時間をかけても安定していれば、自信を持って導入できます。そうでなければ、調整してください。
これらの変更はどれくらいの期間モニタリングすべきでしょうか？
理想的には、新しいバージョンで不正がどれくらいの速さで成熟するか、そしてそれが元のバージョンと比べて同程度かどうかを十分に把握できるだけの時間が必要です。もし時間にかなり余裕がない場合は、ランダムサンプルを手動でレビューすることも検討するとよいでしょう。
データに関する問題に対処する場合
私たちが詳しく見てきたように、このシリーズの第2回で、誤検知の根本原因は必ずしもロジックの不備ではなく、破損したデータである場合があります。
うまくいけば、事前の基礎分析の段階でその問題をすでに特定できているでしょう。最悪の場合は、詳細な手動レビューでようやく原因がそれだと分かるまで、あらゆる手順を踏むことになってしまいます。
これが特定された根本原因である場合、データの問題を近い将来に解決できるかどうかによって、取れる選択肢は2つあります。
オプション1 - データ品質の問題そのものを修正する
破損しているフィールドがあなたの管理下にある場合、つまりあなたのSDKや社内連携、あるいはインフラであるなら、長期的に見て最善の解決策はデータを修復することです。
それは、API ペイロードを修正したり、SDK のバージョンを調整したり、プロダクトチームと連携して抜け穴を塞いだりすることを意味するかもしれません。
それには数日から数週間かかる場合があり、組織によって異なります。しかし、データが修正されれば、そのルールはたいてい再び正しく動作するようになります。
また、同時に他の部門を悩ませていたさまざまな問題も、あなたがまとめて解決した可能性が高いです。
オプション2 - そのフローの不正検知ロジックを調整する
すべてのデータ問題が社内で解決できるわけではありません。原因が、あなたにはどうすることもできない外部の関係者にある場合もあります。さらに厄介なのは、問題を自分たちでコントロールできているのに、解決策がまったく見えないケースです。
すぐに根本的なデータを修正できない場合は、そのフローに特化して不正検知ロジックを調整する必要があるかもしれません。改めて、いくつかの代替案を検討できます。
- 問題のあるフローをそのルールから完全に除外してください。
- ルールの重みを下げるか、その影響度を変更します。
- それらのケースを手動審査に回してください。
不正防止は優雅さよりも実用性が重要であり、時には正しさよりも賢く立ち回ることが大切です。
パート3の終わりまでに身につけておくべきこと
この段階では、次のことができるようになっているはずです。
- 最も頻繁に発生している誤検知の主な要因を特定する。
- それぞれについて、削除すべきか、経路を変更すべきか、あるいは改善すべきかを見極めましょう。
- 「鏡像」メソッドを用いて、効果的で安全な除外条件を作成します。
- 真の不正行為とデータ品質の問題を見分ける。
- リリースする前に、すべての変更をシャドーモードで検証してください。
これは誤検知削減の戦術的な中核であり、あなたのシステム内部にいる特定のアクターへの対処を意味します。
しかし、まだ触れていないレイヤーがもう一つあります。ルールやモデル、エージェント、さらには手動レビューさえも上位で統括するアーキテクチャ層です。
そのレイヤーが、第4部で向かう先です。それでは、またそこでお会いしましょう。
