DELTAと支援先サービス「ecforce」の紹介

丹：DELTAの丹と申します。代表取締役CTOと書いておりますが、社長も兼任しております。創業者です。

弊社は2022年に創業した3期目の若い会社になります。事業内容は大きく3つ、「技術負債解消支援」「生産性向上支援」「開発支援」です。今回のテーマに近いのは「技術負債解消支援」の領域です。

中でも我々の最大の強みは、完全成果報酬型インフラコスト削減代行サービス「CTO Booster」です。お客様のクラウドコストを削減し、削減額に応じて成果報酬をいただくというビジネスモデルで運営しています。このほかにも、言語やフレームワークのバージョンアップ支援、手動で構築されたインフラリソースのIaC化など、多くの開発組織が抱える共通課題を解決するサービスを展開しています。

丹：今回のケーススタディは、我々の支援先であるSUPER STUDIOさんの「ecforce」というプロダクト、ならびにその周辺のアプリケーションをテーマにしてお話しします。

ecforceは、ECカートシステムを中心としたAIコマースプラットフォームです。コマース事業者がecforceを契約することで、マーケティングの最適化や販売チャネルの強化はもちろん、AI駆動型のデータ活用、業務改善、実行まで、コマースビジネスに特化した様々なことを実現できるサービスとなっています。

ecforceは当初、ECカートシステム単体のサービスでしたが、近年は事業領域を拡大しています。2023年には「統合コマースプラットフォーム」として、複数プロダクトの展開やOMO領域の構想を発表しました。「統合コマース」とは、オンラインのECだけでなく、リアル店舗のビジネスも含めて統合的に支援するという意味です。

丹：さらに2025年には「AIコマースプラットフォーム」へと進化し、コマース事業に特化したAIエージェント「ecforce AI」も発表しています。コマース事業の運営に必要なデータを横断的に活用し、業務のサポートから実行までをワンストップで行うAIエージェントとして提供を開始しました。このように、ecforceはECカートシステムから出発し、複数プロダクトがデータを介して横断的につながる統合プラットフォームへ。そして現在では、AI-Readyなシステム基盤を構築するAIコマースプラットフォームへと進化を遂げています。

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

丹：まずマルチテナント化についてお話しします。この取り組みは2020年頃に実施しました。

マルチテナント化とは、シングルテナント構成からマルチテナント構成へ移行することを指します。当時のecforceはシングルテナント構成で、顧客がサービスを契約するたびに、その顧客専用のリポジトリを新規作成していました。顧客ごとに専用のサーバーインスタンスを立て、個別に環境をセットアップする方式です。2019年頃まではこの方式で運用していました。

丹：当時、リポジトリはテナント数と同じ約300個存在していました。GitHubにアクセスすると300個のリポジトリが並んでいるという状況です。顧客ごとにリポジトリを作成し、サーバーインスタンスをプロビジョニングして環境を構築していたため、この作業はすべて手動で行っていました。

最も大きな課題はコストでした。利用頻度が高い顧客もいれば、ショップは開設しているもののアクセスが少ない顧客もいます。しかし利用状況にかかわらず、ショップを開設するだけでEC2インスタンスが立ち上がる構造だったため、テナント数の増加に比例してコストも増え続けていました。

もう1つの課題はデプロイです。新しいバージョンをリリースする際、すべてのインスタンスに適用する必要があったため、デプロイに非常に時間がかかっていました。

マルチテナント化により、単一のリポジトリでリクエストに応じて動的に設定を切り替える構成になったため、リポジトリ数は激減しました。テナントを動的に切り分けられるようになったことで、テナント情報をデータベースで管理し、新規テナントの追加も容易になりました。環境構築の自動化、コスト削減、デプロイ時間の短縮も実現しています。非常に効果的な取り組みでした。

今日は細かい実装の話ではなく、背景を中心にお話しします。マルチテナント化の狙いは3つありました。

丹：1つ目は、未来のコスト増加の抑制です。5年前のSUPER STUDIOは、順当に資金調達を重ね、PMFが一定の水準に達し、マーケティング施策を打てば顧客を獲得できるというスケールを見越していた時期です。

マーケティング投資で顧客を獲得できる段階にあるにもかかわらず、顧客が増えるほどコストも増加する状況では、エコノミクスが成り立たなくなる懸念がありました。将来的にマーケティングを強化してビジネスを拡大していく前に、顧客数の増加がコスト増に直結しないコスト構造へ転換しておく必要があったのです。

2つ目は、新たなリード導線の導入です。当時、タクシーCMによる認知拡大施策を予定していました。広告で認知を一気に広げると、問い合わせが大量に発生します。認知を広く取ると、本格的に導入するかどうか分からない、まずは試してみたいという層も流入してきます。そのような状況でテナント構築を手動で行っていては対応しきれません。自分でサインアップしてすぐに使い始められる、いわゆるお試しプランのようなSaaSの機能が必要でした。

これは2020年頃の話ですが、その約2年後に、某タレントを起用した「ヤー」というタクシー広告が放映されました。マルチテナント化は、このマーケティング施策が本格化する前の段階で取り組んだものです。

タクシーCMで認知を拡大した際に流入するライトユーザー層を受け入れられるアーキテクチャが必要でした。同時に、マーケティング投資で顧客が一気に増加しても収益性が成り立つコスト構造への転換も求められていました。当時のビジネス要件を踏まえると、マルチテナント化は必須の取り組みだったのです。

3つ目は、ショップ提供速度の向上です。環境構築に時間がかかっていたため、環境構築をセルフサービスで自動的に行えること、そして迅速に完了できることが必要な要件でした。

我々が実施した作業についてお話しします。まず、300個のリポジトリが存在していたため、すべての差分を洗い出す必要がありました。

DELTAでは、差分洗い出し用のStep Functionsを構築しました。各リポジトリをクローンしてdiffを取得し、どのファイルに差分があるかを300個のリポジトリ間で比較する仕組みです。その結果をS3にアップロードし、全テナントのソースコード差分を集約しました。集約したデータを目視で確認し、マルチテナント化によってどのような影響が生じるかを洗い出していきました。当時は生成AIが存在しなかったため、diffを一行一行読んで確認するしか方法がありませんでした。

続いて、最も重要な作業です。マルチテナント化するということは、ユーザーのリクエストに応じて設定や接続先DBを動的に切り替える構成への変更を意味します。そのためには、ソースコードにベタ書きになっていた設定を、データベースから動的に取得する方式に変更する必要がありました。

丹：ecforceはRuby on Railsで構築されており、従来はconfig/initializers配下でサーバー起動時に各種設定を初期化していました。これをリクエストごとにデータベースを参照して設定を取得する方式に変更したため、非常に多くの箇所に手を入れることになりました。

具体的には、action_mailer、Rails.cacheのキー、テーマファイル（Liquid）の読み込みパスを動的に切り替える対応を行いました。また、Sidekiqのジョブ実行時に引数へテナントIDを動的に追加する仕組みや、sidekiq-cronのスケジュールをデータベースで管理する仕組みも実装しました。sidekiq-cronはテナントごとに異なるスケジュールで動作していたため、テナントIDを付与できる構成が必要でした。さらに、運用上ログにテナントIDが出力されないと問題の切り分けができないため、loggerへのテナントID付与も実装しています。

さらに、今回のビジネス上の目玉であった自動構築機能についてです。新規テナントを払い出し、顧客へデリバリーするまでを自動化するジョブを構築しました。

丹：もう1つ対処が必要だったのは、schema_migrationsテーブルの同期です。300個のリポジトリにはそれぞれデータベースがあり、マイグレーションのバージョンがテナントごとに記録されています。リポジトリを統合するとファイルシステムは1つになりますが、データベースに記録されているschema_migrationsのバージョンとファイルシステム上のマイグレーションファイルのバージョンが一致しなくなるという問題が発生します。この整合性を取る作業も必要でした。

丹：さらに複雑な要件がありました。契約上シングルテナントで運用しなければならないエンタープライズ顧客も存在していたのです。そのため、単一のソースコードで「この顧客はマルチテナントで動作し、この顧客はシングルテナントで動作する」という切り替えが必要でした。つまり、動的な切り替え処理を適用するかどうか自体を、動的に制御できる仕組みが求められました。

丹：こうした対応を地道に進め、最終的にはリポジトリの統合、必要な情報のデータベースへの退避、マルチテナントフラグの設定という一連の作業を各テナントに対して実行する移行ジョブを構築しました。この移行作業に約1年半を費やし、全テナントの移行を完了しました。

丹：大変な作業ではありましたが、振り返ってみると、やったことは明確です。差分の洗い出し、設定のデータベースへの切り出し、ジョブの構築、問題の修正、そして移行という流れでした。

我々DELTAはSUPER STUDIOのバックアップとして、こうした手間のかかる作業を代行させていただきました。第三者として入った立場から率直に感じたのは、想定していたほど大規模な修正ではなかったということです。

その理由は、もともとの設計が優れていたからです。ecforceというサービスとして共通で満たすべき仕様が、社内のgemとして適切に切り出されていました。

これはRails Engineという機能を活用したもので、共通のテンプレートから複数のアプリケーションを効率的に生成できる仕組みです。ecforceの共通仕様を満たすgemを作成し、各顧客向けのリポジトリはそのテンプレートを呼び出すだけの薄い実装になっていました。

300個存在していたリポジトリ群のほとんどは、独自の実装を持っているわけではなく、共通gemをどう呼び出すかという引数や設定値を保持しているだけでした。そのため、設定の違いや細かな仕様差分を抽出してデータベースに格納するだけで、300個のシングルテナントアプリケーションを比較的ラクに共通化できたのです。

丹：この設計は、SUPER STUDIOのCTOである村上さんが当初から「どこかでマルチテナント化に向き合わなければならない」という見通しを持ち、少なくともソースコードだけは共通化しておこうと考えて進めていたものです。

私だったら、初期の開発フェーズでさまざまな顧客からさまざまな要望が寄せられ、共通モジュールでは機能が足りないという状況になった時、顧客の要望に応えるために、リポジトリが分かれているのであれば、共通部分があったとしても、そのリポジトリ固有の実装を個別に作ってしまうと思います。正直なところ、その誘惑に負けてしまう気がします。

しかし、SUPER STUDIOでは個別の実装を共通箇所に吸収していくことを当然とする文化を築き、それを徹底していました。その結果、後のマルチテナント化が非常にスムーズに進みました。第三者として見ていて、CTOの手腕によるところが大きいと感じました。

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

丹：マルチテナント化は2020年から2021年にかけて、約2年間で実施しました。その後、2023年に「統合コマースプラットフォーム」という構想が発表されましたが、それ以前から構想の実現に向けた実装は進んでいました。

先ほど触れたように、この構想ではオンライン・オフラインのデータ統合を中心に据え、その周辺に複数のプロダクトを展開していきます。カートシステムだけでなく、来店予約といったオフライン店舗向けのプロダクト、データ分析、CRMなど、さまざまなプロダクトが次々と拡張されていく計画です。データを介してマルチプロダクトが有機的に連携していくという方向性であり、これはいわゆる「コンパウンド化」と呼べるものです。

コンパウンド化に向けては、いくつかの課題がありました。まず、プロダクトごとに認証・認可の機構がバラバラだったことです。

丹：また、マルチテナント化以前は環境構築を手動で行っていたという話をしましたが、マルチテナント化によってその問題は一定解消されました。しかし、クロスセルやアップセルに関しては依然として課題が残っていました。例えば、カートシステムを契約している顧客が別のプロダクトを追加契約したい場合、営業担当者と会話し、新たに契約を締結し、環境構築を依頼するという流れが必要でした。プロダクトの追加契約は、依然として手動かつ営業依存のプロセスだったのです。

また、SUPER STUDIOはエンタープライズ領域を強化していました。エンタープライズ顧客の要件を満たすには、エンタープライズグレードのID管理機能が必要です。しかし、当時の構成ではID管理に関する要件への対応が困難でした。

さらに、プロダクトごとに選定技術がバラバラという課題もありました。現在、ecforceスイートは約10個のプロダクトで構成されています。初期に構築されたecforceはRuby on Railsで開発されており、いくつかのサービスも同様にRuby on Railsを採用しています。一方で、Java Springで構築されたもの、Next.js＋TypeScriptで構築されたもの、Remixで構築されたものも存在しています。

これらの課題に対して我々が取り組んだのは、共通の認証基盤の構築です。認証基盤の構築だけでも大きな作業ですが、ビジネス上の要件を考慮すると、認証基盤とセットでSSO用のポータル画面も必要と判断しました。

このポータルがあれば、顧客がログインすると、その企業が契約しているアプリケーションが一覧表示され、Oktaのようにクリックするだけで各サービスにSSOできます。さらに将来的には、未契約のプロダクトをグレーアウト表示し、そこから追加契約できるクロスセル機能や、契約情報の確認・修正、請求書・領収書の閲覧といった機能も実装できます。こうした将来のビジネス要件にも対応できる基盤として、ポータル画面を設計・構築しました。

やったことの内訳ですが、端的に言えばOIDCでSSOできるID Providerを構築したということです。この共通ID基盤を「ecforce accounts」と名付けました。ecforce accountsの内部には、IDプール、認証機構、認可機構、権限管理機能など複数のコンポーネントが存在しますが、これらを総称してID Providerとして提供しています。

丹：ecforce accountsは、SUPER STUDIO社内の契約管理に使用しているSalesforceと連携しています。どのテナントでどのオプションが有効になっているか、誰が管理者かといった情報を同期しています。この基盤から各アプリケーションに対して、OIDCを経由したSSOを実現する仕組みを構築しました。

理想としては、認証基盤を外部から一括で差し替えられれば良いのですが、現実はそう簡単ではありません。各プロダクトにOIDCクライアントを実装する必要がありますし、トークンをリフレッシュする際に認証基盤へ問い合わせる機構も作らなければなりません。このように、全プロダクトに対して泥臭い修正作業が必要でした。この部分は我々DELTAが担当しました。

その上で、SSO用ポータルのフロントエンドを実装しました。このポータルは、単にSSO先を選択する機構だけではありません。各アプリケーションに対して誰がログインでき、何ができるかを管理する権限管理機構、ユーザーの招待やリボークの機能も備えています。ユーザーは自分が権限を持つプロダクトをクリックするだけで、SSOでログインできます。

丹：このポータルを1つの基盤として用意しておけば、将来的な拡張が容易になります。現在契約していないプロダクトの追加契約機能を実装してクロスセル・アップセルに活用することも、領収書の確認や支払い管理機能を追加することも可能です。こうした拡張性を見据えながら、CTOの村上さんと議論を重ねて設計・構築を進めました。

各プロダクトは個別にIdPと通信してOIDC認証を行うため、このポータルのフロントエンド自体はシンプルなNext.jsのWebアプリケーションとして実装できました。権限管理、認可、認証といった複雑なロジックをフロントエンドに含める必要がない設計にしています。

次に取り組んだのは、移行ジョブの構築です。既存アプリケーションから認証情報を抽出し、共通ユーザープールに移行します。パスワードは平文で保存されていないため、パスワードのハッシュアルゴリズムごとユーザープールに移行する処理が必要でした。

丹：興味深い点として、歴史的経緯からプロダクトごとにハッシュアルゴリズムが異なっていました。この点も考慮し、複数のハッシュアルゴリズムに対応できるユーザープールを選定しています。その上で、もともとの権限に合わせて必要な権限を付与し直して、対象テナントのSSO有効フラグを立てて移行完了とする、一連の処理をテナントごとに実行する移行ジョブを構築しました。

ここまでの実装により、OIDCでSSOできる状態が整いました。次の段階として、さまざまな拡張を進めていきます。その1つがエンタープライズIDとの接続です。

今回構築した共通IdPの上流に、顧客のエンタープライズIDを接続できるようにします。顧客が使用しているエンタープライズIDは多様で、Oktaを使用している企業もあれば、Entraを使用している企業、独自の認証基盤を持っている企業も存在します。これらの上流エンタープライズIDから共通IdPに対して、トークンや各種情報を受け取る仕組みを構築しました。

丹：エンタープライズIDを使いたいという顧客には、大抵の場合、共通の要件があります。それは、社内の申請システムやIdPの中で、誰がどのアプリにログインできて何ができるかという権限管理を、社内の他のSaaSと同じように一元管理したいというニーズです。

このニーズに対応するため、アイデンティティの値やロールを柔軟に受け取れるようにしました。これらの情報形式は顧客ごとに大きく異なるため、柔軟性が重要でした。

その上で我々のシステム側では、受け取った情報を内部の形式に読み替えるためのマッピング情報をマスターデータとして管理できるようにしています。例えば、上流のIdPから「この人は営業部の部長です」という情報が渡ってきた場合、こちら側で「ロールID○○番」に読み替えます。そのロールIDに紐づく権限に基づいて、このアプリにアクセスできるという権限のアシュームまで自動的に行う機構を構築しました。

認証自体はOIDCなどの標準プロトコルがあるため、RailsやJavaといった技術スタックの違いによる実装差分はあまり生じません。一方、認可については事情が異なります。この人は何ができる、何ができないという権限判定については、公式の標準プロトコルが存在しないため、通常のHTTP通信などで実現しなければならない箇所が出てきます。そうなると、各プロダクトで技術前提が異なることが課題になりますが、この点はSDKを作ることで解決しています。

丹：プロトコルはConnect（gRPCベース）を使用しており、Ruby向け、Go向け、Java向け、JavaScript向けのように各言語向けのクライアントをビルドしています。これらを社内のプライベートレジストリから配信し、npm installやgo getでインストールできるようにしました。これにより、各プロダクトの開発者はSDKを呼び出すだけで、中央の認可機構にアクセスできます。

また、SDK側にトレーシングやリトライの機構をミドルウェアとして組み込んでいるため、開発者ごとの実装品質のばらつきを防止しています。

この共通認証基盤の構築はそこそこ大変な作業でしたが、振り返ってみると、当初の設計で良かった点がいくつかありました。

特に良かったのは、逆説的ですが、各プロダクトにほぼ何も実装されていなかったことです。権限管理の仕組みが各プロダクトにほとんど実装されていませんでした。

丹：もし各プロダクトに独自の権限管理が実装されていた場合、後から認可基盤・認証基盤を構築する際に、新しい基盤側の権限の仕組みと既存プロダクト側の権限の仕組みを同期させる必要が生じます。また、既存の権限情報を新基盤に移行する際に、プロダクトによって権限の粒度や解釈が異なるといった問題も発生していたと予測できます。そうなると、移行作業は非常に困難になっていたでしょう。

逆に、全プロダクトで権限管理がほとんど実装されていない状況だったからこそ、後から認可の共通基盤を導入しやすかったです。認証機構についても、シンプルにID・パスワードでのログインのみに限定されていました。これも意図的な設計だったと考えています。

もし中途半端に、あるプロダクトではこの機能があり、別のプロダクトでは別の機能があるという状態だった場合、後で共通化する際に非常に困難になります。

将来的に中央集権的な認証認可基盤が実装されることを見越して、あえて各プロダクトで個別に持つべき箇所を最小化し、極端に言えば「ほぼ何もできない」状態にしてあったことは、非常に良かったと思います。この設計には二重のメリットがあります。1つ目は、初期の作り込み工数を削減できること。2つ目は、後で中央集権化する際に考慮すべき変数が減ることです。

この「捨てる」箇所を見極める判断について、CTOの村上さんのセンスは優れていたと感じました。結果として、私がやったことはOIDCを導入してSDKを配布しただけで済み、非常にスムーズに進行しました。

まとめ

丹：5年前の最初の段階では、顧客ごとにシングルテナントで運用しており、300個のリポジトリと300個のインスタンスが存在する状況でした。この構成についても、後でCTOの村上さんに聞くと「あえてそうしていた」とのことでした。

私たちエンジニアは、インターネット上に優れた事例やベストプラクティスが多く紹介されているため、それらを参考に初期から作り込んでしまいがちです。シングルテナントという選択肢は取らないと思うのですが、最初からマルチテナンシーを作り込まないというセンスは優れた判断だったと考えています。

丹：ただし、これを完全に個別化してしまうと、後で仕様を統一する際が大変です。「ソースコードは共通化するが、アーキテクチャはバラバラにする」というバランスを見極められていたのは、CTOである村上さんのセンスによるものだと考えています。

同様に、将来的に共通化が見込まれる認証認可基盤については、各プロダクトで過度に作り込まないという判断も重要でした。この判断があったからこそ、後の移行が非常にスムーズに進みました。やはり「何を捨てるか」を慎重に検討することの重要性を実感しています。

最後に最も強調したいのは、技術投資のポイントはタイミングだということです。「CTOは、ビジネスのことを考えて技術的な意思決定をすべきだ」という話をよく聞きます。しかし正直なところ、この言葉は抽象的で、具体的な指針としては不十分だと感じています。

では、そのポイントはどこにあるのでしょうか。技術的に正しいことはインターネット上にいくらでも情報がありますし、書籍を読めば理解できます。それでは、取締役や経営陣にCTOがいる意味は何でしょうか。私は、CTOによるビジネスを意識した技術意思決定の真髄は、内容よりもタイミングにあると考えています。

丹：「早すぎる最適化は避けましょう」とよく言われますが、これもタイミングの問題です。最適化自体は必ず必要ですが、実施する時期が早過ぎてはいけないということです。将来の拡張性については見込んでおくべきですが、実際には作り込まない。これもタイミングの問題です。将来を考慮しつつも、作り込むタイミングを見極めることが重要です。

「なるべく作り込まない」というのもよく言われることで、一定の真実があります。しかし、どこかで必ず作り込まなければならない時が来ます。SUPER STUDIOの事例では、大型のマーケティング施策を行うタイミングを1年後に控えている時だったかもしれません。あるいは、プロダクトをコンパウンド化させていくタイミング、またはエンタープライズ領域を強化していくタイミングだったかもしれません。

ポイントは、そのタイミングに沿って最適な意思決定を1年、2年、あるいは3年前から仕込んでおくことです。どこかで作り込まなければならない時が必ず来ます。その「どこかで」を見極めるために、今後2〜4年でビジネスがどう動いていくかをまず考えます。そこに必要な非機能要件は何かを検討し、タイムリーに技術投資を行う。これが、CTOとしてのビジネスを意識した技術の意思決定の1つの答えだと考えています。

最後に宣伝をさせてください。先ほど技術投資の話をしましたが、1年後、2年後にこうなっている必要があるという目標が見えたとします。しかし現実には、現場のエンジニアはロードマップの実現に忙しく、「2年後を見据えて、1年かけて認証基盤の共通化をやっておいてほしい」と依頼できるメンバーはなかなかいません。また、CTOやテックリード自身が手を動かせる領域も、ビジネスの成長とともに相対的に狭くなっていきます。

技術投資という名のとおり、予算を投下すべき分野はその時々で存在します。しかし逆に言えば、資金があるからといって自動的に目標が達成されるわけではありません。適切な投資先を見つけることが必要です。

やるべきことが見えてきたものの、それを実行するリソースがない、アサインできる先がないという状況は十分にあり得ます。そのような場合、専門性を持った外部パートナーに外注し、そこを投資先とするという考え方も有効ではないでしょうか。

「親孝行したい時に親はなし」という言葉がありますが、技術投資をしたい時にテックリードがいないという状況も起こり得ます。そのような際に、私たちの名前を思い出していただければ幸いです。

アーカイブ動画・発表資料

イベント本編は、アーカイブ動画を公開しています。また、当日の発表資料も掲載しています。あわせてご覧ください。

▼動画・資料はこちら
アーキテクチャConference 2025

※動画の視聴にはFindyへのログインが必要です。