Web開発 2026年8月28日

1 何を作るか｜Supabase が1つでまかなう範囲

問い合わせフォームと管理画面という題材を、Supabase だけで組み立てるとどうなるかを整理します。データベース・認証・ファイル保存・サーバー処理の担当を確認し、このコースだけが一般ユーザーのログインを扱える理由を説明します。

#Supabase #カリキュラム #全体像
難易度前提知識ゼロでも読めます所要時間約 20 分種別学習コース

このレッスンでわかること

このコースは、問い合わせフォームと管理画面を作って公開するまでを全7章で通します。最初の章では、コードを書く前に「何を作るか」と「Supabase のどの部分が何を担当するか」を決めます。

  • 作るものの全体像と、必要な機能の一覧がわかる
  • Supabase が1つでまかなう範囲と、まかなわない範囲がわかる
  • このコースだけが一般ユーザーのログインを扱える理由がわかる
  • 本コースの中心が RLS（行レベルセキュリティ）である理由がわかる

手順は 2026-08 時点のものです。ダッシュボードの画面構成は変わることがあるので、ボタンの位置よりも「何をしているか」を追ってください。

作るもの

2つの面を持つ、小さな Web アプリケーションです。

面誰が使うかできること
公開フォーム誰でも（ログイン不要）名前・メール・本文を送信する。添付ファイルを1点付けられる
管理画面運営者だけ届いた問い合わせの一覧を見る。対応済みフラグを立てる
マイページログインした一般ユーザー自分が送った問い合わせだけを後から確認する

3つ目は他の2コースには無い面です。理由は後述します。

必要な機能を分解する

作るものを機能に分解すると、次の6つになります。

  1. データを保存する場所 — 問い合わせの本文や送信日時を残す
  2. ブラウザからデータを読み書きする経路 — API
  3. ファイルを保存する場所 — 添付ファイル
  4. 誰がどのデータに触れるかの制御 — 公開フォームからの送信は許すが、他人の問い合わせは読ませない
  5. ログイン — 運営者と、一般ユーザーの両方
  6. サーバー側でしか動かせない処理 — 通知メールの送信など

一般的には、この6つを別々のサービスで組み合わせます。Supabase の特徴は、6つすべてが1つのプロジェクトの中に揃っていることです。

Supabase が担当する範囲

Supabase は「Postgres データベースを中心に、その周りの機能をまとめた開発基盤」です。プロジェクトを1つ作ると、次のものが同時に立ち上がります。

機能何をするかこのコースで扱う章
DatabasePostgres データベースそのもの第2章
Data APIテーブルを作ると自動で生える REST API（PostgREST）第2章
RLS行単位のアクセス制御。Postgres の標準機能第3章
Authサインアップ・ログイン・セッション管理第4章
Storageファイルの保存と配信第5章
Edge Functionsサーバー側で動く関数第6章

**Data API がこのコースの前提になります。**テーブルを作ると、そのテーブルを読み書きする API が自動で用意され、ブラウザの JavaScript から直接叩けるようになります。サーバー側のコードを書かずにデータベースが使える、というのが Supabase の最初の驚きどころです。

「API を書かない」ことの裏返し

サーバー側のコードを書かないということは、アクセス制御をサーバー側のコードで書けないということでもあります。

普通の Web アプリケーションなら、こう書きます。

// 一般的な作り。サーバー側で「見せてよいか」を判断する
app.get("/api/inquiries", (req, res) => {
  if (!isAdmin(req.user)) return res.status(403).end();
  return res.json(await db.query("select * from inquiries"));
});

Supabase の Data API には、この判断を書く場所がありません。代わりに、データベース側に「誰がどの行を読めるか」のルールを置きます。それが RLS です。

だから本コースの中心は第3章になります。ここを飛ばすと、問い合わせの中身が誰にでも読める状態のまま公開してしまいます。

Supabase が担当しない範囲

先に境界を書いておきます。

  • フロントエンドのホスティング — Supabase はアプリの配信をしません。作った画面は別のところに置きます（このコースではローカルで動かすところまでを扱います）
  • 独自ドメインの管理 — プロジェクトの API には プロジェクトID.supabase.co の形の URL が割り当てられます
  • メール配信の本番運用 — Auth は認証メールを送りますが、既定の送信経路は開発用です。詳細は第4章で扱います

つまり Supabase は「アプリのうしろ側」を引き受けるサービスです。前側は自分で用意するか、別のホスティングと組み合わせます。

他の2コースとの違い

同じサイトに、同じ題材を Cloudflare と Vercel で作るコースがあります。3つを見比べると、同じ課題への解き方の違いが分かります。

Cloudflare 入門コースVercel 入門コース本コース
データ保存D1（SQLite）外部サービスを接続Postgres（内蔵）
ファイル保存R2外部サービスを接続Storage（内蔵）
管理画面の保護Cloudflare AccessDeployment ProtectionRLS + Auth
一般ユーザーのログイン扱えない扱えない扱える

一般ユーザーのログインを扱えるのは本コースだけ

ここが3コースのいちばん大きな差です。

  • Cloudflare Access は、管理画面のような社内向けの入口に鍵をかける仕組みです。会社のメールアドレスや ID プロバイダで運営者を絞り込む用途に向いていて、不特定多数の一般ユーザーがサインアップして自分のアカウントを持つ、という使い方は想定されていません
  • Vercel の Deployment Protection は、デプロイされた URL そのものを保護する仕組みです。Preview 環境を関係者以外に見せない、といった目的のものであり、アプリケーションのユーザー認証ではありません

どちらも「運営者だけが入れる画面」は作れます。しかし「一般ユーザーがアカウントを作り、自分のデータだけを見る」は作れません。

**Supabase Auth はアプリケーションのユーザー認証そのものです。**サインアップしたユーザーは Postgres の auth.users テーブルに行として入り、その ID を RLS のポリシーから参照できます。だから「自分が送った問い合わせだけ見える」が成立します。

Cloudflare 入門コースでは第6章で管理画面を Access で守り、そこで「一般ユーザー認証には使えない」と説明しています。本コースの第4章は、その先を扱う章だと考えてください。

3つのサービスの使い分けそのものについては、Cloudflare / Vercel / Supabase の選び方にまとめてあります。

鍵の話を先にしておく

第3章の理解に必要なので、ここで用語を1つだけ押さえます。

Supabase のプロジェクトには2種類のキーがあります。

キー公式の位置づけ置き場所
publishable key（sb_publishable_...）Web ページ・モバイルアプリ・ソースコードに置いてよいクライアント側
secret key（sb_secret_...）バックエンドだけで使う。RLS を完全にバイパスするサーバー側のみ

publishable key は、公式ドキュメントが「オンラインに露出させて安全」と明記しているキーです。ブラウザの開発者ツールを開けば誰でも読み取れます。それでよい設計になっているのは、RLS が守っているからです。

裏を返すと、**RLS を設定していないテーブルは、publishable key を持つ誰からでも読み書きできます。**公式ドキュメントも「公開スキーマにあって RLS の無いテーブルは、grant を持つあらゆるロールから読み書きできる」と書いています。

secret key の方は、名前のとおり秘密です。ブラウザ側のコードに書いてはいけません。第6章で Edge Functions を扱うときに、置き場所も含めて説明します。

以前は anon key / service_role key と呼ばれていました。現在は publishable key / secret key が現行の名称で、旧名称のキーは「2026年末までに非推奨化する」と公式に案内されています（具体的な廃止日は公式ドキュメント上で確認できていません）。既存の記事やサンプルコードでは旧名称が使われていることが多いので、読み替えてください。

このコースの進み方

章やること
第2章プロジェクトを作り、テーブルを設計し、変更をマイグレーションとして残す
第3章RLS を書く。本コースの中心
第4章Auth でサインアップとログインを付ける
第5章Storage で添付ファイルを受け取る
第6章Edge Functions を使う場面と使わない場面を分ける
第7章ブランチング・バックアップ・費用

第3章までで「安全にデータを扱える状態」ができます。そこから先は機能を足していく章です。

やってみよう

手を動かす前の準備として、次の3つを確認してください。

  1. Node.js のバージョンを確認する：node -v を実行します。Supabase のクライアントライブラリは Node.js 20 のサポートを 2026-06-30 に終了しているため、22 以降にしておきます
  2. アカウントを作る：supabase.com でサインアップします。プロジェクトの作成は第2章で行うので、ここではアカウントだけで構いません
  3. 作るものを1文で書き出す：「誰が」「何をできる」を、上の3つの面ごとに紙に書いてみてください。第3章でポリシーを書くとき、この1文がそのまま条件になります

3つ目が地味に効きます。RLS のポリシーは「誰が・どの行に・何をできるか」を SQL で書いたものなので、日本語で書けていないものは SQL でも書けません。

まとめ

  • 題材は公開フォーム・管理画面・マイページの3面を持つアプリケーション
  • Supabase は Database / Data API / RLS / Auth / Storage / Edge Functions を1つのプロジェクトに持つ
  • テーブルを作ると API が自動で生えるので、アクセス制御をサーバーコードに書く場所が無い。代わりにデータベース側の RLS で守る
  • publishable key はクライアントに露出する前提のキー。RLS の無いテーブルは実質公開になる
  • 一般ユーザーのログインを扱えるのは3コース中このコースだけ。Cloudflare Access は運営者向けの入口保護、Vercel の Deployment Protection はデプロイ URL の保護であり、どちらもアプリのユーザー認証ではない
  • フロントエンドのホスティングと本番のメール配信は Supabase の外側

理解度チェック

Q1. Supabase の publishable key について、正しい説明はどれでしょう？

  1. 秘密のキーなので、ブラウザ側のコードに書いてはいけない
  2. クライアントに露出する前提のキーで、テーブルを守るのは RLS の役割
  3. RLS をバイパスするので、管理画面でだけ使う
  4. Edge Functions からしか使えない
答えを見る

正解：2

公式ドキュメントは publishable key を「Web ページ・モバイル・デスクトップアプリ・ソースコードに露出させて安全」と説明しています。露出しても安全なのは、テーブル側で RLS が効いていることが前提だからです。RLS をバイパスするのは secret key の方で、こちらはサーバー側だけで使います。

Q2. 「一般ユーザーがアカウントを作り、自分が送った問い合わせだけを見る」機能を、Cloudflare Access で実現できない理由はどれでしょう？

  1. Cloudflare Access が有料機能だから
  2. Cloudflare Access はデプロイ URL の保護であって、認証機能ではないから
  3. Cloudflare Access は運営者・社内メンバーの入口を絞る仕組みで、不特定多数のユーザーがサインアップする用途を想定していないから
  4. Cloudflare Access はデータベースと連携できないから
答えを見る

正解：3

Cloudflare Access は ID プロバイダと連携して「この画面に入れる人」を絞る仕組みで、管理画面の保護には向いています。一方、一般ユーザーが自由にサインアップしてアカウントを持つ形は想定外です。選択肢2は Vercel の Deployment Protection の説明で、こちらもユーザー認証ではありません。Supabase Auth は認証されたユーザーが auth.users の行として残り、その ID を RLS から参照できる点が違います。

参考リンク