Cursor 3.4 がクラウドエージェント向けにマルチリポジトリ環境と高速な Dockerfile ビルドを追加

2026 年 5 月 13 日、Cursor は バージョン 3.4 をリリースしました。このリリースは主に、クラウドエージェントの群れが実際に作業するために必要な配管に関するものです。目玉はマルチリポジトリ環境ですが、その下にあるビルドシークレットとレイヤーキャッシュの変更こそが、多数のエージェントを並列で動かすことを実用的な水準まで安く済ませる鍵です。これは Cursor 3.3 の並列化作業の直接の延長線上にあり、すでにタスクをサブエージェント間で分割していて「1 環境につき 1 リポジトリ」の壁に当たっていたチームを対象にしています。

1 つの環境に複数のリポジトリ

3.4 までは、クラウドエージェントの環境は 1 つのリポジトリにスコープされていました。タスクが境界を越えた瞬間にそれは破綻します。バックエンド API とその共有型パッケージ、Flutter アプリと Dart サーバー、あるいは .NET ソリューションと隣接するインフラリポジトリといった組み合わせです。追加のリポジトリをセットアップスクリプトの中で手動でクローンする (遅く、壊れやすい) か、タスクを分割してリポジトリ間のコンテキストを失うか、どちらかしかありませんでした。

Cursor 3.4 はマルチルートワークスペースの仕組みを再利用し、エージェントが必要とするすべてのリポジトリを環境定義の一部としてリストできるようにしました。典型的な構成は次のようになります。

{
  "name": "api-and-shared-types",
  "repositories": [
    { "url": "github.com/acme/api", "branch": "main" },
    { "url": "github.com/acme/shared-types", "branch": "main" }
  ],
  "dockerfile": "./infra/agent.Dockerfile"
}

両方のリポジトリが同じ環境にクローンされ、エージェントはそれらを 1 つのワークスペースとして見ます。セッションは環境を再利用するため、同じペアに対して新しいエージェントを立ち上げるのはまっさらなクローンではなくキャッシュヒットになります。

ビルドシークレットと 70% 高速なキャッシュヒット

Dockerfile 側にも実用的な修正が 2 つ入りました。1 つ目は、実行中のコンテナの外側にとどまるビルドシークレットのための --mount=type=secret です。

# syntax=docker/dockerfile:1.7
FROM mcr.microsoft.com/dotnet/sdk:9.0
RUN --mount=type=secret,id=nuget_pat \
    dotnet nuget add source https://nuget.pkg.github.com/acme/index.json \
      --name acme --username ci \
      --password "$(cat /run/secrets/nuget_pat)" --store-password-in-clear-text
COPY . /src
WORKDIR /src
RUN dotnet restore

PAT はビルド手順にスコープされているため、後から走るエージェントプロセスはそれを読めません。これにより、プライベートなパッケージフィードのために資格情報をイメージや環境スクリプトに焼き込まざるを得なかった穴がふさがれます。

2 つ目の修正はレイヤーキャッシュです。リリースノートによれば、キャッシュがヒットしたビルドは 70% 高速になります。Dockerfile を編集したときに、変更されたレイヤーだけが再ビルドされるからです。実用上は、RUN apt-get install ... 行を変更しても、restore のレイヤーが変更箇所より上にある限り、その下の長い dotnet restore は無効化されない、ということです。

エージェント主導のセットアップが、実行前に欠けた資格情報を検出

環境を作成または更新すると、Cursor は確認質問を投げ、欠けている資格情報を特定し、ビルドが成功することを検証してからエージェントにその環境を使わせる、というセットアップパスを実行するようになりました。ビルドが失敗した場合、環境はベースイメージにフォールバックして警告を表面化し、エージェントがクローンを試みた瞬間に黙って失敗することはなくなります。

各環境はまた、管理者のみに制限されたロールバック付きのバージョン履歴と、誰が何を変更したかの監査ログを保持します。すでに並列化されたエージェントを大規模に運用しているチームにとっては、こうしたガードレールは速度面の利得よりも重要です。

3.4 の残りの内容は完全版の Cursor changelog を参照してください。