誤検知に関するブログシリーズ第1回では、お使いのシステムは自らの誤りを報告するようには設計されていないという現実を受け入れました。そのうえで、三角測量の手法を用いてその制約を補い、誤検知の実態を把握できる有用なイメージを作り出す方法について議論しました。
次の問題がやってきます。
偽陽性を数値化することは、単なる観察に過ぎません。計画ではありません。
偽陽性を本当に意味のある形で減らすには、もう一段深く踏み込み、別の種類の問いを立てる必要があります。
- それらはどこから来るのか？
- どれがパートナー主導ですか？
- どれが実際には不正リスクを装ったデータ品質の問題なのか？
- そして何より重要なのは、どこから始めるべきかということです。
この連載の第2部では、誤検知をいくつかのグループに分けて整理し、優先順位を付けて対処できるようにすることをテーマにしています。
どうやってそれを行うのでしょうか？ それは7つのステップからなるプロセスに集約されます。
ストリームA：誤検知を担当者と対策別に分類する
ステップ1：実際にイベントを辞退したのは誰ですか？
最初で最も重要なステップは、すべての誤検知を、その判断を下した担当者に紐づけることです。
取引が拒否されたり、オンボーディングの試みがブロックされたりする場合、必ず誰かまたは何かが「ノー」と言ったということです。
その「誰か」は、次のいずれかかもしれません。
- あなたのシステム内のルール
- 機械学習モデルのしきい値
- AIエージェント
- 手動審査を行う人間のアナリスト
- 第三者パートナー（銀行、発行会社、加盟店契約会社、または不正対策ベンダー）
この分類を行わないと、目に見えるもの、つまり通常はルールやモデルばかりを最適化することになってしまいます。
そのようにしてチームは何か月もかけてルールを微調整しますが、後になって、自分たちが一度も話をしたことのないイシュアからの却下が大半を占めていたことに気づくのです。
最初の作業は本質的には会計処理です。すべての却下について、どの主体がその判断を下したのかを記録します。
場合によっては単一のルールで決まることもあります。場合によっては、特定のモデルスコアのしきい値に基づいた判断になることもあります。場合によっては、手動での上書きになることもあります。場合によっては、決済パートナーから返ってくる二値のレスポンスになることもあります。
初日から完璧にやる必要はありません。大まかな分解でも大きな違いを生みます。
ステップ2：問題のどのくらいが上流に原因がありますか？
その基本的なマップができたら、多くの人が飛ばしてしまう問いを自分に投げかけてみてください。「このうちどれだけが本当に自分のコントロール下にあるのか？」と。
これはカード決済において特に重要です。1回のカード取引でも、最終的に発行会社が承認か否認かを判断するまでに、半ダースもの関係者の手を経ることがあるからです。
カード保有者と発行銀行の間には、しばしば次のような関係者が存在します。
- 加盟店またはプラットフォーム自体
- 決済サービスプロバイダー
- アクワイアラー
- 決済代行業者
- カードネットワーク
- イシュアプロセッサー
- そして最後に、発行銀行です
しかも、そのうえで、こうした関係者の中には自社のスタックにサードパーティの不正対策ベンダーを組み込んでいるところもあります。
これらの関係者のそれぞれが取引を拒否することができます。それぞれが独自のリスクロジックを持ち、それぞれが独自の誤検知を生み出します。
もし誤検知の60％が上流パートナーによって引き起こされているのであれば、あなたが影響を及ぼせる最大の範囲は40％に制限されます。
だからといって、諦めて立ち去るべきだという意味ではありません。むしろ、自分の目標や社内への報告の仕方、そしてどこにエネルギーを注ぐべきかを考え直す必要があるということです。
自分が所有していないルールを調整することはできません。目にすることのないモデルを修正することはできません。発行者のリスクエンジンを再学習させることはできません。
しかし、影響を定量化し、それを可視化し、組織の全員が自分たちの影響力の限界が実際にはどこにあるのかを理解できるようにすることはできます。その一歩だけでも、後々の多くのフラストレーションを防ぐことができます。
戦略的な観点では、もしパートナーのパフォーマンスに不満があり、それが基準に満たないと感じるなら、いつでも彼らを別の相手に置き換えるよう働きかけることはできます。しかし多くの場合、あなたがコントロールできない関係者が依然として存在し、誤検知に影響を与え続けるでしょう。
ステップ3：最悪の違反者を特定する
意思決定を大まかなカテゴリに整理できたら、次はもう一段深掘りする段階です。あなたが持っているあらゆる個々の意思決定手段を取り上げて、それぞれを詳しく分解してください。すべてのルール、ワークフロー、調査担当者、そして AI エージェントまでです。ここで徹底的に細部まで掘り下げていきます。
現実的には、完璧な実行をするのは難しく、時間もかかります。
まずは、最も多くの却下を生み出している対策に注目しましょう。あるルールが比較的正確であっても、件数が多い場合は、そのルールが誤検知の主な原因になっていることがよくあります。
それぞれを個別に集計し、絶対数ベースで最も多くの誤検知を生み出している要因を特定しましょう。これらが「手早く成果を出せる対象（クイックウィン）」であり、十分なデータを使って改善に取り組むことができます。
同時に、あなたの直感は、いくつかの問題のある要因がレーダーの下をすり抜けていることを示しているかもしれません。たとえば、古いルール、時代遅れのポリシー、あるいは十分に検証されていないソリューションなどです。
もし少ない件数しか発生しないルールが問題を引き起こしていると疑われる場合は、手動での確認によってその勘を検証してください。壊れたポリシーを見つけるのに、大量のデータセットは必要ありません。
ストリームB：フローとデータ品質ごとに誤検知を分類する
ステップ4：誰がブロックされているのか？
これでユーザーを妨げている要因は分かりましたが、そのユーザーがどこから来ているのかをまだ把握する必要があります。
あなたが管理しているスタックの範囲内であっても、誤検知が均等に発生することはほとんどありません。特定のフローなどに集中して発生する傾向があります。
- モバイルとウェブ
- iOS 対 Android
- 製品
- 支払い方法
- 新規ユーザーと既存ユーザー
イベントを拒否した当事者だけに注目していると、不正に動作しているルールやモデルがあるように見えるだけです。しかし、ユーザーがどのフローを通ったのかまで見てみると、より深刻な問題が見つかるかもしれません。特定のフローが壊れたデータや欠損データを生み出し、その結果としてスタック全体が誤作動している可能性があるのです。
iOS のサインアップに対して誤った IP データを送信してしまう、モバイル SDK の連携バグを考えてみてください。最初はそのバグ自体には気づきません。目に見えるのは、そのプラットフォーム上で地理情報ベースのルールのいくつかが、突然誤検知率（偽陽性率）の上昇を示していることです。IP ベースの特徴量を使うモデルも、挙動がずれてきているように見えます。アナリストたちは、モバイルから来るイベントの様子がおかしいと不満を漏らします。
ルール単位でしか見ていないと、モデルの再調整に何週間も無駄にしてしまいます。フローごとに分解して見れば、ウェブ上のロジックには問題がなく、問題がiOSの登録フローに限定されていることがすぐに分かります。
必ずしもデータの不具合とは限りません。特定のフローに、全体のユーザーとは違う行動をとる優良ユーザーが多く集まってしまい、そのこと自体が誤検知率を押し上げている可能性もあります。
アクターごとに誤検知を分類し終えたら、同じことをユーザージャーニーごとにも行いましょう。
- どのプロダクトの画面ですか？（例：アプリ版かデスクトップ版か）
- どのプラットフォームですか？（例：iOS と Android）
- どの支払い方法ですか？（例：Apple Pay とクレジットカード）
- どの地域ですか？（例：ティア1市場と新興市場など）
- どの特定のファネルですか？（例：ゲストチェックアウト vs. ログイン済み）
パターンはすぐに明らかになります。
ステップ5：データ品質の問題を明確に探す
フローごとにパターンが見え始めた瞬間、ほとんど必ずと言っていいほど同じ原因に行き当たります。それがデータ品質です。
ときには、根本にある不正検知ロジック自体は実は問題ないこともあります。ルールも妥当で、モデルのキャリブレーションも良好で、アナリストも経験豊富。それなのに、特定のトラフィックの一部ではパフォーマンスが急激に落ち込んでしまうのです。
それは多くの場合、システムが破損している、あるいは欠落している入力データに基づいて動作しているためです。
- 実際のIPアドレスを取得できなかった場合に使用されるデフォルトのIPアドレス
- プレースホルダーのメールアドレスや無意味な値
- 一部のOSバージョンでnullにリセットされるデバイスID
- 特定の決済方法で一切連携されない支払いメタデータ
- サードパーティのインテリジェンスソースとのタイムアウトや連携エラー
このような問題を素早く見つけ出すには、データポイントを値ごとにグループ化し、不自然に多く出現している値がないかを確認する方法が有効です。
ステップ6：データの問題を不具合のあるソリューションと関連付ける
データ品質の問題を特定したら、次は探偵のように原因を突き止める作業が必要になります。
各破損データポイントがどの特徴量に影響しているか（例：メールからメール送信速度など）を追跡し、その特徴量を問題を起こしているルールやモデルに結び付ける必要があります。
ほとんどの組織にとって、この作業は非常に困難になり得ますが、近道があります。それは、ステップ3で洗い出した主要な問題のあるソリューションのリストです。
破損したデータポイントを、パフォーマンスが最も悪いルールで使用されている入力データと突き合わせて確認しましょう。そうすることで、データスキーマの分析に何日も費やさなくても、隠れた関連性を見つけられるかもしれません。
データの問題を解決策と結びつけることで、チェーンの最後の輪を完成させることができます。つまり、最も深刻な問題に対して行ってきたのと同じように、それぞれの問題に価値を割り当てられるようになるのです。
さあ、ここまでの内容をすべて統合していきましょう。
両方の流れを統合する
ステップ7：修正したい項目を特定し、優先順位を付ける
このマップがあれば、優先順位付けははるかに分かりやすくなります。
まず、次のようなカテゴリーから始めます。
- 重要と言えるほど十分に大きい
- あなたの管理下にある
- 上流側や他の場所で対処すべきデータ品質の問題が明らかな原因ではないこと
多くの組織では、これは次のようなことを意味します。
- 少数の高頻度かつ高い影響力を持つルール
- 慎重に設定された1つまたは2つのモデルしきい値
- 過度なブロッキングを助長する特定の案件管理ポリシー
- お使いのシステムでデータ不備が発生するいくつかのフロー
これらこそが、第3部でまさに焦点を当てる領域です。そこで私たちは、不適切に動作するルールの整理・削減、しきい値の調整、そして過剰に反応しないよう意思決定ロジックの一部を再設計するといった具体的な仕組みについて掘り下げていきます。
その作業が本当に効果を発揮するのは、まず根本原因の分析を行い、賢く投資する方法を理解しているからです。
地図からロードマップへ
このプロセスが終わる頃には、3つの成果物が揃っているはずです。
- アクター、フロー、データの健全性ごとに分類された誤検知の状況マップ
- 問題のどの部分が自分の責任で、どの部分がパートナーやアーキテクチャ上の制約から引き継がれたものなのかを明確に理解していること
- 大きな効果が見込め、改善可能な領域の中から、実際に手を付ければ目に見える成果が合理的に期待できる優先候補リスト
これによって、「誤検知」という漠然とした不満が、具体的なワークストリームへと変わります。
このシリーズの第3部では、インパクトの大きい領域に焦点を当て、解決に向けた具体的な戦術について詳しく説明します。
- 問題のあるルールを無効化するか、条件を緩和するか、自動却下ではなく手動審査に回すべきかを判断する方法
- 不正検知プロセスの「鏡像」を活用して、誤検知を取り除きつつ、不正が増える抜け穴を作らないように除外条件を設計する方法
- 不正防止システムのパフォーマンスを低下させているデータ品質の問題への対処方法
最後に、第4部ではグローバルなセーフティネットを構築します。これは、システム全体の上位に位置する高レベルのヒューリスティックであり、下層のあらゆるソリューション（ルール、モデル、エージェント、人間）が誤ってブロックしてしまう前に、優良なユーザーを保護する役割を果たします。
ひとまず、「誤検知が多い」という状態から「そのほとんどがどこから来ていて、どの部分なら実際に改善できるかを把握している」という段階まで来ているのであれば、あなたのチームはすでに多くのチームより一歩先を行っています。
それはとても良い状態です。
