Fintech事業部における2025年のAI効率化の取り組み、あるいはラーメンの話
LayerX Fintech事業部が、複雑な金融システムにおけるQAボトルネック解消のため、LLMを活用したテストケース生成とコードレビュー自動化を実践し、V字モデル下での品質担保と開発スピードの両立を試みた事例報告である。
キーポイント
Fintech領域特有のQA課題と背景
投資家向け画面だけでなく裏側の運用システムまでフルスクラッチで構築される複雑な業務フロー、数値計算の厳密性、法規制対応などにより、単一QAエンジニアでの品質保証がボトルネックとなっていた。
LLMを活用したテストケース生成の実践
仕様書やデザイン資料（Notion, Figma 等）を LLM に読み込ませ、デシジョンテーブルや同値分割などの一般技法を適用して、正常系・異常系・境界値を含むテストケースを自動生成するパイプラインを構築した。
コード差分を用いた既存テストレビュー支援
Codex 等のソースコード理解可能な LLM を活用し、開発されたコードと既存のテストケースの整合性を確認することで、抜け漏れ検出を自動化する試みを行った。
今後の戦略：管理画面対応と自動実行エージェント
入力要素が少ない管理画面などでの LLM 活用限界を認識し、2025 年下期の目標として Selenium 等の自動化エージェントによる自動テスト実行の実用化を掲げている。
ラーメン店の紹介
新宿と人形町に店舗を持つ「丁寧系」のハイレベル醤油ラーメン店が紹介され、卓上調味料で味変が可能であることが述べられています。
2025年のラーメン推奨
読者に対し、2025年に食べたオススメのラーメンをTwitterで共有するよう呼びかけが行われています。
影響分析・編集コメントを表示
影響分析
この記事は、AI が単なる生成ツールとしてではなく、QA プロセス全体（設計から実行支援まで）に統合される実証例を示しており、特に金融・会計領域のような高信頼性が求められる業界における AI 活用ガイドラインとして参考価値が高い。また、LLM の限界（入力情報の不足）を客観的に分析し、自動化エージェントとの組み合わせで解決を図る姿勢は、現場レベルでの現実的な AI 導入戦略を示唆している。
編集コメント
金融システムという極めて高い信頼性が求められる領域で、LLM を QA にどう組み込むかという実務的な課題解決事例として非常に興味深いです。特に「管理画面では効果が薄れる」という限界の指摘と、それを自動化エージェントで補完する方針は、現場のエンジニアにとって即座に共感できる洞察です。
はじめましての人ははじめまして！そうでない人はお久しぶりです！ 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を厚くすると遅くなる」「速くすると抜け漏れが増える」というトレードオフをどう乗り越えるかが課題でした。
QAのLLM化を進めるにあたって、QAエンジニア一人、エンジニア一人で自動化の調査をはじめました。 初版についてはCursor、Devinを用いてテストケース作成の自動化をテストしてみることにしました。 プロンプトは以下のようなものを利用し、作成されたケースが2枚目になります。 
作成されたケースは130ケースほどあり、テストケース作成の効率化が実現できました。 とはいえ、加筆修正が必要ないレベルで洗練されているかと言えば、まだそこまでではありませんでした。
仕様書からのテスト観点・テストケース生成
バージョン1はプルリクを起点にNotionを利用しましたが、次に取り組んだのが仕様書・デザイン（Notion、Figma、Figjamなどのpdf）を入力としてテストケースのCSVを出力させることにしました。 また、一般的なテスト技法(デシジョンテーブルや同値分割など)も併せて入力し、以下のようなことを実施しました。 1. テスト観点の洗い出し 2. 正常系／異常系／境界値の整理 3. テストケースのたたき生成
をLLMに行わせることです。テスト時はGPT5.1・GPT5.2でテストして出力された結果がこちらです。 
既存テストケースのレビュー・改善支援
更に、既存のテストケースとコードの差分をCodexなどのソースコードを読み込めるLLMを利用し、既存のプルリクエストがテストケースを満たすか確認するようにしました。 ↓実際のアウトプット 
このように、エンジニアが作成したコードからケースを満たしていない部分の検出までは行うことができています。 ただ、注意点もあり、「UIがない開発(管理画面など)ではinputが少なくなり、効果的ではなくなる」状況なので、これを解決することと、自動でテストしてくれる君(seleniumなどのテスト自動化エージェントを用いるもの)を実用化していくのが2025年下期の戦略目標です。
そして、おすすめのラーメンの話
東京を代表する焦がし味噌ラーメンのお店。 純連やすみれともまた違い、ガツンとした味が特徴的。 行列必至だが、食べた後の満足感は随一。
東京駅KITTEの地下にあるつけ麺の名店「とみ田」の支店。 本店に劣らず、オールウェイズクオリティの高いつけ麺を提供してくれる。 土日や日中は並んでいるが、退勤時などは比較的空いているのでその時間帯がオススメ。
新宿と人形町に店舗を構える「丁寧系」のハイレベル醤油ラーメン。 卓上調味料も充実しており、色々な味変が可能。 比較的人形町店は空いているので、近くにお立ち寄りの際はぜひ
いかがだったでしょうか？ 2025年、みなさんのオススメのラーメンは何でしたか？ よければ、Twitterでオススメのラーメン店を教えて頂けると幸いです。 それでは、Merry Christmas....
原文を表示
はじめましての人ははじめまして！そうでない人はお久しぶりです！ 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を厚くすると遅くなる」「速くすると抜け漏れが増える」というトレードオフをどう乗り越えるかが課題でした。
QAのLLM化を進めるにあたって、QAエンジニア一人、エンジニア一人で自動化の調査をはじめました。 初版についてはCursor、Devinを用いてテストケース作成の自動化をテストしてみることにしました。 プロンプトは以下のようなものを利用し、作成されたケースが2枚目になります。
作成されたケースは130ケースほどあり、テストケース作成の効率化が実現できました。 とはいえ、加筆修正が必要ないレベルで洗練されているかと言えば、まだそこまでではありませんでした。
仕様書からのテスト観点・テストケース生成
バージョン1はプルリクを起点にNotionを利用しましたが、次に取り組んだのが仕様書・デザイン（Notion、Figma、Figjamなどのpdf）を入力としてテストケースのCSVを出力させることにしました。 また、一般的なテスト技法(デシジョンテーブルや同値分割など)も併せて入力し、以下のようなことを実施しました。 1. テスト観点の洗い出し 2. 正常系／異常系／境界値の整理 3. テストケースのたたき生成
をLLMに行わせることです。テスト時はGPT5.1・GPT5.2でテストして出力された結果がこちらです。
既存テストケースのレビュー・改善支援
更に、既存のテストケースとコードの差分をCodexなどのソースコードを読み込めるLLMを利用し、既存のプルリクエストがテストケースを満たすか確認するようにしました。 ↓実際のアウトプット
このように、エンジニアが作成したコードからケースを満たしていない部分の検出までは行うことができています。 ただ、注意点もあり、「UIがない開発(管理画面など)ではinputが少なくなり、効果的ではなくなる」状況なので、これを解決することと、自動でテストしてくれる君(seleniumなどのテスト自動化エージェントを用いるもの)を実用化していくのが2025年下期の戦略目標です。
そして、おすすめのラーメンの話
東京を代表する焦がし味噌ラーメンのお店。 純連やすみれともまた違い、ガツンとした味が特徴的。 行列必至だが、食べた後の満足感は随一。
東京駅KITTEの地下にあるつけ麺の名店「とみ田」の支店。 本店に劣らず、オールウェイズクオリティの高いつけ麺を提供してくれる。 土日や日中は並んでいるが、退勤時などは比較的空いているのでその時間帯がオススメ。
新宿と人形町に店舗を構える「丁寧系」のハイレベル醤油ラーメン。 卓上調味料も充実しており、色々な味変が可能。 比較的人形町店は空いているので、近くにお立ち寄りの際はぜひ
いかがだったでしょうか？ 2025年、みなさんのオススメのラーメンは何でしたか？ よければ、Twitterでオススメのラーメン店を教えて頂けると幸いです。 それでは、Merry Christmas....
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み