AIで作ったアプリが、本番でログインすると
localhost に戻るときの確かめ方

先に答え

公開したアプリでログインすると http://localhost:3000 のようなアドレスに移ってしまうのは、ログインのあとの「戻り先」（リダイレクト先）に、開発中のアドレスが残っているためです。戻り先を決めている場所は、1つではありません。

1. ログインのサービス（Supabase など）の管理画面の設定
2. コードの中に直接書かれたアドレス
3. 公開先（Vercel など）に入れた設定の値

1つを直しても、ほかの場所に localhost が残っていれば、また localhost に戻ります。「設定を直したのに直らない」ときは、残りの場所を順に確かめてください。

この記事は、Supabase のログイン（Google アカウントでのログインなど）を使ったアプリを例に説明します。ほかのログインのサービスでも、考え方は同じです。アプリを作ったツール（Lovable・Bolt など）や公開先が違っても、確かめる場所の考え方は変わりません。設定の画面の場所は、ツールや公開先によって違います。

何が起きているのか

localhost は、「いま使っている、そのパソコン自身」を指すアドレスです。開発中は、自分のパソコンの中でアプリを動かすので、アプリのアドレスが localhost になります。

Google アカウントなどでログインするとき、利用者はいったんアプリの外（ログインの画面）へ出て、終わるとアプリへ戻ってきます。どこへ戻すか（戻り先）は、アプリの側があらかじめ決めておきます。

AIは、まず開発中に動くようにアプリを作ります。そのため、戻り先が localhost で書かれていることがあります。ログインのサービスの側も、初期の設定が localhost になっていることがあります（Supabase の「Site URL」の初期値は http://localhost:3000 です）。

公開するときには、この戻り先を本番のアドレスに変える作業が要ります。ところが、管理画面の設定はコードの外にあります。AIにコードを直してもらっても、管理画面の設定は変わりません。ここが、公開のあとに残りやすい所です。

自分のパソコンでは、気づきにくい症状です。自分のパソコンで開発用のアプリを動かしたままにしていると、本番でログインして localhost に戻っても、手元のアプリが開きます。そのため、動いているように見えます。ほかの人のパソコンやスマホには、localhost で動いているアプリがないので、「このサイトにアクセスできません」のような画面になります。「自分は使えるのに、ほかの人だけログインできない」ときは、この症状を疑ってください。

まず、戻ったアドレスを見る

ログインのボタンを押したあと、ブラウザーのアドレスの欄に何が出ているかを見てください。出ているアドレスで、進む先が変わります。

表は横にスクロールできます。

アドレスは、あとで人やAIに伝えるときにも使います。書き写すのは、? や # より前の部分だけにしてください（例：http://localhost:3000/auth/callback）。? や # のあとに続く長い文字には、ログインの情報が入っていることがあります。人にもAIにも渡さないでください。スクリーンショットを渡すときも、アドレスの欄が写らないようにしてください。ほかの人に試してもらってアドレスを教えてもらうときも、同じことを伝えてください。

場所1：ログインのサービス（Supabase など）の設定

Supabase の場合は、管理画面のログインの設定（Authentication の「URL Configuration」）に、戻り先の設定が2つあります。

• Site URL：コードが戻り先を指定していないときに使われる、既定の戻り先です。初期値は http://localhost:3000 です。本番のトップのアドレスに変えます。
• Redirect URLs：戻り先として許すアドレスの一覧です。本番のコールバック URLを、正確に入れます（例：https://（本番のアドレス）/auth/callback）。コードが指定した戻り先がこの一覧にないと、その指定が使われず、Site URL に戻ることがあります。

コールバック URLは、アプリによって違います。分からないときは、AIに「このアプリで、ログインのあとに戻ってくるコールバック URLは何ですか」と聞いてください。

Supabase のプロジェクトが1つで、手元の開発と本番の両方で使っている場合（分けた覚えがなければ、こちらです）は、Site URL を本番のアドレスにしたうえで、Redirect URLs に localhost のコールバック URL（例：http://localhost:3000/auth/callback）も入れておきます。一覧になければ足し、あれば消さずに残します（ないと、手元の開発でログインしたときに、本番のアドレスへ戻ってしまうことがあります）。開発用と本番用にプロジェクトを分けている場合は、本番用のプロジェクトだけを変えます。

ここを変えたあと、手元の開発でログインすると本番のアドレスへ戻るようになったときは、コードが戻り先を指定していないことがあります。5の頼み方で「戻り先を指定していない所」を探し、開いているアドレスに合わせて戻り先を指定する書き方に直してもらってください。

この設定は、管理画面でご自分が変えます。どの画面のどの欄かが分からないときは、画面の名前をAIに伝えて、変える欄を教えてもらってください。参考：Supabase「Redirect URLs」（英語） ↗

場所2：コードの中の戻り先

管理画面の設定を直しても localhost に戻るときは、コードの中に localhost が直接書かれていることがあります。コードを読めなくても、AIに探してもらえます。まず、探すだけを頼みます。

このアプリのコードの中で、ログイン・新規登録・パスワードの再設定のあとの戻り先を決めている所を、全部探してください。localhost や 127.0.0.1 が直接書かれている所、設定の値（環境変数）から読んでいる所、戻り先を指定していない所を分けて、ファイル名と行を一覧にしてください。まだ何も直さないでください。

一覧に「localhost が直接書かれている所」があれば、それが原因の1つです。直す前に、いまの状態を残しておきます（AIに「今の状態を Git に保存して」と頼みます。うまくいかなかったときに戻せます。Git を使っていない場合は、使っているツールに「以前の状態に戻す」機能があるかを、先に確かめてください）。そのうえで、直し方を説明させてから直させます。

一覧にあった localhost の戻り先を、本番でも開発中でも正しく動く書き方に直してください。直す前に、どう直すかと、ほかに影響する所を説明してください。

直し方は、アプリの作りによって変わります。Qz AI Labs の診断の報告の見本（架空のアプリの例）では、「ブラウザーが今開いているアドレスをもとに、戻り先を決める」書き方に直しています。この見本では、管理画面の設定とコードの中の1行の、2か所に localhost が残っていました。設定だけを直しても、コードの行が残るかぎり localhost に戻る例です。

メールで届くリンク（登録の確認・パスワードの再設定）も、同じ戻り先のルールを使います。あわせて一覧に入れてもらってください。

場所3：公開先（Vercel など）に入れた設定の値

アプリによっては、サイトのアドレスを「設定の値（環境変数）」として持っています。NEXT_PUBLIC_SITE_URL のような名前です。手元では localhost を入れ、公開先には本番のアドレスを入れて使い分けます。

公開先にこの値を入れ忘れていたり、localhost のまま入れていたりすると、コードに localhost が書かれていなくても、localhost に戻ります。

1. 5の一覧で「設定の値から読んでいる所」があれば、その名前を控える
2. 公開先の管理画面（Vercel なら「Environment Variables」）で、その名前の値が本番のアドレスになっているかを見る。Vercel では、値ごとに使う場面（Production・Preview・Development）を選ぶので、Production に入っているかも見る
3. 値を入れた・変えたあとは、アプリを公開し直す（Vercel では、変えた値は、そのあとに公開したバージョンにだけ効きます）。終わったら、7の順に確かめる

Supabase の公式の資料にも、サイトのアドレスを設定の値から読み、値がなければ localhost を使う書き方の例が載っています。この書き方のアプリでは、公開先に値が入っていないと localhost に戻ります。参考：Supabase「Redirect URLs」の Vercel の節（英語） ↗ 参考：Vercel「Environment variables」（英語） ↗

設定の値の画面には、シークレット（APIキー・パスワード・トークン・Webhook 署名シークレット・秘密鍵など）も並んでいます。スクリーンショットを人やAIに渡すときは、値を伏せてください。

直ったことを確かめる

コードを変えたときは、まず手元の開発用のアプリで、これまでどおりログインできることを確かめます。そのあと、直したバージョンを本番へ公開し直します（最初に公開したときと同じ方法です。分からないときは、AIに「この変更を本番に公開し直す手順を教えてください」と聞きます）。手元のコードを直しただけでは、本番は前のバージョンのままです。公開が終わったことを確かめてから、次の順に試します。「画面が開いた」で終えず、困っていた操作そのものを、本番のアドレスでやり直します。

1. 手元の開発用のアプリを止める（AIに「開発用のアプリを止めて」と頼みます。または、スマホなど別の端末で試す）。動かしたままだと、localhost に戻っても気づけません
2. 本番のアドレスを開き、ログインしていない状態からログインする（履歴を残さない窓を使うと確実です。Chrome では「シークレットウィンドウ」、Safari では「プライベートブラウズ」、Edge では「InPrivate」という名前です）
3. ログインのあと、アドレスの欄が本番のアドレスのままで、ログインした状態の画面になっている
4. 終わったら、手元の開発用のアプリをもう一度動かし、手元でもログインできることを確かめる
5. 登録の確認やパスワードの再設定のメールを使っていれば、メールのリンクも本番で1回試す

それでも直らないとき

次のようなときは、原因が戻り先のほかにあるか、いくつかの原因が重なっています。

• 3つの場所を確かめても、localhost に戻る
• 4と5を確かめても、本番のアドレスに戻るのに、ログインした状態にならない
• Google の画面でエラーが出て、戻ってこない
• 直したら、別の所が動かなくなった

AIに修正を重ねる前に、次のことをメモにしてください。人に相談するときも、AIに頼み直すときも、このメモがあると話が早く進みます。

• ログインのあとに出たアドレス（? や # より前の部分だけ）と、画面に出た文
• 使っているもの（アプリを作ったAI、ログインのサービス、公開先）
• 手元では動くのか、本番だけで起きるのか
• 確かめた場所と、変えたこと
• AIに直させて、どうなったか（同じ所で止まる、別の所が壊れる、など）

Qz AI Labs のAI製コードの診断と修復は、この症状を扱っています。診断では、テスト用の環境で症状を再現し、原因・直す順番・確定した見積もり・「直った」の定義を報告にまとめます。Qzに頼むか、ご自分で直すかは、報告を見てから決められます。診断は29,800円（税込）から。修復の料金は、直ってからのお支払いです。

報告の形は、診断の報告の見本（架空のアプリの例）で見られます。この記事と同じ「本番でログインすると localhost に戻る」症状の例です。症状の相談は無料です（相談の欄に、コードやシークレットは貼らないでください。症状とエラーの文だけで大丈夫です）。

ログインが直ったら、公開の前後に確かめたい点は「生成AIで作ったアプリの品質チェック：公開前に確かめること」にまとめています。

よくある質問