事例で学ぶマルチテナント対応：BtoB2Cプラットフォームを安全にSaaS化する方法

なぜ今、マルチテナント対応のBtoB2Cプラットフォームが重要なのか

近年、1つのサービスで複数の企業とその先にいるエンドユーザーをつなぐBtoB2Cプラットフォームが急速に増えています。EC、予約・決済、サブスクリプション、会員サービスなど、どの領域でも「パートナー企業ごとにブランドや料金、機能を変えたい」というニーズが強く、そのたびに個別開発していては、開発・運用コストが膨らみ、ビジネススピードが鈍ってしまいます。ここで効いてくるのがマルチテナント対応です。1つのアプリケーションとインフラを共有しながら、テナント（顧客企業）ごとにデータと設定を分離することで、スケーラブルなBtoB2Cプラットフォームを実現できます。

最初のうちは、顧客ごとに環境を分けたシングルテナント構成でも回ります。しかし、顧客数が10社、20社と増えてくると、仕様の微妙な違いが積み上がり、「誰も全体像を把握できない」「障害が起きるたびに全テナントを止めざるを得ない」といった問題が顕在化します。事業側では新しいパートナーとの提携や、新ブランド・新エリアの展開などにスピードを求められる一方、開発・運用側は「これ以上の個別対応は難しい」と悲鳴を上げる……。そうした成長痛を乗り越えるための解決策がマルチテナント化とSaaS化なのです。

マルチテナント対応したBtoB2Cプラットフォームにリプレイスできれば、新テナントの追加は「環境構築＋カスタマイズ」ではなく、「テナントを1件追加して設定を行う」作業に置き換えられます。結果として、リリース頻度の向上、テナント追加のリードタイム短縮、障害の影響範囲の限定、3〜5年単位でのTCO削減など、SaaS化のメリットを一気に享受できます。この記事では、あるBtoB2Cプラットフォームを題材に、どのようにマルチテナントなSaaS化プロジェクトを進めたのか、戦略・設計・移行の観点から実務レベルで解説します。

拡張前のBtoB2Cプラットフォームが抱えていた現実的な課題

今回のケースで取り上げるのは、複数の加盟店向けにオンラインサービスを提供するBtoB2Cプラットフォームです。もともとは特定の大口クライアント向けに構築したシステムからスタートし、その後類似案件が増えるなかで「少しだけ仕様の違うコピー」を横に並べていく形で拡大してきました。環境としては顧客ごとにサーバーを分ける疑似マルチテナントのような構成でしたが、ソースコードの実態は1つで、条件分岐と設定ファイルの組み合わせにより、各テナントごとの挙動を変える仕組みになっていました。

当初はこの方式でも問題ありませんでしたが、顧客企業が増え、パートナーごとに異なるキャンペーンや料金体系を持つようになると、コードベースは一気に複雑化します。「A社だけ特別なクーポンロジックを入れたい」「B社だけポイント付与条件を変えたい」「C社だけ決済手段を追加したい」といった要望に応え続けた結果、同じBtoB2Cプラットフォームの中に「A社だけ注意したいIF文」「B社だけONになるフラグ」が乱立し、誰も全体を把握できない状況になっていました。マルチテナントどころか、「テナント別の仕様を再現するのに開発者の勘が必要」という危険な状態です。

さらに、データベースは単一でテナント分離されておらず、テナントIDを条件に含めたSQLが多数存在するものの、インデックスやリソース配分が追いつかず、一部のテナントの負荷増加が他のテナントのレスポンス低下を引き起こすこともありました。いわゆるノイジーネイバー問題であり、「テナント分離されていないBtoB2Cプラットフォーム」が抱えやすい典型的な課題です。ここに障害対応や問い合わせ対応の負荷も加わり、「これ以上の事業拡大は難しい」という限界点が見えてきました。

事業サイドでも、問題は深刻でした。新しい提携先との契約が決まり、できるだけ早くBtoB2Cプラットフォーム上でサービスを開始したいにもかかわらず、環境準備から仕様確認、テスト、個別カスタマイズを含めるとローンチまでに数カ月かかるケースが常態化していました。ここで経営陣と事業責任者が決断したのが、「既存システムを前提とした延命ではなく、マルチテナントを前提としたSaaS化に踏み切る」という方針です。これによって、同じリソースでより多くのテナントを載せられるBtoB2Cプラットフォームへの進化を目指すことになりました。

マルチテナントSaaS化プロジェクトの要件定義と検討ポイント

マルチテナント対応したBtoB2Cプラットフォームを設計するうえで、最初の山場となるのが要件定義です。ここで曖昧さを残すと、後続の設計・実装フェーズで「やり直し」や「テナントごとの例外処理」が増えてしまい、結果としてSaaS化のメリットが薄れてしまいます。要件定義では、まず「どこまで共通化し、どこからテナントごとに分離するのか」という境界線を、ビジネス・運用・技術の観点から整理します。例えば、売上・顧客・権限といったコアデータは必ずテナント分離し、監査ログや共通マスタは共有する、といった判断です。

次に、料金・契約・権限に関する要件を具体化します。プラン別に利用できる機能をどこまで細かく切り分けるか、API利用量やストレージ容量に応じた課金を行うのか、テナント管理者が自社内ユーザーの権限をどこまでコントロールできるのか、といった点はマルチテナントなSaaS化モデルでは非常に重要です。また、テナントをまたいだデータアクセスは原則禁止とするのか、一部の分析用データだけ集約して利用するのかなど、データ利用ポリシーも早い段階で合意しておく必要があります。

非機能要件も、マルチテナント対応では見落とせません。性能（1テナントあたりのトラフィック上限・同時接続数）、可用性（SLA・RPO/RTO）、セキュリティ（暗号化・アクセス制御・ログ保持期間）、運用（監視・アラート・バックアップ）などを、テナント単位でどう扱うかを決めておかなければなりません。特にBtoB2Cプラットフォームでは、1つの障害が複数テナントのビジネスに影響するため、「どの範囲が共通基盤の責任で、どこからがテナントの責任か」を明確にしたSLAが不可欠です。

事業責任者・マネージャーとしては、「技術的に可能かどうか」だけでなく、「自社の収益モデルと営業・サポート体制に合うSaaS化の形は何か」を考えることが重要です。例えば、エンタープライズ向けにはテナント専用環境や専用DBを提供し、中小企業向けには標準的なマルチテナント型BtoB2Cプラットフォームを提供する、といったラインナップ設計も選択肢に入ります。要件定義の段階で「何を売りたいのか」「どこで差別化したいのか」を整理し、それに合わせてマルチテナント化・SaaS化の要件を言語化していくことが成功のカギとなります。

実務で使えるマルチテナントアーキテクチャ設計パターン

要件が固まったら、次はマルチテナント対応のアーキテクチャ設計です。代表的なパターンとして、「DB分離」「スキーマ分離」「行レベル分離（tenant_idカラム）」の3つがあります。DB分離はテナントごとにデータベースを分ける方式で、セキュリティやパフォーマンスを確保しやすい反面、運用コストが高くなりがちです。行レベル分離はひとつのDB・スキーマに複数テナントのデータを格納し、tenant_idで論理的に分離する方式で、多数のテナントを抱えるBtoB2CプラットフォームのSaaS化には適していますが、実装ミスがあるとデータ漏えいに直結します。実務では、標準テナントは行レベル分離、大手顧客や規制業種のテナントはDB分離、というハイブリッドなマルチテナント構成が現実的です。

認証・認可の設計も重要です。特にBtoB2Cプラットフォームでは、テナント企業ごとにIdP（アイデンティティプロバイダ）やSSO要件が異なるケースが多く、SaaS基盤としては「テナントID＋ユーザーID」を軸にした認可モデルを用意する必要があります。アプリケーション側では、あらゆるクエリ・API・画面アクセスでテナントIDを必須とし、「テナントIDが混在する操作を原則禁止」にすることでマルチテナントの境界を守ります。また、管理画面では、プラットフォーム管理者（運営側）とテナント管理者（顧客側）で見える情報・操作できる範囲を明確に分けることで、誤操作や情報漏えいを防ぎます。

もう1つの設計の肝がカスタマイズ戦略です。テナントごとの要望をすべてコード分岐で実装してしまうと、せっかくのマルチテナントが「条件分岐だらけの巨大モノリス」に逆戻りします。そのため、画面テーマ（ロゴ・カラー・レイアウト）、通知ルール（メール・SMS・LINEなど）、ワークフロー（承認ステップ・通知先）などは設定・テンプレート化し、プラグインやWebhook、外部ワークフローエンジンなどを使って一部の業務を外出しする設計が有効です。こうすることで、標準機能でカバーできる範囲を最大化しつつ、どうしても必要な差分だけ拡張ポイントで吸収できます。

インフラ面では、コンテナオーケストレーション（例：Kubernetes）を活用し、テナント単位のリソース制限やオートスケールを組み込むことで、「特定テナントの急激な負荷増加が他のテナントに波及しない」マルチテナント運用が可能になります。監視・ログも、テナントIDを軸にダッシュボードを作成することで、「どのテナントがどの程度BtoB2Cプラットフォームを利用しているか」「どこでエラーが多発しているか」を一目で把握できます。こうしたアーキテクチャ設計を通じてはじめて、本当の意味でのSaaS化されたマルチテナントBtoB2Cプラットフォームが実現します。

既存BtoB2Cプラットフォームを止めずにSaaS化・マルチテナント化する手順

既存のBtoB2Cプラットフォームをゼロベースで置き換えるのは、リスクもコストも大きく、現実的ではありません。そこで有効なのが、「段階的にSaaS化・マルチテナント化を進める」アプローチです。具体的には、新アーキテクチャに基づく共通基盤を先に用意し、一部のテナントから順に移行していく方法を取ります。このとき、機能フラグ（feature flag）やテナントごとのルーティング設定を用いて、「同じドメインからアクセスしていても、テナントによって旧システムと新システムを切り替える」構成を取ることで、サービス停止を最小限に抑えながらマイグレーションを進められます。

データ移行も、慎重な設計と手順が必要です。既存DBにテナントIDを付与していくのか、新しいマルチテナント対応DBへ段階的に移行するのか、履歴・ログ・バックアップの扱いをどうするのかなど、検討すべきことは多岐にわたります。実務では、まず新DBにスキーマだけ用意し、特定テナントのデータを一部コピーして結合テストを行い、その後バッチ処理やオンライン移行ツールを使って本番データを流し込む、というステップを踏むことが多いです。その際、移行前後で売上・残高・在庫などの重要指標が一致しているかを自動で検算する仕組みを用意すると、移行ミスを早期に検知できます。

テストと監視も、マルチテナントならではの視点が求められます。機能テスト・E2Eテストに加えて、「テナント間でデータや処理が混ざっていないか」を確認するテストケースを用意し、テナント境界が破られていないかを継続的にチェックする必要があります。監視では、プラットフォーム全体のメトリクスに加え、「テナントごとのエラーレート・レスポンス時間・リソース使用量」を可視化し、特定テナントの異常が他のテナントに波及する前に気づけるようにしておくことが重要です。こうした運用の仕組みまで含めて整えていくことで、「止めずにSaaS化・マルチテナント化」を実現できます。

プロジェクトマネジメントの観点では、「どのテナントから移行するか」の優先順位付けが成否を分けます。新機能への期待が高く、かつ要件が比較的シンプルなテナントをパイロットとして選び、そこで得られた学びをもとに残りのテナントへ展開していくのが定石です。また、テナント側の業務担当者を巻き込み、テストや受け入れのプロセスを事前に合意しておくことで、「思っていたのと違う」という認識ギャップを減らせます。こうした段階的な移行を通じて、既存のBtoB2Cプラットフォーム全体を、徐々にマルチテナントなSaaS化基盤へと切り替えていくことが現実的なアプローチです。

まとめ：マルチテナント対応を成功させるチェックリストとソフィエイトの支援

ここまで、あるBtoB2Cプラットフォームを題材に、マルチテナント対応とSaaS化のポイントを整理してきました。振り返ると、成功の鍵は「技術の前にビジネスモデルと運用を描くこと」にあります。どのような顧客セグメントをターゲットとし、どのような料金体系・SLA・サポート体制で提供するのかを定めたうえで、テナント境界やデータ分離、認証・認可、カスタマイズ戦略を設計していくことで、はじめて持続可能なマルチテナント型BtoB2Cプラットフォームが成立します。逆に言えば、これらが曖昧なまま進めてしまうと、「結局テナントごとの個別対応に追われるSaaSもどき」になりかねません。

事業責任者・マネージャーの方にとって、まず取り組みやすいのは、現状のシステムやサービスを前提に「もし今からマルチテナント対応のBtoB2Cプラットフォームをゼロから設計するとしたら、何を共通化し、何をテナントごとに変えたいか」を紙に書き出してみることです。そのうえで、技術チームや外部パートナーとディスカッションしながら、「段階的にSaaS化していくロードマップ」を描いていくと、DXの道筋が具体的に見えてきます。

株式会社ソフィエイトでは、こうしたマルチテナント対応のBtoB2Cプラットフォーム構築や、既存システムのSaaS化プロジェクトを、要件定義からアーキテクチャ設計、プロトタイプ開発、移行計画の策定まで一気通貫で支援しています。「どこから手を付ければいいのか分からない」「なんとなくマルチテナントにしたいが、具体的な設計のイメージが湧かない」といった段階でも構いません。無料相談や簡易診断など、貴社の現状に合わせた入り口をご用意できますので、まずはお気軽にご相談ください。