フロントエンドのプロジェクトが増えてきたとき、リポジトリ構成の見直しに直面する方に向けた内容です。マイクロフロントエンド（1つの画面を複数のチームが独立してデプロイできるフロントエンド分割手法）を検討し始めたタイミングや、共通コンポーネントライブラリを複数のチームで使い回すようになったタイミングで、この判断は避けて通れなくなります。
モノレポ（monorepo、複数のアプリやサービスを1つのGitリポジトリにまとめる構成）にするか、ポリレポ（polyrepo、サービスごとに個別のリポジトリを持つ構成）にするか。この問いは単なるGitの設定ではなく、チームの境界線とビルドパイプラインの設計そのものに関わってきます。
結論から言うと、リポジトリの数そのものは本質ではありません。50個のリポジトリがあっても密結合したチームは1つのシステムのように振る舞いますし、逆に1つの巨大なモノレポの中に、互いに無関係な複数のアプリが同居しているケースもあります。大事なのは「どこにチーム・コード・依存関係・デリバリーパイプラインの境界線を引くか」という設計判断です。
判断が必要になる典型的な場面
フロントエンドの現場でこの選択が浮上するのは、共通のUIコンポーネント（ボタンやフォームなどの再利用パーツ）を複数のプロダクトで使い回し始めたときです。
たとえば管理画面・ECサイト・LPの3つが同じデザインシステムを参照するようになると、コンポーネントの変更が3つの成果物に波及します。この波及範囲をどう管理するかが、リポジトリ構成の選択に直結します。
Next.jsやViteでのマイクロフロントエンド導入、Turborepo・Nxといったモノレポ向けビルドツールの採用を検討し始めた段階も、判断のタイミングとして典型的です。
判断軸1: 変更の同時性
APIの型定義やデザインシステムのトークン（色・余白などの共通定義）を変更したとき、複数のフロントエンドプロジェクトを同時に更新する必要があるかどうかです。
モノレポなら、共通パッケージを1箇所で変更し、それを参照する全プロジェクトのビルド・テストを同じPRの中で確認できます。TypeScriptのコンパイラやESLintが、影響範囲を機械的に洗い出してくれます。
ポリレポの場合は、共通ライブラリをnpmパッケージとして公開し、各プロジェクトが新バージョンを取り込むまで待つ必要があります。バージョンのズレが起きやすく、更新の反映に時間差が生まれます。
判断軸2: リファクタリングの範囲
共通関数のシグネチャ変更のような、影響範囲の広いリファクタリングをどれくらいの頻度で行うかです。
たとえばuseAuth()フックの戻り値の型を変えるケースを考えます。モノレポならIDEやtsc（TypeScriptコンパイラ）が呼び出し箇所を即座に洗い出してくれます。
ポリレポだと、共通ライブラリの新バージョンを各リポジトリに配布し、それぞれのCIが通るのを個別に待つ作業が発生します。技術的な変更は小さくても、組織的な調整コストは大きくなりがちです。
判断軸3: CI/CDのコストとビルド時間
リポジトリが1つに集約されるほど、CI（継続的インテグレーション）のビルド対象が肥大化しやすくなります。
モノレポでこの問題に対処するには、Turborepoのようなツールが提供するキャッシュ機構や、変更されたパッケージだけをビルドする差分検知（affected detection）の仕組みが必要になります。
Nxのnx affectedコマンドや、Turborepoのturbo run build --filterのような機能を使えば、無関係なプロジェクトまでビルドし直す無駄を避けられます。こうしたツール投資をしない前提でモノレポを選ぶと、CIの待ち時間がチーム全体のボトルネックになります。
判断軸4: チームの自律性と権限境界
チームごとにデプロイのタイミング・レビュープロセス・コーディング規約を独立させたいかどうかです。
ポリレポは、リポジトリ単位でアクセス権限やCIの設定を分離しやすく、チームごとに異なるリリースサイクルを持たせやすい構成です。組織のセキュリティ要件でリポジトリ単位のアクセス制御が必須な場合にも相性が良くなります。
モノレポでもCODEOWNERSファイルやパスベースの権限管理で疑似的な分離は可能ですが、完全な独立性を求めるなら分離のコストは相対的に低くなります。
選択肢の比較
| 観点 | モノレポ | ポリレポ |
|---|---|---|
| 横断的な変更のしやすさ | 1つのPRで完結しやすい | 複数リポジトリの調整が必要 |
| CIのビルド時間 | ツール投資なしだと肥大化しやすい | リポジトリごとに小さく保ちやすい |
| チームの独立性 | 権限分離の設計が別途必要 | リポジトリ単位で自然に分離できる |
| 初期導入コスト | Turborepo/Nx等の学習が必要 | 既存のGit運用の延長でよい |
ケース別の推奨
デザインシステムを複数プロダクトで共有していて、型の不整合がよく問題になるなら、モノレポとTurborepoまたはNxの組み合わせを検討する価値があります。
共通コンポーネントの変更がリリースの度に手戻りを生んでいるなら、まず影響範囲を1つのCIで可視化できる体制に寄せる方が効きます。
逆に、フロントエンドとバックエンドのチームが完全に別のリリースサイクルで動いていて、セキュリティ上リポジトリ単位のアクセス制御が求められるなら、ポリレポを維持したままAPI契約をOpenAPIやGraphQLのスキーマで明示的に共有する方が現実的です。
小規模なチーム（3〜4人程度）でプロジェクトが1〜2個しかない場合は、どちらを選んでも大きな差は出にくく、今の構成を変える緊急性は低いと考えられます。
あえて見送るべき条件
モノレポ化を見送った方がよいのは、CIのキャッシュ設計やビルドの差分検知に投資する余裕が今すぐには取れない場合です。
ツールなしでモノレポに移行すると、プロジェクトが増えるたびにビルド時間が線形に伸び、開発者の待ち時間がむしろ悪化します。
逆にポリレポへの分割を見送るべきなのは、まだ1つのチームが全プロダクトを見ている段階です。この段階で無理に分割すると、共通ライブラリのバージョン管理という新しい調整コストだけが増えます。
まとめ
リポジトリ構成の選択は、Gitの設定ではなくチームとコードの境界線をどう引くかという設計判断です。
判断の起点として、まず自分のプロジェクトで「共通コードの変更が何個のプロジェクトに波及するか」を数えてみることをおすすめします。波及範囲が広く型の不整合が頻発するならモノレポとビルドツールの組み合わせ、チームの独立性やアクセス制御を優先したいならポリレポが選びやすい方向です。
すでにモノレポを検討しているなら、Turborepoのturbo run build --filterやNxのnx affectedのドキュメントを実際に開いて、差分ビルドの設定がどの程度の学習コストで済むかを確認してみるとよい判断材料になります。