Cursor Cloud Agents を自社の Cloudflare 上で動かせるように — 推論は Cursor、実行は自分のインフラ

要約

2026-09-02、Cloudflare が Cursor Cloud Agents を「self-hosted machines」として Cloudflare 上で実行できるようになったと発表しました。

この発表の面白さは、責務の分け方が明示されている点にあります。

Cursor 側が担うのは、エージェントループ、推論、計画。

Cloudflare 側が担うのは、コマンドの実行、ファイル編集、リポジトリ操作、その他のツール実行——それを**「自分が管理するインフラの内側で」**動かします。

つまり「考えるのは Cursor、手を動かすのは自分のところ」という分業です。

各セッションは、Cloudflare Containers による独立した隔離環境で動きます。セッション同士が互いに影響しない構成です。

統合を担うのが Sandbox SDK で、セットアップ用にオープンソースの Cloudflare Workers テンプレートが用意されています。テンプレートをデプロイすると、Worker、Durable Object の namespace、コンテナアプリケーション、R2 バケットのバインディング、cron トリガーが一式構成されます。手順は公式チュートリアル「Run Cursor Cloud Agents on Cloudflare via self-hosted machines」にあります。

価格と一般提供の時期については、この発表には記載がありません。

何が変わったか

• Cursor Cloud Agents を Cloudflare 上の self-hosted machines として実行できるようになった
• 責務分担: Cursor = エージェントループ・推論・計画 / Cloudflare = コマンド実行・ファイル編集・リポジトリ操作などのツール実行
• ツール実行は利用者が管理するインフラの内側で動く
• セッションごとに Cloudflare Containers による隔離環境
• 統合は Sandbox SDK が担当
• オープンソースの Workers テンプレートをデプロイすると、Worker / Durable Object namespace / コンテナアプリ / R2 バインディング / cron トリガーが構成される
• 価格・一般提供時期の記載なし

業務インパクト（一般企業向け）

「Cursor を使いたいが、コードが外に出るのが承認されない」——この壁に当たっていた組織には、直接効く発表です。

ただし、何が解決して何が解決しないのかを、正確に切り分ける必要があります。

解決するのは、実行環境の所在です。 コマンドを実行し、ファイルを編集し、リポジトリを操作する——これらが動く場所が、自社が管理する Cloudflare 環境になります。 実行時に触れるファイル群、生成される中間成果物、コマンドの出力。これらが自社の境界の中に留まります。

解決しないのは、推論そのものです。 エージェントループ、推論、計画は Cursor 側にあります。 推論のためにコードの内容が Cursor へ送られる構造は変わりません。

この区別は、社内説明で必ず問われます。 曖昧にしたまま「自社環境で動くので安全です」と説明すると、後でひっくり返ります。「実行は内側、推論は外側」と最初から言い切る方が、結果的に通ります。

そのうえで、実行環境が内側にあることの価値は実際に大きい。

エージェントが動くとき、何が起きるかを考えてください。 依存パッケージをインストールする。ビルドを走らせる。テストを実行する。そのプロセスは、環境変数、認証情報、内部ネットワークへの到達性を持ちます。

この部分がベンダー側の環境にあると、統制の範囲外になります。 監査ログをどう取るか、ネットワークをどう絞るか、資格情報をどう渡すか——すべて相手の仕様に従うことになる。

自社の Cloudflare 環境にあれば、これらは自分の設計になります。 Workers の設定、コンテナの構成、R2 の権限、ネットワークの制限。既に持っている統制の仕組みを、そのまま適用できる。

導入の判断で見るべき点を挙げます。

まず、Cloudflare を既に使っているかどうか。 テンプレートは Worker、Durable Object、Containers、R2、cron を一式構成します。Cloudflare の運用経験がない組織にとっては、Cursor の導入と Cloudflare の導入を同時にやることになります。 これは決して軽くありません。

次に、コストの見通しが立たないこと。 価格の記載がありません。 Containers と Workers と R2 の従量課金は発生します。エージェントのセッション数と実行時間に比例する構造になるはずですが、実測しないと月額が読めません。 小さく始めて測る以外に方法がない段階です。

そして、一般提供の位置づけが不明なこと。 発表には GA かプレビューかの明示がありません。本番の開発フローを丸ごと乗せる前に、この点は確認すべきです。

もう一つ、この発表を業界の流れとして読む視点があります。

Cursor は 2026-08-28 に SpaceX による買収が報じられ、OpenAI がモデル提供契約の終了方針を出しています。 その状況で、実行基盤の選択肢が Cloudflare 側に増えたという事実は、Cursor を評価している組織にとって情報の一つになります。

ただし、これを過剰に読むべきではありません。 実行基盤の話であって、モデル供給の話ではありません。 Cursor の推論がどのモデルで動くかという問題は、この発表では何も変わっていません。

副業・個人活用視点

個人開発者にとって、この発表は「今すぐ使うもの」ではなく「知っておくと案件になるもの」です。

率直に言って、個人で self-hosted machines を組む必然性は薄い。 Cursor の Cloud Agents をそのまま使えば済みます。Worker、Durable Object、Containers、R2、cron を構成して運用する手間に、個人の規模では見合いません。

価値があるのは、この構成を「説明できる」ことです。

受託や技術顧問の場面で、「Cursor を入れたいが情報統制で止まっている」という相談は現実にあります。 そのとき、「実行環境だけ自社側に持ってくる構成があります」と即答できるかどうかは、差になります。

さらに一段、正確に説明できると強い。 「推論は外に出ます。出ないのは実行環境です」——この区別を先に言える人は、そう多くありません。できないことを先に言う方が、信用されます。

構築案件としても、輪郭がはっきりしています。

Workers テンプレートをデプロイし、ネットワークと権限を絞り、監査ログの取得先を決め、コストを実測して報告する。 これは工数を見積もれる作業です。 「AI 導入支援」のような曖昧な括りではなく、成果物が明確な仕事になります。

そして、Cloudflare 側のスキルが横に効きます。

Workers、Durable Objects、Containers、R2、cron トリガー。 この組み合わせは、エージェント実行基盤に限らず、非同期処理やジョブ実行の設計でそのまま使える構成です。今回のテンプレートは、その構成の実例として読む価値があります。

学習素材として見るなら、ここがいちばんおいしい部分かもしれません。 「エージェントの実行環境を隔離して動かす」という要求に対して、Cloudflare のどの部品をどう組み合わせるか——その答えが、動くテンプレートとして公開されています。

自分で似たものを作るとき、部品の選び方に迷わなくなります。 セッション単位の隔離に Containers、状態管理に Durable Objects、成果物の保管に R2、定期処理に cron。この対応関係を一度読んでおくと、次に自分の設計をするときの土台になります。

最後に一点、注意を。 価格が非公表で、GA かどうかも明示されていません。 クライアントへ提案するなら、「まず小規模に測ってから判断しましょう」という前提を必ず添えてください。 未確定の部分を確定したように話すのが、いちばん危ない進め方です。