本文へスキップ

SupabaseはGDPR準拠? データの実際の所在地

Markdownで表示Claudeで開くChatGPTで開くPerplexityで開く

質問もコピーされます。チャットが空で開いた場合は貼り付けてください。

TL;DR

Supabaseは、GDPRに準拠したアプリを作れるようにし、Data Processing Agreement(DPA)も用意していますが、アプリを準拠させてくれるわけではありません。選んだリージョンに置かれるのは、Postgresデータベース、Auth、Storageのファイル、バックアップです。リージョンの外で動くものは4つあります。StorageのCDNキャッシュ、固定しないEdge Functions、プラットフォームのログ、サポートのアクセスです。EUが必要なら、アイルランド、パリ、フランクフルト、ストックホルムを選んでください。汎用の「Europe」は、ロンドンやチューリッヒになることもあります。リージョンは後から変更できません。移すには新しいプロジェクトを作って移行します。Lovable Cloudも同じ仕組みで、選ばなければ、あなたに最も近いリージョンが選ばれます。

Denysです。フルスタック・AIエンジニアで、私が作る、あるいは直すアプリのほとんどはSupabaseで動いています。ヨーロッパのクライアントは、まず2つのことを聞きます。SupabaseはGDPRに準拠していますか、そしてデータはどこにありますか。この記事は、2026年10月29日に読んだSupabaseとLovable自身のドキュメントに基づいて両方に答え、プロジェクトの確認に使うコマンドも紹介します。

SupabaseはGDPRに準拠している?

SupabaseのGDPRガイドは、これを責任共有として説明しています。Supabaseはインフラを守り、アプリのデータ処理、同意フロー、アクセス制御についてはあなたが責任を負います。GDPRの用語では、保存するデータについてSupabaseはあなたの処理者で、それを定めた契約がData Processing Addendumです。同じ文書は、1つの区分についてはSupabaseを管理者としています。プラットフォームの運営のために収集する利用データです。

このDPAで実務上重要なのは2点です。

  • リージョン。 あるリージョンでデータを処理するようSupabaseに指示すると、法律、あなた自身の指示、依頼したサービスが別の扱いを必要としない限り、データはそこで保存され、主にそこで処理されます。
  • 復処理者。 Supabaseの復処理者リストを、あなたは事前に承認します。変更の30日前にSupabaseから通知があり、同じページでその変更を購読できます。リストには、ホスティングのAWSとCloudflare、サポート、エラー監視、アカウントユーザーへのメッセージ送信のサービス事業者が含まれます。

Supabaseはデータをどこに保存する?

データ所在地のFAQとリージョンのページでは、次のように分かれます。

プロジェクトの部位 処理される場所
Postgresデータベースとバックアップ 選んだAWSリージョン
Auth(ユーザー、セッション) 選んだリージョン
オリジンのStorageファイル 選んだリージョン
StorageのCDNキャッシュ グローバル。Cloudflareにキャッシュされる
Edge Functions リージョンに固定しない限り、呼び出し元に最も近いエッジ
プラットフォームのログとテレメトリ リージョンの外。ログはEUのデータセンターに保存
サポートのアクセス 支援を求めたとき、またはセキュリティインシデントの際のグローバルなサポートチーム。記録される
アカウントと請求のデータ Supabaseの中央システム。ここではSupabaseが管理者
Supabaseプロジェクトの各部位はどこで処理される?。リージョン=プロジェクト作成時に選ぶAWSリージョン。DB、Auth、バックアップ:Postgres、Auth → 選んだリージョン、Storageファイル:ファイル → 選んだリージョン → CDNキャッシュ(全世界)、Edge Functions(未固定):関数の呼び出し → 最寄りのエッジ、プラットフォームのログ:ログ、テレメトリ → EUのデータセンター。
図1. Supabaseのデータ所在地FAQとリージョンのページ。2026年10月29日確認。

FAQは、率直な問いにそのまま答えています。Supabaseは、データがリージョンの外に出ないことを保証しません。データベースとバックアップは留まりますが、表の下の4つの区分は外に出ることがあります。

EUにあるSupabaseのリージョンは?

EU域内にある具体的なリージョンは4つです。West EU(アイルランド)eu-west-1、West EU(パリ)eu-west-3、Central EU(フランクフルト)eu-central-1、North EU(ストックホルム)eu-north-1です。ロンドンeu-west-2とチューリッヒeu-central-2はヨーロッパにありGDPRの十分性認定を受けていますが、EU加盟国ではありません。

この違いは、プロジェクトを作るときに重要です。汎用の「Europe」を選ぶと、Supabaseが空き状況に応じてヨーロッパのリージョンを選びます。リージョンのガイドは、ロンドンやチューリッヒになりうると警告しています。契約や顧客が「データはEUに留まる」と言っているなら、EUの具体的なリージョンを選んでください。リージョン指定のEdge Functionsを使う場合のもう1点として、リージョンのページによると、関数をリージョンに固定する機能はオハイオとストックホルムでは使えません。

プロジェクトのリージョンをどう確認する?

ダッシュボードでは、リージョンはプロジェクトの設定に表示されます。ターミナルからは、Supabase CLIがアクセスできるすべてのプロジェクトをリージョンとともに一覧にします。

supabase projects list
supabase projects list -o json   # each project has a "region" field, e.g. "eu-west-1"

自分のアカウントでCLI 2.109.1を使って実行したところ、すべてのプロジェクトがAWSのリージョンコードとともに返ってきたので、EU域外にあるプロジェクトがないか、ざっと見れば分かります。

変更できる? できません。Supabaseのトラブルシューティングのノートによると、プロジェクトはインフラのレベルでリージョンに固定されています。移すには、移行先のリージョンに新しいプロジェクトを作って移行し、そのあとアプリのAPI URLとキーを更新し、サードパーティのサインイン用シークレットを手でコピーします。別の組織へプロジェクトを移転しても、リージョンは変わりません。

Lovable CloudはGDPRに準拠している?

Lovable Cloudのアプリは同じモデルでバックエンドを動かすので、同じ問いが当てはまり、その手前にLovableの設定が加わります。Lovableのバックエンドのドキュメント、データベースのドキュメント、DPAのページによると、次のとおりです。

  • リージョンはAmericas、Europe、Asia Pacificのいずれかで、バックエンドを有効にするときに決まります。管理者が設定したワークスペースの既定があればそれが優先されます(BusinessプランとEnterpriseプラン)。なければ、あなた自身の「where project data is stored」設定が使われ、それもなければ、あなたに最も近いリージョンになります。
  • リージョンを目にしないこともあります。 Enable Cloudが「Always allow」だと、Lovableは確認なしにそのリージョンでバックエンドを作ります。先にリージョンを表示するのは「Ask each time」だけです。
  • 変更できません。 プロジェクトのリージョンは変更できず、既存のプロジェクトを移すこともできないと、Lovableははっきり述べています。
  • 確認する場所は、More → Database → Manage → SettingsのDatabase locationの行です。たとえば「Europe (Frankfurt)」と表示されます。
  • サイト自体はリージョンに関係なくグローバルに配信されます。 リージョンが対象とするのはバックエンドだけです。
  • AIのリクエストは別です。 AIモデルへのリクエストをEU内に留める設定はEU inferenceと呼ばれ、Enterpriseのワークスペースで使えます。
  • DPAはBusinessプランとEnterpriseプランに含まれます。

つまり、ヨーロッパの外で作業していて、自分の設定もないままバックエンドを有効にした場合、バックエンドは別のリージョンにある可能性があり、「Always allow」がオンなら、Lovableは確認してきません。最初の本物のユーザーが登録する前に、Database locationの行を確認してください。

リージョンでは解決しないこと

Supabase自身のガイドも述べています。リージョンの選択はデータの所在地に関するコントロールであり、それだけでアプリがGDPRに準拠するわけではありません。私が最もよく見かける抜けは、プラットフォームではなくアプリの側にあります。

  1. 誰でも読める個人データ。 RLSがオフのテーブルや、すべての行を許可するポリシーのあるテーブルは、公開キーを持つ人に名前とメールアドレスを返します。無料のSupabase セキュリティチェックは、RLSのないテーブル、すべての行を許可するポリシー、匿名の訪問者が読める機密性の高そうな列を指摘します。
  2. 他人のアドレスで作られたアカウント。 メール確認をオフにすると、自分のものではないアドレスで誰でも登録できます。
  3. 公開バケットのファイル。 公開バケットは、URLを知っている誰にでもすべてのファイルを返し、CDNがそれを世界中にキャッシュします。
  4. 自分で追加した処理者。 Edge Functionsが呼び出すメール、SMS、AI、分析のサービスはすべて、Supabaseではなくあなたの処理者で、それぞれ個別の契約が必要です。
  5. 削除と保持。 コンテンツを書いたユーザーの削除を外部キーが妨げると、消去の請求は失敗しますし、アドレスを永久に残すログは保持の問題になります。

最後の2つと、さらに4つについては、私のLovableアプリのセキュリティチェックリストのGDPRの節で扱っています。GDPR以外にSupabaseが何を認証されているかは、Supabaseは安全?をご覧ください。この記事は法的助言ではありません。あなたの処理に何が必要かは、データ保護責任者か弁護士が判断します。

アプリのデータがどこにあるか分かりませんか?

リージョンとアクセスルールを一緒に確認できれば嬉しいです。売り込みはありません。

お問い合わせ

© 2026 Denys Zaichenko. 元の記事: https://madsalt.tech/ja/blog/is-supabase-gdpr-compliant/