自社でサービスを2つ、3つと増やしていくと、多くの開発チームが同じ分岐に突き当たります。「サービスごとにリポジトリを分けるか、1つにまとめるか」——。私たちは複数の自社プロダクト（TechMate・ExcelMate ほか）を、1つのリポジトリ（モノレポ）にまとめて運営しています。

ただし、一般的なモノレポの作り方とは少し違う選び方をしています。この記事では、なぜ1リポジトリにまとめたのか、なぜ定番の workspaces をあえて使わなかったのか、共通と個別をどう線引きしたのか、そして運用してみて何が代償になったのかを、開発体制づくりを検討している方の判断材料として整理します。技術の細部よりも、**「どう判断したか」**に軸を置いて書きます。

筆者（馬込）は、少人数で複数の自社サービスを開発・運用してきました。その中で痛感したのは、モノレポの正解が「まとめるか・分けるか」の二択ではなく、**「何を共有したいのか」**の見極めで決まるということです。ここを取り違えると、まとめても分けても後で苦しくなります。

なぜ複数サービスを1リポジトリにまとめたか

サービスが1つのうちは、この悩みは起きません。問題になるのは2つ目、3つ目を立ち上げるときです。

それぞれを完全に別プロジェクトとして作ると、デザインの作法も、検索対策（SEO）の実装も、アクセス計測の配線も、毎回ゼロから作り直すことになります。似たものを二度三度と作り直すのは、少人数で複数サービスを回す事業にとって、じわじわ効いてくる無駄です。人手が限られるほど、この「作り直しコスト」は重くのしかかります。

1リポジトリにまとめる最大の動機は、この繰り返しを止めることでした。一度作り込んだ仕組みを、次のサービスへ低コストで持っていける状態にしたい。作るのは1回、使うのは何度でも、という状態に近づけたかったのです。効果が出るのは常に「2つ目から」で、1つ目のときにはまだ見えません。そこを信じて先に投資できるかが、地味な分かれ目でした。

一般的なモノレポ（workspaces）をあえて採らなかった判断

「モノレポにする」と決めたあと、次の分岐が来ます。定番は pnpm や npm の workspaces で依存を束ね、共通ライブラリを巻き上げる作り方です。私たちはこれをあえて採りませんでした。

理由は、まとめることのもう一つの顔——「1か所を触ると全部に響く」という巻き込みリスクです。workspaces は依存を共有するぶん、共通依存の更新が全アプリに波及しえます。トレードオフを整理すると、判断の軸が見えてきます。

観点 workspacesで束ねる アプリごとに独立（今回）
依存の重複 少ない（巻き上げ） 多い（各アプリで重複）
巻き込み事故 起きうる 起きにくい（影響がアプリ内で閉じる）
ビルドの独立性 設定が要る そのまま独立
共有する対象 コード・依存 作法・設計（コードはコピーでよい）

決め手は最後の行でした。私たちが共有したかったのは、**ライブラリとしてのコードではなく「作法」**だったのです。各アプリは「たまたま同じリポジトリにいる独立したプロジェクト」で、それぞれが自前の依存を持ち、独立してビルド・デプロイされます。

デプロイ基盤（AWS Amplify）側では、amplify.yml の applications[] に appRoot ごとのビルド定義を並べる形で実現しています。

version: 1
applications:
  - appRoot: apps/dev-partner   # TechMate
    frontend:
      phases:
        build:
          commands:
            - npm run build
      artifacts:
        baseDirectory: .next
  - appRoot: apps/excel-mate    # ExcelMate（別アプリとして独立）
    frontend:
      # ...同様にアプリ単位で定義

baseDirectory やキャッシュは appRoot 相対で解決されるため、各アプリのビルドは互いに干渉しません。「ビルドが独立している」とは、この粒度の話です。

「共有するのはコードではなく作法」という線引き

この判断の核心が、共有する対象の見極めです。ここを言語化しておくと、他の設計にも応用が効きます。

私たちが次のサービスへ持っていきたかったのは、たとえば次のようなものでした。

  • 構造化データ（JSON-LD）の入れ方
  • アクセス計測の配線のしかた
  • Markdown ベースの記事システムの作り方

これらはいずれも、「確立したやり方を次のアプリへ持っていく」形で足りるものです。パッケージとして共有し、バージョンを合わせ、更新を全アプリに波及させる——そこまでの仕組みは要りませんでした。むしろ、その仕組みを持つと巻き込みリスクだけが増えます。こうした共通の作法の上に載せた各メディアの回遊導線をどう設計したかは、メディアの導線を構造から作り直した記録で別途整理しています。

共有したい対象がコード（ライブラリ）なのか、作法（設計の型）なのか。 ここでモノレポの正解は変わります。コードを共有したいなら workspaces の巻き上げが効きますが、作法だけを共有したいなら、その恩恵は薄く、独立構成のほうが素直です。「まとめるか分けるか」より一段深いこの問いに答えることが、実際の設計判断でした。

運用して分かった代償——独立構成のコスト

良かったことばかり書くと嘘になるので、つまずいた側も正直に書きます。独立構成には確かな代償がありました。

① パッケージマネージャが混在した。 歴史的な経緯で、ルートは pnpm、後から足したアプリ群は npm という混在状態が生まれました。workspaces で束ねていれば自ずと1つに統一されますが、独立構成は「統一しなくても動いてしまう」。動きはしますが、新しく入った人が「このアプリはどっち？」と一瞬迷い、手順がアプリごとに違うという分かりにくさが残ります。独立させたかったのは「依存とビルド」であって「手順」ではなかった、というのが後知恵の反省です。

② 依存が重複する。 同じ Next.js が複数アプリぶん入ります。ディスクと install 時間は workspaces なら避けられたコストです。ただ私たちの規模では、その重複より独立性のほうが価値が高いという判断でした。あるアプリの依存を上げても他アプリのビルドは無関係、という安心のほうが効いたのです。

代償を並べて分かるのは、独立構成は「まとめる怖さ」を避ける代わりに、別種の地味なコストを引き受ける選択だということです。どちらのコストを取るかが判断の本体でした。

どんな体制に向き、どこは向かないか

この「1リポジトリにまとめる・ただし独立させる」構成は、どの会社にも最適というわけではありません。向き不向きがあります。

  • 向いている：複数のサービスやLPを持ち、デザイン・集客・計測の作法を共有したい。少人数で効率よく回したい。今後もサービスを増やす見通しがある。
  • 急がなくてよい：サービスが1つだけ。あるいは各サービスの中身がまったくの別物で、共有できる作法がほとんどない。この場合、無理にまとめる利点は小さくなります。

分かれ目は、結局のところ**「使い回せる共通の作法が、自社にどれだけあるか」**です。共有できるものが多いほど、まとめる効果は大きい。逆に少なければ、別々のままの身軽さを優先していい。私たちの場合は「集客と計測の作法を共有したい」事情がはっきりしていたので、この構成がはまりました。開発体制そのものの見直しは「開発を内製化する進め方」も参考になります。

TechMateの開発体制づくり支援

私たちTechMateは、こうした自社プロダクトの開発体制づくりを、月単位の準委任で伴走しています。構成の判断・設計・実装まで手を動かして並走し、社内に判断が残る進め方を前提にしています。開発体制やアーキテクチャの相談はこちらからどうぞ。

よくある質問

Q. 最初は別リポジトリで作り、あとから1つに統合することはできますか？ A. 技術的には可能ですが、統合は想像以上に手間がかかります。おすすめは「最初から共通の作法を1箇所に置く」と決めておくことです。逆に、いい加減にまとめてしまったものを後から“ほどく”のも大変です。まとめること自体より、まとめ方の設計に先に手をかけるほうが、後がラクになります。

Q. モノレポにすると、片方のサービスの不具合が全体に波及しませんか？ A. まさにそれを避けるために、私たちは依存とビルドを独立させました。共通で使う部分（作法）と、サービス固有の部分（中身）をはっきり分けて持てば、共通の改善は一度で全体に効き、個別の変更はそのサービス内で閉じます。波及の多くは、この「共通と個別の線引き」が曖昧なまま一緒くたにすることから起きます。

Q. 少人数でもモノレポ運用は回りますか？ A. むしろ少人数だからこそ効きます。作り直しコストを減らせる恩恵が、人手の限られたチームで大きくなるためです。ただし前述のとおり、パッケージマネージャや手順は意識的に揃えておくのが、少人数運用では特に効いてきます。

複数プロダクトを1リポジトリで運営するかどうかは、「まとめるか分けるか」の好みではなく、**「何を共有したいのか」**の見極めで決まります。共有したいのがコードなら workspaces、作法だけなら独立構成。そして、独立を選ぶなら手順まで独立させないよう気をつける——このあたりが、実際に運用して腹落ちした勘所でした。

自社の複数サービスをどう構成すべきか迷う段階でも構いません。開発体制のご相談から、お気軽にお問い合わせください。