2025年5月14日にオンラインセミナー『サービスの成長を加速する！アーキテクチャ設計のベストプラクティス』を開催いたしました。 この記事では当日用いた資料を公開し、そのポイントを解説しています。
はじめに
近年、製造業や建設業など、IT 企業以外でも Web やモバイル技術を活用した SaaS 型サービスやプラットフォームビジネスを展開する企業が増えています。このような BtoBのサービスは社内システムとは異なり、１つのシステムで複数の顧客に対してサービスを提供するため、アーキテクチャにおいても様々な考慮が必要です。
今回は、継続的な成長を遂げるために不可欠な「スケーラビリティ」「セキュリティ」「効率的な運用」を実現するアーキテクチャ設計について、基本的な考え方から解説します。また、具体的な設計判断に必要な知識を事例とともに、初心者にもわかりやすくご紹介します。
新規サービスの発案から展開までの流れ を下図に示していますが、今回は特に左下の新規サービスのシステム開発の部分に焦点を当てて解説します。
IT企業以外がサービスを提供する時代
現在、IT企業以外の企業が、社外向けにサービスの提供を検討・実施する例が増えてきていると感じています。その中でも特に、NCDCが支援してきたものでは次の2つのパターンが多いです。
既存製品・プロダクトとの連携
一つは、既存の製品やプロダクトと連携し、デジタル的な要素を加えることで顧客に新しいユーザー体験を提供するものです。
例えば、以下の3つが挙げられます。
- 家電や楽器などのコンシューマー向けプロダクトとモバイルアプリの連携: 家電をより便利に使えるようにする、楽器の練習を継続的に楽しく行えるようにするといったサービス
- 工場や工事現場で利用するBtoB向け製品との連携: 温度管理装置や重機と連携し、工場や工事現場で働く方向けのBtoBサービスを構築するケース
- 医薬品やヘルスケア系ハードウェアとの連携: 医薬品の処方に関する部分やウェアラブルデバイスなどと連携し、患者さんや医療関係者向けにサービスを提供するケース
これらのケースは、既存製品と組み合わせることで、ハードウェアの性能以外の部分で新たな差別化要素を加えていく方向性のものです。
社内システムをベースにしたBtoBサービス提供
もう一つは、社内で利用しているシステムをベースに、BtoBの社外向けサービスとして提供したいというケースです。
これは、特にその業界・業種において高いシェアを持つ大企業が取り組むことが多い傾向にあります。特定の業務領域のシステムと業務プロセスをセットで、業務のベストプラクティスとして、自社で開発は行わないがシステムを利用したいと考えている中小企業向けに販売するものです。
社外向けサービス開発≒SaaS開発の時代
複数のユーザーにサービスを直接提供する場合、SaaS形式が一般的です。Salesforceやfreeeのような、普段使っているサービスを想像するとわかりやすいでしょう。
従来のシステム開発では、顧客ごとに個別のサーバー環境を準備し、システムをセットアップする必要がありました。しかし、最近は、サービスとして共通の環境を用意し、複数の顧客がアクセスして利用するSaaSモデルが主流になっています。
SaaSの主な特徴
ユーザー側のメリット
- 申し込んだらすぐに利用できる
- 自前で環境を用意する必要がない
- 一般的に初期導入費用が安い
サービス提供側のメリット
- すばやく多くの顧客に提供しやすい
- インフラリソースや運用の人員の共通化によって最適化できる
共通のインフラと運用チームを活用することで、リソースのボトルネックを排除し、ビジネスをスケールしやすくできます。
ビジネスをスケールするために
ビジネス的にスケールできるようにするためには、以下の2点が重要です。
- 共通インフラ・アプリケーションでの対応
複数の顧客に対して、どのように共通のインフラやアプリケーションで対応するのか、どのようなアーキテクチャを採用するのかが重要です。 - 特定顧客からの独自機能要望への対応
特定の顧客から独自機能の要望があった場合、構成管理や運用が複雑になることを踏まえ、どのように対応するのかを検討する必要があります。
マルチテナントとは？
BtoCサービスではあまり見られませんが、BtoBサービスではマルチテナントという考え方を取り入れる必要があります。
マルチテナントとは、サービスを契約する企業や組織を「テナント」と見立て、それぞれのテナントが独立した区画のようにサービスを利用する形態です。商業施設に様々な店舗が入居するイメージに似ています。
そのため、BtoBサービスを開発する際は、ビジネス機能だけでなく、マルチテナントに特有の要件（オンボーディング、認証、セキュリティ、データの分離など）も考慮して設計に組み込む必要があります。
これらの機能についてはこの後に解説しますが、まず概要的なものを2点ご紹介します。
アプリケーションプレーンとコントロールプレーン
「アプリケーションプレーン」と「コントロールプレーン」は、SaaSのアーキテクチャを考える際に用いられる考え方で、AWSのホワイトペーパー「SaaSアーキテクチャの基礎」でも定義されています。
NCDCでよく使っている例を挙げると、以下のようになります。
- アプリケーションプレーン: ビジネスロジック、業務ロジック、データなどを持つ領域で、企業内で企画されているサービスそのものになります。
- コントロールプレーン: マルチテナントやSaaSで共通的に必要となる機能（テナント管理、認証など）を持つ部分です。
ECサイトのプラットフォームを例にすると、商品を検索したり一覧表示したりするサービス、カートに入れて注文するサービスなどがアプリケーションプレーンに該当し、これらのマイクロサービスに対して共通的に機能を提供するのがコントロールプレーンです。
用語の補足説明
ここで、あまり聞きなじみのない用語を2つ取り上げて補足しておきます。
- オンボーディング: 利用者がサービスを申し込み、実際に利用開始できるようになるまでのプロセスを指します。ECサイトのプラットフォームで言えば、お店のオーナーがお店を開設して実際に営業できるようになるまで、といったイメージです。「マルチテナントに必要な機能」にて詳細を説明しています。
- ティアリング: サービスのグレードやプランの違いを指します。Netflixの低解像度プランと高解像度プランのように、ベーシックティアとプレミアムティアで利用できる機能や費用が異なる、といったものです。
マルチテナントのアーキテクチャ選択
マルチテナント型のシステムを考える際、アーキテクチャの選択においては、大きく分けてプール型とサイロ型の2つのパターンがあります。
プール型
複数のテナントが共通のインフラやアプリケーションを共有して利用する形です。
- メリット
- すべてのテナントが共通のインフラをシェアしており、リソースを効率的に利用できる可能性が高い。
- デメリット
- 特定のテナントが高負荷なアクセスを行った場合、他のテナントに影響が出る可能性がある（「ノイジーネイバー問題」）。
- テナントごとのインフラコストを正確に算出するのが難しい（アクセス数やデータ使用量から類推するしかない）。
サイロ型
テナントごとに独立した環境を構築するパターンです。
- メリット
- テナントごとの独立した環境を持っており、他のテナントの影響を受けにくい。
- テナントごとのコストを明確に把握しやすい。
- デメリット
- テナントごとにリソースを確保するため、全体的なリソースの稼働率が低くなり、インフラの費用対効果が下がる。
- テナントが増えた際の環境準備や、テナントが解約した際の管理が複雑になる。
サイロ型とプール型の使い分けと戦略的選択
一般的に、プール型の方が良いことが多いですが、金融業界のように規制が厳しく他の会社とデータを相乗りできない場合や、既存システムをSaaSとして提供する際の移行段階としてサイロ型を採用する可能性もあります。これは戦略的に選択する必要があります。
もちろん、プール型とサイロ型を組み合わせることも可能です。例えば、アプリケーションサーバーはサイロ型でテナントごとに独立させ、データはプール型で共有する、あるいはその逆のパターンも考えられます。
また、ベーシックティアの企業にはプール型を提供する、プレミアムティアのテナントには独立した環境を用意するといった戦略も考えられます。
これらの「アプリケーションプレーンとコントロールプレーン」の話と「アーキテクチャのモデル」が、この後の説明の前提となります。
マルチテナントに必要な機能
オンボーディング
オンボーディングは、利用者がサービスを申し込み、利用可能になるまでのプロセスです。自動か手動かにかかわらず、何らかの形で必要になります。
オンボーディングは、顧客のサービス体験の最初のポイントとなるため、どのように設計するかが非常に重要です。オンボーディングでのエラーは、サービス体験を著しく悪化させ、顧客の離脱につながる可能性があるため、十分に注意する必要があります。
オンボーディングの裏側では、顧客が登録すると、コントロールプレーンがテナントの設定や認証設定を行い、アプリケーションプレーンがそのテナントが利用できるように設定します。
この「プロビジョニング」の複雑さは、採用したアーキテクチャのパターンによって変わります。プール型であれば、設定やデータベースへのデータ登録だけで利用可能ですが、サイロ型の場合はテナント用の環境構築が必要になります。
ユーザーの認証とテナント識別
一般的なユーザー認証に加え、マルチテナントでは、ユーザーがどのテナントに所属しているかを識別する必要があります。
また、テナント情報（名称、ティア、利用状況など）をサービスに渡す必要があります。
例えば、A株式会社の山田さんとB会社の鈴木さんがログインした場合、それぞれの本人認証はもちろん行いますが、テナント識別によって山田さんがA株式会社のベーシックティアのユーザーであることをアプリケーションに渡します。
個々のアプリケーションは、認証されたユーザーが所属するテナントの情報に基づき、そのテナントのデータを返す、あるいはティアに応じて提供する機能を切り替える、といった実装が必要になります。
テナントごとのアクセスポイント
ユーザーがサービスにアクセスする際の入り口について、大きく2つのパターンがあります。
- URLの一部で分ける: サブドメインで分けたり、URLのパスで分けたりします。
- 例：「mierukoji.jp」や「backlog.com」のように、サービス自体のドメインの前にテナント固有の情報が入るサブドメイン形式。
- ドメインは共通だが、パスやパラメーターの値で区別するパターン。
- ドメインそのものを利用企業ごとに分ける: ECサイトのプラットフォーム提供などのパターンです。テナントのブランド名やドメインが前面に出ることで、コンシューマー向けのサービスではブランディング上重要になる場合があります。
サブドメインでテナントを分離している例
データ分離
ユーザー認証とテナント識別の話とセットで、他のテナントのデータを参照できないようにする必要があります。プール型やサイロ型のアーキテクチャタイプを検討する際にも、データ分離を考慮する必要があります。
例えば、データベースであれば、以下の方法が考えられます。
- テナントごとにデータベースインスタンスを分ける（物理サーバーを分けるイメージ）
- サーバーは共通だが、テナントごとにデータベースを分ける
- 一つのデータベース内でテナントごとにテーブルを分ける
- 一つのテーブル内に複数のテナントのデータを管理する
上のものほどハードウェアレベルでの分離度が高くなりますが、テナントが増えた際の対応も複雑になります。
最も一般的なのは、一つのテーブルで複数のテナントを管理するモデルです。顧客テーブルの例で言えば、顧客IDや名前などの顧客情報に加え、テナントIDという列を持ち、データを取得する際に「テナントIDが○○」という条件で絞り込みます。
SELECT * FROM 顧客テーブル WHERE テナントID=“94499df4-1a45-41aa-8a75-4a22c9516416”;
この方法の場合、データ取得処理でテナントIDの条件指定を忘れると、他のテナントの情報が見えてしまうというバグにつながる可能性があります。テストで防ぐことも重要ですが、担当者が意識しなくても仕組みでカバーできる方が望ましいです。
利用しているデータベースやライブラリによりますが、例えばPostgreSQLであれば「行レベルセキュリティ」のような仕組みを活用することで、より安全にデータ分離を行うことが可能です。
具体的な方法はAWSのImplementing managed PostgreSQL for multi-tenant SaaS applications on AWS 「行レベルのセキュリティに関する推奨事項」をご確認ください。同様に、DynamoDBを使用する場合や、ファイルをS3に置いている場合も、AWS IAMと組み合わせることでデータの制御が可能です。
メトリクス
システムパフォーマンスの監視に加え、SaaSサービス開発では「どのテナントが、どのくらいリソースを使っているか（コストが掛かっているのか）」といった「ビジネス的なメトリクス」を収集することが不可欠です。
例えば、テナントのアクティブな利用状況を把握することで、以下のような分析が可能です。
- 最近契約したテナントがきちんとサービスを使っているか、あるいは全く使われずに解約につながっていないか
- 契約終了日が近づいており、かつ利用アクティブさが減っている契約解除を検討しているテナントはないか
これにより、カスタマーサクセスチームは顧客の利用状況を把握し、能動的なサポートや新機能の提案が可能になります。また、テナントごとのコスト分析にも役立ちます。
メトリクスの収集方法としては、CloudWatchからの集計や、S3に蓄積されたログファイルからの収集などが考えられます。メトリクスをログから収集する場合、テナントを識別できる必要があるため、ログのフォーマットを標準化し、テナント識別子を自動でいれてくれるような共通処理を用意しておくのがおすすめです。エラーが発生した時に、どのテナントのユーザーがエラーになっているのか分析できることは重要です。
このように収集したデータは、エンジニアだけでなく、カスタマーサクセス、サポート、プロダクトオーナー、営業など、様々な部門が活用できるようにすることが望ましいです。全員がデータにアクセスできる環境を整えることで、組織全体の顧客理解が深まり、より効果的なビジネス運営に繋がります。
- 日次バッチで集計し、CSVファイルを共有場所に配置
- 簡単なWebアプリでダッシュボードを作成する
- Amazon QuickSightなどのBIツールで把握できるようにする
マルチテナントのアーキテクチャ例
NCDCが提供している建設業界向けのSaaS「ミエルコウジ」を例に、アーキテクチャのサンプルをご紹介します。
ミエルコウジは、基本的にプール型モデルを採用しています。複数のテナントが共通のコンテナ環境（アプリケーションサーバー）やデータベースを使用しています。ただし、一部テナントごとに異なる処理が必要な機能は、AWS Lambdaのような形で外出しにしています。
そのため、新しいテナントが増えた場合のオンボーディングでは、データベースへのテナント登録、テナント管理者アカウントの追加、テナント用サブドメインのDNSサーバー登録、テナント用Lambdaのデプロイなどを行います。
このように、実際にはプール型とサイロ型のハイブリッドモデルになることも少なくありません。
NCDCのサービスご紹介
今回取り上げた内容に関連したNCDCのサービスをご紹介します。
- 新規サービスアーキテクチャコンサルティング: 社外向けサービスに限らず、新規サービスのアーキテクチャをどのようにすべきか、AWS、Google、Azureなどの様々なサービスの中からどの技術を選定すべきか、といったご支援が可能です。
- サービス開発キット: 前述のコントロールプレーンのような共通的に必要となる機能を、開発キットとしてご提供しています。
サービス開発キットについて
サービス開発キットでは、アプリケーションプレーンとコントロールプレーンについて、前述の項目に加え、以下の機能を追加しています。
- コントロールプレーン: 顧客向け情報提供サイト、カスタマーサポート機能
- アプリケーションプレーン: 帳票機能、マスター管理、メール・モバイルへのプッシュ通知、ワークフロー、マスターメンテナンスといった共通機能
- テナント管理: ウェブ管理画面から、テナントの新規追加、一覧表示、詳細情報の確認（利用期間、利用状況、請求状況など）が可能です。
- ユーザー管理: テナント代表の管理者ユーザーや一般ユーザーの管理が可能です。
- 認証機能: ユーザー管理とセットで、ユーザー認証と、ユーザーがどのテナントに所属しているかの確認を行い、アプリケーション側に情報を渡す仕組みを提供しています。
- 請求機能: 請求書発行やクレジットカード決済を行う機能があります。内部的にはStripeなどの決済サービスを利用し、使いやすくしています。
- 顧客向けサービスサイト・サポートサイト: お知らせページ、利用許諾ページ、ステータスページなど、メイン機能ではないが必要となるページや、マニュアル公開、チャットボットによるQ&A窓口など、サポート関連の仕組みも提供可能です。
- 共通機能: プッシュ通知の管理画面、帳票テンプレートの登録・API呼び出しによる帳票生成機能などをご提供しています。
サービス開発キットのご利用の流れ
サービス開発キットは、要件定義フェーズでのご検討が最適です。
サービス開発キットの仕様をデモを交えてご紹介し、個社ごとにサービス内容との適合度やギャップを洗い出します。適合度が高い場合は、NCDCが持つ開発ガイドラインなどを基に、企業のアプリケーションに組み込んでいただくことを想定しています。
もちろん、組み込み部分のサポートも可能ですので、お気軽にご相談ください。
新規事業のデジタルサービス開発はNCDCへ
新規事業の立ち上げに欠かせないテナント管理・認証・決済といった共通機能は、サービス開発キットとしてご提供しており、開発効率を大きく高めることが可能です。さらに、各サービスの内容に応じたカスタマイズや開発サポートにも対応しています。
NCDCでは、新規サービスの企画からデザイン、運営までを一貫してご支援しています。今回ご紹介した内容に限らず、少しでも関心をお持ちいただける点があれば、ぜひお気軽にお問い合わせください。
