初めに
NestJSはアーキテクチャを強制しません。DI・モジュール・デコレータという「部品」だけ渡して、組み立て方は開発者に委ねます。この自由さがNestJSの強みであり、同時に「で、結局どう作ればいいの？」という迷いの原因でもあります。世の中に大量のボイラープレートが乱立しているのは、その答えがプロジェクトごとに違うからです。
この記事は、その迷いを「自分の状況 → 推奨アーキテクチャ → 参考になる実装」へと一本道でたどれる選定マップです。最初に結論（早見表）を置き、その後で判断の軸・各アーキの中身・技術スタックの選び方・実在OSSに学ぶポイントまで降りていきます。
想定バージョンは NestJS v11（Express v5 がデフォルト、Node.js 20+ 必須）。v12 はESM移行・Vitest/oxlint/Rspackへの刷新が予定されています（2026年Q3目標）。本記事のアーキ選定の考え方はバージョンに依存しません。
結論（早見表）
最初に身も蓋もないことを言うと、多くのプロジェクトの最善手は「標準モジュラー構成」か「モジュラーモノリス」 です。Clean Architecture / Hexagonal / CQRS / マイクロサービスは、それが必要になる「痛み」が出てから足すもので、Day 1から全部入れるのが一番ありがちな失敗です。
| あなたの状況 | 推奨アーキテクチャ | 参考になる実装 |
|---|---|---|
| PoC・ハッカソン・とにかく早く形に | 標準モジュラー（Nest CLIデフォルト） | Nest Hackathon Starter / NestJS Prisma Starter |
| スタートアップMVP・小〜中規模のREST API | レイヤード（Controller-Service-Repository） | brocoders / MonstarLab Starter / Awesome Nest Boilerplate |
| 中規模で成長見込み・ドメイン境界を保ちたい | モジュラーモノリス | brocoders（機能モジュール分割）/ Nx・Turborepo構成 |
| ビジネスルールが厚い・CRUDで収まらない | Clean Architecture / DDD | nest-clean-architecture-ddd-example / base-app-nestjs / Nestier |
| フレームワーク非依存・テスト容易性が最優先 | Hexagonal（Ports & Adapters） | Nestier / NestForge / brocoders |
| 読み書き負荷が極端に非対称・監査要件あり | CQRS（必要なら Event Sourcing） | Ultimate Backend |
| 独立スケール・組織分割・マルチテナントSaaS | マイクロサービス | Ultimate Backend / Bunnychess |
| GraphQL中心・フロントと型を共有したい | Code-first GraphQL | Zen / NestJS GraphQL Boilerplate / NextJS-NestJS Starter |
「迷ったらよりシンプルな方を選ぶ」が鉄則です。アーキテクチャは後から足せますが、最初から積みすぎた複雑さを剥がすのは難しいからです。
選定の3軸
アーキテクチャは「good / bad」ではなく「fit / unfit」で決まります。次の3軸で自分の現在地を測ると、早見表のどの行にいるかが見えてきます。
1. ドメインの複雑さ — CRUDが中心か、それともビジネスルールが厚いか。ルールが厚いほどClean / DDD / Hexagonalの「ドメインを中心に置く」設計が効いてきます。逆にCRUD中心なら、それらは過剰投資です。ここが一番大事です。
2. 規模とフェーズ — PoC / MVP / 成長期 / エンタープライズのどこにいるか。フェーズが進むほど、境界の明確さ・独立デプロイ・スケール独立性の価値が上がります。
3. チームの習熟度 — DDDや関数型・新しいアーキテクチャ、デザインパターンにチームが馴染んでいるか。オンボーディング頻度は高いか。全員が理解できないアーキテクチャは、どれだけ理論的に正しくても負債になります。 一貫性は正しさより重要なことが多い、という前提を持っておくと判断がぶれません。
そして全体を貫く原則がひとつあります。
Minimum Viable Architecture（最小で始める）
ドメインに明確な読み書きの非対称性がないならCQRSを入れない。監査証跡が本当に要件でないならEvent Sourcingを入れない。痛みが出てから足す。
アーキパターン別ガイド
各パターンを「一言で／向いている条件／トレードオフ／参考実装」で整理します。上から下へ行くほど複雑度が上がります。
1. 標準モジュラー構成（Controller-Service-Module）
一言で — Nest CLIが生成するそのままの形。機能ごとにModuleを切り、Controllerが受けてServiceが処理する。
向いている条件 — PoC、ハッカソン、社内ツール、小規模API。とにかく速く動かしたい・学習コストを抑えたいとき。
トレードオフ — ビジネスロジックがServiceに溜まって肥大化しやすい。テストがフレームワークやORMに密結合になりがち。
参考実装 — Nest Hackathon Starter（Prisma + JWT + メール認証 + Swagger）、NestJS Prisma Starter（GraphQL + Prisma + Passport-JWT）、Nestify / NestForge のCLI生成。
2. レイヤード（+ Repositoryパターン）
一言で — Controller / Service / Repository の3層に分け、データアクセスをRepositoryに隔離する。標準構成に「データ層の抽象化」を一枚足した形。
向いている条件 — スタートアップのMVP〜小中規模の本番REST API。認証・RBAC・ページネーション・Swaggerなど「定番一式」が要るが、まだドメインは複雑でない段階。
トレードオフ — ドメインルールの置き場所が曖昧なまま育つと、結局Serviceが神クラス化する。Repositoryを挟むだけでドメイン駆動になったと誤解しないこと。prismaなどORMマッパーを入れると不要だったりもする。
参考実装 — brocoders/nestjs-boilerplate（Auth / TypeORM / PostgreSQL / I18N / ファイルアップロード / Docker / テスト / CI）、MonstarLab REST Starter（JWT / RBAC / TypeORM / Pagination / 自動Swagger）、Awesome Nest Boilerplate（TypeScript / PostgreSQL / TypeORM / RBAC）、SQB Boilerplate、vndevteam（ドキュメント充実）。
3. モジュラーモノリス
一言で — 単一デプロイのモノリスだが、内部を業務ドメイン単位のモジュールに論理分割し、モジュール間の境界を厳格に守る。モノリスとマイクロサービスの「実用的な中間点」。
向いている条件 — 中規模で成長が見込まれ、将来マイクロサービスに切り出す可能性はあるが、今その運用コストは払いたくないとき。**「1リポジトリ・1デプロイで始めて、境界線だけ先に引いておく」**のが本質。痛みが出た境界から順にサービスへ切り出せます。
トレードオフ — 境界を守る規律がチームに要る（モジュール間で直接DBやエンティティを触り始めると、ただの密結合モノリスに戻る）。素のモノリスよりわずかにスループットは落ちるが、安定性では上回るという報告もあります。
参考実装 — brocoders の機能モジュール分割、Nx / Turborepo によるモノレポ構成（NestJS Boilerplate with Turborepo、Zen の Nx 構成）。境界を「パッケージ境界」として物理的に強制したいならモノレポが効きます。
4. Clean Architecture
一言で — 依存の向きを内側（ドメイン）へ一方向に固定する。UseCase（アプリケーション層）を中心に、フレームワーク・DB・Web を外側の「詳細」として差し替え可能にする。
向いている条件 — ビジネスルールが厚く長寿命なプロダクト。フレームワークやORMの寿命よりドメインを長く保ちたいとき。テストでドメインを純粋に検証したいとき。
トレードオフ — レイヤーとマッピング（Entity ↔ DTO ↔ ORMモデル）のボイラープレートが増える。小さなCRUDには明確にオーバーキル。
参考実装 — nest-clean-architecture-ddd-example（Prisma + 関数型FP-TS + ユニット/結合/E2Eの三層テスト、テスト設計の教科書として優秀）、Clean NestJs architecture（sudoku-challenge、テスト構成の参考）。
5. DDD（ドメイン駆動設計）
一言で — Clean / Hexagonalと組み合わせて使う「ドメインモデリングの作法」。境界づけられたコンテキスト・集約・値オブジェクト・ドメインイベントでビジネスを表現する。
向いている条件 — ドメインエキスパートと密に協業し、複雑な業務ルールをコードに落とし込む必要があるとき。アーキの箱より「モデルの質」が成否を分ける領域。
トレードオフ — 学習コストが高く、チーム全員の理解が前提。CRUDアプリにフル装備のDDDを持ち込むと、コード量だけ増えて価値が出ない。
参考実装 — base-app-nestjs（DDD + Class Validator + TypeORM、SOLIDでテスタブル）、Nestier（Hexagonal + DDD + Generic Repository）、oNo500/nestjs-boilerplate（DDD + Drizzle + Turborepo）。データ層のパターンとしてはUnit of Work + Identity Map + Data Mapper を備える MikroORM がDDDと相性が良いです。
6. Hexagonal（Ports & Adapters）
一言で — アプリケーションコアが「ポート（インターフェース）」だけを知り、DB・外部API・Webフレームワークは「アダプタ」として外から差し込む。Clean / Onionと思想は同根。
向いている条件 — 外部依存（決済、メール、ストレージ、別システム連携）が多く、それらをモックして高速にテストしたいとき。インフラを後から差し替える前提があるとき。
トレードオフ — インターフェースとアダプタの実装が増える。境界の切り方を間違えると、ただ抽象が増えただけになる。
参考実装 — Nestier、NestForge（Hexagonal + AI支援のコード生成 + JWT/Social Auth/i18n等）、brocoders（Hexagonal志向の構成）。
7. CQRS / Event Sourcing
一言で — コマンド（書き込み）とクエリ（読み込み）のモデルを分離する。さらに状態を「イベントの積み重ね」で表現するのがEvent Sourcing。NestJSは公式に @nestjs/cqrs を提供。
向いている条件 — 読み書きの負荷やモデルが極端に非対称（書き込みは複雑なルール、読み込みは大量・多様なビュー）。あるいは完全な監査証跡・状態の時系列再現が要件のとき。
トレードオフ — 複雑さが跳ね上がる。結果整合性・イベントスキーマ進化・リプレイなど考えることが激増する。「なんとなくスケールしそう」で入れてはいけない筆頭。
参考実装 — Ultimate Backend（CQRS + GraphQLマイクロサービス + Apollo Federation + Event Source + マルチテナント認証）。エンタープライズSaaSの全部入り参照実装。
8. マイクロサービス
一言で — ドメインを独立デプロイ・独立スケール可能なサービス群に分割する。NestJSはTCP / Redis / NATS / gRPC / Kafka 等のトランスポートを公式サポート。
向いている条件 — チーム・組織がサービス境界で分かれている、サービスごとにスケール特性が大きく違う、マルチテナントSaaSで分離が要る——といった「組織と運用の理由」があるとき。技術的な憧れではなく組織構造（コンウェイの法則）で決める。
トレードオフ — 分散システムの全コスト（ネットワーク障害、分散トレーシング、データ整合性、デプロイ複雑性）を払う。多くのチームはモジュラーモノリスから始めて、本当に必要な境界だけ切り出す方が幸せになれます。
参考実装 — Bunnychess（NestJSマイクロサービス + NATS JetStream のスケーラブル実装）、Ultimate Backend、rudemex/nestjs-starter（BFF + MS構成）。
技術スタック選定（横軸）
アーキの「縦軸」が決まったら、横断的に効く技術選択を重ねます。
ORM：2026年は4強
| ORM | 強み | 向いている場面 |
|---|---|---|
| Prisma | スキーマ駆動・型生成・マイグレーションが快適。チームの一貫性を作りやすい | スキーマ変更が頻繁、人が増えるプロダクト。MVP〜成長期の安定択 |
| TypeORM | 最大の制御力。複雑なSQL・トランザクションに強い | トランザクション重め、SQLの特殊ケースが多い。Nest標準系で実績豊富 |
| Drizzle | 生SQLに近い速度＋厳格な型安全。軽量 | 新規プロジェクトでパフォーマンスと型を重視するとき。近年の人気上昇株 |
| MikroORM | Unit of Work + Identity Map + Data Mapper を併せ持つ唯一格 | DDD・複雑なドメインモデルを真面目に作るとき |
ざっくり指針：素早く安定 → Prisma、複雑SQL/制御 → TypeORM、速度と型 → Drizzle、DDD → MikroORM。参考実装は Prisma系（NestJS Prisma Starter、Nest Prisma Zod、Zen）、MikroORM系（rubiin/ultimate-nest）、Drizzle系（NestJS Drizzle Auth.js、oNo500）。なお「あとでORM差し替える」を本気で想定するなら、Hexagonal/Cleanでデータ層をポート化しておくこと。密結合のままでは差し替えは絵に描いた餅です。
API様式：REST / GraphQL / RPC
RESTはデフォルト。Swagger自動生成（Nestia、@nestjs/swagger）で十分まわります。フロントと型を強く共有したい・グラフ的なデータ取得が中心ならCode-first GraphQL（Zen、fernandohenriques、NextJS-NestJS Starter、Knests）。型安全なRPC的アプローチが欲しいなら Nestia + Safe-TypeORM（Samchon Backend）が尖った選択肢です。
モノレポ：Nx / Turborepo
フロント・バック・共有パッケージを1リポジトリで持ち、境界をパッケージとして物理強制したいときに有効。Nx（Zen）、Turborepo（NestJS Boilerplate with Turborepo、oNo500）。モジュラーモノリスの境界規律を機械的に守らせたい場合に効きます。
認証・認可
JWT + Passportが定番（多くのStarterが標準装備）。RBAC/権限を動的に扱うなら NestJS Permission Boilerplate や Truthy（RBAC内蔵のヘッドレスCMS）。認証をマネージドに寄せるなら Stytch（stytch-nestjs-starter）や Auth.js（NestJS Drizzle Auth.js）。
運用周り（最初から入れておくと後が楽）
設定管理（@nestjs/config）、構造化ログ（Pino / Winston）、Swagger、Docker、CI、Lint/Format/commit hooks。vndevteam や rubiin/ultimate-nest はこの「運用一式」が揃っていて、本番前提のテンプレとして参考になります。
実在OSSに学ぶ（プロダクション参照）
ボイラープレートは「始点」、実プロダクトのOSSは「終点でどうなるか」を教えてくれます。アーキ判断に効く実例を挙げます。
- 大規模プロダクトのモジュール設計 — Twenty（Salesforce代替CRM）、Ghostfolio（資産管理ダッシュボード）、Novu（通知インフラ）。成熟したNestJSアプリのモジュール分割・ディレクトリ構成の生きた教材。
- フレームワーク化された拡張性 — Vendure（GraphQLベースのECフレームワーク）。プラグインで拡張させる設計の参考。
- 低コード/プラットフォーム系 — ToolJet、Teable、apitable、Amplication。大規模で多機能なバックエンドの構成例。
- マイクロサービス＋メッセージング — Bunnychess（NATS JetStream）。分散構成の具体実装を読むならここ。
- APIプラットフォーム — Hoppscotch（Postman代替）。実運用規模のNestJSバックエンド。
選定に迷ったら、自分のプロダクトに一番近いOSSのソースを1つ読むのが、どんな比較記事より早い近道です。
決定フロー（テキスト決定木）
- まず作るものはCRUD中心か？ → Yes なら「標準モジュラー or レイヤード」で十分。これ以上の複雑化は不要。
- ビジネスルールが厚い／長寿命プロダクトか？ → Yes なら「Clean / DDD / Hexagonal」を検討。チームがDDDに馴染んでいなければ、まずレイヤードで境界だけ意識する。
- 将来サービス分割の可能性があるが、今は単一デプロイで回したいか？ → Yes なら「モジュラーモノリス」。境界を先に引いて、痛みが出たら切り出す。
- 読み書きが極端に非対称、または監査証跡が要件か？ → Yes なら「CQRS（必要ならEvent Sourcing）」。それ以外では入れない。
- 組織・スケール・テナント分離の理由で独立デプロイが必須か？ → Yes なら「マイクロサービス」。技術的憧れだけが理由なら却下。
各分岐で迷ったら、必ず一段シンプルな方を選ぶ。
やりがちな失敗（アンチパターン）
- Day 1オーバーエンジニアリング — まだ要件も固まっていないのにClean + Hexagonal + CQRS + マイクロサービスをフル投入する。複雑さは負債。必要になってから足す。
- 理解せずボイラープレートを丸々採用 — 高機能テンプレをそのまま本番に乗せ、チームが構造を理解しないまま運用する。テンプレは「学ぶ対象」であって「思考停止の正解」ではない。
- アーキの混在 — モジュールごとに流儀がバラバラ。新メンバーが毎回学び直す羽目になる。一貫性を最優先に。
- 抽象化の自己目的化 — 差し替え予定もないのにインターフェースとアダプタを量産する。Ports & Adaptersは「差し替える理由」があって初めて価値が出る。
- 「差し替え可能」を謳いながら密結合 — ORMやフレームワークを後で変える前提なのに、ドメインがORMモデルに直接依存している。ポート化していなければ差し替えは不可能。
まとめ
NestJSのアーキテクチャ選定は、流行りのパターンを選ぶゲームではなく、「自分のドメインの複雑さ・フェーズ・チーム」に最小限フィットさせるゲームです。多くのプロジェクトは標準モジュラーかモジュラーモノリスで始めるのが正解で、Clean / Hexagonal / CQRS / マイクロサービスは「痛みという招待状」が届いてから採用すれば十分間に合います。
具体的な次の一歩はこの3つです。
- 上の3軸で自分の現在地を測り、早見表の行を1つ選ぶ。
- その行の参考実装を1つ、
git cloneして構造を読む（読むだけ。コピペ採用しない）。 - 自分のプロダクトに最も近いOSSのソースを1つ読み、終点のイメージを持つ。
迷ったら、シンプルな方へ。後から足す方が、剥がすよりずっと簡単です。
参考リンク：アーキ別ボイラープレート＆OSS
Clean Architecture / DDD / Hexagonal
- nest-clean-architecture-ddd-example — Prisma + FP-TS、ユニット/結合/E2Eの三層テスト
- Clean NestJs architecture — Clean Architecture + 各種テストの構成例
- base-app-nestjs — DDD + Class Validator + TypeORM、SOLID
- Nestier — Hexagonal + DDD + Generic Repository
- NestForge — Hexagonal + AI支援コード生成 + エンタープライズ機能一式
- oNo500/nestjs-boilerplate — DDD + Drizzle + Turborepo
本番向けREST（レイヤード／モジュラー）
- brocoders/nestjs-boilerplate — Auth / TypeORM / PostgreSQL / I18N / ファイルアップロード / Docker / CI
- MonstarLab REST Starter — JWT / RBAC / TypeORM / Pagination / 自動Swagger
- Awesome Nest Boilerplate — TypeScript / PostgreSQL / TypeORM / RBAC
- SQB NestJS Boilerplate — 本番志向の全部入り
- vndevteam/nestjs-boilerplate — SWC / Pino / I18N / ドキュメント充実
- rubiin/ultimate-nest — MikroORM / i18n / CI/CD / キャッシュ / Sentry
- NestJS Template (Saluki) — Docker前提の本番テンプレ
- Tony133/nestjs-api-boilerplate-jwt — TypeORM + JWT
- Innei/nest-http-boilerplate — Fastify / Typegoose / Vitest / Redis
高速プロトタイプ / Prisma / Drizzle
- Nest Hackathon Starter — Prisma / メール認証 / JWT / Swagger
- NestJS Prisma Starter — GraphQL / Prisma / Passport-JWT / Docker
- Nest Prisma Zod Boilerplate — Prisma + Postgres + Socket.IO + Zod + Vitest
- NestJS Drizzle Auth.js — Drizzle + Postgres + Auth.js
- Nestify — 本番向けプロジェクトを1コマンド生成するCLI
GraphQL中心
- Zen — Nx monorepo / Prisma / Apollo / Angular、データアクセス層を自動生成
- NestJS GraphQL Boilerplate — Code-first / TypeORM / TypeGraphQL / MongoDB
- NextJS-NestJS GraphQL Starter — OAuth各種つき
- The Knests Stack — PostgreSQL / Knex / Next.js / GraphQL / GitLab CI
- Nest Mongo Graphql — type-graphql のスキーマファースト
CQRS / マイクロサービス / SaaS
- Ultimate Backend — CQRS + GraphQLマイクロサービス + Apollo Federation + Event Source + マルチテナント
- Bunnychess — NestJSマイクロサービス + NATS JetStream
- rudemex/nestjs-starter — BFF / MS / API、GitOps前提
認証・権限・CMS
- Truthy — RBAC内蔵ヘッドレスCMS（2FA / Email / Localization）
- NestJS Permission Boilerplate — 動的なRole/Permission管理
- Stytch NestJS Starter — Stytch認証 + Redisセッション + TypeORM
モノレポ / BFF / リアルタイム
- NestJS Boilerplate with Turborepo — NestJS + Next.js + Turborepo + JWT
- Nest BFF — BFFパターン + CLI + MongoDBマイグレーション
- NestJS Realtime Chat — WebSockets + TypeORM + JWT
- Samchon Backend — Nestia + Safe-TypeORM、TDD/BDD志向
プロダクション参照（実在OSS）
- Twenty — Salesforce代替CRM
- Novu — 通知インフラ
- Ghostfolio — 資産管理ダッシュボード
- Vendure — GraphQL ECフレームワーク
- ToolJet / Teable / apitable / Amplication — 低コード/プラットフォーム系
- Hoppscotch — Postman代替のAPIプラットフォーム
本記事はNestJS v11時点の情報をもとに、アーキテクチャパターンと公開ボイラープレート／OSSを整理した選定ガイドです。技術スタックの最新状況は各リポジトリの最新ドキュメントも併せてご確認ください。