2025年12月17日、primeNumberのオフィスにて、アーキテクチャConference 2025の協賛企業6社が集まり、「スケールするサービスにおけるアーキテクチャの工夫・苦労を語る会」を開催しました。
（アーキテクチャConferenceの様子はこちら）
今回のアフターイベントはログラス、スリーシェイク、ビットキー、タイミー、primeNumber、Finatextの6社共催です。
「アーキテクチャに関心が強い」「非連続な成長を遂げている」を共通項として持つ企業が一堂に会し、それぞれのアーキテクチャにおける工夫や苦労を語り合いました。今回はそのレポート記事をお届けします。
- メタ視点で読み解くソフトウェアアーキテクチャ（ログラス 小林達さん）
- クラウドとオンプレミスを組み合わせた機械学習基盤構築の挑戦（スリーシェイク 永瀬滉平さん）
- 【開発を止めるな】機能追加と並行して進めるアーキテクチャ改善（ビットキー 水谷浩明さん）
- 2時間かかっていた月次バッチを10分に短縮したスケーラブルなバッチアーキテクチャ改善（タイミー 金森秀平さん）
- 100以上の新規コネクター提供を可能にしたアーキテクチャ（primeNumber 田代裕基さん）
- SaaSの基幹システムをモジュラーモノリスとして再設計（finatext Dennis Metzgerさん）
メタ視点で読み解くソフトウェアアーキテクチャ（ログラス 小林達さん）
トップバッターは去年7月にログラスに入社し、リアーキテクチャや共通基盤の構築に取り組んでいる小林達さん。
小林さんはアーキテクチャ設計の歴史を振り返り、「オンプレミス時代は物理サーバーの調達が開発スピードを規定し、予測可能性が重視されていたが、クラウド時代では作ってダメなら作り直すアジャイル的なアプローチがインフラ層まで浸透した」と説明。そして生成AI時代の今では、構造を直すリファクタリングより一から作り直すリライトの方が速いという状況になっているそうです。
小林さんはこれからのアーキテクチャについて「Observability（可観測性）」「Fitness Function（適応度関数）」「Disposability（可処分性）」という3つの重要な性質があると指摘。これら3つの視点を持つことで、個別の技術選定や構成の決定から、アーキテクチャの変化そのものを管理する仕組みの構築へとシフトできると言い、「こうした概念をアーキテクチャのアーキテクチャ、『メタ・アーキテクチャ』として定義したい」と語りました。
クラウドとオンプレミスを組み合わせた機械学習基盤構築の挑戦（スリーシェイク 永瀬滉平さん）
続いて登壇したのはスリーシェイクの永瀬滉平さん。今回は開発者向けに構築している新しいML基盤と、検討中の課題についてお話しいただきました。
この基盤の特徴は、全国の拠点内のデータを基本的にLAN内に閉じておく必要があるため、オンプレミスサーバーが必須ということ。ですが開発者はリモート開発環境、モデルトレーニングと作成したモデルのサービングといった機能を利用したいという要件があるため、Kubernetes ネイティブのオープンソース・フレームワークである「Kubeflow」の採用を検討しているそうです。
また、現在検討中の課題は、DMZ内のKubernetesが物理サーバーであるがゆえの運用負荷に加えて、要件上DMZ内にある必要がないPodも現在DMZ内に配置されており、これを排除してリソースの圧迫を避けたいとのこと。
これに対して永瀬さんは「オンプレ・クラウドを含めて1つのクラスタとして扱う」「既存構成のままマルチクラスタスケジューリングを実装する」という2つの案を提示しつつ、「クラスタ跨ぎでのPodスケジューリング機構」と「誤ったPodにスケジュールすることを防ぐ機構」のどちらが速度高く実装でき、運用しやすいかが論点になると、検討状況を伝えつつ、「まだ構想段階で固まっていないため、知見があればぜひ懇親会で声をかけてほしい」という呼びかけで発表を締めくくりました。
【開発を止めるな】機能追加と並行して進めるアーキテクチャ改善（ビットキー 水谷浩明さん）
続いてはビットキーの水谷浩明さん。水谷さんは今年3月にビットキーに入社し、5月からhomehub アプリのリファクタリングを主担当として進めています。
水谷さんの入社時点でアプリはローンチから5年が経過し、PoCの繰り返しやさまざまなデバイスとの通信機能の組み込みによって技術的負債が溜まっている状態だったことから、リファクタリングプロジェクトが立ち上がりました。
リファクタリングを進めつつも、通常の開発も並行して進める必要があるため、段階的にリファクタリングを行うことになり、まず比較的スコープが狭い「お知らせ機能」からリファクタリングを開始しました。
続いて本格的にコアドメインであるデバイス管理部分のリファクタリングに取り組もうとしたところで問題が発生。「アプリの使用機能のほぼすべてがこの機能に関わっているため、リファクタリングを行おうとすると連鎖的にアプリ内の大半のコードを修正する必要が出てしまった」（水谷さん）。
この課題に対して水谷さんが考えたのが、変換層を用いた新旧アーキテクチャの共存。UIやプレゼンテーション層は既存のまま、コアドメインはリファクタリング後の状態にし、その間に古いモデルクラスから新しいモデルクラスへの変換を行う変換層を挟むことで、新旧アーキテクチャの共存に成功しました。
また、こうした取り組みをやり切るために、実装を始める前にAIの作業方針を固められるようなワークフローを考えたとのこと。
このワークフローにより、作業が定型化して品質が向上し、AIに実装を任せている間に次のタスクの指示を書けるため、並行作業で実施効率も向上したそうです。
2時間かかっていた月次バッチを10分に短縮したスケーラブルなバッチアーキテクチャ改善（タイミー 金森秀平さん）
後半はタイミーのプラットフォームエンジニアリングチーム金森秀平さんの発表からスタートしました。今回紹介いただいたのは月次バッチの改善事例です。このバッチは2時間以内に全プロセスを完了しないと顧客側の処理に悪影響を及ぼしてしまう状況ながら、データ量の増加に伴ってどうしても処理時間も増加しかねないというジレンマがありました。
金森さんのチームが採った改善アプローチは、ボトルネックであるDBのI/Oを企業単位で並列化するというもの。
まず、データの依存関係を分析し、作成・更新するテーブルが全て企業単位でルートとして辿れること、ロジックが企業という集約の中に閉じていること、副作用（他の企業の処理に影響）が発生しないことを確認しました。
ここまでで企業の集約単位でトランザクションにできそうだと分かったものの「大企業1社で処理時間が10分程度かかる場合、その10分間のレコードロックは許容できない」との課題感を金森さんは説明。一方で「時限までに正しい結果が揃っていれば良く、結果整合性を許容できるといった要件があった」ため、企業の集約単位でトランザクションを張らないという判断を採用しました。
それに伴いACID原則による整合性が保証できなくなるため、運用設計で安全性を担保することを決定。既存資産のSidekiqを活用した非同期処理アーキテクチャを構築することで、「タスク分の並列度で処理できて、企業が増えてもプロセスを増やすことで処理時間の増加を抑えつつ、個別の企業でエラーが発生しても他の企業の処理には影響しない」という、理想的な構成を実現できたとのことでした。
100以上の新規コネクター提供を可能にしたアーキテクチャ（primeNumber 田代裕基さん）
続いての発表はprimeNumberの田代裕基さん。primeNumberはクラウドETL「TROCCO」をメインで提供しており、対応しているコネクタの数が競争力の大きな要素になるため、コネクタの数を1年間で100増やそうという「Connect 100+」というプロジェクトに取り組んでいました。
田代さんのチームはAPIを提供しているSaaSに対するコネクタの開発コストを削減することで、リリースペースを上げることを検討し、宣言的なコネクタ実装が行える基盤を開発。結果、「新規追加ファイルは基本的にConfigのみでよく、既存の変更ファイルも不要になり、コネクタリリース数も大幅に増加できた」と語りました。また、このプロジェクトで作った基盤はパターンが明確で出力形式が固定なので、LLMを活用しやすい状態になっています。
田代さんは、短期的な目線と中長期的な目線の両方で、良いアーキテクチャや設計の価値が高まっていると語りました。短期的には、人間側の認知負荷軽減やレビューコスト削減に加えて、LLM側のコンテキストウィンドウ最小化や出力の安定化にも貢献。中長期的には、「とりあえず作る」ことが低コスト化した結果、技術負債が積み上がる速度も相対的に上がっているため、抽象レイヤーが綺麗であることが技術負債を減らすことに繋がります。
田代さんは「良いアーキテクチャ設計は、短期目線ではLLMを高速に精度高く使うための土台として、中長期目線ではコードを制御するブレーキ的な側面として、その価値がもたらすレバレッジがより大きくなっている」と締めくくりました。
SaaSの基幹システムをモジュラーモノリスとして再設計（finatext Dennis Metzgerさん）
最後はFinatextのDennis Metzgerさん。DennisさんはFinatextのインシュアテック事業部に所属し、SaaS型デジタル保険システムの「Inspire」を開発しています。Inspireの基本的な設計は3層構造となっており、今回はその内の1つ、コアシステムの再設計について発表いただきました。
このコアシステム、もともとは一般的なレイヤードアーキテクチャで比較的綺麗に設計されていたものの、決済モジュールや通知モジュールなど内部モジュールが増えるにつれて複雑化していったそうです。
そこでDennisさんのチームは再設計を実施。結果、モジュールは独立したモジュールとして実装し、元々のメインの保険ロジックも別のモジュールという構造にしました。また、「Go言語を使っているためインポートサイクルの問題を避けるべく、共有カーネルを設け、再設計の際には、OpenAPIとコードの自動生成、DAO（Data Access Object）の自動生成なども導入した」とDennisさん。
また、イベント送信の問題に対してはアウトボックスパターンを採用。同じトランザクション内でドメインロジックとイベント登録を行い、定期的にデータベースのイベントテーブルを見てAWS SQSに飛ばすという仕組みで、イベント送信漏れを防げるようになったとのことです。
Dennisさんのチームは、AI時代を見据えたドキュメント整備も実施。「CLAUDE.mdを設け、モジュラーモノリスの説明、設計方針、APIの設計、セキュリティ、トラブルシューティングなどを記載し、AIに学習させることで開発効率向上を図っています」と語りました。
セッション終了後の懇親会では、ピザやドリンクを片手に登壇者と参加者が活発に情報交換。
オフラインならではの活気ある雰囲気で、楽しい会でした。ご参加・ご登壇くださった皆さま、ありがとうございました！
