マルチテナント設計 ― 1つのアプリで複数顧客を安全に捌くデータ設計の基本

SaaSは，1つのアプリケーションを多数の顧客が共有して使う．あなたの顧客A社とB社は，同じプログラム・同じサーバーを使いながら，互いのデータは決して見えてはならない．これを実現するのがマルチテナント設計だ．

この設計を誤ると，『A社の画面にB社のデータが表示される』という，SaaSにとって最悪のデータ漏洩事故が起きる．一度でも起これば，信頼は完全に失われる．マルチテナントは，安全性の心臓部だ．

この記事は，認証を実装し終え，本格的なSaaSのデータ設計に進む個人開発者に向けて書いている．テナントとは何か，どう分離するか，どう識別するか，どうやってデータ漏洩を防ぐかを，個人開発で現実的な方法に絞って解説する．

扱う範囲は，テナントの概念 → 3つの分離方式 → 方式の選び方 → テナント識別 → データ漏洩を防ぐ実装 → 組織とユーザーの関係 → 権限管理 → スケールと運用 → よくある失敗，だ．読み終えたとき，あなたは安全に複数顧客を捌くデータ設計の指針を得ている．

なぜマルチテナント設計が「最重要」なのか

マルチテナントとは，1つのシステムを複数のテナント(契約者＝顧客や組織)で共有する方式だ．マンションに例えれば，1棟の建物(アプリ)を多数の世帯(テナント)が使い，各部屋の中は完全に独立している状態である．

この方式の利点は明確だ．1つのアプリ・1つのインフラを全顧客で共有できるため，運用が1人で回せ，コストも極小に保てる．顧客ごとに別々のシステムを用意していたら，個人ではとても捌けない．

しかし共有するからこそ，『データの分離』が生命線になる．同じDBに全顧客のデータが混在する以上，取り出すときに『このテナントのデータだけ』を厳密に絞り込めなければ，漏洩は即座に起きる．

本記事のメッセージは，『効率のために共有し，安全のために厳密に分離する』．この一見矛盾する2つを両立させる設計こそ，マルチテナントの核心だ．個人開発でも，最初から正しく設計すれば難しくない．

テナントとは何か ― マルチテナントの基本概念

テナント(Tenant)とは，サービスを契約して使う単位のことだ．個人向けサービスなら『ユーザー1人＝1テナント』，法人向けなら『1社＝1テナント(その中に複数の従業員ユーザーがいる)』となることが多い．

重要なのは，『データは必ずどこかのテナントに属する』という大原則だ．すべてのデータに『どのテナントのものか』という情報を持たせ，アクセス時はそのテナントの範囲に限定する．これがマルチテナントの土台になる．

対義語の『シングルテナント』は，顧客ごとに独立したシステムを用意する方式だ．分離は完璧だが，顧客が増えるほど運用が爆発し，個人には不向き．マイクロSaaSは原則マルチテナントを選ぶ．

「ユーザー」と「テナント」を区別する

個人開発者が混同しがちなのが，ユーザー(ログインする個人)とテナント(契約の単位)だ．個人向けなら一致することもあるが，法人向けでは『1テナント(会社)に複数ユーザー(従業員)』という階層になる．

この区別を最初に決めておくと，後の設計が安定する．将来チーム利用に対応する可能性があるなら，最初から『テナント』という概念を立てておく方が，後の作り直しを避けられる．

テナントは課金の単位にもなる

多くのSaaSでは，課金の単位＝テナントだ．『会社単位で契約し，従業員は何人でも使える(または人数課金)』という形になる．テナント設計は，第10回で扱う課金設計と密接に結びつく．

つまりテナントは，データ分離・権限・課金が交わる中心概念だ．ここを最初に丁寧に設計しておくことが，SaaS全体の安定につながる．

3つの分離方式 ― データをどう分けるか

テナントのデータを分離する方式は，大きく3つある．『共有DB・共有テーブル』『共有DB・スキーマ分離』『DB分離』だ．分離の強さと，運用の手軽さがトレードオフになる．

結論を先に言えば，個人開発のマイクロSaaSでは，多くの場合『共有DB・共有テーブル＋テナントID』方式が最適だ．最もシンプルで，運用が楽で，コストも低い．まずこの方式を理解しよう．

『分離が弱い方式で大丈夫か』と不安になるかもしれないが，共有テーブル方式でも，実装で正しくテナントを絞り込めば安全は確保できる．分離の強さは物理的な壁ではなく，規律あるコードで担保するのが，個人開発の現実解だ．

共有テーブル＋テナントID方式とは

この方式では，すべてのテーブルに『テナントID』の列を持たせ，全データがどのテナントのものかを記録する．データを取得・更新するときは，必ず『現在のテナントID』で絞り込む．

シンプルゆえに実装も運用も軽く，バックアップも1つのDBで済む．マイクロSaaSの規模なら，この方式の性能・安全性で十分なことがほとんどだ．まずはこれを基本に考えよう．

DB分離が向く特殊なケース

顧客ごとにDBを物理的に分ける方式は，極めて高い機密性が求められる・顧客がデータの完全分離を契約条件にするといった特殊な場合に検討する．分離は最強だが，運用・マイグレーション・コストの負担が大きい．

個人開発の初期にこの方式を選ぶのは，ほぼオーバーエンジニアリングだ．本当に必要になるまでは，共有方式で身軽に運営するのが賢明である．

方式の選び方 ― 個人開発はまず共有方式

どの分離方式を選ぶかは，『機密性の要求』と『運用できる体力』のバランスで決まる．個人開発では，運用の手軽さを最優先し，共有テーブル方式から始めるのが定石だ．

前回までと同じく，ここでも『将来のために重い方式を選ばない』．顧客が増え，特定顧客が強い分離を求めてきたら，その時に上位の方式を検討すればよい．今ない要件のために複雑化しない．

判断に迷ったら，『共有DB・共有テーブル＋テナントID』を選び，コードで厳密に分離を徹底する．これが個人開発のマルチテナントの王道だ．性能や分離が問題になるのは，嬉しい悲鳴(大成功)の後の話である．

後から方式を変えられるよう備える

共有方式で始めても，『すべてのデータがテナントIDを持つ』設計にしておけば，将来より強い分離方式へ移行する余地は残る．最初からテナントを一級の概念として扱っておくことが，将来の選択肢を守る．

逆に，テナントの概念を曖昧にしたまま作ると，後からの分離強化が困難になる．方式は変えられても，テナントIDの欠如は致命的だ．ここだけは最初から徹底しよう．

「特定の大口顧客だけ分離」も後で選べる

共有方式で運営していて，特定の大口顧客だけが強い分離を求めてきた場合，その顧客だけ専用DBに切り出す『ハイブリッド運用』も可能だ．全顧客を一律に重い方式にする必要はない．

このように，テナントIDを土台に持っていれば，顧客の要求に応じて分離の強さを個別に調整できる．最初から全部を分離するのではなく，必要な顧客に必要な分だけ対応する── これが個人開発で運用負荷とコストを抑えるコツだ．

テナントの識別 ― 「今どのテナントか」を特定する

リクエストが来たとき，システムは『今アクセスしているのはどのテナントか』を正しく特定しなければならない．これを誤ると，別テナントのデータを返す事故になる．

識別の主な方法は，ログインユーザーの所属から特定する・サブドメインで分ける・URLパスに含めるなどだ．個人開発では，ログインユーザーに紐づくテナントを使う方法が最もシンプルで安全だ．

サブドメイン方式は『顧客ごとの専用URL』という見栄えの良さがあるが，ドメイン(ワイルドカード)とサーバーの設定が必要になる．MVPでは，ログインユーザーの所属からテナントを特定する方式で十分だ．

テナント識別は「サーバー側で」確定する

テナントの特定は，クライアントから送られてくる値を信用せず，サーバー側でログイン情報をもとに確定する．『リクエストにテナントIDが入っているからそれを使う』では，書き換えで他テナントになりすませてしまう．

原則は『テナントはログインセッションから導く』．ユーザーが認証された時点でテナントが確定し，以降のすべての処理がその範囲に縛られる── この流れを徹底すれば，識別の事故は防げる．

データ漏洩を防ぐ実装 ― 最重要の防御

マルチテナントで絶対に防ぐべきは，『テナント間のデータ漏洩』だ．共有テーブル方式では，データ取得時のテナント絞り込みを1か所でも忘れると，即座に他テナントのデータが見えてしまう．

防御の核心は，『すべてのデータアクセスに，必ずテナントの条件を付ける』こと．これを開発者の注意力だけに頼ると，必ずどこかで漏れる．仕組みで強制するのが正解だ．

おすすめは，データアクセスの共通層で，自動的にテナント条件を付与する仕組みを作ることだ．個別のクエリで毎回書くのではなく，『テナントで絞り込むのを忘れられない』設計にする．これがヒューマンエラーを根絶する．

「デフォルトで絞り込む」設計にする

理想は，何もしなくても現在のテナントのデータしか取れない状態だ．多くのフレームワークやORMには，クエリに自動で条件を追加する仕組み(スコープ等)がある．これを使い，テナント絞り込みを既定の動作にする．

『絞り込みを書いたら安全』ではなく『絞り込みを外さない限り安全』── この発想の転換が，漏洩事故を構造的に防ぐ．個人開発でこそ，注意力に頼らない仕組み化が効く．

テストで「越境」を検知する

テナント分離は，テストで守るのが効果的だ．『テナントAでログインして，テナントBのデータにアクセスを試みたら，必ず失敗する』というテストを書いておけば，将来のコード変更で分離が壊れてもすぐ気づける．

データ漏洩は，新機能追加のときにうっかり起きやすい．越境を検知するテストを1つ用意しておくだけで，安心感が大きく変わる．最重要の防御線として，ぜひ仕込んでおきたい．

組織とユーザーの関係 ― チーム利用に備える

法人向けSaaSでは，1つのテナント(組織)に複数のユーザー(メンバー)が所属する構造になる．この『組織⇄ユーザー』の関係を，データモデルとして正しく表現する必要がある．

基本は，組織テーブル・ユーザーテーブル・所属を表す中間の関係で構成する．1人のユーザーが複数組織に所属するケース(複数の会社で使う)まで見据えるなら，多対多の関係にしておくと柔軟だ．

ここでも過剰設計は禁物だ．個人向けや『1ユーザー＝1テナント』で始めるなら，組織の概念は後から足してもよい．ただしテナントIDだけは最初から全データに持たせ，将来の組織化に備えておこう．

メンバー招待の仕組み

チーム利用に対応するなら，『既存メンバーが新しいメンバーを招待する』仕組みが要る．招待リンクをメールで送り，受け取った人がそのテナントに参加する流れだ．前回のメール送信・トークンの知識がここで活きる．

招待まわりは，権限(誰が招待できるか)とも絡む．MVPでは『最初の登録者が管理者』というシンプルな形から始め，必要に応じて役割を増やすとよい．

1人が複数テナントに属する場合

実運用では，1人のユーザーが複数の組織（テナント）に所属するケースが出てくる．たとえば取引先と自社の両方で同じSaaSを使う，といった場面だ．この可能性があるなら，ユーザーとテナントを多対多の関係にしておくと柔軟に対応できる．

その場合，ログイン後に『どのテナントとして操作するか』を切り替えるUIが必要になる．複雑に感じるかもしれないが，最初は1人1テナントで始め，要望が出てから多対多に拡張する判断でも構わない．テナントIDさえ全データにあれば，移行は可能だ．

権限管理 ― テナント内の役割を分ける

1テナントに複数ユーザーがいると，テナント内での権限(役割)が必要になる．『管理者は全員のデータを見られるが，一般メンバーは自分の担当だけ』といった制御だ．前回の認可の話が，テナント文脈で再登場する．

個人開発では，まず『管理者』と『一般メンバー』の2役割から始めるのが現実的だ．細かな権限設定は，顧客の要望が出てから足せばよい．最初から複雑な権限体系を作り込まない．

重要なのは，権限チェックもテナントの範囲内で行うことだ．『管理者は全データを見られる』も，あくまで『自テナント内の全データ』であって，他テナントには絶対に及ばない．認可とテナント分離は二重の防御として機能する．

権限は「足りない所から足す」

権限設計は，最初から網羅しようとすると複雑になりすぎる．『最小の役割で始め，顧客が困った所だけ足す』のが，個人開発の鉄則だ．使われない細かな権限を作り込むのは，時間の無駄になる．

実際の顧客の運用を見れば，本当に必要な権限が分かる．机上で完璧な権限体系を設計するより，シンプルに始めて現場の声で育てる方が，的確で軽い設計になる．

スケールと運用 ― 共有方式で増えてきたら

共有テーブル方式は，顧客が増えてもデータが1つのDBに溜まっていく．マイクロSaaSの規模なら問題ないが，大成功してデータが膨大になったときの備えも，頭の片隅に置いておきたい．

対策は，データ量が問題になってから打てばよい．インデックスの最適化，重いテナントの分離，DBの増強など，選択肢は多い．最初から心配して複雑化するより，増えてから対処する方が合理的だ．

個人開発で『スケールの心配』が現実になるのは，ビジネスが大成功した証拠だ．それは喜ばしい問題であり，その頃には対処する資金も知見もある．今は，共有方式のシンプルさを存分に享受しよう．DB運用の詳細は第9回で扱う．

テナントごとの利用状況を把握する

運用が進むと，『どのテナントがどれだけ使っているか』を把握したくなる．テナント単位の利用状況は，課金(第10回)・チャーン分析(第24回)・サポートの優先度判断など，経営に直結する重要データだ．

テナントIDで全データを整理しておけば，こうした集計も容易になる．マルチテナント設計は，安全性だけでなく，事業を数字で見る土台にもなっているのだ．

「重いテナント」を見つけて手を打つ

共有方式では，ごく一部の『極端に大量のデータや負荷を生むテナント』が，全体の性能を引っ張ることがある．テナント単位で利用量を見ておけば，こうした重いテナントを早期に発見し，個別に対処（専用環境へ移すなど）できる．

全体を一律に増強する前に，ボトルネックになっているテナントだけ手を打つ方が，コスト効率が良い．テナント単位の可視化は，性能対策をピンポイントで行うための目にもなる．性能計測の具体策は第35回で扱う．

テナントのライフサイクル ― 作成から解約・削除まで

テナントには，『生まれてから消えるまで』のライフサイクルがある．新規契約でテナントが作られ，利用され，やがて解約され，最終的にデータが削除される．この一連の流れを設計しておかないと，運用で必ず困る．

とくに見落とされがちなのが『解約後のデータの扱い』だ．解約された瞬間に即削除してよいのか，一定期間は保持して復帰に備えるのか．法的・顧客対応の両面から，方針を決めておく必要がある．

解約直後にデータを消すのは危険だ．『誤解約からの復帰』や『再契約』に備え，一定期間は凍結保存するのが親切で安全．一方，顧客から削除要請があれば，確実に消去できる仕組みも必要だ．個人情報保護の観点からも，削除の方針は明文化しておきたい．

テナント作成を自動化する

サインアップからテナントの作成・初期設定までを自動化しておけば，新規契約のたびに手作業が発生せず，1人でも回せる．登録と同時にテナントが立ち上がり，すぐ使い始められる流れが理想だ．

ただしMVPの初期は，前回学んだ通り手動運用でも構わない．契約が来たら自分でテナントを用意する形から始め，件数が増えて大変になったら自動化する，という順序で十分だ．

解約データの保持期間を決めておく

解約後のデータを何日間・どの状態で保持するかを，あらかじめ決めて利用規約に明記しておこう．『解約後30日間は凍結保存し，その後完全削除』といった方針があれば，顧客にも説明でき，トラブルを避けられる．

この方針は，第29回で扱う法務・規約とも関わる．データ削除の要請への対応も含め，テナントのライフサイクルは，技術だけでなく信頼と法令遵守の問題でもあると意識しておきたい．

マルチテナントでやりがちな失敗

最後に，個人開発のマルチテナント実装でありがちな失敗を確認しよう．いずれも，データ漏洩という最悪の事故に直結しうる．

• テナントIDを持たないテーブルを作る：どのテナントのデータか分からなくなる
• 絞り込みを個別クエリに任せる：1か所の書き忘れで漏洩
• クライアントの値でテナントを判定：書き換えでなりすまされる
• 権限チェックがテナントを越える：管理者が他テナントを見られてしまう
• 最初から重い分離方式を選ぶ：運用が回らず個人で破綻

共通する教訓は，『すべてのデータをテナントに属させ，絞り込みを仕組みで強制する』ことだ．注意力ではなく構造で守る．これさえ徹底すれば，共有方式でも安全なマルチテナントSaaSが，個人でも十分に作れる．

公開前に「越境テスト」を必ず行う

公開前には，実際に2つのテナントを作り，一方から他方のデータにアクセスできないことを手で確認しよう．URLのID書き換えなども試す．この数十分の確認が，致命的な漏洩事故を防ぐ最後の砦になる．

マルチテナントの安全性は，SaaSの信頼そのものだ．面倒でも，分離が確実に効いていることを自分の目で確かめてから，世に出そう．

補論 ― 複数顧客を支える「土台」も共有で効率化する

マルチテナントは，1つのアプリで複数顧客を捌くことでアプリ層を効率化する考え方だ．同じ発想は，それを動かすインフラ層にも当てはまる．1台のサーバーで，複数のサービスや環境を効率的に同居させられる．

高速NVMe・50種類以上のOSテンプレートに対応した国内VPS─シン・VPS─のような高性能なVPSなら，1台で本番アプリ・データベース・検証環境までまとめて動かせ，マルチテナントなSaaSを低コストで支えられる．自分でリソースを制御できるため，特定テナントが重くなった際の対処も自在だ．そして各サービスの顔となる独自ドメインやサブドメインは，取り扱い400種類以上のドメイン取得サービス─ムームードメイン─で柔軟に取得・運用できる．サブドメイン方式のテナント識別を採るなら，ドメイン運用の自由度は特に重要になる．

『アプリも，インフラも，共有で効率化し，分離は厳密に』── これが個人開発でSaaSを賢く運営する要諦だ．テナント設計が固まったら，その土台となるデータベースそのものの設計と運用へ進もう．次回は『データベース設計の実践』を解説する．

よくある質問(FAQ)

Q1．マルチテナントとは結局何ですか？

1つのアプリ・インフラを複数の顧客（テナント）で共有しつつ，各テナントのデータは互いに見えないよう分離する方式です．マンションで1棟を多世帯が使い，各部屋は独立しているイメージ．1人で多数の顧客を運用でき，コストも抑えられるため，マイクロSaaSの基本形になります．

Q2．どの分離方式を選べばいいですか？

個人開発では多くの場合『共有DB・共有テーブル＋テナントID』方式が最適です．最もシンプルで運用が楽く，バックアップも1つで済みます．分離はコードで厳密に絞り込んで担保します．DB物理分離は，極めて高い機密性が契約上求められる特殊な場合にのみ検討してください．

Q3．共有テーブル方式で本当に安全ですか？

実装で正しくテナントを絞り込めば安全を確保できます．鍵は『すべてのデータアクセスに必ずテナント条件を付ける』ことを，注意力でなく仕組みで強制すること．ORMのスコープ等で『絞り込みを外さない限り安全』な状態を作り，越境テストで守れば，共有方式でも十分安全です．

Q4．テナントIDは全テーブルに必要ですか？

テナントに属するデータを持つテーブルには必須です．これを欠くと『どのテナントのデータか』が分からなくなり，分離も将来の方式変更も不可能になります．方式は後から変えられても，テナントIDの欠如は致命的なので，最初から全データに持たせてください．

Q5．テナントはどうやって特定すればいい？

個人開発では，ログインユーザーの所属からサーバー側で特定するのが最もシンプルで安全です．クライアントから送られるテナントIDを信用すると，書き換えでなりすまされます．テナントはログインセッションから導き，以降の全処理をその範囲に縛りましょう．サブドメイン方式は見栄えは良いですが設定が増えます．

Q6．他テナントのデータが見える事故を防ぐには？

データアクセスの共通層で，自動的にテナント条件を付与する仕組みを作ります．個別クエリで毎回書くと必ずどこかで忘れます．さらに『テナントAから テナントBのデータにアクセスしたら必ず失敗する』というテストを用意し，コード変更で分離が壊れてもすぐ気づける状態にしておきましょう．

Q7．組織（チーム利用）は最初から作るべき？

個人向けや『1ユーザー＝1テナント』で始めるなら，組織の概念は後から足せます．ただしテナントIDだけは最初から全データに持たせてください．将来チーム利用に対応する可能性が高いなら，最初から組織⇄ユーザーの関係を立てておくと作り直しを避けられます．

Q8．顧客が増えてデータが膨大になったら？

それはビジネス成功の証で，対処はその時で十分です．インデックス最適化，重いテナントの分離，DB増強など選択肢は多くあります．最初から心配して複雑な構成にするより，共有方式のシンプルさを享受し，増えてから対処する方が合理的です．

Q9．マルチテナントとシングルテナントはどう違いますか？

マルチテナントは1つのアプリ・インフラを複数の顧客で共有する方式で，1人で多数の顧客を運用でき，コストも抑えられます．シングルテナントは顧客ごとに独立したシステムを用意する方式で，分離は完璧ですが，顧客が増えるほど運用が爆発し，個人には不向きです．マイクロSaaSは原則マルチテナントを選び，データの分離はコードと仕組みで厳密に担保します．

Q10．テナント分離のテストはどう書けばいいですか？

『テナントAでログインして，テナントBのデータにアクセスを試みたら必ず失敗する』という越境テストを書きます．これを用意しておけば，将来のコード変更で分離が壊れてもすぐ気づけます．データ漏洩は新機能追加のときにうっかり起きやすいので，この検知テストを1つ仕込んでおくだけで安心感が大きく変わります．公開前には実際に2テナントを作り，手でも越境できないことを確認しましょう．

まとめ ― 効率のために共有し，安全のために分離する

マルチテナント設計は，1つのアプリで複数顧客を捌くことで運用を1人で回し，コストを抑えるマイクロSaaSの根幹だ．同時に，テナント間のデータ漏洩を防ぐことが，SaaSの信頼を守る生命線になる．

鍵は，『共有テーブル＋テナントIDで始める』『テナントはサーバー側で確定』『絞り込みを仕組みで強制』『越境テストで守る』『権限もテナント内に限定』．そして過剰な分離方式を最初から選ばない．

安全性は，開発者の注意力ではなく構造で守る．すべてのデータをテナントに属させ，絞り込みを既定動作にすれば，共有方式でも安全なSaaSが個人でも作れる．公開前の越境テストを忘れずに．

テナント設計が固まったら，その土台となるデータベースそのものを深掘りする番だ．次回は，スキーマ設計・マイグレーション・バックアップを扱う『データベース設計の実践』を解説する．