教室の予約アプリが、
本番でログインできない

1症状と再現の結果

• このアプリは、Supabase のプロジェクトを本番用と開発用に分けています。本番の状態（Supabase の設定・公開先の設定と記録・予約のテーブル）は、依頼者の画面共有で見せていただきました。
• Qzの手元（テスト用のプロジェクトにつないだ開発用の環境）では、Googleアカウントでのログイン・予約の一覧・予約の登録がすべて動くことを確かめました。
• Qzのテスト用の環境（本番と同じ設定にしたテスト用の Supabase のプロジェクトにつないだ公開先）に、本番と同じ組み立て（ビルド）で公開すると、次の2つを再現しました。
  1. 「Googleでログイン」のボタンを押すと、ログインのあと http://localhost:3000/ に移ってしまう。
  2. 予約の一覧（/reservations）を開くと500エラーになる。
• 本番のアプリ・本番のデータ・本番のAPIキーやパスワードには触れていません（テスト用の環境は、架空のデータで動かしました）。

2原因の候補と確からしさ

3修復か、作り直しか

修復を勧めます。アプリの全体の作り（画面・データ・ログインの分け方）は大きくは崩れておらず、直す場所が限られるためです。作り直すと、今の画面や予約の流れを作り直す手間のほうが大きくなります。

4直す範囲と順番

1. B：ログインのあとの戻り先を、ブラウザーが今開いているアドレスをもとに決める書き方に直す（1ファイル）。ログインはいったん、そのアドレスのコールバック URL（ログインのあとに戻ってくるアドレス。/auth/callback）に戻ってログインの状態を保存し、そこからトップへ移ります。本番でもテスト用の公開先でも、同じ動きになります。
2. D：予約のテーブルに今あるポリシーを確かめ、広すぎる許可（例：「ログインしていれば全件」）があれば消してから、RLS を有効にし、「本人の予約だけ読める・書ける」ポリシーを足す（許可は「どれか1つに合えば通る」ため、古い許可が残ると全件読めてしまいます。データベースの設定の変更を、元に戻せる形で用意。開発用のプロジェクトにも同じポリシーを入れる）。本番へは、Cの取り込みより先に入れます。今の本番のコードは管理用のキーを使うので、先に入れても画面の見え方は変わりません。元に戻すときは、コードだけを戻し、このポリシーは戻しません。
3. C：ふだんの予約の取得を、管理用のキーではなく、ログインした本人の権限で読む形に直す（3ファイル）。読み出しにも「本人の予約だけ」の絞り込みを書き、RLS と二重にします。このアプリの今の機能では管理用のキーは要らないため、使わない形にする。Dを本番に入れたあとで取り込みます。
4. A：Supabase の管理画面の設定は、依頼者が変更します。本番のプロジェクトでは、Site URL を本番のトップのアドレスにし、Redirect URLs には本番のコールバック URL（https://（本番のアドレス）/auth/callback）を入れます（開発用のプロジェクトは localhost のコールバック URLのまま）。テスト用の公開先のコールバック URLは、テスト用のプロジェクトにだけ入れます（手順をお渡しし、画面共有で一緒に確かめます）。

勧めない直し方：本番の公開先に管理用のキーの値を足すだけでも500エラーは消えますが、管理用のキーはRLSを飛び越えるため、ほかの人の予約まで表示されるおそれがあります。

今回は直さないこと：画面のデザインの調整、新しい機能、予約の確認メールの文面。

5難しさの判定

ふつう（1〜2日・数ファイル・外のサービス）。理由：直すファイルが4つとデータベースの設定1つで、ログインとデータベースの2つの外のサービスの設定にまたがるため。全体の作り直しや引き継ぎは要らないため「むずかしい」ではありません。

6確定した見積もり

金額はすべて税込みです。この報告のあとで成功報酬を増やすことはありません。直し始めてこの範囲を超えると分かった場合は、そこで止めてご相談します。続ける場合は、改めてお見積もりします。

7「直った」の定義

次のすべてを、まずテスト用の公開先（本番と同じ組み立てで公開し、テスト用の Supabase のプロジェクトにつないだ確認用のアドレス）で、依頼者と画面共有で確かめます。この日に変更の提案をお届けし、これを納品とします。そのあと依頼者が取り込んで本番に出し、確かめる期間（納品から5営業日）のうちに、本番でも確かめていただきます。本番では、依頼者が用意する確認用のアカウント2つで、表示と「ほかの人の予約を読めない」ことを確かめます（書き込みの試しはテスト用の公開先だけで行い、確認用の予約は終わったら取り消します）。

期間内に、Qzが直した範囲（B・C・D）の不具合のご指摘がなければ、確かめたものとみなします。ご指摘があれば、直してから改めて確かめます。「依頼者にお願いすること」の作業を、お渡しした手順と違う形で行った・まだ行っていないことが原因のときは、画面共有でお手伝いしますが、Qzの直しの不具合には数えません。お渡しした手順どおりに行っても動かない場合は、手順の不備としてQzの直しの不具合に数えます。

• 「Googleでログイン」を押すと、ログインのあと、開いていたアドレスのトップに戻る（localhost に移らない）。
• 予約の一覧が500エラーにならず、自分の予約だけが表示される（予約の入った利用者2人で確かめる）。
• 予約の登録・取り消し・空き枠の表示が、これまでどおり動く。
• ほかの利用者の予約を、ログインしていない状態でも、別の利用者としてログインした状態でも、読めない・書けない（画面を通さず、Qzが用意する手順で、ログインしていない状態・利用者1・利用者2のそれぞれでデータベースに直接、読み・登録・変更・取り消しを試して確かめる。書き込みの試しはテスト用の公開先だけ。本番では読みの確かめだけを、依頼者の画面で行う）。
• クライアント側に届くコードに、管理用のキーが含まれていない。
• 手元の開発用の環境でも、ログイン・自分の予約の一覧・予約の登録が動く。

8ご自分で直す場合の手順の目安

この報告だけを使って、ご自分のAIで直すこともできます。その場合の順番の目安です。

1. 作業の前に、今の状態を残す（AIに「今の状態を Git に保存して」と頼む。いつでも戻せるように）。
2. Supabase の本番のプロジェクトで、Site URL を本番のトップのアドレスにし、Redirect URLs に本番のコールバック URL（/auth/callback までの完全なアドレス）を入れる（開発用のプロジェクトは localhost のコールバック URLのまま）。
3. コードの中の localhost の戻り先を探し、ブラウザーが今開いているアドレスをもとに決める書き方にするよう、AIに頼む。
4. 予約のテーブルに今あるポリシーを確かめ、広すぎる許可を消してから、RLS を有効にし、本人の予約だけ扱えるポリシーを足す（開発用と本番の両方のプロジェクトに）。本番には、5より先に入れる。
5. 予約の一覧を取る処理を、管理用のキーではなく、ログインした本人の権限で読み、本人の予約だけに絞る形にするよう、AIに頼む。管理用のキーの値を本番に足すだけで済ませない（ほかの人の予約が見えるおそれがある）。
6. 7の「直った」の定義を、1つずつ確かめる。

＋依頼者にお願いすること

• Supabase の本番のプロジェクトの設定の変更（4のA）と、本番の公開先に入れる設定の値の入力（Qzは本番のAPIキーやパスワードを預かりません）。
• 本番のデータベースに、用意したRLSの変更を入れること。取り込みより先に行います（手順をお渡しし、画面共有で一緒に確かめます）。
• GitHubに届いた「変更の提案」（Pull Request）を確かめて取り込み、本番に出したあと、確かめる期間（納品から5営業日）のうちに本番のアドレスでも7を確かめること。
• Google のログインの設定（同意画面）が「テスト中」のままなら、公開の状態に切り替えること（テスト中は、登録した人しかログインできません）。
• このアプリでは管理用のキーを使わなくなるため、開発用の設定ファイルから値を消すこと（GitHubの過去の記録に値が入っていないことは、Qzが確かめました）。
• 終わったら、GitHub の Qz の招待を外すこと。