先に結論
2026-05-30 以降に作る新しい Supabase project では、public schema に table を作っただけでは Data API と GraphQL から見えません。
supabase-js、REST、GraphQL を使うなら、これからは GRANT を明示してから RLS と policy を足す 流れが前提です。
急ぎの判断だけ先にまとめると、こうです。
- 新規 project は今日から対応が必要
- 既存 project は 2026-10-30 までに migration と運用を見直す
- direct Postgres connection だけ なら基本は慌てなくていい
- RLS だけでは直らない。先に GRANT が要る
今回の変更は、Supabase が public schema の新規 table を Data API に自動公開しない方向へ既定値を切り替えたものです。AI coding tool や CLI で table を量産するチームほど、早めに手順を直しておいたほうが安全です。
何が変わったのか
変わったのは、新規 table を API に見せる初期状態 です。
これまでは、public schema に table を作ると anon、authenticated、service_role へ既定の権限が付き、Data API と GraphQL からすぐ触れる動きが一般的でした。
2026-05-30 から新規 project の既定は逆です。table は作成されても、GRANT を書くまで Data API 側には公開されません。
Supabase の changelog では、切り替え時期を次のように案内しています。
- 2026-04-28: project 作成時に新挙動へ opt-in できるように変更
- 2026-05-30: 新規 project はこの挙動が default
- 2026-10-30: 既存 project にも同方針を適用予定
一方で、既存 table はそのままです。今動いている table の権限が、今日いきなり剥がれるわけではありません。
まず影響を受ける人、受けない人
最初に切り分けると、影響が大きいのは Data API を踏む構成 です。
影響を受けやすいのは次のケースです。
supabase-jsで新規 table を直後に read や write する- PostgREST の
/rest/v1/を直接叩いている - GraphQL API を通して query や mutation している
- migration、CLI、AI coding tool で table を作り、そのまま API から触れる前提で組んでいる
逆に、psql、ORM、app server の connection string で direct Postgres connection だけ を使う構成なら、今回の変更は基本的に刺さりません。
つまり見るべきなのは、「Supabase を使っているか」ではなく どの経路で table を読んでいるか です。
なぜ RLS だけでは直らないのか
ここは誤解しやすいです。GRANT と RLS は別レイヤー です。
GRANT は、その role が table に入場できるかを決めます。RLS は、入場できたあとにどの行を見せるかを決めます。
Supabase 公式も、RLS の挙動は変わらず、先に権限チェックが走ると説明しています。つまり GRANT がない状態では、policy が正しくても API からは弾かれます。
権限が足りない時は、PostgREST が permission denied for table ... と返し、必要な GRANT のヒントも出します。silent failure ではないので原因の切り分けはしやすいですが、migration へ反映しない限り再発します。
実務では何を変えるべきか
一番大事なのは、table 作成を単独で終わらせないこと です。
これからの migration は、少なくとも次の3点を同じ変更にまとめるのが安全です。
- 必要な role へ
GRANTを付ける enable row level securityを入れる- 必要な policy を追加する
最小例はこうです。
create table public.orders (
id uuid primary key,
user_id uuid not null,
total integer not null
);
grant select on public.orders to anon;
grant select, insert, update, delete on public.orders to authenticated;
grant select, insert, update, delete on public.orders to service_role;
alter table public.orders enable row level security;
create policy "users can read their own orders"
on public.orders
for select
to authenticated
using (auth.uid() = user_id);もし AI coding tool に table 作成を任せているなら、prompt や template も直したほうがいいです。create table だけで終わる prompt は、2026-05-30 以降の新規 project では壊れやすくなります。
新規 project と既存 project でやることは少し違う
新規 project は、今この瞬間から手順変更が必要です。
project を今日以降に作ったなら、「table を追加したのに API から見えない」はまずこの変更を疑うのが早いです。特に、開発初日に dashboard、SQL editor、agent で schema を量産するチームははまりやすいです。
既存 project は、今日すぐ全面改修しなくてもいいものの、2026-10-30 に向けた棚卸しが必要です。
見ておきたいのは次の3点です。
- 新規 table 作成 migration に GRANT が入っているか
- agent prompt や internal scaffolding が旧前提のままになっていないか
- public schema に増える table を誰がレビューする運用か
既存 project で今のうちに opt-in して検証したい場合は、Supabase が changelog で案内している alter default privileges ... revoke ... を staging で先に試すと移行差分を見つけやすいです。
変更の背景はむしろ自然
この変更は不便というより、人間レビューなしの table 作成が増えた現実に合わせた ものです。
Supabase は changelog で、AI agents、CLI scripts、Management API などが schema change を作る機会が増えたと説明しています。table を作った瞬間に API へ露出する既定は、その流れだと事故の温床になりやすいです。
明示的な GRANT に寄せると、権限が migration に残ります。review しやすく、差分も追いやすく、anon と authenticated を雑に同じ扱いにしにくくなります。
要するに今回の変更は、便利さを少し減らして、意図しない公開を減らす方向 です。
いま困っている人向けの確認リスト
新規 table が見えない時は、この順で見ると早いです。
- その project は 2026-05-30 以降に作られていないか
- 対象 table は
publicschema か anon、authenticated、service_roleのどれに何を許すか決めたか- migration に
GRANTが入っているか - RLS policy だけ追加して満足していないか
BaaS 自体の選び直しまで含めて考えたいなら、AIエージェント時代のbackend比較｜InsForge vs Supabase vs Convex vs Firebase も参考になります。ただ、今回の論点は乗り換えより Supabase 運用を新前提へ合わせること です。
まとめ
Supabase の今回の変更で覚えておくべきことはシンプルです。public schema の新規 table は、もう自動では API に出ません。
supabase-js、REST、GraphQL を使うなら、今後の標準手順は GRANT → RLS → policy です。
新規 project は今日から、既存 project も 2026-10-30 までにこの前提へ寄せておくと、後から permission denied の山を掘らずに済みます。