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

モノレポ メリット デメリット。個人開発でコード共有するなら、モノレポが標準だ。新規プロジェクト立ち上げるたびに出てくる選択肢で、その後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定義ファイル。変更ごとの節約は小さいが、何ヶ月も反復すると積もる。

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

ポリレポが活躍する場面

ポリレポは失敗じゃない。特定の状況では正解で、否定は「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とNx両方このために。Turborepoturbo.jsonはパイプライン定義で、各タスクは入力変更を持つパッケージだけで走る：

{
  "pipeline": {
    "build": {
      "dependsOn": ["^build"],
      "outputs": ["dist/**"]
    },
    "test": {
      "dependsOn": ["build"],
      "cache": true
    }
  }
}

リモートキャッシュ有効（Vercel Turborepo Cloud小チーム無料）なら、変更なしパッケージのキャッシュヒットは即座で、リビルドなし、リテストなし。サイドプロジェクト個人開発なら、ビルドアーティファクト温かいと2分以下でCIキープ。

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

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複雑さ許容度？

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

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