モノレポとは｜Turborepo・Nxの違いと選び方・導入手順

モノレポとは｜定義とポリレポとの違い

モノレポとは、複数のアプリやライブラリを1つのリポジトリで管理する構成です。本記事では、特に依存関係をツールで扱える実務的な構成を前提に説明します。

この「関係が定義されていること」を定義に含める立場もあります。Nxの公式ドキュメントは「A monorepo is a single repository containing multiple distinct projects, with well-defined relationships between them」と説明しています（Nx: What is a monorepo）。

整理すると、構成要素は2つです。1つ目は、複数のプロジェクトが同じリポジトリにあること。2つ目は、プロジェクト間の依存が宣言されていて、ツールがそれを読めること。

実務では、単にフォルダを並べただけの状態をモノレポと呼ぶケースもあります。ただし本記事では、後者をモノレポ運用とは区別して扱います。ツールの恩恵を受けられるかどうかが、2つ目の有無で変わるためです。

モノレポとポリレポの違い

ポリレポは、アプリやライブラリごとにリポジトリを分ける従来の構成です。両者の差は「変更をどこまで一度に反映できるか」に集約されます。

共有ライブラリを直すたびに「パッケージを公開して、利用側5リポジトリでバージョンを上げてPRを5本出す」という作業が発生しているなら、モノレポが効く典型です。逆に、プロジェクト同士がほとんどコードを共有していないなら、無理に寄せる理由はありません。

「ただのディレクトリ分け」との違いはどこか

境目になるのがワークスペース機能です。pnpmやnpm、yarnには、1つのリポジトリ内の複数パッケージを相互にリンクして扱う仕組みがあります。

pnpmならpnpm-workspace.yamlにパッケージの場所を書き、npmならpackage.jsonのworkspacesフィールドに書きます（pnpm Workspaces / npm Docs: workspaces）。これを設定して初めて、アプリ側からローカルの共有パッケージをnode_modules経由で普通にimportできるようになります。

pnpm自体の特徴やnpm・yarnとの違いは「pnpmとは｜特徴とnpm・yarnとの違い・導入手順を解説」で整理しています。

ミニFAQ：ワークスペースを設定すれば、もうTurborepoやNxは要らない？　小規模（たとえば3〜5個程度）で、CIや依存管理に困っていない段階なら、ワークスペースだけで足りることが多いです。ツールが要るのは、ビルドやテストの実行順序を管理しきれなくなってからです。

モノレポのメリット・デメリット

結論から言えば、モノレポはコード共有と横断的な変更を安くする代わりに、ビルド基盤の運用コストを前借りする構成です。

メリット

• 公開オーバーヘッドなしでコードを共有できる。社内npmレジストリやバージョン管理の手間が消える

• アトミックな変更ができる。ライブラリの破壊的変更と、全利用側の修正を1つのコミットにまとめられる

• 単一の情報源になる。「どのバージョンがどこで使われているか」を探す作業が減る

• 依存バージョンを揃えやすい。pnpmのcatalog機能のように、バージョンを一箇所で宣言して各パッケージから参照する書き方もできる

• 規約を強制しやすい。LintルールやCIの設定を全プロジェクトに一括で適用できる

Nxの公式ドキュメントも、利点としてコード共有・単一の情報源・アトミックな変更・規約の強制・開発者の流動性・依存バージョンの統一を挙げています。

デメリット

• リポジトリが肥大化する。クローンやフェッチが遅くなり、エディタのインデックスも重くなる

• CIが素直に書けなくなる。「全部ビルド・全部テスト」のままだと、1行の修正でも全体が走る

• 権限を細かく分けにくい。特定ディレクトリだけ閲覧不可、といった制御は設計が要る

• ツールの学習コストが乗る。タスク定義・キャッシュ・フィルタの概念を全員が理解する必要がある

• 巻き込み事故が起きやすい。共有パッケージの不用意な変更が全アプリに波及する

肥大化のうちGit側の重さは、sparse-checkoutやpartial cloneである程度緩和できます（git-sparse-checkout）。ただし実務で効いてくるのは、次に説明するビルドとCIの側です。

モノレポツールが必要になる理由｜Turborepo・Nxが埋める3つの穴

ワークスペースだけでは埋まらない穴が3つあります。TurborepoもNxも、やっていることはこの3つです。

1つ目は、タスクの実行順序です。 共有パッケージをビルドしてからアプリをビルドする、という依存関係を手書きのシェルスクリプトで管理すると、パッケージが増えた時点で破綻します。ツールは依存グラフから順序を導き、独立したタスクは並列に流します。

2つ目は、キャッシュです。 変更していないパッケージを毎回ビルドし直すのは無駄です。入力（ソース、依存、設定）が同じなら前回の出力を再利用する、という仕組みが入ります。さらにチームやCIでキャッシュを共有できると、他の誰かが既にビルド済みの成果物をそのまま使えます。

3つ目は、影響範囲の特定です。 「このPRで実際に壊れうるのはどのプロジェクトか」を依存グラフから逆算し、そこだけテストを回します。パッケージが30個あってもCIが数分で終わるのは、この絞り込みが効いているからです。

実務上の目安としては、CIの所要時間が10分を超え始めたあたりがキャッシュと絞り込みを検討する頃合いです。ただし許容できる時間は、デプロイ頻度・レビューの往復回数・並列度で変わります。20分を超えると、レビュー往復が多いチームでは待ち時間の影響が無視しにくくなります。

CI自体の組み方は「GitHub Actionsとは？CI/CDの仕組み・基本ワークフロー・案件単価をフリーランス視点で解説」が参考になります。

Turborepoとは｜特徴と向いているチーム

Turborepoは、JavaScript／TypeScriptのモノレポ向けに作られたタスクランナーです。Vercelが開発しています。

公式ドキュメントによれば、中核はタスクのスケジューリングとキャッシュです。利用可能なコアに作業を分散して並列実行し、リモートキャッシュを使うとCIが同じ仕事を二度しなくて済む、と説明されています（Turborepo Docs）。設定はリポジトリルートのturbo.json 1ファイルに集約され、npm・yarn・pnpmに対応します。

turbo.jsonでタスクを定義する

turbo.jsonには、タスクごとに「何に依存するか」「何を出力するか」を書きます。たとえばbuildタスクが依存パッケージのbuildを先に必要とすることを宣言すると、Turborepoが順序を解決します。出力ディレクトリを宣言しておくと、その中身がキャッシュ対象になります（Configuring tasks）。

実行時は、変更したパッケージとその依存先だけを対象にする絞り込みも指定できます。Nxのaffectedに近い使い方はできますが、設計思想は異なります。Nxがimport解析ベースのproject graphを前提にするのに対し、Turborepoはパッケージとタスク定義を中心に扱います。影響範囲を絞れないわけではなく、絞り込みの粒度の考え方が違うと捉えてください。

リモートキャッシュ

ローカルのキャッシュをチームとCIで共有する機能です。ローカルで一度ビルドした成果物をCIが再利用する、あるいはその逆ができます（Caching）。CI時間の削減幅が最も大きいのはここで、キャッシュヒット時はビルドステップが数秒で終わります。

向いているのは、JavaScript／TypeScriptに寄った構成で、設定を厚くしたくないチームです。既存のpackage.jsonのscriptsをそのまま活かせるため、移行時に書き換える量が少なく済みます。

ミニFAQ：Turborepoを入れると既存のビルド設定は書き直しになる？　基本的には不要です。Turborepoは各パッケージのscriptsを呼び出す層として入るため、webpackやViteの設定はそのまま使えます。バンドラ側の役割は「Webpackとは｜モジュールバンドラーの仕組み・Viteとの違い・基本設定」で整理しています。

Nxとは｜特徴と向いているチーム

Nxは、モノレポのビルドシステムに加えて、コード生成とアーキテクチャ制約までを含む範囲をカバーするツールです。

公式ドキュメントが挙げる主要機能は、project graph（プロジェクト間の関係を可視化・問い合わせできる）、affected detection（変更の影響を受けるプロジェクトだけタスク実行）、caching（ローカル・リモート）、module boundaries（プロジェクト間の依存を強制）、code generation（規約に沿ったプロジェクトやコンポーネントの生成）、Nx Cloud（CIの分散実行、キャッシュ共有、自動修復）です。

project graphとaffectedで絞り込む

Nxはパッケージ単位の依存だけでなく、ファイル間のimport解析まで踏み込んでグラフを作ります。そのため「このファイルを変えたとき、実際に再テストが必要なプロジェクトはどれか」の精度が上がります。グラフはコマンドで可視化でき、依存の循環や想定外の参照を目で確認できます（Nx: Run Tasks）。

module boundariesとgeneratorsで規約を強制する

module boundariesは、プロジェクトにタグを付けたうえで「このタグのプロジェクトは、あのタグのプロジェクトをimportしてはいけない」というルールをLintで機械的に落とす仕組みです。feature層からdata-access層は参照してよいが逆は禁止、といった設計を人力レビューに頼らずに守れます。

generatorsは、新規プロジェクトやコンポーネントの雛形を規約どおりに生成するコマンドです。人数が増えてディレクトリ構成が崩れていくタイプの問題に効きます。

向いているのは、複数チームが同じリポジトリを触り、アーキテクチャの境界を守らせたい組織です。TypeScript以外の言語をプラグインで扱いたい場合も候補になります。

ミニFAQ：Nxは後から入れられる？　入れられます。既存のワークスペースに対して段階的に適用する経路が用意されているため、まずキャッシュだけ使い、module boundariesは後から足す進め方ができます。

TurborepoとNxの違い｜比較表と選び方の判断フロー

結論としては、カバー範囲の広さが違うだけで、優劣ではありません。Turborepoはタスク実行とキャッシュに絞り、Nxはそこにアーキテクチャ管理と生成を足しています。

迷ったときの判断フロー

上から順に当てはめて、最初にYesになったところで決めます。

1. 多言語（Java、Python、.NET等）を同じリポジトリで扱うか → YesならNx、またはBazelも検討

2. チームが3つ以上あり、層をまたぐimportを機械的に禁止したいか → YesならNx

3. 新規プロジェクトの雛形生成を標準化したいか → YesならNx

4. 上記に当てはまらず、JS／TSで2〜50パッケージ程度か → Turborepo

5. そもそもパッケージが3〜5個以下か → ワークスペースだけで様子を見る

後から乗り換えられる点は押さえておくと気が楽です。どちらもpackage.jsonのscriptsを起点に動くため、ツール層の差し替えは可能です。最初からNxの全機能を入れるより、Turborepoで始めて必要になった時点で見直すほうが、立ち上がりは早くなります。

ミニFAQ：Bazelはいつ候補になる？　リポジトリに複数言語が混在し、ビルドの再現性を厳密に担保したい場合です。設定の記述量と学習コストがJS系ツールより一段上がるため、JS／TSだけの構成で最初から選ぶ必然性は低めです。

規模・体制別の選び方（ケース別）

ケース1：個人〜3名、パッケージ2〜10個

Webアプリ1つと共有UIライブラリ、型定義パッケージ、といった構成です。

この規模なら、まずpnpm workspacesのみで始めて問題ありません。ビルドが遅いと感じ始めた時点でTurborepoを足します。既存のscriptsが整理されている前提なら、turbo.jsonの作成とscriptsの経由変更で半日〜1日程度で入れられることが多いところです。既存のCIやビルド設定が複雑な場合は、この限りではありません。module boundariesのような強制の仕組みは、人数が少ないうちは過剰になりがちです。

ケース2：複数チーム、パッケージ10〜50個

フロントエンド複数、BFF、共有ライブラリ群、といった構成です。

ここがTurborepoとNxの判断が分かれる帯です。レビューで「その依存はおかしい」という指摘が繰り返し出ているなら、Nxのmodule boundariesで機械化する価値があります。逆に、依存の方向が自然に守られていてCI時間だけが課題なら、Turborepoのリモートキャッシュで足ります。

判断材料として、直近1か月のPRのうち、依存の方向性を理由に差し戻されたものが何件あったかを数えてみると答えが出やすくなります。

ケース3：大規模・多言語

フロントエンドに加えてバックエンドが別言語、という構成です。

Nxのプラグインで扱うか、Bazelのようなビルドシステムを検討する領域です。ただし、全部を1つのリポジトリに寄せる必要があるのかは先に確認したほうがよいところで、言語ごとにリポジトリを分けたまま、共有部分だけモノレポ化する折衷も現実的です。

フロントエンド側の分割戦略そのものを見直す選択肢もあります。判断軸は「マイクロフロントエンドとは｜分割方式・採用判断・運用コストと見送る基準」で整理しています。

モノレポの導入手順と導入前チェックリスト

既存のポリレポから移す場合も、新規で組む場合も、順番は同じです。一度に全部やらないのが要点になります。

ステップ1：ワークスペースを設定する（0.5〜1日）

pnpmならpnpm-workspace.yamlを作り、appsとpackagesの2ディレクトリを切ります。この時点ではまだツールを入れません。

ステップ2：共有パッケージを1つだけ切り出す（1〜3日）

いきなり全部を移さず、最も依存されている共通コードを1つ選んで切り出します。型定義やUIコンポーネントが候補になりやすいところです。ここでimportが解決すること、ビルドが通ることを確認します。TypeScriptのpath設定が絡むため、型周りで一度つまずくのが普通です。TypeScriptの基本は「TypeScriptとは？JavaScriptとの違いや年収、将来性について解説」を参照してください。

ステップ3：Turborepoを入れてタスクを定義する（0.5〜1日）

turbo.jsonを作り、build・test・lintの依存関係と出力先を宣言します。ここまででローカルのキャッシュが効き始めます。

ステップ4：CIでリモートキャッシュを有効化する（0.5〜1日）

CI側でキャッシュを共有します。所要時間の削減が目に見えるのはこの段階です。

ステップ5：絞り込み実行に切り替える（1〜2日）

全パッケージ実行から、変更起点の絞り込み実行に変えます。ここで初めて「30パッケージあってもCIは数分」という状態になります。

導入前チェックリスト

着手前に、以下を一通り確認しておくと手戻りが減ります。

• [ ] 共有したいコードが実際に2つ以上のプロジェクトから使われているか

• [ ] パッケージマネージャをpnpm・npm・yarnのどれに統一するか決まっているか

• [ ] Node.jsのバージョンを全プロジェクトで揃えられるか

• [ ] CIの実行時間を計測して、現状の数値を記録したか

• [ ] リポジトリ分離が必要な権限要件（業務委託先の閲覧範囲など）がないか

• [ ] 移行を担当する人が、最低1〜2週間は継続して手を入れられるか

• [ ] ロールバックの判断基準（いつまでに効果が出なければ戻すか）を決めたか

最後の2つが抜けていると、移行が中途半端な状態で止まったまま放置される原因になります。

モノレポ運用でつまずくポイントと対策

キャッシュが効かない

原因の多くは入力の宣言漏れです。 環境変数や設定ファイルをタスクの入力として宣言していないと、ツールは「同じ入力」と判断できず、毎回ミスヒットします。逆に、タイムスタンプのような毎回変わる値が入力に混ざっていても同じことが起きます。

対策は、キャッシュのヒット率をCIのログで定期的に確認することです。週1回程度見るだけでも、設定変更で壊れたことに早く気づけます。

依存バージョンがパッケージごとにずれる

アプリAはReact 18系、アプリBは19系、という状態になると、共有パッケージがどちらでも動く保証を作りにくくなります。

対策は、バージョンを一箇所で宣言して各パッケージから参照する仕組みを使うことです。pnpmのcatalogがこれにあたります。やむを得ずずらす場合は、なぜずらしているかと、いつ揃えるかをREADMEに書いておきます。

レビュー範囲と権限が曖昧になる

全員が全ディレクトリを変更できる状態だと、所有者が不明瞭になります。GitHubならCODEOWNERSでディレクトリごとにレビュー必須者を設定できます（GitHub Docs: About code owners）。モノレポでは、この設定の有無でレビューの回り方が変わります。

移行が途中で止まる

最も多い失敗がこれです。 半分だけ移した状態は、ポリレポよりもモノレポよりも運用しづらくなります。ステップ2の「共有パッケージを1つ切り出す」を終えた時点で一度区切り、効果を測ってから次に進む進め方にすると、止まっても中途半端になりません。

ミニFAQ：モノレポをやめて戻すことはできる？　できます。ただし戻すコストはパッケージ数に比例して上がるため、ステップ2の段階で判断しておくのが現実的です。

フリーランス案件でのモノレポの扱われ方

結論として、公開案件では、モノレポ単体がスキル要件の主役になるより、CI/CD改善やフロントエンド基盤整備の一部として記載されることが多い領域です。フロントエンド基盤・プラットフォーム系のロールにおける要件の一部、という位置づけになります。

具体的には、「CI/CDの改善」「ビルド時間の短縮」「共通コンポーネントの整備」といった募集要件の中に、モノレポ構成の経験が含まれる形で現れます。そのため、スキルシートに書くときは「モノレポ経験あり」だけでは伝わりにくく、何パッケージ規模のリポジトリで、CI時間をどこからどこまで短縮したかを数値で書くと、採用側に伝わりやすくなる傾向があります。

関連する周辺領域としては、CI/CDパイプラインの設計、コンテナ化、テスト自動化が隣接します。それぞれ「Dockerとは？コンテナ技術の仕組み・できること・フリーランス案件の単価への影響を解説」「Playwrightとは｜E2Eテスト自動化の基本・Cypressとの違い・案件単価をフリーランス視点で解説」が参考になります。基盤運用寄りに広げるなら「SREとは？仕事内容・年収・必要スキルとDevOpsとの違いをエンジニア視点で解説」も合わせて読むと全体像がつかめます。

単価の考え方そのものは「【2026年最新版】フリーランスエンジニアの単価相場と単価の上げ方とは？」で体系的に整理しています。自分のスキルセットでどのくらいの単価を狙えるか確認したい場合は、無料のフリーランスエンジニア単価診断で市場単価の目安を把握できます。実際の募集内容を見たい場合は案件一覧から確認してください。

まとめ

モノレポは、複数プロジェクトのコード共有と横断的な変更を安くする構成であり、その代償としてビルドとCIの運用コストを前借りします。TurborepoとNxはそのコストを回収するためのツールで、違いはカバー範囲です。

• モノレポの条件は「1リポジトリ＋複数プロジェクト＋関係の定義」。フォルダ分けだけでは該当しない

• ツールが要るのはCIが重くなってから。目安は全体のCIが10分を超えたとき

• JS／TS中心で2〜50パッケージならTurborepoが始めやすい。設定はturbo.json 1ファイルで済む

• Nxが効くのは境界の強制と生成の標準化。複数チーム・多言語・アーキテクチャ制約がある場合に差が出る

• 導入は段階的に。ワークスペース設定→共有パッケージを1つ切り出す→キャッシュ→絞り込み、の順で進める

• 効果測定のため、着手前にCI時間とフルビルド時間を記録しておく

• 案件でアピールするなら、ツール名ではなく規模と短縮した時間を数値で示す

次のステップとしては、現在のCI時間を計測したうえで、最も依存されている共通コードを1つ選び、ワークスペースに切り出すところから始めてください。そこまで進めば、ツールを入れるべきかどうかの判断材料が揃います。

参照元・一次情報：

• Turborepo Docs

• Turborepo: Configuring tasks

• Turborepo: Caching

• Nx: What is a monorepo

• Nx: Run Tasks

• pnpm Workspaces

• npm Docs: workspaces

• git-sparse-checkout

• GitHub Docs: About code owners