🕛 2026.5.18 13:32 文:マコトてっぺき

Cursor 3.4 が「クラウドエージェントの作業部屋」をDockerfileで設定できるようにした。並列に走る AI を企業の中で安全に飼う話

Cursor 3.4 が「クラウドエージェントの作業部屋」をDockerfileで設定できるようにした。並列に走る AI を企業の中で安全に飼う話
X はてブ LINE Feedly

結論から言うと、コードを書く AI を「企業の中でちゃんと飼える」状態に、また一段近づいた話です。

Cursor 3.4 が 5 月 13 日にリリースされました。今回の主役は クラウドエージェント用の開発環境。要するに、Cursor の中で並列に走らせている AI エージェントが、どんな「作業部屋」で動くかを、Dockerfile で企業側が定義できるようになった、という変更です。

おさらい:Cursor のクラウドエージェントとは

Cursor は IDE(コードエディタ)で、最近の主力機能のひとつが Background Agents、いわゆるクラウドエージェントです。

ローカルの自分の PC で AI を動かすのではなく、Cursor 側のクラウド上に作業部屋(コンテナ)を立てて、その中で AI が自分でコードを書き、テストを走らせ、PR を出すまでやる仕組み。1 つのタスクを 1 つの作業部屋に閉じ込めて、並列にいくつも回せる、というのが売り。

問題はここで、これまでは作業部屋の中身(言語ランタイム、依存ライブラリ、社内ツール、認証情報)を、Cursor のデフォルト環境に頼るしかなかった。「うちはこの Python バージョン」「うちはこの内製ライブラリ前提」という社内事情を、エージェントの作業部屋に持ち込むのが面倒だった、というのが現場の不満として残っていました。

3.4 で何が変わったか

公式 changelog から取れる範囲だと、変更点は主に 5 つ。順序を間違えないように整理します。

第 1 に、Dockerfile ベースで環境を定義できる。社内で標準化済みの Dockerfile をそのまま持ち込めば、エージェントが動く作業部屋が、自分の手元と同じ構成になる。

第 2 に、マルチリポジトリ対応。1 つの作業部屋に複数のリポジトリをマウントできる。「フロントとバック、両方触らないと変更が完結しない」案件で効きます。

第 3 に、build secrets 対応。コンテナビルド時にだけ必要なシークレット(プライベートパッケージレジストリのトークン等)を、ビルドが終わった後のイメージに焼き付けずに使える。要するに、機密情報がイメージレイヤーに残らない、という設計。

第 4 に、レイヤキャッシュ 70% 高速化。Dockerfile を毎回ゼロからビルドし直すのではなく、変更があった層だけ作り直す。エージェントの起動時間が短くなる、という効率改善。

第 5 に、環境のバージョン履歴とロールバック、egress / secrets の環境別スコープ。ここがセキュリティ的に一番気にしてほしい部分なので、節を分けます。

規制の文脈で言うと、ここが効く

3.4 の中で、見落としがちだけど enterprise の購買稟議で大きいのが、egress(外向き通信)と secrets(機密情報)を、環境ごとに別スコープで持てるようになった点です。

これまでだと、エージェントが動く作業部屋から外向きに通信できる先(egress)と、参照できるシークレットの一覧が、ほぼ「組織全体で共通」の粗い粒度だった。「検証用エージェントが、本番 DB の認証情報を参照できてしまう」のような構成上のリスクが、設計次第で残っていたわけです。

3.4 では、これを 環境(作業部屋テンプレート)単位で分離できる。たとえば「フロントエンドのリファクタ専用環境」は npm レジストリにしか出ていけない、シークレットは Storybook のホスティング鍵だけ、というふうに、作業部屋ごとに必要最小限を切り出す設計が現実的になります。

それから、環境のバージョン履歴とロールバック。これも地味だけど効きます。インシデント発生時に「いつ、どの環境定義の変更がきっかけだったか」を遡れる。監査ログとして、ISMS や SOC 2 の運用にも答えやすい構造になります。

日本の企業導入で考えたい点

3 つだけ、現場目線で言わせてください。

ひとつ、並列エージェントによる end-to-end タスク実行を業務時間中に流すなら、CI と棲み分けを先に決めること。エージェントが自動で PR を出してくる量が増えると、レビュー側のキャパが先に詰まります。

ふたつ、Dockerfile を持ち込めるようになった、ということは、Dockerfile 自体のセキュリティ管理が問われるということ。脆弱性スキャンの対象が増えるので、Trivy 等での自動チェックを CI に組み込む順番を、エージェント本格運用の前に済ませておきたい。

みっつ、「クラウド上の作業部屋」にソースを置く前提なので、データ越境の問題は要確認。Cursor のホスティングリージョン、ログ保管ポリシー、契約上のデータ取り扱い条項、ここは法務と一緒に通しておかないと、後で剥がせなくなります。

で、何が変わるか

「コードを書く AI を、企業の中で安全に並列に飼う」ための配管が、Cursor 側でまた一段ぶん固まった。動向は追っておきたい話です。

情報元
Cursor 公式 changelog — Cursor 3.4(英語)
Cursor 公式 — Background Agents ドキュメント(英語)
Cursor 公式トップ(英語)

みんなの反応

D
DXおじさん
(大企業DX推進室長・50代男性)

egress と secrets の環境別スコープ、これがあるかどうかで稟議の通り方が違うんです。これまでは情シスから「全社共通の認証情報に手が届く設計は無理」で止められてた。3.4 なら開発環境別に切り出せるので、PoC 申請を出し直したい。
エージェント職人
(AIエージェント開発者・20代男性・個人開発)

Dockerfile ベースで作業部屋作れるの、再現性の観点でほんとに助かる。これまで「私の環境では動いた」問題がエージェント間でも起きてて、サポート対応の半分はそこだった。レイヤキャッシュ 70% 高速化もエージェント並列実行で効いてくる数字。
G
GPU貧乏エンジニア
(MLエンジニア・20代男性・スタートアップ)

マルチリポ対応はうちみたいなマイクロサービス構成のスタートアップにとってかなり大きい。これまで「フロントとバック、両方触る変更」を 1 タスクでエージェントに渡せなかったので。コスト面ではクラウド側の課金体系が次の関心事です。
I
IT法務の人
(IT企業法務・40代男性・知財担当)

build secrets が最終イメージに焼き付けられない設計、これは契約レビュー上もポイントになる。プライベートパッケージレジストリへの認証情報を含む形でイメージを社内配布、というのが従来パターンで、ここが綺麗になるなら知財管理側でもプラス。データ越境の論点は別途整理が要りますが。
安全第一マン
(AIセーフティ研究者・40代女性)

エージェント並列実行の安全性は、環境分離の粒度で大きく決まる。3.4 でスコープを切り出せるようになったのは適切な方向。残課題は「エージェント自身が誤って環境を跨ぐ提案を出してきたとき、どの層で止めるか」の設計責任の整理。
X はてブ LINE Feedly