# モノレポ vs ポリレポ - エンジニアチームの構成を決める完全ガイド URL: https://formula.dog/ja/journal/monorepo-vs-polyrepo-ja Type: blog Locale: ja Published: 2026-08-29 Updated: 2026-09-02 --- > モノレポとポリレポ、どちらを選ぶか。本当の問題は「リポの数」ではなく「結合度」だ。大規模チームの実例と判断フレームワークで、あなたの組織に合った選択肢を見つけよう。 ## モノレポ vs ポリレポ モノレポ対ポリレポの話は、エンジニアチームが急速に成長するたびに必ず出てくる。簡潔な答え：複数チームがコードを頻繁に共有し、同じリリースサイクルで連動して変更を加える必要があるなら、モノレポが有利。各チームが独立してデプロイでき、互いに待つ必要がないなら、ポリレポが有利。その間のすべては、サービスがどのくらい密に結合しているか、チーム間の調整コストをどこまで許容できるかで決まる。このガイドでは、実際のトレードオフ、どちらを選ぶべきか示す信号、そして意思決定の枠組みを説明する。 ## 本当の問題は「リポの数」ではなく「結合度」 モノレポ対ポリレポの議論の大半は、そもそも間違った質問から始まる。リポの数なんて本質じゃない。本質はチーム同士が一緒に動く必要があるかどうかだ。 チームAの変更がチームBに同じリリースサイクル内で何か対応させるなら、それはコードが密に結合している状態。そういう場合、1つのリポで管理するのが大抵はシンプルだ。チームAとチームBがそれぞれ独立したスケジュールでリリースし、システムの別々の部分を担当し、お互いを待たないなら、リポを分けるのは筋が通る。 最悪の状況：リポは分かれているのに、実際には一緒にデプロイしなきゃいけないコード。モノレポのすべての調整コストを被りながら、メリットは何もない。複数のチームが同時にリポAとリポBにPRを開き、両方がCIを通るのを祈る。ポリレポを選んだはずなのに、後から気付いたらサービス間の依存が増してしまった、という組織は案外多い。 最初にやるべきは、単純な依存図を描くこと。チームが所有するサービスやパッケージをすべてリストアップして、依存関係に矢印を引く。矢印が密なクラスタを作っているなら、そのクラスタは1つのリポに属するべき。 ![Software development team gathered around a whiteboard reviewing code architecture diagrams](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/accorata/2026-09/be767c-img-1-inline.webp) ## GoogleやMeta、Microsoftが大規模でモノレポを採った理由 Googleはほぼ全コードを単一リポに保存してる。データ容量80TB超、コード行数20億行超だ。MetaとMicrosoftも同じ。複雑さを好んでるからじゃなくて、数百のリポ間で依存を同期させることが、単純に専従のエンジニア仕事になってしまうから。 共有ライブラリのAPI変更1つで、40個のリポ全体への調整が必要になるかもしれない。モノレポなら、PR1本。レビュー1回。マージ1回。問題があってもロールバック1回。 Sourcegraphの研究では、50人以上のエンジニアを持つ企業の63%がモノレポを使ってる。3年前より大幅に増えてる。 最も実益のあるメリット：アトミックコミット。APIの破壊的変更がフロントエンドとバックエンドの同時更新を要する場合、モノレポなら3つの変更を1つのPRに詰め込んで、一緒にテストして、問題があれば1単位でロールバックできる。ポリレポなら3つのPRを開いて、3回のレビューを待って、その間にサービスがバージョン違いで動く状況を管理することになる。 あるエンジニアチームの例：Nxモノレポへのマイグレーションでフロントエンドパッケージを統合した結果、デプロイが数週間に数回から週40回以上に増えた。Angularアップグレード（昔は数ヶ月かかった）が、チームが他の仕事を止めずに処理できるルーチン作業になった。 ## ポリレポの隠れたコスト ポリレポにはまともなメリットがある。各チームが独自のCI/CDパイプライン、リリーススケジュール、アクセス制御を管理できる。セキュリティ・コンプライアンスチームが好む理由は、コードアクセスをチーム単位で制限できるから。金融・医療など規制の厳しい業界では重要だ。オープンソースコンポーネントは、内部コード公開なしに独立したリポで管理できる。 本当に独立してるチームなら、メリットは実質的。他のサービスと依存がなく、独立したスケジュールで動くデータパイプラインなら、大規模モノレポに入る理由は薄い。 ただ、ポリレポ組織は時間とともに目立たないコストを溜める。リポ間の依存バージョン管理が独自の課題になる。共有ユーティリティライブラリが一方では古いまま、もう一方は最新、なんてことになる。どのバージョンの何がどのバージョンの何と相性があるか、互換性マトリックスを誰か保守しなきゃいけない。 知っておく価値のあるメトリック：モノレポのPRサイクル時間の中央値は約19時間。ポリレポは約2時間。モノレポのPRは複数の表面に触れるから大きくなり、レビューが遅くなる傾向。でも、ポリレポで機能1つをマージするのに3つのリポで3つのPRが必要ともなると、トータルのサイクル時間はモノレポを超えることもある-加えて、部分的なマージでサービスが不整合状態になるリスクも。 意外と多いパターン：「独立を目指してリポ分けたのに、今はリリースのたびに4つの場所でPR開かないといけない」。その時点で、両方の悪いところ取りだ。 ## ビルド時間はもう決定打じゃない（2024年以降） モノレポ反対派の昔の言い分：ビルド時間。200個のパッケージがあるリポで1ファイル変えたら、200個全部rebuild？ この議論は2022年から2024年のどこかで賞味期限切れになった。 現代的なビルドツールはコンテンツベースのキャッシュ。変わったものだけ再構築、入力が同じなら何もしない。`payments`パッケージ変更しても、`design-system`になんも変わってなけりゃ再構築スキップ。GitHub Actionsは有料の遠隔キャッシュ必要になるまで、10GB無料。 TurborepoはJavaScript/TypeScriptチームなら20パッケージくらいまで無難。設定は`turbo.json`1ファイル、リモートキャッシュはVercel無料またはセルフホスト、学習曲線も緩い。チーム1日で実戦投入できる。 20パッケージ超、または複数言語混在のビルドなら、Nxのより体系的なアプローチが急な学習曲線に見合う。コード生成、自動CI分散、粒度細かい依存トラッキングがあって、リポでかくなるほど価値が上がる。 超大規模組織で複数言語にまたがる数千パッケージ運用なら、Bazel（Googleのオープンソースビルドシステム）が唯一のスケール設計。セットアップコストは重く、ほぼ常に専任プラットフォーム班が要る。 ![Multiple parallel deployment pipelines flowing from a central codebase, abstract DevOps infrastructure concept](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/accorata/2026-09/6761f6-img-2-inline.webp) ## チーム判断を決める4つの質問 万能な正解はないが、信頼できる枠組みはある。 **1. チーム間で頻繁に変わるコード共有してますか？** 共有デザインシステム、共有APIクライアントライブラリ、共有認証ロジックなら、モノレポはほぼ正解。複数リポ間で共有ライブラリを同期させたままにするなら、継続的な規律が要る。ほぼ絶対に漂流する。 **2. チーム独立してデプロイできますか？** チームAが火曜、チームBが木曜に調整なしでリリースできるなら、ポリレポの価値あり。別のサービスのリリースに同時リリース要するなら、その結合コストは判断に入る。 **3. 何人のエンジニアがこのコードベースに触ってますか？** 20人未満なら、リポ構造はそこまで要らない。50人超なら、ポリレポのコスト調整が目に見える。200人超なら、チームが本当に製品と技術で分離してない限り、モノレポケースが非常に強くなる。 **4. チーム間でコード分離するセキュリティ・コンプライアンス要件ありますか？** 金融・医療・一部の政府機関など規制の厳しい業界では、コードアクセスを特定スタッフに限定する必要がある場合がある。その制約が判断を上書きできる。コンプライアンス的に厳密な分離が必須なら、ポリレポは選択肢じゃなく制約だ。 質問1「はい」かつ質問4「いいえ」なら、モノレポはほぼ確実に正解。質問1「いいえ」かつ質問2「はい」なら、ポリレポは防御可能。それ以外は判断の呼び出し。 ## 成長したエンジニアチームが実際にやってること ほぼ完成度の高い組織は両極端では動かない。よく見るパターン：コアプロダクト（フロントエンド、共有ライブラリ、相互依存バックエンドサービス）はモノレポ、本当に独立したコンポーネントはリポ分け。 独立スケジュールで動いてメインプロダクトとコード共有しないデータパイプラインはモノレポの外。1人チームが保守する内部ツールは外。公開可視性が必要なオープンソースライブラリは外。 妥協じゃなく、清潔な二者択一めったにない質問への正解。一緒に動く物は一緒に。本当に独立してる物は分ける。 大事：デフォルトじゃなく、意図的に決める。ポリレポ肥大化に終わるチーム、選んでない。サービス1個から始まって、次、その次...という感じで、「これ一緒に住むべき？」と立ち止まらなかっただけ。 ## どちらでも機能させるツール群 **モノレポ向け:** - Nx：最強の機能セット、ポリグロットビルド・20超パッケージ向け。学習曲線急だが、さらに拡張する。 - Turborepo：シンプルなスタート、20以下パッケージJS/TS向け。ネイティブVercelキャッシュまたはセルフホスト。 - Bazel：超大規模マルチ言語リポ、エンタープライズスケール向け。セットアップ投資大。 **ポリレポ向け:** - 共有ライブラリのバージョン規律は必須。セマンティックバージョンと統一変更ログなしなら、依存漂流が半年で常態化。 - 共有依存更新時にクロスリポパイプラインをトリガーするCI/CDツール。GitHub ActionsはリポURL間で`workflow_dispatch`と`repository_dispatch`サポート。 - 依存レジストリ（npm private registry、GitHub Packages、Artifactoryなど）で共有パッケージ分配管理。 Biscuitがコンフィグ取れる。どっち選ぶかの判断は、それでもあの4つの質問に帰結する。 ![Developer working at dual monitor setup reviewing pull requests in a dark home office](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/accorata/2026-09/47a076-img-3-inline.webp) ## FAQ ### モノレポとポリレポ、どちらが「正解」ですか？ 万能な正解はない。チーム間のコード共有の頻度、独立性、調整コストの許容度で決まる。小規模チームなら構造は二の次。50人超のチームなら、モノレポの利点が目に見える。 ### モノレポでビルド時間が長くなるのでは？ 2024年以降、Turborepo や Nx などの最新ビルドツールがコンテンツベースのキャッシュで解決した。変わったものだけ再構築する仕組みで、リポサイズはもう制限要因じゃない。 ### 共有ライブラリの同期がめんどくさいです それはポリレポの典型的な隠れコスト。複数リポ間で共有ライブラリを最新に保つなら、継続的な規律が必要。モノレポなら、1つのPRで全体が同期。 ### セキュリティ・コンプライアンス的にはどう？ 規制の厳しい業界（金融・医療）でコードアクセス制限が必須なら、ポリレポが要件になることもある。ただし多くの場合、モノレポ内でもアクセス制御は可能。 ### 現実のチームはどうしてる？ 大多数は両者を組み合わせてる。コアプロダクトはモノレポ、独立したコンポーネント（データパイプライン、内部ツール、OSS）はリポ分け。 ### Nx、Turborepo、Bazelどれを選ぶ？ JS/TS 20パッケージ以下なら Turborepo。20超またはポリグロットなら Nx。超大規模マルチ言語なら Bazel。ただしセットアップは重。