モノレポとは
モノレポ（Monorepo）とは、複数のプロジェクトやパッケージを1つのリポジトリで管理する手法だ。フロントエンド、バックエンド、共有ライブラリ、インフラ設定などが、すべて同じGitリポジトリに格納される。
メリット
- コードの共有が容易：共有ライブラリの変更が即座にすべてのプロジェクトに反映される
- アトミックな変更：APIの変更とそのクライアント側の修正を1つのコミットで行える
- 統一された設定：ESLint、TypeScript設定、CI/CDパイプラインを一元管理
- 依存関係の可視化：プロジェクト間の依存関係が明示的に管理される
デメリット
- リポジトリの肥大化：Git操作が遅くなり、cloneに時間がかかる
- CI/CDの複雑化：変更の影響範囲を正確に把握し、必要なビルドだけを実行する仕組みが必要
- アクセス制御の難しさ：リポジトリ単位の権限管理ができないため、コード所有権の管理が複雑になる
- ツールへの依存：効率的に運用するために専用ツール（Nx、Turborepo等）が必要
マルチレポとは
マルチレポ（Multirepo / Polyrepo）とは、プロジェクトやサービスごとに独立したリポジトリを持つ手法だ。マイクロサービスアーキテクチャと相性が良く、各チームが独立してリポジトリを管理する。
メリット
- 独立性：チームごとに独自の開発サイクル、リリースタイミングを持てる
- シンプルなCI/CD：リポジトリ単位でパイプラインを構築でき、影響範囲が明確
- アクセス制御：リポジトリ単位で権限を設定できる
- 技術の多様性：各リポジトリで異なる言語・フレームワークを使える
デメリット
- コード共有の摩擦：共有ライブラリをnpmパッケージ等として公開・管理する手間が発生する
- 横断的変更の困難さ：複数リポジトリにまたがる変更は、PRが分散し調整コストが高い
- 設定の分散：ESLint、テスト設定等がリポジトリごとにバラバラになりやすい
- 依存関係の管理：サービス間の依存バージョンが乖離しやすい
2026年のモノレポツール事情
Nx
Nrwlが開発するNxは、最も機能が豊富なモノレポツールだ。依存グラフの可視化、影響を受けたプロジェクトのみのビルド、分散キャッシュ（Nx Cloud）など、大規模モノレポの運用に必要な機能が揃っている。
Turborepo
Vercelが買収・開発するTurborepoは、シンプルさと高速性を重視したモノレポビルドツールだ。既存のnpm/pnpm workspacesに最小限の設定で導入でき、学習コストが低い。リモートキャッシュによるビルド高速化が大きな売りだ。
pnpm workspaces
pnpmのワークスペース機能は、モノレポの依存関係管理において最も効率的だ。コンテンツアドレッサブルストレージにより、ディスク使用量を大幅に削減する。Turborepoやnx との併用がデファクトスタンダードとなっている。
Bazel
Googleが開発したBazelは、超大規模モノレポ向けのビルドシステムだ。言語に依存しない汎用的なビルドが可能で、Googleの数十億行のコードベースを支えている。ただし学習コストが非常に高く、中小規模チームには過剰なことが多い。
判断基準：どちらを選ぶべきか
モノレポが向いているケース：
- チーム間のコード共有が頻繁
- フロントエンドとバックエンドの密結合が高い
- 統一された品質基準・ツールチェーンを維持したい
- 少〜中規模チーム（50人以下）
マルチレポが向いているケース：
- マイクロサービスアーキテクチャで各チームが独立運用
- 外部への公開APIやSDKを提供している
- チーム間の技術スタックが大きく異なる
- 厳密なアクセス制御が必要
「正解」は文脈の中にある
モノレポかマルチレポかは、技術的な優劣の問題ではなく、組織の文脈に依存する設計判断だ。チームの規模、開発文化、プロダクトのアーキテクチャ、そして何を最も重視するかによって最適解が変わる。
重要なのは「みんなが使っているから」ではなく、自分たちの課題に対して最も効果的な選択をすることだ。あなたのチームには、どちらのアプローチがフィットするだろうか。
モノレポを支える運用プラクティス
モノレポを健全に運用するには、ツール以上に運用プラクティスが重要だ。 ディレクトリごとのオーナー定義（CODEOWNERS）、影響を受けるプロジェクトのみをビルドする仕組み、依存関係の自動可視化、ブランチ戦略の統一。 これらを欠いたまま規模を拡大すると、モノレポはただの巨大カオスに変わる。 Google や Meta が成功しているのは、ツールだけでなく数百人規模で磨かれた運用文化を持っているからだ。
マルチレポで避けたい失敗
マルチレポで最も多い失敗は、共有ライブラリのバージョン管理が崩れることだ。 各サービスが異なるバージョンを使い続け、セキュリティパッチの適用が進まず、障害対応時にコードの挙動が予想できなくなる。 これを防ぐには、依存関係の自動更新（Renovate、Dependabot）、共有ライブラリのリリースノートの徹底、依存バージョンの統一ポリシーが必要だ。 マルチレポは自由度が高い分、規律が弱いと一気に崩れる。
ハイブリッドという第3の選択
現実の多くの企業は、モノレポとマルチレポのハイブリッドを採用している。 フロントエンドとバックエンドをモノレポにし、インフラや公開SDKはマルチレポに分ける。 事業ドメインごとに独立したモノレポを持ち、それらを横断する共有ライブラリは別途マルチレポで管理する。 完全なモノレポか完全なマルチレポではなく、用途と組織に合わせたハイブリッド構成が、運用の現実解になる。
選択を支える組織の成熟度
リポジトリ戦略の優劣を左右するのは、最終的には組織の成熟度だ。 コードレビュー、CI/CD、オンコール、技術的負債の扱い、ドキュメント文化。 これらが整っていない組織が高度なモノレポ運用を目指しても、運用負担だけが増えて成果は出にくい。 逆に、成熟した組織ならどちらの構成でも高い生産性を保てる。 あなたのチームは、今の戦略で次の3年を戦える運用基盤を持っているだろうか。
次の戦略は何年で見直すか
リポジトリ戦略は、一度決めたら10年続くものではない。 事業の成長、チームの人数、採用するアーキテクチャ、クラウドの進化によって、最適解は変化する。 3年に一度は戦略そのものを見直し、必要なら移行コストを払ってでも構造を変える判断をする。 移行コストは高く見えても、放置したときの運用コストはそれを上回ることが多い。 あなたのチームが次にリポジトリ戦略を見直すのは、いつの予定になっているだろうか。
戦略より大切なもの
モノレポかマルチレポかを議論する前に、チームが共通して大切にしている価値観を揃えておく方が重要だ。 レビューの深さ、ドキュメントの粒度、失敗への姿勢、技術選定の基準。 この土台が揃っていれば、戦略の選択がどちらに転んでも、チームは前に進める。 ## 関連記事 - [Claude Code使うなら、CursorとVS Codeどっちが正解？ 開発体験・コスト・セットアップを徹底比較](/articles/10000320) - [LangChain入門ガイド｜LLMアプリ開発の定番フレームワークを基礎から完全解説【2026年版】](/articles/10000160) - [Cursor完全ガイド｜AIコーディングエディタの使い方・設定・活用術を徹底解説【2026年版】](/articles/10000158)
