はじめに
新規プロダクトやプロジェクトの立ち上げにおいて、どれだけ意思決定を明確化し、設計を固めることができるかは、後々の開発効率や品質に大きな影響を与えます。一方で、最初が肝心だからといって調査や設計に何か月も費やす余裕は、多くの企業にはありません。できる限り早く設計を確立し、実装を開始して価値を生み出すことが求められます。
LayerXのバクラク事業では、法人向けのクレジットカード「バクラクビジネスカード」を提供しています。サービス開始時から不正利用を検知する仕組みを導入していましたが、ますます巧妙化する不正に素早くかつ柔軟に対応するため、決済基盤を拡張する形で新たな不正検知システムを構築することにしました。
このシステムの設計立ち上げにあたり、私は3日でDesign Doc (設計ドキュメント) を2本、関連するADR (Architecture Decision Record, 技術的な意思決定の記録）を5本まとめあげるという、かなりハイペースな取り組みを行いました。その結果、開発キックオフから約3週間で本番リリースにこぎつけることができました。その裏には、Large Language Model（以下LLM）の活用が大きく寄与しています。
本記事では、その背景やプロセス、得られた知見、そしてLLM活用によってなぜこれほどの速度と質を維持できたのかを紹介します。
なお、この記事はLayerX Tech Advent Calendar 2024 の 18 日目の記事です。
背景：クレジットカード不正検知システムとは
クレジットカードの不正利用は、金融機関や決済事業者にとって永遠の課題です。不審なトランザクションをリアルタイムで検知し、即座に対策しなければなりません。
特に、テクノロジーの進化とともに不正利用の手口はますます巧妙化しており、AIを活用したフィッシング詐欺や、カード情報を盗むための架空のショッピングサイト、出会い系サイト等が広がっています。不正利用の決済内容も巧妙化しており、決済事業者も対策を強化しています。
そのため、不正検知システムには以下の要件が求められます。
- 高い信頼性と可用性：24時間365日稼働し、トランザクションあたり数百ミリ秒のオーダーで判断する必要がある
- 高度なスケーラビリティ：トランザクション数は増え続けるため、スケールアウトが容易なアーキテクチャが求められる
- モデル精度と継続的改善：機械学習モデルやルールエンジンを駆使して、不正を極力見逃さず、かつ誤検知を最小限に抑える必要がある
- コンプライアンス対応：セキュリティ基準や法規制を満たす設計が求められる
これらは単なる技術選定だけでなく、システム全体の設計思想や運用・モニタリング基盤にも大きく影響します。そのため、アーキテクチャ段階から十分なドキュメントと意思決定プロセスの明確化が求められました。
3日でDesign Doc 2本、ADR 5本を執筆
不正検知システムの開発には、クレジットカード機能を提供する開発チーム、機械学習チーム、データチーム、クレジットカード利用者向けの業務企画・オペレーションチームなど、多くステークホルダーが関わります。そうした中で、早期に基本方針を固め共有する必要がありました。また、既に不正利用被害が発生し始めていたため、事業継続性確保とお客様体験の改善の観点からも、スピード重視が求められました。
進め方は、私がドキュメントを一気に書き上げ、カード開発チームマネージャーであるtakaeさんに素早くレビューしてもらう、というスタイルでした。ここでは「関係者全員の完璧な合意形成」よりも「NoがなければGo」という考え方で、後から修正できる範囲で最初の基盤を固めてしまう方針を取りました。
作成したドキュメントは以下です。
- Design Doc x 2本
- 不正検知システム全体のハイレベルアーキテクチャ
- 不正検知のコアロジックの設計 (オンライン処理、オフラインバッチ処理など)
- ADR x 5本
- パフォーマンスの計測方法と目標値の定義
- コアロジックの実装言語をPythonとする (他の選択肢: Go)
- オンライン処理はAmazon ECSで動かす (他の選択肢: AWS Lambda)
- オンライン処理における状態管理にはAmazon DynamoDBを使う (他の選択肢: Amazon Aurora)
- オフラインバッチ処理に関する決定
バクラク事業の開発ではGo＋Amazon Aurora＋Amazon ECSといったスタックが多用されており、今回の決定はその標準構成とはかなり異なります。なぜ例外を許容したのか、なぜこの技術選定をしたのかを、後に続く開発者が確認できるようADRとして記録しました。
実際に、カード開発チームのメンバーから「本当にPythonで運用できるのか？」という問いかけがあり、予想通り議論となった箇所でした。Pythonを選んだ主な理由は、機械学習エンジニアとの親和性が高く、データ処理面での優位性があり、オフラインバッチ処理とオンライン処理のロジックを共通化できることでした。Python実装の雰囲気を見せたり、議論をする中で、Goをメインとするエンジニアたちから「私たちもPythonに挑戦しよう！言語が違ってもたぶん大丈夫！」と前向きな反応をいただき、最終的にこの決定に至りました。
また、オンライン処理をAmazon ECSで動かすという決定について、検討初期は私の中でAWS Lambdaの方が有力でした。これは、AI-OCRを含むバクラクのあらゆるコンポーネントでAWS Lambdaで採用され、可用性とパフォーマンスの両面で良好な結果を得られていた実績があったためです。しかし、決済基盤に組み込む不正検知システムでは厳しいレイテンシー要求があり、LLMとの対話を続ける中で判断を変えることになりました。
3週間で開発し、本番環境にリリース
Design DocとADRが揃ったことでシステム全体の実装には迷いはありませんでしたが、不正検知のコアロジックの実装は悩みながら作りました。この3週間では以下の実装・テストをしました。
- 最小限の動く不正検知ロジック
- 不正検知を実行するAPIサーバー
- 決済サーバーから不正検知のAPI呼び出し
- 不正検知システムのインフラ作成
- いろんな箇所で意図的に障害を発生させ、決済が止まらないことを確認
また、監視やアラート整備、バクラクで初のPythonによるWebサーバー構築といったMLOpsの文脈で、データグループのcivitaspoさん、TrsNiumさんにも多大な貢献をいただきました。
LLM活用による効率化のポイント
今回の開発では、以下の観点でLLMを活用しました。
目的・要件の整理
何を解決したいのか、制約は何か、といった目的と要件の整理は、LLM登場以前から大事にされてきた基本プロセスで、最初にここを明確にすることが重要です。
不正検知システムの要件は多岐にわたりますが、「不正検知システムに必要な要件をリストアップしてください」という単純なプロンプトをLLMに投げかけるだけで、初期の検討事項を効率的に抽出できます。LLMが提示した要件を起点に、より詳細なプロンプトで深掘りしたり、自社特有の状況をLLMに教えたりすることで、要件リストを短時間で確定することができました。
プロンプトエンジニアリングにこだわりすぎる必要はありません。
要件を満たす技術的オプションの洗い出し・技術調査
「XXXといった制約・要件がある中で、データベースとしてDynamoDBを使うべきかAmazon Auroraを使うべきか、メリット・デメリットを洗い出してください」といったプロンプトを実行すると、LLMはベストプラクティスや一般的な比較ポイントを提供してくれます。もちろん、LLMの出力を鵜呑みにはせず、さらなる対話で深堀りしたり、追加情報を与えたり、自分の経験や検証を通じて最終判断を下しますが、LLMは情報探索の初動を大幅に短縮してくれました。
新しいサービスやツール、フレームワークの特徴を調べる際にも、短時間で概要を理解し、その後の技術選定や実装をスピーディに進めることができました。
オプションの洗い出しでは、ChatGPTのo1系モデルとの対話が特に効果的でした。
PoC実装
これも技術調査の一環ではありますが、導入を検討している技術やツールの特徴をさらに深く理解するために、実際に使ってみることは重要です。
たとえばパラメータ化テストを書きたい時、LLMに「XXXのテストを書きたい。pytestとparametrizeを使って書いてください」と指示することで、基本的な実装パターンを素早く把握できました。
特にコード生成においては、cursor + o1-mini or Claude 3.5 Sonnet がいい感じでした。
ドキュメントの執筆・技術選定
Design DocやADRを書く際にも、LLMは有用でした。これまでの活動で技術選定の背景は出揃っているので、それをプロンプトに加えつつ、LLMに「以上の背景を踏まえて、XXXとしていくつか選択肢を上げ、それぞれのメリット・デメリットを提示しつつ、ADRとしてまとめてください」のように指示することで最初のたたき台を高速に書き出してくれました。
これまでと同様に、必要な情報の追加や対話による深掘りを重ね、最終的な微調整と整合性の確認を人間が行うことで、ドキュメント作成の効率が大幅に向上しました。
文書作成においては、ChatGPTでo1系のモデルで対話していくのがいい感じでした。また、一緒に文書を編集できるcanvas機能も便利でした。
本実装
基本的にはPoC実装と同じですが、より効率的な書き方や、テストコードの生成、自分が指示した設計への書き換えなどでLLMが助けになりました。
これらの効率化により、全体のリリース期間を大幅に短縮することができました。
学び
設計から実装まで、LLMが全てのプロセスをスピードアップしてくれました。特に、オプションの洗い出しや初稿の作成がとにかく速いので、考え方や追加の制約などを付け足してあげることで、より良い解決策に誘導してあげるという感覚がありました。
ただし、現状のLLMではまだ、方向性や考え方、理想や美学といった高次の判断を人間が指示する必要があると感じました。個人的にはAGIが近い将来に出てくると考えており、もっと多くの業務を任せられる時代が来ることを期待しています。
おわりに
LLMを活用して何とかリリースできましたが、不正利用との戦いはまだまだ続きます。毎週のように新しい不正パターンが出てきており、犯罪者ほんとに許せないなと感じる日々です。
バクラクカードは、法人向けクレジットカードに関する様々な課題を解決し、企業のガバナンスと利便性の両面を強化するサービスです。
今後もしっかりと対策を講じ、事業の持続可能性を高めつつ、お客様への価値提供を続けていきます！
ということで、最後までお読みいただきありがとうございました！
