Cursor Cloud AgentとCloudflare Workersを比較：残る2つの差【2026年5月】

5月13日、Cursorはマルチリポジトリ対応のクラウドエージェント環境をリリースしました。Cursorの製品ページによると、Cursor Cloud Agentはすでに実運用に入り、Cursorがマージするプルリクエストの30%超を、クラウドサンドボックス上で動作する自律型エージェントが作成しています。

Cursor Cloud Agentの5月13日アップデートで何が変わったのか

目玉は、複数のリポジトリを扱えるクラウドエージェント環境です。エージェントは、Cursorが4月24日に投入したマルチルートワークスペースを土台に、設定済みの1つの環境から複数のリポジトリを横断して作業できるようになりました。環境はセッションをまたいで再利用できます。つまり、エージェントを起動するたびに同じ開発環境を設定し直す必要がありません。

設定の中心はDockerfileです。ビルドシークレットはビルド工程だけに限定され、実行中のエージェントには渡りません。ビルドに埋め込んだAPIキーが、意図せずエージェントの作業メモリに入り込む――エージェント基盤で起こりがちな事故を防ぐ設計です。Cursorには、リポジトリ内のツールや依存関係を調べてDockerfileを設定する機能もあります。このフローは引き続きEnterpriseチーム向けのプライベートベータです。

性能面で最も大きく改善したのはレイヤーキャッシュです。キャッシュヒット時は変更されたDockerfileレイヤーだけを再ビルドするため、ビルドが70%高速になりました。チーム内で何度も立ち上がるエージェントにとって、待たされるか、すぐ作業に入れるかを左右する改善です。

競合が軽く扱いがちなのは、むしろ運用機能です。各環境にはロールバック可能なバージョン履歴があり、ロールバックは管理者だけに制限されています。監査ログには、チームメンバーが環境に対して行ったすべての操作が記録されます。外向き通信の許可リストとシークレットのスコープは環境単位なので、環境Aのシークレットへ環境Bからアクセスすることはできません。エージェントに本番コードへのPRを作らせる前に必要になる、目立たないながら重要な基盤です。

Cursorが発表で実例に挙げたのはAmplitudeです。同社のCursor Automationsは公開Slackチャンネルを監視し、報告された問題を調査して、影響を受けるリポジトリを特定し、該当する複数のリポジトリへPRを作成します。実在する企業の実運用規模で、初動の切り分けを担うマルチリポジトリエージェントです。デモではありません。

「マージ済みPRの30%超」がCursorの実力を示している

Cursorによると、同社がマージするプルリクエストの30%超は、クラウドサンドボックスで動く自律型エージェントが作成しています。重要なのは分母です。数えているのはエージェントの試行回数ではなく、マージされたプルリクエストです。すべてのコミットを人がプッシュしなくても、レビュー、修正、引き渡しまで一連のループを完結できることを示しています。

2026年9月2日以降、CursorのSelf-Hosted Machinesを使えば、ファイル編集、ターミナルコマンド、コンピュータ操作ツール、ローカルMCPの実行を顧客管理のワーカーへ移せます。一方で、エージェントループ、推論、計画はCursorのクラウドに残ります。これで非公開環境で実行できないという差は解消されましたが、Cursorがプログラム可能な永続ランタイムになったわけではありません。

もはや選択軸は「セッション限りか、永続するか」ではありません。Cursorは会話状態をバックエンドに保存し、実行を後から開いて再開できます。Self-Hosted Team Poolsでは休止したワークスペースも復元できます。より本質的な違いは、ベンダー管理のエージェント状態か、プログラム可能なアプリケーション状態かです。Cloudflareでは、AgentごとのSQLite状態と永続的なWorkflowステップをコードから制御できます。

私のCloudflare Workers＋Agents SDK構成ですでにできていること

私はCloudflare上で6つの本番エージェントを運用しています。ランタイムはWorkers、状態はインスタンスごとのSQLiteを備えたDurable Objects、長時間のオーケストレーションはCloudflare Workflowsが担います。1人で構築し、単一アカウントで運用している内訳は、こちらで詳しく解説しています。Cloudflareの全構成にかかった2026年4月の費用は$19.14でした。これは特定時点の本番請求額であり、プラットフォームの見積価格ではありません。CursorのEnterprise価格はCustomで、Team PoolsにはEnterpriseが必要です。Self-Hosted Machinesでも、選択したモデルの料金に加えてワーカーの費用が発生します。

この構成とCursorの現行製品には、3つの違いがあります。

コードで実装するマルチリポジトリ。 Workerは実行時にHTTP経由でリソースを取得できます。コンテキストがWebサイトの先にある場合は、旧Browser RenderingであるBrowser Runからヘッドレスブラウザを操作できます。Cursorはマルチリポジトリアクセスを再利用可能な環境設定として提供します。一方、Cloudflareでは取得処理、認証、リポジトリ操作を自分で実装します。どちらが優れているという話ではなく、制御する場所が異なります。

プログラム可能な永続状態。 Cloudflare Agentはアプリケーション状態を専用のSQLiteデータベースへ自動保存し、再起動や休止の後に読み戻します。Cursorも会話状態を保存し、実行を再開できます。違いは制御権です。Cursorでは会話ストアとエージェントランタイムを同社が管理しますが、Cloudflareではアプリケーション状態とそのスキーマを自分のコードから扱えます。

自動的なexactly-once実行ではなく、永続的なステップ境界。 Workflowsでは各ステップを個別に再試行でき、状態を出力しておけば、ネットワーク障害やインフラ障害の後も実行を保存して続行できます。step.doはステップ単位の再試行設定を受け取り、NonRetryableErrorは回復不能な失敗の再試行を止めます。また、WorkflowのインスタンスIDは一意です。ただし、同じステップが複数回実行される可能性はあります。副作用を伴う呼び出しは冪等にするよう、Cloudflareも明記しています。利点は、開発者が永続性と再試行を設計できることです。プルリクエスト、メール、課金の重複を自動で防いでくれるわけではありません。

Cursor Cloud Agentに今も残る2つのギャップ

ギャップ1：顧客が制御できる、プログラム可能なエージェント状態。 Cursorは基本的な再開性をすでに実現しています。会話状態はデフォルトで無期限に保持され、管理VMのスナップショットは非アクティブ期間90日を基準とするローリング方式で保持されます。Self-Hosted Machinesはツール実行を移しますが、エージェントループの運用と会話の保存は引き続きCursorが担います。Cloudflare Agentでは、SQLiteに保存された状態をアプリケーションランタイム内で利用できます。エージェントがインシデントを監視したり、移行作業を調整したり、数日間のオンボーディングを通じて業務状態を引き継いだりする場合に、この違いが効きます。

このギャップは、5月に述べたときより狭くなりました。Cursor製品内のエージェント実行は再開できます。それでも、アプリケーションがCursorのチャットとは独立して照会、拡張、連携できる、顧客所有のステートマシンは公開されていません。

ギャップ2：開発者が定義できる永続的なステップ機構。 Cursorの現行Cloud AgentおよびSelf-Hosted Machineのドキュメントには、状態を保存し、ステップごとに再試行を設定できるWorkflowステップ相当のアプリケーションプリミティブがありません。Cloudflareにはあります。コーディングエージェントが課金、メール、デプロイなど、外部への副作用を伴う処理まで踏み込むと、この差が重要になります。

ツール呼び出しを自分のマシンへ移しても、このギャップは埋まりません。変わるのは実行場所であって、オーケストレーションの契約ではないからです。Cloudflareも副作用をexactly-onceにはしません。再試行されるステップは、やはり冪等に設計する必要があります。

これはCursorへの批判ではなく、製品カテゴリーの違いです。Cursorは、マネージド環境と顧客運用環境の両方でツールを実行できるコーディング製品です。Cloudflareはプログラム可能なアプリケーションランタイムです。9月のリリースでインフラ面の差は縮まりましたが、状態とオーケストレーションの境界は今も両者を分けています。

創業者とCTOが今週選ぶべき構成

チームのタイプが3つなら、取るべき選択も3つに分かれます。

プロダクト機能を出荷する小規模チームなら、Cursorの環境とネットワーク制御でビルドを再現できる限り、Cursor管理のCloud Agentsを使うのが合理的です。5月13日の環境アップデートで、マルチリポジトリ設定、ビルドシークレット、キャッシュ、監査性を扱えるようになりました。さらに、マージ済みPRの30%超というCursorの公表値が、実運用の裏付けになっています。明確なポリシー上の理由がないなら、ワーカーフリートを自前で運用する必要はありません。

すでにCloudflareやVercelで長時間動くバックグラウンド処理を運用しているなら、永続的なアプリケーション状態とオーケストレーションはその基盤に残します。Cursor Self-Hosted Machinesでは、CloudflareやVercelのインフラをツール実行に使えるようになりましたが、エージェントループの管理者はCursorのままです。Anthropicが同種のプリミティブを中小企業向けにどうまとめているかは、コンシューマー側の類似例も参考になります。各プラットフォームがエージェントへ収束する流れは、至るところで起きています。

エンタープライズ導入を計画しているなら、許可リスト、Tailscale、AWS PrivateLink、Cloudflare Tunnelでアクセス要件を満たせる場合は、まずマネージドCloud Agentsから始めます。チェックアウト、ツール実行、カスタムハードウェア、ワーカーイメージを自社管理下に置く必要がある場合はTeam Poolsを使います。Team Poolsには、価格がCustomのEnterpriseが必要です。CursorによるDockerfile設定は、引き続きプライベートベータです。

5月以降、何が変わったのか

注目すべきシグナルは2つです。

1つ目は、Cursorが会話状態とランタイムのワークスペースを分けて説明するようになったことです。会話状態はデフォルトで無期限に保持されるため、後から実行を開いて再開できます。管理VMのスナップショットは、開始または再開によって期限が延長されない限り、90日間操作がないと失効します。基本的な再開性はもうギャップではありません。残る論点は、所有権とプログラム可能性です。

2つ目は、非公開環境で実行できないというギャップが消えたことです。Self-Hosted Machinesがこの問題を解消する一方、エージェントループ、推論、計画はCursorのクラウドに残ります。顧客が制御するエージェント状態と、開発者が定義する永続的なステップ機構。この2つが、現在も意味のある違いです。

Cursorの5月13日リリースで、セルフホスト型エージェント基盤は不要になりますか？

いいえ。Cursorは現在、個人のワークフロー向けにMy Machines、Enterpriseのフリート向けにTeam Poolsというセルフホストの選択肢も提供しています。これによりツール実行は自社ネットワーク内へ移せますが、エージェントループの実行と会話状態の保存はCursorが担います。プログラム可能なアプリケーションランタイムや永続的なWorkflowステップが必要なチームには、そのレイヤーを支える基盤が引き続き必要です。

Cursorのキャッシュ済みクラウドエージェント環境は、どれほど高速になりましたか？

5月13日のレイヤーキャッシュ改善により、キャッシュヒット時のビルドは70%高速になりました。キャッシュがヒットすると、変更されたDockerfileレイヤーだけが再ビルドされます。

Cursor社内の『マージ済みPR』という数字は何を意味しますか？

Cursorの現行ファーストパーティページによると、同社がマージするプルリクエストの30%超は、クラウドサンドボックスで動く自律型エージェントが作成しています。試行されたタスクではなく、マージ済みのプルリクエストを測っているため、実運用での採用を示す有用な指標です。

本番シークレットに触れるコードでも、Cursor Cloud Agentsは安全ですか？

5月13日のリリースでは、外向き通信とシークレットのスコープが環境単位になり、ビルドシークレットは実行中のエージェントから分離されました。さらに、バージョン履歴、ロールバック、監査ログも用意されています。Self-Hosted Machinesなら、チェックアウト全体とマシン上の認証情報を自社ワーカー内に保てます。ただし、必要なファイル内容、ツール出力、差分、スクリーンショット、ローカルMCPの結果はCursorへ送られる可能性があります。安全性を判断するには、両方の境界を承認できるか確認する必要があります。

Cloudflare WorkersとCursor Cloud Agentsは併用できますか？

はい。CursorはCloudflareをSelf-Hosted Machinesの連携先として挙げており、リファレンステンプレートではCloudflare Workerをコントローラーに使い、処理対象のリクエストを1件取得するごとにCloudflare Containerを1つ起動します。コーディングエージェントのループはCursorに任せ、永続的なアプリケーション状態とオーケストレーションはWorkers、Durable Objects、Workflowsで扱えます。両製品はツール実行の領域では重なるようになりましたが、エージェントループの境界は一致していません。