付録B　Supabase＋Google認証セットアップ

📖 このページのゴール：Supabaseでデータベースとログインを用意する。 ← 目次・はじめにへもどる

このページは 手順中心 です。会話の保存（データベース）と、Googleでのログイン（認証〔にんしょう：あなたが本人かを確かめること〕）を、ここで一度だけ用意します。上から順に番号どおりに進めれば大丈夫です。

💡 この土台は第1弾「Twitterクローン」とまったく同じです。同じ手順をもっとくわしく書いた 付録A Supabaseセットアップ手順 ／ 付録B Google認証設定手順 も、つまずいたときの参考になります。

🪜 Supabaseプロジェクトを作る

無料アカウントを作る。 ブラウザで https://supabase.com を開き、右上の「Sign in」または「Start your project」を押します。GitHubアカウントでサインインするのが一番かんたんです（持っていなければメールでも作れます）。
新しいプロジェクトを作る。 ダッシュボード（操作の入口画面）の「New project」を押し、次の3つを入力します。
- プロジェクト名（Name）：好きな名前でOK（例：chatgpt-clone）。
- データベースのパスワード（Database Password）：自分で決めます。かならずメモして控えてください（あとで必要になることがあり、再表示できません）。
- リージョン（Region〔さーばーのある地域〕）：自分に近い場所を選びます。日本なら Tokyo (ap-northeast-1) がおすすめ（近いほど速い）。
入力したら「Create new project」を押し、準備が終わるまで1〜2分ほど待ちます。

🔑 2つのキーと接続情報

左メニューの「Project Settings（歯車アイコン）」→「API」を開くと、コードから使う情報が並んでいます。次の3つを控えます。

Project URL（https://xxxx.supabase.co の形）… あなたのプロジェクトの住所。
anon キー（公開してよい・ブラウザ可） … 名前のとおり「公開してよい鍵」。ブラウザのコードに置いてOKです。「誰でも何でもできる」という意味ではなく、後で設定するRLS（あとで説明）で守る前提だから、安全に置けます。
service_role キー（全権限・秘密・サーバーのみ） … RLSも素通りする「マスターキー」。ぜったいにブラウザや、GitHubなどの公開リポジトリに出さないでください。使うのはサーバーの中だけです。

💡 この「公開してよい鍵／秘密の鍵」の見分け方は、第2章おまけの「公開/秘密の見分け」とまったく同じ考え方です。「これがバレたら、自分の財布で勝手に使われる・全データを触られる」鍵だけが“秘密”。service_role はその秘密側、anon は公開側です。

サーバー側で使う鍵は .env（環境変数〔かんきょうへんすう：プログラムの外から渡す設定値〕をまとめたファイル）に置きます。

# .env  ← このファイルは絶対にgitに入れない
SUPABASE_URL=https://xxxx.supabase.co
SUPABASE_ANON_KEY=ここに anon キー
SUPABASE_SERVICE_ROLE_KEY=ここに service_role キー

1行ずつ読むと：

SUPABASE_URL=... … あなたのプロジェクトの住所（Project URL）。
SUPABASE_ANON_KEY=... … 公開してよい鍵。ブラウザにも置けますが、サーバーからも使えるよう控えておきます。
SUPABASE_SERVICE_ROLE_KEY=... … 全権限の秘密の鍵。サーバーの中だけで読み、ブラウザには絶対に出しません。

🪜 Google認証を有効にする

「Googleでログイン」を動かすには、Google側で許可（鍵）を作り、それをSupabaseに登録してつなぐ必要があります。

OAuthクライアントを作る。 Google Cloud Console を開き、「APIとサービス」→「認証情報」→「+認証情報を作成」→「OAuthクライアントID」を選びます。種類は「ウェブアプリケーション」。作成すると クライアントID と クライアントシークレット が出るので、2つとも控えます。
承認済みのリダイレクトURIを登録する。 同じ画面の「承認済みのリダイレクトURI」に、Supabaseの戻り先（コールバック）を追加します。<あなたのプロジェクト> は自分の値に置きかえます。ここが1文字でも違うとログインできません。
```
https://<あなたのプロジェクト>.supabase.co/auth/v1/callback
```
SupabaseでGoogleを有効化する。 Supabaseダッシュボード →「Authentication」→「Providers」→「Google」を開きます。有効化して、手順1で控えた クライアントID と クライアントシークレット を貼り付け、保存します。
戻り先のURLを登録する。 「Authentication」→「URL Configuration」で、Site URL（開発中は http://localhost:3000 など、使うポート番号に合わせる）と Redirect URLs を登録します。ここが未設定だと、ログイン後に自分のアプリへ戻ってこられません。

🛠 テーブルとRLS

この教材では、4つの表（テーブル）を使います。

conversations … 会話のまとまり（チャット1個＝1行）。
messages … 会話の中の発言（user/assistant の1往復ぶんなど）。
usage … 使った量（トークン数・回数）。第6章の使いすぎ防止で使います。
memories … 会話をまたいで覚えておきたいこと。第10章のメモリで使います。

どの表にも、RLS（行レベルセキュリティ〔ぎょう・レベル・セキュリティ：表の“1行ごと”に見える人を絞るしくみ〕） を有効にして、「自分の行だけ」さわれるようにします。各行に持ち主のID（user_id）を入れ、ログイン中の本人を指す auth.uid() と一致する行だけを許可する、という形です。

-- 例：conversations を「自分の行だけ」にする
alter table conversations enable row level security;

create policy "own rows only" on conversations
  for all using (auth.uid() = user_id);

1行ずつ読むと：

alter table ... enable row level security … この表でRLSをONにする（ONにするまでは全公開のままなので注意）。
create policy ... for all using (auth.uid() = user_id) … 読み書き全部について、「ログイン中の本人（auth.uid()）＝その行の持ち主（user_id）」のときだけ許可する。

💡 4つの表をぜんぶ作るくわしいSQL（列の定義や、他の表のポリシーまで）は、付録H　会話データのスキーマ例 にまとめてあります。ここではまず「RLSをONにして、自分の行だけにする」という考え方を押さえればOKです。

⚠️ よくあるつまずき

リダイレクトURIの設定漏れ／ズレ … いちばん多い失敗です。Google側の「承認済みのリダイレクトURI」と、Supabaseの /auth/v1/callback が一字一句そっくり同じでないと、redirect_uri_mismatch というエラーになります。https/http・末尾の /・プロジェクト名まで合わせます。
RLSの有効化を忘れる … 表を作っただけで enable row level security を実行しないと、その表は全公開（誰でも全行を読める）になります。表を作ったら必ずRLSをONにしてください。
service_role キーをブラウザに置く事故 … マスターキーがバレると、他人にデータを全部読まれる・消されるおそれがあります。service_role はサーバーの中だけ。ブラウザのコードや公開リポジトリには絶対に出しません。

📝 ことばメモ

RLS（行レベルセキュリティ）：表の「1行ごと」に、見える人・さわれる人を絞るしくみ。auth.uid() = user_id で「自分の行だけ」にする
anon（キー）：公開してよい鍵。ブラウザに置ける。RLSで守る前提
service_role（キー）：全権限のマスターキー。サーバー専用で、ブラウザや公開リポジトリに出さない
OAuth（オーオース）：「このアプリにログイン確認してOK？」をGoogleなど他社に安全にお願いするしくみ
リダイレクトURI：ログインのあと戻ってくる住所。Google側に事前登録した住所しか使えない

🔗 第1弾 Twitterクローンで学ぶWeb開発入門 — はじめに・目次の付録A／付録Bも、まったく同じ手順です。画面のスクリーンショット感覚でもう少していねいに見たいときは、そちらもどうぞ。

← 目次・はじめにへもどる

付録B Supabase＋Google認証 セットアップ