2026年4月に開催されたREPLY AI Agent Challengeに参加しました。
チャレンジの真の課題
ナラティブ（設定）を取り除くと、課題は次のようなものでした：
複数のデータセット（取引、ユーザー、場所、SMS、メール）が与えられた状況で、 どの取引が不正（フロード）であるかを判断せよ。
主な制約事項：
- 不正の振る舞いは時間の経過とともに変化する
- 判断には非対称なコストが伴う（偽陽性 vs 偽陰性）
- システムは異なるデータセット間でも汎用性を持たなければならない
- 公式スコアは評価用データセットのみで決定される
- 評価用データに対する提出は、最初の1回のみ受け付けられる
正確性に加え、システムは以下の点でも評価されます：
- コスト
- 速度
- 効率性
チャレンジ前の準備（実行管理）
チャレンジが始まる前に、通常は見落とされがちな「ある一点」に焦点を当てました。
制約下でチームがいかに機能するか。
チームは日本とブラジルに分かれていたため、早い段階で最小限の構造を導入しました：
- 最終的な決定と結論のための共有チャンネルを1つ設置
- 試行とフィードバックのためのプライベートなループを形成
- 「シグナル（重要な情報）」と「ノイズ（不要な情報）」を明確に分離
役割も事前に定義しました：
- アーキテクチャ / ディレクション（私） → システム設計、意思決定、スコープ管理
- コア・エンジニアリング → 実装と統合
- バリデーション / アウトプット → テストと最終結果の確認
シンプルな実行ループについても合意しました：
定義（Define） → 実装（Implement） → 接続（Connect） → テスト（Test） → 繰り返し（Repeat）
これはプロセスのオーバーヘッド（無駄）を作ることではなく、以下の事態を避けるためのものでした：
- 作業の重複
- 時間的なプレッシャー下での認識のズレ
- 意思決定のボトルネック
結果：
チームは方向性を見失うことなく、並行して作業を進めることができました。
データを見る前の戦略
すべての問題を見る前に、いくつかの作業前提を共有しました：
- これはデータに基づく意思決定システムであり、UIの課題ではない。
- 初期の正確性よりも、反復（イテレーション）の速度が重要である。
- 早期に稼働し、段階的に改善できるものが必要である。
それに基づき、以下の準備を整えました：
- 基本的なデータパイプライン
- モジュール化されたスコアリング構造
- 高速な反復を支えるロギング（記録）環境
チャレンジが始まった時：
私たちはゼロから始めるのではなく、既存のシステムを「適応」させていました。
システム設計
シグナルの質、コスト、速度のバランスを取るため、階層型の意思決定システムを構築しました。
L1 — 統計的ベースライン
ユーザーごとに、以下を算出しました：
- 取引金額の中央値
- MAD（中央絶対偏差）
- 振る舞いのリファレンス（送金先、手法、活動時間帯）
これにより、ユーザーごとの「正常な」振る舞いの基準を安定して定義しました。
L2 — 特徴量ベースのスコアリング
各取引を、一連の特徴量に変換しました：
- 金額の偏差（MADベース）
- 金額 vs 収入
- 残高減少率
- 新規送金先の検知
- 地理的な不整合（適用可能な場合）
- 説明文（description）ベースのシグナル
- 取引前のフィッシング露出
フィッシングへの露出は、以下によってモデリングしました：
- SMSとメールのパース（解析）
- 不審なパターンの検知
- ユーザーごとのタイムライン構築
- 取引のタイミングと先行イベントの相関分析
これにより、取引データ単体では見えない「文脈（コンテキスト）」を追加しました。
L3 — 複合スコアリング
各特徴量を、重み付けされたスコアに統合しました。
設計上の選択：
- 単一の特徴量だけで判断しない
- 既知の「安全なパターン」はスコアを下げる
- 少額の取引は重みを大幅に下げる
- 特定の取引タイプにはペナルティを課す
不審な取引を選別するために、**動的なしきい値（上位約10％）**を使用しました。
これにより以下が保証されました：
- 有効なアウトプット制約の維持
- データセット間での適応性
L4 — 選択的なLLMの活用
LLM（大規模言語モデル）は主要な仕組みとしてではなく、選択的に使用しました。
上位約30％のハイリスクな取引のみを、Groqでホストされたモデルに送信しました。
モデルには以下を渡しました：
- 取引のコンテキスト
- ユーザープロファイル
- 直近のコミュニケーション内容
そして、確率スコアを算出させました。
このシステムにおいて：
LLMは、統計的・行動的分析の上に重ねられた「二次的なシグナル」として機能します。
鍵となった設計の選択
不正を直接検知しようとするのではなく、以下に焦点を当てました：
取引の「前」に何が起きているか。
具体的には：
- フィッシングメッセージ
- 不審なメール
- 接触から実行までの時間
これにより、単なる孤立した異常値ではなく、因果関係の文脈をモデリングすることができました。
効率性への配慮
効率性を「一級の制約」として扱いました：
- ほとんどの取引をローカルで解決
- LLMは必要な場合にのみ使用
- レイテンシ（遅延）を制御するためのバッチ処理
- 重いモデルではなく、シンプルな統計的手法を優先
これにより、負荷がかかった状態でも応答性が高く、予測可能なシステムを維持しました。
結果
1,971チーム中 40位
以下の状況を考慮すると：
- 6時間という制約
- 分散されたチーム
- 変化し続けるデータセット
この結果は、単一の最適化ではなく、一貫した「実行力」を反映したものです。
改善の余地
時間制約の中で、速度と信頼性を優先するためにいくつかの決断を下しました。
もしもっと時間があれば、以下に注力したでしょう：
-
時間的モデリング（Temporal modeling） 取引は主に独立して評価されました。時系列を考慮した分析を組み込むことで、変化する不正の振る舞いをより正確に捉えることができたはずです。
-
適応的な重み付け 特徴量の重みは固定されていました。データ駆動型のアプローチを採ることで、データセット間での汎用性をさらに高めることができました。
-
よりタイトなフィードバックループ しきい値とスコアリングはデータセットごとに調整されましたが、実行中に継続的に洗練されるまでには至りませんでした。
-
より洗練されたLLMルーティング LLMは既にフォールバック（代替手段）として使用されていましたが、コストとインパクトのバランスをさらに最適化できた可能性があります。
これらは、意図的なトレードオフでした：
安定させるのに時間がかかる複雑なシステムよりも、制約下で確実に機能するシステムを優先する。
最後に
このチャレンジの本質は、完璧なモデルを作ることではありませんでした。
それは：
- 不確実な状況下で意思決定を行うこと
- 正確性とコスト、速度のバランスを取ること
- 素早く適応できるシステムを構築すること
そしてチームレベルでは：
プレッシャー下でも実行が安定するよう、十分な構造を作り上げることでした。