しかし、コーディングエージェントを利用するようになり、「エージェントにシステム全体のコンテキストを効率よく理解させる」という新しい観点から、モノレポの価値を再評価する必要が出てきました。

ローカル内で相対パスを指定して無理やり相互参照させる運用もありますが、チーム開発でのディレクトリ差異に弱く、CI/CD上でもビルドがコケやすいため、技術的負債になりがちです。

モノレポなら、プロンプトで前提条件を長々と書く必要がなくなります。例えば以下のような構成です。

1/my-project
2├── backend/   # Go (API, DBマイグレーション)
3├── frontend/  # React (Web UI)
4└── mobile/    # Android (モバイルUI)

この状態で「プロフィールに『誕生日』フィールドを追加して」と指示を出すだけで、GoのDBマイグレーション、APIのレスポンス修正、Androidのデータクラス修正まで、一貫した修正案を出してくれます。この開発体験の良さは、今すぐ享受すべきメリットです。

どちらの環境にも全く同じコード（Goのモデル・ハンドラ・マイグレーション・OpenAPIスキーマ、TypeScriptの型定義・APIクライアント・Reactコンポーネント）を配置し、同じタスクをエージェントに投げました。

完全分離の構成では、以下のような流れになります。
1. Session 1（FE）：「誕生日フィールドを追加して」→ フロントエンドの型定義とコンポーネントだけが修正される（14,439tokens消費）
2. 人間の橋渡し作業：FE側で何がどう変わったかを確認し、BE側のエージェントに伝えるプロンプトを作成（ここに5〜10分かかる）
3. Session 2（BE）： 橋渡しプロンプト（311tokens）を添えてBE側を修正（18,545 tokens消費）

つまり、開発者がエージェント間の「人間ルーター」になってしまうんです。FEのエージェントが出した結果を人間が読み解き、BEのエージェントが理解できる形に翻訳する。この仲介コストがトークンと人間の時間の両方で発生します。

さらに見落とせないのが整合性リスクです。完全分離の構成では、人間の橋渡しプロンプトの精度がBE側の修正品質を左右します。もし伝達にミスがあれば、FEとBEで型が噛み合わず3セッション目（さらに+10,000 tokens以上）が必要になるケースも現実的にあり得ます。

モノレポであれば、エージェントが両方のコードを直接参照するため、このような伝達ミスは構造的に発生しません。

フロントエンドを外部委託している場合など、「バックエンドのコアなコードは見せられない」という要件が発生します。さらに、すべてのコードが一箇所に集まると、ちょっとしたWeb側のテキスト修正でAndroidのビルドテストまでトリガーされるなど、GitHub Actionsのコストが跳ね上がる問題に直面します。

一番の課題は「更新時の2段階コミット」です。サブモジュール側を更新した場合、親リポジトリ側でも「新しいコミットハッシュを参照するためのコミットとPR」を毎回作成する必要があり、日常的な開発体験（DX）が少し落ちます。

ただ、インフラ面では少し注意が必要です。ソースコードは共通でも、ビルドの仕組みはiOSとAndroidで異なりますよね。なので、「コード生成はモノレポとしてAIの恩恵を受けつつ、CI/CD周りはOSごとにしっかり分けて組む」といった構成にするのが現実的かなと思います。

② 【外部委託あり・バックエンドが巨大】なら ➡︎「サブモジュール」で部分解決
「フロントエンドは外部委託している」「バックエンドのコードベースが巨大すぎてCIが死ぬ」といった制約があるなら、無理なモノレポ化は危険です。今の分割構成を維持しつつ、「型定義・スキーマ」などAIに読ませたい文脈だけをサブモジュール化して、最小限のコストでAIの恩恵を受けましょう。

③ 【既存モバイルアプリ・複雑なCI】なら ➡︎「完全分離」のまま維持
すでにFirebase Test Labなどの重厚なモバイル独自パイプラインが組まれている場合、AIのためにリポジトリを統合すると、CI/CDのメンテコスト増大という痛いしっぺ返しを食らいます。この場合は構成を変えず、プロンプトの工夫や、人間が適切にコンテキストを切り出す運用でカバーするのが正解です。