管理画面フォーマット開発編 #3
AuthProviderでログイン済みユーザー情報を全体共有

ログイン成功直後に取得したユーザー情報をAuthProvider（Client Context）でアプリ全体に配布

初回公開日2025/9/12

最終更新日2025/11/6

0. はじめに

今回の記事では、 ログイン済みユーザー情報をアプリ全体で共有する仕組み を構築します。
前回の記事 【管理画面フォーマット開発編 #2】JWT +Cookie＋middlewareで実装するログイン機能 までで「ログイン → Cookie 保存 → middleware で早期蹴り → Server Action 側でセッション検証」という流れを整えましたが、このままでは各ページでユーザー情報を毎回取得する必要があり、効率的ではありません。

そこで本記事では、AuthProvider を導入し、Context API を利用してユーザー情報をグローバルに展開する構成を作ります。これにより、Sidebar やページコンポーネントからシームレスにユーザー情報・ロール情報を利用可能になります。

txt

【処理フローの全体像】

[loginAction] → JWT発行＋User情報返却
        ↓
[AuthProviderServer]（SSRでセッション確認）
        ↓
<AuthProvider>（CSR Context）
        ↓
子コンポーネントから useAuth() で参照

本記事のゴール

まずは記事のゴールを明確にします。今回の実装を終えると、以下が実現できます。

区分	内容
ユーザー情報	名前・メールアドレス・アバター・ロールなどを Context で一元管理
Sidebar制御	ロールごとに表示するメニューを出し分け可能
画面制御	ページ単位で「ADMIN専用」などの RBAC 判定が容易に
効率性	各 page.tsx ごとに DB 問い合わせをせず、Context から即座に参照可能

こうした仕組みによって、UI 側の保守性とユーザー体験の両立を目指します。

管理画面フォーマット開発編の完成形（デモとGithubリポジトリ）

「管理画面フォーマット開発編 #1〜#11」の記事内容についてのデモページです。下記より確認可能です。
管理画面フォーマット開発編の完成版デモ： https://delogs.jp/demo/dashboard-format

Githubにも公開済みです。
管理画面フォーマット開発編のGihubリポジトリ： https://github.com/delogs-jp/dashboard-format-fullstack

技術スタック

Tool / Lib	Version	Purpose
React	19.x	UIの土台。コンポーネント/フックで状態と表示を組み立てる
Next.js	15.x	フルスタックFW。App Router/SSR/SSG、動的ルーティング、メタデータ管理
TypeScript	5.x	型安全・補完・リファクタリング
shadcn/ui	latest	RadixベースのUIキット
Tailwind CSS	4.x	ユーティリティファーストCSSで素早くスタイリング
Zod	4.x	スキーマ定義と実行時バリデーション

本記事では、前回の記事 【管理画面フォーマット開発編 #2】JWT +Cookie＋middlewareで実装するログイン機能 までのソースコードを引き継いで追加・編集していきます。

1. 要件と設計方針

本章では、ログイン済みユーザー情報をアプリ全体で共有 するための要件整理と設計方針を固めます。実装は次章以降で行えるよう、データの粒度・取得タイミング・型インターフェース・データフローを先に明確化します。

共有するデータと共有しないデータ

「常にどこからでも参照したい最小限の情報」と「必要時にだけ取得する詳細情報」を分けます。PII を最低限に抑え、JWT には個人情報を載せない 前提を維持します。

区分	キー	例	共有可否	取得先
ユーザー識別	`userId`	`uuid`	共有する（必須）	Session 由来
表示用	`name`	`"山田太郎"`	共有する	`User.name`
表示用	`email`	`"taro@example.com"`	共有する	`User.email`
表示用	`avatarUrl`	`"/user-avatar.png"` or サインドURL	共有する	プロファイル由来
認可	`roleCode`	`"ADMIN" \| "EDITOR" \| "VIEWER"`等	共有する	`Role.code`
認可	`rolePriority`	`100`	共有する	`Role.priority`
変動の大きい詳細	電話番号・住所・権限フラグ群	`phone`, `canEditData` 等	必要時取得	個別 Server Action

取得タイミングの選定

ユーザー情報をいつ Context に載せるかを比較し、下記のうち（A）を採用します。

案	タイミング	長所	注意点
A	ログイン成功直後（`loginAction`）で DB からスナップショットを取得し、クライアントへ返す	初回描画が速い／以降は Context 参照のみ	途中でロール等が変わった場合の再同期フローを用意（後述）
B	各 `page.tsx` の SSR で毎回取得	常に最新	ページ遷移たびに DB 負荷／同じ取得を繰返す
C	初回ロード時にクライアントで API 叩く	実装が直感的	API 依存・Flicker（無認可瞬間描画）のリスク

データフローの全体像

Context は CSR のみ で保持し、SSR は従来どおりセッションでガード します。SSR/CSR の責務を分けることで、安全かつ高速な体験を両立します。

txt

[loginAction (Server Action)]
  ├─ 認証（Department.code + email + password）
  ├─ Session 作成 → JWT を Cookie に保存
  └─ ★ ユーザースナップショットを返す（name/email/role/...）

       ↓（クライアント側）

<AuthProvider>  ← 受け取ったスナップショットを Context に格納
  ├─ useAuth() で name/role 等を即参照（Sidebar, Header, Pages）
  └─ 必要時は Server Action で詳細情報を追加フェッチ

[SSR page.tsx]
  └─ lookupSessionFromCookie() でアクセスガード（従来どおり）

型定義（最小インターフェース）

ここでは Context に載せる最小集合 の型だけを先に固めます。実装章で AuthProvider を用意し、useAuth() フックから参照できるようにします。

// src/lib/auth/types.ts
export type AuthUserSnapshot = {
  userId: string;
  name: string;
  email: string;
  avatarUrl: string | null;
  roleCode: string; // ← Prisma の Role.code に一致
  rolePriority: number;
};

export type AuthContextValue = {
  ready: boolean; // 初期化済みか
  user: AuthUserSnapshot | null; // 未ログイン時は null
  setUser: (user: AuthUserSnapshot | null) => void; // ログイン／ログアウトなどのクライアント操作から呼べるように
  // 将来用：再同期フロー（ロール変更を反映したい等）
  refresh?: () => Promise<void>;
};

上記は 「Context に置く最小限の形」 を明文化しただけで、まだロジックはありません。AuthProvider 実装時にこの型を使って、受け取ったスナップショットを Context に保存します。refresh は任意（後章で増設予定）です。

データ源：Prisma（リードレプリカ対応）

DB アクセスは、src/lib/database.ts の prisma を単一出所として利用します。リードレプリカが設定されているため、読み取り系はスケール しやすい構成です。

// 例）ユーザースナップショット取得用の共通関数
// src/lib/auth/user-snapshot.ts
import { prisma } from "@/lib/database";
import type { AuthUserSnapshot } from "./types";

/**
 * セッションで得られた userId から、Context 用の最小スナップショットを作る。
 * PII を最小化し、重い JOIN は避け、必要な列だけ select する。
 */
export async function getUserSnapshot(
  userId: string,
): Promise<AuthUserSnapshot | null> {
  const user = await prisma.user.findUnique({
    where: { id: userId },
    select: {
      id: true,
      name: true,
      email: true,
      role: {
        select: { code: true, priority: true },
      },
      // avatar の保存方式は後続章で実装（仮で null）
      // プロダクションではサインドURLや保護ルートを生成して返す
    },
  });

  if (!user || !user.role) return null;

  return {
    userId: user.id,
    name: user.name,
    email: user.email,
    avatarUrl: null, // 後続で実装（/api/avatar/[userId] など）
    roleCode: user.role.code,
    rolePriority: user.role.priority,
  };
}

prisma は src/lib/database.ts から import し、ログやリードレプリカ設定を一元化します。
select で必要列だけを取り、Context に積む情報を最小化。
アバターは「直リンク禁止・Next.js 経由で認可配信」という方針に沿い、後続章で安全な URL を発行します。ここでは null を返す仮仕様にしています。

ルーティングとガードの整理

SSR 側のページ保護はこれまでどおり lookupSessionFromCookie() → redirect("/") の流れを維持します。Context は CSR で保持するため、SSR/CSR の責務が混ざらない点が重要です。

txt

SSR（page.tsx）            CSR（AuthProvider / useAuth）
┌──────────────────┐      ┌──────────────────────────────┐
│ lookupSession... │      │ 受け取ったスナップショットを  │
│  └ redirect("/") │      │ Context に保持（最小集合）     │
└──────────────────┘      └──────────────────────────────┘

※ SSR の可否（入場権）はセッションで判定、
  表示のための軽量情報は CSR の Context から即参照。

この章のまとめ

Context に置くのは最小限の「表示/認可用スナップショット」。
取得タイミングは「ログイン成功直後」（方針 A）を採用。
SSR は従来どおりセッションでガード し、CSR の Context は体験向上 に寄与。
DB アクセスは src/lib/database.ts の 単一出所 prisma を使い、select 最小化 で負荷と漏洩リスクを下げる。

次章では、この方針に沿って AuthProvider と useAuth() を実装 し、loginAction から返すスナップショットを受け取って Context を初期化するところまでを組み立てます。

2. AuthProvider と useAuth の実装

本章では、前章で整理した要件に基づき、Context を実際に構築するための AuthProvider と useAuth フック を実装します。
これにより、アプリ全体から「ログイン済みユーザーのスナップショット」を簡単に参照できるようになります。

AuthProvider の責務

まずは AuthProvider が担う責務を整理します。

責務	説明
初期化	ログイン成功時にサーバから受け取ったユーザースナップショットを Context に格納
提供	`useAuth()` フックを通じて、子コンポーネントから即座に参照可能にする

これにより、Sidebar や Header、各ページコンポーネントから useAuth() を呼ぶだけでユーザー名やロールを表示できるようになります。

ディレクトリ構成

Auth 関連の Context は以下のように整理します。

txt

src/
├─ lib/
│  └─ auth/
│     ├─ types.ts           # AuthUserSnapshot / AuthContextValue
│     ├─ user-snapshot.ts   # DBから最小スナップショット取得
│     └─ context.tsx        # AuthProvider / useAuth

Context 実装

次に、Context と Provider を用意します。

tsx

// src/lib/auth/context.tsx
"use client";

import { createContext, useContext, useState, useEffect } from "react";
import type { AuthContextValue, AuthUserSnapshot } from "./types";

const AuthContext = createContext<AuthContextValue>({
  ready: false,
  user: null,
  setUser: () => {}, // デフォルトno-op
});

export function AuthProvider({
  initialUser,
  children,
}: {
  initialUser: AuthUserSnapshot | null;
  children: React.ReactNode;
}) {
  const [user, setUser] = useState<AuthUserSnapshot | null>(initialUser);
  const [ready, setReady] = useState(false);

  useEffect(() => {
    // 初期化完了フラグを立てる
    setReady(true);
  }, []);

  const value: AuthContextValue = {
    ready,
    user,
    setUser,
    refresh: async () => {
      // 将来: /_actions/auth/refresh などから再取得する仕組みを実装予定
      setUser(user);
    },
  };

  return <AuthContext.Provider value={value}>{children}</AuthContext.Provider>;
}

export function useAuth() {
  return useContext(AuthContext);
}

AuthProvider はログイン時に受け取った initialUser を Context に格納します。
useAuth() フックでいつでも Context の値にアクセス可能になります。
refresh は将来的な拡張用で、例えば「管理者がロールを変更した後、即時反映したい」といったケースに利用できます。

SSR と CSR の接続

AuthProvider 単体では CSR に限定されます。
そこで、SSR 側でセッションを確認し、ユーザースナップショットを取得してから AuthProvider に渡す仕組みを追加します。

txt

[SSR page.tsx]
   └─ lookupSessionFromCookie() で有効な userId を判定
        ↓
[getUserSnapshot()] で DB から最小情報を取得
        ↓
<AuthProvider initialUser={snapshot}> に渡して CSR へ展開

Server Wrapper の実装

サーバ側でセッション確認を行い、スナップショットを取得してから CSR の AuthProvider を呼び出すラッパーを作ります。

tsx

// src/lib/auth/provider-server.tsx
import { lookupSessionFromCookie } from "./session";
import { getUserSnapshot } from "./user-snapshot";
import { AuthProvider } from "./context";

export async function AuthProviderServer({
  children,
}: {
  children: React.ReactNode;
}) {
  const session = await lookupSessionFromCookie();
  if (!session.ok) {
    return <AuthProvider initialUser={null}>{children}</AuthProvider>;
  }

  const snapshot = await getUserSnapshot(session.userId);
  return <AuthProvider initialUser={snapshot}>{children}</AuthProvider>;
}

SSR 側で lookupSessionFromCookie() を呼び、無効なら initialUser = null を渡します。
有効なら getUserSnapshot() を呼び出して最小限の情報を取得し、AuthProvider に渡します。
これにより、CSR 側で初期レンダリング時から useAuth() が正しい情報を参照できます。

ProtectedLayout への組み込み

既存の src/app/(protected)/layout.tsx に AuthProviderServer を挟み込みます。

tsx

// src/app/(protected)/layout.tsx
import { AppSidebar } from "@/components/sidebar/app-sidebar";
import { SidebarProvider, SidebarInset } from "@/components/ui/sidebar";
import { Toaster } from "@/components/ui/sonner";
import { AuthProviderServer } from "@/lib/auth/provider-server";

export default function ProtectedLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return (
    <SidebarProvider>
      <AuthProviderServer>
        <AppSidebar />
        <SidebarInset className="min-w-0">
          {/* サイドバー/ヘッダ/パンくずは“各 page.tsx”で自由に */}
          {children}
          <Toaster richColors closeButton />
        </SidebarInset>
      </AuthProviderServer>
    </SidebarProvider>
  );
}

(protected) 配下のすべてのページは、ログイン済みユーザー情報を useAuth() 経由で参照可能になります。
SSR 側は従来どおり lookupSessionFromCookie() によるガードを維持しますが、CSR 側は AuthContext による即時参照が可能になります。

この章のまとめ

AuthProvider と useAuth を実装し、Context API でユーザー情報を共有できるようにした。
SSR 側でセッション確認を行い、スナップショットを取得する AuthProviderServer を用意。
(protected)/layout.tsx に組み込むことで、アプリ全体から useAuth() でログイン済み情報を利用可能にした。

次章では、loginAction を改修し、ログイン成功時にユーザースナップショットを返す処理を実装します。

3. loginAction の改修 ─ スナップショット返却

本章では、既存の loginAction を改修し、 ログイン成功時にユーザースナップショットを返す ようにします。
これにより、ログイン直後に AuthProvider が初期化できるようになり、全ページから即時にユーザー情報を参照できるようになります。

変更点の整理

従来の loginAction では「セッション作成 → JWT を Cookie に保存 → ダッシュボードにリダイレクト」という流れでした。
今回の改修では、以下の点を追加します。

区分	従来	改修後
セッション作成	DB に Session を保存	同じ
JWT 保存	Cookie に保存	同じ
レスポンス	リダイレクトのみ	ユーザースナップショットも返す

これにより、クライアント側はログイン成功直後にユーザー情報を Context に流し込み可能となります。

loginAction の改修

loginAction を改修します。前章で実装した getUserSnapshot() をここで利用します。
セッション作成後に呼び出すことで、DB から最小限のユーザー情報を取得できます。改修後は、戻り値に { ok: true, user: snapshot } を含めるようにします。

tsx

// src/app/_actions/auth/login.ts
"use server";

import { prisma } from "@/lib/database";
import argon2 from "argon2";
import {
  loginServerSchema,
  type LoginServerInput,
} from "@/lib/login/server-schema";
import { signSessionJwt } from "@/lib/auth/jwt";
import { setSessionCookie, getSessionTtlSeconds } from "@/lib/auth/cookies";
import { getUserSnapshot } from "@/lib/auth/user-snapshot";
import type { AuthUserSnapshot } from "@/lib/auth/types";

const LOCK_THRESHOLD = Number(process.env.LOCK_THRESHOLD ?? "5");
const LOCK_MINUTES = Number(process.env.LOCK_MINUTES ?? "15");
const AUTH_ERROR_MODE = process.env.AUTH_ERROR_MODE ?? "detailed"; // "ambiguous" | "detailed"

type FieldErrors = Partial<Record<keyof LoginServerInput, string>>;

function ambiguousMessage(): string {
  return "アカウントまたは認証情報が正しくありません";
}

function maybeAmbiguous(fieldErrors?: FieldErrors, fallback?: string) {
  if (AUTH_ERROR_MODE === "ambiguous") {
    return { ok: false as const, message: ambiguousMessage() };
  }
  if (fieldErrors) return { ok: false as const, fieldErrors };
  return { ok: false as const, message: fallback ?? ambiguousMessage() };
}

export type LoginActionResult =
  | { ok: true; user: AuthUserSnapshot }
  | { ok: false; fieldErrors?: FieldErrors; message?: string };

export async function loginAction(
  input: LoginServerInput,
): Promise<LoginActionResult> {
  // 1) サーバ側バリデーション（※ loginSchema 側で punycode 正規化済み）
  const parsed = loginServerSchema.safeParse(input);
  if (!parsed.success) {
    const fe: FieldErrors = {};
    for (const issue of parsed.error.issues) {
      const path = issue.path[0] as keyof LoginServerInput;
      fe[path] = issue.message;
    }
    return { ok: false, fieldErrors: fe };
  }
  // ★ ここで得られる email は「punycode ASCII（大小保持）」、accountId は trim 済み
  const { accountId, email, password } = parsed.data;

  // 2) 部署を特定
  const department = await prisma.department.findUnique({
    where: { code: accountId },
  });
  if (!department) {
    // ユーザーが特定できないためカウントはできない。メッセージは項目別 or 曖昧化。
    return maybeAmbiguous({ accountId: "アカウントIDが見つかりません" });
  }

  // 3) ユーザー特定
  const user = await prisma.user.findFirst({
    where: { departmentId: department.id, email },
    select: {
      id: true,
      hashedPassword: true,
      failedLoginCount: true,
      lockedUntil: true,
      isActive: true,
    },
  });
  if (!user) {
    // ここもユーザー未特定のためカウント不可。メッセージは項目別 or 曖昧化。
    return maybeAmbiguous({ email: "メールアドレスが見つかりません" });
  }

  // 4) ロック/無効チェック（ここではカウントは増やさない）
  if (user.lockedUntil && user.lockedUntil.getTime() > Date.now()) {
    return {
      ok: false,
      message: `アカウントがロックされています。時間をおいて再試行してください。`,
    };
  }
  if (!user.isActive) {
    return maybeAmbiguous(undefined, "このアカウントは無効化されています。");
  }

  // 5) パスワード検証
  const passwordOk = await argon2.verify(user.hashedPassword, password);
  if (!passwordOk) {
    // 失敗：ユーザー特定済みなので +1（原子的）
    const updated = await prisma.user.update({
      where: { id: user.id },
      data: { failedLoginCount: { increment: 1 } },
      select: { failedLoginCount: true },
    });

    if (updated.failedLoginCount >= LOCK_THRESHOLD) {
      await prisma.user.update({
        where: { id: user.id },
        data: {
          failedLoginCount: 0, // ロック発火時にリセット
          lockedUntil: new Date(Date.now() + LOCK_MINUTES * 60 * 1000),
        },
      });
      return {
        ok: false,
        message: `一定回数以上の失敗によりロックされました。${LOCK_MINUTES}分後に再試行してください。`,
      };
    }

    // 閾値に近づいたら曖昧化（もしくはモードが ambiguous なら常に曖昧）
    if (updated.failedLoginCount >= Math.max(1, LOCK_THRESHOLD - 2)) {
      return { ok: false, message: ambiguousMessage() };
    }
    return maybeAmbiguous({ password: "パスワードが違います" });
  }

  // 6) 成功：カウンタ/ロック解除
  await prisma.user.update({
    where: { id: user.id },
    data: { failedLoginCount: 0, lockedUntil: null },
  });

  // 7) セッション発行（DB + JWT + Cookie）
  const ttl = getSessionTtlSeconds();
  const session = await prisma.session.create({
    data: { userId: user.id, expiresAt: new Date(Date.now() + ttl * 1000) },
    select: { id: true, userId: true },
  });
  const token = await signSessionJwt({ jti: session.id }, ttl);
  await setSessionCookie(token);

  // 8) スナップショット取得
  const snapshot = await getUserSnapshot(user.id);
  if (!snapshot)
    return { ok: false, message: "ユーザー情報取得に失敗しました" };

  return { ok: true, user: snapshot };
}

このように改修することで、ログイン直後に ユーザースナップショットが返却される ようになります。
クライアント側では、この結果を AuthProvider に流し込めば即座にグローバル利用が可能になります。

redirect("/dashboard");の部分は、src/components/login/login-form.tsxへ移行しますが、ここは次章でやります。

処理フローの更新

最後に、改修後の全体フローを整理します。

txt

[loginAction]
  ├─ 認証（ID/Email/Password）
  ├─ Session 作成
  ├─ JWT 保存（Cookie）
  └─ ユーザースナップショット返却  ← ★ New

       ↓

<AuthProvider initialUser={snapshot}>
  └─ useAuth() で Sidebar や Pages から即参照可能

この章のまとめ

getUserSnapshot() を用いて 最小限のユーザー情報を取得。
loginAction の戻り値に user を追加し、ログイン直後から Context を初期化可能に。
以降のページ遷移では DB 再取得不要で、useAuth() により即参照できる。

次章では、この戻り値を AuthProvider に流し込み、ログイン成功時に Context が初期化される仕組みを実装します。

4. ログインフローとの統合

本章では、前章で実装した AuthProvider を実際のログインフローと接続し、ログイン成功直後にユーザー情報を Context に展開 する仕組みを組み立てます。これにより、ログイン後のページでは都度 DB を叩くことなく、Sidebar や Header から即座にユーザー情報を利用できるようになります。

前章の修正により、サーバアクションの返却値は以下のようになっています。

状態	内容
成功時	`{ ok: true, user: AuthUserSnapshot }`
失敗時	`{ ok: false, fieldErrors?, message? }`

redirect("/dashboard") は削除し、リダイレクトはクライアント側で制御します。

クライアント側で Context 初期化

ログインフォームでは、成功レスポンスからスナップショットを受け取り、AuthProvider に渡して Context を初期化します。ここで redirect を呼び出してダッシュボードへ遷移します。

tsx

// src/components/login/login-form.tsx（一部抜粋）
"use client";

import { useRouter } from "next/navigation"; // 追加
import { useState, useTransition } from "react";
import { useForm } from "react-hook-form";
import { z } from "zod";
import { zodResolver } from "@hookform/resolvers/zod";
import { loginSchema } from "@/lib/login/schema";
import { loginAction } from "@/app/_actions/auth/login";
import { useAuth } from "@/lib/auth/context"; // 追加

// ── 省略

export default function LoginForm() {
  const [pending, startTransition] = useTransition();
  const [globalError, setGlobalError] = useState<string | null>(null);
  const { setUser } = useAuth(); // 追加 ★ Context API
  const router = useRouter(); // 追加 

   // ── 省略

   const onSubmit = (values: LoginValues) => {

    // ── onSubmitの既存部分省略

        // 全体エラー（ロック/曖昧メッセージなど）はグローバルに表示
        if (res.message) setGlobalError(res.message);
        return;
      }

      // 下記2行を追加： ★ 成功時：Contextに保存してから遷移
      setUser(res.user);
      router.push("/dashboard");
    });
  };

// ── 以下、省略

こうすることで、ログイン直後に AuthProvider が初期化され、Sidebar や Header で即座にユーザー情報を利用できます。

データフローの確認

実装後のデータフローは以下のように整理されます。

txt

[ユーザー] → [LoginForm] → loginAction(Server Action)
       → セッション保存＋ユーザースナップショット返却
       → AuthProvider.setUser() に渡す
       → Context 初期化完了
       → router.push("/dashboard")

これでログイン後のページでは useAuth() からユーザー情報を即座に参照でき、再取得の必要がなくなります。
以降は Sidebar のメニュー制御やページ単位の RBAC 判定に、この Context を活用していきます。

5. UIへの適用 ─ Sidebar/ヘッダに Context を接続

本章では、これまでモックで表示していたユーザー名・メール・アバター・ロールを AuthContext（useAuth()）へ置き換え 、さらに ロール優先度(rolePriority)でメニューを出し分け できるようにします。
SSR のガードは従来どおり middleware / lookupSessionFromCookie() に任せ、CSR 側の Sidebar / ヘッダでは Context を参照して即座に描画します。

変更方針（Before/After）

まずは今回 UI 側で行う差分を表で俯瞰します。

対象	Before	After
`NavUser`	`mockUser` を表示	`useAuth()` からユーザー表示（未ログイン時は安全にデグレード）
`AppSidebar`	`mockUser` 固定 / メニューは全表示	`useAuth()` の `rolePriority` でメニューをフィルタ
メニュー制御	なし	`minPriority` を下回る項目を非表示（親子再帰対応）

メニューのロール制御ユーティリティ

MenuTree から minPriority を満たさないノードを除外 する関数を用意します。
「親が消えると子も消える」「空のセクションは消す」など再帰的に整形します。

// src/lib/sidebar/menu.rbac.ts
import type { MenuRecord } from "./menu.schema";

/**
 * 親の minPriority は子孫に “継承” され、子側での上書きは不可という仕様。
 * 有効値 = 親が持っていれば親の値、なければ自分の値（どちらも無ければ undefined）
 */
function inheritMinPriority(
  parentMin: number | undefined,
  selfMin: number | undefined,
): number | undefined {
  return parentMin ?? selfMin;
}

type Index = {
  byId: Map<string, MenuRecord>;
  childrenOf: Map<string | null, MenuRecord[]>;
};

function buildIndex(records: MenuRecord[]): Index {
  const byId = new Map<string, MenuRecord>();
  const childrenOf = new Map<string | null, MenuRecord[]>();

  for (const r of records) {
    byId.set(r.displayId, r);
    const key = r.parentId ?? null;
    const arr = childrenOf.get(key) ?? [];
    arr.push(r);
    childrenOf.set(key, arr);
  }

  // 兄弟は order 順に
  for (const [, arr] of childrenOf) {
    arr.sort((a, b) => a.order - b.order);
  }

  return { byId, childrenOf };
}

/**
 * MenuRecord[] を rolePriority でフィルタし、空になった見出しは除去する。
 * - 非アクティブ（isActive=false）は常に除外
 * - 親が不可なら子孫も不可（自動的に落ちる）
 * - 見出し（isSection=true）は、最終的に子が 0 件なら除外
 */
export function filterMenuRecordsByPriority(
  records: MenuRecord[],
  userPriority: number,
): MenuRecord[] {
  const { childrenOf } = buildIndex(records);

  const kept: MenuRecord[] = [];
  const keptIds = new Set<string>();

  // 深さ優先：親 → 子へ “継承された minPriority” を渡しながら評価
  const walk = (parentId: string | null, inheritedMin: number | undefined) => {
    const children = childrenOf.get(parentId) ?? [];
    for (const rec of children) {
      if (!rec.isActive) continue;

      const effMin = inheritMinPriority(inheritedMin, rec.minPriority);
      const allowed = effMin == null || userPriority >= effMin;
      if (!allowed) continue;

      kept.push(rec);
      keptIds.add(rec.displayId);

      // 子孫へは “親の minPriority を優先継承”
      walk(rec.displayId, effMin);
    }
  };

  // ルートから開始
  walk(null, undefined);

  // 2 パス目：空見出し除去（子が一件も残っていない見出しは落とす）
  const hasChild = new Set<string>();
  for (const r of kept) {
    if (r.parentId && keptIds.has(r.parentId)) hasChild.add(r.parentId);
  }

  const pruned = kept.filter((r) =>
    r.isSection ? hasChild.has(r.displayId) : true,
  );

  // order の連番正規化（兄弟ごと）
  const byParent = new Map<string | null, MenuRecord[]>();
  for (const r of pruned) {
    const key = r.parentId ?? null;
    const arr = byParent.get(key) ?? [];
    arr.push(r);
    byParent.set(key, arr);
  }
  for (const [, arr] of byParent) {
    arr.sort((a, b) => a.order - b.order);
    arr.forEach((r, i) => (r.order = i));
  }

  return pruned;
}

上記は rolePriority（数値が大きいほど強い権限）で閲覧可能メニューを抽出する単機能です。
既存の toMenuTree() の後段に差し込むことで、UI 側からは 「常に表示可能なツリー」 を受け取れます。

`AppSidebar` の改修（Context 参照 + メニュー出し分け）

mockUser 依存を解消し、useAuth() でユーザーとロール優先度を取得します。
filterMenuRecordsByPriority() を toMenuTree() の後に適用し、出し分け済みの tree を NavMain へ渡します。

tsx

// src/components/sidebar/app-sidebar.tsx
"use client";

import { useMemo } from "react";

import { ModeToggle } from "@/components/sidebar/mode-toggle";
import { NavMain } from "@/components/sidebar/nav-main";
import { NavUser } from "@/components/sidebar/nav-user";
import { NavTeam } from "@/components/sidebar/nav-team";

import {
  Sidebar,
  SidebarContent,
  SidebarFooter,
  SidebarHeader,
  SidebarRail,
} from "@/components/ui/sidebar";

import { mockTeam } from "@/lib/sidebar/mock-team";
import { getMenus } from "@/lib/sidebar/menu.mock"; // MenuRecord[] を返す
import { toMenuTree } from "@/lib/sidebar/menu.transform"; // 変換レイヤ

// ← ★ 追加：RBAC フィルタ
import { filterMenuRecordsByPriority } from "@/lib/sidebar/menu.rbac";
// ← ★ 追加：AuthContext から優先度を取得
import { useAuth } from "@/lib/auth/context";

export function AppSidebar({ ...props }: React.ComponentProps<typeof Sidebar>) {
  const { user } = useAuth(); // user?.rolePriority を使う

  // 依存に使う“安定したプリミティブ”へ切り出し
  const rolePriority = user?.rolePriority ?? null;

  // 現状はモックストアから毎レンダー取得（将来は Server Action などに置換）
  const records = getMenus();

  const tree = useMemo(() => {
    const filtered =
      rolePriority != null
        ? filterMenuRecordsByPriority(records, rolePriority)
        : [];
    return toMenuTree(filtered);
  }, [rolePriority, records]);

  return (
    <Sidebar collapsible="icon" {...props}>
      <SidebarHeader>
        <NavTeam team={mockTeam} />
      </SidebarHeader>

      <SidebarContent>
        {/* priorityを利用したメニュー表示 */}
        <nav aria-label="メインメニュー">
          <NavMain items={tree} />
        </nav>
      </SidebarContent>

      <SidebarFooter>
        <ModeToggle className="ml-auto" />
        {/* Contextを利用したユーザ情報表示 */}
        <NavUser />
      </SidebarFooter>

      <SidebarRail />
    </Sidebar>
  );
}

useAuth() から user?.rolePriority を参照し、メニュー表示をロール優先度で制御。
NavUser には props を渡さず、コンポーネント内で useAuth() を直接参照する形に揃えました（次節）。

`NavUser` の改修（Context 参照 + 未ログイン時の安全表示）

NavUser を useAuth() ベースに変更します。
未ログインまたは user が未初期化の場合は、 安全なデフォルト表示 （プレースホルダー）にフォールバックします。

tsx

// src/components/sidebar/nav-user.tsx
"use client";
import { useTransition } from "react"; // ★ 追加
import { logoutAction } from "@/app/_actions/auth/logout"; // ★ 追加
import Link from "next/link";
import {
  Bell,
  ChevronsUpDown,
  KeyRound,
  LogOut,
  User as UserIcon,
} from "lucide-react";

import { Avatar, AvatarFallback, AvatarImage } from "@/components/ui/avatar";
import {
  DropdownMenu,
  DropdownMenuContent,
  DropdownMenuGroup,
  DropdownMenuItem,
  DropdownMenuLabel,
  DropdownMenuSeparator,
  DropdownMenuTrigger,
} from "@/components/ui/dropdown-menu";
import {
  SidebarMenu,
  SidebarMenuButton,
  SidebarMenuItem,
  useSidebar,
} from "@/components/ui/sidebar";

import { useAuth } from "@/lib/auth/context";

export function NavUser() {
  const { isMobile } = useSidebar();
  const [pending, startTransition] = useTransition(); // ★ 追加

  const { user } = useAuth();

  const name = user?.name ?? "ゲスト";
  const email = user?.email ?? "";
  const avatarUrl = user?.avatarUrl ?? "/user-avatar.png"; // 後続章で保護配信URLへ置換
  const initial = name.slice(0, 1);

  const handleLogout = () => {
    if (pending) return; // ★ 二重実行防止
    startTransition(async () => {
      await logoutAction(); // サーバ側で Cookie 削除 + Session 失効 + redirect("/login")
    });
  };

  return (
    <SidebarMenu>
      <SidebarMenuItem>
        <DropdownMenu>
          <DropdownMenuTrigger asChild>
            <SidebarMenuButton
              size="lg"
              className="data-[state=open]:bg-sidebar-accent data-[state=open]:text-sidebar-accent-foreground"
              aria-label="ユーザーメニューを開く"
              disabled={!user} // 未ログイン時は操作不可
            >
              <Avatar className="h-8 w-8 rounded-lg">
                {/* 画像は next/image でもOKだが AvatarImage で十分 */}
                <AvatarImage src={avatarUrl} alt={name} />
                <AvatarFallback className="rounded-lg">
                  {initial}
                </AvatarFallback>
              </Avatar>
              <div className="grid flex-1 text-left text-sm leading-tight">
                <span className="truncate font-medium">{name}</span>
                <span className="text-muted-foreground truncate text-xs">
                  {email && (
                    <span className="text-muted-foreground truncate text-xs">
                      {email}
                    </span>
                  )}
                </span>
              </div>
              <ChevronsUpDown className="ml-auto size-4" />
            </SidebarMenuButton>
          </DropdownMenuTrigger>

          <DropdownMenuContent
            className="w-(--radix-dropdown-menu-trigger-width) min-w-56 rounded-lg"
            side={isMobile ? "bottom" : "right"}
            align="end"
            sideOffset={4}
          >
            {/* ヘッダー（ユーザー情報の再掲） */}
            <DropdownMenuLabel className="p-0 font-normal">
              <div className="flex items-center gap-2 px-1 py-1.5 text-left text-sm">
                <Avatar className="h-8 w-8 rounded-lg">
                  <AvatarImage src={avatarUrl} alt={name} />
                  <AvatarFallback className="rounded-lg">
                    {initial}
                  </AvatarFallback>
                </Avatar>
                <div className="grid flex-1 text-left text-sm leading-tight">
                  <span className="truncate font-medium">{name}</span>
                  {email && (
                    <span className="text-muted-foreground truncate text-xs">
                      {email}
                    </span>
                  )}
                </div>
              </div>
            </DropdownMenuLabel>

            <DropdownMenuSeparator />

            <DropdownMenuGroup>
              <DropdownMenuItem asChild>
                {/* 変更: /profile に差し替え */}
                <Link href="/profile" className="flex items-center gap-2">
                  <UserIcon className="size-4" />
                  ユーザー情報確認
                </Link>
              </DropdownMenuItem>

              <DropdownMenuItem asChild>
                {/* 変更: /profile/password に差し替え */}
                <Link
                  href="/profile/password"
                  className="flex items-center gap-2"
                >
                  <KeyRound className="size-4" />
                  パスワード変更
                </Link>
              </DropdownMenuItem>

              <DropdownMenuItem asChild>
                {/* TODO: /notifications に差し替え */}
                <Link href="#" className="flex items-center gap-2">
                  <Bell className="size-4" />
                  通知
                </Link>
              </DropdownMenuItem>
            </DropdownMenuGroup>

            <DropdownMenuSeparator />

            {/* ★ ここを Link ではなく onClick で Action 直結 */}
            <DropdownMenuItem
              onClick={handleLogout}
              disabled={pending}
              className="text-destructive flex cursor-pointer items-center gap-2"
              aria-disabled={pending}
            >
              <LogOut className="size-4" />
              {pending ? "ログアウト中..." : "ログアウト"}
            </DropdownMenuItem>
          </DropdownMenuContent>
        </DropdownMenu>
      </SidebarMenuItem>
    </SidebarMenu>
  );
}

useAuth() によって モック脱却。ログイン直後でも Context 初期化済みのため、即座に氏名/メール/アバターを表示できます。
未ログイン時（user=null）はボタンを disabled にし、リンクも disabled で安全側へ。
アバター URL は一時的にダミーへフォールバックしています（直リンク禁止方針に合わせ、次回章で /api/avatar/[userId] 等へ置換予定）。

この章のまとめ

NavUser / AppSidebar を useAuth() へ移行 。モック依存を排除してログイン直後から正しい表示に。
rolePriority による メニュー出し分け を filterMenuRecordsByPriority() で実現。
未ログイン時は UI を安全側へデグレードし、SSR ガード + CSR 表示最適化の責務分離を維持。

6. まとめと次回予告

本章では、ログイン済みユーザー情報を Context API でアプリ全体に共有する仕組み を構築しました。
これにより、Sidebar やヘッダから即座にユーザー名やロール情報を参照でき、さらにロール優先度に基づいたメニューの出し分けも実現しました。

本記事で実現したポイント

区分	内容
グローバル共有	AuthProvider + useAuth によるユーザー情報のContext管理
SSR/CSR責務分離	SSRはセッションガード、CSRはContext参照に特化
RBAC対応	rolePriorityに基づきSidebarメニューをフィルタリング
UI統合	NavUser/SidebarがDBユーザー情報を即時表示

これで「ログイン後のUI制御」の基盤が完成しました。

次回予告

次回は、現在ダミーとして扱っている アバター画像の取り扱い をテーマにします。

直リンク禁止の方針 に基づき、/api/avatar/[userId] のような認可付きエンドポイントを実装
サインドURLや認可済み配信の仕組みを組み合わせて、セキュアにアバターを提供
Sidebar やヘッダの NavUser コンポーネントに組み込み、実際のユーザーごとに動的に反映

これにより、UI 表示の信頼性とセキュリティをさらに高めます。

参考文献

本記事の実装や設計にあたり、以下の公式ドキュメントや資料を参照しました。

種別	リンク
React Docs: Context API	https://react.dev/reference/react/useContext
Next.js App Router Docs	https://nextjs.org/docs/app
Zod Official Docs	https://zod.dev
TypeScript Handbook	https://www.typescriptlang.org/docs/
Lucide Icons	https://lucide.dev
shadcn/ui Docs	https://ui.shadcn.com

この記事の執筆・編集担当

松本孝太郎

DELOGs編集部/中年新米プログラマー

ここ数年はReact&MUIのフロントエンドエンジニアって感じでしたが、Next.jsを学んで少しずつできることが広がりつつあります。その実践記録をできるだけ共有していければと思っています。

この記事の更新履歴

2025/11/6
デモ環境とGithubリポジトリについての記述を追加
2025/9/21
ログインのサーバアクションで小文字変換してマッチングする箇所を削除：src/app/_actions/login.ts
2025/9/19
ログイン関連のサーバアクションファイルのディレクトリを調整: src/app/_actions/ → src/app/_actions/auth/
2025/9/16
app-sidebar.tsxの内容を修正：次のワーニング対応: The 'filtered' conditional could make the dependencies of useMemo Hook (at line 40) change on every render.
2025/9/12
初回公開

管理画面で受け付けたパスワード再発行依頼を、Server Action・Shadcn/uiのデータテーブル・メール送信を組み合わせて運用可能なワークフローに統合

2025/10/15公開

[管理画面フォーマット開発編 #11] パスワード再発行依頼とメールテンプレート統合のイメージ

[管理画面フォーマット開発編 #10] メニュー管理UIをDB連携する

グローバルで一貫したMenuテーブルを保ちながら、部署ごとにメニュー表示をカスタマイズ

2025/10/12公開

[管理画面フォーマット開発編 #10] メニュー管理UIをDB連携するのイメージ

[管理画面フォーマット開発編 #9 後編] 部署別ロール対応 ─ プロフィール管理の改修

DepartmentRole導入に伴い、プロフィール管理で「実効ロール」を参照するように修正と一部ついでの変更

2025/10/8公開

[管理画面フォーマット開発編 #9 前編] 部署別ロール対応 ─ ユーザ管理の改修

DepartmentRole導入に伴い、ユーザ管理で「実効ロール」を参照するように修正

2025/10/5公開

[管理画面フォーマット開発編 #9 前編] 部署別ロール対応 ─ ユーザ管理の改修のイメージ

[管理画面フォーマット開発編 #8 後編] 部署別ロール ─ 管理UIとServer Action実装

部署ごとのロールを実際に操作できるように、Server Actionと管理画面UIを構築

2025/10/2公開

管理画面フォーマット開発編 #3AuthProviderでログイン済みユーザー情報を全体共有

0. はじめに

本記事のゴール

管理画面フォーマット開発編の完成形（デモとGithubリポジトリ）

技術スタック

1. 要件と設計方針

共有するデータと共有しないデータ

取得タイミングの選定

データフローの全体像

型定義（最小インターフェース）

データ源：Prisma（リードレプリカ対応）

ルーティングとガードの整理

この章のまとめ

2. AuthProvider と useAuth の実装

AuthProvider の責務

ディレクトリ構成

Context 実装

SSR と CSR の接続

Server Wrapper の実装

ProtectedLayout への組み込み

この章のまとめ

3. loginAction の改修 ─ スナップショット返却

変更点の整理

loginAction の改修

処理フローの更新

この章のまとめ

4. ログインフローとの統合

クライアント側で Context 初期化

データフローの確認

5. UIへの適用 ─ Sidebar/ヘッダに Context を接続

変更方針（Before/After）

メニューのロール制御ユーティリティ

AppSidebar の改修（Context 参照 + メニュー出し分け）

NavUser の改修（Context 参照 + 未ログイン時の安全表示）

この章のまとめ

6. まとめと次回予告

本記事で実現したポイント

次回予告

参考文献

管理画面フォーマット開発編 #3
AuthProviderでログイン済みユーザー情報を全体共有

`AppSidebar` の改修（Context 参照 + メニュー出し分け）

`NavUser` の改修（Context 参照 + 未ログイン時の安全表示）