個人開発の 「認可」 は最初が 9 割。 手戻りゼロの最小設計 〜 認証と認可、 後回しにして積まないための実装ガイド 〜

「認可なんて、機能ができてから制限かければいいでしょ？」

かつての僕は、本気でそう思っていました。
ログイン機能（認証）さえあれば、あとは `if (user.isAdmin)` を画面にちょこっと書けばいい。
そう高を括っていたのです。

しかし、個人開発アプリのリリース直前、僕は絶望することになります。

「あれ、この API、管理者以外も叩けるぞ……？」
「管理者画面のレイアウトを変えたら、一般ユーザーの画面が壊れた」
「DB スキーマに Role を足そうとしたら、マイグレーションでデータ整合性が……」

積み上げたコードの至る所に、後付けの `if` 文がツタのように絡みつき、リファクタリングもできない「スパゲッティ状態」になっていたのです。
結局、僕は泣きながら主要なロジックを書き直す羽目になりました。

「認可（Authorization）」は、後付けできません。
いえ、正確には「後付けすると、コストが 10 倍になる」のです。

今日は、僕のような失敗をしないために、個人開発における「認証」と「認可」の最小設計と、Next.js (App Router) + NextAuth.js (v5) + Prisma での実装パターンを共有します。
これさえ最初に決めておけば、もう手戻りに怯えることはありません。

「認証」 と 「認可」 は、 似て非なるもの

まず、初心者が（そして過去の僕が）混同しがちなこの 2 つを整理します。

僕の失敗は、「認証（ログイン）」さえあればなんとかなると思っていたことでした。
しかし、システムを守る「門番」は、ID カードを確認するだけでは不十分なのです。
「この人はこの部屋に入っていいのか？」という権限チェックがなければ、セキュリティホールだらけになってしまいます。

なぜ 「後回し」 が地獄を招くのか

「とりあえず動くものを作る」という精神は、個人開発において尊いものです。
しかし、「データ構造」と「セキュリティ境界」だけは例外です。

認可を後回しにすると、以下のような地獄が待っています。

最初に 「マトリクス」 を作るだけでいい

では、どうすればいいのか。
コードを書く前に、「誰が」「何を」「どうできるか」の表（マトリクス） を作るだけです。

| Role | 記事閲覧 | 記事投稿 | ユーザー管理 |
| :--- | :---: | :---: | :---: |
| GUEST | ✅ | ❌ | ❌ |
| USER | ✅ | ✅ (自分ののみ) | ❌ |
| ADMIN | ✅ | ✅ (全て) | ✅ |

これさえあれば、迷うことはありません。
複雑な権限管理ライブラリを入れる必要もありません。
個人開発なら、この表をコードに落とし込むだけで十分なのです。

ここからはメンバーシップ限定エリアです。

「じゃあ、具体的にどう実装するの？」
「Next.js の App Router で、どこにガードを置けばいいの？」

そんな疑問に答えるために、Next.js + NextAuth (v5) + Prisma を使った具体的な実装パターンを公開します。
僕が実際に使っている 「コピペで使える schema.prisma と Middleware 設定」、そして 「Server Actions を守るための高階関数」 を用意しました。

これを知っているだけで、開発スピードと安心感が段違いに変わります。