【ITニュース解説】CaseGuard: Winning with Uncertainty-Gated Agentic Fraud Investigation on TigerGraph

従来の不正検知システムは、設定された基準やリスクスコアに基づいて、取引が不正かどうかという単純な判断を下すことが一般的である。しかし、現実の不正調査はそこまで単純ではない。例えば、新しいデバイス、普段と違う場所、あるいは短期間での少額決済の繰り返しといった要因で取引が疑わしく見えることがあるが、それらがすべて正当な場合も多い。このような課題に対応するため、CaseGuardという自律的なAI不正調査システムが開発された。CaseGuardは「知らないことを知っている」というユニークな特性を持ち、確信が持てない状況で安易な判断をせず、追加の情報を収集して慎重に判断を進める。

CaseGuardは、TigerGraphというグラフデータベース、GSQLというグラフクエリ言語、GraphRAG（Graph-based Retrieval Augmented Generation）という情報検索・生成技術、そしてAgentic Reasoning（エージェント的推論）という自律的な意思決定プロセスといった先進技術を組み合わせて機能する。これらの技術が連携し、疑わしい取引の調査、追加証拠の収集、次に取るべき行動の推奨、SAR（不審な活動報告）の生成、そして過去のケースの記憶といった一連のプロセスを自動化する。

CaseGuardの処理フローは、アラートの発生から始まる。システムが不審な取引を検知するとアラートが生成され、TigerGraphで詳細な分析が行われる。次に、不正パターンが検知され、GraphRAGがポリシーに基づいた判断の根拠を提供する。ここで「不確実性ゲート」という重要な段階に入る。システムが十分な確信を持てない場合、安易な判断をせず、追加の証拠を収集するステップに進む。証拠が揃った後、次に取るべき最適な行動が推奨され、必要に応じてSARが自動生成される。最後に、この一連の調査結果はケースとして記憶され、将来の調査に活用される。

TigerGraphはCaseGuardシステムの「認知の背骨」ともいえる中心的な役割を果たす。これは、データ間の複雑な関係性を効率的に扱うグラフデータベースである。CaseGuardのグラフデータには、顧客、カード、取引、デバイスのプロファイル、請求地域、完了したケース、現在調査中のケースといったさまざまな「エンティティ」（実体）が含まれている。これらのエンティティは、「所有する（OWNS）」「行った（MADE）」「デバイスから（FROM_DEVICE）」「請求された場所（BILLED_IN）」「関わる（INVOLVES）」といった「リレーションシップ」（関係性）によって密接に結びついている。このグラフ構造により、従来のデータベースでは困難だった、複雑なデータ間のつながりを高速に分析できる。

CaseGuardは、大規模言語モデル（LLM）に直接複雑なグラフ計算をさせるのではなく、TigerGraphが持つ強力なグラフクエリ言語であるGSQLを直接使用して分析を行う。具体的な不正検知の例として、一つ目は「カードテスティングの検知」である。これは、不正なカード情報が有効かどうかを確かめるために、短期間に少額の決済を繰り返し行い、その後高額な決済を試みる手口である。CaseGuardはcard_windowというGSQLクエリを使って、このような取引の連続性を分析し、不審なパターンを検知する。二つ目は「デバイスシンジケートの検知」である。これは、複数の不正アカウントが同じデバイスを共有している可能性を特定するもので、device_neighborsというGSQLクエリを用いて、共有されたデバイスを介して複数の顧客カードやアカウントが関連しているつながりを明らかにする。例えば、１台のAndroidデバイスが５２枚の顧客カードに接続されていたケースが明らかになったという。三つ目は「地理的異常の検知」である。region_burstクエリは、顧客の過去の取引履歴から通常の行動パターンを学習し、それとは異なる地域からの取引、つまり通常では考えられない場所からの決済活動を特定する。これにより、不正利用の可能性が高い地域的な異常を捉えることが可能となる。

CaseGuardの最も革新的な思想の一つは、「システムが確信を持てないなら、推測すべきではない」という点にある。これは「不確実性ゲートAI」として実装されている。例えば、単に中程度の低リスクスコアに基づいてアラートが発生した場合でも、CaseGuardはすぐに顧客をブロックしたり、取引を拒否したりしない。代わりに、事前に定義されたポリシーに従い、顧客本人確認、追加認証（ステップアップ認証）、取引内容の確認といった追加の証拠を要求する。このプロセスにより、単一の不審な信号だけに頼ることなく、より多角的な視点から安全な調査ワークフローを実現し、誤った判断を避けることができる。

システムは、証拠収集の前と後で、次に取るべき最適な行動を推奨する。証拠収集前の段階では、「取引を許可し、同時に顧客に確認を行う」または「取引を拒否し、追加認証を求める」といった選択肢が提案される。追加証拠の収集後、不正が明確に確認された場合には、「カードのブロック」「不正調査ケースの作成」「関連当局への報告」といったアクションが示され、これらの行動には、自動承認、一次承認者（L1）、二次承認者（L2）といった適切な承認経路が設定されている。

CaseGuardは、完了した調査結果を貴重な知識として蓄積する。全てのクローズされた調査ケースは、insert_case_vertexというGSQLクエリを通じてTigerGraphに保存される。これにより、過去の調査がシステムの「機関記憶」となる。例えば、過去に正当な旅行履歴があったカードホルダーの海外取引によるアラートを、その記憶を活用してクリアするといったことが可能になる。これは、人間が過去の経験から学ぶように、システムが過去の調査結果から学び、将来の判断に役立てる仕組みである。

さらに、CaseGuardは、特定の条件を満たした場合に、FinCEN（米国金融犯罪取締ネットワーク）が求める構造化された不審な活動報告（SAR）の記述を自動的に生成する機能も持つ。これにより、調査担当者は不正の検知から報告書の作成までをスムーズに進めることができ、手作業で調査の経緯を再構成する手間が省け、効率が大幅に向上する。

CaseGuardは、Hacker House Goaが設定した２０の公式ベンチマークケースすべてに対して評価され、その有効性が証明された。結果として、システムのスキーマとポリシーへの１００％準拠、多様な不正類型の正確な特定、適切に調整された承認ルーティング、そして過去の調査結果を記憶から呼び出して利用する機能が確認された。このプロジェクトを通じて得られた最大の教訓は、グラフ計算と大規模言語モデル（LLM）による推論の役割を明確に分離することの重要性であった。TigerGraphは、データ間の決まった関係性や複雑なグラフ分析を担当し、AIレイヤーは、TigerGraphが提供する構造化された証拠を解釈し、ポリシーに基づいた判断を下すことに集中する。

今後の改善点としては、リアルタイムストリーミング処理の導入や、LouvainやWCCのようなグラフアルゴリズムを利用したコミュニティ検知、対話型の調査機能を持つアナリストコパイロットの開発などが挙げられる。

CaseGuardは、TigerGraph、GSQL、GraphRAG、そしてAgentic AIの組み合わせが、より透明性が高く、証拠に基づいた不正調査ワークフローをどのように実現できるかを示す好例である。このシステムは、「この取引は不正か？」という単純な問いにとどまらず、「どんな証拠があり、何を知らないのか、そして次に何をすべきか？」という、より深く多角的な問いを立てる。これが、CaseGuardの根底にある考え方であり、「知らないことを知る」探偵のようなAI不正調査システムを可能にするのである。