【ITニュース解説】Supabase's 30 Oct change: the next table your AI builder creates needs a GRANT. Here's the 2-minute check.

Supabaseを利用してアプリケーションを開発しているシステムエンジニアの皆さん、特にAIビルダーを活用している方にとって、2026年10月30日以降、データベースの扱いに重要な変更が適用される。この変更は、新しく作成されるデータベーステーブルのセキュリティ強化を目的としたもので、今後の開発作業に直接影響するため、その内容をしっかり理解しておく必要がある。

これまで、Supabaseでは新しいテーブルをデータベースのpublicスキーマ内に作成すると、自動的に特定の役割（anon、authenticated、service_role）に対して、データの読み取り、追加、更新、削除といった基本的な操作（select, insert, update, delete）の権限が与えられていた。これにより、テーブルが作成された瞬間から、アプリケーションが利用するデータAPI（supabase-jsなどのクライアントライブラリが利用するREST/GraphQL層）を通じて、すぐにそのテーブルにアクセスできるようになっていた。この仕組みは開発を迅速に進める上で便利だったが、同時にセキュリティ上の潜在的なリスクも抱えていた。特に、AIエージェントや自動化されたスクリプトが人間のレビューなしにテーブルを作成するケースが増えたことで、意図せず重要なデータが外部に公開されてしまう可能性があったのだ。

このリスクを軽減するため、Supabaseはデフォルトの動作を変更する。具体的には、2026年10月30日以降に新しく作成されるテーブルは、明示的にPostgresのGRANTステートメント（権限付与の命令）を実行しない限り、アプリケーションからアクセスできなくなる。既に存在するテーブルについては、この変更の影響を受けず、これまで通りアクセス可能だ。問題が発生するのは、例えば2026年10月31日にAIビルダーを使って新機能のために新しいテーブルを作成した場合など、変更適用日以降に作られたテーブルである。

この変更は、段階的に適用されてきた。2026年4月28日には、新規プロジェクト作成時にこの設定をオプトイン（任意で選択）できるようになった。次に、2026年5月30日からは、新規プロジェクトのデフォルト設定としてこの変更が適用され、そして最終的に2026年10月30日には、既存の全てのプロジェクトに対してもこのルールが強制的に適用される。

影響を受けるのは、主にSupabaseのデータAPI（supabase-jsやその他のクライアントライブラリ、/rest/v1/、/graphql/v1/などのエンドポイント）を通じてpublicスキーマ内のテーブルと通信するアプリケーションである。また、データベースのマイグレーション（スキーマ変更履歴）やAIコーディングツールが、テーブル作成時にGRANTステートメントを含まない場合も影響を受ける。特に、WebブラウザからSupabaseのREST APIを直接呼び出すようなAIを使って構築されたアプリケーションの多くがこれに該当するだろう。

もしアプリケーションで新しい機能が動作しない、データがロードされない、保存できないといった問題が発生し、以前からある機能は正常に動作する場合、この変更が原因である可能性が高い。Supabaseのトラブルシューティング情報によると、クライアント側では「401 Unauthorized」や「403 Forbidden」のようなエラーとして報告されることが多い。

問題を確認するには、Webブラウザの開発者ツールを開き、ネットワークタブで失敗しているリクエストを探す。通常、...supabase.co/rest/v1/<table>のような形式のURLに対するリクエストでエラーが発生しているはずだ。そのエラーレスポンスを確認すると、code: "42501"とともに、message: "permission denied for table your_table"のようなメッセージが表示される。さらに、不足している権限を付与するためのGRANT SELECT ON public.your_table TO anon;といった具体的なSQLヒントが示されることもある。このヒントは、どのロールにどの権限が不足しているのかを明確に示してくれるため、非常に有用だ。

ここで注意すべき点として、同じ42501というエラーコードが表示されても、「new row violates row-level security policy」というメッセージが表示されている場合は、これは行レベルセキュリティ（RLS）が正しく機能していることを示しており、今回の権限変更とは異なる問題である。RLSは、テーブルへのアクセスは許可しつつ、どの行にアクセスできるかを細かく制御するための機能であるため、この変更による「テーブル自体へのアクセス拒否」とは区別する必要がある。

解決策としては、新しいテーブルが作成された際に、適切なGRANTステートメントを明示的に実行する必要がある。基本的には、テーブルの作成と同じマイグレーションファイル内で、GRANTステートメントと行レベルセキュリティ（RLS）の設定を同時に行うことが推奨される。

具体的なGRANTステートメントの例は以下の通りである。

• grant select on public.your_table to anon;：ログアウトしたユーザー（匿名ユーザー）にもテーブルのデータを読み取る権限を与える必要がある場合にのみ使用する。
• grant select, insert, update, delete on public.your_table to authenticated;：ログイン済みのユーザーに対して、データの読み取り、追加、更新、削除の権限を与える。
• grant select, insert, update, delete on public.your_table to service_role;：サービスロール（サーバーサイド処理など）に対して、データの読み取り、追加、更新、削除の権限を与える。

これらのGRANTステートメントでテーブルへのアクセス権を付与した後、必ず行レベルセキュリティを有効にし、適切なポリシーを設定することが重要だ。例えば、alter table public.your_table enable row level security;でRLSを有効にし、create policy "users can read their own rows" on public.your_table for select to authenticated using (auth.uid() = user_id);のように、ユーザーが自分自身のデータのみを読み取れるようなポリシーを設定する。

この対応を行う上で、特に避けるべき点がいくつかある。 まず、anonロールに対して反射的に全ての権限を付与することは避けるべきだ。このロールはアプリケーションにログインしていないユーザーを指すため、本当に公開が必要なテーブル以外には権限を与えないよう慎重になるべきである。 次に、GRANTステートメントだけでセキュリティが完結すると考えないこと。Supabaseのドキュメントにもあるように、GRANTは「どのロールがテーブルにアクセスできるか」を決定するものであり、RLSは「どの行にアクセスできるか」を決定する。RLSが有効になっていない状態でGRANTによってテーブルを公開してしまうと、そのテーブルは対応する権限を持つ全てのロールから、全てのデータにアクセス可能な状態となる。特にanonロールに権限を与えた場合、そのテーブルはインターネット上の誰からでもアクセスできてしまうため、非常に危険である。 最後に、GRANTステートメントでスキーマ全体に一度に権限を付与することも避けるべきだ。これにより、RLSが適切に設定されていない、あるいは意図せずRLSが無効になっているテーブルまでが公開されてしまうリスクがある。

AIビルダーやコーディングエージェントを利用している場合は、今後のテーブル作成時にこれらのGRANTステートメントとRLSの設定を自動的に含めるよう、そのツールに指示を与える必要がある。例えば、「今後はSupabaseのpublicスキーマに新しいテーブルを作成する際、そのテーブルと行レベルセキュリティ、そしてポリシーを定義する同じマイグレーション内に明示的なGRANTステートメントを含めること。アプリケーションで必要とされる場合にのみ、authenticatedとservice_roleにselect, insert, update, delete権限を付与し、ログアウトしたユーザーが読み取るべきテーブルにのみanonにselect権限を付与すること。決して行レベルセキュリティを無効にせず、スキーマ全体に一度に権限を付与しないこと。」といった具体的な指示をシステムプロンプトに加えることが推奨される。

この変更は、Supabaseを利用したアプリケーションのセキュリティを強化するための重要なステップである。システムエンジニアとして、この変更内容を正確に理解し、適切な対応を行うことで、安全で堅牢なアプリケーション開発を進めることができるだろう。