Fintech事業部の2025年起きたAI効率化の話、あるいはラーメンの話

はじめましての人ははじめまして！そうでない人はお久しぶりです！ LayerX Fintech事業部でVPoEを担当しています、 takochuu です。

この記事は、LayerX Tech Advent Calendar 2025 の 24 日目の記事です。
23日目は、「バクラク事業部のデータ基盤 2025: 今年一年の変化を振り返るの巻」でした。
tech.layerx.co.jp

最近は速い車に乗るのが趣味です。
最近ゴルフもはじめました。ゴルフ誘ってください。車出しますよ！

さて、唐突ですが2025年のLayerX Fintech事業部は複数のプロダクトを高速に改善・リリースし続けているチームです。
その中で、QA（品質保証）はプロダクトの信頼性を支える重要な役割を担っていますが、同時に以下のような課題を抱えていました。
1. テストケースの作成・更新コストが高い
2. 仕様変更にQAが追いつきづらい
3. 人手によるレビュー・確認作業がボトルネックになる

これらの課題に対して、私たちは LLMを活用したQA効率化に取り組みましたので、その顛末を書こうと思います。

これまでのFintech事業部のQAについて

まず前提としてFintech事業部の開発はV字モデルの考え方を基に設計されています。
要求分析・要件定義をPdMの責任として、要件定義から単体テストまではエンジニアの責任として、結合テストから受け入れテストはQAエンジニアの責任としています。
これまでは上記フェーズにおける「テストケース作成」「実行」はQAエンジニアが手で行っていましたが、プロジェクトのスケジュールが重なり上記のスケジュールが重複する状態になると、QAエンジニアは一人しかいないためQAが渋滞するという状況が度々発生していました。

FintechにおけるQAの難しさ

また、我々が運用しているALTERNA(オルタナ)は、投資家の皆様に見えている画面だけではなく、裏側の運用システムまで全て開発チームがフルスクラッチで作成しているので、一般的なWebサービス以上に複雑なコンポーネントが存在しており高い品質が求められます。
例として、投資家の皆様の税金を計算して納税・還付を行うなど、一般的な複雑さ以上のQAもQAエンジニア一人で担当しなければなりません。
その他にも、以下のような特徴が存在しています。
1. 業務フローが複雑
2. 金額・数値計算の正確性が必須
3. 法規制や会計要件が絡む

一方で、QAが複雑なことを理由にプロダクトをデリバリーするスピードは落としたくありません。
「QAを厚くすると遅くなる」「速くすると抜け漏れが増える」というトレードオフをどう乗り越えるかが課題でした。

LLMの使い方

QAのLLM化を進めるにあたって、QAエンジニア一人、エンジニア一人で自動化の調査をはじめました。
初版についてはCursor、Devinを用いてテストケース作成の自動化をテストしてみることにしました。
プロンプトは以下のようなものを利用し、作成されたケースが2枚目になります。

作成されたケースは130ケースほどあり、テストケース作成の効率化が実現できました。
とはいえ、加筆修正が必要ないレベルで洗練されているかと言えば、まだそこまでではありませんでした。

バージョン2への歩み

仕様書からのテスト観点・テストケース生成

バージョン1はプルリクを起点にNotionを利用しましたが、次に取り組んだのが仕様書・デザイン（Notion、Figma、Figjamなどのpdf）を入力としてテストケースのCSVを出力させることにしました。
また、一般的なテスト技法(デシジョンテーブルや同値分割など)も併せて入力し、以下のようなことを実施しました。
1. テスト観点の洗い出し
2. 正常系／異常系／境界値の整理
3. テストケースのたたき生成

をLLMに行わせることです。テスト時はGPT5.1・GPT5.2でテストして出力された結果がこちらです。

既存テストケースのレビュー・改善支援

更に、既存のテストケースとコードの差分をCodexなどのソースコードを読み込めるLLMを利用し、既存のプルリクエストがテストケースを満たすか確認するようにしました。
↓実際のアウトプット

このように、エンジニアが作成したコードからケースを満たしていない部分の検出までは行うことができています。
ただ、注意点もあり、「UIがない開発(管理画面など)ではinputが少なくなり、効果的ではなくなる」状況なので、これを解決することと、自動でテストしてくれる君(seleniumなどのテスト自動化エージェントを用いるもの)を実用化していくのが2025年下期の戦略目標です。