SardineCon SF/2026

Learn More

不正検知AIを開発してわかった、チームの数か月分の工数を削減できる5つのポイント

Chen Zamir
Chen Zamir
bg-image
bg-image
「不正検知AIを構築してわかった5つのこと」というタイトルのグラフィック。5段のらせん階段で、本番運用に耐えるAIにおける失敗ポイントを示している:限定的なエージェント、過度な疑い、幻覚的な推論チェーン、フィードバックループ設計の欠如、監査証跡の欠如。
Subscribe to newsletter
Share

自社開発する決断を下しましたね。モデルは十分に高性能で、チームも優秀、そして明確なユースケースもある。いい判断です。

私は何年も不正防止に携わり、ここ数年は自社開発の不正検知AIを構築し、また他社が同様のシステムを構築する様子も見てきました。その中で、いつも同じ5つの要因が開発スケジュールを長引かせ、社内開発への信頼を損なっていくのを見てきました。

どれも、実際に構築を深く進めてみるまでは明らかになりません。ですが、どこに注意すべきか分かっていれば、すべて避けることができます。そして、どれも「より良いプロンプト」だけで解決できるものではありません。

要するに、不正検知AIで「とりあえず何か出力させる」だけなら簡単ですが、本番環境できちんと機能する不正検知AIを作るのは、まったく別の仕事です。その二つの間にあるギャップを生んでいるのはモデルそのものではなく、ここで挙げる5つの要素なのです。

落とし穴

何が問題なのか

修正

幅広いエージェント

攻撃の種類ごとに誤ったキャリブレーションが行われている

タスクごとの狭く専門特化したエージェント

過度に疑い深いモデル

通常の行動を不正として検知する

正当な説明を求めるステップを強制する

推論における幻覚

不確かな推論に基づいて組み立てられた自信満々の論理

原子的で検証可能なステップに分解する

フィードバックループがない

パターンが移り変わる中で、エージェントは漂い続ける

初日を迎える前に、正確な基準(グラウンドトゥルース)と取得フローを定義する

監査履歴がありません

意思決定は再構築も統制もできません

最初から人間が読める意思決定の記録

1. 不正検知では、汎用型よりも特化型のAIエージェントの方が優れている

本能的には、有能なエージェントをひとつ作り、広い文脈を与えて、あとは自分で判断させたくなります。データは大量にあるのだから、すべてモデルに食わせればいい、という発想です。しかし実際には、それが「何をやらせても中途半端なエージェント」への最短ルートになってしまいます。

しかし、不正行為の攻撃パターンは多様すぎて、1つのエージェントだけで対応することはできません。シンセティックID詐欺はアカウント乗っ取りとは異なるシグナルプロファイルを持ち、そのどちらもプロモーション悪用や決済詐欺とはまったく異なる様相を示します。

それらすべてに対応できるように作られたエージェントは、平均的なシグナルに最適化されてしまい、個々のケースごとには不適切な調整になります。しかもこれはユースケースに限った話ではなく、スキルについても同様で、多くのことができるエージェントほど、簡単に脱線してしまいます。

効果的なのはその逆です。攻撃パターン1つ、あるいは調査タスク1つに特化して調整された、狭く専門化されたエージェントです。デモではあまり派手に見えませんが、本番環境でははるかに信頼できます。1つのことだけを行うエージェントは、評価・デバッグ・改善もずっと簡単です。なぜなら、間違っているときに、どこを見ればよいかが正確に分かるからです。

そして、この問題が露呈するのがまさにデモの場です。幅広く何でもこなすエージェントは、15分ほどのウォークスルーでは魔法のように見えます──何を聞いても、すべて答えてくれるからです。一方で、狭い領域に特化したエージェントは、実運用に耐えるものの、見た目は地味な選択肢です。1人の名探偵というより、特定のスキルごとに人を置き換える専門家チームだと考えてください。それぞれが人間1人分を丸ごと代替するのではなく、特定の能力だけを担い、次のエージェントが引き継ぎやすい、明確で追跡可能な作業の痕跡を残していくイメージです。

2. 過度に疑い深い不正検知モデルには、母集団コンテキストを踏まえた不正検知が必要だ

モデルはパターンを認識するように訓練されており、不正検知では特に「不審な」パターンを見つけることが求められます。これらを抑制策なしに組み合わせると、「普通」がどういうものか分からないために、過剰にフラグを立ててしまうエージェントが出来上がってしまいます。

暗号資産のオンランプでは標準的な取引速度でも、母集団の文脈を持たないモデルには異常に見えてしまいます。世帯全体で使われる共有デバイスや、企業のキオスク端末などは、協調した行動として検知されてしまうのです。

エージェントが幻覚を見ているわけではなく、不完全な母集団コンテキストから推論しているだけです。その結果としてエスカレーションが過剰になり、最終的にはアラートと、そのアラートに対するエージェントの推論をあなたのアナリストが確認しなければならなくなります。

この問題を解決するには、エージェントに必ず誤検知(フォルス・ポジティブ)を考慮させる必要があります。エージェントが不正の結論に到達する前に、同じシグナルに対して最ももっともらしい「不正ではない」説明を生成するよう強制してください。正当なストーリーのほうが説得力がある場合は、その旨をエージェントに明示させるべきです。

LLM はデフォルトで陰謀論寄りに傾きがちです。実際の答えが完売したコンサートや、子会社間で資金を動かしている財務関連の組織である場合でも、すぐにボット攻撃やシェルネットワークだと決めつけてしまいます。これに対抗するには、推論チェーンの中に検証ステップを導入し、正当な(合法的な)説明を主張できるよう最適化する必要があります。

3. 不正対策エージェントの幻覚は、不正検知におけるAIの幻覚から始まる

汎用的なAIのハルシネーションは、たいていはすぐに分かります。モデルが存在しない引用をでっち上げたり、架空の名前を作ったり、事実ではないことを断定的に述べたりするからです。一方で、不正検知エージェントのハルシネーションはもっと微妙で見抜きにくいものです。なぜなら、エージェントは実在するシグナルを材料に、自信たっぷりの推論チェーンを組み立てるものの、その間をつなぐ論理的なステップが成り立っていないからです。

実際には偶然にすぎない共起から、2つのアカウント間に関係があると推論してしまいます。あるセグメントでは通常のパターンであっても、その速度を不審だと読み取ってしまいます。また、あるデバイスシグナルが既知の攻撃ベクターに見えるという理由だけで過大に重み付けし、そのシグナルが母集団全体でどれほど一般的かを考慮しません。

対策はより優れたモデルではなく、分解することです。推論を明示的な最小単位のステップに分け、それぞれが次のステップが実行される前に検証可能な中間アウトプットを出すようにします。

1. このユーザーセグメントの基準となる速度を確立する。

2. このセッションをそのベースラインと比較します。

3. このリスク階層において、差分がしきい値を超えているかどうかを評価する。

各ステップは検証可能であり、全体の連なりも単に読めるだけでなく監査可能になります。そして、うまくいかなかったときには、結論全体を疑うのではなく、どのステップで破綻したのかを特定できます。

4. 最初のプロンプトを書く前に、不正検知のフィードバックループを設計する

社内開発の多くは、フィードバックループを「第2フェーズの課題」として扱っています。ですが、それこそが後々いちばん大きな痛みを生む意思決定です。はっきり言います――最初に設計してください。

なぜこの落とし穴にはまってしまいやすいのかというと、不正のラベルが付くまでに時間がかかるからです。チャージバックや紛争解決、正式な調査結果が出るまでには、表面化するのに数週間かかります。そのため、まずはエージェントをリリースして、学習の仕組みは後から考えようという誘惑に駆られてしまうのです。

しかし、最初の日から明確なフィードバックループを定義しておかなければ、エージェントは次第に逸れていきます。

それは構築時に、あなたのデータを使った不正検知AIのキャリブレーションによって調整されました。しかしその後、不正のパターンは変化し、顧客層も変わっていきます。実際の結果に基づいて更新する仕組みがなければ、そのエージェントは時間とともに信頼性が高まるどころか、むしろ低下していきます。この劣化は徐々に進むため、気づいたときにはすでに信頼が損なわれていることが多いのです。

出荷する前に、次の4つを明確にしてください:

  1. 何がグラウンドトゥルースと見なされるのか
  2. どれくらいの時間待つか
  3. アナリストによる上書きがどのように記録されるか
  4. それらすべてがどのようにシステムへ戻っていくのか

これは初日から自動化されている必要はありませんが、初日から設計されている方が望ましいです。

これを早期に解決すべき第2の理由もあります。それは「エージェントによるラベリング」です。チャージバックを待たずに、エージェントが新しいイベントに対して「不正の可能性が高い」あるいは「問題なさそう」とタグ付けできるようにすることで、攻撃者の動きの速さに合わせて検知ロジックを学習させることができるのです。

しかし、後から付け足したフィードバックループでは、取り逃した数か月分の新鮮なラベルを遡って手に入れることはできません。これを正しく実践しているチームは、ラベルの鮮度を「あると良いもの」ではなく「土台」として扱っています。

5. 監査証跡は機能ではなく、必須要件だ

規制された環境では、正確さだけでは不十分です。あなたのエージェントが関わるあらゆる重要な判断(否認された取引、フラグが立てられた口座、エスカレーションされた案件)は、後から再現できなければなりません。どんなシグナルを使ったのか?どのデータソースを参照したのか?各ステップでの確信度はどれくらいだったのか?監査人やコンプライアンス担当者が、その推論プロセスを追跡し、妥当だと認められるのか?

しかし、これはコンプライアンスだけの問題ではありません。証拠の連鎖を明らかにしないまま結論だけを提示するエージェントは、運用上大きなリスクとなります。

監査証跡こそが、人間がAIエージェントを統制できるようにする仕組みです。これがなければ、推論の検証や幻覚の排除、ドリフトの把握がはるかに難しくなります。ですから、私たちの他のスタックと同様に、エージェント型AIも完全に説明可能であり、ブラックボックスであってはなりません。

最初から人間が読める意思決定の履歴を構築し、ブラックボックスのAI不正検知にはしないでください。あらゆるステップが、構造化され追跡可能なアウトプットを生み出すべきです。

ケースを確認するアナリストは、30秒でその推論をざっと検証し、誤ったステップを見つけて修正できるようにすべきです。そして、その修正自体もデータであり、フィードバックループの一部としてシステムに還元される必要があります。

これらの不正検知AIの本番運用における課題は、開発をやめる理由にはならない

それらは自社開発が行き詰まりやすい具体的なポイントであり、そのどれもが、初期段階で正しい判断を下せば解決可能です。

本番環境で本当に機能する不正検知AIをリリースしているチームは、必ずしも最高のモデルを持っているチームではありません。そうではなく、エージェントロジックを1行書く前から、キャリブレーション、フィードバック、監査可能性をきちんと設計しているチームなのです。

スコープを絞って構築しよう。エージェントには正当なケースを主張させること。推論を分解すること。まずフィードバックループを設計すること。すべての判断を追跡すること。この5つをきちんと押さえれば、モデルはほとんど自ずと上手く回る。

継続学習型不正検知AIの全体像を把握する

私たちはホワイトペーパーを作成しました(こちらからお読みいただけます)。このホワイトペーパーでは、エージェンティックな不正対策オペレーションの全体像として、なぜこの変化がすべての不正対策チームに訪れるのか、システムはどのような姿であるべきか、必要となる人員規模とスキル構成、安全な継続学習のためのガバナンスモデル、そして18か月間の導入ステップについて解説しています。

本番環境で不正検知AIを構築する際のよくある質問

社内の不正検知AIチームにとって、AIを本番運用するうえで得られた最大の教訓は何ですか?

社内の不正検知AIチームにとって、実運用から得られる最大の教訓は、用途を絞ったエージェントを構築すること、誤検知率を適切に調整すること、推論プロセスを分解して設計すること、早い段階から不正検知のフィードバックループを組み込むこと、そして最初から監査証跡を残せるようにしておくことです。不正検知AIを本番環境で構築するうえで重要なのは、「より良いプロンプトを書くこと」ではなく、システムを信頼できるものにし、説明可能性を持たせ、変化に適応できるようにすることです。

なぜ不正検知では、汎用的なAIエージェントよりも特化型(ナロー)AIエージェントの方がうまく機能するのですか?

不正検知向けのナローAIエージェントがより高い効果を発揮するのは、不正行為の種類ごとに挙動が異なるためです。シンセティックID詐欺、アカウント乗っ取り、プロモーション悪用、決済不正などは、それぞれ異なるシグナルパターンを持っています。特化型エージェントであれば、特定のタスクに絞ってチューニング・テスト・デバッグ・改善を行えるため、あまりに多くのワークフローを同時に扱って平均的な性能にとどまってしまうことを避けられます。

なぜ過度に疑い深い不正検知モデルは問題を引き起こすのですか?

過度に疑い深い不正検知モデルは、十分な母集団の文脈を考慮せずに行動をリスクと判定してしまうため、問題を引き起こします。通常の取引速度や共有デバイス、あるいは一見変わった取引パターンであっても、その顧客セグメントにとって正当な行動がどういうものかをモデルが理解していなければ、不審なものとして扱われてしまう可能性があります。

人口コンテキストを用いた不正検知とは何ですか?

人口コンテキストを用いた不正検知とは、特定のユーザーセグメント、プラットフォーム、または取引タイプにとって「通常」とされる行動と照らし合わせてシグナルを評価することを意味します。人口コンテキストがないと、不正検知AIは一般的な行動を不審な行動と誤認し、アナリストに対する不要なエスカレーションを生み出してしまう可能性があります。

不正検知におけるAIのハルシネーションはどのように現れますか?

不正検知におけるAIのハルシネーションは、多くの場合「事実の捏造」ではなく、「誤った推論の流れ」として現れます。たとえば、不正対策担当者が実在するシグナルを使っていても、それらを誤って結びつけてしまったり、弱いシグナルを過大評価したり、実際には存在しないアカウント同士の関係を推測してしまう、といった形で表れます。

チームはどのようにして不正検知エージェントのハルシネーションを減らせますか?

チームは、推論をより小さく検証可能なステップに分解することで、不正対策担当者による誤った判断(ハルシネーション)を減らすことができます。各ステップでは、ベースライン、比較結果、しきい値チェックなどの中間アウトプットを生成し、アナリストが推論のどこが正しく機能していて、どこで破綻しているかを確認できるようにする必要があります。

なぜ最初に不正対策のフィードバックループを設計する必要があるのですか?

不正対策のフィードバックループは、まず最初に設計しておく必要があります。なぜなら、不正のラベル(確定情報)が判明するまでに時間がかかるからです。チャージバックや異議申し立て、調査結果の確定には、しばしば数週間を要します。初日からフィードバックループがなければ、不正のパターンや顧客行動が変化するにつれて、モデルやルールは本来の精度から徐々にずれていってしまいます。

本番環境において、不正検知AIのチューニングはどのような役割を果たしますか?

不正検知AIのキャリブレーションは、エージェントを実際の結果、最新の不正パターン、そしてアナリストからのフィードバックと常に整合させるためのものです。キャリブレーションを行わないと、攻撃者の手口が変化したり、顧客層が変わったりするにつれて、エージェントの信頼性は時間とともに低下してしまう可能性があります。

なぜ不正検知におけるAIガバナンスが重要なのですか?

不正対策におけるAIガバナンスが重要なのは、エージェントが支援して下した判断について、不正対策チームが理解し、検証し、説明できる必要があるからです。優れたAIエージェントのガバナンスには、明確な監査ログ、アナリストによる上書き(オーバーライド)、フィードバックループ、そしてエージェントがどのようにしてその推奨結論に至ったかを示す、人間が読んで理解できる意思決定の履歴が欠かせません。

人間が読める意思決定トレースとは何ですか?

人間が読める意思決定トレースとは、エージェントが何を確認し、どんなシグナルを使い、どのように推論し、どこで確信度が変化したかを構造的に示した説明です。これにより、アナリストはエージェントの作業を素早く検証でき、また不正検知向けのAIを監査・ガバナンス・改善しやすくなります。

継続学習型の不正検知AIはどのように機能しますか?

継続学習型の不正検知AIは、新しい取引結果、アナリストによる上書き、確定した不正ラベル、そして正当な行動のシグナルを取り込みながら、時間とともに精度を高めていきます。目的は、遅れて届くラベルを数週間から数か月待つのではなく、最新の行動パターンから即座に学習できるようにすることです。

社内でAI不正検知エージェントを構築する前に、チームは何を理解しておくべきですか?

チームは、社内でAI不正検知エージェントを構築することは、単にモデルを選べばよいという問題ではないことを理解しておく必要があります。難しいのは、スコープの設定、キャリブレーション、推論の質、フィードバック設計、そして監査可能性です。成功しているチームの多くは、開発を始める前に、本番環境での制約を前提に設計しています。