想像してみてください。不正対策チームが月曜日に新たな攻撃を発見したとします。それを阻止するルールが本番環境に反映されるのは1週間後、場合によっては2週間後です。その間ずっと、攻撃者はアカウントを開設したり、資金を抜き取ったりしています。こうした日数のロスは、一般にエンジニアリング部門への引き継ぎが原因だと考えられています。対策を設計したアナリストが本番環境を管理する別のチームにそれを引き渡し、その対策はほかの作業に埋もれて待ち行列に入り、引き継ぎが重なるたびに時間がかかるのです。
私たちもその見立てを信じていましたし、実際、部分的には正しかったため、何年もかけてプラットフォームから引き継ぎ作業をなくしてきました。アナリストはチケットを起票することなく、ダッシュボードから直接ルールを作成し、デプロイできます。モデルのデプロイは自動化されたパイプラインを通じて行われ、どちらの経路にもテストが組み込まれています。そのため、以前ならデプロイのタイミングを何日も待たなければならなかった変更も、今では数分で本番環境に反映できます。
その取り組みは実を結びましたし、今でも同じ投資をするでしょう。数日かかっていたデプロイは今では数分で完了し、顧客がその効果を真っ先に実感できる部分でもあります。同時に、この取り組みによって、その背後にあった制約も明らかになりました。引き継ぎがなくなっても、攻撃を検知してから修正を本番環境で稼働させるまでには依然として数日を要していました。つまり、そもそもその日数の大半は引き継ぎに費やされていたわけではなかったのです。既知のボトルネックを取り除いて初めて、そのことが見えるようになりました。
不正への対応サイクルでは、どこに時間がかかるのか
このことを明確に把握するまでには、しばらく時間がかかりました。その一因は、時間がかかっていた部分が、どちらか一方の機能の内部ではなく、2つの機能の間にあったためです。調査によって攻撃に関する仮説が生まれ、テストによってその仮説が実際に導入可能な対策へと変わります。この2つの間、つまり誰かが導入に踏み切る前に、仮説を実際のデータと照らし合わせて検証しなければならない工程が、日程の大半を費やしていました。
その境界部分にはいくつかの異なる問題が潜んでいます。それぞれに適した自動化のアプローチが異なるため、一つずつ分けて見ていく価値があります。
不正検知シグナルのデータはそもそも取得されていたのか？
最初に時間を費やすのは、そもそもデータが存在するかどうかの確認です。アナリストは、特定のデバイスシグナルによって攻撃トラフィックと通常のトラフィックを区別できるか検証したいと考えています。しかし、テストを実行する前に、イベントの3分の1でそのフィールドが空になっている理由を明らかにしなければなりません。このトラフィックセグメントでは、そもそもデータが収集されていたのでしょうか。ベンダー連携が、誰にも気づかれないまま、ある時点から機能しなくなっていたのでしょうか。あるいは、もっとありふれた理由かもしれません。そのフィールドに値が入るのは新しいSDKリリースを使用しているクライアントだけで、そのため影響を受けたユーザーの半数がルールの検知対象から外れているのです。
これらは基本的な疑問に聞こえます。しかし、答えるには各フィールドがどのように生成されるのかを把握する必要があり、多くの組織では、その知識を頭の中に持つ数少ない人を探し出さなければなりません。私たちが構築したデプロイ自動化は、この作業にはまったく役立ちません。なぜなら、これはデプロイするものができるよりもずっと前の段階で行われるからです。
不正ラベルの問題
2つ目の部分はラベルに関するものです。不正検知におけるラベルは、この分野以外の人が考えている以上に厄介な問題を抱えています。
チャージバックが届くまでには数週間かかることがあります。詐欺の報告は、加盟店や提携銀行、あるいは被害者が異変に気づき、わざわざ届け出るかどうかに左右されるため、まったく上がってこないこともあります。さらに、自社の管理策そのものが記録に偏りを生じさせます。ブロックした取引、つまり最も確信を持って下した判断からは、何のフィードバックも得られません。決済をブロックすると、学習に使える結果が生じないからです。
そのため、アナリストが提案されたルールを評価するには、まずこの攻撃における正解データとは何かを見極めるために、相応の時間を費やさなければなりません。バックテスト自体は1時間で終わります。しかし、その結果を信頼できるかどうかの判断には数日かかります。
不正検知バックテストにおける情報漏洩
私が最も懸念している失敗パターンは、情報漏洩です。つまり、結果に関する情報が評価に紛れ込んだために、バックテストでは良好な成績を示したルールやモデルが、本番環境ではまったく機能しなくなるケースです。後から振り返って初めて利用可能になった特徴量が使われていることもあれば、誰も気づかないままラベル期間と評価期間が重複していることもあります。
危険なのは、その進行の速さです。ルールはレビューを通過して本番環境に導入されると、すぐに自動で判断を下し始めます。そのため、手作業なら徐々に明らかになったはずの欠陥が、わずか数時間で被害を増幅させてしまいます。被害を元に戻すのに、元の攻撃への対応よりも長い時間を要したケースもあります。
これをデプロイ前に検出するには、診断用のインフラと相応の警戒心が必要です。どちらのコストも、調査とテストの狭間にある同じ領域で発生します。
不正対策業務向けのAIエージェントを導入する場合、これが意味すること
エージェント型の不正対策ツールの多くはスピードを売りにしていますが、そこで強調される速さは通常、サイクルの両端、つまりルール作成の迅速化とデプロイの迅速化にあります。ルールエンジンが十分に優れていれば、これらの工程はもともと速く、まさに私たちもそのような状況でした。
実際に得られた効果は、エージェントをプロセスの中間部分に活用することで生まれたものであり、それが機能するのは、基盤となるインフラが整っている場合に限られます。
- エンティティリンキング。これは実際にはグラフ機能を意味し、不正組織の範囲を特定するエージェントが、つながりを推測するのではなく実際にたどれるようにするものです
- その基盤となる整理されたデータモデル。断片化されたデータを結合する際、エージェントもアナリスト以上の信頼性を発揮できるわけではないためです
- 出所が明確なラベル。これにより、ルールの評価は、正当性を主張できるグラウンドトゥルースに基づいて行われます
- すべてのシグナルに付随するコンテキスト：そのフィールドが何によって生成され、いつ信頼できなくなるのか
その基盤がなければ、エージェントは、アナリストが抱えていたのと同じ盲点を残したまま、機械的な速さで結論を導き出してしまいます。
ここで私たちを何度も救ってきた原則があります。それは、エージェント向けに構築するものはすべて、同じインターフェースを通じて人間にも使えるものでなければならない、ということです。私たちは、エージェントに使わせる前に、何年もかけて人間向けの調査ツールを構築してきました。その間に得た、データがどこで嘘をつくのか、どのエンティティ間のつながりが誤解を招くのかといった知見は、現在エージェントが使用しているものに組み込まれています。
自社の不正検知ルールのデプロイサイクルを確認する
Chenはこのブログで、不備を発見してから修正を実行するまでの時間を指す「対応サイクル」こそ、不正対策チームが注視すべき指標だと述べています。エンジニアリングの観点から、これに1点付け加えたいと思います。直近のいくつかのインシデントについて、どの工程に時間がかかっているかを追跡すると、おそらく誰も最適化してこなかった段階が浮かび上がります。私たちの場合、それは調査とテストの間の引き継ぎ部分でした。その後工程にある障害をすべて取り除いたことで、初めてその継ぎ目が明確になったのです。
不正検知ルールのデプロイとは何ですか？また、不正対策チームにとってなぜ重要なのでしょうか？
不正対策ルールのデプロイとは、ルール、モデル、しきい値の調整などの不正防止策を、調査からテストを経て本番環境へ導入するプロセスです。攻撃を発見してから対策を実際に稼働させるまでの時間によって、検知から対応までの間に不正グループがもたらし得る被害の大きさが決まるため、このプロセスは重要です。不正対策ルールをより迅速かつ確実にデプロイできれば、そのリスクを直接軽減できます。
不正検知におけるバックテスト・リーケージとは何ですか？また、なぜ危険なのですか？
不正検知のバックテストにおけるリーケージとは、不正事象の結果に関する情報が、提案されたルールやモデルの評価に混入し、本番環境で実際に得られる以上の性能があるように見えてしまうことです。リーケージによって審査を通過したルールは、そのままリリースされて直ちに自動判定を開始するため、特に危険です。手動プロセスであれば徐々に明らかになる欠陥でも、わずか数時間で影響が増幅する可能性があります。リーケージを検出するには、導入後ではなく導入前に診断基盤を整備しておく必要があります。
不正ラベル問題とは何ですか？
不正ラベルとは、過去の事象が不正だったかどうかをモデルやルールに示す、正解データとなるシグナルです。しかし、不正検知におけるラベルは、不完全だったり、判明が遅れたり、観測できなかったりすることが少なくありません。チャージバックが発生するまでには数週間かかります。詐欺被害の報告がまったく上がってこない場合もあります。また、不正検知ルールによってブロックされた取引からは結果に関するフィードバックが得られません。決済が成立しなければ、学習に使える情報も生まれないためです。バックテストの結果を信頼するには、アナリストがまず、その特定の攻撃における正解データが実際にどのようなものかを時間をかけて明らかにする必要があります。バックテスト自体は1時間で終わっても、この作業には数日かかることがあります。
不正検知シグナルデータの収集とは、具体的にどのようなものですか？
不正検知シグナルのデータ取得状況とは、アナリストがルールで使用したいデバイス、行動、またはネットワークのシグナルが、評価対象の母集団について実際に収集されていたかどうかを指します。データモデル上に存在するフィールドでも、ベンダー連携が機能しなくなった、SDKのバージョンの違いによって収集にばらつきが生じた、または特定のトラフィックセグメントではそのシグナルが一度も収集されていなかった、といった理由で、一部のイベントでは空になっている場合があります。これを確認するには各フィールドがどのように生成されるかを把握する必要がありますが、多くの組織では、その知識は文書化されておらず、少数の担当者だけが持っています。
不正対策業務において、AIエージェントは具体的にどのような場面で役立ちますか？
不正対策業務向けのAIエージェントは、不正検知ルールの導入サイクルの両端、具体的にはルール作成とデプロイの高速化を売り文句にする傾向があります。しかし、ルールエンジンがすでに十分な性能を備えているなら、そこはもともと迅速に進められていた部分です。本当に効果が得られるのは、エージェントをサイクルの中間部分に活用することです。たとえば、不正グループのつながりをたどるためのエンティティ連携、エージェントが確実に照会できるよう整理されたデータモデル、出所が明確な不正ラベル、そして各シグナルが何によって生成され、いつ信頼できなくなるのかを説明するコンテキストの付与などです。こうした基盤がなければ、エージェントは人間のアナリストと同じ盲点を抱えたまま、機械的な速さで結論を出すだけです。
不正対策チームは、不正検知ルールの導入パフォーマンスをどのように測定すべきですか？
攻撃を検知した瞬間から、修正が本番環境で稼働するまでの不正対策サイクル全体を追跡します。次に、直近の複数のインシデントについて、各工程にどれだけ時間がかかったかを確認します。多くの場合、原因はこれまで誰も積極的に最適化してこなかった工程にあります。よくある要因としては、不正検知シグナルのデータ取得漏れ、不正ラベルの品質問題、不正検知モデルのバックテストにおけるデータリークのチェックなどが挙げられます。これらはいずれも、デプロイそのものより前の工程にあります。エンジニアリング部門への引き継ぎであれ、デプロイパイプラインであれ、既知のボトルネックを解消することで、真の不正検知のボトルネックが初めて明らかになることがよくあります。
多くのチームが見落としている不正検知のボトルネックとは何ですか？
多くの不正対策チームは、不正検知におけるボトルネックはエンジニアリング部門への引き継ぎ、つまりアナリストが提案した改善策を、本番環境を管理する別チームに渡す工程にあると考えています。アナリスト自身がルールをデプロイできるようにして、この引き継ぎをなくすことには価値がありますが、その結果、調査とテストの間にある、より根深いボトルネックが明らかになることも少なくありません。この境界領域には、不正の兆候を示すデータが正しく取得されているかの検証、不正ラベルに関する問題への対処、自動化された不正検知ルールをリリースする前のバックテストにおけるリーケージの診断などが含まれます。これらの問題は、どちらか一方の機能の内部ではなく、2つの機能の間に存在するため、最適化されないまま最も長く放置されがちです。
