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

Monorepoのシステム開発は、複数のアプリや共通コードを一つのリポジトリで管理し、共有範囲、業務の境界、リリース方式を整理したうえで、開発と運用を一つの基盤で進める方法です。各テーマの詳細は、次の関連記事もご覧ください。

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

Monorepoのシステムの全体像

Monorepoは、共通コードを安全に再利用し、変更の影響範囲を見えるようにするための運用設計です。また、複数のチームの開発ルールもそろえられます。

リポジトリを一つにまとめること自体が目的ではありません。

Monorepoの定義

Monorepoは、アプリや共通コードを一つのバージョン管理リポジトリで管理しつつ、用途に応じて分けて運用できる方式です。

管理対象：複数のアプリ、サービス、ライブラリ、インフラ定義
アプリの配置例：販売管理画面、在庫管理API、共通認証、請求バッチ
共通化の例：型定義、UI部品、ログ処理を共通パッケージとして参照
実行・リリース：アプリごとにビルド、テスト、デプロイを行い、障害時も全体を止めず、変更したサービスだけをリリースできる

モノリスやPolyrepoとの違い

違いは、実行の単位とソースコードの管理の単位をどこに置くか、そしてリポジトリを分けるかどうかにあります。

モノリス：アプリの機能や実行単位が一体化した構成
Monorepo：同一コミットで変更を反映しやすく、独立デプロイも一体リリースも可能
Polyrepo：アプリやライブラリごとに分け、権限の境界やチームの単位をはっきりさせる
運用上の違い：Polyrepoは共通更新や横断修正が複雑になりやすく、Monorepoは全体の統治とCI設計が必要

両者は組み合わせることもでき、Monorepoの中にモノリス型のアプリを置く構成もあります。

Monorepoの種類と適用判断

Monorepoの構成は、パッケージの管理方式、アプリの分け方、チームと業務ドメインの境界によって変わります。そのため、ツールの名前だけで選ばず、導入する側と開発会社が、共有する範囲と独立させる範囲を先に決めておきます。

ワークスペース型の構成

ワークスペース型は、パッケージ管理の機能で複数のパッケージをまとめる構成です。導入を始めやすいのが特徴です。

利用ツール：pnpm、npm workspaces、Yarnなど
ルートで管理：設定ファイル、ロックファイル、共通スクリプト
始めやすい対象：小規模Webアプリや、共通UI・型定義・APIクライアントを持つチーム
追加設計：依存方向、公開API、影響範囲、CI、成果物、テスト、環境変数
設定後の対応：ワークスペースの設定だけでは、影響判定やCIの高速化は完了しない

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

複数のアプリで共通コードを使う組織では、Monorepoが候補になります。ただし、導入を検討する側は、権限や技術を分ける必要があるかも確かめます。

向く組織：複数アプリが型定義や認証、UI部品、業務ルールを共有する
効果を測りやすい状態：チーム間でレビュー基準がばらついている
Polyrepoが候補の状態：厳格なアクセス分離や異なる技術・リリース周期が必要
導入前の確認：共有コードが少なく、横断変更もほとんどない

共通ライブラリの更新漏れが障害につながっている組織も、導入の効果を測りやすい対象です。一方で、Polyrepoのほうが管理しやすい組織もあります。

まずは1〜2ドメインに絞って試し、そのあとで全社への統合を考えます。判断材料として、CI時間や重複コード、リリース頻度、レビュー待ち時間を測っておきます。

ポイント

共有範囲と独立させる範囲を先に決め、そのうえで構成とツールを選びます。小規模で共通部品を持つチームはワークスペース型から始めると進めやすいです。

構成例とツールの選び方

共有部品と業務データの境目が、変更の広がりを左右します。

ツールを選ぶときは、対応言語やプロジェクト数、CIの実行時間を比べます。開発者の習熟度やセルフホストの要否も、あわせて確かめます。そのうえで、導入の前にディレクトリと依存関係のルールを決めておきます。

業務システムの構成例

アプリ、共通部品、データを分けたうえで、業務の境界に沿って責任の範囲を保つ構成の例です。

apps：販売管理フロント、在庫API、請求バッチ、管理画面
packages：認証、権限、APIクライアント、型定義、UI部品、監査ログ
データ境界：DBは業務ごとに分け、共通パッケージから直接接続しない
変更範囲：共通認証を変えたときは影響するアプリを検出し、必要なテストを実行する
共有範囲：安定した契約や小さな部品を共有し、業務ルールはドメイン側に置く

業務ロジックを共通化しすぎると、販売・在庫・請求の間で変更が連鎖してしまいます。

ワークスペース管理ツールの選び方

ツールは、JavaScript中心の軽量な構成から多言語の大規模な管理まで、開発規模に合わせて選びます。

軽量なJavaScript・TypeScript開発：pnpmなどとTurborepo
組織的な依存管理：Nx
大規模Web開発：Rush
多言語・巨大規模：再現可能なビルドを重視してBazelも検討

pnpmとTurborepoは、タスクの依存関係、並列実行、キャッシュ、変更範囲を、比較的少ない設定で扱える組み合わせです。

Nxは、プロジェクトグラフやコード生成、依存境界、分散CIまで管理したい場合の候補になります。選ぶときは、失敗時のログとキャッシュの無効化も確認しておきます。

選定では、開発者が原因を追えるか、将来の内製移管が可能かも確かめてください。

ポイント

ツールは開発規模に合わせて選びます。軽量なJavaScript開発ならpnpmとTurborepo、組織的な依存管理ならNx、多言語・巨大規模ならBazelも検討します。

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

各段階の判断根拠を残すと、移行計画を見直しやすくなります。

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

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

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

適用範囲を決めるには、既存の資産と業務の境界を把握したうえで、移行の方式と退避条件を整理します。

リポジトリ、アプリ、パッケージ、担当チーム、使用言語、依存関係の一覧を作り、CI時間、リリース頻度、障害履歴も確かめます。
業務の境界とコードの境界は一致するとは限らないため、販売、在庫、請求などの責任範囲も押さえます。
全リポジトリの一括統合、共通ライブラリの先行統合、1ドメインずつの段階移行を比べます。
移行中の旧リポジトリからのリリース退避策、対象外の基準、元に戻す条件を決めておき、計画変更に備えます。

標準化と依存関係の設計

複数のチームが安全に変更するには、共通ルールと依存の向きを文書にして決めておく必要があります。

開発規約：ディレクトリ、命名、パッケージ名、NodeやJavaのバージョン
運用設定：依存方向、公開API、ロックファイル、環境変数、ログ、テストレベル
所有と承認：共通パッケージの所有チームと、破壊的変更の承認者
依存境界：アプリから共通パッケージへ依存し、共通パッケージ同士の循環は禁止
ドメイン間連携：直接参照せず、APIやイベントを介して連携し、将来のPolyrepo分割に備える

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

開発会社がCI/CDを設計し、変更の影響を必要な範囲に絞って、アプリ単位で安全にリリースできる仕組みを整えます。

affected判定：変更したパッケージと依存先だけをテスト・ビルド
実行効率：タスクの並列実行、成果物のキャッシュ、プレビュー環境
デプロイ：アプリ単位に分離し、承認ゲートと段階リリースを設定
受入条件：ロールバックと、データベース変更の後方互換性の確認

リモートキャッシュは、チームやCIで成果物を共有し、同じ入力の処理を省ける仕組みです。公式資料では、マネージド環境とセルフホストの構成が示されています。

また、成果物にHMAC-SHA256署名を付けて完全性と真正性を検証する方法も、公式ドキュメントで説明されています（出典: Turborepo公式ドキュメント、2026年確認）。ログもキャッシュの対象になるため、秘密情報や個人情報を出力しない設計が必要です。

ポイント

導入は、現状把握と適用範囲の決定から始めます。一括統合と段階移行を比べ、CI時間や障害履歴などの実測値をもとに、対象を広げるか決めます。

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

対象規模が上がるにつれて、概算費用の幅も大きくなります。

Monorepo構築だけを対象にした国内の統一相場は公表されていません。そのため、ここに示す数字は2026年時点の編集用の概算です。

この概算は、リポジトリ数やパッケージ数、言語数、既存テストを前提にしています。さらに、CI/CD、セキュリティ要件、移行の難易度も含めています。機能開発やデータ移行は、別の見積もりになります。

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

規模別の費用相場

新規構築から既存の移行、大規模対応まで、規模ごとの費用と期間を次のとおり並べます。

小規模な新規構築：4〜8人月、約240万〜800万円、1.5〜3か月
既存リポジトリの統合・移行：10〜25人月、約600万〜2,500万円、3〜8か月
大規模・複数言語・規制対応：25〜80人月、約1,500万〜8,000万円、6〜18か月

小規模な新規構築には、3〜6パッケージとWebアプリ1〜2個が含まれます。また、ワークスペースや基本的なlint・単体テスト、CI、README整備も含まれます。

既存コードが少なく、共通パッケージの範囲が明確であれば、PoCから始めることもできます。

既存移行は、5〜20リポジトリと10〜50パッケージが対象です。依存関係の整理、テストの補修、デプロイの分離、権限の設計が含まれます。特に工数がかかるのは、壊れたビルド、暗黙の環境差、古い依存関係の修正です。

大規模対応では、数十〜数百のパッケージや複数のクラウドを扱います。加えて、監査ログ、SSO、多要素認証、SBOM、災害対策も対象になります。

費用は、基幹業務の機能開発やデータ移行まで含めると、数千万円から1億円を超えることもあります。

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

見積書は作業を「一式」にまとめず、工程や役割ごとに分けてもらうと、複数の案を比べる際に役立ちます。

計画・設計：要件整理、現状調査、設計
構築・移行：移行、テスト補修、CI/CD、セキュリティ
定着・運用：ドキュメント、教育、保守

デジタル庁の実践ガイドブックでは、人件費を工数と単価の掛け算で積算し、20人日を1人月とする考え方が示されています（出典: デジタル庁「標準ガイドライン実践ガイドブック」、2025年）。

工程ごとの人日、人月、役割、前提を分けておくと、比較しやすくなります。

初期費用とは別に、CIランナーやリモートキャッシュ、アーティファクト保管、コードホスティングの費用がかかります。さらに、監視、商用サポート、バックアップ、脆弱性スキャンの費用も必要です。

暫定予算は月5万〜50万円程度ですが、席数や実行時間、ストレージ、保管期間、セルフホストの運用工数によって変わります。そのため、契約の前に利用量を試算しておいてください。

ポイント

費用は規模によって大きく変わるため、見積もりを工程ごとに分けてもらいます。CIやキャッシュの利用料は初期費用とは別にかかるので、契約前に利用量を試算してください。

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

Monorepoでは、アクセス権やCIの秘密情報、依存パッケージを一つの運用体系で管理します。キャッシュや監査ログも、同じ体系に含めます。特に、権限を広げすぎると、機密コードや本番のデプロイ権限が、本来は不要なメンバーにまで届くおそれがあります。

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

発注側と開発会社で、業務ドメインと本番環境ごとに承認者を分け、認証と変更管理を組み合わせます。

認証・権限：SSO、多要素認証、最小権限
変更管理：CODEOWNERS、保護ブランチ、必須レビュー
本番反映：環境ごとのデプロイ承認
異動・退職時：リポジトリ、CI、クラウド、レジストリの権限を同時に見直す

秘密情報は、リポジトリやビルドログに出さず、CIのシークレット管理や短期トークンで扱います。

リモートキャッシュには、顧客データや個人情報、秘密鍵、内部URLを含めないよう確かめます。さらに、読み取り専用での実行や署名検証も検討します。

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

パッケージが増えると、間接依存の脆弱性やライセンス条件も増えていきます。そのため、依存関係の審査では次の点を扱います。

変更内容：プルリクエストで追加・更新された依存関係
リスク：既知の脆弱性とライセンス条件
運用：SBOM、重大度別の期限、例外承認者

公式の依存関係レビュー機能では、条件に応じてマージを止めることもできます（出典: コードホスティングサービスの公式依存関係レビュー文書、2026年確認）。

外部に委託する場合は、ソースコードに加えて、IaC、CI定義、テスト、設計書、SBOM、ビルド手順も引き渡しの対象に含めます。

契約書では、著作権の帰属と改修権、OSSの表示義務、秘密保持、脆弱性を見つけたときの連絡、SLA、別の体制へ移す条件を確かめます。

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

Monorepoの支援先は、大きく分けると、受託開発会社、ツール専門の支援、コードホスティングやCI/CDのサービス、クラウド基盤の設計支援があります。移行だけを支援してもらうのか、業務要件や運用、教育まで任せるのかによって、契約の範囲と費用は変わります。

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

発注側は、支援先の経験を、運用の規模や導入後の変化がわかる実績資料で確かめます。

運用規模：リポジトリ・パッケージ数とチーム数
運用状況：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、セキュリティ、運用移管の条件を分けて書いておきます。そうすると、支援先の提案を同じ基準で比べられます。

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
 ・スクラッチシステム開発の完全ガイドブック
 ・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。