会社情報
採用情報
お問い合わせ
Article

ソーシャルログイン実装事例：UX向上でユーザー登録率が大幅改善

高田晃太郎
ソーシャルログイン実装事例：UX向上でユーザー登録率が大幅改善

新規登録フローの離脱要因の約24%が「アカウント作成の強制」という指摘は、ECのカート離脱調査で広く報告されており、Baymard等の知見でも「アカウント作成は確認画面まで遅らせる」ことが推奨されています。特に「アカウント作成を強制された」ことが離脱理由の約24%を占めるという業界調査のまとめがあり¹²。さらに、複数のベンダー調査ではソーシャルログイン導入により登録（サインアップ）完了率が10〜50%改善する可能性が示されています³⁴。本稿では、公開知見をベースにした再現性の高い「実装事例（構成例）」として、OAuth 2.1/OIDC（OpenID Connect）、PKCE（認可コード横取り対策の拡張）、アカウント連携設計、計測基盤までを一気通貫で示し、CTOやエンジニアリーダーが意思決定に使える粒度で整理します。特定の自社実績や未公開数値には依拠せず、一般化可能な手順と注意点に絞って解説します。

事例の背景と課題定義：摩擦の正体を分解する

対象はモバイル比率が高いtoCサービスを想定します。従来フローがメールアドレスとパスワードの入力、メール検証、同意確認という直列構成だと、p95の登録時間が長引き、モバイルSafariではメールアプリ遷移後に復帰できず離脱するケースが目立ちがちです。行動ログを精査すると、入力開始から検証メール送信までの遅延、メールアプリ移動に伴うセッション喪失、弱いパスワードに対するバリデーション再試行が主要な摩擦として観測されます。これらは个々に対策可能ですが、根本にはユーザーがすでに持つアイデンティティ（Google/Apple/LINE等）を再入力させる冗長さがあります。ソーシャルログインは、その冗長さをIdP（Identity Provider）に委譲し、同意と属性取得を短距離で完了させる設計です。ただし、導線追加による選択肢過多や、アカウント重複、プライバシー懸念が新たなリスクとして現れます。そこで、実装ではOAuth/OIDCによる標準化、PKCE + stateの厳格運用、メール登録との安全な併存、アカウント連携テーブルによる統合、そして計測イベントの正規化を同時に進めるのが有効です。

実装アーキテクチャと技術選定：OIDC準拠と拡張性

WebはNext.js、APIはNode.js、アイデンティティはGoogle、Apple、LINEを採用する構成例を示します。ブラウザのサードパーティクッキー制限やIETFの最新動向を踏まえ、暗黙フローは用いず、すべてAuthorization Code with PKCEを採択します（アクセストークンの露出を避け、モバイル/ITP環境でも安定しやすい）。フロントはリダイレクト方式を基本に、Google One Tapは条件に応じて遅延読み込みし、同意率の低下を避けます。アカウント連携はusersとidentitiesの二層構成で、一意制約とインデックスにより重複を回避します。以下に主要なコードを示します。

NextAuth（Next.js）によるマルチIdP構成

// pages/api/auth/[...nextauth].ts
import NextAuth, { NextAuthOptions } from "next-auth";
import GoogleProvider from "next-auth/providers/google";
import AppleProvider from "next-auth/providers/apple";
import LineProvider from "next-auth/providers/line";
import { PrismaAdapter } from "@next-auth/prisma-adapter";
import { prisma } from "../../../server/prisma";

export const authOptions: NextAuthOptions = {
  adapter: PrismaAdapter(prisma),
  session: { strategy: "jwt", maxAge: 60 * 60 * 24 * 30 },
  providers: [
    GoogleProvider({
      clientId: process.env.GOOGLE_CLIENT_ID!,
      clientSecret: process.env.GOOGLE_CLIENT_SECRET!,
      authorization: { params: { prompt: "consent", access_type: "offline", response_type: "code" } },
    }),
    AppleProvider({
      clientId: process.env.APPLE_CLIENT_ID!,
      clientSecret: process.env.APPLE_CLIENT_SECRET!,
      authorization: { params: { response_mode: "form_post", response_type: "code" } },
    }),
    LineProvider({
      clientId: process.env.LINE_CLIENT_ID!,
      clientSecret: process.env.LINE_CLIENT_SECRET!,
      checks: ["pkce", "state"],
    }),
  ],
  callbacks: {
    async signIn({ user, account, profile }) {
      // 業務要件に応じたドメイン制御など
      return true;
    },
    async jwt({ token, account }) {
      if (account?.access_token) token.at = account.access_token;
      return token;
    },
    async session({ session, token }) {
      (session as any).at = token.at;
      return session;
    },
  },
};

export default NextAuth(authOptions);

Express + PassportでのGoogle実装とエラーハンドリング

// app.js
import express from "express";
import session from "express-session";
import passport from "passport";
import { Strategy as GoogleStrategy } from "passport-google-oauth20";

passport.use(new GoogleStrategy({
  clientID: process.env.GOOGLE_CLIENT_ID,
  clientSecret: process.env.GOOGLE_CLIENT_SECRET,
  callbackURL: "/auth/google/callback",
}, async (accessToken, refreshToken, profile, done) => {
  try {
    const user = await upsertUserFromGoogle(profile);
    return done(null, user);
  } catch (e) {
    return done(e);
  }
}));

passport.serializeUser((user, done) => done(null, user.id));
passport.deserializeUser(async (id, done) => {
  try { const user = await findUserById(id); done(null, user); } catch (e) { done(e); }
});

const app = express();
app.use(session({ secret: process.env.SESSION_SECRET, resave: false, saveUninitialized: false }));
app.use(passport.initialize());
app.use(passport.session());

app.get("/auth/google", passport.authenticate("google", { scope: ["openid", "email", "profile"] }));

app.get("/auth/google/callback", (req, res, next) => {
  passport.authenticate("google", (err, user) => {
    if (err) return res.status(500).send("Auth Error");
    if (!user) return res.redirect("/login?error=denied");
    req.logIn(user, (e) => {
      if (e) return res.status(500).send("Session Error");
      return res.redirect("/welcome");
    });
  })(req, res, next);
});

export default app;

アカウント連携スキーマ：重複と切替を正しく扱う

-- PostgreSQL
CREATE TABLE users (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  email TEXT UNIQUE,
  display_name TEXT,
  created_at TIMESTAMPTZ DEFAULT now()
);

CREATE TABLE identities (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id UUID NOT NULL REFERENCES users(id) ON DELETE CASCADE,
  provider TEXT NOT NULL,
  provider_user_id TEXT NOT NULL,
  email TEXT,
  created_at TIMESTAMPTZ DEFAULT now(),
  UNIQUE (provider, provider_user_id)
);

CREATE INDEX idx_identities_user ON identities(user_id);

フロントのログインボタンと遷移管理

// components/SocialButtons.tsx
import React from "react";

export function SocialButtons() {
  const redirect = new URLSearchParams({ callbackUrl: "/welcome" }).toString();
  const go = (p: string) => () => { window.location.href = `/api/auth/signin/${p}?` + redirect; };
  return (
    <div>
      <button onClick={go("google")} aria-label="Sign in with Google">Googleで続ける</button>
      <button onClick={go("apple")} aria-label="Sign in with Apple">Appleで続ける</button>
      <button onClick={go("line")} aria-label="Sign in with LINE">LINEで続ける</button>
    </div>
  );
}

Cloudflare Workersでのトークン交換とPKCE検証

// src/worker.ts
export default {
  async fetch(req: Request, env: any): Promise<Response> {
    try {
      const url = new URL(req.url);
      if (url.pathname !== "/oauth/callback") return new Response("Not Found", { status: 404 });
      const code = url.searchParams.get("code");
      const state = url.searchParams.get("state");
      const verifier = await env.SESSION.get(`pkce:${state}`);
      if (!code || !state || !verifier) return new Response("Invalid request", { status: 400 });
      const body = new URLSearchParams({
        grant_type: "authorization_code",
        code,
        redirect_uri: env.REDIRECT_URI,
        client_id: env.CLIENT_ID,
        code_verifier: verifier,
      });
      const res = await fetch(env.TOKEN_ENDPOINT, { method: "POST", body, headers: { "Content-Type": "application/x-www-form-urlencoded" } });
      if (!res.ok) return new Response("Token error", { status: 502 });
      const token = await res.json();
      await env.SESSION.delete(`pkce:${state}`);
      return new Response(null, { status: 302, headers: { Location: `/welcome#at=${token.access_token}` } });
    } catch (e) {
      return new Response("Server error", { status: 500 });
    }
  }
} satisfies ExportedHandler;

Cookieとセキュリティ属性の強化（Next.js Middleware）

// middleware.ts
import { NextResponse } from "next/server";
import type { NextRequest } from "next/server";

export function middleware(req: NextRequest) {
  const res = NextResponse.next();
  const cookie = req.cookies.get("next-auth.session-token");
  if (cookie) {
    res.cookies.set("next-auth.session-token", cookie.value, {
      httpOnly: true, secure: true, sameSite: "lax", path: "/", maxAge: 60 * 60 * 24 * 30,
    });
  }
  return res;
}

上記の構成により、主要ブラウザのサードパーティクッキー制限下でも動作しやすく、SSOの恩恵を活かしつつセキュアにセッションを確立できます。AppleのプライベートリレーやLINEのメールアドレス非提供パターンにも、identitiesテーブルでのユニーク制約と属性の遅延取得で対応しやすくなります。

UX設計と計測：登録率を上げる具体策

UXの鍵は選択肢の提示タイミングと文言の差です。ソーシャルログインのボタンはファーストビューに置き、色やラベルは各プラットフォームのガイドラインに準拠させながら、説明文では**「数秒で完了」「パスワード不要」といった利益を短く明示します。ユーザーは入力負荷の少ないサインイン・サインアップを好む傾向が各種調査で示されています⁴。メール登録は折りたたみではなく同列に示し、ユーザーの主導性を残します。GoogleのOne Tapは、初回訪問では遅延表示とし、既存ユーザーにだけ即時出現するルールにすると、同意拒否によるバナー疲れを抑制しやすい設計になります。One Tapは公開事例でも主要指標の改善が報告されています⁵。プライバシーの懸念に対しては、取得する属性を最小限に留め、同意文には具体的な利用目的と第三者提供が無いことを明記します。登録後のプロフィール拡充は、初回価値提供の後に行うプログレッシブプロファイリング**とし、早期の長文フォームは避けます。ゲスト（メール）導線を過度に隠さずに提示するのは、チェックアウト研究のベストプラクティスとも整合します⁶。

計測はファネルを正規化し、ページ表示、ボタンクリック、IdP許可、コールバック完了、アカウント作成、初回アクティベーションの各イベントを同一セッションIDで連結します。これにより、どのIdPでどのデバイスがどの段で離脱し、平均に比べてどの程度の遅延があるかを比較できます。実運用では、ボタン配置やラベル、One Tapの対象制御などをA/Bテストで検証し、クリック率・許可率・完了率・タイムトゥサインアップ（登録完了までの時間）を継続的に監視すると、改善ポイントが特定しやすくなります。端末別ではモバイルSafariでの完了率が改善しやすい傾向があり、メールアプリ往復を排除できることが寄与するケースが多いです。詳細なテスト設計やイベント設計は再現可能な形にまとめています。

成果とビジネスインパクト：数値で読み解くROI

ソーシャルログイン導入は、一般に登録完了率の上昇、登録時間の短縮、再ログイン摩擦の低減を通じて、獲得効率（CAC）と継続率（D7、D30）に好影響を与えやすい取り組みです。加えて、パスワード起因の問い合わせ削減や、メール検証に依存しないフローによるメール送信キューの平準化など、運用コストの低減が見込めます。SLOの観点では、認証エンドポイントのp95レイテンシ改善（セッション再利用・リダイレクト短縮・同意UI最適化の複合効果）や、IdP障害時にもメール登録へ自動フォールバックする設計により、エラー率の突発的な悪化を回避しやすくなります。ROI評価は、導入前後のファネル指標とサポート/インフラコストの差分、LTV/CACの推移で定量化すると経営判断に接続しやすいでしょう。国内でも、ソーシャルログイン導入による新規獲得・再ログイン改善の公開事例が複数報告されています⁷。

よくある落とし穴と回避策：安全性と運用の両立

アカウント重複は代表的な落とし穴です。メール登録済みのユーザーが後からソーシャルログインを使った場合、メール一致のみで自動リンクすると他人のメールで誤結合する恐れがあります。そこで、初回は暫定ユーザーで作成し、セッション内で本人性を確認したうえでidentsテーブルに統合する設計が安全です。Appleの匿名化メールでは連絡不能リスクがあり、オンボーディング中に通知チャネルの選好を取ることで顧客接点を確保します。ブラウザ互換性では、ITPやETPの影響でサードパーティクッキーに依存しないフローが前提です。実装ではPKCEとSameSite=Laxのクッキー設定でリダイレクト後のセッション継続性を担保します。モバイルアプリ連携ではユニバーサルリンクとカスタムスキームの両対応が必要で、深いリンクの整合性テストをCIに組み込み、IdPごとのUI変更に備えて監視の合成テストを走らせます。障害時運用も重要で、IdPのステータスが降下した場合には自動でメール登録を最前面に表示し、ソーシャルは後段に退避させるフェイルオープンを採用します。ログにはstate不一致、nonce不一致、コールバック失敗、属性欠落などの主要エラーコードを正規化し、ダッシュボードで発生比率と平均回復時間を追跡します。プライバシーの観点では、取得属性の最小化、利用目的の具体化、撤回の容易性を満たすことで、同意率と信頼の両立が可能です。

まとめ：最小実装から確実に成果へ

ソーシャルログインは魔法ではなく、標準規格とUXの地道な組み合わせです。PKCEとstateでセキュアな骨格を作り、アカウント連携で重複を防ぎ、One Tapや明快な文言で摩擦を削るという手順を踏めば、登録率と登録時間は高い確率で改善が見込めます。まずは一つのIdPから導入し、計測イベントを正規化してA/Bテストを回し、成果が確認できた段階で対応IdPと導線を段階的に拡張すると、リスクを抑えつつ最大の効果を得られます。次に何を計測し、どの摩擦を一つ削るか。今日の登録フローを開いて、最初の改善の一手をチームで決めるところから始めてみてください。

参考文献

  1. Taptool. Social login’s impact on conversion: data, best practices, and vendor options. https://blog.taptool.co/articles/social-login-conversion-impact/ （カート離脱理由として「アカウント作成の強制」が約24%を占める旨の引用を含む）
  2. Baymard Institute. Save Account Creation for the Confirmation Step. https://baymard.com/blog/delayed-account-creation
  3. Auth0. How to Use Social Login to Drive Your App’s Growth. https://auth0.com/blog/how-to-use-social-login-to-drive-your-apps-growth/
  4. LoginRadius. 9 Facts About Social Login and CRO. https://www.loginradius.com/blog/growth/9-facts-about-social-login-and-cro/
  5. Stytch. Improving conversion with Google One Tap. https://stytch.com/blog/improving-conversion-with-google-one-tap/
  6. Baymard Institute. Make ‘Guest Checkout’ Prominent. https://baymard.com/blog/make-guest-checkout-prominent
  7. インキュデータ. ソーシャルログインの基礎知識と導入メリット. https://www.incudata.co.jp/magazine/000178.html