世の中のSaaSにおけるマルチテナント（単一のシステム環境を複数の顧客で共有する仕組み）は、主に「データの隔離レベル」と「インフラの共有度合い」のバランスによって、大きく3つのアーキテクチャパターンに分類されます。

それぞれの構造、メリット・デメリットを整理して解説します。

1. マルチテナントの3つの基本構造（データ分離パターン）

① データベース共有型（プール型 / Pool）

単一のデータベース、単一のスキーマ（テーブル群）をすべてのテナントで共有する構造です。 現在画面でご覧になっているシステム構成定義書の「シングルDB / tenant_id隔離方式」がまさにこれに該当します。

• 仕組み: users や orders といった共通のテーブルに tenant_id（テナント識別子）カラムを持たせ、データを保存します。データを取得する際は、必ず WHERE tenant_id = ? という条件を付与して論理的に隔離します。
• メリット: インフラコストが最も安く抑えられます。また、データベースのアップデートやマイグレーション（テーブル構造の変更）が一度に全テナント分完了するため、運用が非常に楽です。
• デメリット: アプリケーションの実装ミス（WHERE 句の付け忘れ）があると、他テナントのデータが見えてしまう致命的なバグに繋がります。また、特定のテナントが高負荷をかけると他のテナントの動作も重くなる「Noisy Neighbor（うるさい隣人）問題」が発生しやすいです。

② スキーマ分離型（ブリッジ型 / Bridge）

データベースのインスタンス（サーバー）は1つですが、その内部でテナントごとに「スキーマ（独立したデータ空間）」を完全に分ける構造です。

• 仕組み: アプリケーションにリクエストが届いた際、接続するスキーマ（例：tenant_a_schema、tenant_b_schema）を動的に切り替えます。テーブル構造は同じですが、データは物理的に異なるエリアに保存されます。
• メリット: データベースの仕組み自体でデータが分離されるため、プログラムの書き忘れによるデータ混入リスクが大幅に下がります。
• デメリット: テナント数が増える（数千〜数万など）と、データベース内のスキーマ数が膨大になり、一斉マイグレーションの管理やパフォーマンスの維持が難しくなります。

③ データベース分離型（サイロ型 / Silo）

テナントごとに完全に独立したデータベース（場合によってはサーバーインスタンスやAWSアカウントごと）を個別に用意する構造です。

• 仕組み: テナントごとにインフラを丸ごと、またはデータベースを完全に隔離してデプロイします。
• メリット: 最高レベルのセキュリティと独立性。他テナントの負荷影響を絶対に受けず、テナントごとの個別カスタマイズや特定の国・地域へのデータ保存（データローカリティ要件）にも柔軟に対応できます。金融、医療、大企業（エンタープライズ）向けのSaaSで強く求められる傾向にあります。
• デメリット: インフラコストが跳ね上がります。また、テナントが増えるほど管理の手間が掛け算で増えるため、インフラの自動化（IaCなど）が必須になります。

2. アプリケーション層での「ガードレール」の敷き方

世の中のモダンなSaaSでは、低コストな「データベース共有型（プール型）」を採用しつつ、デメリットである「実装ミスによるデータ漏洩」を防ぐためのガードレールをシステム的に敷いています。

• テナントの識別（Tenant Resolution）: URLのサブドメイン（clientA.saas.com）や、ログイン時のJWT（認証トークン）から、リクエストが誰のものかをミドルウェアで一網打尽に特定します。
• グローバルスコープの自動適用: 開発者がいちいち WHERE tenant_id = ... と書かなくても、フレームワークの機能（LaravelのTraitや、PostgreSQLの行レベルセキュリテイ（RLS）など）を使って、データベースへのクエリに自動でテナント制限を強制適用させます（画面の定義書にある「TenantScoped Trait」がまさにこのアプローチです）。

3. 最近のトレンド：ハイブリッド型とセルベース

最近の大規模なSaaSでは、これらを組み合わせた「ハイブリッド型」が多く見られます。

• プランによる切り替え: 無料プランや一般プランの顧客は「プール型」で高密度・低コストに収容し、高額な月額費用を払うエンタープライズ顧客だけを「サイロ型（専用DB）」に隔離して提供するビジネスモデル連動型。
• セルベースアーキテクチャ: テナントが数万規模になった際、1000テナントごとにインフラの塊（セル）を小分けにし、万が一障害が起きても影響をそのセル内（全体の1%など）だけに留める設計。

私たちがプロジェクトで選択した方法は、超短期MVPを見据えて「最もコスト効率が良くスピードが出るプール型」を選択しつつ、AI生成や将来の拡張に耐えられるよう「Traitによる自動隔離」という強固なガードレールを最初に組まれている点が非常に戦略的だと言えます。