Monorepoのシステム開発の完全ガイド - ブログ

Monorepoのシステムとは、複数のアプリケーションや共通パッケージを一つのリポジトリで管理しながら、業務ごとのデプロイや運用は分けて進める開発基盤です。モノリス化とは異なり、コードの置き場所を統合する仕組みと、実行単位・データ・業務責任を分離する設計を両立できます。

本記事では、Monorepoのシステムの全体像、種類、モノリスやPolyrepoとの違い、導入の進め方、2026年時点の費用相場、セキュリティ、開発会社・サービスの選び方までまとめて解説します。新規構築だけでなく、既存リポジトリを移行する場合の判断材料や、あえてMonorepoを採用しない方がよい条件も整理しています。

Monorepoのシステムの全体像

Monorepoは、リポジトリを一つにまとめること自体が目的ではありません。共通コードを安全に再利用し、変更の影響範囲を見えるようにし、複数チームの開発ルールをそろえるための運用設計です。

Monorepoとは何ですか？

Monorepoとは、複数のアプリケーション、サービス、ライブラリ、インフラ定義などを一つのバージョン管理リポジトリで扱う方式です。たとえば販売管理の画面、在庫管理API、共通認証、請求バッチ、管理者向け画面を別々のアプリとして配置し、型定義やUI部品、ログ処理だけを共通パッケージとして参照できます。

一つのリポジトリに置くことと、一つの実行ファイルにすることは別です。アプリごとにビルド、テスト、デプロイを分けられるため、障害時に全システムを同時停止させず、変更したサービスだけをリリースする構成も可能です。

モノリスやPolyrepoとは何が違いますか？

モノリスは、アプリケーションの機能や実行単位が一体化した構成を指します。Monorepoはソースコードの管理単位であり、内部のアプリを分割して独立デプロイすることも、一体でリリースすることもできます。この二つは対立する概念ではなく、Monorepoの中にモノリス型のアプリを置く構成もあります。

一方、Polyrepoはアプリやライブラリごとにリポジトリを分ける方式です。Polyrepoは権限境界やチーム単位を明確にしやすい反面、共通ライブラリの変更、バージョン更新、横断的な修正の調整が複雑になりやすいです。Monorepoは変更を同じコミットで反映しやすい反面、リポジトリ全体のガバナンスとCI設計が欠かせません。

Monorepoの種類と適用判断

Monorepoの構成は、採用するパッケージ管理方式、アプリの分け方、チームと業務ドメインの境界によって変わります。名称だけでツールを選ぶのではなく、何を共有し、何を独立させるかを先に決めることが重要です。

ワークスペース型はどのような構成ですか？

最も取り入れやすいのは、パッケージマネージャーのワークスペース機能を使う構成です。pnpm、npm workspaces、Yarnなどで複数パッケージを管理し、ルートの設定ファイル、ロックファイル、共通スクリプトをそろえます。小規模なWebアプリや、共通UI・型定義・APIクライアントを持つチームで始めやすい方式です。

ただし、ワークスペースを設定しただけでは、影響範囲の判定やCIの高速化は完成しません。パッケージ間の依存方向、公開するAPI、ビルド成果物、テスト対象、環境変数の扱いまで決めて初めて、業務で使えるMonorepoになります。

Monorepoに向く企業と向かない企業

Monorepoに向くのは、複数のアプリが同じ型定義や認証、UI部品、業務ルールを共有し、横断的な変更を頻繁に行う組織です。チーム数が増えてレビュー基準がばらついている場合や、共通ライブラリの更新漏れが障害につながっている場合も、導入効果を測りやすいです。

反対に、組織間のアクセスを厳格に分離しなければならない場合、技術スタックやリリース周期が大きく異なる場合、共有コードがほとんどない場合は、Polyrepoの方が管理しやすい可能性があります。全社統合を前提にせず、まず1〜2ドメインで、CI時間、重複コード、リリース頻度、レビュー待ち時間を測定して判断するのが安全です。

構成例とツールの選び方

ツール選定では、対応言語、プロジェクト数、CIの実行時間、開発者の習熟度、セルフホスト要件を軸に比較します。ツールを導入すれば自動的に設計が良くなるわけではないため、先にディレクトリと依存関係のルールを定義します。

業務システムの構成例

たとえば、ルート直下にappsとpackagesを置き、appsには販売管理フロント、在庫API、請求バッチ、管理画面を配置します。packagesには認証、権限、APIクライアント、型定義、UIコンポーネント、監査ログを置きます。データベースは業務境界に合わせて分け、共通パッケージから直接データベースへ接続しないルールにすると、再利用と責任範囲を整理しやすいです。

この構成では、共通認証を変更したときに影響を受けるアプリを自動検出し、必要なテストだけを実行できます。一方、業務ロジックまで共通化しすぎると、一つの変更が販売・在庫・請求へ連鎖します。共有するのは安定した契約や小さな部品から始め、業務ルールはドメイン側に残す判断が重要です。

ワークスペース管理ツールはどう選びますか？

JavaScriptやTypeScriptが中心で、まず軽量に始めたい場合は、pnpmなどのワークスペースとTurborepoの組み合わせが候補です。タスクの依存関係、並列実行、キャッシュ、変更範囲の管理を、比較的少ない設定で整えやすいです。

プロジェクトグラフ、コード生成、依存境界のルール、分散CIまで組織的に管理したい場合はNxが候補になります。大規模Web開発向けの管理方式としてRushを比較し、多言語・巨大規模で再現可能なビルドを重視する場合はBazelも検討します。選定時には、機能一覧よりも、失敗時のログ、キャッシュの無効化、開発者が原因を追えるか、将来の内製移管が可能かを確認してください。

Monorepoのシステム開発の進め方

導入は、リポジトリを移動する作業ではなく、コード・チーム・デプロイ・権限を再設計するプロジェクトです。新規構築でも既存移行でも、現状把握、適用範囲の決定、標準化、CI/CD、運用移管の順に進めると、判断の根拠を残しやすくなります。

▶ 詳細はこちら：Monorepoのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

現状把握と適用範囲の決定

最初に、リポジトリ、アプリ、パッケージ、担当チーム、使用言語、依存関係、CI時間、リリース頻度、障害履歴を一覧化します。業務ドメインの境界と、現在のコード境界が一致しているとは限らないため、販売・在庫・請求などの責任範囲も合わせて確認します。

既存システムでは、全リポジトリを一度に統合する方法、共通ライブラリだけを先に統合する方法、1ドメインずつ段階移行する方法を比較します。移行中も旧リポジトリからリリースできる退避策、移行対象外を明確にする基準、元に戻す条件を決めておくと、計画変更に対応しやすいです。

標準化と依存関係の設計

次に、ディレクトリ規約、命名、パッケージ名、依存方向、公開API、NodeやJavaなどのバージョン、ロックファイル、環境変数、ログ形式、テストレベルを文書化します。共通パッケージをどのチームが所有し、破壊的変更を誰が承認するかまで決めることがポイントです。

依存関係は、アプリから共通パッケージへ向かう方向を基本にし、共通パッケージ同士の循環を禁止します。業務ドメインをまたぐ依存は、直接参照ではなくAPIやイベントなどの契約を介する方が、将来Polyrepoへ分割する場合にも移行しやすいです。

CI/CDと段階的なリリース

CIでは、変更されたパッケージとその依存先だけをテスト・ビルドするaffected判定、タスクの並列実行、成果物のキャッシュ、プレビュー環境を組み合わせます。デプロイはアプリ単位で分け、承認ゲート、段階リリース、ロールバック、データベース変更の後方互換性を受入条件に含めます。

リモートキャッシュはチームやCIで成果物を共有できるため、同一入力の処理を繰り返さずに済みます。公式ドキュメントでは、マネージド環境とセルフホストの両方が示され、成果物にHMAC-SHA256署名を付けて完全性・真正性を検証する方法も説明されています（出典: Turborepo公式ドキュメント、2026年確認）。ただし、ログもキャッシュ成果物として扱われるため、秘密情報や個人情報を出力しない設計が必要です。

Monorepoのシステム開発にかかる費用相場と期間

Monorepo構築だけを対象にした国内統一相場は公表されていません。以下は、リポジトリ数、パッケージ数、言語数、既存テスト、CI/CD、セキュリティ要件、移行の難易度を前提にした2026年時点の編集用概算です。機能開発やデータ移行を含める場合は、別見積もりとして扱う必要があります。

▶ 詳細はこちら：Monorepoのシステム開発の見積相場や費用/コスト/値段について

規模別の費用相場

小規模な新規構築は、3〜6パッケージ、Webアプリ1〜2個、ワークスペース、基本的なlint・単体テスト、CI、README整備を含めて4〜8人月、約240万〜800万円、1.5〜3か月が目安です。既存コードが少なく、共通パッケージの範囲が明確なら、PoCとしてこの規模から始められます。

既存リポジトリの統合・移行は、5〜20リポジトリ、10〜50パッケージ、依存関係の整理、テスト補修、デプロイ分離、権限設計を含めて10〜25人月、約600万〜2,500万円、3〜8か月を推定します。単純なGit移管ではなく、壊れたビルド、暗黙の環境差、古い依存関係を直す工数が中心になります。

大規模・複数言語・規制対応では、25〜80人月、約1,500万〜8,000万円、6〜18か月程度を見込みます。数十〜数百パッケージ、複数クラウド、監査ログ、SSO、多要素認証、SBOM、災害対策を含める場合です。基幹業務の機能開発やデータ移行まで含めると、さらに数千万円から1億円を超えることもあります。

見積もりで分けるべき費用

見積書では、要件整理、現状調査、設計、移行、テスト補修、CI/CD、セキュリティ、ドキュメント、教育、保守を「一式」にしないことが重要です。デジタル庁の実践ガイドブックでも、人件費は基本的に工数と単価の掛け算で積算し、20人日を1人月とする考え方が示されています（出典: デジタル庁「標準ガイドライン実践ガイドブック」、2025年）。工程ごとの人日、人月、担当者の役割、前提条件を分けると、複数見積もりを比較しやすくなります。

初期費用以外には、CIランナー、リモートキャッシュ、アーティファクト保管、コードホスティング、監視、商用サポート、バックアップ、脆弱性スキャンの費用がかかります。暫定予算として月5万〜50万円程度を置けますが、席数、実行時間、ストレージ、保管期間、セルフホストの運用工数で大きく変わるため、契約前に利用量を試算してください。

セキュリティ・ライセンス・運用の注意点

Monorepoでは、リポジトリを一つにまとめるほど、アクセス権、CIの秘密情報、依存パッケージ、キャッシュ、監査ログを一つの運用体系で管理する必要があります。開発効率だけを見て権限を広げると、機密性の高い業務コードや本番デプロイ権限まで不要なメンバーに届く危険があります。

アクセス制御とCIの秘密情報

最小権限、SSO、多要素認証、CODEOWNERS、保護ブランチ、レビュー必須、環境ごとのデプロイ承認を基本にします。業務ドメインや本番環境によって承認者を分け、退職・異動時にはリポジトリ、CI、クラウド、パッケージレジストリの権限を同時に見直します。

秘密情報はリポジトリやビルドログへ出力せず、CIのシークレット管理や短期トークンを使います。リモートキャッシュを使う場合は、成果物の中に顧客データ、個人情報、秘密鍵、内部URLが含まれないことを確認し、読み取り専用の実行や署名検証も検討します。

依存関係・OSSライセンス・契約

パッケージ数が増えると、直接依存だけでなく間接依存の脆弱性やライセンス条件も増えます。公式の依存関係レビュー機能では、プルリクエストで追加・更新された依存関係、既知の脆弱性、ライセンスなどを確認し、条件に応じてマージを止める運用ができます（出典: コードホスティングサービスの公式依存関係レビュー文書、2026年確認）。SBOMの生成、脆弱性の重大度に応じた期限、例外承認者を決めてください。

外部委託では、ソースコードだけでなく、IaC、CI定義、テスト、設計書、SBOM、ビルド手順を引き渡す対象に含めます。著作権の帰属と改修権、OSSの表示義務、秘密保持、脆弱性発見時の連絡、SLA、別の開発体制へ移管する条件まで契約書で確認することが重要です。

開発会社・ベンダー・サービスの選び方

Monorepoの支援先は、要件定義から受託する開発会社、ワークスペースやビルドツールの専門支援、コードホスティングとCI/CDのサービス、クラウド基盤の設計支援に分けて考えます。同じ「Monorepo対応」でも、移行作業だけを支援するのか、業務要件・運用・教育まで担うのかで、契約範囲と費用は大きく変わります。

実績と技術力を確認する方法

実績は「Monorepoを使ったことがある」という説明だけでなく、何リポジトリ・何パッケージを、何チームで、どの程度のCI時間、権限分離、リリース頻度で運用したかを確認します。可能であれば、導入前後のビルド時間、重複コード、リードタイム、障害件数、移行期間を匿名化した資料で提示してもらいます。

ツール名の多さより、依存グラフを説明できる設計力、テスト不足を補修する力、失敗時に切り戻せるCI/CD、業務ドメインの境界を守る力を評価します。複数言語、複数クラウド、規制対応がある場合は、対象環境と同じ条件で小さな検証を行うと、提案書だけでは分からない運用負荷を確認できます。

RFPと提案比較に入れる項目

RFPには、既存リポジトリ数、言語、アプリ数、パッケージ数、チーム数、CI時間、リリース頻度、権限区分、移行希望時期を記載します。移行対象と対象外、可用性、監査要件、データの保管場所、外部委託先のアクセス条件、納品物、内製移管の時期も明記します。

提案比較では、初期費用だけでなく、運用費、追加ライセンス、CIの利用量、キャッシュ保管、保守時間、教育、障害対応、契約終了時の移行費を含む総保有コストを比べます。PoCの成功条件を「導入できた」ではなく、CI時間を何％削減するか、レビュー待ち時間をどこまで短縮するか、共通コードの変更を何件安全に通すかなど、測定できる指標に置くことが大切です。

▶ 詳細はこちら：Monorepoのシステム開発でおすすめの開発会社/ベンダー6選と選び方

▶ 詳細はこちら：Monorepoのシステム開発の発注/外注/依頼/委託方法について

よくある質問（FAQ）

Monorepoの導入では、技術の疑問だけでなく、費用、組織、セキュリティ、将来の分割に関する質問が多く出ます。ここでは、業務システムの担当者が判断に使いやすい質問に絞って回答します。

Monorepoにすると開発費用は安くなりますか？

Monorepoにしただけで必ず安くなるわけではありません。初期には設計、移行、テスト補修、CI/CD、権限整備の費用がかかりますが、共通コードの重複や更新漏れを減らし、影響範囲に応じてCIを実行できれば、中長期の変更コストを抑えられる可能性があります。

既存システムをMonorepoへ移行する期間はどのくらいですか？

小規模な新規構築は1.5〜3か月、既存の5〜20リポジトリを統合する場合は3〜8か月、大規模・複数言語・規制対応では6〜18か月が一つの目安です。テストの不足、依存関係の複雑さ、権限分離、デプロイの再設計を含むかで変わるため、最初に1ドメインのPoCを行い、実測値から全体計画を更新してください。

MonorepoからPolyrepoへ戻すことはできますか？

できますが、分割を想定した境界設計が必要です。アプリと共通パッケージの依存方向、公開API、データ所有者、CIの責任者を明確にし、業務ドメインをまたぐ直接参照を減らしておけば、将来のリポジトリ分割や組織再編にも対応しやすくなります。

まとめ

Monorepoのシステムは、複数のアプリや共通パッケージを一つのリポジトリで管理し、変更を安全かつ速く共有するための開発基盤です。モノリスと同じ意味ではなく、デプロイ単位、業務ドメイン、データ、コード所有者を分離したまま、開発ルールと依存関係を一元化できます。

導入を成功させる要点

成功の要点は、最初から全社を統合するのではなく、共通UI、型定義、APIクライアントなど効果が測りやすい範囲でPoCを行うことです。CI時間、重複コード、レビュー待ち時間、リリース頻度、障害影響範囲を計測し、結果が確認できた範囲だけを段階的に広げます。ツール選定と同じくらい、依存境界、最小権限、テスト、契約、内製移管の設計が重要です。

次に決めること

まず既存資産とチームの境界を棚卸しし、Monorepoにする範囲、Polyrepoを残す範囲、PoCの成功指標、想定費用、移行時期を一枚にまとめてください。そのうえで、RFPに移行・テスト・CI/CD・セキュリティ・運用移管の条件を分けて記載すると、支援先の提案を同じ基準で比較できます。