第三章：台湾で案件を受けるための必須武器：Line Login 開発者バックオフィスの申請と Callback の連携

前章では、Googleログインの攻略に成功しました。しかし台湾、日本、東南アジアのビジネス環境において、LineログインをスキップできるB2C（企業対消費者）プロジェクトはほぼ存在しません。

クライアントは必ずこう要求します：「ユーザーがワンクリックでログインできるようにして、パスワードを覚えさせるな！台湾人は全員スマホにLineを入れているんだから！」 この要求の背後には驚くべきビジネス価値があります：Lineログインでユーザーを誘導できれば、基本情報を取得できるだけでなく、Line公式アカウント（Line Official Account）と直接紐付けられます。紐付けが成功すれば、今後Line Messaging APIを通じて「カスタマイズされたプロモーションメッセージ」をプッシュ通知として送信可能です！これは現代のSaaSプラットフォームが持つ最強のマーケティング武器なのです。

本章では、Line Developersバックオフィスの攻略から、既存のAuth.jsアーキテクチャへのLineログインの統合までを手順を追って解説します。

🟢 ステップ1：Line Developersバックオフィス攻略ガイド

Google Cloud Consoleの企業向けインターフェースとは異なり、Lineのバックオフィスはシンプルですが、多くの落とし穴が潜んでいます。

1. Provider（開発会社/企業名）の作成

  1. LINE Developers Consoleにアクセスし、個人のLineアカウントでログイン
  2. Providers横のCreateボタンをクリック （注：Providerとは「このアプリを開発する会社やチーム名」を意味します。例：VibeTutor Inc.。この名前はユーザーの認証画面に表示されるため、実際の正式な名称を使用してください）

2. LINE Login Channelの作成

1つのProviderの下に複数のChannel（例：1つはLogin用、もう1つはMessaging APIボット用）を作成できます

  1. 作成したProviderをクリックし、**「Create a new channel」**を選択
  2. **「LINE Login」**を選択
  3. 以下の情報を入力：
    • Channel type: LINE Login
    • Provider: VibeTutor Inc.
    • Region to provide the service: TaiwanまたはGlobalを選択
    • Channel icon: 強く推奨（ユーザーへの第一印象となります）
    • Channel name: VibeTutor 公式サイトログインと入力
    • Channel description: 簡単なサービス説明を記入
    • App types: **Web app**にチェック（ネイティブアプリはチェックしない）
  4. 規約に同意し、Createをクリック

3. 認証情報の取得（Channel ID & Secret）

作成後、Channelの概要ページが表示されます Basic settingsタブで下にスクロールすると、2つの極めて重要な情報が確認できます：

  • Channel ID：コピー（OAuthのClient IDに相当）
  • Channel secret：コピー（OAuthのClient Secretに相当）

4. コールバックURLの設定（Callback URL）

前章で学んだように、ユーザーがLineでログインに成功した後、Lineは「認証コード（Auth Code）」をどこに送信するかを知る必要があります

  1. LINE Loginタブに切り替え
  2. Web appセクションで、Callback URL横のEditをクリック
  3. Auth.jsのデフォルトURLを入力： 👉 http://localhost:3000/api/auth/callback/line （🚨 注意：Vercelにデプロイする際は、必ず正式ドメインのURLを追加してください）
  4. Updateをクリックして保存

5. 最終ボス：Channelの公開（Publish）

これは99%の初心者がつまずくポイントです！ ページ上部に**Developing**（開発中）と表示されている状態では、あなたのLineアカウント以外の全ユーザーがログインを試みるとエラー画面が表示されます！

  • Developingタグをクリックし、**Publish**を勇敢に押してください
  • ステータスがPublishedに変われば、ログイン機能が正式に公開されます

📧 ステップ2：Line Email権限の申請（特殊な落とし穴）

Googleと大きく異なる点：Lineはデフォルトでは絶対にユーザーのEmailを提供しません！ 提供されるのはユーザー名（displayName）とプロフィール画像（pictureURL）のみです。

システムでEmailを一意の識別子として必要とする場合（領収書の発行やパスワードリセットなど）、Lineに申請する必要があります。

  1. Basic settingsタブで最下部までスクロール
  2. Email address permissionを探す
  3. ApplyまたはRequestをクリック
  4. サイトのどこかでEmail収集の通知をしているスクリーンショットの提出が要求されます（プライバシーポリシーのスクリーンショットで可）
  5. 審査を提出。通常、正当なアプリケーションであれば高い確率で承認されます

⚠️ Vibe Coding 注意事項： この権限を取得していない状態でAuth.js内でEmailを要求すると、Lineは接続を拒否します！Emailが不要でLine ID（Profile Subject）だけで識別可能な場合は、このステップをスキップできます

💻 ステップ3：Auth.jsへのLine Provider統合

バックオフィスの設定が完了したら、お馴染みのコードの世界に戻りましょう。

1. 環境変数の更新（.env.local）

取得したLineの認証情報を貼り付け：

# 既存のGoogle認証情報...
AUTH_GOOGLE_ID="12345..."
AUTH_GOOGLE_SECRET="GOCSPX-..."

# 新規Line OAuth認証情報の追加
AUTH_LINE_ID="コピーした_Channel_ID"
AUTH_LINE_SECRET="コピーした_Channel_Secret"

2. コア設定ファイルの更新（src/auth.ts）

src/auth.tsを開き、LineProviderを配列に追加します。Auth.jsのアーキテクチャの美しさに感動するでしょう：

import NextAuth from "next-auth"
import GoogleProvider from "next-auth/providers/google"
import LineProvider from "next-auth/providers/line" // Lineをインポート
 
export const { handlers, signIn, signOut, auth } = NextAuth({
  providers: [
    GoogleProvider({
      clientId: process.env.AUTH_GOOGLE_ID,
      clientSecret: process.env.AUTH_GOOGLE_SECRET,
    }),
    LineProvider({
      clientId: process.env.AUTH_LINE_ID,
      clientSecret: process.env.AUTH_LINE_SECRET,
      
      // 🚨 Email権限を申請していない場合、追加のscope要求は絶対にしない
      // デフォルトでは'profile'と'openid'のみ要求
      
      // 🚨 特殊な落とし穴：OIDCの保護機構
      // Auth.js v5以降はOIDC規格を厳格に遵守し、Line APIのstateが互換性問題を起こす場合あり
      // ログイン時にstateエラーが発生した場合、以下の行のコメントを解除：
      // checks: ["state"], 
    }),
  ],
})

3. デュアルログイン画面のテスト！

npm run devサーバーが起動していることを確認 ブラウザでhttp://localhost:3000/api/auth/signinにアクセス

奇跡の瞬間です！シンプルなログイン画面に2つのボタンが表示されます：

  1. Sign in with Google
  2. Sign in with LINE

Lineログインをクリックすると、Lineの緑色の認証画面にリダイレクトされます スマホでアクセスした場合、Lineアプリが自動的に開き、パスワードなしで認証可能！認証後、localhost���戻ります

🤝 ビジネス応用問題：Account Linking（アカウント連携）の課題

複数のログイン方式を提供する場合、アーキテクチャとして避けて通れない難しいビジネスロジックに直面します：

シナリオ： Aさんは昨日ming@gmail.comで「Googleでログイン」し、あなたのサイトで講座を購入 今日、Aさんは別のスマホを使い、昨日のログイン方法を忘れて「Lineでログイン」を選択 たまたま、AさんのLineもming@gmail.comに紐付けられていた

問題： システムはこれらを「同一人物」とみなすべきか、「別人」とみなすべきか？

  • 別人と判断した場合、Aさんは購入した講座が見えず激怒
  • 自動的に統合した場合、セキュリティリスク（メールアドレスの偽造など）が発生

この問題は業界で**Account Linking（アカウント連携）**として知られています。

幸い、私たちが使用するSupabase Adapterアーキテクチャでは、デフォルトの動作は： 「異なるProviderでも同じEmailの場合、アカウント乗っ取り攻撃を防ぐため、ユーザーが明示的に同意しない限り自動統合しない」 このような複雑なAccount Linkingを処理するには、強力なリレーショナルデータベースが必要です。これが次章のテーマ：Cookie Sessionを捨て、Supabase PostgreSQLデータベースとのAdapter連携実践です！

完全なチュートリアルをロック解除

このチャプターは有料コンテンツです。プロジェクトに参加して、10以上の神レベルのPromptや実際のソースコード例を含む、5000字以上の深い分析をロック解除してください！

💳 支払いプランを見る (NT$ 1999)すでに購入済みですか？ここをクリックしてログイン