Supabaseを利用しているプロジェクトにおいて、API経由でデータを取得しようとした際に「42501」などのエラーが発生したり、新規に作成したテーブルからデータが取得できなくなったりする事例が報告されています。
これは、Supabaseが2026年5月30日より順次実施している「Data API（PostgRESTおよびGraphQL）におけるデフォルト公開仕様の変更」が原因です。従来は新規テーブルを作成すると自動的にAPI経由でアクセス可能な状態になっていましたが、今後は明示的な権限付与（GRANT）が必要になります。
この記事では、この重要な仕様変更がどのような影響を与えるのか、自分のプロジェクトが対象かどうかの判定方法、SQLを用いた具体的な解決手順、そしてBaaSに依存しない別のインフラ構成（GCPのCloud RunやNeonなど）への移行案までをわかりやすく解説します。
この記事で行うこと
前提条件
注意点
この仕様変更は、supabase-jsなどのクライアントライブラリやGraphQL、REST API（PostgREST）を経由したアクセスにのみ適用されます。
PrismaやDrizzle ORMなどのツールを使用し、データベース接続文字列を用いてサーバーサイドから直接PostgreSQLに接続している場合は、今回の仕様変更による影響を受けません。直接接続は引き続き以前と同様に動作します。
仕様変更のスケジュールと内容
今回の仕様変更は、セキュリティを向上させ「最小権限の原則」をデフォルトで適用するために実施されます。
従来は、publicスキーマにテーブルを作成すると、自動的に「anon（未認証ユーザー）」「authenticated（認証済みユーザー）」「service_role（管理者）」といったAPI用ロールに対してSELECT、INSERT、UPDATE、DELETEの権限が付与されていました。
2026年5月30日以降は、新規作成されたプロジェクトにおいてこの自動権限付与が廃止され、初期状態ではAPIからテーブルに一切アクセスできなくなります。
スケジュールは以下の通りです。
既存プロジェクトの既存テーブルについては、2026年10月30日以降も設定が自動的に剥奪されることはありませんが、新しくテーブルを追加する場合は対応が必要になります。
手順1：影響を受ける対象の確認方法
自分のプロジェクトでどのテーブルがData APIに公開されているかは、SupabaseのダッシュボードにあるSecurity Advisorを利用して確認できます。
Security Advisorでの確認
- Supabase Dashboardにログインし、対象のプロジェクトを選択します。
- 左メニューの「Advisors」から「Security Advisor」をクリックします。
- 警告や推奨事項のリストが表示されるため、Data APIへの露出状況やRow Level Security（RLS）が設定されていないテーブルがないかを確認します。
もしエラー「42501」が発生している場合、APIが求める権限がテーブルに対して付与されていないことを意味します。その場合は、次の手順に沿ってSQLで権限を付与してください。
手順2：SQLで権限（GRANT）を明示的に付与する
新しく作成したテーブルをAPI経由で公開するためには、SupabaseのSQL Editorから以下のSQL文を実行し、適切なロールに権限を明示的に付与する必要があります。
1. ログインユーザーのみにアクセスを許可する場合
認証されたユーザー（authenticatedロール）に対して、特定のテーブルへの操作を許可する場合は、以下のSQLを実行します。
GRANT SELECT, INSERT, UPDATE, DELETE ON TABLE public.your_table_name TO authenticated;2. 未ログイン（アノニマス）ユーザーにも読み取りを許可する場合
未ログインユーザー（anonロール）に対して読み取り（SELECT）のみを許可する場合は、以下のSQLを実行します。
GRANT SELECT ON TABLE public.your_table_name TO anon;3. RLS（行レベルセキュリティ）の有効化
GRANTによる権限付与は、APIからテーブルに「到達できる状態」にするためのものです。セキュリティを守るためには、必ずRow Level Security（RLS）を有効にし、適切なポリシーを作成してください。
ALTER TABLE public.your_table_name ENABLE ROW LEVEL SECURITY;
CREATE POLICY "Users can read their own data" ON public.your_table_name
FOR SELECT TO authenticated
USING (auth.uid() = user_id);このように、今後は「テーブル作成」「GRANTによる権限付与」「RLSの有効化とポリシー定義」を1つのマイグレーションフローとしてまとめて運用する必要があります。
手順3：別のインフラ環境への移行案
今回の仕様変更を機に、クライアントから直接データベースを叩くBaaS（Backend as a Service）のモデルから、APIサーバーを中間に挟む一般的なWebシステム構成へ移行することも選択肢に入ります。代表的な移行案を3つ紹介します。
移行案1：GCP Cloud Run ＋ マネージドPostgreSQL（推奨）
Google CloudのCloud Runを利用して自前のAPIサーバー（Next.jsのAPI Routes、FastAPI、Go、Expressなど）を構築し、データベースに直接接続する構成です。
移行案2：Neon ＋ 自前APIサーバー（RenderやFly.io）
Neonはサーバーレスに対応したPostgreSQLデータベースサービスです。
移行案3：Supabase Self-hosted（セルフホスト版）
Supabaseはオープンソースであるため、独自のVPSやAWS、GCPなどのサーバー上にDocker Composeを使って丸ごとホストすることができます。
よくある質問
Q. RLS（行レベルセキュリティ）を設定していればGRANTは不要ですか？
いいえ、今回の仕様変更により、RLSポリシーの評価よりも手前の段階で、テーブル自体へのアクセス権限（GRANT）が必要になります。そのため、GRANTを実行した上でRLSを有効にする必要があります。
Q. 既存のプロジェクトはすぐに動かなくなりますか？
いいえ、2026年10月30日までは既存プロジェクトの既存テーブルおよび新規テーブルに対しては、以前の挙動（自動公開）が維持されます。ただし、それ以降に作成される新規テーブルには制限が適用されるため、早めのマイグレーションフローの改修を推奨します。
Q. 直接データベースに接続してデータ操作をする場合も影響を受けますか？
いいえ、psqlなどのクライアントツール、PrismaやDrizzleなどのORMを利用して直接PostgreSQLポート（5432など）に接続している場合は、何の影響もありません。
まとめ
SupabaseのData APIのデフォルト仕様変更は、プロジェクトのセキュリティを向上させるための重要な変更です。
最新のセキュリティ仕様を正しく理解し、安全なシステム開発を進めていきましょう。
