🔐

Supabase + Gemini API + Google認証でアプリを作ってハマったところまとめ

に公開
Next.js
Vercel
Supabase
Gemini
Claude Code
tech

はじめに

Claude Codeを利用して、Next.js + Supabase + Gemini API + Google認証を使ったアプリを作成した際、いくつか詰まったポイントがあったので備忘録としてまとめます。

特に詰まったのは、以下の点です。

  • Gemini API 接続時にエラーが出る（404 / 429 / 503）
  • Googleログイン後に localhost にリダイレクトされる
  • Supabase の Site URL と Redirect URLs の設定で混乱する
  • Google Cloud Console の URI 設定で混乱する

この記事では、実装手順を一から説明するというより、実際に詰まったポイントと、その解消方法をまとめます。

環境

今回の検証環境は以下です。

  • Next.js 16.2.3
  • App Router
  • TypeScript
  • Supabase
  • Gemini API
  • Google OAuth
  • Vercel

※ Next.js アプリを Vercel にデプロイし、Supabase Auth の Google認証と Gemini API を組み合わせた構成で検証しました。

Google認証はどういう流れで動くのか

最初に、Google認証がどう流れるのかをざっくり整理しておきます。

ユーザー
  ↓ Googleでログインを押す
自分のアプリ
  ↓
Supabase
  ↓
Googleで認証
  ↓
Supabaseが結果を受け取る
  ↓
自分のアプリに戻す
  ↓
ログイン完了

Supabaseを利用する利点

Google認証をそのまま扱おうとすると、認証後のセッション管理やユーザー管理も自分で考える必要があります。

Supabase を利用すると、そのあたりをまとめて扱いやすくなります。

  • Google認証後のセッション管理をしやすい
  • アプリ側のユーザー管理とつなげやすい
  • Supabase Auth と RLS を組み合わせることで、ログイン中のユーザー本人のデータだけ触れる設計にしやすい

今回のように、認証だけでなくデータベースも Supabase を使う場合は、特に相性がよいと感じました。

👇 ここからは、実際に詰まったポイントごとに、原因と解消方法をまとめていきます。

Gemini API 接続時にエラーが出る（404 / 429 / 503）

問題

Gemini API でいくつかモデル名を試したところ、次のようなエラーが出ました。

  • gemini-2.5-flash → 503
  • gemini-1.5-flashとgemini-2.0-flash → 404 または 429

gemini-2.5-flash を利用したかったのですが、うまくいかず、Claude Code の提案に沿ってモデルを何度か切り替えながら試していました。

解消

最終的には、課金を有効にした上で gemini-2.5-flash を使うことで動作しました。
また、503 はサーバー混雑による一時的なエラーと考え、再試行前提で扱うようにしました。

原因

少なくとも自分の環境では、課金未設定が一因でした。
また、公式を確認するとgemini-1.5-flash は廃止されたモデルに分類されていました。

エラーごとの可能性：

  • 404 は、そのモデル名が存在しない、使えない、提供終了している、API バージョンが合っていない、などの可能性
  • 429 は、利用回数や無料枠などの上限に引っかかっている可能性
  • 503 は、サーバー側が一時的に混雑している可能性

Gemini API を使う場合は、毎回必ず成功する前提ではなく、再試行やエラーハンドリングを考えておいた方が安心です。

Googleログイン後に localhost にリダイレクトされる

問題

本番環境（Vercel）で Google ログインしたのに、ログイン後に localhost:3000/?code=xxx のような URL にリダイレクトされてしまいました。

本番環境の URL から認証しているのに localhost に戻されるため、最初は Google Cloud Console 側の設定ミスかと思いました。

解消

Supabase の Authentication → URL Configuration → Site URL を確認したところ、http://localhost:3000 のままになっていました。
これを Vercel の本番ドメイン に変更することで解決しました。

原因

Site URL は、Supabase における既定の戻り先です。
そのため、ここが localhost のままだと、本番環境で認証していても localhost に戻そうとすることがあります。

OAuth 周りで「本番環境なのに localhost に戻される」という挙動が出たときは、まず Site URL を確認すると切り分けしやすいです。

Supabase の Site URL と Redirect URLs の設定で混乱する

問題

Supabase には Site URL （上記に記載）と Redirect URLs という似た設定項目があり、最初はどちらに何を書けばよいのか分かりにくかったです。

解消

次のように整理すると分かりやすくなりました。

  • Site URL
    既定の戻り先
  • Redirect URLs
    認証後に戻してよい URL の許可リスト

今回の本番環境では、Redirect URLs に以下を追加しました。

https://your-vercel-domain.vercel.app/auth/callback

原因

Site URL と Redirect URLs の違いがあいまいなままだと、「本番URLをどこに書くべきか」「callback URL はどこに追加するべきか」で迷いやすいです。

今回は本番環境のみで利用したかったため、localhost:3000/auth/callback は削除しました。

Google Cloud Console の URI 設定で混乱する

問題

Google Cloud Console には 承認済みのリダイレクト URI と 承認済みの JavaScript 生成元 という設定があり、最初はどちらに何を書けばよいのか分かりにくかったです。

特に、本番環境で利用している Vercel の URL を、どちらに設定するべきかで混乱しました。

解消

最終的には、次のように設定しました。

  • 承認済みのリダイレクト URI
    https://<プロジェクトref>.supabase.co/auth/v1/callback
  • 承認済みの JavaScript 生成元
    https://your-vercel-domain.vercel.app

原因

Google から認証結果を直接受け取るのは自分のアプリではなく、Supabase だからです。

そのため、

  • Google → Supabase に認証結果を返す URL
    → Google Cloud Console の 承認済みのリダイレクト URI

  • 自分のアプリのドメイン
    → Google Cloud Console の 承認済みの JavaScript 生成元
    💡 そのドメイン上のフロントエンドから Google OAuth / API を利用してよいと許可する設定

という役割になります。

まとめ

Google認証まわりは、設定項目が多くて混乱しましたが、Google → Supabase → 自分のアプリ という流れで整理するとかなり理解しやすくなりました。

また、Gemini API についても、モデル名や課金設定、エラーコードの違いを切り分けて考えることが大事だと感じました。

同じように詰まっている方の参考になればうれしいです。

GitHubで編集を提案

Discussion