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