この記事は、CYBOZU SUMMER BLOG FES '26の記事です。

kintoneのダッシュボード開発をしている uta8a です。複数のリポジトリを参照・編集するチーム開発で、Claude CodeのようなAI Agentツールを素朴に活用していると、以下のようなことが気になってきます。

複数のリポジトリをVS Codeで開いたり、 cd コマンドで移動して、それぞれで claude を打つのが面倒
複数のリポジトリを跨ぐ調査をしたいときに、複数リポジトリを参照できる上位の場所から claude を打ちたくなる

自チーム管理のリポジトリであればmonorepo化も検討に入りますが、他チーム管理のリポジトリも調査で参照する必要がある場合、monorepoにするという選択肢は取れません。

このような課題を解決する方法の一つに、Virtual Monorepoというものがあります。

弊社のymmtが書いたブログがVirtual Monorepoの把握に役立ちます。(今回の取り組みは、社内でVirtual Monorepoが話題になったのがきっかけです)

ymmt.hatenablog.com

Virtual Monorepoをチームで作る場合の選択肢

Virtual Monorepoを単純に「複数のリポジトリを参照可能な、仮想的なmonorepo」というものだと捉えるといくつか実装方法があります。

パターンA. gitignoreで repos/ 以下を無視して、repos/ 以下に直接cloneしてくる
- 実装が楽で、チームに展開しない個人の参照リポジトリも repos/reference-repos/ 以下にcloneするなど運用が柔軟
パターンB. symlinkで既存のすでにあるリポジトリを参照する
- 個人のワークフローがghqに依存する場合など、すでにあるワークフローに馴染みやすい
- symlinkだとClaude Codeが読んでくれないことがあった...
パターンC. Git submoduleで管理する
- どのcommitまでかまで指定できる。ただ運用が重くなる...

kintoneダッシュボードチームで管理しているVirtual Monorepoは、パターンAとパターンBの併用としました。

理由としては、Virtual Monorepo自体が当時実験的に入れたものであること(パターンBで既存のワークフローとの互換性を取る)、参照用リポジトリが多そうなのでgitignoreでまとめて repos/ 以下を管理しないようにするのが良さそうだと判断したためです。

実際導入してみて

導入してから3ヶ月ほど経ちました。チーム内で積極的にVirtual Monorepoを使っている人とそうでない人に分かれてはいますが、使っている人には良い効果を与えられたかなと思っています。 kintoneダッシュボードチームの管理するコードは、kintone本体と切り離されているため、実装中にkintone本体を参照したい時にVirtual Monorepoはとても便利です。

当初の想定と異なった部分や、学んだことを雑多に書きます。

Agent SkillsやSkillsのためのちょっとしたツールがVirtual Monorepo側に入った
- Virtual Monorepoが、単にリポジトリを束ねたものから、開発に必要な一式をまとめたものになってきた
- 新規メンバーのオンボーディングにも将来的にいい影響があるかもしれない
Virtual Monorepo側は開発用ツールのまとまりであって、製品コードと分離されているので、コードレビューが多少雑でも良い
- リポジトリを分離する基準みたいなものを考えるきっかけになりました。例えば、LLM wikiをリポジトリ管理する際にはどういう運用がいいんだろうか？みたいな(そういうデータベース的な使い方は本来の用途ではない説もありますが...)
チームに一つVirtual Monorepoという想定は正しそう
- チームのワークフローをVirtual Monorepoに詰め込む発想