管理画面フォーマット開発編 #2
JWT +Cookie＋middlewareで実装するログイン機能

httpOnly Cookie と middleware を組み合わせ、JWTはjtiのみを運ぶ“鍵”として使用。法人ユースに耐える堅牢なログインを実装

初回公開日2025/9/12

最終更新日2025/11/6

0. はじめに

本章では、今回の記事の背景と目的を整理します。前回の記事 【管理画面フォーマット開発編 #1】 Prisma × PostgreSQLで進めるDB設計 では、Prisma × PostgreSQL を用いた DB 設計を行い、ログインに必要なテーブル構造を整備しました。今回はその続編として、 実際に動作するログイン機能 を実装していきます。

前回までの振り返り

前回の記事で構築したポイントをまとめると、以下のようになります。

項目	内容
ログイン境界	`Department.code` を利用し、部署ごとにユーザーを管理
ユーザー管理	`User.email` を部署内で一意に制約
パスワード	`User.hashedPassword` に argon2 でハッシュ化して保存
ロール管理	`Role.code` と `priority` を持ち、RBAC を実現できる構成
初期データ	Seed スクリプトで管理者ユーザー・ロール・契約を投入済み

これにより、認証に必要な土台はすでに完成しています。

今回の実装範囲

今回の記事では、以下の内容を実装対象とします。

ログインフォームとサーバアクションの接続
JWT 発行（ただしペイロードは jti と exp のみ）
httpOnly Cookie に保存して middleware で保護
失敗時のエラーメッセージ（項目別＋列挙検知時の曖昧化）
5回連続失敗による一時ロック

このように、セキュリティ要件を満たしつつ UX にも配慮したログイン機能を「実践記録」として構築していきます。

今後の流れ

本記事（管理画面フォーマット開発編 #2）はログインにフォーカスし、ログイン成立後に最低限ページを表示できる状態までを目指します。次の記事（管理画面フォーマット開発編 #3）では、ログイン済みユーザー情報を Context（AuthProvider） としてアプリ全体で共通利用できるように拡張し、メニューや各画面の RBAC 制御を体系化していく予定です。

管理画面フォーマット開発編の完成形（デモと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	スキーマ定義と実行時バリデーション

1. ログイン仕様の概要

本章では、今回実装するログイン機能の仕様を整理します。ログインに必要な認証要素やセッション管理、そして成功・失敗時の挙動を明確にすることで、実装に向けた全体像を固めます。

認証要素

ログインに必要な入力と検証対象は以下の通りです。
アカウントIDは部署コード、メールは部署内一意、パスワードは argon2 での照合を行います。

項目	入力値	DB側の検証対象	備考
アカウントID	Department.code	Department.code	15文字以上、大小英数字を各1以上含む
メールアドレス	User.email	User.email	部署内で一意制約 @@unique([departmentId, email])
パスワード	平文入力	User.hashedPassword	argon2.verify で照合

セッション管理

セッションは JWT と Session テーブルを組み合わせて管理します。JWT は「鍵」としてのみ機能させ、実体のユーザー情報はサーバ側で参照します。

項目	内容
JWT ペイロード	jti（Session.id）、exp のみ
Cookie 属性	httpOnly, secure, sameSite=lax, path=/
middleware	JWT 検証（署名・期限）＋ Session 存在確認
Session テーブル	jti に紐づくセッションを保持、失効や期限切れを管理

成功・失敗時の挙動

ログインの成否に応じて、リダイレクトやエラーメッセージ表示を制御します。UX とセキュリティの両立を図るため、通常は項目別エラーを返しつつ、列挙攻撃が疑われる場合は一時的に曖昧メッセージへ切り替えます。

状況	挙動
成功時	Cookie に JWT を保存し、`/dashboard` にリダイレクト
失敗時（通常）	項目別にエラーメッセージ表示（アカウント / メール / パスワード）
失敗時（列挙検知中）	曖昧メッセージ「アカウントまたは認証情報が正しくありません」を表示
5回連続失敗	ユーザーを 15 分間ロック（解除は時間経過または成功時リセット）

このように、仕様全体を通じて「安全性」と「使いやすさ」の両立を意識した構成としています。

2. セッションストア設計と作成

ここでは、JWT にユーザー情報を含めず「鍵」としてのみ使うための仕組みとして、サーバ側に用意するセッションストアの設計を説明します。これにより、ログイン状態を一元管理し、即時失効や監査ログの基盤を整えられます。

設計の目的

セッションストアを設けることで、以下のような利点が得られます。

目的	説明
PII の最小化	JWT に個人情報を含めないため、漏洩リスクを低減できる
即時失効	サーバ側の `Session` 行を無効化すれば、次リクエストから強制ログアウト可能
権限変更の即時反映	ユーザーのロール変更を DB 側に反映するだけで次アクセスに適用される
監査対応	認証イベントの履歴を保持し、法人利用で求められる監査性を高められる

セッションテーブルの概要

実装する Session テーブルの構造を整理すると以下の通りです。

カラム名	型	説明
id	String (UUID)	JWT の jti として利用
userId	String	対応するユーザー ID
expiresAt	DateTime	セッションの有効期限
createdAt	DateTime	作成日時
revokedAt	DateTime?	任意、手動失効やログアウト時に記録
ip	String?	任意、監査用（接続元IP）
userAgent	String?	任意、監査用（UA文字列）

セッションのライフサイクル

セッションの生成から失効までの流れを整理します。

txt

[loginAction]
  ├─ User 認証（Department.code + email + password）
  ├─ Session 行を INSERT（id = jti, expiresAt = 1h）
  ├─ JWT を発行（payload = { jti, exp }）
  └─ JWT を httpOnly Cookie に保存 → /dashboard へ redirect

[middleware]
  ├─ Cookie から JWT を取得
  ├─ JWT の署名・exp 検証
  ├─ jti を使って Session を DB で参照
  └─ 有効なら通過 / 無効なら /login へ redirect

[logoutAction]
  ├─ 現在の jti を特定
  ├─ Session.revokedAt = now()（または行を削除）
  └─ Cookie 削除 → /login へ redirect

このように、JWT はあくまで「セッション ID を運ぶトークン」として機能し、ユーザーの文脈はすべてサーバ側のストアを参照して解決します。

Prisma スキーマへの追記

ここから実際に prisma/schema.prisma に Session モデルを追加します。既存データを保持するため、マイグレーションは追加のみ行います。

// prisma/schema.prisma（抜粋：User に逆側のリレーションを追加／明示的な名前を付与）

model User {
  id        String    @id @default(uuid())
  displayId String    @unique @default(dbgenerated("generate_display_id('user_display_id_seq','US')")) @db.VarChar(10)
  isActive  Boolean   @default(true)
  createdAt DateTime  @default(now()) @db.Timestamptz
  updatedAt DateTime  @updatedAt      @db.Timestamptz
  deletedAt DateTime?                  @db.Timestamptz

  departmentId     String
  roleId           String
  email            String // login & notice
  hashedPassword   String
  name             String
  phone            String?
  remarks          String?

  // ログイン失敗ロック
  failedLoginCount Int       @default(0)
  lockedUntil      DateTime? @db.Timestamptz

  // リレーション
  department Department @relation(fields: [departmentId], references: [id], onDelete: Restrict)
  role       Role       @relation(fields: [roleId], references: [id], onDelete: Restrict)

  // Session への逆側（双方向）リレーション
  sessions Session[] @relation("UserSessions")

  // 部署内メール一意（ログインキー）
  @@unique([departmentId, email])
  @@index([departmentId])
  @@index([roleId])
  @@index([isActive])
  @@index([createdAt])
}

// Session 定義
model Session {
  id        String   @id @default(uuid())
  userId    String
  user      User     @relation("UserSessions", fields: [userId], references: [id], onDelete: Cascade)

  expiresAt DateTime @db.Timestamptz
  createdAt DateTime @default(now()) @db.Timestamptz
  revokedAt DateTime?                @db.Timestamptz

  ip        String?
  userAgent String?

  @@index([userId])
  @@index([expiresAt])
  @@index([revokedAt])
}

このコードでは、Session と User をリレーションで結び、userId が削除された場合は関連するセッションも削除されるよう onDelete: Cascade を設定しています。また、期限切れやユーザー別の検索が高速に行えるよう、インデックスを付与しています。

マイグレーションの実行

新しいモデルを追加したら、既存データを保持したままマイグレーションを実行します。

zsh

npx prisma migrate dev --name add_session_and_user_sessions

// クライアント再生成
npx prisma generate

このコマンドで Session テーブルが追加され、既存のユーザーやロールのデータは保持されます。これで、ログイン機能に必要なセッションストアが完成しました。

3. ログイン処理の実装（Server Actions 編）

本章では、実装に踏み込みます。サーバアクションを src/app/_actions 配下にまとめ、JWT（jtiのみ）発行・Cookie設定・セッション生成・ロック判定・エラーメッセージの曖昧化切替までを実装します。フロントは既存の login-form.tsx を最小差分でサーバアクションに接続します。

txt

┌───────────────────────────────────────────────┐
│ LoginForm (client)                           │
│   └─ onSubmit -> loginAction(...) ───────────┼─▶ サーバ側Zod検証
│                                              │    │
│                                              │    ├─ ロック確認/失敗カウント更新
│                                              │    ├─ ユーザー認証 (Department.code + email + argon2)
│                                              │    ├─ Session作成 (DB)
│                                              │    ├─ JWT発行 (payload={ jti, exp })
│                                              │    ├─ Cookie設定 (httpOnly/secure/sameSite=lax)
│                                              │    └─ redirect("/dashboard")
└───────────────────────────────────────────────┘

ディレクトリ構成と方針

サーバアクションと共通ユーティリティを以下のように分割します。アプリ本体の import が読みやすく、テストもしやすい構成です。

種別	役割	提案パス
サーバアクション	ログイン／ログアウト	`src/app/_actions/auth/login.ts`, `src/app/_actions/auth/logout.ts`
JWTユーティリティ	署名・検証（jti/expのみ）	`src/lib/auth/jwt.ts`
Cookieユーティリティ	set/clear など	`src/lib/auth/cookies.ts`
セッション解決	jti→Session→User解決	`src/lib/auth/session.ts`
サーバ側Zod	入力検証（同等以上）	`src/lib/login/server-schema.ts`

以降、順番にファイルを作っていきます。

txt

src/
├─ app/
│  └─ _actions/
│      └─ auth/
│          ├─ login.ts
│          └─ logout.ts
├─ components/
│  └─ login/
│     └─ login-form.tsx   # 既存：最小差分で接続
└─ lib/
   └─ auth/
      ├─ jwt.ts
      ├─ cookies.ts
      └─ session.ts
   └─ login/
      └─ server-schema.ts
   └─ database.ts # DB接続用のライブラリ

JWTユーティリティ（`src/lib/auth/jwt.ts`）

JWT は jti と exp のみを持つ署名付きトークンとして扱います。アルゴリズムは固定、JWT_SECRET は環境変数から取得します。

`jose`のインストール

下記のコマンドでインストールを実行します。

zsh

npm install jose

src/lib/auth/jwt.tsの作成

// src/lib/auth/jwt.ts
import { SignJWT, jwtVerify } from "jose";

const alg = "HS256";
const encoder = () => new TextEncoder().encode(process.env.JWT_SECRET ?? "");

if (!process.env.JWT_SECRET || process.env.JWT_SECRET.length < 32) {
  // 起動時に早期発見したいため例外化（本番では適宜ハンドリング）
  throw new Error(
    "JWT_SECRET is missing or too short (>=32 chars recommended).",
  );
}

export type SessionJwtPayload = {
  jti: string; // Session.id
  // exp は SignJWT 側で設定
};

export async function signSessionJwt(
  payload: SessionJwtPayload,
  ttlSeconds: number,
): Promise<string> {
  const now = Math.floor(Date.now() / 1000);
  const token = await new SignJWT({ jti: payload.jti })
    .setProtectedHeader({ alg })
    .setIssuedAt(now)
    .setExpirationTime(now + ttlSeconds)
    .sign(encoder());
  return token;
}

export async function verifySessionJwt(
  token: string,
): Promise<{ jti: string }> {
  const { payload, protectedHeader } = await jwtVerify(token, encoder(), {
    algorithms: [alg],
  });
  if (protectedHeader.alg !== alg) {
    throw new Error("Invalid JWT alg");
  }
  const jti = (payload as unknown as { jti?: string }).jti;
  if (!jti) throw new Error("JWT missing jti");
  return { jti };
}

解説

SignJWT で jti のみをクレームに入れ、exp は setExpirationTime で付与します。
verifySessionJwt は署名・期限を検証し、jti を取り出すだけの最小実装です。
alg を固定し、none 等を拒否することで安全側に寄せています。
JWT_SECRET は 32 文字以上を推奨（十分長い乱数文字列）。

JWT_SECRET を`.env`に設定

env

JWT_SECRET=BIKGag4（以下省略）

Cookieユーティリティ（`src/lib/auth/cookies.ts`）

httpOnly Cookie の設定・削除を共通化します。SESSION_COOKIE_NAME, SESSION_TTL_SECONDS は環境変数で調整できるようにします。

`src/lib/auth/cookies.ts`の作成

// src/lib/auth/cookies.ts
import { cookies } from "next/headers";

const COOKIE_NAME = process.env.SESSION_COOKIE_NAME ?? "session";
const TTL_SECONDS = Number(process.env.SESSION_TTL_SECONDS ?? "3600");
const isProd = process.env.NODE_ENV === "production";

export function getSessionCookieName(): string {
  return COOKIE_NAME;
}
export function getSessionTtlSeconds(): number {
  return TTL_SECONDS;
}

export async function setSessionCookie(token: string) {
  const jar = await cookies();
  jar.set(COOKIE_NAME, token, {
    httpOnly: true,
    sameSite: "lax",
    secure: isProd, // ★ 本番のみ true
    path: "/",
    maxAge: TTL_SECONDS,
  });
}

export async function clearSessionCookie() {
  const jar = await cookies();
  jar.delete(COOKIE_NAME);
}

解説

Cookieは httpOnly/secure/sameSite=lax/path=/ を付与。
maxAge はセッションの TTL と揃えます。
削除は cookies().delete(name) で即時に反映されます。

環境変数の設定

.envにSESSION_COOKIE_NAME, SESSION_TTL_SECONDSを設定しておきます。とりあえず、上記のcookies.tsのデフォルト設定のまま設定します。

env

# セッションCookieの名前（任意。省略時は "session"）
SESSION_COOKIE_NAME=session

# Cookie と JWT の有効期限（秒）
# 例: 3600 = 1時間
SESSION_TTL_SECONDS=3600

サーバ側Zodスキーマ（`src/lib/login/server-schema.ts`）

クライアントの Zod（既存）と 同等以上 の検証をサーバでも行います。DB問い合わせ前の早期排除が狙いです。とはいえ、スキーマを別途記述するのは2度手間ですので、src/lib/login/schema.tsですでに設定した内容を流用します。ただ、ここで、メールアドレスについて、日本語ドメイン対策も追加しておきます。メールアドレスのドメインで日本語ドメインを利用しているのレアケースだと思いますが、念の為です。

まずは、ASCIIコードへドメインを変換するツールpunycodeをインストールします。

zsh

# 送信周りの依存を追加
npm i punycode

# 型（TS）を使う場合
npm i -D @types/punycode

つづいて、src/lib/login/schema.tsのメールアドレスのzodスキーマを変更します。

// src/lib/login/schema.ts
import { z } from "zod";
import * as punycode from "punycode/";

function toAsciiEmailSafe(input: string) {
  const s = input.trim();
  const at = s.lastIndexOf("@");
  if (at === -1) return s; // 後段の z.email で弾かせる
  const local = s.slice(0, at);
  const domain = s.slice(at + 1);
  if (!local || !domain) return s;
  try {
    return `${local}@${punycode.toASCII(domain)}`;
  } catch {
    // 不正なIDNなどはそのまま返して z.email で invalid に
    return s;
  }
}

export const loginSchema = z.object({
  accountId: z
    .string()
    .min(15, "アカウントIDは15文字以上で入力してください。")
    .regex(/[A-Z]/, "大文字を1文字以上含めてください。")
    .regex(/[a-z]/, "小文字を1文字以上含めてください。")
    .regex(/[0-9]/, "数字を1文字以上含めてください。"),
  email: z
    .string()
    .transform((s) => toAsciiEmailSafe(s))
    .pipe(z.email("メールアドレスの形式が正しくありません")),
  password: z
    .string()
    .min(15, "パスワードは15文字以上で入力してください。")
    .regex(/[A-Z]/, "大文字を1文字以上含めてください。")
    .regex(/[a-z]/, "小文字を1文字以上含めてください。")
    .regex(/[0-9]/, "数字を1文字以上含めてください。"),
});

サーバ側のスキーマは上記のファイルを読み込むようにします。

// src/lib/login/server-schema.ts
import { z } from "zod";
import { loginSchema } from "@/lib/login/schema";

/**
 * サーバ側では、(1) 正規化（trim/lowercase）と (2) サーバ限定ルール があれば“後付け”する。
 * - 形式チェックは loginSchema に委譲（DRY）
 * - パスワードは加工しない（ハッシュ照合に影響するため）
 */
export const loginServerSchema = loginSchema.transform((v) => ({
  ...v,
  accountId: v.accountId.trim(),
  email: v.email.trim(),
  // password は加工しない
}));

export type LoginServerInput = z.infer<typeof loginServerSchema>;

解説

アカウントID／パスワードは15文字以上＋大小英字・数字を各1以上を強制。
形式不正はDBアクセス前に弾き、辞書的攻撃の負荷を軽減します。

データベース接続用のライブラリ（`src/lib/database.ts`）

Prismaを扱いやすくするためにデータベース接続ライブラリを作成します。DELOGsの環境ではリードレプリカDBを導入していますので、その設定もここで行います。

// src/lib/database.ts
import { PrismaClient, Prisma } from "@prisma/client";
import { readReplicas } from "@prisma/extension-read-replicas";

const globalForPrisma = global as typeof globalThis & { prisma?: PrismaClient };

const basePrisma = new PrismaClient({
  log:
    process.env.NODE_ENV === "development"
      ? ["query", "info", "warn", "error"]
      : ["error"],
});

export const prisma =
  globalForPrisma.prisma ||
  (basePrisma.$extends(
    readReplicas({
      url: process.env.DATABASE_URL_REPLICA!,
    }),
  ) as unknown as PrismaClient);

if (process.env.NODE_ENV !== "production") globalForPrisma.prisma = prisma;

//  Prismaの型もエクスポート
export { Prisma };

上記については、 Prisma × PostgreSQLで始めるユーザー・ロール管理 でも詳しく記載していますので参照ください。今回は、リードレプリカDBを扱うための設定をしています。リードレプリカの用の設定については、 【自サーバでNext.jsアプリを動かす#5】リードレプリカ（スレーブ）DBの利用 を参照ください。

セッション解決ユーティリティ（`src/lib/auth/session.ts`）

jti から Session を引き、期限／失効を確認します。次回記事で Context 注入に使う getSessionUser の土台にもなります（ここでは最小限）。

// src/lib/auth/session.ts
import { verifySessionJwt } from "./jwt";
import { cookies } from "next/headers";
import { prisma } from "@/lib/database";

const COOKIE_NAME = process.env.SESSION_COOKIE_NAME ?? "session";

export type SessionLookupResult =
  | { ok: true; sessionId: string; userId: string }
  | { ok: false };

export async function lookupSessionFromCookie(): Promise<SessionLookupResult> {
  const jar = await cookies();
  const token = jar.get(COOKIE_NAME)?.value;
  if (!token) return { ok: false };

  try {
    const { jti } = await verifySessionJwt(token);
    const session = await prisma.session.findUnique({
      where: { id: jti },
      select: { id: true, userId: true, expiresAt: true, revokedAt: true },
    });
    if (!session) return { ok: false };
    if (session.revokedAt) return { ok: false };
    if (session.expiresAt.getTime() <= Date.now()) return { ok: false };
    return { ok: true, sessionId: session.id, userId: session.userId };
  } catch {
    return { ok: false };
  }
}

解説

Cookie → JWT 検証 → Session 存在/期限/失効を確認して結果を返します。
次回記事（Context注入）で、この userId から User/Role/Department を JOIN 取得する実装へ拡張します。

loginAction の実装（`src/app/_actions/auth/login.ts`）

サーバアクションでログイン成立までを実装します。 ロック判定 （5回/15分）、 項目別エラー 、 列挙検知時の曖昧化 に対応します。

// 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";

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) ダッシュボードへ
  redirect("/dashboard");
}

解説

バリデーション → 部署/ユーザ特定 → ロック検査 → パス検証 → カウンタ更新 → セッション発行の順で実装。
失敗時は原則「項目別エラー」を返しますが、閾値接近時は曖昧メッセージに切替（列挙耐性）。
成功時は Session を作成し、jti を入れた JWT を Cookie に保存して /dashboard へ redirect。
failedLoginCount / lockedUntil は 2章で追加したカラムを使用します。

.envへの関連パラメータ追加

env

# 失敗ロック関連
LOCK_THRESHOLD=5
LOCK_MINUTES=15

# 曖昧化モード（任意）
# detailed: 項目別エラー / ambiguous: 常に曖昧メッセージ
AUTH_ERROR_MODE=ambiguous

認証まで進んだ段階で項目別にエラーを返すのは、UXとしては良いと思うのですが、あまり具体的にエラー内容がわかるのもセキュリティ面では良くないと思い、曖昧なメッセージを表示するようにしました。AUTH_ERROR_MODE=detailedにすれば、項目別のエラーが表示されるように変更可能です。

logoutAction の実装（`src/app/_actions/auth/logout.ts`）

現在のセッションを失効（revokedAt 更新）し、Cookie を削除して /login に戻します。

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

import { prisma } from "@/lib/database";
import { cookies } from "next/headers";
import { clearSessionCookie } from "@/lib/auth/cookies";
import { verifySessionJwt } from "@/lib/auth/jwt";
import { redirect } from "next/navigation";

const COOKIE_NAME = process.env.SESSION_COOKIE_NAME ?? "session";

export async function logoutAction() {
  const jar = await cookies();
  const token = jar.get(COOKIE_NAME)?.value;
  if (token) {
    try {
      const { jti } = await verifySessionJwt(token);
      await prisma.session.update({
        where: { id: jti },
        data: { revokedAt: new Date() },
      });
    } catch {
      // 署名エラーや期限切れは無視してCookieだけ消す
    }
  }
  await clearSessionCookie();
  redirect("/");
}

解説

JWT が検証可能なら Session.revokedAt を更新して即時失効します。
期限切れや壊れたトークンでも、Cookie を消せばログアウト動作としては十分です。

ログインフォームをサーバアクションに接続

既存の src/components/login/login-form.tsx の onSubmit を、loginAction 呼び出しに差し替えます。フォーム側で項目別エラーを受け取り、画面に反映します（成功時はサーバ側で redirect されるため、クライアント側の遷移は不要）。

tsx

// src/components/login/login-form.tsx
"use client";

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 {
  Form,
  FormField,
  FormItem,
  FormLabel,
  FormControl,
  FormMessage,
} from "@/components/ui/form";
import { Input } from "@/components/ui/input";
import { Button } from "@/components/ui/button";
import { Eye, EyeOff } from "lucide-react";

type LoginValues = z.infer<typeof loginSchema>;

export default function LoginForm() {
  const [pending, startTransition] = useTransition();
  const [globalError, setGlobalError] = useState<string | null>(null);

  const form = useForm<LoginValues>({
    resolver: zodResolver(loginSchema),
    defaultValues: { accountId: "", email: "", password: "" },
    mode: "onSubmit",
  });

  const [showPassword, setShowPassword] = useState(false);

  const onSubmit = (values: LoginValues) => {
    setGlobalError(null);

    // 送信中の2重送信防止（任意）
    if (pending) return;

    startTransition(async () => {
      // サーバアクション呼び出し
      const res = await loginAction({
        accountId: values.accountId,
        email: values.email,
        password: values.password,
      });

      if (!res || !("ok" in res)) {
        setGlobalError(
          "予期せぬエラーが発生しました。時間をおいて再試行してください。",
        );
        return;
      }

      if (!res.ok) {
        // 項目別エラーを formState に注入（既存の <FormMessage /> が拾う）
        if (res.fieldErrors) {
          for (const [field, message] of Object.entries(res.fieldErrors)) {
            // message が undefined の場合でも空文字は避ける
            if (message) {
              form.setError(field as keyof LoginValues, {
                type: "server",
                message,
              });
            }
          }
        }
        // 全体エラー（ロック/曖昧メッセージなど）はグローバルに表示
        if (res.message) setGlobalError(res.message);
        return;
      }

      // 成功時：サーバ側で redirect("/dashboard") 済みのため、ここには戻らない想定
    });
  };

  return (
    <Form {...form}>
      <form
        onSubmit={form.handleSubmit(onSubmit)}
        noValidate
        className="mx-auto max-w-md space-y-4 pt-4 pb-10"
      >
        <FormField
          control={form.control}
          name="accountId"
          render={({ field }) => (
            <FormItem>
              <FormLabel>アカウントID</FormLabel>
              <FormControl>
                <Input
                  data-testid="accountId"
                  placeholder="CoRP000123456"
                  autoFocus
                  aria-invalid={!!form.formState.errors.accountId}
                  disabled={pending}
                  {...field}
                />
              </FormControl>
              <FormMessage data-testid="accountId-error" />
            </FormItem>
          )}
        />
        <FormField
          control={form.control}
          name="email"
          render={({ field }) => (
            <FormItem>
              <FormLabel>メールアドレス</FormLabel>
              <FormControl>
                <Input
                  data-testid="email"
                  type="email"
                  autoComplete="email"
                  placeholder="your@email.com"
                  aria-invalid={!!form.formState.errors.email}
                  disabled={pending}
                  {...field}
                />
              </FormControl>
              <FormMessage data-testid="email-error" />
            </FormItem>
          )}
        />
        <FormField
          control={form.control}
          name="password"
          render={({ field }) => (
            <FormItem>
              <FormLabel>パスワード</FormLabel>
              <div className="flex items-start gap-2">
                <FormControl>
                  <Input
                    {...field}
                    data-testid="password"
                    type={showPassword ? "text" : "password"}
                    autoComplete="current-password"
                    placeholder="半角英数字15文字以上"
                    aria-invalid={!!form.formState.errors.password}
                    disabled={pending}
                  />
                </FormControl>
                <Button
                  data-testid="password-toggle"
                  type="button"
                  size="icon"
                  variant="outline"
                  onClick={() => setShowPassword((prev) => !prev)}
                  aria-label={
                    showPassword
                      ? "パスワードを非表示にする"
                      : "パスワードを表示する"
                  }
                  className="shrink-0 cursor-pointer"
                >
                  {showPassword ? <EyeOff size={18} /> : <Eye size={18} />}
                </Button>
              </div>
              <FormMessage data-testid="password-error" />
            </FormItem>
          )}
        />
        {/* グローバルメッセージ（ロック/曖昧メッセージなど） */}
        {globalError && (
          <p className="mt-2 text-sm text-red-500" data-testid="global-error">
            {globalError}
          </p>
        )}

        <Button
          data-testid="submit"
          type="submit"
          className="mt-4 w-full cursor-pointer"
          disabled={pending}
        >
          {pending ? "ログイン中..." : "ログイン"}
        </Button>
      </form>
    </Form>
  );
}

解説

loginAction の戻りを見て、フィールド別エラーは form.setError、曖昧メッセージは globalError として表示。
成功時はサーバ側がリダイレクトするため、クライアント側での router.push は不要です。
useTransition() の pending を使い、送信ボタンを無効化しつつラベルを「ログイン中…」に切替。
サーバアクションの戻りで fieldErrors を form.setError へ流し込み、既存の <FormMessage /> がそのまま表示。
項目に紐づかないメッセージは globalError に格納して <p data-testid="global-error"> に表示。
フォームは noValidate を付けてブラウザネイティブのバリデーションポップアップを抑止（UIを統一）。
aria-invalid を正しく付与（アクセシビリティ配慮）。

ログアウトをサーバアクションに接続

既存の src/components/sidebar/nav-user.tsxにログアウト導線があります。NavUser の「ログアウト」を サーバアクション logoutAction に直結 します。useTransition で二重押下を防ぎつつ、処理完了時はサーバ側の redirect("/login") が発火します。Link は使いません。

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 type { User } from "@/lib/sidebar/mock-user";
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";

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

  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="ユーザーメニューを開く"
            >
              <Avatar className="h-8 w-8 rounded-lg">
                {/* 画像は next/image でもOKだが AvatarImage で十分 */}
                <AvatarImage src={user.avatar} alt={user.name} />
                <AvatarFallback className="rounded-lg">
                  {user.name.slice(0, 1)}
                </AvatarFallback>
              </Avatar>
              <div className="grid flex-1 text-left text-sm leading-tight">
                <span className="truncate font-medium">{user.name}</span>
                <span className="text-muted-foreground truncate text-xs">
                  {user.email}
                </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={user.avatar} alt={user.name} />
                  <AvatarFallback className="rounded-lg">
                    {user.name.slice(0, 1)}
                  </AvatarFallback>
                </Avatar>
                <div className="grid flex-1 text-left text-sm leading-tight">
                  <span className="truncate font-medium">{user.name}</span>
                  <span className="text-muted-foreground truncate text-xs">
                    {user.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>
  );
}

補足

logoutAction はサーバ側で Session.revokedAt 更新 → Cookie削除 → redirect("/login") まで行うため、クライアント側で router.push は不要です。
disabled={pending} と aria-disabled を付けて、連打防止とA11y を確保しています。
もしゼロJSで運用したい場合は、<form action={logoutAction}> + <button type="submit">ログアウト</button> でもOKですが、今回の UI（DropdownMenuItem）に合わせて onClick 方式にしています。

動作確認のポイント

以下の観点で手動確認します（E2E は今回は対象外）。

観点	確認内容
正常系	正しい `Department.code + email + password` で `/dashboard` へ遷移する
形式不正	アカウントID/パスが形式外のとき、DBアクセス前にフォームエラーになる
項目別エラー	部署不一致／メール不一致／パス不一致でそれぞれエラー表示
ロック	連続5回失敗でロック→ロック中メッセージが表示される
曖昧化	閾値接近時に曖昧メッセージへ切替される
Cookie	`session` Cookie（httpOnly/secure/sameSite=lax）が設定される
セッション	`Session` テーブルにレコード作成・ログアウトで `revokedAt` が入る

以上で、 サーバアクション中心のログイン実装 が完了です。次章では middleware とルート保護の実装を行い、未ログイン時のアクセス制御を仕上げます。

4. middleware とルート保護の実装

この章では、ログイン済みユーザーだけが管理画面にアクセスできるようにする仕組みを構築します。
方針は以下の通りです。

middleware は「早期蹴り（未認証ユーザーを即座に / にリダイレクトする）」のみに利用
セッションの実体確認やユーザー情報の解決は Server Action で行う
ログインページは /、ログイン後の画面は src/app/(protected) 配下にまとめて保護する

これにより、APIを用いずにシンプルかつ安全 な保護が実現できます。

ディレクトリ構成の確認

まず、ルート構造と保護対象を整理します。

txt

/project-root
├─ src/
│  ├─ app/
│  │  ├─ (protected)/
│  │  │  ├─ dashboard/
│  │  │  ├─ users/
│  │  │  └─ profile/
│  │  │     └─ password/
│  │  └─ page.tsx     # ログインページ (/)
│  └─ lib/
│  │  └─ auth/
│  │  ├─ jwt.ts
│  │  ├─ cookies.ts
│  │  └─ session.ts
│  └─ middleware.ts

つまり、(protected) 配下はすべて「認証必須」とし、middleware で早期判定を行います。

middleware での早期蹴り

middleware.ts では Cookie 内の JWT を検証し、期限切れ or 無効な場合は / にリダイレクト します。
ここでは 署名と exp のみ を確認し、DB照会は行いません。これにより「明らかに無効なリクエスト」を早期に排除し、DB負荷を下げます。

middleware.ts は srcディレクトリ を採用しているときは プロジェクト直下ではなく 、 srcディレクトリ直下 に配置しないと動かないので注意する必要があります。

// src/middleware.ts（src/直下）
import { NextResponse } from "next/server";
import type { NextRequest } from "next/server";
import { verifySessionJwt } from "@/lib/auth/jwt";

const LOGIN_PATH = "/";

// 実際の公開パス（(protected)配下の各ルートのパスを列挙）
const PROTECTED_PATHS = [
  "/changelog",
  "/dashboard",
  "/masters",
  "/tutorial",
  "/users",
  "/profile",
];

export async function middleware(req: NextRequest) {
  const { pathname } = req.nextUrl;

  // いずれかの保護パスで始まる場合のみチェック
  if (PROTECTED_PATHS.some((p) => pathname.startsWith(p))) {
    const token = req.cookies.get(
      process.env.SESSION_COOKIE_NAME ?? "session",
    )?.value;
    if (!token) return NextResponse.redirect(new URL(LOGIN_PATH, req.url));

    try {
      await verifySessionJwt(token); // 署名とexpのみ
      return NextResponse.next();
    } catch {
      return NextResponse.redirect(new URL(LOGIN_PATH, req.url));
    }
  }
  return NextResponse.next();
}

export const config = {
  matcher: [
    "/changelog/:path*",
    "/dashboard/:path*",
    "/masters/:path*",
    "/tutorial/:path*",
    "/users/:path*",
    "/profile/:path*",
  ],
};

上記コードのポイント:

処理	内容
`pathname.startsWith(PROTECTED_PREFIX)`	`(protected)` 配下のみに適用
Cookie チェック	`SESSION_COOKIE_NAME`（デフォルト: `"session"`）を取得
JWT 検証	署名と期限のみ確認（DBアクセスなし）
失敗時	即座に `/` へリダイレクト

これにより「明らかに期限切れ・偽造されたトークン」はDBを叩かずに早期拒否されます。

Server Action 側での完全検証

middleware はあくまで「早期蹴り」。実際の処理では DBに存在するセッションかどうか を必ず確認します。

そのため、3章で作成したsrc/lib/auth/session.ts の lookupSessionFromCookie を用いて、User 情報解決まで を行います。

// src/lib/auth/session.ts（3章で作成済み）
import { verifySessionJwt } from "./jwt";
import { cookies } from "next/headers";
import { PrismaClient } from "@prisma/client";

const prisma = new PrismaClient();
const COOKIE_NAME = process.env.SESSION_COOKIE_NAME ?? "session";

export type SessionLookupResult =
  | { ok: true; sessionId: string; userId: string }
  | { ok: false };

export async function lookupSessionFromCookie(): Promise<SessionLookupResult> {
  const jar = await cookies();
  const token = jar.get(COOKIE_NAME)?.value;
  if (!token) return { ok: false };

  try {
    const { jti } = await verifySessionJwt(token);
    const session = await prisma.session.findUnique({
      where: { id: jti },
      select: { id: true, userId: true, expiresAt: true, revokedAt: true },
    });
    if (!session) return { ok: false };
    if (session.revokedAt) return { ok: false };
    if (session.expiresAt.getTime() <= Date.now()) return { ok: false };
    return { ok: true, sessionId: session.id, userId: session.userId };
  } catch {
    return { ok: false };
  }
}

この関数を Server Action や Page Server Component 内で呼び出すことで、常に有効なユーザーだけ が操作対象になります。

まとめると次のように役割分担します。

層	役割
middleware	期限切れ・不正トークンの早期拒否
lookupSessionFromCookie() (Server Action)	DBと照合し、セッション失効やユーザー無効を確認

これにより、UX とセキュリティを両立できます。

実際の利用例

ダッシュボードページを例に、ログイン済みユーザーを必須とするコードは次のようになります。

tsx

// src/app/(protected)/dashboard/page.tsx
import { redirect } from "next/navigation"; // 追加
import { lookupSessionFromCookie } from "@/lib/auth/session"; // 追加

import type { Metadata } from "next";
import Link from "next/link";

// ──省略

// function に async を追加
export default async function DashboardPage() {

// 下記を追記
  const session = await lookupSessionFromCookie();
  if (!session.ok) {
    redirect("/");  // 未ログインはログインページ（/）へ
  }

// ──省略

このように page.tsx の先頭 で lookupSessionFromCookie() を呼びます。
セッションが不正ならすぐ redirect("/")。
有効なら session.userId を使って必要なデータをフェッチしたり、UI に渡せます。

少し面倒ですが、src/app/(protected)配下のpage.tsxとnot-found.tsxに上記のように追記しておきます。

ここまでで、今回の目標は達成です。

5. まとめと次回予告

本記事では、ログイン機能の完成形として「サーバアクションによるログイン／ログアウト」「セッション管理」「middlewareでの早期蹴り」「ルート保護」を一通り実装しました。ここで一度全体を整理し、次回以降の展開につなげます。

本記事で実現したこと

今回の実装で達成したポイントを表にまとめます。

項目	実装内容	ポイント
ログイン処理	`loginAction`でDB照合・JWT発行・Cookie保存	5回連続失敗でロック、曖昧エラーメッセージ切替
セッション管理	`Session`テーブルを導入、JWTはjtiのみ	即時失効・権限変更の即時反映が可能
ログアウト処理	`logoutAction`で`revokedAt`更新＋Cookie削除	即時失効とUXの両立
middleware	JWT署名とexpのみを検証	DBを叩かず不正トークンを早期排除
ルート保護	`(protected)`配下を一括保護、`page.tsx`で最終確認	Server Actionで完全なDB検証

実装アーキテクチャの整理

ここまでの構成を、役割ごとに簡易図で示します。

txt

[LoginForm] --(server action)--> [loginAction]
    ├─ 部署/ユーザ特定
    ├─ パスワード照合
    ├─ ロック判定・カウント更新
    ├─ Session作成
    └─ JWT発行 → Cookie保存

[middleware]
    ├─ CookieのJWT署名・期限確認
    └─ NGなら即 ログイン画面 へredirect

[(protected)/page.tsx]
    ├─ lookupSessionFromCookie()
    ├─ Session有効性(DB)検証
    └─ OKなら画面表示 / NGなら ログイン画面

次回予告

次回の記事では、ログイン済みユーザー情報をアプリ全体で共有できるようにします。
具体的には、AuthProviderを導入し、Context経由でユーザー情報・ロール情報をコンポーネント全体から利用可能にします。

テーマ	内容
Context注入	`lookupSessionFromCookie`を用いてUser/Role情報を解決し、Contextに格納
メニュー制御	Sidebarのメニューをロールに応じて動的表示
画面制御	ページ単位のRBACを可能にし、認可レベルを整理

参考文献

今回の記事執筆にあたり、以下のドキュメントや記事を参考にしました。
リンクはすべて公式または信頼性の高い技術情報源です。

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

松本孝太郎

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

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

この記事の更新履歴

2025/11/6
デモ環境とGithubリポジトリについての記述を追加
2025/9/25
src/lib/login/schema.tsのメールアドレスのバリデーション部分を preprocess からtransform + pipe へ変更
2025/9/21
メールアドレスの日本語ドメイン対応のため、punycodeを利用した変換対応を追加:src/lib/login/server-schema.ts
2025/9/19
ログイン関連のサーバアクションファイルのディレクトリを調整: src/app/_actions/ → src/app/_actions/auth/
2025/9/18
middleware.tsの配置をsrc/middleware.tsに修正。/src/appの構成の場合、srcディレクトリ直下に配置しないと機能しません。
2025/9/12
DB接続用のライブラリ（src/lib/database.ts）を作成したので、3章に記述を追記して、サーバアクションとセッションのDBアクセス部分を変更
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公開

管理画面フォーマット開発編 #2JWT +Cookie＋middlewareで実装するログイン機能