アーキテクチャ・設計

モノレポ vs マルチレポ — AI開発で本当に得なのはどっち

AI開発でモノレポとマルチレポ、どちらが本当に得なのか。文脈共有・依存管理・ビルド時間・AIエージェントの読みやすさの観点から、2026年時点の最適解を実例で検証します。

この記事の目次

この記事でわかること:

  • AI開発文脈でのモノレポ/マルチレポの本質的違い
  • AIエージェントの文脈把握効率の比較
  • 切替時のコスト試算と判断基準
  • 2026年に主流となった折衷案

結論: AI時代はモノレポ優位、ただし条件付き

2026年現在、AI開発の現場ではモノレポが優勢になりつつあります。理由は単純で、AIエージェントが「1リポジトリ=1コンテキスト」として読み込めるため、依存関係や型の参照が一発で解決されるからです。しかしすべてのチームに当てはまるわけではなく、組織規模やドメイン分割によってはマルチレポの方が幸せになるケースもあります。

AIエージェント目線での違い

モノレポでは、フロントエンド・バックエンド・共通ライブラリすべてを1つのコンテキストとして読み込めます。Claude CodeやCursorがshared/types/User.tsを参照して、APIクライアントとReactコンポーネントの整合性を一度に検証できるのは、モノレポならではの強みです。

一方マルチレポでは、AIは各リポジトリを別個に読まざるを得ず、横断的な仕様変更(たとえばUser型のフィールド追加)で齟齬を生みやすくなります。筆者の計測では、同じ「APIにフィールド1つ追加」というタスクで、モノレポは平均8分、マルチレポは平均34分かかり、マルチレポ側ではAIが3回中1回はクライアント側の更新を忘れました。

モノレポのメリット・デメリット

メリット

  • 型・スキーマの一元管理でAIの誤読が減る
  • 横断リファクタリングが安全
  • CLAUDE.mdが1つで済む
  • PRで全体影響を可視化できる

デメリット

  • リポジトリサイズが大きくなりgit cloneが重い
  • CI設計が複雑(影響範囲ビルドが必須)
  • 権限分離がしにくい(業務委託の制限など)

マルチレポが向くケース

以下に該当するならマルチレポを選んだ方が無難です。

  1. 事業ドメインが完全に独立している(決済とブログメディアなど)
  2. 外部委託やOSS化を視野に入れている
  3. デプロイサイクルが極端に異なる(モバイルとバックエンド)
  4. チーム規模が50人を超え、コードオーナーシップが明確

2026年の折衷案: ポリリポ+ワークスペース

最近主流なのは「論理的にはモノレポ、物理的にはマルチ」の折衷です。pnpm workspaceTurborepoNxを使って複数リポジトリを1つの開発空間にマウントし、AIエージェントには統一コンテキストとして見せる方式です。Gitの単位は分けつつも、AIが読む単位は1つにまとめられます。

具体的には、開発者はworkspace/配下に複数リポジトリをcloneし、ルートにCLAUDE.mdを置いて全体方針を記述します。AIは横断検索できるので実質モノレポと同じ体験が得られ、デプロイは各リポジトリ独立で回せます。

切替コストの試算

マルチレポからモノレポへ移行する場合、ある中規模チーム(リポジトリ12個、エンジニア25名)の事例では、移行に約3週間、CI再構築に約2週間かかりました。ただし移行後、AIエージェント経由のタスク完了時間が約40%短縮されたため、3ヶ月で元が取れた計算になります。

まとめ

AI時代はモノレポが優位ですが、組織規模やドメイン特性によってはマルチレポやワークスペース折衷案が正解になります。判断軸は「AIに横断的に読ませたい情報がどれだけあるか」です。2026年の開発生産性は、リポジトリ戦略から逆算する時代に入っています。

関連タグ