フロントエンドのCLIツールやSDKを複数リポジトリに分割して運用している方に向けた内容です。小さな機能追加のはずが、複数リポジトリのリリースを連鎖させないと届かない構成になっていないか、判断材料を整理しました。
CLI（コマンドラインツール）にフラグを1つ追加するだけの作業を思い浮かべてください。コア機能を直し、それを外部公開するAPIを直し、そのAPIをラップする生成SDK（Software Development Kit、APIを扱いやすくする補助ライブラリ）を直し、さらにそれを使いやすくするラッパーSDKを直し、最後にCLI本体を直す。4つのリポジトリを順番にリリースしないと、ユーザーの手元にフラグ1つ届かない構成です。このような「マルチリポ税」とも呼べる摩擦は、フロントエンドのモジュール分割やパッケージ設計でも同じ形で発生します。
どんな場面でこの判断が必要になるか
フロントエンド開発では、UIコンポーネントライブラリ、APIクライアント、CLIツール、共通ユーティリティなどを別々のnpmパッケージ・別々のリポジトリに分けるケースがよくあります。npm（Node.jsのパッケージ管理システム）でバージョンを固定して依存させる設計は、責務分離という点では理にかなっています。
ただし、ある機能追加が複数パッケージにまたがった瞬間に問題が表面化します。パッケージAを直し、リリースし、パッケージBの依存バージョンを上げてリリースし、パッケージCで使う、という手順を毎回踏む必要が出てきます。途中で設計ミスに気づけば、この連鎖を最初からやり直すことになります。
この摩擦がチームの生産性に与える影響が無視できない規模になってきたら、リポジトリ構成そのものを見直すタイミングです。
判断軸1: 変更の伝播範囲
最初に確認したいのは、機能追加や修正が普段どれくらいの数のリポジトリ・パッケージをまたぐかです。
1つのパッケージ内で完結する変更が大半なら、マルチリポ（複数リポジトリ）構成でも大きな痛みはありません。逆に、コア→API→SDK→CLIのように毎回3つ以上のリポジトリを横断するなら、リポジトリ分割の境界線が実際の変更の単位と一致していない可能性があります。
直近3ヶ月のプルリクエスト（コード変更の提案・レビュー単位）を振り返り、「1つの機能追加のために何個のリポジトリでPRを作ったか」を数えてみると、実態が見えてきます。
判断軸2: バージョン固定の必要性
次に確認したいのは、コンポーネント間でバージョンをピン留め（固定）する必要が本当にあるかどうかです。
社外に公開しているSDKやライブラリは、利用者の環境が壊れないようセマンティックバージョニング（メジャー・マイナー・パッチで互換性を表す採番ルール）に沿ったリリースが欠かせません。一方、社内でしか使わないラッパーSDKやCLIの内部依存まで律儀にバージョンピンする必要があるかは、別問題です。
バージョンピンをやめて未固定のブランチを直接参照する運用も考えられますが、これは上流の破壊的変更が下流に無警告で流れ込む「ビルドの脆さ」を招きます。CIで上流の変更を検知できていない場合、この選択肢はリスクが高いと判断してください。
判断軸3: ビルド・テスト基盤の対応状況
モノレポ（複数プロジェクトを1つのリポジトリで管理する構成）を選ぶなら、依存関係全体をビルド・テストできる基盤が前提になります。
フロントエンドの文脈では、Turborepo、Nx、pnpm workspaces、Bazelといったツールが候補です。これらはリポジトリ内の依存グラフを解析し、変更があったパッケージとその影響範囲だけを再ビルド・再テストする仕組みを持っています。
この基盤がないままモノレポ化すると、逆にCIの実行時間が肥大化し、無関係な変更のたびに全パッケージがビルドされる事態になりかねません。導入前に、手元のCI設定ファイル（GitHub Actionsのworkflowなど）でキャッシュや差分ビルドの仕組みがあるかを確認しておく必要があります。
判断軸4: 個別リリースの必要性
モノレポ化しても、外部チームや社外ユーザー向けに個別リリースを続ける道は残されています。
リポジトリを1つにまとめることと、成果物を1つのパッケージとして配布することは別の話です。モノレポ内の各パッケージから個別にnpm publishする運用は十分に成立します。「1つにまとめたら、もう個別リリースできなくなるのでは」という懸念は、この点を整理すれば解消できます。
選択肢の比較
| 観点 | マルチリポ | モノレポ |
|---|---|---|
| 変更の反映速度 | リリース連鎖が必要で遅い | 最新コミット参照で即時反映 |
| 破壊的変更の検知 | 公開後に発覚しやすい | CIで即座に検知しやすい |
| 初期セットアップ負荷 | 低い（分割済みなら追加作業不要） | ビルド基盤の整備が必要 |
| コードの発見しやすさ | リポジトリを跨いで探す必要あり | 1箇所で検索・参照が完結 |
ケース別の推奨
複数パッケージにまたがる機能追加が月に何度も発生し、そのたびにPRを3つ以上作っているなら、モノレポ化の検討に踏み込む価値があります。まずはTurborepoやNxのドキュメントで、既存のパッケージ構成をワークスペースとして取り込めるか確認してください。
社外公開しているライブラリと社内専用ツールが混在しているなら、モノレポ内でパッケージごとに公開設定を分ける運用が現実的です。pnpm workspacesのpublishConfigやchangesetsツールで、パッケージ単位のリリース管理は十分に実現できます。
変更が各パッケージ内でほぼ完結しており、他パッケージへの影響が稀なら、無理にモノレポ化する理由は薄いと言えます。分割そのものが問題ではなく、境界線の引き方が実態と合っているかどうかが焦点です。
あえて見送るべき条件
チームの規模が小さく、パッケージ間の依存関係もシンプルなら、モノレポ化のための基盤整備コストが見合わない可能性があります。
また、すでに複数の独立したプロダクトチームがそれぞれ異なるリリースサイクル・異なる技術スタックで動いている場合、無理に1つのリポジトリへ統合すると、CIの設定やアクセス権限管理がかえって複雑になります。この場合は、リポジトリは分けたまま、依存解決の摩擦だけを減らす方向（内部レジストリの整備やリリース自動化ツールの導入）を先に検討したほうが現実的です。
まとめ
リポジトリ構成は、設計パターンほど議論されない割に、日々の開発速度に直結する要素です。
判断の出発点として、直近の機能追加が何個のリポジトリ・PRにまたがったかを数える作業から始めてみてください。その数が慢性的に多いなら、TurborepoやNxのドキュメントを開き、既存パッケージをワークスペースとして統合できるか確認する段階に進んで問題ありません。
逆に変更がパッケージ内で完結しているなら、今の分割を急いで見直す必要はありません。境界線が実態と合っているかどうかを、定期的に確認する習慣を持っておくと安心です。