トグル一つ、二晩
デプロイは成功したのにログインできなかった夜
ブラウザにURLを入力した。
stacktube-production.up.railway.app
画面が表示された。私が作った——正確にはAIが作り私が指示した——ランディングページがインターネット上に存在していた。機能紹介、料金表、FAQ。全部あった。管制塔にURLを送ったら確認してくれた。「ランディングページ正常レンダリング、全セクション確認。」
できた。
しかし「できた」の賞味期限は短かった。
会員登録ボタンを押した。メールアドレスとパスワードを入力した。登録ボタンを押した。エラーが出た。
validation_failed: Unsupported provider: provider is not enabled
このエラーで理解できた単語は「not enabled」だけだった。何かが有効化されていないという意味。しかし何が？
エラーを管制塔に送った。答えが来た。
「SupabaseでEmail Providerが無効化されているために発生するエラーです。」
Supabaseはこのプロジェクトでユーザー認証を担当する外部サービスだ。管制塔の案内に従った。Supabaseダッシュボードにアクセス。Authentication → Providers → Email。そこにトグルスイッチがあった。オフになっていた。オンにした。
再び会員登録を試みた。できた。
トグル一つ。
しかしこのトグルに辿り着く前に、別の問題があった。リダイレクトURLというものだった。
デプロイすると、アドレスが変わる。自分のPCではlocalhost:3000だったアドレスが、インターネットに上げるとxxxxx.up.railway.appになる。当然のことだ。しかし私が知らなかったのは、認証サービスにこの新しいアドレスを「教えなければならない」ということだった。ログイン後にユーザーをどこに戻すかを認証サービスが知る必要があるのに、新しいアドレスを伝えていなかったのだ。
そしてこの二日の間に、セキュリティ事故が一つあった。
管制塔にエラーログを送る過程で、GitHub Personal Access Tokenが一緒に露出してしまった。これは自分のコード保管庫にアクセスできる鍵のようなもので、チャット画面にそのまま出てしまったのだ。
管制塔がすぐに警告を出した。「このトークンを直ちに無効化してください。」
こういうミスは初心者が必ず一度はやるものだという。APIキー、トークン、パスワードのようなものは、コードに直接入れたりチャットに晒したりしてはいけない。環境変数という別の場所に保管すべきだ。分かっていたが、急いでエラーをコピーしているうちに一緒に付いてきてしまった。
この二晩で学んだことを整理するとこうなる。
エラーは重なって来る。一つ直すとその裏に隠れていた別のエラーが現れる。これは驚くが正常だ。最初のエラーが塞いでいたから二番目のエラーが見えなかっただけで、二番目のエラーは最初からそこにあった。
そしてエラーの原因は大抵些細なものだ。トグル一つがオフだった。URL一つが登録されていなかった。このレベル。システム全体が間違っているわけではない。どこか一つが抜けているか、合っていないだけだ。
🔧 このエピソードの技術用語解説
デプロイ（Deploy/Deployment） 自分のPCだけで動くプログラムをインターネットに公開し、誰でもアクセスできるようにすること。レストランの例えなら、試験営業から正式開業への転換。
Railway コードをアップロードすると自動でサーバーを構築してくれるデプロイプラットフォーム。
Supabase Auth 会員登録、ログイン、パスワード管理を代行するサービス。認証システムを自前で作るとセキュリティリスクが高いため、専門サービスを使うのが業界標準。
Provider（認証プロバイダー） ログイン方法の種類。Email、Google、GitHubなどがそれぞれ一つのProvider。Supabaseで該当Providerを「オン」にしないとそのログイン方法は使えない。
リダイレクトURL（Redirect URL） ログイン成功後にユーザーを「どこに戻すか」を伝えるアドレス。デプロイ後にアドレスが変わるため、認証サービスに新しいアドレスを伝えないとログイン後に迷子になる。
トークン（Token） デジタル身分証。APIトークンは「この人はこのサービスを使う権限がある」という証明書。露出すると他人が自分のアカウントで行動できるため、直ちに無効化すべき。