「モノレポで管理します」「こちらはリポジトリを分けて開発します」――開発会社から受け取った提案書や、打ち合わせの議事録の中に、こうした言葉が登場して戸惑った経験はないでしょうか。その場では話の流れを止めたくなくて分かったふりをしたものの、あとで意味を調べてみると、出てくるのはエンジニア向けの専門的な解説ばかり。ツールの名前やCI/CDといった、さらに分からない用語が増えるだけだった、という方も多いはずです。
発注者として本当に知りたいのは、「モノレポという言葉の正確な定義」だけではありません。その方針が自社のシステムの将来や、開発費用・保守費用、そして将来別の会社に引き継ぐときのしやすさにどう影響するのか、という点です。残念ながら、世の中にある解説記事の多くは開発者が読むことを前提に書かれており、発注者が「何を確認し、どう判断すればよいか」までは踏み込んでいません。
モノレポは、ひとことで言えば「ソースコードの保管場所のまとめ方」に関する選択であり、どちらが絶対に正しいという話ではありません。ただし、この選択はあとから変更しようとすると手間がかかることがあり、初期の設計段階で発注者が納得しておくことに意味があります。
本記事では、非エンジニアの方に向けて、モノレポとは何かを平易な言葉で定義したうえで、対になる「ポリレポ」や混同しやすい「モノリス」との違いを整理します。さらに、メリット・デメリットを費用や保守といった発注者目線に翻訳し、自社のプロジェクトに向いているかを見極める判断軸と、開発会社にそのまま聞ける確認質問のリストまで解説します。読み終えるころには、提案された方針に対して根拠をもって賛同したり、的確な質問を返したりできる状態を目指します。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
モノレポとは？発注者が知っておきたい基本
まずは「モノレポとは何か」を、専門用語をできるだけ使わずに整理していきます。モノレポを理解するには、その前に「リポジトリ」という言葉を押さえておく必要があります。
リポジトリ（ソースコードの保管庫）とは
システム開発では、プログラマーが書いたプログラム（ソースコード）を、専用の保管場所で一括管理します。この保管場所を「リポジトリ」と呼びます。書類を保管するキャビネットや、ファイルを整理しておくクラウドストレージをイメージすると分かりやすいかもしれません。
リポジトリには、現在のソースコードだけでなく、「いつ・誰が・どこを変更したか」という履歴がすべて記録されます。そのため、不具合が起きたときに過去の状態に戻したり、複数のエンジニアが同じシステムを同時に編集しても混乱しないように管理したりできます。システム開発において、リポジトリはソースコードの「正本」を保管する非常に重要な場所です。
ここで覚えておきたいのは、リポジトリはあくまで「ソースコードの保管庫」であり、実際に動いているシステムそのものとは別物だという点です。この区別は、のちほど「モノリス」との違いを整理する際に重要になります。
モノレポは複数システムを1つの保管庫にまとめる方式
一般的なシステム開発では、1つのシステムを複数の部品（サブシステム）に分けて作ることがよくあります。たとえば、社内の人が使う「管理画面」、お客様が使う「ユーザー向けアプリ」、それらの裏側でデータをやり取りする「API」といった具合です。
このとき、これら複数のサブシステムのソースコードを、すべて1つのリポジトリ（保管庫）にまとめて管理する方式が「モノレポ（Monorepo）」です。「モノ（mono＝単一）」と「レポ（repo＝リポジトリ）」を組み合わせた言葉で、「モノリポジトリ」と呼ばれることもあります。
たとえるなら、管理画面・ユーザーアプリ・APIという3つの書類の束を、1つの大きなキャビネットにまとめて入れて管理するイメージです。提案書で「モノレポ構成で開発します」と書かれていた場合、開発会社は「複数の部品をまとめて1か所で管理する」方針を取ろうとしている、と理解しておけば大きく外しません。
モノレポとポリレポ（リポジトリ分割）の違い
モノレポを理解するうえで欠かせないのが、対になる考え方である「ポリレポ」です。提案書では「リポジトリを分割します」「マルチリポで管理します」という表現で登場することもあります。
ポリレポ（リポジトリ分割）とは
ポリレポ（Polyrepo、マルチリポとも呼びます）は、サブシステムごとに別々のリポジトリ（保管庫）を用意して管理する方式です。先ほどの例で言えば、管理画面・ユーザーアプリ・APIのそれぞれに専用のキャビネットを用意し、3つの保管庫に分けて管理するイメージです。
モノレポが「1つの大きな箱にまとめる」方式だとすれば、ポリレポは「部品ごとに箱を分ける」方式だと考えると、両者の関係が掴みやすくなります。どちらが新しい／古いという話ではなく、それぞれに向いている場面があります。
モノレポとポリレポの比較
両者の違いを、発注者が気にしやすい観点で整理すると次のようになります。
観点 | モノレポ（まとめる） | ポリレポ（分ける） |
|---|---|---|
全体の見通し | 1か所に集まっているため、システム全体を把握しやすい | 保管庫が分散するため、全体像の把握には複数を確認する必要がある |
共通部品の使い回し | 同じ保管庫内にあるため、部品の共有・統一がしやすい | 保管庫をまたぐため、共通部品の共有に一手間かかることがある |
サブシステムの独立性 | まとまっている分、独立して動かしづらい面がある | 保管庫が独立しているため、サブシステム単位で扱いやすい |
将来の分離しやすさ | あとからサブシステムだけを切り出す際に手間がかかりやすい | もともと分かれているため、特定の部品だけ別扱いしやすい |
担当チーム・会社の分担 | 同じチームで一括開発する場合に向く | サブシステムごとに別チーム・別会社で担当する場合に向く |
ここで重要なのは、どちらにも長所と短所があり、優劣ではなく「プロジェクトの状況に合うかどうか」で選ぶものだという点です。提案書でどちらが提案されていても、この相対的な立ち位置を押さえておけば、開発会社の意図を読み取りやすくなります。
モノレポとモノリスの違い（混同しやすい用語の整理）
発注者が最も混乱しやすいのが、「モノレポ」と「モノリス（モノリシック）」の区別です。どちらも「モノ（単一）」で始まるため似た言葉に見えますが、実はまったく別の話をしています。ここを整理しておくと、提案書の用語を正しく分類できるようになります。
「リポジトリの分け方」と「システムの分け方」は別問題
ポイントは、2つの言葉が指している対象がそもそも違うということです。
- モノレポ／ポリレポは「ソースコードをどの保管庫に置くか」という、置き場所の話です。
- モノリス／マイクロサービスは「実際に動くシステムをどう分割するか」という、システムの構造（アーキテクチャ）の話です。
「モノリス」とは、1つのシステムを分割せず、ひとかたまりの大きなプログラムとして作る構造を指します。一方「マイクロサービス」は、システムを小さな部品（サービス）に分けて、それぞれが独立して動くように作る構造です。これは保管庫の話ではなく、稼働しているシステムそのものの組み立て方の話です。
重要なのは、この2つの選択が独立しているという点です。たとえば「モノレポで管理しつつ、中身はマイクロサービスとして作る」ことも、「ポリレポで管理しつつ、中身はモノリスとして作る」ことも可能です。保管庫のまとめ方と、システムの組み立て方は、それぞれ別々に選べるのです。
なお、システムの構造そのもの（モノリスとマイクロサービスの違い）については、別の観点で発注判断に関わるテーマです。アーキテクチャの選択について詳しく知りたい場合は、マイクロサービスとモノリスの違いとは？発注者が知るべき選び方の判断基準も併せて確認することをおすすめします。
よくある誤解（モノレポ＝モノリスではない）
以上を踏まえると、「モノレポにすると1つの大きなシステムになってしまう（＝モノリスになる）」という理解は誤解だと分かります。モノレポはあくまでソースコードの保管方法であり、システムを1つにまとめることを意味しません。
提案書で「モノレポ」という言葉を見たときに、システムの構造まで決まってしまうわけではない、と覚えておきましょう。もし「モノレポだとシステムが分割できなくなるのでは」という不安があれば、それは杞憂であり、後述する確認質問の場で開発会社に整理してもらうとよいでしょう。
モノレポのメリット・デメリットを発注者への影響で読み解く
ここからは、モノレポを選んだ場合のメリット・デメリットを見ていきます。エンジニア向けの記事では「コード共有が容易」「CIが複雑化する」といった技術用語で語られがちですが、本記事では発注者が気にする「費用」「保守」「スピード」の言葉に翻訳して解説します。記事の中でも、この章が最も判断に直結する部分です。
メリット（重複開発の削減・整合性・横断的な改修のしやすさ）
モノレポの主なメリットを、発注者への影響に置き換えると次のようになります。
- 共通部品を使い回しやすく、重複開発が減りやすい：管理画面とユーザーアプリで共通して使う部品（ログイン機能やデザインの共通パーツなど）を、1つの保管庫の中で共有できます。同じものを二重に作る無駄が減りやすく、結果として開発工数（＝費用）の抑制につながる場合があります。
- システム全体の整合性が取りやすい：すべてのソースコードが1か所にあるため、開発会社がシステム全体を見渡しやすくなります。「片方だけ仕様変更が反映されていなかった」といった食い違いが起きにくく、品質の安定につながります。実際、Googleのような巨大企業が約20億行ものソースコードを1つのリポジトリで管理しているのも、全体の見通しのよさと共通ライブラリの利用しやすさが理由とされています（Publickey「Googleが単一のリポジトリで全社のソースコードを管理している理由」）。
- 複数のサブシステムにまたがる改修をまとめて行いやすい：「全画面のデザインを一新する」といった横断的な変更を、1か所で一括して進めやすくなります。複数の保管庫を行き来する手間が減るぶん、改修のスピードが出やすい場面があります。
これらは「同じチームで関連の強い複数のサブシステムを一括開発する」ケースで特に効いてきます。
デメリット・注意点（規模拡大時のCI/ビルド負荷・権限管理・将来の分離コスト）
一方で、モノレポには注意すべき点もあります。こちらも発注者目線に翻訳します。
- 規模が大きくなると、ビルドや自動チェックの設計に負荷がかかる：保管庫が大きくなるほど、プログラムを動く形に組み立てる処理（ビルド）や、変更のたびに自動で行う品質チェックの仕組みが複雑になりがちです。これを効率化するには専用ツールの導入や設計の工夫が必要で、初期の設計費用に影響する可能性があります。
- 共通部品の変更が広く影響する：1つの保管庫にまとまっている分、共通部品を変更すると多くのサブシステムに影響が及びます（出典: Spinny.dev「モノレポ vs ポリレポ」）。影響範囲の確認に手間がかかる場合があり、テストの範囲が広がることもあります。
- アクセス権限の管理に配慮が要る：すべてのソースコードが1か所にあるため、「このサブシステムだけ別の会社に見せたい」といった部分的な権限分けが、分割している場合に比べて工夫を要することがあります。
- 将来サブシステムだけを切り出すときに手間がかかりやすい：もし将来「ユーザーアプリだけを別会社に引き継ぐ」「特定の部品だけ売却・分社化する」といった事態が想定されるなら、1つにまとまっているぶん、その部分だけを取り出す作業に追加のコストが発生しやすくなります。これは発注者にとってベンダー乗り換えのしやすさに直結する重要な観点です。
これらのデメリットは、システムの規模が大きくなったり、サブシステムごとに担当を分けたくなったりするほど顕在化しやすくなります。「いま小さくても将来どう広げる予定か」を念頭に判断することが大切です。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
自社のプロジェクトにモノレポは向いている？判断の目安
ここまでの内容を踏まえ、「では自社のプロジェクトにはどちらが向いているのか」を見極めるための目安を整理します。繰り返しになりますが、どちらが絶対正解というものではなく、プロジェクトの状況によって適切な選択は変わります。
モノレポが向いているケース
次のような状況では、モノレポのメリットが活きやすくなります。
- サブシステム同士の関連が強い：管理画面・ユーザーアプリ・APIが密接に連携し、同時に開発・更新することが多い場合。
- 共通して使う部品が多い：複数のサブシステムで同じ機能やデザインを共有したい場合。重複開発を減らせます。
- 同じチーム・同じ会社で一括開発する：1つの開発体制でシステム全体を見ながら進める場合。全体の見通しのよさが活きます。
- 当面はサブシステムを別々に切り出す予定がない：将来も一体で運用・保守していく見込みが強い場合。
ポリレポ（分割）が向いているケース
逆に、次のような状況ではポリレポ（分割）のほうが適していることが多くなります。
- サブシステムごとに担当チームや開発会社が異なる：それぞれ別の体制で開発・保守する場合、保管庫が分かれているほうが分担しやすくなります。
- リリースの周期が部品ごとに大きく違う：頻繁に更新する部品と、ほとんど変えない部品が混在している場合。
- 将来、特定の部品だけを切り出す可能性がある：分社化、事業売却、別会社への引き継ぎなどが視野に入っている場合は、最初から分けておくほうが身動きが取りやすくなります。
- サブシステムごとに独立性を強く保ちたい：一方の変更が他方に影響しないようにしたい場合。
自社のプロジェクトがどちらの傾向に近いかを当てはめてみることで、開発会社の提案に納得できるか、あるいは別の選択を相談すべきかの手がかりになります。
開発会社にモノレポ方針を確認するときの質問リスト
ここまで理解できれば、あとは開発会社と具体的に対話するだけです。提案を鵜呑みにするのでも、専門用語に気後れして黙ってしまうのでもなく、的確な質問を投げかけることで、納得して発注判断ができるようになります。打ち合わせでそのまま使える確認質問を、意図とともに挙げておきます。
- 「なぜモノレポ（または分割）を選ぶのですか？」 → 方針の根拠を確認します。明確な理由が返ってくるか、自社の状況を踏まえた説明になっているかを見ます。
- 「将来、特定のサブシステムだけを別会社に引き継ぐ場合、どのような影響がありますか？」 → ベンダー乗り換えや事業切り出しのしやすさを確認します。発注者にとって長期的に重要な観点です。
- 「この方針によって、保守費用やリリースのしやすさはどう変わりますか？」 → 運用フェーズのコストとスピードへの影響を確認します。初期費用だけでなく、長く使う前提での負担を把握します。
- 「ビルドや自動チェックの仕組みの設計に、追加の費用や期間は発生しますか？」 → モノレポで規模が大きくなる場合に生じうる設計負荷を、費用・期間の面で事前に確認します。
- 「途中でこの方針を変更することは可能ですか？その場合の手間はどのくらいですか？」 → 一度決めた方針の変更しやすさを確認します。あとから変えにくいなら、最初の判断がより重要になります。
これらの質問に対して、自社の状況を踏まえた具体的な回答が返ってくる開発会社であれば、設計の意図をきちんと持っていると判断できます。逆に説明が曖昧な場合は、もう一段踏み込んで確認するとよいでしょう。
よくある質問（FAQ）
最後に、発注者からよく寄せられる疑問をQ&A形式でまとめます。
Q. モノレポにすると開発費は高くなりますか？
A. 一概には言えません。共通部品の使い回しで重複開発が減れば費用を抑えられる場面がある一方、規模が大きくなるとビルドや自動チェックの設計に手間がかかり、初期の設計費用が増える場合もあります。自社の規模やサブシステムの数を伝えたうえで、開発会社に費用への影響を具体的に確認するのが確実です。
Q. 途中でモノレポからポリレポ（分割）に変更できますか？
A. 技術的には可能ですが、サブシステムを切り出して別々の保管庫に移す作業が必要になり、規模が大きいほど手間と費用がかかります。あとからの変更にはコストがかかるため、最初の設計段階で方針を納得しておくことが大切です。
Q. GoogleやSNSの大手はなぜモノレポを使うのですか？自社にも当てはまりますか？
A. Googleのような巨大企業は、膨大なソースコードでも全体を見渡しやすく、共通ライブラリを社内全体で活用しやすいといった理由でモノレポを採用しているとされています。ただし、これは多数の開発者が同じコードベースで協力する大規模な体制を前提とした選択です。中小規模のプロジェクトにそのまま当てはまるとは限らないため、「大手が使っているから」ではなく、自社の状況に合うかどうかで判断することをおすすめします。
Q. モノレポだとセキュリティ上のリスクはありますか？
A. すべてのソースコードが1か所にまとまるぶん、アクセス権限の管理に配慮が必要です。「このサブシステムは特定の協力会社にだけ見せたい」といった要望がある場合は、その実現方法を開発会社に確認しておくとよいでしょう。適切に権限設計をすれば、モノレポだから危険ということはありません。
まとめ
モノレポとは、複数のサブシステムのソースコードを1つのリポジトリ（保管庫）にまとめて管理する方式のことです。対になるポリレポ（分割）と比べて、全体の見通しや共通部品の使い回しに強い一方、規模拡大時のビルド負荷や、将来サブシステムだけを切り出すときの手間といった注意点もあります。
ここで改めて押さえておきたいのは、次の2点です。1つは、モノレポはあくまで「ソースコードの保管庫のまとめ方」の話であり、システムの構造を決めるモノリス／マイクロサービスとは別の選択だということ。もう1つは、どちらが絶対に正しいというものではなく、プロジェクトの状況（サブシステムの関連の強さ、担当体制、将来の切り出し予定など）によって適切な選択が変わるということです。
発注者として大切なのは、提案された方針をそのまま受け入れることでも、専門用語に気後れすることでもありません。意味を正しく理解したうえで、「なぜその方針なのか」「将来の引き継ぎや費用にどう響くのか」を開発会社に確認することです。本記事の質問リストを手元に、ぜひ自信をもって発注判断に臨んでください。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
