Cursorが5月13日に公開したクラウド環境の更新で、クラウドエージェントの「単一リポしか触れない」という制約が外れた。同じ更新でDockerfileビルドのレイヤキャッシュ動作も改善され、公式値ではキャッシュヒット時に従来比で約70%高速化されている。地味な変更が並ぶリリースだが、フロントとバックエンドを別リポで運用しているチームには直接効く内容なので、本稿で実機ベースで整理する。
1 environment に複数リポを束ねられるようになった
新しいクラウド環境設定では、1つのenvironmentに複数のリポジトリを束ねることができる。エージェントはセッション内で複数リポを横断し、片方の変更が他方に与える影響を読みながら作業する。これまでは「フロントは見えるがバックエンドは見えない」状態でPRが上がってくることがあり、文脈不足を理由に何度も差し戻すパターンが多かった。
筆者の運用では、フロントのweb-app、バックエンドAPIのapi-server、共有型定義のshared-typesの3つを1環境に束ねている。エージェントに「APIに新しいエンドポイントを追加してフロントから叩けるようにして」と頼むと、3リポを跨いだ実装が1セッションで通るようになった。これまではリポを切り替えるたびにエージェントを立て直していたので、体感の摩擦はかなり下がっている。
もうひとつ大事なのは、その環境がセッションをまたいで再利用できる点。毎回セットアップし直す必要がなく、これまでの「使い捨てクラウドVM」感がだいぶ薄れた。
Dockerfileビルドの「キャッシュが効く」更新が体感的には最大
正直に言うと、マルチリポ対応より体感が大きかったのはこちら。Dockerfile変更時のレイヤキャッシュ動作が改善され、変更されたレイヤだけが再ビルドされる構造になった。公式の数値ではキャッシュにヒットしたビルドは従来比で約70%高速とされている。
これは「Dockerfileの上の方のapt-get installに1行足したらフルビルドし直し」というよくある苦痛を、レイヤ単位で逃がしてくれる挙動だ。手元の小規模プロジェクト（Python 3.12とNode 20の混在環境）で計測したところ、再ビルド時間は3分47秒から1分08秒まで縮んだ。約70%減という公式値とほぼ一致する。
クラウドエージェントが「実装→ビルド→テスト→修正」のループを回すユースケースでは、ビルド時間が1分台で収まるかどうかは決定的だ。3分待つループは人間が見張りたくなるが、1分なら別作業に戻れる。エージェントの自律性がここで一段上がる。
ビルドシークレットが「ビルド時限定」スコープに
実務寄りの更新がもう1つ。Dockerfileビルド時にプライベートパッケージレジストリ用のクレデンシャルを使う場合、そのシークレットはビルドステップにスコープされ、ランタイムには渡らない仕様になった。BuildKitの--mount=type=secret相当が、Cursorのクラウド環境でも素直に使えるようになった、と理解している。
これは小さく見えるが、セキュリティ運用としては大きい。これまで「ビルド時にだけ必要なnpmレジストリトークンが、なぜかランタイムでも参照可能」という構成事故が起きやすかった。今回の更新で、設計レベルでこの種の漏洩経路が塞がる。レビュー側も「このシークレットはランタイムに渡る？渡らない？」を毎回確認しなくて済む。
「準備のコスト」が分散される設計
これまで多くのクラウドエージェント系サービスでは、セッション開始時に依存パッケージのインストール、認証情報のセットアップ、テストデータのロードが毎回走っていた。これが1分強、長いと3分ほど。1日10セッション回すと、それだけで30分が消える。
今回の更新では、環境定義（Dockerfile・依存リポ・シークレット・環境変数）が一度ビルドされたら、その状態のまま次のセッションが立ち上がる。差分があったレイヤだけ更新される構造で、「準備のコスト」が分散される形に変わった。
エンジニアリングの世界では「準備が0秒になる」と作業の頻度が変わる、という法則がある。テストが速くなった瞬間からテストを書く回数が増える、あの現象に近い。クラウドエージェントへのタスク投入も同じで、立ち上げが軽くなれば1日に投げる回数が増え、結果として「ちょっとした調査」もエージェント任せにする運用が現実的になる。
推奨アクション
- フロント/バックを別リポで運用しているチームは、1つのenvironmentに束ねる構成を試す
- Dockerfileビルドが長いプロジェクトは、レイヤ順を見直してキャッシュヒット率を上げる
- プライベートレジストリのトークンは
--mount=type=secret相当のビルドシークレットに移行する
今回の更新の本質は、機能リストではなく「クラウドエージェントが固有の環境を持って活動する存在に近づいた」という設計思想の変化だと思う。これまで「都度使い捨てのワーカー」だったものが、「環境を引き継いだまま継続的に作業するインフラ的存在」に寄ってきた。マルチリポ対応とビルドキャッシュ刷新は、その方向性を支える土台の更新だ。
