Cursorは「Self-Hosted Machines」を公開した。クラウド上のコーディングエージェントが行うツール実行の部分を、企業が自ら管理するマシン上で動かせるようにする機能だ。移動するのは実行環境だけで、エージェントのループ、推論、計画立案はこれまで通りCursorのクラウド側に残り、タスクの起動とスケジューリングもCursorが担う。
接続の仕組みは逆向きに設計されている。企業側のマシンにCursor CLIを導入し、agent worker startを実行すると、そのマシンからCursorのクラウドへ向けて長時間持続するアウトバウンドのHTTPS接続が確立される。Cursorは公式に、プラットフォーム側から企業ネットワーク内部へ接続を開始することはないと明言している。セキュリティチームにとっては外向きの通信のみで完結する経路であり、このためにファイアウォールに穴を開ける必要がない。
なぜ実行環境を社内に戻すのか
Cursorが挙げるシナリオは3つある。1つ目は、エージェントが作業中に社内のソースリポジトリ、内部サービス、データベースに直接アクセスする必要がある場合で、ホスト型の仮想マシンでは届かない。2つ目は特定のハードウェアが必要なケースで、学習にはGPU、iOSアプリのビルドにはMacが要る。3つ目は、OSやビルドパイプライン自体が重すぎて標準的なクラウドイメージに収まらない場合だ。
この3つの制約に直面するのは、いずれも大企業だ。中小チームがホスト型サンドボックスを使う分には障害はほとんどないが、金融、医療、大手製造業ではコンプライアンス要件によってコードをサードパーティ基盤に置かないことが明文化されているケースが多く、これまでこうした顧客はエージェントの導入自体を見送るしかなかった。
2種類の形態と並んだ提携先
設定は2段階に分かれる。「My Machines」はノートPCや仮想マシン1台を個人アカウントに紐づけるもの。「Pools」はチームや企業向けの名前付きキューで、リクエスト量に応じて自動的にスケール(拡縮)する。後者は数十〜数百人が同じビルドマシン群を共有する場面を想定したものだ。
サンドボックス側にはAWS Lambda、Cloudflare、Coder、Daytona、E2B、Modal、Namespace、Vercelといった顔ぶれが名を連ねる。これらの組み合わせは今回の発表の位置づけを物語っている。Cursorは自前の隔離実行環境を作るつもりはなく、その層はすでに手がけている企業に委ね、自らはエージェントのスケジューリングとモデルという2つの領域を握る構えだ。中でもNamespaceが提供する機能は特徴的で、クラウドエージェントのセッションごとに実機のMacを起動できる。
LinuxとMac、両方のワーカーでブラウザ操作にも対応する。マシンにChromeまたはChromiumの依存関係を入れておけば、エージェントが自らページを開いて変更内容を確認できる。
実態を物語る一つの数字
Cursorは記事の中で、社内でマージされたプルリクエストのうち60%超がクラウドエージェントによって作成されていると明かした。この数字は企業導入をテーマにした記事の中で示されており、狙いは分かりやすい——まず自社が使いこなしていることを示し、その上で顧客にマシンの提供を求めるという流れだ。
製品ラインを振り返ると、Cursorはこの1年、一貫してスケジューリング層に踏み込んできた。まずエージェントをクラウドに移し、次に起動速度の問題を解決し、そして今回は実行場所そのものに手を付けた。コーディングツール同士の競争軸は、補完の質からランタイムの所在地へと移っており、「マネージド体験」と「コードを外に出さない」という両立を実現できるかどうかが、大口顧客の予算を獲得できるかを左右する。
参考資料：Cursor公式ブログ、CocoLoop、各サンドボックスプロバイダーの公開情報。内部マージにおける60%という割合、接続方式、プロバイダー一覧はCursor公式の発表内容に基づく。