私は実務で、「最初に決めなかったこと」が原因の修正や、Lintエラーの山、ぐちゃぐちゃになったディレクトリ構造を何度も見てきました。本記事では、プロの現場でそのまま採用できる Next.js (App Router) の環境構築手順を、「なぜその設定が必要なのか」という理由と共にまとめます。
1. 開発環境の前提（Node.js と パッケージマネージャ）#
環境構築トラブルの 8 割は、Node.js のバージョン不一致に起因します。
Node.js バージョンの固定#
.nvmrc または .node-version をプロジェクトルートに作成し、LTSバージョン（例：v20.x）を明記します。これにより、チーム全員が同じランタイムで開発することを保証します。
node -v > .node-versionパッケージマネージャの選定#
実務では、インストール速度とディスク効率に優れた pnpm または、標準の npm を推奨します。package-lock.json（または pnpm-lock.yaml）を必ずリポジトリに含め、環境差異を排除します。
2. create-next-app と プロフェッショナルな選択肢#
npx create-next-app@latest実務プロジェクトでは、以下の選択を強く推奨します。
- TypeScript: Yes: 型安全なしでの現代的な開発は不可能です。
- ESLint: Yes: 構文チェックの自動化。
- Tailwind CSS: Yes: （プロジェクト方針によりますが）標準的なUI構築の加速。
- src/ directory: Yes: ルートディレクトリを汚さず、設定ファイルとソースコードを明確に分離できます。
- App Router: Yes: 現在の Next.js の標準かつ推奨アーキテクチャ。
- Import Alias: Yes (@/*): 深い階層の相対パス（
../../../../）を排除し、コードの可読性を高めます。
3. 保守性を高める「3つの初期設定」#
① TypeScript の厳格化#
tsconfig.json の compilerOptions に noImplicitAny: true や exactOptionalPropertyTypes: true を追加（またはデフォルトの strict: true を確認）し、型の曖昧さを排除します。
② Prettier の導入と統合#
コードフォーマットの自動化は、コードレビューの時間を「本質的なロジック」に集中させるために不可欠です。
npm install -D prettier eslint-config-prettier③ Husky & lint-staged による「品質の強制」#
「Lintエラーがあるコードをコミットさせない」仕組みを作ります。
npx husky-init && npm install
npm install -D lint-stagedpackage.json に設定を記述することで、コミット直前に自動的にフォーマットとチェックが走るようになります。
4. 現場で採用される「src/ フォルダ内」のディレクトリ設計#
App Router環境において、app/ フォルダは「ルーティング」に特化させ、実体となる部品は components/ や features/ に逃がすのが定石です。
src/
├─ app/ # ルーティング定義、Server Components
├─ components/ # 汎用的な共通UI部品（ボタン、入力欄等）
├─ features/ # 機能単位の構成（例: features/auth, features/posts）
├─ hooks/ # 汎用的なカスタムフック
├─ lib/ # 外部ライブラリの設定（Prisma, Supabase等）
├─ types/ # 共通の型定義
└─ utils/ # 純粋な関数（計算、フォーマット等）5. 環境変数の「型安全」を確保する#
process.env.API_KEY が undefined かもしれないという不安を解消するため、起動時に環境変数を検証する仕組み（例：t3-env ライブラリの思想）を取り入れます。これにより、環境変数の設定漏れがあった場合にビルドを即座に失敗させることができます。
まとめ：最初の1時間がプロジェクトの寿命を決める#
環境構築は「開発を始めるための儀式」ではなく、**「プロジェクトの品質と速度の下支えを作る工程」**です。
- ツールによる自動化（Lint/Prettier/Husky）
- 型による防衛（Strict TypeScript）
- 設計による整理（Directory Structure）
この3本柱を最初に立てることで、数ヶ月後の自分やチームメンバーが「使いやすく、壊れにくい」と感じる最高の開発環境が完成します。
