← エピソード一覧に戻る Episode 161 Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
0:00 / 0:00
スクリプト
Chapter 1 オープニング ― 共有すれば安い、では終わらない
タカシ
皆さんこんにちは、タカシです。今日は SaaS 開発の最重要論点の一つ、マルチテナント設計です。同じ基盤に顧客を載せると効率は上がりますが、設計を誤ると障害も不信もまとめて増えます。
ミカ
ミカです。なんとなく共有したほうが SaaS っぽい、くらいの理解でした。でも実際は、原価率、セキュリティ説明、営業が取れる顧客層まで変わるんですね。思ったより経営テーマです。
タカシ
その通りです。マルチテナント設計は、どこまで共有し、どこから分けるかを決める仕事です。データベースの話に見えて、実は価格、導入条件、運用負荷、将来の拡張余地まで含んだ経営判断なんです。
ミカ
今日は、pool と silo の考え方、認証と分離の違い、そして大口顧客が来たときに設計がどう商談へ返ってくるか、このあたりを整理したいです。
Chapter 2 基本 ― pool と silo をどう使い分けるか
タカシ
AWS の SaaS アーキテクチャ資料では、共有環境の pool と、専用環境の silo を同じ SaaS 内で混在させるのは珍しくないと説明しています。標準顧客は共有、プレミアム顧客は専用、という設計ですね。
ミカ
なるほど。じゃあ答えは共有か専用かの二択ではなくて、顧客セグメントごとに分離レベルを変える発想なんですね。高単価顧客だけ専用に寄せるのは現実的です。
タカシ
ええ。ただし AWS は、専用環境でも顧客ごとの特注構成にしてはいけないと強調しています。同じコード、同じバージョン、同じ運用を守る。これを外すと、売るほど保守コストが膨らみます。
ミカ
専用環境を出した瞬間に、なんでも個別対応したくなる誘惑がありますよね。でもそれをやると、SaaS というより受託運用に近づいてしまうわけだ。
タカシ
まさにそこです。マルチテナント設計は効率化の話ではありますが、実態は例外をどこまで許すかの統治設計でもあります。営業条件まで含めて決めないと、技術だけでは守れません。
Chapter 3 落とし穴 ― 認証できても隔離できているとは限らない
ミカ
ここで気になるのが、ログインできてロールもあるなら十分では、という誤解です。ユーザー管理がちゃんとしていれば、他社データも防げそうに見えます。
タカシ
AWS はそこを明確に否定しています。認証や権限はセキュリティの一部ですが、テナント分離そのものではありません。認証済みでも、API や SQL が tenant context を持っていなければ越境アクセスは起こりえます。
ミカ
つまり、画面の権限設定だけで安心してはいけなくて、データベース、キャッシュ、ログ、バッチ処理まで同じ境界が貫かれている必要があるんですね。地味ですが重い話です。
タカシ
加えて Microsoft は、50 テナントを超える、あるいはそこまで伸ばす前提なら、スケール戦略と自動管理を先に持てと言っています。後から増築すると、隔離と運用の両方が崩れやすいからです。
ミカ
顧客が増えてから考える、では遅いんですね。特に B2B SaaS は、1 社ごとのデータ量や監査要求が違うので、最初の設計が後の粗利に響きそうです。
Chapter 4 具体例 ― 共有基盤のまま、商用要件に応える
タカシ
Google Cloud の BigQuery ガイドは、SaaS 事業者が数万テナントを扱う前提で、信頼性、隔離、コスト、地理要件を同時に見るべきだと述べています。そのうえで dataset-per-tenant という中間解を示しています。
ミカ
全部を顧客ごとに分けるわけでも、全部を完全共有にするわけでもないんですね。管理資源を増やしすぎず、でも横断分析や運用は回る。SaaS らしい折衷案です。
タカシ
Snowflake も象徴的です。2025 年 2 月時点で 13,300 社超の顧客、754 社の Forbes Global 2000 利用企業を抱えつつ、multi-cluster shared data architecture で高い同時実行性をうたい、地域展開でデータ主権にも応えています。
ミカ
共有基盤で伸ばしながら、必要な顧客にはリージョン選択や統制を足していくわけですね。最初から全部を専用にしなくても、商談の幅は後から広げられると。
タカシ
Figma の豪州向け local data hosting も同じです。NAB は顧客接点の 98% 超がモバイルとインターネットバンキングだと述べていますが、そういう規制産業ほど、機能だけでなくデータ所在地の説明責任が商談条件になります。
Chapter 5 クロージング ― 分離条件を経営ルールにする
ミカ
明日からやるなら、まず顧客を共有で十分な層と、分離が必要になる層に分けて、条件を文章にするのが良さそうです。専用環境、専用鍵、地域要件のどれが商談条件なのかを曖昧にしない、と。
タカシ
その上で、アプリ、DB、キャッシュ、ログ、分析基盤の五層で tenant context が通っているかを点検すること。マルチテナント設計は技術の美しさではなく、原価、信用、拡張性を守るための経営基盤です。
ミカ
共有か専用かを感覚で決めず、移行条件と例外禁止の原則まで決める。そこまでやって初めて、SaaS としてきれいに伸びるんですね。今回はここまでです。