モノレポとポリレポ：中規模チームでの選択基準と移行コスト

要点

モノレポの利点はツールチェーン投資とセットでのみ成立する。ビルドキャッシュや部分ビルドの基盤に投資できないチームでは、ポリレポの方が総運用コストは低くなりやすい。

モノレポが解決する問題

複数リポジトリにまたがる依存関係の更新は、バージョン固定と互換性確認の往復コストを生む。モノレポはこれを単一コミットでの一括更新に置き換えられる。Bazel や Nx といった主要ツールの公式ドキュメントは、この一括更新こそがモノレポ採用の中心的な動機であると位置づけている。

前提条件という代償

ただし、この利点にはコストが伴う。リポジトリが大きくなるにつれ、変更のたびに全体をビルドしていては CI 時間が線形に増加する。これを避けるには、依存グラフに基づく部分ビルドとリモートキャッシュが必須になる。Turborepo の公式ドキュメントが強調するように、これらの基盤を整えないままモノレポ化すると、CI 時間の増加という形でコストが利用者に転嫁される。Bazel の公式ドキュメントも同様に、部分ビルドの仕組みなしにモノレポを運用することは推奨していない。権限分離も課題で、単一リポジトリでは特定ディレクトリへの書き込み権限をチームごとに分けるための追加設定が必要になる。

判断基準

部分ビルドとリモートキャッシュに投資できるチームはモノレポの利点を活かせる。もっとも、そうした基盤への投資が難しい小規模チームでは、依存更新の頻度が低ければポリレポのシンプルさが上回る。ブランチ運用の選択がレビューや障害調査のしやすさを左右するのと同様に、モノレポかポリレポかは日々の開発体験を左右する構造的な判断であり、インフラをセルフホストするかマネージドにするかという別のコスト判断とも独立に検討すべきである。

ツール選定を先に決めるのではなく、まず CI 時間の許容範囲とチームの投資余力を数字で確認してから構成を選ぶことが、後戻りのコストを避ける近道である。