「このライブラリに脆弱性が出たので、使っている全システムを更新してほしい」——受託で複数のシステムを預かっていると、こうした依頼への対応が、年々重くなっていきます。理由は単純で、システムごとにリポジトリが分かれ、同じライブラリでもバージョンがバラバラだからです。あるリポジトリは最新版、別のリポジトリは二年前の版、さらに別のは「誰も覚えていない古い版」。脆弱性が出たとき、まず「どこに、どの版が残っているか」を棚卸しするところから始めねばならず、更新そのものより調査に時間がかかる。リポジトリが案件のたびに増えていくほど、この「依存のズレ（dependency drift）」が静かに広がり、横断的な対応のコストを押し上げていきます。
この問題に正面から取り組んだ事例として、InfoQ が 2026 年 6 月に報じた Block 450 JVM Repositories Into Monorepo（InfoQ） があります。Block 社は 450 もの JVM リポジトリを一つのモノレポへ統合し、依存のズレを減らす取り組みを進めました。規模こそ大きいですが、その背景にある「分散したリポジトリが依存のズレを生む」という構図は、受託で複数システムを抱える現場とまったく同じです。本記事では、モノレポ化という選択肢を、受託の文脈でどう判断し、どう進めるかを整理します。
なぜ「リポジトリが増える」と依存がズレるのか
リポジトリを案件ごと・システムごとに分ける運用は、最初は理にかなっています。それぞれが独立して動き、ある案件の変更が別の案件に影響しない。問題は、時間が経つにつれて次のことが起きるからです。
第一に、同じ依存が各リポジトリに別々に書かれる。リポジトリ A も B も同じ JSON ライブラリを使うとして、それぞれの設定ファイルにバージョンが独立して書かれます。A だけ更新して B を忘れれば、その時点でズレが生まれる。更新の判断が各リポジトリ任せになり、足並みが揃いません。
第二に、全体像を見る場所がどこにもない。「このライブラリを使っているのはどのシステムか」を知るには、全リポジトリを一つずつ開いて確認するしかない。リポジトリが数十・数百になると、この棚卸し自体が現実的でなくなります。
第三に、共有コードが複製される。複数システムで使う共通処理を、リポジトリをまたいで共有しづらいため、コピーして持つことになりがちです。すると、共通処理にバグが見つかったとき、コピーされた全箇所を探して直す羽目になります。
依存の所在が分からなくなる構図は、サービス間の繋がりが見えなくなる問題と地続きです。システム全体の依存関係を可視化する考え方は、サービス依存関係の可視化の記事で扱ったとおりで、モノレポ化はその可視化を「一つのリポジトリに集める」という形で実現する一手です。
モノレポで何が変わるのか — 「一つの真実」を持つ
モノレポ（monorepo）は、複数のプロジェクトを一つのリポジトリで管理する方式です。誤解されがちですが、これは「全部を一つの巨大なアプリにまとめる」ことではありません。各プロジェクトは独立したまま、置き場所だけを一つにする。その上で、依存のバージョンを一か所で揃えられるようにします。
monorepo/
├── apps/
│ ├── customer-site/ # 顧客Aのサイト（独立して動く）
│ └── admin-tool/ # 顧客Bの管理ツール（独立して動く）
├── packages/
│ └── shared-ui/ # 共通の部品（コピーせず参照する）
└── 依存バージョンの定義 # ライブラリの版を一か所で管理この構成にすると、依存をめぐる三つの問題が裏返ります。
| 観点 | 分散リポジトリ | モノレポ |
|---|---|---|
| 依存バージョン | リポジトリごとにバラバラ | 一か所で統一できる |
| 「どこで使っているか」 | 全リポジトリを横断調査 | 一つのリポジトリ内を検索 |
| 共通コード | コピーして複製 | 一つを参照して共有 |
| 脆弱性対応 | どこに古い版があるか不明 | 一か所直せば全体に反映 |
脆弱性が出たときの動きが、決定的に変わります。分散していれば「どこに古い版が残っているか」の調査から始まりますが、モノレポなら依存定義を一か所更新し、影響範囲をその場で検索できる。受託で「使っている全システムを更新して」という依頼に、棚卸しなしで応えられるようになります。
受託で導入するときの落とし穴
弊社が運用を引き継いだある企業グループのシステム群（社名は伏せます）は、グループ各社向けに作られた十数個のリポジトリに分かれていて、共通の認証処理が各リポジトリにコピーされていました。あるとき認証処理に不具合が見つかり、修正したものの、どのリポジトリに同じコードが複製されているかの一覧がなく、結局すべてのリポジトリを開いて確認する作業に丸二日かかりました。
私たちは、まず「共通処理のコピー」を一つの共有パッケージに集約し、各システムがそれを参照する形へ段階的に寄せました。全リポジトリを一気にモノレポへ移すのではなく、新規に作る部分と、改修で触る部分から順に共有パッケージへ移行する方針です。依存バージョンの定義も、移したものから一か所に集めていきました。結果、次に共通処理を直したときは、一か所を直すだけで参照側すべてに反映され、二日かかっていた横断確認が消えました。
この移行で一番効いた学びは、モノレポ化は「一度に全部」をやらないことでした。450 リポジトリを統合した Block のような大規模事例は華々しく見えますが、受託の現場で同じことを一括でやろうとすると、移行中にすべてのシステムを止めかねません。共通処理の集約から始め、効果を確認しながら範囲を広げるのが安全です。なぜその構成を選んだかを記録に残しておくと、後の判断もぶれません。設計判断の記録については、ADR（設計決定記録）の記事で扱った手法が役立ちます。
もう一つの落とし穴は、モノレポにすると、こんどはビルドや CI が重くなりがちなことです。すべてが一つのリポジトリに入ると、一か所の変更で全体をビルド・テストしようとして時間がかかる。「変更があった部分だけをビルド・テストする」仕組みを最初から入れておかないと、統合した代償に開発の回転が落ちます。リポジトリの構成と同じく、CI やインフラ設定も一か所で標準化しておく考え方は、CDK/Terraform でIaCを標準化する記事で扱った方針と組み合わせると効果的です。
どこから着手するか
リポジトリが案件ごとに増え、同じライブラリの版がバラバラで、脆弱性対応のたびに棚卸しから始めているなら、依存を一か所に集める価値があります。ただし、いきなり全リポジトリの統合を目指す必要はありません。
最初の一歩としては、複数システムにコピーされている「共通処理」を一つ選び、共有パッケージに切り出して各システムから参照させること。そして、その共有部分の依存バージョンを一か所で管理するところから始めます。これだけで「直したのに一部に反映されていない」事故が一つ減り、横断的な依存の把握も少し楽になります。効果を確かめてから、範囲を段階的に広げれば、移行のリスクを小さく保てます。
リポジトリが増えすぎて依存の全体像が見えない、脆弱性対応のたびに棚卸しで疲弊している、共通処理のコピーが各所に散らばっている——そうしたお悩みがあれば、グリームハブのお問い合わせからご相談ください。現行のリポジトリ構成と依存関係を拝見し、依存のズレを断つための集約を、システムを止めずに段階的に進める設計をご一緒に組みます。
