# モノレポ vs ポリレポ 比較：データで判断する構造選択 URL: https://upstreamapi.com/ja/journal/monorepo-vs-polyrepo-hikaku Type: blog Locale: ja Published: 2026-09-12 Updated: 2026-09-13 --- > モノレポとポリレポの選択は好みの問題ではなく、計測の問題だ。320チームを12ヶ月間追跡したFaros AIのデータと30%ルールで、あなたの組織に合う構造を特定する。 **モノレポ vs ポリレポ 比較**において、答えは推薦ではない。計測だ。具体的には：複数のサービス境界をまたぐ変更が必要なフィーチャーの割合はいくらか？ その数字がわからないなら、チームの好みに基づいてインフラ決定を下していることになる。50人規模のエンジニアリング組織では、その「好み」が誰かの日曜日を奪うことになる。 キーワードは「計算」だ。両アプローチにはコストが伴う。自分の組織がどちらのコストをうまく吸収できるか、つまりポリレポの調整コストか、モノレポのツール投資か、それが問いだ。 ## PRサイクルタイムのデータは答えを出さない [Faros AIは320チームを12ヶ月間分析し](https://www.faros.ai/blog/monorepo-vs-polyrepo-benchmark-data)、モノレポ環境のPRサイクルタイム中央値が19時間であることを明らかにした。ポリレポ環境は2時間だ。 中央値で9.5倍の差がある。90パーセンタイルでは8.6日対5.5日と差は縮まるが、どちらの末端も遅い。平均値も収束する：モノレポが3.6日、ポリレポが2.8日だ。 反論は確立されている：キャッシュが機能する場合、モノレポの個別ビルド時間は速い。5つのリポジトリ、5つのCIパイプライン、5つのCODEOWNERSサインオフが必要なクロスサービス変更を調整しているポリレポチームも、2時間でPRをクローズできるわけではない。 このデータは典型的なPRのサイクルタイムを捉えているのであって、最悪ケースのクロスカッティングな変更を対象にしているのではない。その区別は重要だ。ポリレポチームは中央値（ほとんどのPRが分離されているので速い）を引き合いに出す。モノレポ支持者はリポジトリ間の調整の苦痛（これも現実で、PR末端の最悪ケースに記録されている）を強調する。両者はそれぞれ異なるシナリオについて正しい。 データは議論に決着をつけない。ただ、感覚よりも正確にトレードオフを記述するだけだ。 ![SREエンジニアが複数のダッシュボードを持つワークステーションでデプロイメントメトリクスを監視している](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-09/6a5eb6-inline1.webp) ## 計算されていないブラストラジウス カンファレンストークのスライドに滅多に出てこないのが、これだ：モノレポでは、壊れた共有依存関係が、ダウンストリームオーナーシップを持つ誰かが変更をレビューする前に、同じコミットで、それをインポートするすべてのサービスに波及する。 ポリレポでは、壊れたパッケージバージョンはアップグレードしたサービスを壊す。しかしアップグレードする時だけだ。ブラストラジウスは遅延し、コンシューマーの選択によって境界付けられる。 これはSLOゲートのロールアウトにとって重要だ。モノレポ内の壊れた共有ライブラリはカナリアウィンドウを与えてくれない。単一のデプロイイベントでクロスサービスのブラストラジウスをもたらす。ロールアウト自動化がパターンを検出してリバートをトリガーする前に、複数のSLOにまたがってエラーバジェットの消費が始まる。 ポリレポでは、共有依存関係の変更のロールアウトは本質的にシーケンシャルだ。サービスAがアップグレードしてSLOを監視する。サービスBは3日後にアップグレードする。任意の時点でのブラストラジウスは、すでに変更を採用した者の数によって境界付けられる。 問いは、どちらの構造が本質的に安全かではない。デプロイメントプリミティブが何かだ。デプロイメントユニットが独自のSLOゲートを持つサービスなら、ポリレポは自然な分離を提供する。デプロイメントユニットがフロントエンド、API、バックグラウンドワーカーを横断して一貫してランディングするアトミックなフィーチャー変更なら、モノレポはバージョニングのズレなしにその調整を可能にする。 マイクロサービスをシップしているほとんどのチームは前者の問題を抱えている。密結合したプロダクト表面をシップしているほとんどのチームは後者を抱えている。 ## 50人規模でポリレポが壁に当たる理由 調整コストは複利で増大する。8人のエンジニアで4つのリポジトリを管理するのは面倒だが実現可能だ。50人では、何人かにとってパートタイムの仕事になる。 ポリレポの調整オーバーヘッドが構造的になったサインの具体例： - プラットフォームチームが、誰も明確なオーナーシップを持たない共有ライブラリリポジトリを保守している - サービス間のバージョニングがずれすぎて、共有ライブラリのバンプが2週間プロジェクトになっている - 新入エンジニアが、23個のリポジトリのどれから最初にクローンすべきかを理解しなければ生産性を発揮できない - 共有依存関係へのセキュリティパッチが、追跡スプレッドシートとともに数十のリポジトリにまたがる調整PRを必要とする これらは作られた病理ではない。80人規模に到達し、リポジトリの決定を後悔しながら振り返ったチームのドキュメント化された失敗モードだ。 ポリレポは、チームが真に独立している場合に機能する：異なるリリースサイクル、異なるテックスタック、異なるオンコールローテーション。チームが、あるサービスの変更が他の3つについて推論することを必要とするほど多くのコードを共有する場合、ポリレポが購入した分離が調整を苦痛にさせるメカニズムになる。 組織的なサイン：クロスリポジトリリリースを調整するために特定的に存在するSlackチャンネルの数を数えよ。答えがゼロより多ければ、すでに調整コストを継続的に支払い始めている。 ## モノレポが95パーセンタイルで実際にかかるコスト Faros AIの90パーセンタイルデータは示唆に富む：90パーセンタイルでのモノレポPRは8.6日だ。遅いチームではない。複数のコードオーナー、広範なCIマトリクス、組織的な境界をまたがるレビューサイクルを必要とする大規模なクロスカッティング変更の構造的な帰結だ。 GoogleはBazelを持っている。MetaはBuckを構築した。Nx CloudとTurborepoのリモートキャッシュが存在するのは、モノレポをパフォーマンスよく動かすためのツール投資が軽微ではないからだ。200人規模のエンジニアリング組織でaffected-onlyビルド選択、分散キャッシュ、自動マージキューなしにモノレポを運用すると、共有ユーティリティ関数に触れるPRで45分間のCIランが生じる。 ツールコストは現実であり、日常的に過小評価される。モノレポをスケールで正常に運用しているチームは、そのインフラに特化したプラットフォームエンジニアを雇用している。プロダクトをシップしながら成長中のコードベースにモノレポツールを後付けするのは、ポストモーテムに現れる前にデプロイ頻度に現れる負担だ。 プラットフォームチームがすでにストレッチしているなら、モノレポツールのメンテナンスを追加することは重要なコミットメントだ。設定の選択ではない。 ![モノレポとポリレポのパイプライン構造を示すホワイトボード上のアーキテクチャ図](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-09/6dbec8-inline2.webp) ## 高パフォーマンスチームが実際に使う30%ルール この決定を意図的に下したチームからの有用なヒューリスティック：フィーチャーの30%超が複数のサービス境界をまたぐ変更を必要とする場合、ポリレポの調整オーバーヘッドは最終的に適切に運用されたモノレポのツール投資を超える。 30%未満では、ほとんどのマイクロサービス組織がそこに位置するが、ポリレポの分離メリットが通常調整コストを上回る。クロスサービスの変更は発生するが、共有ツールが分離よりも早く回収できるほど頻繁ではない。 これは計測可能だ。過去6ヶ月間のマージされたPRを引き出し、単一のユーザー向けフィーチャーをシップするために複数のリポジトリの変更が必要だったものの数を数えよ。その比率が入力値だ。小数点以下の精度はないかもしれないが、方向性は示す。チームの好みではなく、方向性で議論を止めるには十分だ。 12%のクロスサービス率を持つチームはモノレポを必要としない。38%で増加しているチームは複利で増大し続ける調整コストを支払っている。 ## ロールアウト戦略が計算を変える この決定のほぼカバレッジがない次元がある：ロールアウトプリミティブだ。 SLOゲート付きパーセンテージベースのロールアウトを実行している場合、つまりフィーチャーをトラフィックの5%にシップし、エラーバジェットを監視し、段階的に拡大する場合、フィーチャーが1つのサービスにまたがるか複数にまたがるかによってブラストラジウスの計算が変わる。 ポリレポでは、マルチサービスフィーチャーのロールアウトはサービス間でロールアウト状態を調整する必要がある。サービスAが20%にある間、サービスBはまだ0%という状態が生じ、インシデント状況下で推論するのが本当に困難な一貫性のない状態を作り出す。フィーチャーフラグは役立つが、ロールアウト進捗の単一の真実の源なしにクロスサービスフラグ状態を管理することになる。 アトミックコミットを持つモノレポでは、フィーチャーはサービス間で一貫してランディングする。ロールアウトはインフラレベルでパーセンテージベースのままだが、デプロイが発生した瞬間からコードは一貫している。SLOゲートはコヒーレントな状態に対して発火する。 アトミックマルチサービスフィーチャーを多数実行し、SLO違反に対する自動ロールバックとともにプログレッシブロールアウトを実施しているチームは、モノレポの一貫性がポリレポがクリーンな名称を持たないインシデントのカテゴリ全体を排除することに気づく場合が多い。クロスサービス状態の乖離インシデントだ。バグのように見えるが実際にはデプロイメント調整問題だ。 ## ポストモーテムが実際に語ること ほとんどのエンジニアリング組織は、アーキテクチャ的な妥協のように聞こえるためにハイブリッドとは誰も呼ばないハイブリッドに行き着く。 密結合したプロダクト表面には1つか2つのモノレポ。独立したデプロイメントサイクル、独自のオンコールローテーション、6ヶ月間共有ライブラリの変更を調整する必要がなかったチームを持つ真に自律的なサービスには別々のリポジトリ。 現在の設定を見直すシグナル： - クロスサービスの変更頻度が30%を超え、CIランタイムが複利で増大している - モノレポのツールに投資する能力を持つプラットフォームエンジニアを雇用した - ブラストラジウスインシデントで、ポリレポの分離が偽りであったことが明らかになった：サービスはインフラを十分に共有しており、分離はコンフォートを提供していたが安全を提供していなかった 現在は問題ないシグナル： - チームが真に独立しており、調整オーバーヘッドが低い - 最悪のインシデントがクロスサービス依存関係のドリフトによって引き起こされたものではなかった - プロダクト提供を遅らせることなくモノレポツールを維持するプラットフォームエンジニアリング能力が存在しない ポストモーテムはあなたが実際にどちらに生きているかを教えてくれる。その文書は通常、それが記述するシステムに先行したアーキテクチャ決定レコードよりも正直だ。 ## FAQ ### モノレポとポリレポの主な違いは何ですか？ モノレポはすべてのサービスを単一リポジトリに集約し、アトミックなクロスサービス変更と一貫したツールチェーンを可能にします。ポリレポは各サービスを独立したリポジトリで管理し、チーム間の自律性と独立したリリースサイクルを提供します。どちらが優れているかではなく、組織のフィーチャーのクロスサービス変更率に基づいて選択します。 ### モノレポのPRサイクルタイムはポリレポより本当に遅いですか？ Faros AIの320チームを対象とした12ヶ月間の調査によると、モノレポの中央値PRサイクルタイムは19時間、ポリレポは2時間と9.5倍の差があります。ただし、このデータは典型的なPRを対象としており、クロスリポジトリの複雑な変更では差が縮まります。大規模なクロスカッティング変更ではどちらの構造も遅くなります。 ### 30%ルールとは何ですか？どのように計算しますか？ 過去6ヶ月間のマージされたPRのうち、単一のユーザー向けフィーチャーをシップするために複数のリポジトリ変更が必要だったものの割合を算出します。この割合が30%を超える場合、ポリレポの調整オーバーヘッドはモノレポのツール投資を超える可能性があります。30%未満であれば、ポリレポの分離メリットが通常勝ります。 ### Google、Metaのようにモノレポをスケールさせるために必要なツールは何ですか？ GoogleはBazel、MetaはBuckを開発しました。商用ソリューションとしてはNx CloudとTurborepoのリモートキャッシュが一般的です。重要なのはaffected-onlyビルド選択、分散キャッシュ、自動マージキューの3点です。これらなしに200人規模でモノレポを運用すると、共有ユーティリティ関数に触れるPRで45分間のCIランが発生する可能性があります。 ### SLOゲートのロールアウトにはモノレポとポリレポのどちらが適していますか？ アトミックなマルチサービスフィーチャーをプログレッシブロールアウトで展開するチームにはモノレポが有利です。モノレポのアトミックコミットにより、デプロイ時点からコードはサービス間で一貫しており、SLOゲートはコヒーレントな状態に対して発火します。ポリレポでは、サービスAが20%ロールアウト中にサービスBが0%という非一貫状態が生じ、インシデント時の原因特定が困難になります。 ### ポリレポからモノレポへの移行を検討すべきタイミングはいつですか？ 以下の3つのシグナルが移行を示唆します：クロスサービス変更頻度が30%を超えてCIランタイムが増大している、モノレポツールに投資できるプラットフォームエンジニアを採用した、またはブラストラジウスインシデントでポリレポの分離が偽りであると判明した場合です。プラットフォームエンジニアリング能力なしに移行を試みると、プロダクト提供速度の低下に直結します。 ### ハイブリッドアプローチは機能しますか？ 多くの高パフォーマンスエンジニアリング組織が実際に採用しています。密結合したプロダクト表面にはモノレポを使用し、独立したリリースサイクル・オンコールローテーションを持つ真に自律的なサービスは別リポジトリで管理するパターンです。これをハイブリッドと呼ぶのを避けるのは、アーキテクチャ上の妥協のように聞こえるからですが、実際には多くの組織の現実的な解答です。