ボストンで開催された ACFE Global の1週間を終えたばかりで（そこでは想像以上にたくさんのウノのゲームが行われており、）、ヘイリー・ウィンダムはチェン・ザミール（不正対策戦略責任者）、トム・トッド（応用AIリード）、ライアン・マコーマック（エンジニアリングディレクター）とともに、エージェント型不正オペレーションについて徹底的に掘り下げて語り合いました。Sardine のメンバーたちは、クライアントのアカウント乗っ取り（ATO）攻撃が自社のブロックを変異シグナルとして利用していた事例から、自動デプロイが完了して初めて見えてきたインフラ面のギャップに至るまで、あらゆるトピックを取り上げました。
ぜひウェビナー本編をご覧ください。それまでの間に、私たちが特に興味深いと感じたポイントを手短にご紹介します。
マシン速度の不正攻撃：あらゆるブロックから学習したATO攻撃
チェンは、アカウント乗っ取りに悩まされているクライアントの事例から話を始めました。クライアントがルールを調整するたびに、攻撃は少し形を変えて再び現れ、そのサイクルがあまりにも速いため、チームはそのタイミングに注目し始めたのです。
「攻撃がブロックされるたびに、その拒否自体が攻撃者にとって行動を変化・適応させるためのシグナルになっていました。私たちは実際に、その変化がミリ秒単位で起きているのを目の当たりにしましたが、それが人間の仕業でないことは明らかでした。」
彼は、これは私たちが目にしているものの中では依然としてごく一部に過ぎないと、すぐに付け加えました。しかし、方向性ははっきりしており、彼は率直にこう言いました。「良いニュースがあって、『Sardine を買って、うちを統合すればそれで終わりです』と言えたらいいんですが、そんなふうにはいきません。」不正対策プログラムを機械のスピードにまで引き上げるということは、ツールだけでなく、組織やプロセスそのものを見直すことを意味します。
リアクションサイクルKPI：1週間の対応時間が実際にはどこに隠れているのか
攻撃がミリ秒単位で適応してくるのであれば、問題になるのは「どのスピード」を実際に測っているのか、という点です。ルール自体はリアルタイムで発火しますが、そのルールを変更するまでのプロセス（問題を発見し、影響範囲を見極め、対策を設計し、テストし、最終的に本番環境へ反映するまで）には、簡単に1週間かかってしまいます。Chen はこれをリアクションサイクルと呼んでおり、その内容について当社のブログで執筆しています。これは、多くの不正対策チームが注目すべき最重要KPIだとしています。
私たちのエンジニアリングチームは、そのサイクルの「デプロイ」側を短縮することに何年も費やしてきました。アナリストが直接ルールを投入できるルールエンジン、自動化されたモデルパイプライン、組み込みのテストなどです。そうした取り組みは大きな成果を生み、同じことをもう一度やる価値があると感じています。しかし、デプロイが高速化されても、サイクル全体の所要時間はほとんど短くならず、つまり1週間かかっていた原因は、そのプロセスのもっと前のどこかに潜んでいたのです。
「本当に、私たちが見つけるボトルネックは、はるかに厄介な問題で、調査とテストの“つなぎ目”の部分にあります。必ずしもデプロイや検知そのものが原因というわけではないのです。」
必要なデータがそもそも記録されていなかったり、ベンダーとの連携が数か月前からひっそりと動かなくなっていても、誰も気づいていないことがあります。ラベルはまた別種の問題です。チャージバックには数週間かかり、詐欺報告はそもそも届かないかもしれず、自分たちのブロック判断によって記録が検閲されてしまいます。なぜなら、ブロックされた取引からは学習に使える結果が一切生まれないからです。さらに「リーケージ（漏れ）」の問題もあります。あるルールはバックテストではうまくいき、本番にリリースされても、運用の中で崩壊してしまうのです。「こうした問題は非常に大きく、厄介で、元に戻すことも、場合によっては検知することさえ難しくなり得ます。」
大規模な不正調査：デバイスフィンガープリンティングと15万件のアカウント詐欺組織
インフラが整うと、反対側がどのように見えるのかをトムが示してくれました。バックグラウンドでパターン探索を行うエージェント、朝一番に理由付けまで添えられた提案ルールを開くアナリスト、出荷前にエージェントとチャットして異議を唱えることができる仕組み――そうした姿です。
それから彼は、その調査の流れを順を追って説明しました。 以前にも紹介したことがある調査です。あるクライアントが不審なサインアップを検知し、私たちは共有デバイスのフィンガープリントを取得しました。IP上は米国を示している一方で、実際のユーザーはドイツとUAEにいることに気づき、そのすべてをデータアナリストエージェントに渡しました。エージェントは関連するアカウントをマッピングし、共通するシグナルを洗い出し、その範囲はどんどん広がっていきました。最終的には15万件のアカウント、ひとつの組織的な詐欺グループであり、最初のフラグから全体像が見えるまでにかかった時間は、ほんの数分でした。
以下のクリップでは、トムがそれを一歩ずつ解説しています。
不正対策業務におけるAIエージェント導入の4つの落とし穴
その調査がうまくいったのは、その背後にあるデータ基盤がすでに整っていたからです。私たちは、自分たちのエージェント的な取り組みの初期段階でそれが整っていないと何が起こるのかを学びました。
私たちはエージェントにデバイスIDフィールドを渡しましたが、デバイスIDは消去可能なブラウザストレージに依存していること、人々は定期的にクッキーを削除していること、そしてブラウザによっては自動的に削除するものもあることを説明しませんでした。エージェントにはそれを知るすべがなく、「ずっとフラグを立て続けていた。これは悪質なユーザーだ、デバイスを10個持っている。これは悪質なユーザーだ、デバイスを10個持っている」と判断してしまったのです。たった1つのフィールド、たった1つの文脈の欠落がこれを招きました。これを意味づけのない1万個の特徴量にまでスケールさせれば、エージェントは大量のノイズを生み出すことになります。
LLM には、どの国が怪しく見えるかといった先入観があらかじめ組み込まれていることもあります。グローバルに事業を展開する企業は、モデルのこうした事前の思い込みにそのまま従うのではなく、自社のデータから得られる証拠に基づいてそれらを上書きしていく必要があります。
人間のアナリストによる判断は、一見すると精度の基準としては堅実に思えますが、実際に監査してみると、ケースごとの一貫性やSOP（標準作業手順）との整合性にどれだけばらつきがあるかが分かります。私たちが目標としていた精度を達成できたのは、その基準そのものを精査して作り直すまでのことでした。
エージェントに自社のナレッジベース全体への制限のないアクセス権を与えるのは、一見すると効率的に思えます。しかし、そのナレッジベースには、かつては正しかったものの、今ではひそかに通用しなくなっている前提が含まれており、誰も気づかないうちに、それらがエージェントの提案内容を方向づけてしまいます。
AIエージェントのガバナンス：スキル、信頼、そして順序
ウェビナーの中でチェンが示した導入フレームワークは、ここでさらに詳しく掘り下げる価値があります。
あなたのチームがAIを使いこなせるようになるには、本当に時間がかかり、近道はありません。ロールアウトのスケジュールには、技術的な統合だけでなく、その習熟までの期間も織り込む必要があります。チェンは、自分が1年前より確実に優れたAIユーザーになっていると話しており、その学習曲線は不正対策チームのすべてのアナリストにも当てはまると言っています。
人員数の話題が、いつものように持ち上がりました。チームがAIを導入しても、人員数は横ばいのままです。これは必ずしも失敗を意味しませんが、信頼のギャップがあることは示しています。解決策は、導入を義務化することではありません。必要なのは透明性です。明確な目標、見える形でのモニタリング、エージェントが実際に何をしているのかを示すレポーティング。それがなければ、チームはエージェントに任せず、これまでどおり人手で作業を続けてしまい、自分たちの労力を切り替えられないのです。
チェンの主張は、エージェントはデータとモニタリングによってガバナンスされるべきであり、それはアナリティクスの仕事だということです。しかし多くの不正対策組織には、その役割を担う人材がまだ十分に配置されていません。そうしたポジションが成長して初めて、業務規模を縮小する話ができるようになるのです。
どの順番で構築していくかも重要です。ラベルが古いままでは、エージェントを導入してルール作成を高速化してもあまり意味がありません。なぜなら、そのルールは誤った前提データで学習されてしまうからです。まずイベントにほぼリアルタイムでラベル付けできるようになっていなければ、高速にルールを書くエージェントも、弱い土台の上に積み上げているだけになってしまいます。
どこから始めるべきか：不正対策オペレーション監査フレームワーク
ヘイリーは各パネリストに、あなたが自分のデスクに持ち帰るべきことを一つ挙げてほしいと頼みました。
トムの提案は最も基礎的なものでした。何かを買ったり作ったりする前に、まずはチームが行うあらゆる業務について、不正対策オペレーションのSOPを文書化しておくべきだというものです。チャージバックを精査するとき、実際にはどんな手順を踏んでいるのか？ どこに一番時間がかかっているのか？ クライアントは、AIエージェントに何をさせたいのかを整理する前にSardineにAIエージェントを求めてやって来ますが、その整理（マッピング）自体は無料でできるのです。
ライアンのポイントは、その後に続く部分についてでした。つまり、システムを構築する前に、どのように評価し、監査するかをあらかじめ決めておくということです。それがきちんと機能しているか、あなたはどう判断しますか？問題をどうやって見つけますか？その監査の仕組みは、後から付け足すよりも、最初から設計しておくほうがはるかに簡単です。
チェンの主張はシンプルでした。データ環境をきちんと整えておく必要がある、ということです。データがすでに整理されていて、AI にすぐ利用できる状態にあると「思い込む」だけで、実際に確認していないのであれば、その前提はほとんどの場合間違っています。さらに、エージェントが断片的なデータを自力でうまく扱えると仮定することも、同じくらい危険です。
完全な録画はオンデマンドで視聴できます。また、パネルがたびたび参照していた、チェンが「寝る前の軽い読み物」として勧めていたホワイトペーパーはこちらです。
