この記事は、Finatext Advent Calendar 2025 の3日目の記事です。
こんにちは！Finatextでリードエンジニアをしている山崎です。
本記事は、先日開催されたアーキテクチャConference 2025にて発表した
「SaaS拡大期の成長痛〜モジュラーモノリスへのリアーキと生成AIの活用〜」
というタイトルについて、当日語った内容に少し補足をした紹介になっています。
会社としてブースも出展させて頂き、まだFinatextのことを知らなかった多くの方に、弊社の魅力を少なからずお伝えできたかと思います。そちらの様子は本記事の最後にリンクを記載しておくので、ぜひ目を通してみてください。
アーキテクチャConference とは？
「アーキテクチャConference」は、ファインディ株式会社が主催する、アーキテクチャ設計をテーマにした日本最大級のテックカンファレンスです。技術の進化と組織の多様化が進む中で、より良いアーキテクチャをいかに描き、どう実現していくかを考える場として開催されています。
2回目の開催となる今回は、「技術の変化が加速し組織やツールが多様化する今、最適なアーキテクチャをどう描くか。」をテーマに、各社が直面してきた実例やその意思決定プロセスを軸に構成されていました。参加申込者数は5,000名を突破し、セッションの会場参加枠は満席続出という大盛況ぶりでした。
当社は昨年に引き続き2度目の協賛となり、今回もゴールドスポンサーとして参加しました。
発表内容
弊社が提供するSaaS型の保険システムInspireのリアーキテクチャについて発表しました。
ここで、弊社はフィンテックベンチャーであるため、発表内容も一般的なシステム開発の話よりは少々理解しづらい場合があります。保険システムって何？保険ってそもそもどういう仕組み？など、事前知識などが無い視聴者を置いてけぼりにしかねません。
そのため、できる限り多くの人に今回の発表内容に納得感を持ってもらうため、保険システムの役割や概要、どうして当時そういった意思決定をしたのかなどの背景を丁寧に説明するようなストーリーで資料を作成しました。
- グループの事業概要
- 保険システムInspireの概要
- ゼロイチフェーズで何を考えていたか
- 実際にどんなアーキテクチャになったか
- 数年の運用を経て出てきた課題
- 課題解決のためのリアーキテクチャ
- 生成AIでリアーキテクチャにチャレンジ
- これからの取り組み
1. グループの事業概要
グループ全体として「金融領域のサービス開発・汎用技術支援」「オルタナティブデータを活用したビッグデータ解析」「クラウドネイティブな金融インフラの提供」といった事業を展開しています。
また、グループに証券会社や少額短期保険会社、貸金会社など金融領域の事業会社も抱えており、我々が第一人者として金融事業も行なっているという、国内でもなかなか見られないユニークな企業体になっています。
金融インフラストラクチャ事業では、各ドメイン（証券、保険、貸金などの領域をドメインと呼んでいます）ごとに基幹システムを開発しており、パートナー企業がそれを利用する形で、それぞれの企業が新しいサービスを開発・運用するような構図になっています。
2. 保険システムInspireの概要
Inspireは、保険ビジネスをするうえで必要となるAPIを「お客さま向け」「業務向け」それぞれで提供しています。パートナー企業は、このAPIを利用してお客さま向けのサービスを開発・提供しつつ、管理コンソールと呼ばれる業務システム画面を利用して、保険業務を行うことが可能です
Inspireが提供する機能概観です。お客さまが利用するサービス上では主に商品説明や見積もり、申し込みや契約管理、そして保険金請求などの機能が必要になります。
一方、管理コンソールでは更に細かい機能が必要になりますが、それらを提供しているコアシステムが今回のリアーキテクチャの対象になっています。
3. ゼロイチフェーズで何を考えていたか
ここで言いたかったことは、とにかく保険（商品）というのはシステム化するには複雑すぎる！ ということです。
金融の世界では法定通貨や株式、債券など様々な形の金融商品がありますが、これらはそれ自体の定義や用途は比較的はっきりしています。
一方で保険は、基本保険約款に自然言語で書かれている内容が商品性になります。保険法や業法における定義は当然ありますが、補償/保証や特約の内容は自然言語よろしく、かなり自由に定義できるため、これをシステムに落とし込むというのはかなり難易度が高いです。
そういった特性の金融商品を扱うシステムを作る際には、「未来に何が起こり得るか」「今の時点で何をやらないか」などを精度高く思慮しながら、アーキテクチャの方向性を決める必要がありました。
4. 実際にどんなアーキテクチャになったか
概要図でも示したように、まずはCore APIサーバーを立てて、ここに保険に関する普遍的なドメインロジックや、各テナント（保険会社や保険代理店）で共通になるようなロジックを提供するようにしました。
そして、各テナント毎にBFF（Backend For Frontend）を用意して、個社固有の実装や、共通化すべきかその時点では不明瞭な要件などをこのレイヤーで吸収するようにしました。
またフロントエンドはCSR（Client Side Rendering）にすることで、サービスを別にしても同じBFFを利用できるようにしたり、フロントエンドUI開発だけに集中できるような構成を目指しました。
AWS Amplify Hostingと非常に相性が良かったのも選定理由の一つです。
この構成は、初期のパートナー開拓においては非常に有用でした。
しかしながら、わかってはいたことですが徐々に管理すべきリポジトリが増え続けていきます。
ブログ記事的には唐突ですが、Insuretech事業におけるスキルスタックもご紹介しておきます。
5. 数年の運用を経て出てきた課題
管理すべきリポジトリが増えるのは想定の範囲内ではありましたが、共通機能としてCoreに落とし込む十分な時間がなかなか取れない時期もあり、既存のBFFの実装を参考に新しいBFFを展開するなど、若干場当たり的な判断をせざるを得ない事もありました。
そもそも、共通化というのはなかなかに難易度が高い技術です。各プロジェクトの微妙な差異を見極め、それを抽象・汎用化してプロダクションにまで持っていくには、それ相応のコストがかかります。
マイクロサービスほどではないにせよ、トランザクション管理が難しいという課題もあります。
6. 課題解決のためのリアーキテクチャ
こういった課題から、リアーキテクチャを決めました。
既存のCoreシステムのリポジトリはモノリシックにモジュール概念を取り込もうとしたキメラのようになっていたのですが、これを全く新しいリポジトリにモジュラーモノリスで実装することにしました。
モジュラーモノリスのベースはクリーンアーキテクチャを採用しました。
クリーンアーキテクチャと言っても詳細の実装方針はそれぞれかと思いますが、上図のようにGo言語ではinternalディレクトリでスコープを切れるなどの特性を利用して、今のアーキテクチャから移行しやすく、かつ取り回しやすい構成を考えました。
代表的なモジュール間連携のパターンを調査し、どういうルールでどのパターンを採用するかを決めていきます。
トランザクションの管理についてです。リアーキ後のシステムでは、まずどの層であってもトランザクションが必要であれば自身の層で開始するようにします。
そして、もし上の層でトランザクションが開始されていれば、それを暗黙的に使い回すという実装にすることで、どの層での実装かを意識せずに整合性を担保できるようにしました。
Coreシステムだけでなく、フロントエンドのアーキテクチャの刷新にもチャレンジしています。
AWS Amplify Gen 2でSSRが手厚くなったため、SPAを基本としたCSRから、SSRに変更しました。
Gen 2ではフロントのリポジトリでLambdaをProxyやBatchとして実装するのが容易になったのも非常に嬉しいです。
そして、比較的新しい機能であるAmazon RDS Data APIをSSRサーバから呼べるようになったのも大きいです。
これまではDB操作にはCoreシステムを介さないといけなかったのが、シンプルな閲覧等の操作であればフロントから直接呼べるため、サーバ側の実装を待つことなく、プロアクティブな開発が可能になりました。
余談ですが、AWSのAmplifyを担当していた方と現地でお話しさせてもらった時に、Gen 2を使ってここまで使い倒しているところはまだ他に無いのではないかと仰っていました笑
7. 生成AIでリアーキテクチャにチャレンジ
ちょうどリアーキテクチャのプロジェクトが始まったのが2025年の始めごろだったのですが、Claude CodeなどのAgentic AIが実用的になってきた時期でした。
リアーキでの活用を考えてみると、リアーキは
- 明確な変更指針があり
- 既存コードがあるので、求められる機能も明確
- 同じような作業の繰り返しの多い作業
という特徴から「ベースのアーキテクチャだけちゃんと作り切れば、横展開はかなり効率的にできるのでは？」と考えました。
とりあえず試してみようと「契約の更新APIを移行して」のようなシンプルな指示を出してみました。
結果としてはなんとなくそれっぽいものはできたのですが、元からあったロジックがなかったり、あるいは存在しないロジックが追加されている、いわゆるハルシネーションが激しく、フィールドや型も踏襲できてませんでした。
改善のために色々と試行錯誤をしてみて、効果的だったのはテスト駆動の導入でした。
生成AIは与えられた指示から、可能性の高い期待値を予測しながら出力をしているので指示が抽象的だと出力も中途半端になってしまう問題が起こります。
AnthropicのBestPracticeとしても紹介されている内容ですが、TDDはこの問題を解決するのに非常に優れており、要件をまずテストとして実装し、それを達成する実装を追加する指示は非常に明確です。
コーディング規約の課題に対応するために「ナレッジを共有する」ということをしました。
生成AIは毎回ゼロベースで会話が始まり、伝えたことを覚えておいてくれません。そのため開発メンバーであれば自然と身につく「暗黙知」がわからないため、ずっと初歩的なところでミスをしてしまいます。
Claude CodeであればCLAUDE.mdというファイルを作成すると、立ち上げた時に自動的にその内容が読み込まれるようになっているため、ここにアーキテクチャやワークフローといったナレッジを共有してあげることで解決することができます。
また、改善を重ねる中でも「ロジックが足りていない問題」にぶち当たります。これに対応するために「タスクを分解する」ということを試しました。
これによってそれぞれのステップで作業する内容が明確になり、期待するアウトプットも明示されているので、生成されるコードの質をあげることができました。
これらの改善方針は、生成AI特有のものではなく、人間にも当てはまるものだと実感しています。AI特有のプロトコルはありますが、今後活用していくためにも、まず（自身も含む）人間であればどうすれば良くなるかを考えるのは肝要だと思います。
8. これからの取り組み
今後の取り組みとして、当然移行を進めていくのもそうですが、新たな機能の拡張をガンガン推進していく必要があります。
また、Inspireは業務システムでもあるため、Inspire自体を生成AIでアップデートするだけでなく、生成AIを業務で使ってもらう、という機能も考えていかなければなりません。
保険業界において、このアップデートをどれだけアグレッシブにできるかは、今後の業界の発展に影響しえる、大義あるミッションです。
まとめ
アーキテクチャConference 2025で発表した内容を、一部ではありますが抜粋して紹介いたしました。
これからの取り組みにも書きましたが、Finatextでは保険業界を変えるかもしれないポテンシャルのあるサービスの開発を手伝ってくれるエンジニアを大募集中です！
カジュアル面談も絶賛募集中です！
一緒に金融業界を変えてきましよう！！
関連リンク
Discussion