マルチリポジトリで開発する際のTips

AI Coding Meetup Aichiの登壇資料です

https://aiau.connpass.com/event/369264/

1. マルチリポジトリで開発する際のTips AI Coding Meetup Aichi 株式会社USEN-ALMEX AIエバンジェリストチーム 興野 大雅
2. 自己紹介 株式会社 USEN-ALMEX 興野 大雅 R＆D本部 開発部 バックエンド開発グループ 兼 CTO室 採用・育成センター 兼 AIエバンジェリストチーム 外部活動 AIエージェントユーザー会 (AIAU) 運営 AI駆動開発勉強会 運営 X(旧Twitter) https://x.com/taiga_kk322
3. モノレポ vs ポリレポ 〜AI時代のベストはどちらか〜
4. モノレポ モノレポ（Monorepo）とは、 複数のプロジェクトやサービスを 1つのリポジトリで管理する手法のこと 「mono（単一の）」＋「repository（リポジトリ）」の略 Webアプリプロジェクト用のディレクトリ モバイルアプリプロジェクト用のディレクトリ サーバーサイドプロジェクト用のディレクトリ など複数のプロジェクトのリポジトリを一つにまとめて扱う 例 /my-company-repo ├── backend/ ├── frontend/ ├── mobile/ ├── shared/ └── infra/
5. ポリレポ ポリレポ（Polyrepo）とは、 プロジェクトごとに独立したリポジトリを持つ開発手法のこと 「poly（複数の）」＋「repository（リポジトリ）」の略で、モノレポの対になる概念 それぞれのリポジトリが独立しており、 別のチームが管理・デプロイ・リリースが可能 例 /frontend-repo /backend-repo /mobile-repo /shared-library-repo /infrastructure-repo
6. モノレポのメリット コード共有が容易 共有のライブラリなどを複数プロジェクトで簡単に再利用可能であり、 重複の排除がしやすい 変更の一貫性 複数サービス間の依存変更を 1つのコミットで管理でき、整合性を保ちやすい リリースの同期 関連プロジェクトを同時にリリースしやすく、 複数のリポジトリ間でタグやバージョンを合わせる手間が不要 透明性と見通しの良さ リポジトリが一つのため全エンジニアが組織全体のコードを見渡せる コード検索・調査がリポジトリ 1つで完結する
7. モノレポのデメリット リポジトリの巨大化 プロジェクト数やコード量が増えると、 Git 操作（clone, fetch, log, search）が重くなる CI/CD の実行範囲も広がり、ビルド時間が長くなる アクセス制御の複雑化 1つのリポジトリに全員がアクセスするため、 「どのチームがどのコードを管理するか」の境界が曖昧になりやすい 依存関係の密結合 サービス間でコードが密接に結びつき、 1つの変更が他プロジェクトへ意図せず影響するリスクがある
8. ポリレポのメリット 独立性の高さ 各チームが自分のリポジトリを完全に管理できる 技術スタックやリリースサイクルを自由に選べる スケーラビリティ リポジトリが軽量で、Git操作・CI/CDが高速 リポジトリごとの成長に応じてスケールできる アクセス制御が容易 プロジェクト単位で閲覧権限・編集権限を明確に分けられる チームの自律性 他のサービスに影響されず、独立して開発・デプロイできる
9. ポリレポのデメリット コード共有の困難 共通ライブラリを使い回す際、バージョン管理や更新同期が煩雑 同じ処理を各リポジトリで重複実装するリスクがある 横断的変更の難しさ API仕様変更などを複数リポジトリで反映する際、 複数箇所で手動作業・プルリク対応が必要 全体把握の難しさ 組織全体のコードベースを俯瞰しづらく、 横断的なコード検索・影響調査に手間がかかる リリース同期の負荷 複数サービスを同時にリリースする場合、 それぞれでタグ付け・デプロイを行う必要がある
10. モノレポ vs ポリレポ 旧来の場合
11. ポリレポから見たモノレポ コードの共有が容易は理想論 共有は便利に見えるが、それは短期的な効率を見た場合 モノレポでは確かに共通コードを直接参照できるが、 共通化が進むほど、将来的な影響範囲が読めなくなる 共通が容易ではなく 全員が同じ鎖で繋がれてしまう構造 になりがち 全員で共有しているから便利 ではなく、 全員が巻き込まれるから不便 になっていく コードの「再利用」は簡単ではなく「再調整」が増える 共有ライブラリを複数プロジェクトで使う場合、 抽象化レベルの調整が常に必要 になる 例えば チームAの都合で関数を変更すれば、 チームBの要件に合わなくなる 共通コードを汎用化しすぎると保守が難しくなり、 特定プロジェクト向けに分岐が増える など 結果として、 共通ライブラリなのにプロジェクトごとに if 条件だらけ にな る。 コード共有のつもりが、全員の都合を聞く会議になる
12. ポリレポから見たモノレポ 「全体を見渡せる」は幻想に近い 理論上は1リポジトリにすべてのコードがあるため見渡せる とされるが、実際にはあまりにも情報量が多すぎて把握で きない 数百ディレクトリの中から目的のモジュールを探すのは困難 全体が見える は見えても理解できない 状態となって しまう 「全員が同じリポジトリを触れる」ことが問題を生む 透明性が高い反面、他チームのコードに簡単に影響を与え られてしまう レビュー文化が崩壊 しやすく、誰が何を直したのか が 不明瞭になる 共有コードへの小さな修正が、意図せず他プロジェクトを壊 す 全員で管理する構造 は、責任の分散 を生む 共有責任は、しばしば誰も責任を取らない状態 に化ける
13. じゃあ基本的には実務じゃ ポリレポが良いよね
14. モノレポ vs ポリレポ AI時代
15. AI時代の変化 コードの共有が容易は理想論 共有は便利に見えるが、それは短期的な効率を見た場合 モノレポでは確かに共通コードを直接参照できるが、 共通化が進むほど、将来的な影響範囲が読めなくなる 共通が容易ではなく 全員が同じ鎖で繋がれてしまう構造 になりがち 全員で共有しているから便利 ではなく、 全員が巻き込まれるから不便 になっていく ローカルインデックスや DeepWikiによる影響範囲解析 GitHub CopilotやCursor、Windsurfが開いた ワークスペース内の内容を自動でインデックス化 既存のコードを簡単に解析が可能に DeepWikiが活用できる環境であれば AskDevinなどを利用することで Chat形式での調査も可能 どこを直せば何に影響するか が人ではなくAIによって 即座に提示される
16. AI時代の変化 コードの「再利用」は簡単ではなく「再調整」が増える 共有ライブラリを複数プロジェクトで使う場合、 抽象化レベルの調整が常に必要 になる 例えば チームAの都合で関数を変更すれば、 チームBの要件に合わなくなる 共通コードを汎用化しすぎると保守が難しくなり、 特定プロジェクト向けに分岐が増える など 結果として、 共通ライブラリなのにプロジェクトごとに if 条件だらけ にな る。 コード共有のつもりが、全員の都合を聞く会議になる コードの「再利用」から「再構成」へ これまでの再利用＝人間による共通ライブラリ設計 今後の再利用＝AIが目的別にコード断片を再構成 共通化・汎用化を過剰に行う必要がなくなる 分岐（ifだらけのコード）が発生しても、 AIがリファクタリング 可能
17. AI時代の変化 「全体を見渡せる」は幻想に近い 理論上は1リポジトリにすべてのコードがあるため見渡せる とされるが、実際にはあまりにも情報量が多すぎて把握で きない 数百ディレクトリの中から目的のモジュールを探すのは困難 全体が見える は見えても理解できない 状態となって しまう 「全体を見渡す」ことより「 AIが要点を要約する」時代に 人間が大量のコードを読む必要はなく、 AIがタスクに合わせて複数のファイルのコードを解析して、解説を 提示できる つまり、「見渡す」ではなくAIが“要約して提示する ”が デフォルトになる
18. AI時代の変化 「全員が同じリポジトリを触れる」ことが問題を生む 透明性が高い反面、他チームのコードに簡単に影響を与え られてしまう レビュー文化が崩壊 しやすく、誰が何を直したのか が 不明瞭になる 共有コードへの小さな修正が、意図せず他プロジェクトを壊 す 全員で管理する構造 は、責任の分散 を生む 共有責任は、しばしば誰も責任を取らない状態 に化ける 「全員が同じリポジトリを触る」リスクは AIレビューで緩和 以前は「レビュー文化の崩壊」が懸念だったが、現在は code review Bugbot Codex reviews CodeRabbit などによって 変更範囲に応じた差分レビュー セキュリティ等の自動指摘 変更の自動要約 がAIで可能になった 「全員が見る必要がない」 構造にAIが変える 人手レビューの限界という前提自体が崩れつつある
19. AI時代の変化 ルールファイルによるコードの生成と管理 プロジェクト全体の他、特定のディレクトリ配下に適用するルールなどを Markdownファイル として設定が可能になった。またこのファイルをコードレビューで使用することにより品質も向上 プロンプトの共有 commitメッセージやプルリクエストの内容などを、プロンプトファイルとして定義 もしくはカスタムコマンドとして設定することでチーム前提がルールに則り メッセージを作成できるようになった gitの有効活用 AI自身が過去のcommitやプルリクの内容などを参照するようになったため、 過去との差分などが分かりやすくなった
20. AI時代はモノレポが良いのでは
21. ただ今からまたポリレポから 変えるのは現実的に難しい
22. マルチリポジトリの最適化 前提 Copilotを含め、様々なAIツールはアプリケーションの 全体像を把握しているときに最も効果的に機能する そのため、インデックスを構築し AIを動かすのがCopilot活用の第一歩となる CopilotやCursorの場合、このように フォルダーをワークスペースに追加 ...(Add Folder to Workspace…) を使用することで複数のリポジトリを一つのワークスペースとして 活用でき、インデックスも作成される ↑ マルチルートワークスペースという ワークスペースの詳細はこちら https://github.com/orgs/community/discussions/175497
23. インデックスの作成 GitHub Copilotはインデックス可能なファイルが 750ファイル未満の場合 高精度なローカルインデックスを作成する インデックスは一般的なコードをはじめ、 mdファイルや設定、ドキュメントなどほとんどの プログラミングファイルおよびテキストベース形式のファイルを認識する この際、インデックスに含めたくない情報は .gitignore,files.exclude settings,search.exclude settingsで設定が可能 ※最大2500ファイルまで対応 ※Cursorの場合は.cursorignoreファイルを活用
24. ドキュメントの生成 開発内で整合性が取れなくなる代表的なものとしてあげられるドキュメント 特に /frontend-repo /backend-repo /mobile-repo /shared-library-repo /infrastructure-repo /docs のように、プロジェクトに関連する docsディレクトリを用意し Hugoなどの静的サイトジェネレーターで管理 社内からのみアクセスできるサーバーにアップロードしているといった運用の場合 mainにマージして単体テストも結合テストも問題がなくリリースされた後に書くことが多いため 開発者自身も忘れて徐々に整合性が取れなくなってしまう
25. 解決策１ CodeRabbit Proの使用 CodeRabbit Proプランの機能の一つにカスタマイズ可能なレポートがある これを使用することであらかじめ設定したプロンプトで 自動で定期的にレポートを生成させ通知させることができる これにより１週間に１度などの頻度で mainにマージされたコードに対するリリースノートが自動で SlackやDiscord、TeamsやEmailに届くようになる 後はそれに沿ってDocsディレクトリの更新を行えば良い
26. 解決策2 非同期AIエージェントの活用 docsリポジトリ 非同期型 AIエージェント frontend-repo backend-repo mobile-repo プルリク作成
27. GitHub Actions 解決策2＿応用 非同期AIエージェントの活用 docsリポジトリ 非同期型 AIエージェント frontend-repo backend-repo mobile-repo プルリク作成 ユビキタス言語辞書MCP等 GitHub MCP
28. まとめ モノレポ vs ポリレポ問題については、現状は AIに与えられるコンテキストの観点からも モノレポが良い可能性が高い 小中規模のプロジェクトの場合、まずはモノレポで開発を行い 必要があれば後から変更する方が良い またマルチワークスペースで実装を行う必要がある場合は Add Folder to Workspace…でワークスペースを追加し インデックスの作成をおすすめする ドキュメントについては、後からの更新になることが多いため 後から見返せるようなドキュメント生成の自動化フローを組むと良い
29. Thank you