第2章：Auth.js 初期設定、Google Developer Console 申請と環境変数設定

理論編が終わり、いよいよ実践に入ります！ビジネス開発において、サードパーティログインの実装で最も難しいのは「コーディング」ではなく、「GoogleやFacebook、Lineなどの巨大テック企業が提供する複雑で頻繁に改訂される開発者向け管理画面を突破すること」です。

この章では、Google Cloud Consoleの突破方法をステップバイステップで丁寧に解説します。「どうすればいいか」だけでなく、「なぜこの情報を入力する必要があるのか」も詳しく説明するので、将来Googleのインターフェースが変更されても、核心的なロジックを理解できるようになります。

🛠️ ステップ1：プロジェクトのセットアップと依存パッケージの準備

まず、Next.js 14+ (App Router) のプロジェクトが既に構築されていることを確認してください。ターミナルを開き、プロジェクトのルートディレクトリで以下のコマンドを実行します：

# 最新版のAuth.jsをインストール（現在はApp Routerの新機能をサポートするためbeta版）
npm install next-auth@beta

これで認証のコアパッケージがインストールされます。betaと記載されていますが、本番環境でも十分に安定しており、Vercel公式から強く推奨されています。

解読不可能なAuth Secretの生成

Auth.jsは、すべてのセッションCookieとJWTを強力に暗号化するための「鍵（Secret）」を必要とします。この鍵がない場合、または123456のような単純な鍵だと、ハッカーが簡単にログイン認証情報を偽造できます。

ターミナルで次のコマンドを実行します：

npx auth secret

この小さなプログラムは、32バイトのランダムなハッシュ値を自動生成し、プロジェクトルートの.env.localファイルに自動追加します。

.env.localを開くと、次のような行が追加されているはずです：

AUTH_SECRET="Jk9z8H/yT7xM4+qR1pW2vN6bL3jX5cD8eF0gA9hI4Kk="

⚠️ ビジネスセキュリティ警告：このAUTH_SECRETはあなたのウェブサイトの「生命線」です。絶対に.env.localをGitHubにコミットしないでください（.gitignoreが機能していることを確認）。この鍵が漏洩すると、ハッカーが管理者権限を持つTokenを自分で発行してシステムにログインできてしまいます！

🌐 ステップ2：Google Cloud Consoleで認証情報を申請

ここが多くの初心者が3日間詰まるポイントです。Googleの管理画面は宇宙で最も複雑な企業向けに設計されているため、オプションが多すぎて圧倒されます。以下の手順に厳密に従ってください：

1. GCPプロジェクトの作成（Google Cloud Project）

Google Cloud Consoleにアクセスし、Googleアカウントでログインします。
左上のプロジェクトドロップダウンをクリックし、**「新しいプロジェクト（New Project）」**を選択します。
プロジェクト名にVibeTutor-Auth-System（任意に変更可）と入力し、作成をクリックします。
右上の通知ベルに作成完了が表示されるまで待ち、必ず新しく作成したプロジェクトを選択します。

2. OAuth同意画面の設定（OAuth Consent Screen）

Googleはプライバシーを非常に重視しています。ユーザーがログインをクリックすると、Googleは「VibeTutorがあなたのデータを取得しようとしています！同意しますか？」というポップアップを表示します。このポップアップ画面を設計します。

左側のハンバーガーメニューから 「APIとサービス（APIs & Services）」 > **「OAuth同意画面（OAuth Consent Screen）」**に移動します。
ユーザータイプ（User Type）：**「外部（External）」**を選択します。 （注：内部（Internal）はGoogle Workspaceの企業ドメイン内の従業員のみが使用できます）
**作成（Create）**をクリックします。

詳細情報の入力ページに進みます：

アプリ名（App name）：VibeTutor 知識有料プラットフォームと入力します。これはエンドユーザーに直接表示されます。
ユーザーサポートメール：自分のメールアドレスを選択します。
アプリロゴ（App logo）：（任意）ビジネスプロジェクトではロゴをアップロードすることを強く推奨します。これによりログイン画面がプロフェッショナルで信頼できる印象になります。
承認済みドメイン（Authorized domains）：ローカル開発時は空欄のままにします。本番環境では正式なドメイン（例：vibe-tutor.com）を入力する必要があります。
開発者連絡先情報：自分のメールアドレスを入力します。

次の**スコープ（Scopes）**ステップ：スコープとは、ユーザーから「どのくらいのデータ」を取得するかを指定します。デフォルトでは.../auth/userinfo.emailと.../auth/userinfo.profileのみ必要です。保存して次へをクリックします。

最後の**テストユーザー（Test users）**ステップ：アプリケーションが「テスト段階（Testing）」にある間は、ここに追加されたメールアドレスのみがログインできます！ 👉 必ず自分自身とクライアントのGmailアカウントを追加してください。追加しないとテスト時にAccess Deniedエラーが発生します。

3. OAuthクライアントIDとシークレットの作成

同意画面の設定が完了したら、最も重要な鍵（Client IDとClient Secret）を取得します。

左側のナビゲーションバーから **「認証情報（Credentials）」**をクリックします。
画面上部の **「+ 認証情報を作成（CREATE CREDENTIALS）」をクリックし、「OAuthクライアントID（OAuth client ID）」**を選択します。
アプリケーションタイプ（Application type）：**「ウェブアプリケーション（Web application）」**を選択します。
名前をVibeTutor Next.js Web Clientと入力します。

次に最も重要で、間違いやすい2つのURL設定です：

【承認済みのJavaScript生成元（Authorized JavaScript origins）】 これはあなたのウェブサイトのURLを指定します。GoogleはこれらのURLからのみログインリクエストを許可します。

「URIを追加」をクリックし、http://localhost:3000と入力します。

【承認済みのリダイレクトURI（Authorized redirect URIs）】 第1章のフローチャートを思い出してください。ユーザーがGoogleでログインに成功すると、Googleは「認証コード（Authorization Code）」をあなたのサーバーに返送します。GoogleはこのコードをどのURLに送信するかを知る必要があります。そうでないと、ハッカーが自分のサーバーに認証コードを送信させることができてしまいます。これがCallback URLです。

「URIを追加」をクリックし、Auth.jsが規定する固定パスを入力します： 👉 http://localhost:3000/api/auth/callback/google

🚨 よくあるデバッグの落とし穴（Troubleshooting）：

localhostの前には必ずhttp://を付けます（ローカルでSSL証明書を発行している場合を除き、https://は絶対に使用しません）。

URLの最後にスラッシュ/を絶対に付けません。

将来Vercelにデプロイする際は、この画面に戻ってhttps://vibe-tutor.comを追加する必要があります。追加しないと本番環境のログインが確実に失敗します！

設定が完了したら、「作成」をクリックします。画面にポップアップが表示され、**クライアントID（Client ID）とクライアントシークレット（Client Secret）**が表示されます。これらをコピーしてください。

💻 ステップ3：環境変数の設定とNextAuthのコア設定

コードエディタに戻ります。.env.localを開き、Googleから取得した2つの重要な情報を貼り付けます：

AUTH_SECRET="Jk9z8H/yT7xM4+qR1pW2vN6bL3jX5cD8eF0gA9hI4Kk="

# Google OAuth認証情報
AUTH_GOOGLE_ID="123456789-abcde.apps.googleusercontent.com"
AUTH_GOOGLE_SECRET="GOCSPX-xxxxxx_yyyyyy_zzzzzz"

auth.tsコア設定ファイルの作成

Next.jsプロジェクトのsrcディレクトリ下（srcディレクトリを使用していない場合はプロジェクトルート下）に、auth.tsという名前のファイルを作成します。このファイルはAuth.js v5で設定を一元管理するためのものです。

// src/auth.ts
import NextAuth from "next-auth"
import GoogleProvider from "next-auth/providers/google"
 
export const { 
  handlers, // GET/POSTルートを処理
  signIn,   // ログインメソッド
  signOut,  // ログアウトメソッド
  auth      // 現在のセッション状態を取得する万能関数
} = NextAuth({
  // サポートするサードパーティログインプロバイダーの設定
  providers: [
    GoogleProvider({
      clientId: process.env.AUTH_GOOGLE_ID,
      clientSecret: process.env.AUTH_GOOGLE_SECRET,
      // オプション：毎回アカウント選択画面を強制表示する場合
      // authorization: { params: { prompt: "consent" } },
    }),
  ],
  // その他の高度な設定（後の章で使用）
  // pages: { signIn: '/login' } 
})

🧠アーキテクチャの深い解説：なぜこのauth.tsファイルを作成するのでしょうか？Auth.js v4では設定ファイルがAPI Route内に記述されていたため、Server Componentsで設定を再利用するのが困難でした。v5では設定をすべて分離し、signIn、signOut、authという3つの魔法の関数を生成します。これにより、「フロントエンドコンポーネント、バックエンドAPI、Middleware」など、プロジェクトの「どこからでも」簡単に呼び出せるようになります。

API Route（Route Handler）の作成

Googleがデータを返送する際、Next.jsはそれを受け取る「エンドポイント」が必要です。次のディレクトリ構造とファイルを作成します：src/app/api/auth/[...nextauth]/route.ts。

注：[...nextauth]はNext.jsのCatch-all動的ルート構文です。これにより、/api/auth/signin、/api/auth/callback/google、/api/auth/signoutなどのすべてのリクエストがこのファイルで処理されます。

このファイルに次のコードを記述します：

// src/app/api/auth/[...nextauth]/route.ts
import { handlers } from "@/auth"

// auth.tsからhandlersをインポートし、GETとPOSTルートとしてエクスポート
export const { GET, POST } = handlers

たったこれだけの2行です！fetchを書く必要も、switch-caseでルートを判別する必要もありません。Auth.jsは内部ですべてのOAuthの複雑な流れとToken検証ロジックをこの2行にカプセル化しています。

🎉 ステップ4：成果の確認とデバッグ実践

奇跡を目の当たりにする準備はできましたか？

ターミナルでnpm run devを実行し、開発サーバーを起動します。
ブラウザを開き、アドレスバーに直接入力します： 👉 http://localhost:3000/api/auth/signin

Auth.jsが自動生成するシンプルなログイン画面が表示され、白色の**「Sign in with Google」**ボタンが表示されます。

深呼吸して、このボタンをクリックしてください。設定がすべて正しければ：

Googleのアカウント選択ページにリダイレクトされます。
アドレスバーにはclient_id=...を含む長いGoogle認証URLが表示されます。
Googleアカウントを選択すると、画面が一瞬切り替わり、http://localhost:3000に戻ります。

🚨 よくあるエラーと究極の解決ガイド（Troubleshooting）

現実世界では、最初の設定で成功する人は約10%しかいません。赤いエラーメッセージが表示された場合は、以下の解決策を参照してください：

エラー1：`Error: redirect_uri_mismatch`（Google画面に表示）

原因：localhostに変なポート番号が付いているか、Google Consoleで設定したCallback URLのタイプミスです。
解決策：Google Cloud Consoleの「認証情報」ページに戻り、「承認済みのリダイレクトURI」が一字一句http://localhost:3000/api/auth/callback/googleと一致しているか確認します。変更した場合は、Googleサーバーが同期するまで5分待ちます。

エラー2：`Access Denied (403)`（Google画面に表示）

原因：OAuthアプリケーションの状態が「テスト中（Testing）」で、ログインに使用したGmailアカウントが**「テストユーザー（Test users）」**リストに追加されていません。
解決策：Google OAuth同意画面の設定ページに戻り、自分のメールアドレスをテストユーザーに追加します。

エラー3：ボタンをクリックするとページがクラッシュし、ターミナルに`MissingSecret`と表示される

原因：.env.localにAUTH_SECRETが設定されていないか、環境変数を変更した後にNext.jsサーバーを再起動していません。
解決策：.env.localの内容を確認し、ターミナルでCtrl+Cを押してサーバーを終了し、npm run devを再実行します。

本章のまとめ

おめでとうございます！宇宙で最も面倒な「開発者認証情報の作成」関門を突破し、Next.jsプロジェクトにAuth.jsエンジンを搭載し、Googleログインを実装することに成功しました。

しかし、Googleログインだけでは不十分です。台湾でのビジネス開発では、クライアントからの次の要望は間違いなく「Lineログインを追加して」です。次の章では、より閉鎖的で挑戦的なLine Developersの管理画面を探索し、同じシステムで複数のサードパーティログイン機構をエレガントに共存させる方法を学びます。