急成⻑SaaSを⽀えた 5年間のアーキテクチャ進化史 マルチテナント化からコンパウンド化まで 2025/11/21 

● ⾃⼰紹介 / 弊社紹介 ● アーキテクチャ進化史①：マルチテナント化 ● アーキテクチャ進化史②：コンパウンド化 ● まとめ ⽬次 

⾃⼰紹介 / 弊社紹介 

⾃⼰紹介 東京⼤学を2015年に卒業 株式会社ワークスアプリケーションズにてエンタープライズ向けの ERPパッケージシステムを開発。 2019年、SEVENRICH GROUPにジョイン。 SEVENRICH GROUPでは、パーソナルジム向けの経営管理SaaS Glialの⽴ち上げ、 完全Web予約制のクリニック CLINIC TEN SHIBUYAの⽴ち上げなど、グループ内外で のOMO（Online Merges Offline）サービスのプロトタイピング‧⽴ち上げを 連続的に⼿掛ける。 その中でAWSやAzureなどクラウドインフラの最適化を請け負うサービス 「CTO booster」を⽴ち上げ、株式会社DELTAをスピンアウト。 以後株式会社DELTAの代表CTOを務める。 丹 哲郎 Tetsuro Tan 代表取締役CTO 

弊社概要 会社名 株式会社DELTA 所在地 東京都渋⾕区桜丘町９−８ ＫＮ渋⾕３ビル 2F 設⽴ 2022年 代表者名 丹 哲郎 事業内容 開発組織向け技術⽀援事業 私たちは CTOとエンジニア組織のための テクニカル‧プロフェッショナルです リアーキテクチャやコスト削減などの技術負債解消、 時にはエンジニア特化の採⽤⽀援まで。 エンジニア組織向けに幅広いソリューションを備え、 挑戦と成⻑を⽀え続けます。 グループ元 SEVENRICH GROUP 

サービスラインナップ 要求仕様に合わせたシステム開発〜納品までを実⾏ システム受託開発 技術負債解消⽀援 完全成果報酬型インフラコスト削減代⾏サービス IaCコードの実装を格安‧最短2週間で代⾏するサービス クラウド利⽤状況の分析を⾏い、コスト状況の可視化するサービス FinOps booster IaC booster エンジニア特化型の採⽤⽀援AIエージェント ⽣成AIエージェント開発 組織/業務課題の解決に最適な ⽣成AIエージェントを構築‧導⼊サービス 技術アドバイザー 技術顧問でエンジニアリング課題の解決をサポート ⽣産性向上⽀援 開発⽀援 主要クラウドサービスに対応した 法⼈向けの請求代⾏サービス DELTAの請求代⾏ ⾔語やフレームワークの 格安‧⾼速バージョンアップ⽀援サービス VersionUp booster クラウドマイグレーション 既存システムのクラウド移⾏を計画‧実⾏し、 最適な運⽤環境へ移⾏ 

今回のケーススタディ EC/D2C 事業者様の売上・利益を上げることに特化した「売上を逃さない」EC プラットフォーム「ecforce」を提供。 受注や顧客の一元管理はもちろん、多彩なマーケティング機能によりショップの売上を最大化します。 ※1：全導入ショップの年商平均 /集計期間 2019年12月~2020年11月 ※2：ecforceへ移行したショップ 3社の1年経過時点のデータ /集計期間 2017年9月~2020年4月 ※3：ecforceへ移行したショップ 10社の移行前後 6ヶ月の比較データ /集計期間 2017年9月~2020年4月 ※1 ※2 ※3 

今回のケーススタディ 2023年に「統合コマースプラットフォーム」としてecforce（ECカートシステム）に限らない複数プロダクト展開構想を発表。 さらに2025年には「AIコマースプラットフォーム」として「ecforce AI」を中心としたAIプラットフォーム化を発表 

アーキテクチャ進化史①：マルチテナント化 

マルチテナント化で変わったこと マルチテナント化 コンパウンド化 ● テナント数のリポジトリが存在（約300） ● ⼿動での環境構築 ● コストもテナント数/nぐらいで増加傾向 ● デプロイジョブも⻑期化 Before After ● リポジトリ数が激減 ● 環境構築が⾃動(5分)に ● テナントあたりコストが80%削減 ● デプロイジョブも短期化 

環境開設のリードタイムの⻑さによる機会損失を防ぎたい ecforceの申し込みから⼿動で環境構築をしており、お客様 にecforceの環境を開設するまでに時間を要していた。 未来のコスト増加の抑制 新たなリード導線の導⼊ ショップ提供速度の向上 マルチテナント化検討当時の狙い 1 2 3 認知度向上に伴い発⽣するリードの取りこぼしを防ぎたい タクシー∕テレビ CM による認知度向上施策の実施に伴いト ライアルプランのようなものを実装検討していた マルチテナント化 コンパウンド化 マーケティング施策を打つことで契約件数の伸⻑が⾒込めて おり、コストのショップ数依存からの脱却を図りたい ecforceのインフラコストはショップ数に⼤きく依存（2020.6時点） 

ソースコードで 表現されていた 設定をDBに 切り出し ⾃動構築の ジョブの構築 schema_ migrations テーブルの同期 全修正を ﾏﾙﾁﾃﾅﾝﾄ環境と ｼﾝｸﾞﾙﾃﾅﾝﾄ環境 で同居させる 移⾏ジョブの 構築 Makara(当時) との同居 やったこと①：差分の洗い出し 差分の 洗い出し ● 差分洗い出し⽤のStep Functionsを実装 ○ テナントごとリポジトリのclone ○ ベースリポジトリもclone ○ diffを取る ○ diff結果をS3にアップロード ● S3の情報をまとめる（⽣成AIなんて無いので⽬検） マルチテナント化 コンパウンド化 

差分の 洗い出し ⾃動構築の ジョブの構築 schema_ migrations テーブルの同期 全修正を ﾏﾙﾁﾃﾅﾝﾄ環境と ｼﾝｸﾞﾙﾃﾅﾝﾄ環境 で同居させる 移⾏ジョブの 構築 Makara(当時) との同居 やったこと②：ｿｰｽｺｰﾄﾞで表現されていた設定をDB切り出し ソースコードで 表現されていた 設定をDBに 切り出し マルチテナント化 コンパウンド化 ● config/initializers配下でpuma起動時に初期化されていた 各種設定もDBから逐次取り出しに修正 ○ action_mailer ○ Rails.cache ○ テーマファイル(liquid)の読み込み ○ sidekiq(引数にtenant idを追加) ○ sidekiq-cron ○ loggerへのtenant id tagの追加 ○ 各種メールに記載のURLのベースパスの変更 ○ バケット、CDNのディストリビューションID等の動的変更 ○ ‧‧‧ 

schema_ migrations テーブルの同期 全修正を ﾏﾙﾁﾃﾅﾝﾄ環境と ｼﾝｸﾞﾙﾃﾅﾝﾄ環境 で同居させる 移⾏ジョブの 構築 Makara(当時) との同居 差分の 洗い出し ソースコードで 表現されていた 設定をDBに 切り出し やったこと③：⾃動構築のジョブの構築 ⾃動構築の ジョブの構築 ● テナント管理DBへのデータ投⼊ ● DNSレコードの払い出し ● 管理者ユーザーの払い出し ● 各種設定データの投⼊ マルチテナント化 コンパウンド化 

全修正を ﾏﾙﾁﾃﾅﾝﾄ環境と ｼﾝｸﾞﾙﾃﾅﾝﾄ環境 で同居させる 移⾏ジョブの 構築 Makara(当時) との同居 差分の 洗い出し ソースコードで 表現されていた 設定をDBに 切り出し ⾃動構築の ジョブの構築 やったこと④：schema_migrationsテーブルの同期 schema_ migrations テーブルの同期 ● リポジトリごとにmigrationファイルのバージョンが異なる ● Railsでは、ファイルシステムのmigrationファイルとDBに記録されている 適⽤済みマイグレーションのバージョンが違うとエラーになる ● 過去分の適⽤済みマイグレーションのバージョンをsquashし、 バージョンを揃える マルチテナント化 コンパウンド化 

移⾏ジョブの 構築 Makara(当時) との同居 差分の 洗い出し ソースコードで 表現されていた 設定をDBに 切り出し ⾃動構築の ジョブの構築 schema_ migrations テーブルの同期 やったこと⑤：全修正をﾏﾙﾁﾃﾅﾝﾄ環境とｼﾝｸﾞﾙﾃﾅﾝﾄ環境で同居 全修正を ﾏﾙﾁﾃﾅﾝﾄ環境と ｼﾝｸﾞﾙﾃﾅﾝﾄ環境 で同居させる ● 今の環境がマルチテナント環境かどうかを動的に判定 ○ シングルテナントの場合：ファイルシステムの設定を読み込み ○ マルチテナントの場合：データベースから設定を読み込み ● これらの処理の動的な差し替えのため、メタプログラミングを多⽤した ○ Rubyでなければもっと⾟かったはず‧‧‧ マルチテナント化 コンパウンド化 

Makara(当時) との同居 差分の 洗い出し ソースコードで 表現されていた 設定をDBに 切り出し ⾃動構築の ジョブの構築 schema_ migrations テーブルの同期 全修正を ﾏﾙﾁﾃﾅﾝﾄ環境と ｼﾝｸﾞﾙﾃﾅﾝﾄ環境 で同居させる やったこと⑥：移⾏ジョブの構築 移⾏ジョブの 構築 ● マイグレーションバージョンの同期 ● 既存設定の抽出 ● 既存設定をデータベースに投⼊ ● 同期、投⼊の成否をチェック ● マルチテナントフラグを⽴てる ● 公開！ マルチテナント化 コンパウンド化 

差分の 洗い出し ソースコードで 表現されていた 設定をDBに 切り出し ⾃動構築の ジョブの構築 schema_ migrations テーブルの同期 全修正を ﾏﾙﾁﾃﾅﾝﾄ環境と ｼﾝｸﾞﾙﾃﾅﾝﾄ環境 で同居させる 移⾏ジョブの 構築 やったこと⑦：Makara(当時)との同居 Makara(当時) との同居 ● リーダーインスタンスへのSELECTクエリのルーティングを⾏うgem ● 複数のコネクションを取り回す設計となる = ミドルウェアで、リクエスト 時にコネクションを use 句で切り替えるApartment gemとの⾷い合わせが 極端に悪い ● マルチDB x マルチテナンシーの実現が⼤きな課題 ○ 結局、Makaraのアダプタを⾃作 ○ Makara側がコネクションを切り替える際に、再度テナントを参照して その都度切り替える設計 マルチテナント化 コンパウンド化 

初期の設計の優れた点 共通化と⾮共通化のセンス ec_force gem (rails engine) ec_force_app_mothwing ec_force_app_xxx ec_force_app_xxx ec_force_app_xxx ● コアな処理は全て共通のgemとして実装されていた ● 分散していたリポジトリ群は、ほぼ共通のgemを呼び出すのみの薄い実装だった ● 将来の共通化を⾒越した賢い設計 マルチテナント化 コンパウンド化 

アーキテクチャ進化史②：コンパウンド化 

【再掲】今回のケーススタディ 2023年に「統合コマースプラットフォーム」としてecforce（ECカートシステム）に限らない複数プロダクト展開構想を発表。 さらに2025年には「AIコマースプラットフォーム」として「ecforce AI」を中心としたAIプラットフォーム化を発表 

コンパウンド化で変わったこと ● プロダクトごとに認証‧認可がバラバラ ● クロスセル‧アップセルが営業依存 ● エンタープライズグレードのID管理に 追従しづらかった ● プロダクトごとに選定技術もバラバラ Before After ● 共通の認証基盤を構築 ● ポータル画⾯を⽤意、将来のクロスセル ⾃動化を⾒越せるように ● 認証基盤とエンタープライズIDを 接続できるように ● SDKを実装し、技術依存の箇所を局所化 マルチテナント化 コンパウンド化 

やったこと①：共通の認証基盤の構築 ● 全てのプロダクトにOIDCクライアントを実装 ● 共通のOIDC ID Providerを実装 ● セッション管理機構も⼀部共通化 ecforce accounts (ID Provider) ecforce ecforce chat ecforce check ecforce bi Salesforce(契約管理) 横断ポータルの 実装 移⾏ジョブの 構築 エンタープライズID との接続 SDKの実装 共通の 認証基盤の構築 マルチテナント化 コンパウンド化 

横断ポータルの 実装 移⾏ジョブの 構築 エンタープライズID との接続 SDKの実装 共通の 認証基盤の構築 やったこと②：横断ポータルの実装 ● SSO⽤のポータルのフロントエンドを実装 ● 権限管理、招待/revoke、各プロダクトへのログインを⼀元化 ● 将来的にはポータル上での請求管理、別プロダクトの購買も可能な導線 ● 各プロダクトは個別にIdPと通信してOIDCするため、極めて薄く軽量な Webアプリケーションとして実装できた マルチテナント化 コンパウンド化 

共通の 認証基盤の構築 移⾏ジョブの 構築 やったこと③：移⾏ジョブの構築 横断ポータルの 実装 エンタープライズID との接続 SDKの実装 ● 既存アプリケーションの認証情報を抽出 ● パスワードのハッシュアルゴリズムごと共通ユーザープールに移⾏ ● 必要な権限を付与 ● 対象テナントのSSO有効フラグを⽴てる ● 公開！ マルチテナント化 コンパウンド化 

共通の 認証基盤の構築 エンタープライズID との接続 やったこと④：エンタープライズIDとの接続 エンタープライズ IdP 共通 IdP ログイン先 アプリケーション 横断ポータルの 実装 移⾏ジョブの 構築 SDKの実装 ● 共通IdPの上流に顧客のエンタープライズIDを接続 ● 上流のエンタープライズIDからのSSOを実現 ○ OIDC/SAMLでアイデンティティやロールを受け取る ○ 共通IdP側の属性に読み替え ○ 権限をassume マルチテナント化 コンパウンド化 

SDKの実装 共通の 認証基盤の構築 やったこと⑤：SDKの実装 横断ポータルの 実装 移⾏ジョブの 構築 エンタープライズID との接続 ● 共通の認可基盤との通信を⾏うためのSDKリポジトリを実装 ● プロトコルはConnect (gRPC)ベースだが、クライアントを含めて 各⾔語向けにビルドしてプライベートレジストリから配信 ● 各プロダクトの開発者はSDKを呼び出すだけ ● SDK側にトレーシング‧リトライの機構をミドルウェアとして積むことで 中央集権的な管理を実現 マルチテナント化 コンパウンド化 

初期の設計の優れた点 設計として「捨てる」箇所のセンス ● 権限管理の機構が各プロダクトに（ほぼ）実装されていなかった ● 認証機構もごくシンプルなID/PW形式のみに敢えてしていた ● 将来的に中央集権的な認証認可基盤が実装されることを⾒越して、 敢えて各プロダクトで個別に持つべき箇所を最⼩化していた マルチテナント化 コンパウンド化 結果的に、各プロダクトへの影響を最⼩化して ⼤規模な基盤の差し替えに成功 

まとめ 

マーケティングへの投資を⾒込んだ構築⾃動化の実現、 コンパウンド化/エンタープライズ戦略を⾒込んだID基盤。 ビジネス上の要求を先読みして技術投資をタイムリーに⾏ う。 共通化‧個別化のセンス 設計を「捨てる」センス 技術投資とビジネスの同期 まとめ：SUPER STUDIO社の事例から学ぶ3つのポイント 1 2 3 将来的に共通化が⾒込まれる箇所は、敢えて個別での実装 を⾏わずに運⽤⾯でカバーする意思決定も効いてくる 最初からマルチテナンシを作り込むと実装コストが嵩み、 noisy neighborも発⽣する。しかし、完全に個別化すると 管理コストが⾼まり将来の共通化も⾟くなる。 良いバランスを⾒極める 

まとめ：CTOの役割とは？ 「ビジネスを意識した技術意思決定」の真髄は「タイミング」 ● YAGNI(You Ain’t Gonna Need It)原則に沿って早すぎる最適化は避ける ● 将来の拡張性は「⾒込む」が「作り込まない」 ○ エンジニアの習性として、特にメガベンチャー出⾝のCTOは初期から作り込んで しまう ○ ビジネスは不確実であり、作り込んだものが無駄になってしまう危険性もある ● しかし、どこかでリアーキテクチャリングは必要になる この「どこかで」を⾒極め、ビジネスが今後2-3年でどう動くか。 それに必要な⾮機能特性は何かを⾒据えて、タイムリーに技術投資することが CTOとしての「ビジネスを意識した技術意思決定」なのではないか 

CTOの役割とは？ 親孝⾏したいときに親はなし ● 将来のためにやるべきことが⾒えたとしても、現場のエンジニアはロードマップの 実現に忙しい ● CTOやテックリード本⼈が⼿を動かせる領域は相対的に狭くなっていく ● 技術投資は、⾦銭的な投資と同じく、資⾦があればできるわけではない ○ 投資先のソーシングと選定が重要 ロードマップやスクラムの「外」にある課題こそ 外注という選択肢も有効ではないか？ ▶ DELTAにぜひご相談を！ 

EOF