SaaS拡大期の成長痛 モジュラーモノリスへのリアーキと生成AIの活用

SaaS拡大期の成長痛 〜モジュラーモノリスへのリアーキと生成AIの活用〜 アーキテクチャConference 2025 Koki Imanaka / Renma Yamazaki © Finatext Holdings Ltd.

Finatextグループの紹介 © Finatext Holdings Ltd. 1

Finatextグループの紹介 顧客志向の金融サービスを開発・展開するFintechベンチャー 設立 上場 社員数 2013年12月 2021年12月 406名 ※ 東京証券取引所グロース市場 （証券コード：4419） 2025年10月現在 大手金融機関を中心に幅広く協業させていただいております © Finatext Holdings Ltd. 2

Finatextグループの紹介 グループのミッション 金融をサービスとして再発明する © Finatext Holdings Ltd. 3

Finatextグループの紹介 2014年のビジネス開始以来徐々にケイパビリティを拡大 現在は複数領域で事業を展開 事業セグメント フィン テック シフト (2014-) プロダクト・開発実績 toCサービス toBソリューション サービス インフラストラクチャ • 金融機関のDXニーズに対応したフロントエンドの アプリケーションの開発や汎用的な技術ソリューションを提供 • システム開発だけでなく事業企画やマーケティング支援も行う ビッグ データ 解析 (2016-) Nowcast • 機関投資家や公的機関に対して、オルタナティブデータを提供 • POSやクレジットカードデータのクレンジングや解析に関する 知見を保有 • 国内データホルダーとのリレーションを構築 金融 インフラス トラクチャ • 資産運用・保険ビジネス向けのクラウドネイティブかつAPI (2018-) ベースのインフラストラクチャを提供 © Finatext Holdings Ltd. 4

Finatextグループの紹介 金融インフラストラクチャ領域の展開 ● 金融領域（ドメイン）ごとの機能を有した、マルチテナントのSaaSプラットフォームを提供 ○ 証券・保険・クレジット（貸金）の基幹システムを提供しつつ、 その上で実現されたtoC向けのプロダクトも協業で開発・運用している フロントサー ビスA フロントサー ビスB フロントサー ビスC フロントサー ビスD フロントサー ビスE フロントサー ビスF パートナー 企業A パートナー 企業B パートナー 企業C パートナー 企業D パートナー 企業E パートナー 企業F 協業 証券事業領域 SaaS 協業 保険事業領域 SaaS © Finatext Holdings Ltd. 協業 クレジット事業領域 SaaS 5

Finatextグループの紹介 ● 今中 公紀（Koki Imanaka） ● 山崎 蓮馬（Renma Yamazaki） ○ 株式会社 Finatext ○ 株式会社 Finatext ○ Insuretech team リードエンジニア ○ Insuretech team リードエンジニア ○ 東京大学大学院 → H.I.S. →現職 ○ 東北大学大学院 → Simplex、他 →現職 © Finatext Holdings Ltd. 6

昨年のアーキテクチャConference登壇 © Finatext Holdings Ltd. 7

昨年のアーキテクチャConference登壇 最大公約数的アーキテクチャで個別実装から脱却する ～認証認可基盤の共通化に向けた取り組み～ ● ● ● グループ全体で個別に実装されていた認証認可を共通化できる基盤を作成 保険と証券、自社プロダクトなど幅広く展開済み 今回はその続編: 保険SaaS「Inspire」のリアーキテクチャについて https://www.docswell.com/s/s4ichi/KQR96J-gcd-authn-authz © Finatext Holdings Ltd. 8

• https://www.docswell.com/s/s4ichi/KQR96J-gcd-authn-authz

について © Finatext Holdings Ltd. 9

Inspireについて SaaS型デジタル保険システム ● 保険ビジネスをするうえで必要となる 一連の業務システムをAPIベースで 提供する次世代基幹システム ● 新規保険商品の導入を短期間で実現し、 低コストかつスピーディーな 事業展開を実現 ● 高度な商品設計を可能にする、 柔軟性・拡張性の高いスキーマ設計 （特許取得済） © Finatext Holdings Ltd. 10

Inspireについて Inspireの機能概観 © Finatext Holdings Ltd. 11

Inspireについて 今回のリアーキテクチャの範囲 © Finatext Holdings Ltd. 12

Inspireについて ファーストフェーズで 考えなければいけないあらゆる状況 ● 保険はいくらでも複雑な商品設計になり得る ○ ● 同じ保険でも年次で商品改定があり得る ○ ● 何が共通概念になり、何が個別要件になるかを慎重に見極める必要性 商品性の違いによってはフルスクラッチで作らなければならない ○ ● いつから販売しているのか、いつから加入しているのかで保険の内容が変わる可能性 同じ種類の保険でも会社によって内容が異なる ○ ● 例えばデリバティブにも対応できるような柔軟性・拡張性が求められる可能性 設計・開発・運用などの各種フェーズにおいてリソースが逼迫する可能性 フルサイクルエンジニア+ドメイン知識を持つ人材の希少性 ○ 適切なリソース配分ができなければプロジェクトが失敗する可能性 © Finatext Holdings Ltd. 13

Inspireについて ファーストフェーズのアーキテクチャ思慮 ● Core APIサーバーで、全テナント（保険会社・保険代理店）共通の保険ロジックを提供 ● 各テナント毎にBFF（Backend For Frontend）を配置 ○ ○ ○ ● Core API + BFF + CSR（Client Side Rendering）構成 ○ ○ ○ ● 当時はカスタマイズがあることはわかっていたが、どうカスタマイズが入るのかが未知数だった 何が共通概念なのか（Coreにあるべきか）が明確でないうちは、BFFレイヤーで吸収する 明らかに個社要件でカスタマイズが必要な場合も、このレイヤーで吸収 Core APIはモノリスで開発 同じAPIを利用して違うフロントサービスを作ることもあったため、 フロントエンドUIだけ取り扱いやすくするCSRを採用 CSRであれば当時のAWS Amplifyのマネージドホスティングの恩恵を受けられた （ゆくゆくは共通BFFという構想） © Finatext Holdings Ltd. 14

Inspireについて ファーストフェーズのアーキテクチャイメージ 保険会社用コンソール 代理店用コンソール Frontend Frontend 代理店B サービス 保険会社A サービス BFF Frontend BFF Frontend BFF Frontend ••• 共通化できる領域を取り込みながら、 徐々に増え続けるサービス BFF Core API © Finatext Holdings Ltd. 15

Inspireについて 技術スタック © Finatext Holdings Ltd. 16

Inspireについて 数年の運用を経て、課題が見えてきた ● BFF + CSR構成のサービスの乱立 ● シンプルなモノリシックリポジトリの限界 ● 完全なるマルチテナントとセキュリティ要求のトレードオフ ● グローバル対応 © Finatext Holdings Ltd. 17

現行アーキテクチャの課題 © Finatext Holdings Ltd. 18

現行アーキテクチャの課題 BFF + CSR構成のサービスの乱立 ● 単純にプロジェクト数が増大し、Coreの設計・開発に割く時間が十分に取れない ○ ○ ● 各プロジェクトへの対応が常に最優先になりがちで、その場しのぎの横展開も増える 個社ごとにBFFを管理するコストも増えてきた 各プロジェクトの差異を見極める難易度の高さ ○ ○ ○ 横展開の際に、仕様から文言レベルまでの様々な差異を意識できるかは難しい 抽象化・汎用化するとなると更に難易度がはね上がる 共通と思っていたものが、エンハンスフェーズになって微妙な違いを持つようになっていたりして、 微妙に違う仕様をメンテナンスするコストも増えてきた © Finatext Holdings Ltd. 19

現行アーキテクチャの課題 BFF構成による課題 ● ドメインロジックがBFF側に流出 ○ ○ ● トランザクション管理が難しい ○ ● 難しいユースケースは一旦BFFで回避しようとした結果、 Coreにプリミティブなものが多くなった BFFに複雑なユースケースを実現するためのドメイン知識が流出 BFFからCore APIを複数呼び出すため、一つのAPIでトランザクションを担保できない リソース定義の重複 ○ ○ 修正する時にCoreとBFFの両方の修正が必要になる 個社実装の吸収という役割から多少のカスタマイズが入っている場合があり、修正をそのまま取り込め ないケースもある © Finatext Holdings Ltd. 20

現行アーキテクチャの課題 シンプルなモノリシックリポジトリの限界 ● 当初のモノリスという選択について ○ ○ ○ ○ ● 開発初期はプロパーエンジニア2名体制だった PMFの検証をするためにもスピーディなリリースが求められていた 適切なマイクロサービスやモジュールに分割できるだけの十分なドメイン知識もなかった モノリスから始める選択は合理的であった 現在の開発体制 ○ ○ ○ プロパーエンジニアが十数名以上になった コードベースも肥大化しつつあり、影響範囲の特定も知識が必要になってきた 一方でドメインに対する解像度はあがり、境界づけられたコンテキストも見えてきた © Finatext Holdings Ltd. 21

現行アーキテクチャの課題 完全なるマルチテナントと セキュリティ要求のトレードオフ ● 完全なるSaaSとして利用することが難しいテナント ○ 金融業界あるあるかもしれない ● セキュリティチェックシートがオンプレ時代の項目から変わらない ● 厳格なリソースの分離・コントロールの必要性がうったえられる場面 ○ ○ テナントごとに物理的にDBを分けていないと利用できない -> シングルテナント テナント内のこのユーザだけしかアクセスできないようにして欲しい -> リソース可視性制御の難しさ © Finatext Holdings Ltd. 22

現行アーキテクチャの課題 グローバル対応 ● 時刻の取り扱い これまでは国内サービスの提供がほとんどだったため、 日本時間の取り扱いだけ注意すれば良かった ○ ● 通貨 ○ 時刻同様、日本円の整数値のみの取り扱いだけ考慮していれば良かった © Finatext Holdings Ltd. 23

現行アーキテクチャの課題 リアーキテクチャという意思決定と 我々が考える理想 ● モジュラーモノリス ○ ○ ● イベント駆動 ○ ○ ● ドメインイベントを活用した非同期処理 個社ロジックをLambdaでフック 全社共通の認証認可基盤 ○ ● BFFのロジックを共通・汎用的に設計し直して、ロジックをCoreに集約 モジュール境界を明確にして疎結合に保つ IAM的な可視性ポリシーの導入 AWSの新機能をフル活用 ○ ○ Amplify Gen 2 RDS Data API © Finatext Holdings Ltd. 24

リアーキテクチャ © Finatext Holdings Ltd. 25

リアーキテクチャ モジュラーモノリスとは？ ● ● マイクロサービスとモノリスの中 間的アーキテクチャ 具体的な仕様は言及されておらず 緩い定義 ○ 一つのアプリとしてデプロイさ ○ ○ ● れる（モノリス） 内部はモジュールという単位で 分離している 各モジュールにPublic APIを定 義 モジュール同士はPublic APIを介 して連携することで、お互いの詳 細を隠蔽 What Is a Modular Monolith? https://www.milanjovanovic.tech/blog/what-is-a-modular-monolith © Finatext Holdings Ltd. 26

• https://www.milanjovanovic.tech/blog/what-is-a-modular-monolith

リアーキテクチャ 我々が目指したい アーキテクチャ構成 ● クリーンアーキテクチャをベースに設計 ● ○ Usecase層以下のレイヤーをモジュール単位で分割 他のモジュールから呼び出すことができるUsecaseはPublic API として公開 Handler Application ディレクトリ構成 app/ ├── internal/ │ └── module/ │ ├── Aモジュール/ │ │ ├── internal/ <-モジュール内部の詳細は隠蔽 │ │ │ ├── domain/ │ │ │ ├── infra/ │ │ │ └── usecase/ │ │ └── usecase.go <- Public APIを定義 │ ├── Bモジュール/ © Finatext Holdings Ltd. Public API Public API Usecase Usecase Domain Domain Infrastructure Infrastructure 契約管理モジュール 通知モジュール 27

リアーキテクチャ モジュールとDBの構成 共有DB モジュールA ● モジュールA モジュールB ⭕ トランザクション利用 ⭕ モジュール単位でスケール ⭕ 運用負荷が低い ⭕ 独立性が高い 保険ドメインの特性 ○ ○ ● モジュールB モジュールごとのDB 金融商品ゆえにデータの完全性や整合性は最重要 商品性からあまりにも高いリクエスト数は考えづらい 稼働中のサービス影響 ○ ○ 既に稼働しているサービスへの影響は極力減らしたい リアーキ活動の負荷もなるべく減らしたい © Finatext Holdings Ltd. 28

リアーキテクチャ 共有DBのデメリットへの対策 ● モジュールの独立性 ○ 物理的には共有しつつ、論理的には分離させる モジュールA モジュールB テーブル モジュールA ● モジュールB Public API モジュールB テーブル スケーラビリティ ○ ○ ○ 会社によってはストレージをテナント単位で完全に隔離して欲しいという要望があった 通常: マルチテナント共有のDB オプション: 専用のDBによってRDSの最大のインスタンスまでスケール可能に © Finatext Holdings Ltd. 29

リアーキテクチャ モジュール間の連携パターン ● ● 詳細な仕様はなくPublic APIを介した呼び出しのみを定義している 事例を調べてみると4つの連携パターンがあった パターン 種類 具体例 ① モジュール間の 直接呼び出し 同期 契約モジュールが決済モジュールの executePayment() を呼び出す ② Application レイヤー経由 同期 Applicationレイヤーが契約、決済、通知の3つのモジュールを順次呼び出し ③ イベント駆動 同期 契約成立処理と同時に成立イベントを発行し、 同じプロセス中で通知モジュールがイベントを受け取り契約成立メールを発行 ④ イベント駆動 非同期 契約成立処理と同時に成立イベントをエンキュー、 通知モジュールはキューから取り出し契約成立メールを発行 © Finatext Holdings Ltd. 30

リアーキテクチャ 同期と非同期の使い分けについて ● 非同期イベント駆動の利点 ○ ○ ○ ● ● 疎結合によってモジュールが独立 障害の局所化できる 拡張性が高い 即時性・即時整合性が必要 → 同期 それ以外の結果的整合性で良い場合 → 非同期 x イベント駆動 © Finatext Holdings Ltd. 31

リアーキテクチャ 非同期イベント駆動 ● 非同期は不整合に注意する必要がある ○ ○ ● ドメインの更新のトランザクションが成功して、 イベントのpushは失敗 イベントはpushできたが、データベースへの保存 が失敗と言った不整合が起こりえる 非同期処理の不整合を防止するため 「アウトボックスパターン」をベースに実装 ○ ビジネスロジックとイベントを同一トランザクショ ン内で発行することで不整合を防止 © Finatext Holdings Ltd. 32

リアーキテクチャ 同期3パターンの比較 ● ① 呼び出し方は3つあるが、依存の性質が違っている パターン 種類 具体例 ① モジュール間の 直接呼び出し 同期 契約モジュールが決済モジュールの executePayment() を呼び出す ② Application レイヤー経由 同期 Applicationレイヤーが契約、決済、通知の3つのモジュールを順次呼び出し ③ イベント駆動 同期 契約成立処理と同時に成立イベントを発行し、 同じプロセス中で通知モジュールがイベントを受け取り契約成立メールを発行 契約モジュール ② Application層 決済モジュール 契約モジュール 決済モジュール © Finatext Holdings Ltd. ③ 通知モジュール 契約モジュール 通知モジュール 33

リアーキテクチャ 同期3パターンを比較検討して 採用した2パターン ● ① モジュール間の直接呼び出し ○ ドメイン的に密結合な関係（例：注文→決済） ● ② Applicationレイヤー経由 ○ 複数モジュールの協調処理を明示的に記述 ● 同期イベント駆動の課題：認知負荷が高い ○ ○ ○ ○ ● イベントハンドラの実行順序の制御が複雑 暗黙的な処理フローで可読性が低い 気づかずデグレさせるリスク デバッグ・トレーシングの難易度が高い 段階的な導入 ○ ○ まずはシンプルで可読性の高い実装から 必要性が明確になった時点で再検討 © Finatext Holdings Ltd. 34

リアーキテクチャ 同期処理のトランザクション管理 ● トランザクション境界の課題 ○ ○ ○ ● Applicationレイヤーで複数モジュールをまとめて制御したい Usecase単位でトランザクションが必要 UsecaseがUsecaseを呼ぶケースでネストが発生 採用した方針：外側のトランザクションを優先 ○ ○ 上位レイヤーで既にトランザクションが開始されている場合 → 内側のトランザクション宣言は無視し既存トランザクションに参加 トランザクション境界を明示的にコントロール可能 例1) Application層でトランザクション開始 ○ 配下の全Usecaseが同一トランザクション内で実行 ● 例2) Usecase単独呼び出し ● ○ そのUsecaseでトランザクション開始 © Finatext Holdings Ltd. 35

リアーキテクチャ 権限管理・リソース可視性制御について ● B2Bでは複雑な可視性制御が求められる ○ ○ ○ ● 部署や人ごとのアクセス可否 関連会社からのアクセス SaaSなのでこれらを汎用的に打ち取る 必要がある ミドルウェアレイヤーで透過的な 可視性制御を実施 ○ ○ ○ ○ ユーザーから受け取ったJWTからアクセス できるスコープを特定 ユーザーやロールの情報をベースに ポリシーを作成しcontextに設定 DBレイヤーでの自動的にフィルター ミドルウェアレイヤーでレスポンス時に 自動チェック © Finatext Holdings Ltd. 36

リアーキテクチャ AWSの新機能をフル活用 保険会社や代理店が利用する管理コンソールを刷新 ● Amplify Gen 2でSSRサポートが手厚くなった ○ ○ ○ ● BFF + CSR構成をやめてSSRに ■ 内部的にはLambda Edge サイドカー的にFunctionsでLambdaをProxyやBatchとして実装するのが容易 フロント、サーバ、IaCなどに分散していたコードを、一元管理可能に RDS Data APIをSSRで利用可能になった ○ ○ ○ HTTPSでRDSがコール可能に（トランザクションも張れる） 前述のSSR化のおかげで、フロントエンド裏のLambdaから直接RDSを扱える！ ■ 今まで全てAPIサーバを通さなければならなかった手間が緩和 管理コンソールでのみ利用するデータソースを、サーバサイドを意識せず使える ■ サーバサイドを待たずにプロアクティブに開発が可能に © Finatext Holdings Ltd. 37

リアーキテクチャ AWSの新機能をフル活用 保険会社や代理店が利用する管理コンソールを刷新 ● Amplify Gen 2でSSRサポートが手厚くなった ○ ○ ○ ● BFF + CSR構成をやめてSSRに ■ 内部的にはLambda Edge サイドカー的にFunctionsでLambdaをProxyやBatchとして実装するのが容易 フロント、サーバ、IaCなどに分散していたコードを、一元管理可能に RDS Data APIをSSRで利用可能になった ○ ○ ○ HTTPSでRDSがコール可能に（トランザクションも張れる） 前述のSSR化のおかげで、フロントエンド裏のLambdaから直接RDSを扱える！ ■ 今まで全てAPIサーバを通さなければならなかった手間が緩和 管理コンソールでのみ利用するデータソースを、サーバサイドを意識せず使える ■ サーバサイドを待たずにプロアクティブに開発が可能に 以前よりも開発効率が向上し、よりスピーディーな機能提供が可能に © Finatext Holdings Ltd. 38

リアーキテクチャでの生成AIの活用 © Finatext Holdings Ltd. 39

リアーキテクチャでの生成AIの活用 背景と期待 ● 背景 ○ ● リアーキプロジェクトを検討し始めたのが2025年の初め、 ちょうどClaudeCodeなどのAgentic AIが実用的になってきた時期 リアーキテクチャと相性は？ ○ ○ ○ 明確な変更指針があり、コード量も比較的膨大 既存コードを参照可能なので、ドメインに紐付くサンプルは多い 繰り返しの作業が多いが、丸コピではなく微妙に差分がある ベースのアーキテクチャができれば、横展開を大幅に効率化できるのでは？ © Finatext Holdings Ltd. 40

リアーキテクチャでの生成AIの活用 Finatextでの生成AI活用状況（2025年4月時点） © Finatext Holdings Ltd. 41

リアーキテクチャでの生成AIの活用 Claude Codeでとりあえずやってみた ● 試したこと：「契約の更新APIを移行して」 既存のCore APIの実装コードを、移行先のコードに変換してもらう ○ ● 結果：見た目はなんとなくそれっぽいものができた ● 問題 ○ ○ ○ ○ 元々あったロジックがない、あるいは存在しなかったロジックが追加されている（ハルシネーション） フィールドや型が踏襲できてない、知らないフィールドが追加・削除されている 出力も安定しない コーディング規約が守られていない 思ってたよりは上手くはいかなかったので もう少し生成AI活用に向き合ってみる © Finatext Holdings Ltd. 42

リアーキテクチャでの生成AIの活用 生成AIを活用するためのアイデア ● テスト駆動開発（TDD）の導入 ● ナレッジを共有する ● タスクを分解する © Finatext Holdings Ltd. 43

リアーキテクチャでの生成AIの活用 テスト駆動開発（TDD）の導入 ● 生成AIには明確な指示が必要 ○ ○ なぜなら、生成AIは指示から可能性の高い期待値を予測して出力している そのため指示が抽象的だと、アウトプットもブレてしまう ● TDDは非常に明確な指示が可能 ○ ○ 期待する結果をテストとして実装し、 それを達成する実装を追加する AnthropicのBest Practiceの記事でも紹介されている ● 試したこと：「テスト駆動で契約の更新APIを移行して」 ● 結果：テスト駆動では実装された ○ ○ ○ ⭕ 実装はクリーンになった ❌ ロジックがたりてないところが散見 ❌ コーディング規約の課題も継続 © Finatext Holdings Ltd. 44

リアーキテクチャでの生成AIの活用 ナレッジを共有する ● 生成AIにコーディング規約を共有してあげる ○ ○ 生成AIは毎回ゼロベースで会話が始まる 開発メンバーであれば知っている「暗黙知」はわからない ● CLAUDE.mdにナレッジを明文化していく ○ ○ ○ ○ ● アーキテクチャ エラーハンドリング Gitのワークフロー 今の設計に至る歴史的背景、etc. 結果：コーディングの品質が徐々に上がるようになった © Finatext Holdings Ltd. 45

• http://claude.md

リアーキテクチャでの生成AIの活用 タスクを分解する ● 大きなタスクを段階に分解する ○ ○ ● 「移行」と一言で伝えていたが実行までには複数のステップが存在する AnthropicのBest Practiceの記事でも「段階的アプローチ」として紹介 自分ならどう進めるかを考えてタスクを分解して、プロンプトを作成 ○ 旧実装のIF、仕様についての調査 ○ 新アーキテクチャにおける実装の設計 ○ 調査や設計で疑問点があればそれを確認 ○ 調べた要件に応じてTDDで実装 各フェーズにおける作業や期待するアウトプットを明示したことによって アウトプットの質が上がった © Finatext Holdings Ltd. 46

リアーキテクチャでの生成AIの活用 コンテキストウィンドウの制約 ● コンテキストウィンドウとは 生成AIが一度に処理できる情報量の上限 ○ ○ 会話履歴、ファイル内容、指示などすべてがここに含まれる ● 発生した問題 突然おかしな修正をしだす ○ ○ ● 手前の調査内容を無視した修正を行う 原因 コンテキストウィンドウが90%を超えていた コンテキストウィンドウが逼迫すると古い情報（初期の方針）が押し出される AnthropicのBest Practiceでも定期的に「/clear」を実行することを推奨 ○ ○ ○ ● 課題 ○ プロンプトなしでこれを自動的にやるのは難しく、経緯を忘れられても困る © Finatext Holdings Ltd. 47

リアーキテクチャでの生成AIの活用 Claude Code Subagentによる解決 ● Subagentとは ○ ○ 別の独立したコンテキストウィンドウで動作する仕組み 親エージェントとは完全に分離 ● 役割分担 ○ ○ 親エージェントはタスクの段取りを管理 実際の調査や実装などはSubagentで実行する ● 重い調査を別のコンテキストで処理して結果のみ親エージェントが受け取り後続の処理を実行す ることでコンテキストウィンドウの逼迫を防ぐことができた © Finatext Holdings Ltd. 48

リアーキテクチャでの生成AIの活用 実際にやってみた感想 ● これらの取り組みにより複雑すぎないケースでは精度よく実装ができるようになった ● 意図せぬコードが生成された時は、進めるのではなくてプロンプトやCLAUDE.mdを見直してリ トライすると改善が評価しやすい ○ さらにうまくいったものはリポジトリーにコミットすることでみんなでシェア、ブラッシュアップがで きる ● 一方で自分で実装しているのと比べると気づきが少ない ○ ○ 普段の開発であれば改善やインサイトを得られていたがアウトプットをレビューしているだけでは得ら れない まずは移行プロンプトで移行しつつ、怪しいところがあったらペアプロに切り替えて実施するとよかっ た リアーキテクチャや技術的負債の返済へのハードルがぐっと下がった！ © Finatext Holdings Ltd. 49

• http://claude.md

今後の展望 これから取り組むこと ● 新アーキテクチャの移行展開 ○ ● アーキテクチャをさらにアップデートする ○ ○ ○ ● 現行システムの機能の移管を推進中 今回実現できなかった課題への対応 モジュール分割・テスト容易性のさらなる改善 生成AI活用の拡大 ○ ○ ● 新規・既存プロジェクトで順次リリース 開発フェーズでの活用 → 運用・保守フェーズへ AI機能のプロダクト組み込みを加速 一緒に挑戦してくれる仲間を募集中！ ○ ○ SaaS基盤の進化に興味がある方 金融×テクノロジーで社会課題を解決したい方 © Finatext Holdings Ltd. 50

株式会社 Finatext Ask the speaker, 採用情報 ● 発表後の Ask the speaker は Finatext の企業ブースでやっています ○ 事業・発表に興味を持った方・質問あるかたはブースまで（H会場入口付近です） Finatext 採用情報: https://hd.finatext.com/recruit/ © Finatext Holdings Ltd. 51

• https://hd.finatext.com/recruit/