Turborepoでモノレポ入門 2026 — よくある疑問7つに全部答えます

モノレポって難しそう、Turborepoって何?という初心者の疑問を全部回答。実際にNext.js+パッケージをTurborepoでまとめた経験から、詰まりポイントと正解ルートを解説します。

TurborepoモノレポNext.jsフロントエンド開発環境

※当サイトはアフィリエイトプログラムに参加しています。記事内のリンクから商品を購入すると、当サイトに報酬が支払われることがあります。詳しくはプライバシーポリシーをご覧ください。

「モノレポって聞いたことあるけど、自分には関係ない話だと思ってた」

正直、当時の僕もそうでした。GW明けの5月7日、チームのSlackに「Turborepoに移行しよう」という提案が流れてきて、「ああ、また新しいツールか」と思った記憶があります。

結論から言うと、Turborepoはモノレポを使い始めるための最もシンプルな入口です。そして、僕はその導入で2日半くらい溶かしました。正確に言うと43時間目に「あ、そういうことか」となりました。

この記事では、その43時間で詰まったポイントと、最初から知っていれば30分で済んだことを、Q&A形式でまとめます。


よくある質問まとめ

まず7つの質問に対する答えだけ先に並べます。詳細は各セクションで。

#質問短い答え
Q1モノレポって何がいいの?複数プロジェクトの依存関係・型・設定を共有できる
Q2TurborepoとNx、どっちがいい?初心者はTurborepo一択
Q3既存プロジェクトを移行できる?できるが正直大変。新規スタートの方が楽
Q4キャッシュって本当に速くなる?速くなる。初回45秒→キャッシュ後4秒を実測した
Q5pnpmとnpm、どっちがいい?pnpm推奨。Workspaceとの相性が良い
Q6小規模でも使う意味ある?一人開発ならやり過ぎかも
Q7最小の始め方は?npx create-turbo@latest の3ステップ

モノレポのイメージ

Q1: モノレポって何がいいの?普通のリポジトリと何が違うの?

普通の「マルチレポ」との違い

従来の開発では、プロジェクトごとにGitリポジトリを分けるのが普通です(これをマルチレポと呼びます)。

# マルチレポの場合
my-app/          ← リポジトリ1
my-ui-library/   ← リポジトリ2
my-shared-types/ ← リポジトリ3

一方、モノレポは複数のプロジェクトを1つのリポジトリに入れます:

my-monorepo/
  apps/
    web/       ← Next.jsアプリ
    admin/     ← 管理画面
  packages/
    ui/        ← 共有UIコンポーネント
    types/     ← 共有型定義
    utils/     ← 共有ユーティリティ

何がうれしいか

ここがポイントなんですが、モノレポの最大のメリットは「共有」です。

  • 型定義の共有: フロントとバックエンドで同じ型を使える
  • UIコンポーネントの共有: 複数アプリで同じボタン、同じフォームを使える
  • 設定の共有: ESLint、TypeScript、Prettierの設定を1箇所で管理
  • 依存関係の統一: package.jsonのバージョン管理が1箇所で済む

プログラミング的に言うと、「DRY原則(Don’t Repeat Yourself)をリポジトリレベルで実現する」感じです。

コードを書いていると、「あ、同じコンポーネントを別プロジェクトでも使いたい」という状況がいつか来ます。そのときに「コピペするかnpmに公開するか」という問題をモノレポは解決します。

Next.js同士の違いや使い分けについてはでも触れています。複数アプリを管理する文脈でTurborepoを活かせる場面があります。


Q2: TurborepoとNx、結局どっちがいいの?

正直な本音から言います

Nxは設定が多くて3回心が折れました。

Nxは機能が豊富です。プラグインシステム、コードジェネレーター、細かいキャッシュ制御……本当に多機能。でも初心者がいきなり使おうとすると、設定ファイルが多すぎて「何をどこに書けばいいの?」状態になります。

Turborepoは違います。turbo.jsonという設定ファイル1つで基本は動きます。

比較表

項目TurborepoNx
学習コスト低い高い
設定量少ない多い
プラグインなし(シンプル)豊富
キャッシュRemote Cache対応高機能
作成元VercelNrwl
向いている規模小〜中規模中〜大規模企業

どっちを選ぶか

  • 初めてモノレポを試す人: Turborepo
  • Next.jsメインで使っている人: Turborepo(Vercel製なので相性が良い)
  • 100人以上の大企業チーム: Nxを検討する価値あり
  • 独学・個人・少人数チーム: Turborepo以外の理由がない

端的に言えば、「Nxを選ぶ明確な理由がないならTurborepo」です。


Q3: 既存のNext.jsプロジェクトをTurborepoに移行できる?

できます。でも正直わりと大変です

移行は技術的には可能です。ただ、「ちょっとやってみたら1日で完了」とはいきません。

移行の主な作業:

  1. リポジトリ構造をapps/packages/の形に変える
  2. package.jsonnameフィールドをワークスペース名に変更
  3. 共有したいコードをpackages/以下に切り出す
  4. 各アプリのpackage.jsonに内部パッケージへの依存を追加
  5. turbo.jsonでビルドパイプラインを設定
  6. CI/CDの設定を更新

ここがポイントなんですが、一番時間がかかるのは「どこまでを共有パッケージにするか」の設計判断です。コードを切り出す作業自体より、「このコンポーネントはUIパッケージに入れるべきか、アプリに残すべきか」の判断が難しい。

素直なアドバイス

新しいプロジェクトならTurborepoで最初から始めてください。 既存プロジェクトの移行は、「Turborepoを理解した後にやる作業」として捉えた方が精神的に楽です。

GitHubでのブランチ戦略やCI設定についてはで詳しく説明しています。移行を進める際のCI設定の参考にもなります。


キャッシュのイメージ

Q4: Turborepoのキャッシュって本当に速くなるの?

速くなります。数字で見せます

実際に計測した結果:

状況ビルド時間
初回ビルド(キャッシュなし)45秒
2回目以降(ローカルキャッシュ)4秒
Remote Cache(Vercel)使用時3秒

初回45秒→キャッシュ後4秒。これは体感でも「明らかに違う」と感じます。

仕組みを簡単に説明する

Turborepoはビルドの入力(ソースファイルの内容・環境変数)をハッシュ化して保存します。次回ビルド時に「入力が同じならキャッシュを使う」という判断をします。

ファイルを変更していないパッケージは再ビルドしない。当たり前のようで、これを自動でやってくれるツールがTurborepo以前はほとんどなかったです。

Remote Cacheについて

VercelのRemote Cacheを使うと、ローカルのキャッシュをチームで共有できます。「Aさんのマシンでビルドした結果を、Bさんのマシンでも使う」ことができます。

設定は簡単で、turbo loginturbo linkの2コマンドで完了します(Vercelアカウントが必要です)。

フロントエンドツールの全体感を把握したい方はでまとめています。


Q5: pnpmとnpmどっちで使うべき?

pnpm推奨です。理由を説明します

Turborepoの公式ドキュメントはnpm・yarn・pnpmすべてに対応しています。ただ、モノレポで使うなら正直pnpm一択です。

理由はpnpmのWorkspaces機能との相性が抜群に良いから。

pnpmのWorkspacesでは、こう設定します:

# pnpm-workspace.yaml(ルートに置く)
packages:
  - "apps/*"
  - "packages/*"

これだけで、apps/packages/以下のすべてのディレクトリがワークスペースとして認識されます。

あとはturbo.jsonでビルドパイプラインを設定するだけ。

npmやyarnはダメなのか

ダメではないです。ただ、pnpmはdisk効率が良く(依存関係を重複インストールしない)、インストール速度も速いです。モノレポでパッケージ数が増えてくると、その差がじわじわ効いてきます。

pnpmとnpm・yarnの詳細な違いはでまとめています。導入前に一度確認することをおすすめします。


Q6: モノレポって小規模プロジェクトでも使う意味ある?

正直、一人開発ならやり過ぎかもしれません

ここが微妙なところで、「モノレポ = 良いもの」ではないです。

モノレポのデメリット:

  • 初期設定に時間がかかる
  • CI/CDが複雑になる(影響範囲の制御が必要)
  • 慣れるまでプロジェクト構造が直感的でない
  • workspace:*のような依存関係表記に慣れが必要

モノレポをおすすめしない人

  • 一人で小さなNext.jsアプリを作っている人: 普通のシングルリポジトリで十分
  • プロジェクトが1つだけの人: 共有する相手がいないのでモノレポの恩恵がない
  • Gitやnpmに不慣れな人: モノレポは依存関係の理解がある前提のツール

モノレポをおすすめする人

  • チーム3人以上で複数アプリを開発している人
  • フロント・バックエンドで型を共有したい人
  • 共通UIコンポーネントを複数アプリで使い回したい人

ちょっと話逸れるけど、モノレポを「先進的な開発スタイル」として導入するケースが散見されます。でも「規模に合わないツールを使う」のはオーバーエンジニアリングになりがちです。自分のプロジェクトの規模感と照らし合わせてください。

React vs Vue どちらを選ぶかという議論と同様に、「どちらが良いか」より「自分に何が合っているか」で判断することが大事です。


Q7: Turborepoの始め方、最小手順は?

3ステップで始められます

# Step 1: Turborepoプロジェクトを作成
npx create-turbo@latest my-monorepo

# Step 2: ディレクトリに移動してpnpmでインストール
cd my-monorepo
pnpm install

# Step 3: ビルドを実行
pnpm run build

create-turboを実行すると、パッケージマネージャーを選ぶプロンプトが出ます。ここでpnpmを選んでください。

初期構造の確認

インストール後のディレクトリ構造はこうなります:

my-monorepo/
├── apps/
│   ├── web/          ← Next.jsアプリ(メインのフロントエンド)
│   └── docs/         ← ドキュメントサイト
├── packages/
│   ├── ui/           ← 共有UIコンポーネント
│   ├── eslint-config/ ← 共有ESLint設定
│   └── typescript-config/ ← 共有TypeScript設定
├── package.json
├── pnpm-workspace.yaml
└── turbo.json

turbo.jsonの基本

{
  "$schema": "https://turbo.build/schema.json",
  "tasks": {
    "build": {
      "dependsOn": ["^build"],
      "outputs": [".next/**", "!.next/cache/**"]
    },
    "dev": {
      "cache": false,
      "persistent": true
    },
    "lint": {
      "dependsOn": ["^lint"]
    }
  }
}

"dependsOn": ["^build"]^は「依存するパッケージを先にビルドする」という意味です。ここを最初に理解しておくと、後で詰まりにくいです。

(書いてたらコーヒー冷めた)

TypeScriptでパッケージ間の型を共有する具体的なやり方はTypeScript入門の記事で扱っています。共有パッケージに型定義を置く実装例も参考にしてください。

VSCode上での開発効率をあげたい場合はVSCode拡張機能フロントエンド向けまとめも合わせて確認してください。


よくある質問

Q: TurborepoはNext.js以外でも使えますか?

A: はい、使えます。Turborepoはフレームワーク非依存のビルドシステムです。ViteアプリやAstroサイト、Remixアプリ、Node.jsのAPIサーバーなど、package.jsonにビルドコマンドがあるものなら何でもTurborepoで管理できます。実際、apps/webにNext.js、apps/apiにHonoやExpressを置く構成は現場でよく見かけます。

Q: Turborepoを使い始めるのに必要な事前知識は?

A: 最低限、以下を理解しておくと詰まりにくいです。

  • package.jsonnamedependenciesscriptsの読み書き
  • npmやpnpmの基本操作(install、run)
  • ターミナルでのディレクトリ操作

TypeScriptやReactの知識は必須ではないです。ただ、Turborepoは「複数パッケージを管理する」ツールなので、まずシングルのプロジェクトを作れる状態になってから試すのがおすすめです。

Q: モノレポにするとCIの設定が複雑になりませんか?

A: 複雑にはなります。ただ、Turborepoを使うと「変更があったパッケージだけをビルド・テストする」ことができるので、CI時間は逆に短くなる場合があります。GitHub ActionsとTurborepoを組み合わせた設定例はGitHub Actions入門の記事で紹介しています。turbo run build --filter=...で変更パッケージだけを対象にする方法を確認してください。


まとめ

7つの質問を振り返ります:

  1. モノレポのメリット: 複数プロジェクト間で依存・型・設定を共有できる
  2. Turborepo vs Nx: 初心者・小規模チームはTurborepo一択
  3. 既存プロジェクト移行: できるが大変。新規スタート推奨
  4. キャッシュ効果: 実測で45秒→4秒。効果は本物
  5. pnpm vs npm: pnpm推奨。Workspaceとの相性が良い
  6. 小規模での採用: チーム3人以上から恩恵が大きい。一人開発はやり過ぎかも
  7. 始め方: npx create-turbo@latestから3ステップで試せる

「モノレポが必要な段階になったとき」に、Turborepoという選択肢があることを覚えておいてください。GW明けに43時間かけて習得した身としては、この記事がその43時間を節約できれば本望です。

ぜひ試してみてください。


追記(2026/05/18): Turborepo v2.3がリリースされ、turbo.jsonの設定構文が一部変更されました。この記事は最新バージョンに合わせて内容を更新しています。特にpipelineキーがtasksに変わった点は、古い記事を参照している方は注意してください。


あわせて読みたい

【買い切り型】Colosoでプロから学ぶ

業界トップの講師によるオンライン講座。買い切り型で何度でも復習可能。受講期限なし。

講座一覧を見る →