Cursorのクラウドエージェントが速く立ち上がる理由！buildsとenvironment.jsonの書き分け

🙌 結論からいうと

クラウドエージェントが速く立ち上がるようになったのは、Cursor が裏で「すぐ使える開発環境」を作り置きしてくれるようになったからです。

この仕組みが builds で、2026年8月17日からは全環境でデフォルトになっています！

設定を何も変えなくても恩恵があるのはありがたいです (^o^)

ただ、速さをちゃんと引き出すには .cursor/environment.json の install と start の書き分け が相当大事です。

ここを雑に書いていると、せっかくの作り置きが半分しか役に立ちません・・・。

👀 builds の仕組み

一言でいうと、開発環境のコピーをバックグラウンドで準備しておく仕組みです。

中身はこんな状態になっています。

リポジトリはクローン済み
依存パッケージはインストール済み
install スクリプトも最後まで実行済み

エージェントを起動すると、この準備済みの環境から始まります！

公称では、初回の応答まで 最大3倍速く なったとのこと 🚀

Cursor 社内の環境だと、起動そのものは10倍速くなったそうです (・∀・)

ビルドは デフォルトで1時間ごと に作り直されます 👀

しかも温まったマシンを複製して起動するので、ディスクから復元するより速いんですよね。

追加料金はかかりません。

クラウドエージェントを何本も並べて投げる使い方は、ローカル・worktree・クラウドの使い分けの記事でも書きました。

あの記事で「クラウドは立ち上がりが少し待つ」と書いた部分が、builds でかなり解消されています 👍

💡 install と start の書き分け

.cursor/environment.json で使うキーのうち、今回大事なのはこの3つです。

install: ビルドを準備するときに実行される
start: エージェントが動き始めるときに実行される
terminals: エージェント開始時に、共有の tmux セッションの中で立ち上がる

ポイントは、install は「作り置きの段階」で走る ということです。

つまり、時間がかかる処理ほど install に寄せたほうが、エージェント起動時の待ちが減ります！

私の Laravel + Vite のプロジェクトだと、こんなふうに分けています。

{
  "install": "composer install && npm ci",
  "start": "cp -n .env.example .env && php artisan key:generate",
  "terminals": [
    { "name": "vite", "command": "npm run dev" }
  ]
}

最初は npm run dev を install に入れてしまっていました (T_T)

install はビルドの準備で走るものなので、開発サーバーのような「動き続けてほしいプロセス」を置く場所ではないんですよね。

常駐させたいものは terminals に書くと、エージェント開始時にちゃんと立ち上がります！

逆に composer install を start に書くと、エージェントを起動するたびに毎回インストールが走ります (´･ω･`)

せっかくの作り置きがムダになるので、ここは必ず install 側にしておきたいです 💡

✨ 壊れたビルドはどうなるか

個人的に一番ありがたいのがここでした。

依存パッケージの更新や Dockerfile の変更でビルドが失敗しても、そのビルドは有効になりません。

エージェントは 最後に成功したビルド を使い続けます！

失敗したことは通知で教えてくれるので、裏で直している間も作業が止まりません (｀・ω・´)

以前だと、誰かが package.json を壊した瞬間に、全員のクラウドエージェントが起動でコケていました。

あれがなくなったのは、チームで使うときにかなり大きいです 🎉

😅 私が気をつけていること

便利な反面、「古いビルドで動き続けている」ことに気づきにくい という面もあります。

ビルドの失敗通知を見落とすと、エージェントだけ1つ前の依存関係で動いている・・・ということが起こり得ます (・_・;)

なので私は次の3つを意識しています。

ビルド失敗の通知は、チームの Slack チャンネルに流れるようにしておく
依存パッケージを上げたPRをマージしたら、次のビルドが成功したかを一度だけ確認する
シークレットは environment.json に直書きせず、Cursor 側のシークレット設定に入れる

あとは install をなるべく決定的にしておくことです。

npm install ではなく npm ci にしているのもそのためで、ロックファイルどおりに入るので、1時間ごとのビルドで中身がブレにくくなります (^_^)

🔧 install と start の書き分けの例

記事で書いた「install と start の書き分け」を、Laravel のプロジェクトで書くとこんなイメージです(^^)

{
  "install": "composer install && npm ci",
  "start": "php artisan migrate --force && npm run build"
}

考え方はシンプルで、作り置きしておけるものは install、毎回やり直したいものは start です👀

install に入れるもの: composer install や npm ci のような、依存パッケージの準備。時間がかかるけど、何度やっても結果が同じもの
start に入れるもの: マイグレーションやビルドのように、そのときのブランチの内容で毎回やり直したいもの

逆に、install にマイグレーションを入れてしまうと、作り置きした時点のデータベースのまま止まってしまい、ブランチを切り替えたときに食い違いが出ます(・_・;)

迷ったら、**「ブランチが変わっても結果が同じなら install」**で分けると、ほぼ外れません✨

パパ系Webエンジニア〜愛用ガジェット一覧 🛍️

AI開発・執筆に使っている作業デスク環境を楽天ROOMにまとめています ✨ デスク周りの参考にどうぞ 🙌

👍 まとめ

Cursor のクラウドエージェントが速くなったのは、builds が1時間ごとに開発環境を作り置きしてくれるからでした。

設定なしでも速くなりますが、重い処理は install、常駐プロセスは terminals に分けておくと、その速さをちゃんと活かせます 🙌

壊れたビルドが本番の環境を置き換えない仕組みも、チームで使うならかなり安心材料です。

一度 .cursor/environment.json を見直してみると、待ち時間がかなり変わるかも・・・！

※ バージョン番号・提供範囲は今後も変わる可能性があります。最新情報は公式サイトをご確認ください👀