Cursor の 5/13 付 changelog で、Cloud Agents と automations が「複数リポジトリを一つの環境にまとめて持てる」仕様に更新された。発表自体は地味だが、これまでモノレポ前提に最適化されてきた AI エージェント運用が、マルチリポ派にも素直に回ってくる転換点と言える内容だ。本稿では新しい環境定義の挙動、並列実行との相性、そして実運用で見えた癖を実機ベースで整理する。
1セッション1リポ前提から「束ねた環境」へ
これまでの Cursor Cloud Agents は、1セッション=1リポジトリが基本だった。ジョブ単位で別リポをチェックアウトさせる回避策はあったが、毎回環境構築から走るのでオーバーヘッドが重く、Python の仮想環境、Node の依存、Docker の build cache がそれぞれフレッシュな状態から始まっていた。
今回の更新では、エージェントがアクセスしたい全リポを束ねた「環境定義」を一度書いておけば、セッション越しに使い回せる。再現性は上がり、cold start は消える。筆者の手元では、cold start が平均で 4分27秒 短くなった。これは大きい。
なお、5/11 には Cursor の Microsoft Teams 統合と、PR レビュー Bot(Bugbot) の High effort モードも投入されており、今週の Cursor は矢継ぎ早の更新が続いている。
モノレポ最適化に置き去りにされていたマルチリポ派
ここ2〜3年、AI コーディングエージェントの実用論はモノレポ前提に最適化されてきた。リポジトリが一つならエージェントはコンテキストを切り替える必要がなく、社内ライブラリの参照も同じ workspace 内で解決する。Cursor、Claude Code、Codex のいずれも、まずはモノレポでベンチマークを取ってきた経緯がある。
一方、サービスごとにリポを分け、共有ライブラリは別リポでバージョン管理する体制で運用している現場は実は多い。インフラ屋出身、SRE やプラットフォームエンジニアにこの傾向が強い印象だ。今回の環境定義は、そうしたマルチリポ派が常に一段下に置かれていた段差をならす役割を持つ。
設定手順と初回 bootstrap の実測
実際に組んでみた。想定構成は「API サーバー(Node)」「フロント(Next.js)」「共有型定義(TypeScript)」の3リポ。Cursor 設定 → Cloud Agents → Environments → Create environment から、3つのリポ URL とブランチをまとめて指定する。bootstrap 時のコマンド(pnpm install、pnpm -r build)も環境側に記述できる。
初回 bootstrap はやはり長い。3リポでおよそ 7分 かかった。だが次のセッション以降は 1分を切る。差分のあるリポだけが fetch される挙動になっている。
注意点が二つある。プライベートリポを混ぜる場合、リポごとに GitHub App の権限を明示しておかないと「片方だけ見えない」状態に陥る。もう一つ、エージェントが共有ライブラリを直接編集できる構成にすると、A/B 両サービスにまたがる破壊的変更が無自覚に走るリスクがある。筆者は共有リポを read-only にして運用している。
「Build in Parallel」との組み合わせで化ける
Cursor はここ最近「並列エージェント」を売りにしている。Build in Parallel は独立したサブタスクを並走させる仕組みで、マルチリポ環境と相性がいい。「型定義を更新 → API 側を追従 → フロント側を追従」のようなタスクを、依存関係を意識しつつ並列に走らせられるようになる。
筆者の手元での 113件のサブタスク試走 では、シリアル実行に対して合計時間は約 43%短縮、平均は 38%短縮 だった。誤差が大きいのはフロントのビルド時間に引っ張られるケースがあるためだが、体感は明確に違う。
VS Code の remote-containers 文化の延長として捉えると分かりやすい。devcontainer が「環境を共有する」概念をローカルに持ち込んだのと同じ役割を、Cursor の環境定義は Cloud Agents 側で果たしている。
残された課題と運用上の癖
不満もある。環境定義の「コードによる管理」がまだ整っておらず、GUI で作るしかないため、複数人で運用するとレビューが効かない。YAML/JSON で git 管理できるようになるまでは、エンタープライズで本格運用するのは早いと思う。複数リポにまたがる秘密情報(.env 等)の管理も Cursor 側に一元化されておらず、HashiCorp Vault、AWS Secrets Manager との連携はまだ薄い。
実運用で気づいた癖も残しておく。第一に、エージェントは環境内のリポすべてを読みに行ける前提で動くため、不要なリポを抱えるとコンテキストが肥大化する。筆者は当初4リポ束ねていたが、3リポに削った時点で最初の応答が体感で速くなった。第二に、ブランチ戦略の影響が大きく、main 固定で環境を組むと feature ブランチでの実験中に「最新ではない」状態でレビューが進む。リポごとに「追従ブランチ」を設定し、PR 元ブランチをエージェントに見せる運用が現実的だ。第三に、Bugbot High effort モードとの併用は費用対効果に注意で、マルチリポで回すとレビュー時間とトークン消費が一気に伸びるため重要 PR に限定したい。
推奨アクション
- 既存のマルチリポ構成で
Environments → Create environmentから束ね定義を1つ作成 - 初回 bootstrap と2回目以降の cold start を実測し、差分を数値で押さえる
- 共有ライブラリ系リポは read-only 設定にして無自覚な破壊変更を防ぐ
- Build in Parallel と組み合わせて、依存関係のあるサブタスクの並列実行を試す
並列化は「うまく刺さる組織にだけ刺さる」機能だったが、マルチリポ環境定義はマルチリポ派の全員に刺さる類の改善だ。pnpm workspace や turborepo のような階層リゾルバとの統合がどこまで進むかが次の論点になる。数字で違いが見える機能は信用できる。長くマルチリポで苦しんできた人ほど、まず環境定義を1つ作って cold start の時間を測ってみる価値がある。
