# モノレポ vs ポリレポ：選んだら決まる

URL: https://whatshouldibuildnext.com/ja/journal/monorepo-vs-polyrepo
Type: blog
Locale: ja
Published: 2026-09-26
Updated: 2026-09-26

---

> モノレポかポリレポか。サービス間でコード共有するかどうか、誰がアクセス必要か、CI耐性で決まる。実践的なフレームワークを紹介。

モノレポ メリット デメリット。個人開発でコード共有するなら、モノレポが標準だ。新規プロジェクト立ち上げるたびに出てくる選択肢で、その後6ヶ月のCI/CDセットアップ、リファクタリング、チームアクセス制御が決まる。2026年のいま、理由は単純：複数パッケージが連携する瞬間、ポリレポが要求する「公開セレモニー」を避けられるから。サービス間で共有コードが本当にゼロなら、ポリレポでいい。ほぼ全部のケースはコンテキストと関係性の問題。

夜の10時。新しいプロジェクト走り出した。バックエンドAPI、TypeScript型ライブラリ、それを使うフロントエンドダッシュボード。タブは2つ。カーソルが点滅してる。

このテーマについて書かれた記事の大半は、DevOps専任者がBazelを設定してる20人以上のチームを対象だ。この記事は「最初のコミット前に決める必要がある」個人開発者向け。6ヶ月後、実ユーザー抱えてCI走ってる状態でリポ構成変えるのは、サイドプロジェクト殺す級の流れを後押しするやつだから。

## モノレポが実際に買う価値（教科書版じゃなく）

標準的なピッチは「1リポ、共有依存、アトミックな変更」で、これらは本当。でも個人開発が日々感じる価値は、より実践的だ：ローカルで使うパッケージを公開しなくていい。

ポリレポセットアップでは、`shared-utils`のバグ修正が`api-service`にも影響するなら、`shared-utils`を新バージョン公開して、`api-service`の依存をアップデートして、CI待ってデプロイ。あるいは`npm link`ハックに逃げるが、これは途中で壊れる。モノレポ＋ワークスペースなら、コード書き換えたら、それをインポートするパッケージが即座に変更を見る。公開セレモニーなし。

pnpm ワークスペースでどう見えるか。設定は最小限だ：

`/packages
  /shared-types      ← api と web から直接インポート
  /api
  /web
package.json         ← workspace フィールド付きルート`
```
`// api/package.json
{
  "dependencies": {
    "@myapp/shared-types": "workspace:*"
  }
}`
```
公開なし。開発中のバージョンアップなし。`workspace:*`はローカルパッケージ解決して、TypeScriptプロジェクト参照でグラフ全体に対して段階ビルド。

2番目の価値：クロスパッケージリファクタリングが1PRに収まる。`shared-types`のインターフェース名変えたら、TypeScriptが全コンシューマを同じエディタセッション内で赤字にする。ポリレポなら、リポAで名前変えて、公開して、同僚がリポBで`npm install`走すまで3日待ってから「型がランタイムと合わん」を発見する。

3番目の価値（個人開発が過小評価する）：ツール設定が1箇所。`.eslintrc`、`prettier.config.js`、CI定義ファイル。変更ごとの節約は小さいが、何ヶ月も反復すると積もる。

モノレポが与えないもの：サービス間カップリングを減らさない。独立したサービスを無理にモノレポに入れたら、コードベースにカップリングがない状態で、調整オーバーヘッドだけ追加。モノレポの価値は、サービスが実際に共有コードを持つか、一緒に変わる必要があるときだけ。リポ構成は依存グラフを反映すべき。依存を作り出すべきじゃない。

![モノレポ単一ツリーと複数ポリレポボックスの比較を表す抽象図](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/whatshouldibuildnext/2026-09/06d7c6-img-1.webp)

## ポリレポが活躍する場面

ポリレポは失敗じゃない。特定の状況では正解で、否定は「40サービスのモノレポで25分クローン待ち」を招く。

最明確なケース：オーナーシップ、リリースサイクル、コンプライアンス要件が本当に異なるサービス。決済サービスがPCI対象で、マーケティングサイトが対象外なら、別リポでアクセス制御、監査ログ、影響範囲をきれいに分離できる。運用オーバーヘッドじゃない。機能だ。

ポリレポはまた、コードベースの一部をオープンソース化するとき勝つ。専用の公開リポなら、外部コントリビュータがforkしてPRするとき、プライベートインフラを範囲に引っ張らない。GitHubのリポジトリレベル権限モデルは、大規模なパス単位のアクセス隔離を与えない。別リポなら正しく処理できる。

そしてマイクロサービスで技術スタックが全く異なるとき：GoサービスとReact Nativeアプリが、コードレベルで共有ゼロなら、モノレポは調整コスト乗せるのに、メリット届かない。共有パッケージなけりゃ、共有する物がない。

正直なバージョン：多くのインディープロジェクトがポリレポで始めたけど後悔する。ポリレポが悪い設計じゃなくて、パーツが独立な状態で留まると過大評価した。フロントエンドが必ずバックエンド型を必要にする。ワーカーがAPIユーティリティ必要。2リポが機能ごとに4PRになる。

## 誰も言わないCI/CDコスト

モノレポは実際のオペレーショナルコスト持つ：CI が全部ナイーブに全コミット走したら、変更と無関係なビルド・テストに時間と金払う。

ウェブパッケージにCSS微調整プッシュ。CI は`api`、`worker`、`shared-types`フル テストスイート走す。色変更で6分のGitHub Actionsコンピュート。規模で、CI待機列がチーム全体をブロック。

解決は存在するが、明確なセットアップ必須：依存グラフを理解するビルドオーケストレーション。[Turborepo](https://turbo.build/)とNx両方このために。Turborepo`turbo.json`はパイプライン定義で、各タスクは入力変更を持つパッケージだけで走る：

`{
  "pipeline": {
    "build": {
      "dependsOn": ["^build"],
      "outputs": ["dist/**"]
    },
    "test": {
      "dependsOn": ["build"],
      "cache": true
    }
  }
}`リモートキャッシュ有効（Vercel Turborepo Cloud小チーム無料）なら、変更なしパッケージのキャッシュヒットは即座で、リビルドなし、リテストなし。サイドプロジェクト個人開発なら、ビルドアーティファクト温かいと2分以下でCIキープ。

コスト：Turborepo or Nx 必要になる前に学ぶ。だいたい半日セットアップ。スキップして CI ファット溜まったら、モノレポが疑わしくなって、そこでポリレポが正解だったと思う。実は設定ファイル忘れてただけ。

![モノレポアーキテクチャの並列ビルド・デプロイステータスを示すCI/CDダッシュボード](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/whatshouldibuildnext/2026-09/10ba32-img-2.webp)

## AI開発ツールがこの議論を変えた理由

つい最近まで、ポリレポの本当の主張は認知負荷：小さいリポは孤立してるから理解しやすい。新サービスにコンテキストスイッチしたら、そのサービス関連だけ見える。議論は正当だった。

AI開発ツールがその計算を変える。Cursor、Claude Code、GitHub Copilotで作業するとき、ツールはフルコードベースをコンテキストで作動。クロスサービス依存を見て、インターフェースがどのサービスに使われてるか理解して、フィールド名変更を全コンシューマで追跡。メンタルモデルを自分で持つ必要なし。「孤立リポは分かりやすい」議論が大幅に弱くなる。AI補助が依存グラフ全部コンテキストに握るとき。

具体例：ポリレポセットアップなら、AIアシスタントにAPI変更がアクセスする型も関わるリファクタ頼むと、通常は両リポをセッション内で見られない。手動で調整。それがモノレポ防ぐ目的のオーバーヘッド。モノレポなら同じリファクタが1会話。

これが決定全部を反転しない。でも小チーム・個人開発のポリレポ正当化1つが消えて、コード本当にカップルしてたら、デフォルトが少しモノレポに傾く。

## リポを今すぐ分割すべき3つの信号

モノレポで始めた。いい。でも分割が正解の明確な信号が3つある：

**アクセス制御が基盤になってきた。** 契約者はフロント必要で、バック不要。パートナー統合チームがAPI仕様読むがプロプライエタリー不要。GitHubの Codeowners でレビュー対象パス限定できるが、読み取りアクセスは制限しない。読み隔離がコンプライアンス・セキュリティで重要なら、別リポが清潔。Codeowners 体操は完全なリポ権限置き換わらない。

**1サービスのCI失敗が無関係サービスのデプロイをブロック。** `payment-service`壊れたテストが、出したい`marketing-site`ホットフィックスゲート；モノレポがコードベースにない結合を作ってる。ビルド設定直るか（Turborepo タスクスコープで解決）、2サービス本当に同じリポ属さない。

**片方がオープンソース化、片方がプライベート。** 最もシンプルな分割ケース。オープン部を専用公開リポに抜き出す。GitHub モノレポの混合パブリック・プライベートは本当に苦しい：別オーガナイゼーション or 手動刈り込みプロセスで常メンテ負債。

## ほとんどの開発者が着地する実装

経験ある開発者が最終的に落ち着く答え：1プロダクト領域ごと1モノレポ。「今まで作った全部1モノレポ」でもなく「パッケージごと1リポ」でもなく。

SaaS でウェブフロント・API・共有型ライブラリ作ってるなら、それは1プロダクト。1モノレポに保つ。別でオープンソースCLIメンテナンスしてるなら、別リポで別オーディエンス・別リリースサイクル。

ミスは モノレポ/ポリレポを思想的に扱うこと。「モノレポ派」対「ポリレポ派」じゃない。3つの質問ベースの構造決定：サービス間の依存グラフは？アクセス必要・隔離重要？CI/CD複雑さ許容度？

![ノートパソコンでプロジェクトアーキテクチャ決定を考える個人開発者](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/whatshouldibuildnext/2026-09/0b60e1-img-3.webp)

サイドプロジェクト特に：pnpmワークスペースでモノレポ始める（npm ワークスペースも動くが、使い勝手劣る）。CI が常に4分以上走ったら Turborepo 足す。オープンソース・アクセス制御・コンプライアンス・パートナーチーム別リリース、具体的理由あるときだけ別リポ分割。「アーキテクチャきれいに見えるから」じゃなく。

モノレポ vs ポリレポ議論は、ほぼ全個人開発者に同じ答えな選択肢の1つ：シンプルに始めて、具体的な摩擦出たら最適化。カーソルはまだ点滅してる。最初のコミット。ship it.

## FAQ

### モノレポはCursorやGitHub Copilotみたいなエディタツール向けに有利？

はい、一般的に。AIアシスタントは依存グラフ全体をコンテキスト内で見るときベスト。モノレポなら、Cursorが共有型から全コンシューマまで変更をトレース、1セッション。ポリレポなら、クロスリポコンテキスト欠けるか手動セットアップで、調整が手に戻る。

### TurborepoとNxの実際の違い？

両方ともモノレポ向けビルドオーケストレーションツール。変更なしパッケージをスキップ（依存グラフ分析）。Turborepo はシンプル設定。NxはJavaScript/TypeScriptプロジェクト向け。Nx はジェネレータ、プロジェクトグラフUI、複数言語対応で高機能。サイドプロジェクトなら、Turborepo が通常、スタート地点。

### 後でポリレポからモノレポに移行できる？

できるが、十分な破壊力がある。プロセスは、各パッケージをワークスペース構成に移す、インポート更新、CI パイプル調整、オプションでgit subtree or git-filter-repo で履歴書き直し。経験チームはやる価値あったと言う。でも最小2～3日必須。有意義なプロジェクトなら。

### 大企業もモノレポ使う？

Google、Meta、Microsoft、Twitter は主コードベース モノレポ歴史持つ。Uber の iOS・Android チーム両方モノレポに切り替え（クロスサービス調整削る目的）。でも使うツール（Bazel、Buck、Pants）は個人開発不要な複雑さ。Turborepo と pnpm ワークスペースは、メリット 95% と、インフラ負債なし。

### モノレポはVercelやプラットフォーム デプロイに影響？

モダンプラットフォームはネイティブ モノレポ対応。Vercel は、プロジェクトごとにルートディレクトリ指定できる。packages/web をデプロイしながら、ビルドコマンドがモノレポルート。Netlify と Railway も同様。設定は10分。特別インフラ不要。

### 個人開発は初日から Turborepo 設定？

必須じゃない。pnpmワークスペースで共有パッケージメリット。CI が常に3～4分超えたか、ローカルビルド速度欲しいとき Turborepo 足す。既存ワークスペースに Turborepo は30分。初日から固定化じゃない。