モノレポ × モノリスという選択 ― 目的・歴史・企業規模から逆算する個人開発の構造

はじめに

個人開発で進めている beatSinkCentral では、リポジトリ構造としてモノレポ、アプリケーション構成としてモノリス（厳密にはモジュラーモノリス）を採用している。

技術選定の場面で「最新だから」「大手がやっているから」を根拠に置くと、ほぼ確実に過剰設計か運用破綻のどちらかに行き着く。何のためにその構造を選ぶのか（目的）、なぜ今その選択肢が主流に見えるのか（歴史的背景）、それを採用するとどんな難しさが発生するのか（マイクロサービスのコスト）、自分の状況（企業規模・個人）にとってそれは適切か ── ここを順に整理しないと、選んだ構造に後から振り回される。

この記事では、その変数を一つずつ並べたうえで、「個人開発である自分にとってはモノレポ × モノリスが基本的に正しい」という結論に至った思考の道筋を残す。

記事のスコープ。 技術選定の「正解」を語るためのものではなく、「制約から逆算した選択」の記録だ。組織規模が変わればこの答えは変わる、という前提で読んでほしい。

---

達成したい目的を先に置く

選定の話に入る前に、自分が何を達成したいのかを明示しておく。これがないと、議論が「どの構造がカッコいいか」に流れる。

目的	達成できないと何が起きるか
1人で開発・運用を回せる	運用破綻でプロダクトが止まる
共通する型・ドメインを安全に共有したい	フロントとサーバーの型がズレてバグの温床になる
横断的な変更を1コミットで届けたい	APIの変更とフロントの追従が別PRになり、整合が壊れる
将来の切り出し（マイクロサービス化）を残す	成長したときに全部書き直しになる
デプロイ・運用をできるだけ単純にしたい	個人開発の体力で複数サービスを24/365監視できない

これらの目的が先にあって、そこから「どの構造ならこの目的を最小コストで満たせるか」を問う。順序を逆にして「モノレポを採用したい、なぜなら…」と理由を後付けすると、何が成立条件かを言語化できないまま設計が進む。

---

歴史的背景：なぜマイクロサービスが「主流」に見えるのか

技術選定で迷うときは、その選択肢がなぜ生まれたかを見ると判断しやすい。アーキテクチャの歴史をざっくり辿ると、流れはこうなる。

時代	主流のアーキテクチャ	なぜそれが必要だったか
〜2000年代前半	モノリス（巨大な1アプリ）	サーバー台数も少なく、デプロイ単位を分ける必然がなかった
2000年代後半〜	SOA / Web API 分離	異なるシステムを連携させる必要が出てきた
2010年代	マイクロサービス	クラウド普及で大規模スケール・組織並行開発が現実的になった
2020年代前半	モジュラーモノリス回帰	マイクロサービスの隠れたコストが顕在化し、揺り戻しが起きている

注目すべきは、マイクロサービスが流行ったのは特定の組織課題を解くためだったという点だ。数千人〜数万人規模の組織で、複数チームが同じコードベースを触ると衝突が頻発する。その問題を解くために、サービスを物理的に分割してチームの責任境界を作ったのがマイクロサービスの本来の動機だ。

つまりマイクロサービスは「コードの問題」を解いた技術ではなく、「組織の問題」を解いた技術と捉えるのが正確だ。

揺り戻しが起きている

ここ数年、その流れには揺り戻しが起きている。マイクロサービスから一部をモノリスに戻したり、最初から「モジュラーモノリス」として意図的に1アプリで設計する流れが出てきている。背景にあるのは、運用コスト・分散システムの複雑性・チーム間の契約管理コストといった、マイクロサービスの隠れた負債が顕在化したことだ。

ここから読み取れる重要な示唆はこうだ。マイクロサービスは万能解ではなく、特定の規模・特定のドメインに対しての処方箋でしかない。流行の表層だけを真似て採用すると、組織の実態に対してオーバースペックになり、コストだけが先に来る。

---

マイクロサービスの難しさを直視する

「最新だから」で選ぶと見えなくなる、マイクロサービスの隠れたコストを並べる。

表に見えるメリット	隠れているコスト
サービス単位で独立デプロイ	ネットワーク越し通信のレイテンシ・失敗ハンドリング
技術スタックを自由に選べる	各サービスの技術を運用できる人材が常に必要
チームごとに独立して動ける	サービス間の契約（API・イベント）の管理が膨大
スケーリング単位を細かくできる	分散トランザクション・整合性の問題
障害をサービス単位に閉じ込める	複数サービスを跨ぐデバッグ・トレースの難しさ
共通の責任境界が作れる	共通ライブラリのバージョン管理がポリレポだと地獄になる

これは「マイクロサービスが悪い」という話ではなく、これらのコストを払える組織体力があるかを問う話だ。コストを払える条件は概ね次のようなものだ。

• 専任の SRE / プラットフォームチームがいる
• サービスごとに責任を持つ開発チームが分かれている
• 監視・ロギング・分散トレースの基盤が整備されている
• リリース・ロールバックの自動化が成熟している

これらが揃っていない段階でマイクロサービスを選ぶと、メリットを享受する前にコストだけが先に来る。マイクロサービスを選ぶ条件を満たしているか ── これが選定で最初に問うべき変数だ。

---

企業規模という変数

組織の規模は、アーキテクチャ選定にとって最も大きな変数の一つだ。Conway の法則（システムは組織のコミュニケーション構造を反映する）の通り、組織と構造を切り離すと破綻する。

組織規模	適したアプリケーション構成	理由
個人（1人）	モノリス	サービス分割の利点がない、運用負荷を最小化する必要
小規模（〜10人）	モノリス / モジュラーモノリス	チーム境界がまだ存在しない、分割は早すぎる
中規模（10〜50人）	モジュラーモノリス	チーム境界が見え始めるが、運用基盤が追いつかない
中堅（50〜数百人）	モジュラーモノリス → 部分的に分割	ドメインごとにチームが分かれ、ボトルネックから順に切り出していく
大企業（数千人〜）	マイクロサービス	並行開発・独立デプロイの必然性が出る、運用基盤も自前で持てる

日本の開発組織の多くは10〜50人規模で、サービスを並行開発するほどの組織規模に達していないケースが多い。組織が小さいのにサービスを細かく分けると、誰も全体を把握できなくなる。

そして個人開発（1人）の場合、答えはほぼ自動的に決まる。モノリス一択だ。マイクロサービスのメリットは「組織問題の解決」であり、組織問題が存在しない1人開発では、コストだけが残る。

---

モノレポとモノリスは独立した軸

ここで誤解されやすい点を整理する。「モノレポ」と「モノリス」は字面が似ているが別の軸だ。

軸	選択肢	何を決めているか
リポジトリの分け方	モノレポ / ポリレポ	コードをどこに置くか
アプリケーションの構成	モノリス / マイクロサービス	デプロイ単位をどう分けるか

軸が独立しているので組み合わせは4通りある。

組み合わせ	説明
モノレポ × モノリス	1リポジトリに1つの大きなアプリ
モノレポ × マイクロサービス	1リポジトリに多数のサービス、共通資産は同じツリーで管理
ポリレポ × モノリス	あまり見ない構成
ポリレポ × マイクロサービス	サービスごとにリポジトリを分ける、共通資産の管理コストが高い

ポイントは、マイクロサービスを選ばないからといって、モノレポを選ばない理由にはならないということだ。モノレポの利点（型・依存・横断変更の管理）は、モノリスでもそのまま効く。

---

個人開発が満たすべき条件にモノレポ × モノリスを当てる

最初に挙げた目的に対して、モノレポ × モノリスがどう機能するかを照合する。

目的	モノレポ × モノリスでの解き方
1人で開発・運用を回せる	デプロイ対象は1サーバー＋Nクライアント、運用がシンプル
共通する型・ドメインを安全に共有したい	packages/ で型・ドメインを共有、import で参照するだけ
横断的な変更を1コミットで届けたい	API・フロント・型を同一PRで変更・レビューできる
将来の切り出しを残す	モジュール境界を守れば、特定機能を後から切り出せる
デプロイ・運用をできるだけ単純にしたい	サーバー1プロセス、ネットワーク越し通信なし

すべての目的に対して、最も低コストで満たせるのがこの構造だ。逆に言えば、「将来マイクロサービスにするかもしれない」という曖昧な想定で最初からマイクロサービスを選ぶのは、コストの先払いでしかない。

---

beatSinkCentral の実構造

これらの判断をふまえて、beatSinkCentral は次のような構成になっている。

beatSinkCentral/
├── apps/
│   ├── api-server/       # サーバーサイド（1アプリ・1デプロイ）
│   └── beatfolio/        # エンドユーザー向けクライアント
├── packages/
│   ├── data/             # 共通データ定義
│   ├── database/         # DB スキーマ・マイグレーション
│   └── ui/               # 共通UIコンポーネント
├── turbo.json            # Turborepo によるタスク・依存管理
└── package.json

構造上の要点をいくつか書き留めておく。

1. サーバーサイドは1つのアプリケーション（＝モノリス）

apps/api-server は単一プロセス・単一デプロイで動く。マイクロサービスではない。内部でドメインごとにモジュール分割しているので、将来サービスを切り出す余地は残してある（モジュラーモノリス）。

2. クライアントは独立したアプリケーション

apps/beatfolio は Next.js のエンドユーザー向けアプリ。サーバーサイドとは別にビルド・デプロイされる。「クライアントが複数あっても、サーバーが1つなら全体としてはモノリス」という整理になる。

「マイクロサービス」を名乗るには、サーバーサイドが独立してデプロイ可能な複数のサービスに分かれている必要がある。クライアント側がいくつあっても、それはマイクロサービスとは関係ない。

3. 共有資産は packages/ に集約

• packages/data：ドメインの型・データ定義
• packages/database：DB スキーマ、マイグレーション
• packages/ui：共通の UI コンポーネント

これらを apps/api-server と apps/beatfolio の両方から import する。型の同期・UIの一貫性・スキーマの一元管理がここで担保される。ポリレポでは npm publish や git submodule が必要になるところを、モノレポなら import 文だけで済む。

4. Turborepo によるタスク・依存管理

turbo.json で各パッケージ・アプリのビルド依存とキャッシュを管理している。packages/database のスキーマが変わったら、それを参照する apps/api-server のビルドが自動でトリガされる、という関係を宣言的に書ける。

---

この意思決定の言語化

最後に、この選択をなぜ行ったかを自分の言葉で残す。技術選定は「何を選んだか」より「なぜそれを選んだか」の方が重要で、それが残っていないと、半年後の自分も他の開発者も判断を継承できない。

達成したかったこと

• 個人の体力で開発・運用を回し続ける
• フロントとサーバーで共通する型・ドメインを安全に共有する
• 機能の切り出し・付け替えが将来できる余地を残す

採用しなかった選択肢と、その理由

選択肢	採用しなかった理由
ポリレポ × モノリス	共通の型・ドメインの同期コストが大きい、横断変更が複数PRに分散する
ポリレポ × マイクロサービス	個人の運用体力では絶対に支えられない、組織問題が存在しないので利点がない
モノレポ × マイクロサービス	個人開発でサービス分割の必然性がない、運用負荷だけ増える

採用した選択肢

モノレポ × モノリス（モジュラーモノリス）。

• 共通資産は packages/ で1ヶ所に集約
• サーバーサイドは1プロセスでシンプルに運用
• 内部でドメインごとにモジュール分割し、将来の切り出し余地を残す

認識しているリスクと向き合い方

• モジュール境界の崩壊：モノリスは全部参照できるので、依存方向の規律を意識的に守る必要がある。packages/ の依存方向を明示し、api-server の内部もドメインごとにディレクトリを分けることで対処する
• デプロイ単位の粗さ：サーバーの一部だけ更新できない。個人開発の段階では問題にならないと判断
• 将来の切り出しコスト：モジュール境界が緩いと切り出しが大変になる。最初から境界を意識して書くことで予防する

---

まとめ

技術選定で大事なのは、流行や規模感の大きい事例ではなく、自分の目的と制約から逆算することだ。

• 目的から始める（何を達成したいか）
• 歴史的背景を踏まえる（その選択肢が生まれた動機を理解する）
• マイクロサービスの難しさを直視する（隠れたコストを払える体力があるか）
• 企業規模という変数を当てる（組織と構造は分離できない）

これらの変数を整理した結果、個人開発の自分にとってはモノレポ × モノリスが基本的に正しい、という結論になった。

適切な選択は組織の状態とドメインの成熟度によって変わる。今のこの選択が「正しかった」かどうかは、プロダクトが育ったときの自分が、その時の制約に照らして判断すればいい。

それまでは、この構造で動かせるところまで動かす。設計の判断は、その時点で最善を尽くせばよく、未来の不確実性に対して保険を払いすぎる必要はない。

---

参考

• 個人プロダクトのモノレポプロジェクト全体像について
• BEAT:SINK CENTRAL のフロント設計について
• beatSinkCentral リポジトリ