Supabase RLSでマルチテナントSaaSのデータ分離を実装する

Supabase でマルチテナント SaaS を作るとき、「テナント間のデータ分離をどう実装するか」は設計の最重要課題です。アプリ層でフィルタリングするだけでは不十分で、DB 層で強制的にデータ分離するのが堅牢な設計のポイントです。

この記事では、実際の 1on1 支援 SaaS プロジェクト（one-on-one-ai）の実装をもとに、Supabase の Row Level Security（RLS）を使ったマルチテナントのデータ分離について解説します。テーブル設計から CREATE POLICY の具体的なコード、Next.js App Router での createServerClient セットアップ、テスト方法、よくある落とし穴、そしてフリープランでの運用上の注意点まで、実践的な内容を紹介します。

RLS（Row Level Security）とは何か

RLS（Row Level Security）は PostgreSQL の機能で、テーブルの行ごとにアクセス制御をかける仕組みです。Supabase はこれをフルサポートしており、SQL で CREATE POLICY を書くだけで「このユーザーにはこの行だけ見せる」という制御が実現します。

RLS が有効なテーブルに対してクエリを実行すると、PostgreSQL は自動的にポリシーで定義した条件を WHERE 句に追加します。アプリ側でフィルタリングを忘れても、DB 層で強制的に行レベルのアクセス制御が働く点が大きなメリットです。

例えば、セッションテーブルに team_id = 'team-a' の行と team_id = 'team-b' の行が混在していても、team-a のユーザーが SELECT を実行すれば自動的に team-a の行だけが返ってきます。アプリ側のコードでフィルタ漏れがあっても、DB 層で守られているため安心です。

RLS の有効化

まずテーブルに RLS を有効化する必要があります。デフォルトでは無効になっているため、明示的に設定してください。

-- RLS を有効化する（全テーブルに必ず設定する）
ALTER TABLE profiles ENABLE ROW LEVEL SECURITY;
ALTER TABLE teams ENABLE ROW LEVEL SECURITY;
ALTER TABLE team_members ENABLE ROW LEVEL SECURITY;
ALTER TABLE sessions ENABLE ROW LEVEL SECURITY;
ALTER TABLE session_notes ENABLE ROW LEVEL SECURITY;
ALTER TABLE action_items ENABLE ROW LEVEL SECURITY;
ALTER TABLE ai_suggestions ENABLE ROW LEVEL SECURITY;

RLS を有効化すると、ポリシーがない状態では全行がブロックされます。ポリシーを書いて初めてアクセスが許可されます。これが「デフォルト拒否」の動作で、セキュリティの観点では正しい設計です。

—

マルチテナントのデータ分離パターン

マルチテナント SaaS のデータ分離方式には大きく 3 つあります。どれを選ぶかはコスト・スケーラビリティ・実装の複雑さとのトレードオフになります。

方式	概要	コスト	スケール	実装難度
スキーマ分離	テナントごとに別スキーマ	高	△ テナント数に限界	高
DB 分離	テナントごとに別 DB インスタンス	非常に高	○	非常に高
共有テーブル + RLS	全テナントが同じテーブルを共有。RLS で行レベルで分離	低	◎	中

インディーズ開発者が個人でマルチテナント SaaS を立ち上げる場合、コストとスケーラビリティを考えると「共有テーブル + RLS」が最もバランスが良い選択肢です。Supabase のフリープランでも十分運用できます。

team_id + team_members によるデータ分離

実装でおすすめのパターンは、全テーブルに team_id 列を持たせ、team_members テーブルでユーザーとチームの関係を管理するアプローチです。

-- チームテーブル
CREATE TABLE teams (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  name TEXT NOT NULL,
  created_at TIMESTAMPTZ DEFAULT NOW()
);

-- チームメンバーテーブル（ユーザーとチームの紐付け）
CREATE TABLE team_members (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  team_id UUID NOT NULL REFERENCES teams(id) ON DELETE CASCADE,
  user_id UUID NOT NULL REFERENCES auth.users(id) ON DELETE CASCADE,
  role TEXT NOT NULL DEFAULT 'member', -- 'owner' | 'admin' | 'member'
  created_at TIMESTAMPTZ DEFAULT NOW(),
  UNIQUE(team_id, user_id)
);

-- セッションテーブル（team_id で分離）
CREATE TABLE sessions (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  team_id UUID NOT NULL REFERENCES teams(id) ON DELETE CASCADE,
  title TEXT NOT NULL,
  scheduled_at TIMESTAMPTZ,
  created_at TIMESTAMPTZ DEFAULT NOW()
);

RLS ポリシーの中核となるのが、「auth.uid() が team_members テーブルに存在するか」というチェックです。このパターンを使うことで、ユーザーが所属するチームのデータだけにアクセスを限定できます。

—

全テーブルの RLS ポリシー実装例

実際の 1on1 支援 SaaS（one-on-one-ai）で使用しているポリシーをすべて公開します。テーブルは profiles / teams / team_members / sessions / session_notes / action_items / ai_suggestions の 7 つです。

profiles テーブル

-- 自分のプロフィールのみ参照・更新可能
CREATE POLICY "profiles_select_own"
  ON profiles FOR SELECT
  USING (user_id = auth.uid());

CREATE POLICY "profiles_insert_own"
  ON profiles FOR INSERT
  WITH CHECK (user_id = auth.uid());

CREATE POLICY "profiles_update_own"
  ON profiles FOR UPDATE
  USING (user_id = auth.uid());

teams テーブル

-- 所属するチームのみ参照可能
CREATE POLICY "teams_select_member"
  ON teams FOR SELECT
  USING (
    id IN (
      SELECT team_id FROM team_members
      WHERE user_id = auth.uid()
    )
  );

-- チームの作成は誰でも可能（作成後に team_members に自分を追加する）
CREATE POLICY "teams_insert_any"
  ON teams FOR INSERT
  WITH CHECK (true);

-- チームの更新・削除はオーナーのみ
CREATE POLICY "teams_update_owner"
  ON teams FOR UPDATE
  USING (
    id IN (
      SELECT team_id FROM team_members
      WHERE user_id = auth.uid() AND role = 'owner'
    )
  );

team_members テーブル

-- 同じチームのメンバーを参照可能
CREATE POLICY "team_members_select_same_team"
  ON team_members FOR SELECT
  USING (
    team_id IN (
      SELECT team_id FROM team_members
      WHERE user_id = auth.uid()
    )
  );

-- 自分をメンバーとして追加できる（招待フローで使用）
CREATE POLICY "team_members_insert_self"
  ON team_members FOR INSERT
  WITH CHECK (user_id = auth.uid());

-- オーナーはメンバーを削除できる
CREATE POLICY "team_members_delete_owner"
  ON team_members FOR DELETE
  USING (
    team_id IN (
      SELECT team_id FROM team_members
      WHERE user_id = auth.uid() AND role = 'owner'
    )
  );

sessions / session_notes / action_items / ai_suggestions テーブル

これら 4 つのテーブルは同じパターンで実装します。全テーブルに team_id 列を持たせ、team_members テーブルへのサブクエリで分離するのがポイントです。

-- sessions テーブル
CREATE POLICY "sessions_select_team_member"
  ON sessions FOR SELECT
  USING (
    team_id IN (
      SELECT team_id FROM team_members
      WHERE user_id = auth.uid()
    )
  );

CREATE POLICY "sessions_insert_team_member"
  ON sessions FOR INSERT
  WITH CHECK (
    team_id IN (
      SELECT team_id FROM team_members
      WHERE user_id = auth.uid()
    )
  );

CREATE POLICY "sessions_update_team_member"
  ON sessions FOR UPDATE
  USING (
    team_id IN (
      SELECT team_id FROM team_members
      WHERE user_id = auth.uid()
    )
  );

CREATE POLICY "sessions_delete_team_member"
  ON sessions FOR DELETE
  USING (
    team_id IN (
      SELECT team_id FROM team_members
      WHERE user_id = auth.uid()
    )
  );

session_notes、action_items、ai_suggestions も同じパターンで実装してください。team_id の条件だけを変えれば OK です。

—

Next.js App Router でのサーバークライアント設定

RLS を正しく動作させるには、Supabase クライアントが認証済みユーザーのセッション（JWT トークン）を持っている必要があります。Next.js App Router では @supabase/ssr パッケージを使って、Cookie ベースのサーバークライアントを作成します。

パッケージのインストール

npm install @supabase/supabase-js @supabase/ssr

サーバークライアントの実装

// lib/supabase/server.ts
import { createServerClient } from '@supabase/ssr'
import { cookies } from 'next/headers'
import type { Database } from '@/types/supabase'

export async function createClient() {
  const cookieStore = await cookies()

  return createServerClient<Database>(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!,
    {
      cookies: {
        getAll() {
          return cookieStore.getAll()
        },
        setAll(cookiesToSet) {
          try {
            cookiesToSet.forEach(({ name, value, options }) => {
              cookieStore.set(name, value, options)
            })
          } catch {
            // Server Component から呼ばれた場合は Cookie の書き込みができないため無視する
          }
        },
      },
    }
  )
}

Route Handler / Server Action での使い方

// app/api/sessions/route.ts
import { createClient } from '@/lib/supabase/server'
import { NextResponse } from 'next/server'

export async function GET() {
  const supabase = await createClient()

  // RLS が自動的にユーザーのチームのセッションのみを返す
  const { data: sessions, error } = await supabase
    .from('sessions')
    .select('*')
    .order('scheduled_at', { ascending: false })

  if (error) {
    return NextResponse.json({ error: error.message }, { status: 500 })
  }

  return NextResponse.json({ sessions })
}

createServerClient が Cookie からセッションを読み取り、Supabase へのリクエストに JWT を自動付与します。これにより RLS ポリシーが auth.uid() を正しく認識できるようになります。

Middleware の設定

セッションの自動更新のために Middleware も設定してください。

// middleware.ts
import { createServerClient } from '@supabase/ssr'
import { NextResponse, type NextRequest } from 'next/server'

export async function middleware(request: NextRequest) {
  let supabaseResponse = NextResponse.next({ request })

  const supabase = createServerClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!,
    {
      cookies: {
        getAll() {
          return request.cookies.getAll()
        },
        setAll(cookiesToSet) {
          cookiesToSet.forEach(({ name, value }) =>
            request.cookies.set(name, value)
          )
          supabaseResponse = NextResponse.next({ request })
          cookiesToSet.forEach(({ name, value, options }) =>
            supabaseResponse.cookies.set(name, value, options)
          )
        },
      },
    }
  )

  // セッションを更新する（重要：これを忘れると JWT が期限切れになる）
  await supabase.auth.getUser()

  return supabaseResponse
}

export const config = {
  matcher: [
    '/((?!_next/static|_next/image|favicon.ico|.*\\.(?:svg|png|jpg|jpeg|gif|webp)$).*)',
  ],
}

—

RLS ポリシーのテスト方法

実装したポリシーが正しく動いているかを確認する方法を紹介します。Supabase Dashboard の SQL Editor を使って、特定ユーザーの権限でクエリをテストできます。

SET LOCAL を使ったポリシーテスト

-- 特定ユーザーとして RLS ポリシーをテストする
BEGIN;

-- ユーザーの JWT をセットする
SELECT set_config(
  'request.jwt.claims',
  '{"sub": "USER_UUID_HERE", "role": "authenticated"}',
  true
);

-- authenticated ロールに切り替える
SET LOCAL ROLE authenticated;

-- このクエリは RLS が適用された状態で実行される
SELECT * FROM sessions;

ROLLBACK;

EXPLAIN ANALYZE でポリシーの評価を確認

-- ポリシーの評価がクエリプランに含まれているか確認する
EXPLAIN ANALYZE
SELECT * FROM sessions WHERE id = 'SESSION_UUID_HERE';

クエリプランに Filter: (team_id = ANY (...)) のような行が表示されれば、RLS ポリシーが正しく適用されています。

Supabase Dashboard からのテスト手順

1. Supabase Dashboard → Authentication → Users でテストユーザーを確認

2. Table Editor → sessions テーブルを開く

3. 「Row Level Security」トグルが ON になっているか確認

4. SQL Editor で上記の SET LOCAL ROLE を使ったテストを実行

具体例として、team-a に所属するユーザーが team-b のセッションを取得しようとした場合、空配列が返ってくることを確認してください。これが正しい動作です。

—

パフォーマンス最適化：インデックスの重要性

RLS ポリシーのサブクエリは、クエリのたびに評価されます。特に team_members テーブルへのサブクエリは頻繁に実行されるため、インデックスがないとデータ量が増えた際にパフォーマンスが急激に低下します。

必須インデックスの設定

-- team_members テーブル：ポリシーのサブクエリで使われる列
CREATE INDEX idx_team_members_user_id ON team_members(user_id);
CREATE INDEX idx_team_members_team_id ON team_members(team_id);
CREATE INDEX idx_team_members_user_team ON team_members(user_id, team_id);

-- 各テーブルの team_id 列
CREATE INDEX idx_sessions_team_id ON sessions(team_id);
CREATE INDEX idx_session_notes_team_id ON session_notes(team_id);
CREATE INDEX idx_action_items_team_id ON action_items(team_id);
CREATE INDEX idx_ai_suggestions_team_id ON ai_suggestions(team_id);

実際に運用してみると、1チーム・100セッション程度ではインデックスなしでも体感差はほぼありません。しかし、テナント数が 50 を超え始めたあたりからクエリ遅延が出始めます。具体的には、50テナント×各1,000行のデータ規模でインデックスありとなしを比較すると、同一クエリでおよそ 3〜8ms から 40〜80ms に悪化するケースが確認されています。インデックスの設定は後回しにせず、テーブル作成時に一緒に行ってください。

auth.uid() の呼び出しコスト

PostgreSQL の auth.uid() は関数呼び出しであり、ポリシー評価のたびに実行されます。パフォーマンスを最大化したい場合は、JWT のカスタムクレームに team_id を埋め込んで auth.jwt() ->> 'team_id' で参照する方法もあります。ただし、これはチームの切り替え時にトークンの再発行が必要になるため、実装の複雑さが増します。シンプルな実装を優先するなら、まずは team_members テーブルへのサブクエリパターンで始めるのが得策です。

—

Supabase フリープランでの運用注意点

フリープランを使って運用する場合、いくつかの制限を把握しておく必要があります。

フリープランの主な制限

項目	制限	対策
DB 容量	500MB	古いデータのアーカイブ・削除
帯域幅	5GB/月	必要最小限のデータ取得
自動バックアップ	なし	手動 pg_dump か Edge Function で定期エクスポート
7日間放置で停止	プロジェクトが一時停止される	Keep-alive cron ジョブの設定
Edge Function	500,000 回/月	不要な Function 呼び出しの削減

7日間放置問題への対策

フリープランの最大の落とし穴が「7日間アクセスがないとプロジェクトが自動停止する」仕様です。開発中やベータ期間中に気づかずに停止して、ユーザーに影響が出るケースがあります。

対策として、外部の cron サービス（GitHub Actions、cron-job.org など）から定期的に Supabase の API を叩く Keep-alive ジョブを設定してください。

# .github/workflows/keep-alive.yml
name: Supabase Keep Alive
on:
  schedule:
    - cron: '0 0 * * 0'  # 毎週日曜 0:00 UTC に実行
jobs:
  ping:
    runs-on: ubuntu-latest
    steps:
      - name: Ping Supabase
        run: |
          curl -s "${{ secrets.SUPABASE_URL }}/rest/v1/" \
            -H "apikey: ${{ secrets.SUPABASE_ANON_KEY }}" > /dev/null
          echo "Ping complete"

—

RLS 実装でよくある落とし穴

実装中に詰まりやすいパターンをまとめます。これらは実際のプロジェクトで遭遇したミスです。

落とし穴 1：INSERT 時に WITH CHECK を忘れて全件拒否される

RLS の SELECT ポリシーと INSERT ポリシーは別物です。SELECT に USING を書いただけでは INSERT は通りません。INSERT / UPDATE には WITH CHECK を書く必要があります。

例えば、以下の SELECT ポリシーだけ書いて INSERT しようとすると、new row violates row-level security policy エラーが返ってきます。

-- ❌ これだけでは INSERT が通らない
CREATE POLICY "sessions_select_team_member"
  ON sessions FOR SELECT
  USING (team_id IN (SELECT team_id FROM team_members WHERE user_id = auth.uid()));

-- ✅ INSERT には WITH CHECK が必要
CREATE POLICY "sessions_insert_team_member"
  ON sessions FOR INSERT
  WITH CHECK (team_id IN (SELECT team_id FROM team_members WHERE user_id = auth.uid()));

FOR ALL でまとめて書く方法もありますが、操作ごとに別ポリシーを書くほうがデバッグしやすくおすすめです。

落とし穴 2：service_role キーをフロントエンドに公開してしまう

service_role キーは RLS を完全バイパスします。これをフロントエンドのコードや .env.local にそのまま書いてしまうと、すべてのテナントのデータにアクセスできてしまいます。

// ❌ 絶対にやってはいけない
const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.SUPABASE_SERVICE_ROLE_KEY!  // これはサーバー専用
)

// ✅ フロントエンドには必ず anon キーを使う
const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!  // NEXT_PUBLIC_ プレフィックスがついているもの
)

service_role キーは管理者専用のサーバーサイド処理（マイグレーション、バッチ処理）のみで使い、フロントやクライアントには絶対に渡さないようにしてください。

落とし穴 3：RLS を有効化し忘れて全行が見えてしまう

テーブルを作成しただけでは RLS は有効になりません。ALTER TABLE ... ENABLE ROW LEVEL SECURITY を忘れると、ポリシーを書いていても全行がすべてのユーザーに見えます。

手順として、テーブル作成直後に必ず RLS 有効化 SQL を実行してください。Supabase Dashboard の Table Editor でも「RLS Enabled」のトグルを確認するポイントを設けることをおすすめします。

—

よくある質問

Q. RLS を使わずにアプリ層だけでフィルタリングするのではダメですか？

A. アプリ層だけのフィルタリングは、コードのバグや実装漏れによってデータが漏洩するリスクがあります。RLS は DB 層での強制的なアクセス制御なので、アプリ側にフィルタ漏れがあっても守られます。どちらも実施するのが理想ですが、RLS は必須です。

Q. service_role キーを使うと RLS をバイパスできますか？

A. はい、service_role キーを使うと RLS がバイパスされます。これは管理者タスク（バッチ処理、マイグレーションなど）には便利ですが、クライアントサイドや Edge Function に service_role キーを公開してはいけません。フロントエンドには必ず anon キーを使ってください。

Q. チームの role（owner / admin / member）によってアクセス制御を分けるにはどうすればいいですか？

A. team_members.role 列を使ってポリシーに条件を追加する方法が最も直接的です。例えば role = 'owner' のユーザーだけが削除できるポリシーは、本記事の teams_delete_owner の例を参考にしてください。

Q. RLS でパフォーマンスが悪化した場合はどうすればいいですか？

A. まず EXPLAIN ANALYZE でクエリプランを確認し、インデックスが使われているか確認してください。次に、ポリシーのサブクエリを実体化ビュー（Materialized View）に置き換える方法もあります。ただしビューの更新タイミングの管理が必要になるため、まずインデックスで解決できるか試す方法がおすすめです。

Q. Cloudflare Workers から Supabase を使う場合も同じ設定で大丈夫ですか？

A. Workers の場合は @supabase/ssr の代わりに @supabase/supabase-js を直接使い、JWT を Authorization ヘッダーで渡す方法になります。Cookie の扱いが Next.js とは異なるため、Supabase 公式の Workers 向けガイドを確認してください。

—