【2025版】Next.js 最適フォルダ(ディレクトリ)構成・設計の話

Next.jsに悩んでる人へ！

Next.jsを勉強している人やNext.jsを開発で使っている人、あとは
最近流行りのAI駆動開発でよくNext.jsのコードが出るから気になった人などなど...
Next.jsに触れる機会が多くなって、使い方や効率的な方法を探している人もいるかと思ったので、
そこで今回は、僕が採用しているディレクトリ(フォルダ)構成を共有します。この記事がNext.jsのディレクトリ構成に悩む開発者の助けになれば幸いです。

また、「コレが正解だぁ！」ってわけじゃないので、
「私はこういうディレクトリー構成です」って人は是非教えてください！
※Next.js 15,App routerでのお話になります。

---

自己紹介

どうも！現役でエンジニアやってるやむぅ。です！フリーランスエンジニアとして働きながら、「個人サービス運営」「エンジニア教育」「YouTube発信」この三つを主軸に活動しています。直近では、「YouTubeをNuxt x FastAPI x MySQLで作ってみた」をしました。

僕がエンジニアとして、失敗したことや上手くいったこと、実際に行動したことなどをもとに書いてるので、ぜひ参考にしてください！

Next.js最適ディレクトリ構成【2025年版】

next-project/
├── app/
│   ├── api/
│   │   └── hello/
│   │       └── route.ts
│   ├── actions/
│   │   └── aaa-action.ts
│   └── page.tsx
├── components/
├── hooks/
├── lib/
├── utils/
├── styles/
├── types/
├── stores/
├── constants/
├── public/
│
├── next.config.js
├── package.json
└── tsconfig.json

解説

app

├── app/
│   ├── api/
│   │   └── hello/
│   │       └── route.ts ←/api/helloのAPIを実装
│   ├── actions/
│   │   ├── aaa-action.ts ←サーバーアクションを実装
│   │   └── hello-action.ts ←APIを作らずにここで実装することも可能
│   ├── page1/
│   │   ├── [id]/
│   │   │   ├── page.module.css ←個別のCSSの実装
│   │   │   ├── actions.css ←個別でサーバーアクションの実装も可能
│   │   │   └── page.tsx ←/page1/1とかのページを実装
│   │   ├── page.module.css
│   │   └── page.tsx ←/page1のページを実装
│   ├── page.tsx ←/のページを実装
│   ├── loading.tsx ←ロード中ページを実装
│   ├── layout.tsx ←全体レイアウトを実装
│   └── globals.css ←全体のcssを実装

Next.js 13で導入されたappディレクトリ。以前の「pages」のようなもので、主にアプリケーションのエントリーポイントになる。server components・server actionsも置けるのがappの強いところ。より直感的で管理しやすいアプリケーション構造を実現することができる。

components

├── components/
│   ├── atoms/ ←一番小さな部品はここ
│   │   ├── osha-icon/
│   │   ├── osha-label/
│   │   ├── osha-input/
│   │   └── osha-button/
│   │       ├── page.tsx ←そのコンポのUIを実装(名前はpage.tsx固定)
│   │       ├── button.module.css ←そのコンポのcssを実装(頭の名前はbuttonじゃなくてもOK)
│   │       └── button.test.tsx ←テストを書くなら僕はここ
│   ├── molecules/ ←atomsの集合体のイメージ
│   │   └── osha-input-cell/ ←osha-inputとosha-buttonを組み合わせた入力パーツ
│   │       ├── page.tsx
│   │       └── 〜
│   ├── organisms/ ←moleculesとかの集合体のイメージ
│   │   └── osha-input-form/ ←osha-input-cellを集めた入力フォームパーツ
│   │       ├── page.tsx
│   │       └── 〜
│   └── templetes/ ←organismsとかの集合体のイメージ
│       └── osha-contact-form/ ←osha-input-formをつかったお問い合わせフォーム
│           ├── page.tsx
│           ├── button.module.css
│           └── button.test.tsx

componentsディレクトリは、よく使う部品を置く場所です。詳しくいうと、再利用可能なUIコンポーネントとレイアウト関連のコンポーネントを格納します。僕は基本的にAtomic Designを使っています。これに関しては以下の記事がめちゃくちゃわかりやすい&イメージしやすいです。
https://zenn.dev/bizlink/articles/b5c8985af8407a
https://qiita.com/Kazuhiro_Mimaki/items/3d9a8594064aab5119da

他にもNextでやってる人が多いのはもっとシンプルに、uiディレクトリにはボタンやカードなどの汎用的なUIコンポーネント(Atomsやギリmoleculesに当てはまるもの)、layoutディレクトリにはヘッダーやフッターなどのレイアウト関連のコンポーネント(モロmolecules以降のもの)を置くような書き方もあります。
どちらにせよ、汎用的に部品として使えるような構造でわかりやすければそれでOKです！

hooks

├── hooks/
│   ├── use-mobile.tsx ←画面サイズがモバイルの時の処理とか
│   ├── supabase/ ←フォルダーでまとめることも可能
│   │   ├── use-auth.tsx ←認証系の処理
│   │   └── use-user.tsx ←ユーザーのCRUD処理とか

hooksディレクトリは、よく使う処理・機能のうちuse~を使うものを置きます。詳しくいうと、カスタムフックを格納するための場所です。再利用可能なロジックをここで定義しておくことで、コードの重複を避け、スッキリできます。

lib

├── lib/
│   ├── library-A/ ←library-Aに関するもの
│   │   └── config.ts ←初期設定用コード
│   ├── library-B/ ←library-Bに関するもの
│   └── (utils.ts ※後述するutilsを一個にまとめてここに置く人もいる)

libディレクトリは、使用しているライブラリ固有のコード、初期化や設定のコードなどを配置します。
ライブラリ毎に分けて書くと管理しやすい。

utils

├── utils/
│   ├── dates.ts ←日付に関する処理
│   └── texts.ts ←文字に関する処理

utilsディレクトリは、よく使う処理・機能のうちuse~を使わないものを置きます。詳しくいうとユーティリティ関数をここに配置します。例えば、ランダム文字の生成や、日付をyyyy年mm日ddにする、などです。再利用可能なロジックをここで定義しておくことで、毎回同じような長いコードを書く必要がなくなります。

styles

├── styles/
│   ├── globals.css ←全体のcssをここで実装することも可能
│   └── theme.ts ←デザインに関する処理も書ける

stylesディレクトリは、グローバルなスタイルシートやテーマに関するファイルを置くことができます。ここで定義されたものは、アプリケーション全体に適用されます。
でも僕は、app配下にglobals.cssとかを直接置くのでこのstylesディレクトリはあんまり使いません。

types

├── types/
│   ├── aaa.d.ts ←aaaに関する型
│   ├── ui/ ←画面に関するもので分けることもできる
│   ├── api/ ←APIに関するもので分けることもできる
│   │   └──api-a.d.ts ←api-aに関する型
│   └── bbb.d.ts

typesディレクトリは、TypeScriptの型定義ファイルを格納します。アプリ内で使う型をここで一箇所で管理することで、画面で使うデータもAPIなどで処理するデータも型安全かつシンプルに扱えるようになります。

stores

├── stores/
│   ├── userStore.ts ←ユーザーに関する全体共有データについて
│   └── blogStore.ts ←ブログ情報に関する全体共有データについて

storesディレクトリは、グローバルステートの管理するためのコードを配置します。簡単にいうと、アプリケーション全体で共有されるデータを管理するためのものです。
僕はよくZustandを使うのでそれっぽい名前~Store.tsになっています。

constants

├── constants/
│   ├── A-constant.ts ←Aに関する固定値・定数
│   └── B-constant.ts ←Bに関する固定値・定数

constantsディレクトリは、固定値を置く場所です。

public

├── public/
│   ├── images/ ←画像系のものはここ
│   │   ├── favicon.ico ←app配下のものをここに置くこともできます
│   │   ├── user.png
│   │   └── logo.svg
│   └── fonts/ ←フォント系のものはここ

publicディレクトリは、静的なアセットを格納します。

featuresディレクトリいる？

まだ僕はあまりfeaturesディレクトリを入れたやり方をしていないので、今はいらないかなという印象です。

├── features/
│   ├── blog/ ←ブログの機能に関するものはここ
│   │   ├── api/
│   │   │   └── get-blog.ts
│   │   ├── stores/
│   │   ├── const/
│   │   ├── styles/
│   │   ├── components/
│   │   │   └── blog-card.tsx
│   │   ├── hooks/
│   │   └── types/
│   └── auth/ ←認証に関するものはここ

featuresディレクトリを使うと、ドメインを意識した開発ができるというのが僕の印象です。もうちょっと簡単にいうと「ロジック + コンポーネントをまとめたもの」として、特定の機能やドメインごとにAPIアクセスとかコンポーネントを実装できるので、機能ごとでの管理が容易になるようです。

そのため、今までの構成は「全体的に汎用的になるような構成(全体共通のcomponentsやhooks,storesが一箇所で管理)」だったが、featuresを使う場合は「機能ごとで個々に構成(全体共通のcomponentsやhooks,storesがなくなり、各所に散らばる)」になると感じました。

---

最後に：あなたもきっと、エンジニアになれる。

この投稿が少しでも役に立てたなら嬉しいです。

「もっと詳しく知りたい！」「プログラミング勉強したい！」「エンジニア目指してる！」という方は、YouTubeで入門動画やエンジニアのこぼれ話などを出しているので、ぜひみに来てください！

【告知】僕が1 on 1でプログラミング教えます👋

エンジニアのリアルを体験 & AIの使い方を網羅したカリキュラムを実際の開発案件をもとに作り上げました！
またスクール関係なしにも、プログラミングに興味ある・エンジニアを目指す方向けに、1on1で個別相談を実施しています。プログラミング初心者の方やリスキリングを考えている方はぜひ！https://programing-factory.raimuproject.com/lp