フレームワークが設計判断を肩代わりしてくれる問題
Next.js は優秀なフレームワークだ。ルーティングはファイルベースで自動、API は Route Handlers に書けばエンドポイントになる。画像最適化、コード分割、SSR/SSG の切り替え — 考えなくても、いい感じにしてくれる。
でも「なぜその構成なのか？」と聞かれると、答えに詰まる。
- 「なぜ SPA ではなく SSR にしたのか？」→ Next.js がデフォルトでそうなっているから
- 「フロントとバックの型共有はどうしている？」→ 同じプロジェクトだから特に考えていない
- 「認証フローの設計は？」→ NextAuth.js がやってくれている
動くものは作れる。でも、設計判断をしているのは自分ではなくフレームワークだった。
これは Next.js が悪いという話ではない。フレームワークの仕事は、よくある設計判断をデフォルトとして提供し、開発者が本質的な問題に集中できるようにすること。その設計は正しい。
問題は、自分がそのデフォルトに乗っかっているだけで、なぜそうなっているかを理解していなかったこと。
「魔法を外す」とは何か
Next.js がやってくれていることを分解すると、こうなる:
| Next.js がやってくれること | 自分でやると |
|---|---|
| ファイルベースルーティング | React Router などで明示的に定義 |
| API Routes（同一プロジェクト内） | 独立したバックエンドサーバーを立てる |
| フロント/バックの型共有 | モノレポの設計（workspaces） |
| 認証（NextAuth.js） | JWT の発行・検証を自分で配線 |
| CORS 不要（同一オリジン） | 別オリジンなので CORS 設定が必要 |
| ビルド・最適化 | Vite の設定を自分で書く |
「魔法を外す」とは、これらを自分で1つずつ設計・実装することで、フレームワークが隠していた設計判断を自分の手で経験すること。
なぜ会計システムなのか
技術の学びが目的なら、何を作ってもいい。会計システムを選んだのは、設計判断が多いから。
- DB 設計: 複式簿記のデータモデル（正規化、ENUM、金額の型）
- マルチテナント: 組織ごとのデータ隔離（RLS）
- 認証・認可: 誰がどの組織のデータにアクセスできるか
- バリデーション: 借方と貸方の合計が一致するか、業務ルールの検証
TODO アプリでは CRUD の練習にはなるが、設計判断が少なすぎる。会計というドメインは、技術スタックの選定からテーブル設計まで「なぜそうするか」を考える場面が多い。
技術スタック
| レイヤー | 技術 | 選定理由 |
|---|---|---|
| フロントエンド | React + Vite (SPA) | Next.js の自動最適化に頼らず、状態管理・ルーティングを自分で設計する |
| バックエンド | Hono (TypeScript) | 独立したバックエンドでミドルウェア・エラーハンドリングの設計パターンを理解する |
| データベース | Supabase (PostgreSQL) | RLS・マルチテナント設計を深める。ローカル Docker 環境で開発 |
| パッケージ管理 | pnpm workspaces | フロント/バックの型共有をモノレポで実現する |
ポイントは React を使わないのではなく、React を「道具」として使うこと。フレームワークが隠していたレイヤー（ルーティング、認証、API 設計）を自分で組み、React は UI の構築に専念させる。
このシリーズで書くこと
| # | テーマ | 扱う内容 |
|---|---|---|
| 1 | モノレポ + Hono | pnpm workspaces による型共有、Hono の最小構成 |
| 2 | 認証フロー | Supabase Auth + JWT ミドルウェア、CORS |
| 3 | DB 設計 + RLS | 複式簿記のスキーマ設計、マルチテナントの行レベルセキュリティ |
各記事では、実装だけでなく 「なぜその方法を選んだか」「他にどんな選択肢があったか」 を必ず書く。動くコードは GitHub にもある。この記事シリーズの価値は、コードそのものよりも設計判断の過程にある。
では、次の記事からモノレポ構成とバックエンドの構築に入る。