マルチテナント vs マルチサイトアーキテクチャについて、数ヶ月間議論して誤った選択をしてから6ヶ月かけて移行し直すチームを見てきました。これは3スプリント進めるまで抽象的に思えるような決定の1つで、その時点でコンテンツエディターが誤ったブランドに公開してしまうか、変更があったのは1つなのに12のサイトを再ビルドしているために展開パイプラインに45分かかることに気付きます。

これは理論的な比較ではありません。両方のパターンを構築してきました — 時には最初の選択が上手くいかなかったときに同じクライアント向けに構築してきました。この判断を下す際に実際に重要なことについて、説明させてください。

目次

Multi-Tenant vs Multi-Site Architecture: How to Decide

用語の明確な定義

これらの用語は緩く使われているため、正確に定義しましょう。

マルチテナントアーキテクチャ

1つのアプリケーションインスタンスが複数のテナント（ブランド、クライアント、地域）にサービスを提供します。同じコードベース、通常は同じデータベース、同じデプロイメントを共有します。テナント分離はアプリケーション層で発生します — ミドルウェア、データベーススキーマ、または行レベルフィルタリングを通じて。

アパートビルのように考えてください。みんなが構造、配管、電気を共有します。しかし各ユニットは独自のロックを持っています。

マルチサイトアーキテクチャ

各サイトは独立したアプリケーションインスタンスで、独自のコードベース（または共有されたものをフォーク）、独自のデータベース、独自のデプロイメントパイプラインがあります。デザインシステムやコンポーネントライブラリを共有することもありますが、独立して展開および運用されます。

これは住宅開発のようなものです。同じビルダー、類似したブループリント、しかし各家は独自の基礎の上にあります。

ハイブリッドゾーン

正直に言うと、ほとんどの本番システムはその間のどこかに落ち着きます。マルチテナント CMS がコンテンツを独立して展開されたフロントエンドに供給しているかもしれません。または共有されたコードベースがテナントごとに別々のインスタンスとしてデプロイされているかもしれません。本当の質問は「どちらか」ではなく「スペクトルのどこか」です。

マルチテナントアーキテクチャが有利な場合

マルチテナントは、サイトが異なっているより類似している場合に活躍します。

強力なブランドの一貫性要件

同じブランドの15の地域サイトを管理していてデザインをロックダウンしておく必要がある場合、マルチテナントはあなたの友人です。1つのコードベースは1つの真実のソースをコンポーネント、レイアウト、インタラクションパターンに意味します。ブランドチームがボタンスタイルを更新するとき、それはどこでも展開されます。

新しいテナントへの迅速なスケーリング

新しい場所を毎週立ち上げる必要があるフランチャイズプラットフォームで働きました。マルチテナントでは、新しいサイトを追加することはデータベースエントリと DNS レコードでした。新しいインフラストラクチャなし、新しいデプロイメントなし。立ち上げ時間は2週間から約30分に短縮されました。

一元化されたコンテンツ操作

複数のプロパティを管理する小さなコンテンツチームがいる場合、マルチテナントはすべてを1つの場所に保ちます。エディターは1つのシステムにログインし、コンテキストを切り替え、すべてのテナント全体でコンテンツを管理します。ダースの CMS インスタンスの認証情報をジャグリングすることはありません。

共有機能開発

構築するすべての機能はすべてのテナントに同時に利益をもたらします。バグ修正、パフォーマンス向上、新しい統合 — 一度デプロイして、どこでも利益を得ます。開発努力の ROI は乗法的です。

マルチサイトアーキテクチャが有利な場合

マルチサイトは、サイトが大幅に異なる必要がある場合に勝ちます。

根本的に異なるユーザー体験

ブランド A がeコマース店舗でブランド B がコンテンツ出版である場合、それらを1つのコードベースに詰め込むと混乱が生じます。マルチテナントコードベースの60%がテナント固有の条件の背後にあったのを見てきました。その時点で、1つのアプリケーションを持っていません — リポジトリを共有する複数の悪いものを持っています。

異なるテクノロジー要件

1つのサイトは動的でアプリのような体験のために Next.js を必要とし、別のサイトはコンテンツが多いサイトで Astro に最適である可能性があります。マルチサイトでは各プロパティが正しいツールを使用できます。Next.js と Astro で実行されるサイトを持つポートフォリオを構築してきました。すべて 共有ヘッドレス CMS からプルしています。

独立したリリースサイクル

異なるビジネスユニットが異なるサイトを所有し、独自のスケジュールで配信する必要がある場合、マルチテナントはボトルネックを作成します。テナント A の新しい機能のデプロイは、テナント B からテナント Z への回帰テストを必要としません。マルチサイトは各チームに自律性を与えます。

規制またはデータ分離

一部の業界は厳密なデータ分離を必要とします — アプリケーション層の分離だけでなく、物理的に独立したデータベース、潜在的に異なる地域に配置されます。ヘルスケア、金融、政府プロジェクトはこれを要求することが多いです。マルチサイトは分離がアーキテクチャ的であるため、論理的ではないため、コンプライアンスを単純にします。

異なるパフォーマンスプロファイル

1つのテナントが月間1000万アクセスを得ていて別のテナントが50,000を得ている場合、インフラストラクチャを共有することは、小さいテナント用にオーバープロビジョニングするか大きいテナント用にアンダープロビジョニングするかを意味します。個別のデプロイメントでは各プロパティを適切なサイズに調整できます。

Multi-Tenant vs Multi-Site Architecture: How to Decide - architecture

決定フレームワーク

これは実際にクライアントと一緒に使用するフレームワークです。あなたの状況の各要因をスコアしてください：

要因 マルチテナントに有利 マルチサイトに有利
サイトの類似性 80%以上の共有 UI/機能 50%未満の共有
プロパティの数 10+サイト 5サイト未満
成長率 サイトを頻繁に追加 安定、めったに追加しない
チーム構造 1つの中央チーム サイトごとに独立したチーム
コンテンツモデル 同一またはほぼ同一 大きく異なる
コンプライアンスニーズ 標準要件 厳密なデータ分離
テックスタック どこでも同じフレームワーク 異なるフレームワークが必要
リリース頻度 調整されたリリース OK 独立したリリースが必要
カスタマイズの深さ テーマレベル（色、ロゴ） 構造的（レイアウト、機能）
予算 効率を最適化 柔軟性を最適化

1つの列で主にスコアしている場合、決定は明白です。真ん中で分かれている場合、おそらくハイブリッドアプローチを探しています — そしてそれで大丈夫です。

実践におけるアーキテクチャパターン

これらがコードでどのように見えるかについて具体的になりましょう。

Next.js を使用したマルチテナント

最も一般的に使用するパターンはミドルウェアベースのテナント解決です：

// middleware.ts
import { NextRequest, NextResponse } from 'next/server';

const TENANT_MAP: Record<string, string> = {
  'brand-a.com': 'brand-a',
  'brand-b.com': 'brand-b',
  'brand-c.com': 'brand-c',
};

export function middleware(request: NextRequest) {
  const hostname = request.headers.get('host') || '';
  const tenantId = TENANT_MAP[hostname] || 'default';
  
  // Pass tenant context via headers
  const response = NextResponse.next();
  response.headers.set('x-tenant-id', tenantId);
  
  // Rewrite to tenant-specific paths if needed
  const url = request.nextUrl.clone();
  url.pathname = `/${tenantId}${url.pathname}`;
  
  return NextResponse.rewrite(url);
}

その後、ページコンポーネントがテナント固有の設定をプルします：

// lib/tenant-config.ts
export async function getTenantConfig(tenantId: string) {
  // Could be from database, CMS, or config files
  return {
    theme: await fetchTheme(tenantId),
    navigation: await fetchNavigation(tenantId),
    features: await fetchFeatureFlags(tenantId),
    locale: await fetchLocaleConfig(tenantId),
  };
}

これはテナントが異なるページ構造、異なるデータ取得戦略、または異なるサードパーティ統合を必要とし始めるまでうまく機能します。それが条件付きロジックがクリープを開始します。

共有パッケージを使用したマルチサイト

マルチサイトの場合、共有パッケージを含むモノレポを使用します：

├── apps/
│   ├── brand-a/          # Next.js app
│   ├── brand-b/          # Astro app  
│   └── brand-c/          # Next.js app
├── packages/
│   ├── ui/               # Shared component library
│   ├── cms-client/       # Shared CMS integration
│   ├── analytics/        # Shared analytics wrapper
│   └── config/           # Shared TypeScript/ESLint config
├── turbo.json
└── package.json

// turbo.json
{
  "pipeline": {
    "build": {
      "dependsOn": ["^build"],
      "outputs": [".next/**", "dist/**"]
    },
    "deploy": {
      "dependsOn": ["build"]
    }
  }
}

Turborepo (または Nx) は依存グラフを処理し、変更されたものだけを再ビルドします。ブランド A が新しい機能を取得しますか？ブランド A のみが再ビルドしてデプロイされます。共有 UI パッケージが更新されますか？それに依存するすべてが再ビルドされます。

ハイブリッド：マルチテナント CMS、マルチサイトフロントエンド

正直なところ、これはほとんどのシナリオで私のお気に入りのパターンです。中央集約的なコンテンツ管理と独立したフロントエンドデプロイメントの両方を取得します：

┌─────────────────────┐
│   Headless CMS      │
│  (Sanity/Contentful)│
│   Multi-tenant      │
│   content spaces    │
└──────┬──────┬───────┘
       │      │
   ┌───┘      └───┐
   ▼              ▼
┌──────┐    ┌──────┐
│Site A│    │Site B│
│Next.js│   │Astro │
└──────┘    └──────┘

コンテンツエディターはログインを1つ取得し、すべてのプロパティを管理できます。開発者は独立したコードベースとデプロイメントパイプラインを取得します。予算がある場合、両方の世界を最良に活用します。

CMS に関する考慮事項

CMS の選択は、アーキテクチャの決定を大幅に制限またはそれを有効にします。

マルチテナント CMS サポート

CMS マルチテナントモデル マルチサイトサポート 価格への影響
Sanity テナントごとのデータセット 優秀（1つのプロジェクト内の複数のデータセット） 無料ティア：2つのデータセット；有料は$99/月から
Contentful テナントごとのスペース 良好（組織レベルの管理） 各スペースはプランにカウント；$300以上/月
Strapi 単一 DB、テナント別に フィルタリング 手動実装が必要 自己ホスト、インフラストラクチャでスケール
Hygraph 環境とステージ ネイティブマルチサイトコンテンツフェデレーション チームプランから$199/月
WordPress (headless) WordPress マルチサイト 成熟しているが複雑 ホスティングコストはサイトごとにスケール
Payload CMS コレクションレベルのマルチテナント 成長中のサポート(v3.0+) 自己ホスト、オープンソース

Sanity のデータセットモデルはマルチテナント設定に特に優れています。各テナントは独自のスキーマを持つ独自のデータセットを取得しますが、1つのプロジェクトの下に存在します。スキーマ定義をデータセット全体で共有しながら、テナント固有のカスタマイズを許可できます。規模では(10+テナント)、これはコンテンツ操作を理にかなったものに保ちます。

Contentful のスペースの分離のアプローチは機能しますが、急速に高額になります。チームプランの各スペースは実際のお金がかかり、スペースの追加を開始する前に最低$300/月を見ています。

コンテンツモデルへの影響

マルチテナントでは、コンテンツモデルはすべてのテナントに対応する必要があります。これは通常以下を意味します：

  • すべてのコンテンツタイプの tenant または brand フィールド
  • テナント固有の検証ルール
  • エディターが自分のテナントのコンテンツのみを表示するように慎重な権限モデリング
  • テナント スコーピングが必要な共有コンテンツタイプ（「グローバル設定」など）

マルチサイトでは、各サイトは独自のコンテンツモデルを持っています。サイトごとには簡単ですが、追加のコンテンツシンジケーション層なしに、サイト全体でコンテンツを共有する機能を失います。

パフォーマンスとスケーリング

マルチテナントパフォーマンス特性

マルチテナントの最大のリスクは「うるさい隣人」問題です。テナント A がバイラルキャンペーンを実行してトラフィックが10倍にスパイクすると、すべてのテナントがそれを感じます。緩和戦略：

  • テナントごとのエッジキャッシング：Vercel または Cloudflare のエッジネットワークを使用してキャッシュキーにテナント識別子を含める
  • テナント対応 ISR の再検証：コンテンツが変更されたテナントのページのみを再検証
  • テナントごとのレート制限：共有リソースを任意の単一テナントでの圧倒から保護
// next.config.js - テナント対応の再検証を使用した ISR
export async function generateStaticParams() {
  const tenants = await getAllTenants();
  const paths = [];
  
  for (const tenant of tenants) {
    const pages = await getTenantPages(tenant.id);
    paths.push(...pages.map(page => ({
      tenant: tenant.slug,
      slug: page.slug,
    })));
  }
  
  return paths;
}

マルチサイトパフォーマンス特性

各サイトは独立してスケールします。それが良いニュースです。悪いニュースは、N個のデプロイメントパイプライン、N個の監視ダッシュボード、N個のパフォーマンスバジェットセットを管理していることです。20+サイトでは、アプリケーションパフォーマンスではなく、運用オーバーヘッドがボトルネックになります。

2025年に実行したベンチマークから、Vercel で期待するものは大まかに以下の通りです：

メトリック マルチテナント（1つのアプリ、10テナント） マルチサイト（10アプリ）
コールドスタート（エッジ） 20-50ms サイトごとに 20-50ms
ビルド時間 8-15 分（すべてのテナント） サイトごとに 2-4 分
インクリメンタルビルド 30-90 秒 サイトごとに 30-90 秒
インスタンスあたりのメモリ 256-512MB 共有 各256-512MB
月額 Vercel コスト（プロ） 〜$20 〜$200（$20 × 10）

そのコストの違いは重要です。$20/月で Vercel Pro の単一プランでマルチテナント対 Enterprise を必要とするマルチサイトまたはクリエイティブなプロジェクト組織。

コスト分析

12ヶ月間で10サイトのポートフォリオについて実数を見てみましょう。

マルチテナントコスト見積

項目 月額コスト 年間コスト
Vercel Pro（1つのプロジェクト） $20 $240
Sanity Team（1つのプロジェクト、10データセット） $99 $1,188
開発（初期ビルド） -- $40,000-60,000
メンテナンス（進行中） $2,000 $24,000
合計 1年目 -- $65,428-$85,428

マルチサイトコスト見積

項目 月額コスト 年間コスト
Vercel Pro（10プロジェクト） $200 $2,400
Sanity Team（10プロジェクト） $990 $11,880
開発（初期ビルド、共有パッケージ） -- $50,000-80,000
メンテナンス（進行中、10サイト） $4,000 $48,000
合計 1年目 -- $112,280-$142,280

マルチテナントはおよそ40-60%安く、主に軽減されたメンテナンス負担によるものです。しかし、マルチテナント複雑さがより多くのバグ、より遅い機能開発、または後で苦痛な移行につながる場合、これらの数字は反転します。

あなたの特定の状況のより正確な見積もりが必要ですか？発見プロセス中に詳細にアーキテクチャコストを分解します。

移行戦略

時々あなたは1つのアプローチで始まり、切り替える必要があります。すべてを燃やすことなくそれをする方法です。

マルチテナント → マルチサイト

これはより一般的な移行方向です。それが必要な兆候：

  • テナント固有のコードはコードベースの30%を超える
  • デプロイメントはクロステナント回帰テストによってブロックされている
  • チームが互いの変更を踏んでいる

戦略：

  1. 最初に共有コードをパッケージに抽出（UI コンポーネント、ユーティリティ、CMS クライアント）
  2. 既存のアプリの周りにモノレポ構造を作成
  3. 最も分散したテナント用にアプリをフォーク
  4. 他のテナントを徐々に独自のアプリに移動
  5. テナント切り替えロジックを各アプリから削除すると、スタンドアロンになります

マルチサイト → マルチテナント

より一般的ではありませんが、それは起こります。通常、企業が複数のブランドを買収し、操作を統合したいときです。

  1. 共有パターンのすべてのサイト（期待以上を見つけるでしょう）を監査
  2. 最高の実装から共有コンポーネントライブラリを構築
  3. 最も単純なサイトで始まるマルチテナントアプリを作成
  4. サイトを1つずつ移行し、各ステップでパリティを検証
  5. テナントがライブになると、個別のアプリを廃止

どちらの移行も破壊的です。3-6ヶ月と重要なテスト努力を予算に含めてください。これはまさに最初の決定を正しくすることが重要な理由です — それはアーキテクチャの選択ではなく、コミットメントです。

この決定に直面していて、それを以前に行った人と話したい場合は、お問い合わせください。

FAQ

マルチテナントアーキテクチャとマルチサイトアーキテクチャの違いは何ですか？

マルチテナントは、単一のアプリケーションインスタンスを使用して複数のブランドまたはクライアントにサービスを提供し、テナント分離がアプリケーション層で処理されます。マルチサイトは、各サイトに独立したアプリケーションインスタンスをデプロイし、モノレポとコンポーネントライブラリを通じてコードを共有する可能性があります。重要な違いは、1つのアプリケーションを実行しているのか複数のアプリケーションを実行しているのかです。

マルチテナント CMS をマルチサイトフロントエンドで使用できますか？

絶対に、そしてしばしば最良のアプローチです。複数のデータセットを持つ Sanity のようなヘッドレス CMS により、一元化されたコンテンツ管理が提供され、独立したフロントエンドデプロイメントは各サイトにテクノロジーの選択肢、デプロイメントスケジュール、パフォーマンススケーリングの独立性を提供します。このハイブリッドパターンは、サイトがコンテンツ構造を共有しているが異なるユーザー体験が必要な場合に特に機能します。

マルチテナントアーキテクチャは SEO にどのように影響しますか？

マルチテナントアプリはドメインまたはサブドメインに基づいて異なるコンテンツを提供します。これは適切な正規 URL、テナントごとの一意のメタデータ、および個別のサイトマップを実装している限り、検索エンジンが問題なく処理します。リスクはテナント全体のコンテンツ重複の事故です — サイトマップ生成とrobots.txt がテナント対応であることを確認してください。SEO の観点から、検索エンジンはサイトがコードベースを共有しているかどうかを気にしません。彼らが受け取るコンテンツとマークアップを気にします。

マルチテナントはマルチサイトより安いですか？

一般的にはい。ホスティングとメンテナンスコストで40-60%安い傾向があります。1つのデプロイメント、1つの監視設定、1つのインフラストラクチャセットの支払いをしています。ただし、テナントが大幅に異なる場合、マルチテナントはより開発時間がかかる可能性があります。複雑なテナント固有のロジック管理は非線形で増加するためです。損益分岐点はサイトが実際にどれだけ似ているかに依存します。

ヘッドレス WordPress マルチサイトに最適なアプローチは何ですか？

WordPress マルチサイトは本質的にマルチテナントです — 1つの WordPress インストール、複数のサイト。WordPress をヘッドレス CMS として使用している場合、マルチサイトネットワークは一元化されたコンテンツ管理を提供します。フロントエンドはマルチテナント（1つの Next.js アプリ）またはマルチサイト（WordPress サイトごとの個別アプリ）のどちらかです。ほとんどの WordPress ベースのプロジェクトの場合、ハイブリッドをお勧めします：CMS としての WordPress マルチサイト、サイトごとの個別フロントエンドデプロイメント。

マルチテナントアプリ全体で共有認証を処理する方法は？

テナント対応セッション管理を備えた一元化された認証プロバイダー（Auth0、Clerk、または NextAuth.js）を使用します。認証トークンにはテナントコンテキストを含める必要があり、ミドルウェアは認証されたユーザーが要求されたテナントにアクセスできることを検証する必要があります。Supabase と Neon の両方がサポートしているデータベースの行レベルセキュリティにより、テナント間データリークに対する保護の2番目のレイヤーが追加されます。

マルチテナントアプリが処理できるテナントの最大数は何ですか？

ハード制限はありませんが、実際的な制限がビルド時間と運用複雑さの周りに現れます。Vercel での Next.js ISR では、50+テナントを効果的に処理するマルチテナントアプリを見てきました。100テナントを超えると、事前生成ではなくオンデマンド ISR を探したくなります。洗練されたキャッシング戦略が必要になります。Shopify のような SaaS プラットフォームは事実上、何千ものテナントを実行しますが、そのインフラストラクチャに数年投資しています。

マルチサイトアーキテクチャにはモノレポを使用する必要がありますか？

ほぼ常にはい。Turborepo または Nx を備えたモノレポは、マルチテナント（共有コンポーネント、ユーティリティ、構成）の利点をマルチサイト（デプロイメント独立）の利点で提供します。重要なことは、共有パッケージをよく定義し、バージョン管理することです。モノレポがなければ、リポジトリ間でコピーされたコードで終わり、すぐに分散し、数ヶ月以内にメンテナンスの悪夢になります。