このブログシリーズでは、Chen Zamir が（ほとんど）存在論的ともいえる不正対策の課題、つまり誤検知をどう減らすかという問題に取り組みます。パート1では、データが自ら答えを示してくれないときに、不正対策チームが誤却下を定量化するための5つの実践的な方法を紹介します。
誰もが誤検知は良くないと認めていますが、それを定量化できる人はほとんどいません。
不正対策の責任者に先月のチャージバック件数を聞けば、正確な数字が返ってきます。では、誤ってブロックしてしまった優良顧客が何人いたかを聞いてみてください。返ってくるのは肩をすくめる仕草か、ひどいときには「ゼロ」という答えでしょう。
人々が気にかけていないからではありません。私たちの不正検知システムの作り方そのものが、誤検知を意図せず見えなくしてしまっているのです。
取引を承認すれば、世の中からフィードバックが返ってきます。不正だった場合は、そのことを知らされます。正当な取引であれば、お客様が戻ってきて、さらに利用し、再びログインし、通常のお客様として行動する様子が見えてきます。
しかし、何かをブロックすると、そのシグナルは途絶えてしまいます。
いちばん良くても、お客様がクレームを入れてくれる程度です。ですが、そのクレームがあなたのデータにきちんと反映されることはほとんどありません。たいていはサポートチケットの中に埋もれたり、受信トレイに放置されたり、怒りのこもった電話の記憶として薄れていったりして、どこかのサイロの中で消えてしまうのです。
それが特定のイベントに紐づいた構造化ラベルになり、モデル学習用パイプラインに供給されたり、ダッシュボードを支えるデータになったりすることは、ほとんどありません。
だから、誤検知を減らすという話をする前に、まずはそれらにラベルを付けるということについて話さなければなりません。
このシリーズの第1回では、次の逆説に取り組みます。隠すように設計されたシステムの誤りを、どのように測定すればよいのでしょうか？
万能の解決策はありません。誤検知を測定することは、常に三角測量のような作業です。いくつかの不完全な手法を組み合わせて、意思決定に十分なほど鮮明な像を信号から浮かび上がらせなければなりません。
本題に入りましょう。
不正検知システムにおける誤検知を測定する5つの方法
何 | どのように |
シミュレーション | 過去のデータでルールをバックテストし、誤った却下を特定する。 |
手動レビュー | ミスを見つけるために、拒否された取引を監査しましょう。 |
行動リンク | 良い行動を取るようになって戻ってきたブロック済みユーザーを追跡する |
対照群 | 見逃しているものを測定するために、テストグループの通過を許可する |
ユーザーからのフィードバック | 支払いが拒否された理由についてユーザーにアンケートを取る |
方法1 - ルールとワークフローのシミュレーション
チームがシミュレーションに自然と惹かれるのは、それが簡単だからです。自分たちのロジックを過去のデータに対してバックテストするだけでよいのです。
あるルール、ルールセット、もしくはワークフローを取り出し、直近6か月分のトラフィックに対して実行してみてください。そこで、そのルールが本来であればすべてのイベントを拒否していたかどうかを確認し、それらを最終的なステータス（不正か正常か）と突き合わせて評価します。
重要な点として、不正の成熟度を必ず考慮してください。チャージバックが発生するまでには時間がかかるため、直近のデータは実質的に「ラベルなし」とみなされます。30日間のバッファは最低ラインであり、90日間のウィンドウを取ることで、「クリーン」と見なしているユーザーが本当にクリーンであることを確実にできます。
あなたのルールでブロックされていたはずの「クリーン」とラベル付けされたあらゆる取引は、理論上の偽陽性となります。
ここでの利点はアクセスしやすさです。SQL や不正検知プラットフォーム上で、新たなインフラを導入することなく実行できます。
しかし、シミュレーションには重要な制約があります。テストしているのはあくまで単体のルールですが、本番環境ではそのルールは、さまざまなルールやモデルのしきい値、AIエージェント、手動レビュー、外部サービスによる判断などが組み合わさった複雑な「ディシジョンスタック」の中で動作しています。
実際には、ルールは単独で機能するわけではありません。上流でのブロックによって無効化されたり、手動レビューによって覆されたりすることがあります。シミュレーションでは自分のルールが最終的な権限を持つと仮定していますが、本番環境では多くの場合、大勢の中の一つの声に過ぎません。
また、運用上の摩擦をバックテストすることもできません。シミュレーションはコードが完全に動作することを前提としますが、バグや連携上の問題、発行会社やプロセッサーといった上流の関係者の挙動までは捉えられません。そうした要因はすべて誤検知を生みうるにもかかわらず、「もしこのルールが本番で動いていたら、何をしていただろうか？」という単純な検証では一切反映されないのです。
そう、シミュレーションはぜひやるべきです。良い出発点になります。ただし、「このルールは誤検知率が低い」ことと「これで全体像がわかった」と勘違いしないでください。
方法2 - 否認されたイベントの手動レビュー
2つ目の方法は、より古く、より遅いものの、はるかに強力です。拒否されたトラフィックを手動で確認する方法です。
ロジックそのものを見るのではなく、その結果としての影響を直接確認します。全体のブロックされたイベント、または特定のソリューションに絞ったイベントからサンプルを取り、経験豊富な不正調査担当者にそれらへ手作業でラベル付けしてもらいます。
これは本質的に、新しいルールを設計したり新たな不正パターンを探したりするときと同じプロセスですが、その手順を逆向きに適用しているだけです。
制約は明らかです。スケールせず、時間がかかり、運用コストも高くつきます。また、高度な専門知識を持つアナリストも必要で、それでもなお、一定割合の事象は結論の出ない「グレーゾーン」のケースとして残ってしまいます。
一方で、これはリアルタイムの判断ではなくオフラインでの監査であるため、ケースごとの精度はそれほど重要ではありません。また、すべてにラベル付けする必要もありません。
大事なのは、自分がどの位置にいて、どこに最悪の問題点があるのかを把握することだけです。結局のところ、あるルールの正確性が45％なのか48％なのかを厳密に見極めることには、それほど意味はありません。
最初の2つの手法を組み合わせることも可能です。これは、ブロックしたい新しい不正パターンに対処していて、そのパターンが「成熟」するのを待つ余裕がない場合に特に有効です。直近1か月分のデータにそのロジックを適用し、その結果のサンプルを確認して性能を評価してください。
方法3 - 拒否をその後の良好な行動と結び付ける
3つ目の方法は、私が最も過小評価されていると思うものです。それが「リンク付け」です。
考え方はシンプルです。多くの場合、優良なユーザーは、ブロックされる前も後も、あなたのプラットフォームに何度も現れます。別のカードで再度試すかもしれません。別のメールアドレスで再度オンボーディングを試みるかもしれません。リスクが高いとは判断していないIPアドレスを使って、同じデバイスから再び取引を行うかもしれません。
それらの出来事を結びつけて一連の流れとして確認できれば、元の却下が誤検知だったことを示す非常に強力なシグナルが、突然得られることになります。
このつながりは、単純なものにもなり得ます。
- 同じユーザーIDで、別のカード。
- 同じデバイスで、異なるメールアドレス。
- 同じIPと名前で、異なるデバイス。
または、同じ世帯内でブロックされたユーザーの後に、その配偶者が正常に登録されるといった、より確率的（あいまい）なケースである場合もあります。
一度基本的なインフラが整えば、この手法は非常にうまくスケールします。定期的にブロックされたユーザー全体を見直し、その前後に起きた好ましい出来事と結びつけられないかを確認するだけでよいのです。
問題は、そのようなインフラが必要になるという点です。十分に機能するヒューリスティックを調査・検討しなければなりません。何らかのエンティティ解決も必要です。時間の経過に沿ってイベントのシーケンスを取り出せるようにする必要があります。これは決して簡単な作業ではありません。
しかし、ROI は非常に大きいのです。高精度な誤検知ラベルを継続的に生成できます。すべての誤検知を捉えられるわけではありませんが、捉えたものについては非常に信頼性が高くなります。
方法4 - コントロールグループ：意図的に一部の不正を通す
4つ目の方法は、誰もが少し居心地の悪さを感じるものです。それが「コントロールグループ」です。
通常は全体の1％程度のトラフィックをランダムに抽出し、そのサンプルを完全にホワイトリストに登録します。
ルールは一切なし。モデルに基づく却下もなし。手動審査もなし。この集団は、次のステップ――決済処理、アカウント作成、機能へのアクセス――へと、そのままスムーズに進みます。
そして、あとは何が起こるか見ているだけです。
全体としてシステムがうまく機能していれば、そのコントロールグループの中に、意味のある量の不正が発生しているはずです。一方で、コントロールグループの誤検知率が想定よりもはるかに高いことに気づいた場合は、設定を見直す必要があると分かります。
コントロールグループが強力なのは、「一部のユーザーに対してシステムを完全に停止したらどうなるのか？」という、非常に直接的な問いに答えてくれるからです。その結果はたいてい、目を背けたくなるようなものですが、偽りのない真実です。
しかしこの手法が実用的になるのは、大規模な場合に限られます。全体の1〜2％に絞っても、妥当な期間内に統計的に意味のある数値が得られるだけの十分なトラフィックが必要です。
また、損失を吸収できるだけの予算も必要です。薄い利益率と限られた取引量しかない小規模なフィンテック企業にとっては、これは現実的ではないかもしれません。一方で大手企業にとっては、本当に偏りのない測定結果を得られる数少ない手段の一つです。
方法5：ユーザーに尋ねる
5つ目の方法であるユーザーからの直接フィードバックの依頼は、特定の状況でしか使えない、より機会的な手法です。すでに把握していて信頼しているアカウントで発生した却下された取引を確認している場合には、「末尾1234の取引をブロックしました。これはあなたによるものですか？」といった、バンド外通知を送信することができます。
ユーザーがログインして認証されている場合、アプリ内のプロンプトやメールで、そのブロックが正当なものだったかどうかを明示的に確認できます。
しかし、これは一律に行えることではありません。ユーザーを一度も見たことがないオンボーディング時には役に立たず、見知らぬ相手に「不正利用者かどうか」を尋ねても有益なデータは得られません。
さらに、これは本当に強調しておきたいのですが、不正利用者に自分の試行を「良いもの」としてマークできる手段を絶対に与えないでください。もし「はい、自分です」というボタンが自動的にブロックを解除してしまうのであれば、それはフィードバックループを構築したのではなく、不正利用者が自分自身をホワイトリストに載せるための裏口を作ってしまったことになります。
しかし、失敗したログイン試行や連絡先情報の変更といったごく限られた状況において、追加の「事実に基づく情報源」として用いるのであれば、これは驚くほど有用な場合があります。
唯一の魔法の方法は存在しません
もしあなたの結論が「どれも完璧ではない」というものなら、それは正しいです。それが物事というものの本質なのです。
あなたが求めているのは、システム内の誤検知の正確な数を教えてくれる、たったひとつの魔法の指標ではありません。複数の独立した指標を組み合わせて、精度とスケーラビリティの両方を高めることなのです。
実際には、ほとんどのチームは次のような要素を組み合わせることになります。
- ルールごとの妥当性を素早く確認するためのシミュレーション。
- 高価値なフローと主要な違反ケースに対する手動レビュー。
- エンジニアリング作業が完了した後は、リンクを主要な継続的計測パイプラインとして活用します。
- ある程度の管理された損失を許容できる大規模集団向けのコントロールグループ。
- 慎重に選ばれた限定的な状況におけるユーザーからのフィードバック。
これらを適切に組み合わせれば、誤検知率について実用的な推定値を得ることができます。その推定値は、プロダクトフロー、トラフィックの種類、意思決定レイヤーなど、少なくともいくつかの重要な観点ごとに分解して把握できるようになります。
そして、問題を測定できるようになって初めて、正しい問いを立てることができます。
「どれくらいの数か？」から「どこから来たのか？」へ
誤検知の問題があると知ることと、その原因がどこにあるのかを知ることは、まったく別の話です。
主な原因はルールですか？ モデルのしきい値ですか？ 人によるレビューですか？ モバイルでIPアドレスを壊してしまう特定の連携ですか？ それとも、特定の地域で過度に厳しいサードパーティの決済プロセッサーですか？
このシリーズの第2部では、検知できた誤検知を根本原因ごとに分類していきます。具体的には、次の点を見ていきます。
- あなたの誤検知の問題のうち、実際に自分でコントロールできる部分はどれくらいあるのか。
- どの程度が特定のフローやプラットフォームに起因しているのか。
- どれだけの部分が、不正とは無関係なデータ品質の問題によって生じているのか。
- そして何より重要なのは、どのバケットは修正する価値があり、どのバケットは受け入れて付き合っていくしかないのかを見極める方法です。
誤検知がゼロというのは神話にすぎません。しかし、残っている誤検知がすべて「意図的に受け入れたもの」か「自分の影響範囲の外にあるもの」だけ、という状態まで持っていくことはできます。
そして、その明確さだけでも大きな価値があります。
パート2でまたお会いしましょう。
