要約：TypeSafe AIの新しいSystem Oneモデル「Jev」を、Sardineが抱える不正対策およびコンプライアンス上の3つの課題でテストしました。Jevは、ソフトウェア間で高速に判定を行うためのモデルです。実在する不正グループの事例では、不正取引の93%を検出し、Claude Sonnetの62%を上回りました（再現率が31ポイント向上）。しかも、コストは約25分の1、1回の呼び出しにかかる時間は約100ミリ秒でした。
- 詐欺グループに関する判定： Jevは29件の不正取引のうち27件を検出しました。これに対し、当社のルールベースのアプローチでは26件、Sonnetでは18件でした。
- 氏名とメールアドレスの不一致：長年コードでは扱えなかったシグナルが、今ではリアルタイムの判定に利用できるほど高速かつ正確になりました。
- 他のソフトウェア向けのKYB回答：Jevは現在Sardine Flowのノードとして機能し、調査結果を顧客のエージェントが対応に活用できる構造化された回答へと変換します。
Sardineは、銀行、フィンテック企業、決済会社が、ログイン、支払い、新規の法人口座開設が正当なものかどうかを判断できるよう支援します。こうした判断は1秒間に数百回行われ、顧客を待たせているため、一つひとつをほんの一瞬で完了させる必要があります。
この制約があるため、業界ではルールと機械学習モデルが主流となっており、大規模言語モデルはほとんど活用されてきませんでした。LLMは不審な取引を的確に分析できますが、回答に数秒かかり、1回の呼び出しにつき約1セントのコストが発生します。毎分数千件もの決済を判定する状況では、速度とコストのどちらの面でも実用的ではありません。
TypeSafe AIは9月、従来とは異なるタイプのモデルとしてJevをリリースしました。Jevは、人間が介在せず、ソフトウェアから呼び出されることを前提に設計されています。データのまとまりと型付きの質問リストを送信すると、質問ごとに1つの回答が返されます。回答形式は、確率を伴う「はい」または「いいえ」、ユーザーが定義したリストからの選択、あるいはユーザーが定義した尺度上の位置です。1回の呼び出しにかかる時間は約100ミリ秒で、コストは1セント未満です。
TypeSafe AIは、ダニエル・カーネマンの著書『ファスト＆スロー』で示された、素早く直感的な思考様式になぞらえて、これを「システム1モデル」と呼んでいます。不正対策プラットフォームには、まさにそのようなソフトウェアによる構造化された証拠に基づく、迅速で一貫した判断が必要な場面が数多くあります。私たちは、そのうち3つの場面でJevを試しました。
まず、不正グループに対する最終判断として。次に、長年コードでは算出できなかったシグナルを計算する手段として。そして最後に、ビジネス上のチェックを、他のソフトウェアが処理できる回答へと変換する要素としてです。
1. 詐欺グループに関連する取引の検出
9月、ステーブルコインのオンランプサービスを提供する当社の顧客の1社が新製品をリリースしたところ、わずか数日で詐欺グループの被害に遭いました。同社から、不正利用者と判明している5人の情報が提供されました。デバイス、メールアドレス、カードを共有するアカウント同士を関連付ける当社のリンク分析により、そのリストは13人のユーザーと、検知をすり抜けていた29件の不正なカード取引にまで拡大しました。
この事例をもとに、これら29件の取引について不正かどうかを判定する3つの方法を比較しました。
1つ目は、従来から採用しているアプローチです。独自にデータベースクエリを作成してインシデントを調査するAIエージェント「Data Analyst Agent」が、同じ10日間におけるこの犯罪グループの行動を数千人の一般ユーザーと比較しました。その結果、一般ユーザーが1アカウントあたり平均1.8枚のカードを使用していたのに対し、このグループは平均4枚を使用し、IPアドレスも2倍以上の頻度で切り替えていたことが判明しました。
次に、これらの違いに基づいて、3つのベロシティルール（一定の時間枠内で何かが発生した回数をカウントするルール）を提案しました。これらのルールを適用していれば、29件の取引のうち26件を検知でき、検知率は90%に達していました。
2つ目と3つ目はいずれも、同じ出発点から始まります。まずコードが、同じカードやデバイスを共有している顧客が何人いるか、過去1時間にこのメールアドレスで何件の取引が行われたかといった、各取引に関する事実を算出します。次に、それらの事実をモデルに渡して判定させます。一方のパイプラインでは、汎用LLMのClaude Sonnetがモデルとして使われました。もう一方ではJevが使われ、「低い」から「非常に高い」までの尺度で、この取引にどの程度の詐欺グループ関与リスクがあるか、という1つの質問を投げかけました。
Jevは29件中27件、つまり93%を検出しました。LLMは18件、つまり62%を検出しました。
この差を生んだのは、一貫性です。不正グループ内のあるアカウントは「Jedi Force」という名前で登録され、約100分間に12件の取引を行っていました。そのうち一部の取引では、同じグループ内の別のアカウントでも使われていたカードが使用され、残りでは新しいカードが使われていました。
注意点が1つあります。今回、Jevには「この取引にはどの程度の詐欺グループ関連リスクがあるか？」という大まかな質問を1つだけ投げかけました。TypeSafeと結果について話し合った結果、次のステップでは、アカウントのアクティビティが急増しているか、カードやデバイスが他のアカウントと関連付けられているか、といった、より具体的な質問に分解する予定です。それによってスコアの精度がさらに高まるかを検証します。ここで示した結果は、質問を1つだけ使用したバージョンによるものです。
Jevは、2時間足らずの間に12件の取引が行われたことを最も重要な要素と捉え、カードの共有は小さな追加要素として扱ったため、12件すべてを狭いスコア帯で高リスクと評価しました。一方、Sonnetは各取引を個別に判断し、カードに関するフラグによって判定を丸1段階変えたため、同じアカウントによる同じ一連の活発な取引が、中リスクと高リスクに分かれる結果となりました。このうち低いほうの中リスク判定では、通常、決済はブロックされません。
Jevは、コストもはるかに安く、処理も高速でした。各呼び出しの入力は1,000トークン未満（およそ1ページ分のテキスト）で、処理時間は約100ミリ秒、29件の判定にかかった費用は合計で約0.1セントでした。一方、LLMによる処理には約25倍のコストがかかりました。しかもこれは、29件すべての判定を1回のリクエストにまとめた場合の数字であり、リアルタイムの決済フローではそのような処理はできません。取引が発生するたびにスコアリングする場合、LLMでは呼び出しのたびに完全な指示文の処理コストがかかり、回答にも数秒を要します。
Jevはステートレスです。呼び出し間の情報を記憶せず、自らデータを取得することもできないため、取引について必要な情報はすべて、あらかじめコードで計算してリクエストに含める必要があります。ルールベースの手法が僅差まで迫ったのも、このためです。不正検知の大部分を担うのはアカウントの関連付けと一定期間内の取引回数の集計であり、これらはどのパイプラインでも同じです。Jevがもたらすのは、そうした証拠をより低コストかつ高速に、そして一貫性をもって判断へと変換する方法です。
その一貫性は、後続のプロセスにもメリットをもたらします。当社のルール推奨エージェントはラベル付けされた事例から学習するため、呼び出すたびに回答が変わるモデルよりも、同じ行動を毎回同じように判定するモデルのほうが質の高いラベルを生成でき、そのラベルがより強力なルールへとつながります。
2. オンボーディング時に不審な兆候を特定する
Krista Thomasonという名義でアカウントが開設されていますが、登録されているメールアドレスはdylan.whitman@gmail.comです。人なら一瞬で問題に気づきます。しかし、これを確実に検出するコードを書くのは驚くほど難しく、どの不正対策チームも（何年にもわたって）取り組んできました。
難しいのは、こうした不一致のほとんどに悪意がないことです。人は愛称やイニシャル、ミドルネームを使い、配偶者や親族と同じ住所を共有することもあります。名前は別の文字体系に転写されたり、語順が入れ替わったり、アクセント記号が省かれたりします。また、メールアドレスの多くには名前がまったく含まれず、ハンドルネームや数字の羅列だけという場合もあります。Dylanを検出できるほど厳格なルールでは、何千人もの正当な顧客まで不正と判定されてしまいます。
私たちは以前にもこの問題の解決を試みてきました。長年不正対策に携わってきた人なら、ほぼ誰もが同じでしょう。そして、問題は常に同じ2つ、精度とレイテンシーでした。LLMに問い合わせる方法を含め、十分な精度を得られるアプローチは、ページが読み込まれる前に完了しなければならない判定処理に組み込むには、実行に時間がかかりすぎました。
そこで、この問題をJevに任せることにしました。リクエストには氏名欄とメールアドレスを含め、次の3つの選択肢から回答を求めます。
- メールアドレスが氏名と一致している
- メールアドレスには、名前を特定するのに役立つ情報が含まれていない
- メールアドレスが明らかに別人のものである
指示では、問題のないケースを明確に示すことで、モデルがそれらを整合していると判断できるようにし、「別人」は他人の名前が含まれているメールにのみ適用します。
この質問については、何度か改善を重ねました。バージョンを重ねるたびに、不一致のアカウントと正当なアカウントを従来の手法よりも明確に区別できるようになり、チューニング前にJevが返すデフォルトの確率だけでも、実用的な判別が可能でした。どの回答も、リアルタイムの判定に使えるほど迅速に返ってきました。社内テストツールでは、「Richard Anderson」と見知らぬ人のメールアドレスを組み合わせると別人と判定され、同じ名前にr.andersonというメールアドレスを組み合わせると、98%の信頼度で一致と判定されます。
その答えは、機械学習でいうところの「特徴量」です。つまり、既存の何千ものシグナルと併せて、ルールやモデルで利用できる新たなシグナルです。ほかのデータポイントと同じように利用できるようにする予定です。そうすれば、たとえば「メールアドレスが別人のもので、かつカードが過去1時間以内に追加された場合は、追加の認証を求める」といったルールを記述できます。未解決のエッジケースは、結婚によって姓が正当に変わる場合であり、リリース前に対応を進めています。Jevをルールエンジンに統合することで、このような高度な特徴量をお客様に提供できるだけでなく、ユーザー自身がカスタム特徴量を定義し、さまざまな問題を迅速にチェックできるようになります。
3. KYBリスクチェックの自動化
この3つ目の活用例をTypeSafe AIのチームに紹介したところ、Jevの典型的なユースケースだと評価されました。
企業が加盟店口座や銀行口座を申し込む際、金融機関は承認前に、その企業が正式に登録され、実際に事業を行っていることを確認し、事業内容を把握したうえで、懸念事項がないかを調べる必要があります。業界ではこれを「Know Your Business（KYB）」と呼びます。当社のWeb360製品は、こうした情報収集を担います。納税者番号や州の登録記録を確認し、企業のウェブサイトを読み取り、ウェブ検索を行い、オンラインレビューを収集します。その後、調査担当者が判断できるよう、調査結果を整理して提示します。
ここ数か月、別の形での提供を求めるお客様が増えています。お客様は独自のAIエージェントや口座開設の自動化フローを構築しており、Web360が検出した情報を、ソフトウェアが処理できる回答として受け取りたいと考えています。
この企業には、訴訟や規制当局による措置など、重大なネガティブ情報がありますか？確認された活動は、当社のオンボーディングポリシーに合致していますか？これは正しい法人ですか？これらの各項目について、毎回、定義済みの値のセットを持つ固定フィールドが必要です。
従来は、質問ごとにアプリケーションロジックを手作業で実装していました。たとえば、苦情履歴です。Better Business Bureauのレビューを対象に、深刻な苦情の傾向と単なる不満を区別するためのヒューリスティックを用いていましたが、顧客ごとに求める定義が少しずつ異なっていました。顧客ごと、質問ごとに個別のロジックを保守する方法では、規模の拡大に対応できません。
Jevを使えば、質問を一度記述し、収集した情報を渡すだけで、決まった形式の回答を得られます。私たちは、ワークフロービルダーであるSardine FlowにJevをノードとして追加しました。これにより、フローの最初のステップで情報を収集し、その情報についてJevに具体的な質問をいくつか投げかけ、回答を構造化されたラベルとして書き込めるようになりました。テスト環境でSardine自体を対象に実施したデモでは、ウェブ検索のステップを追加して「この会社はベンチャー資金を調達しているか？」と尋ねるフローに対し、「はい」という回答と1億ドル超という金額が返ってきました。
同じ調査パイプラインは、現在では2通りの形で結果を出します。調査担当者向けの経路では、Web360が見つけたすべての情報を人が確認できます。一方、他のソフトウェアから呼び出されるAPI向けの経路では、同じ情報をJevで処理し、顧客側のエージェントが待ち受けている構造化された回答を返します。
現在、フォーチュン500企業をデザインパートナーとして、Web360とJevを統合したシステムの構築を最終段階まで進めています。また、世界最大級のデジタル銀行の一つも、Jevを搭載したエージェントを活用してコンプライアンスアラートを精査し、その結果を自社のワークフローに取り込む予定です。
これが私たちの現在地です
3つのユースケースすべてにおいて、Jevが担ったのは、構造化された根拠をもとに、顧客が待てる時間内で判断を下すという特定の役割です。これまでは、その判断を人間や壊れやすいヒューリスティック、あるいはリアルタイムの意思決定には遅すぎるLLMに委ねていました。データ収集、アカウント連携、ルールはすべてそのままです。Jevが目にするのは、コードによって提示された情報だけだからです。
まずは、TypeSafeの助言に従い、不正グループのスコアリングにおいて、分解した質問をテストします。イベントのラベリング、ルールの提案、リスクスコアリングも同じ構造を持つため、次はこれらの領域で試す予定です。より多くのインシデントで実験を重ねながら、得られた知見も随時公開していきます。別の分野でJevを使った意思決定システムを構築している方がいれば、ぜひ情報交換させてください。
