青〜紫の光のストリームが一点に収束し、背景にノードと線で構成されたネットワークが広がる、抽象的でアンビエントなデジタルイメージ

kickflow プロダクト開発本部の小本です。

GoogleなどのIT企業が複数のプロジェクトを単一のリポジトリで管理するモノレポを採用していることは以前から知られています。

20億行のコードを保存し、毎日4万5000回のコミットを発行しているGoogleが、単一のリポジトリで全社のソースコードを管理している理由－ Publickey https://www.publickey1.jp/blog/15/2045000google.html

私たちkickflowでも最近リポジトリを統合する「モノレポ化」を実施しました。その結果、AI時代にはモノレポがさらに有効になると感じています。

kickflowでのモノレポ化の実践
従来のモノレポの利点
AI時代のモノレポの利点
モノレポ化の課題感と解決策
まとめ
- We are hiring!

kickflowでのモノレポ化の実践

kickflowでは以下の2つのリポジトリを統合する作業を行いました。両者はソースコードの内容もデプロイするPaaSも異なり共通性は低いのですが、1つのレポジトリに統合する判断をしました。

メインリポジトリ kickflow：kickflow本体。Ruby on Rails + Nuxt.jsで実装し、Heroku上で動作
サブリポジトリ kickflow-teams：Microsoft Teams連携機能のマイクロサービス。TypeScript・Expressで実装し、Firebase上で動作

具体的には以下の作業を行いました。

kickflowリポジトリに teams/ ディレクトリを作成し、kickflow-teamsのソースコードから必要なものをコピーしてコミット
kickflow-teams側で定義していたGitHub Actions等をkickflowリポジトリに再定義
kickflowリポジトリのAI向けの指示（CLAUDE.mdなど）に teams/ ディレクトリの説明を追加
ESLintの設定などがkickflowと teams/ で異なっていたため修正

従来のモノレポの利点

ソフトウェア開発は「ソフトウェアの構造はそれを開発する組織の構造に似る」というコンウェイの法則に支配されています*1。

レポジトリ戦略についても、開発チームが１つであればモノレポにするのが自然であり、開発チームが分かれておりデプロイ頻度やソースコードの管理権限が異なるならリポジトリを分けるべきとするのが通説です。kickflowでレポジトリを統合したのも１チームで開発しているためです。

またモノレポ化することにより「1回のプルリクエストで複数のコンポーネントの変更を行える」ようになり開発がスムーズになるメリットがあるとされています。

AI時代のモノレポの利点

しかし、実際にモノレポ化してみるとAI開発におけるモノレポを採用する新たなインセンティブが生じていることを実感しました。

今のAIエージェントはコンテキスウィンドウが十分に大きいため、モノレポ化するとAIエージェントが全てのコンポーネントのコードを同時にコンテキストに載せられるようになります。

つまり、単に「1回のプルリクエストで複数のコンポーネントの変更を行える」だけでなく、

「AIエージェントが1回のプロンプトで複数のコンポーネントの変更を生成する」
「AIエージェントが1回のコードレビューで全てのコンポーネントを見渡して整合性を確認する」

といった事も可能になるためAIによる開発速度アップを倍化できるのです。

なお、単純なメリットとしては、AIエージェントの設定をレポジトリごとにする必要が無くなるというメリットがあります。

モノレポ化の課題感と解決策

「モノレポ化」で最初にどこまでやるべきか？

モノレポ化する際には、以下のような共通化を考えがちです。

全サブプロジェクトで同じコーディング規約を使うよう eslint.config.js を共通化しよう
pnpmでパッケージを共通管理しよう

これらは確かに良いことですし、kickflowでも最終的にはそうしています。

しかし、実際にやってみると「単一のGitリポジトリにディレクトリを切ってサブプロジェクトのコードをコミットする」段階で、すでに「全コードがコンテキストに載る」の利点を享受できました。

つまり、「共通化」を最初の段階で頑張りすぎなくても良いということです。また、「共通化」は機械的な作業なので、AIエージェントに任せることも可能です。

Gitの履歴問題

単純にソースコードをコピーする方法ではサブリポジトリ側のGit履歴が引き継がれません。

kickflowではサブリポジトリの歴史が浅く、コード規模も小さかったため、履歴を維持する必要性は低いと判断しました。そのため、Git履歴は無視して単純なファイルコピーを選択しました。仮に過去の履歴を調査する必要が生じた場合も、元のリポジトリをアーカイブしているので、それを参照すれば問題ありません。

なお、Gitの機能としては履歴を引き継いだままリポジトリを統合することも可能です。詳しくは以下のドキュメントを参照してください。

git-scm.com

ソースコードの巨大化

モノレポ化に際して一般に挙げられる懸念として「ソースコードが巨大化してチェックアウトに時間がかかるのではないか？」とするものがあります。kickflowの規模ではこの問題は起きていません。

一方、CLAUDE.mdが巨大化する問題はあります。CLAUDE.mdはClaude AIエージェント向けにプロジェクト固有の文脈（ルール、設計、規約など）を説明するファイルです。CLAUDE.mdのサイズが倍になってもAIエージェントには問題ないでしょうが、人間がCLAUDE.mdを直接読み書きするのは大変になります。これは.claude/rules/ を使ってファイルを分割するなどして対処すればよいでしょう。