Cursor セルフホストの実像：ツール実行を社内ネットワークへ

Cursorが2026年9月2日に発表したCursor セルフホストの変更により、セキュリティ境界だけでなく、インフラ費用の負担先も変わります。エージェントによるツール実行は自社管理のマシン内に置けるようになりますが、そのワーカーの運用も自社の責任になります。一方、モデル、プランニング、エージェントループは引き続きCursorのクラウド上で動きます。

Cursor セルフホストは実行環境を二分する

Cursor Cloud Agentは2つの要素で構成されます。エージェントループは、次に何をするかを判断してモデルを呼び出す部分です。ツール実行は、ファイル編集、ターミナルコマンドの実行、ブラウザ操作、ローカルMCPサーバーとの通信、社内サービスへのアクセスを担います。

Cursor Self-Hosted Machinesは、この2つを分離します。ループ、推論、プランニング、インターフェース、セッションのオーケストレーションはCursorが引き続き担当し、ツールだけを自社管理のワーカーで実行します。

ワーカーには、ノートPC、VM、Mac、Kubernetes Pod、連携パートナーが提供するサンドボックスを利用できます。ワーカーからCursorへ外向きのHTTPS接続を確立し、ツール呼び出しを受け取ってローカルで実行した後、その結果を返す仕組みです。ワーカー側で受信用ポートやパブリックIPを用意する必要はありません。

役割分担は次のとおりです。

Cursorが用意するワーカー形態は2つです。My Machinesは1台のマシンを個人アカウントに紐づけるもので、開発用マシンや限定的な個人ワークフローに向いています。Team PoolsはEnterpriseチーム向けの名前付きキューです。空いているワーカーが取得するまでリクエストはプール内で待機し、各プールワーカーが同時に処理できるCloud Agentセッションは1つです。

これはCursorのモデルをオンプレミスで動かす機能ではありません。顧客が実行部分を所有する分割型ランタイムです。この違いを正しく理解することが、自社ポリシーへの適合性を判断する前提になります。

社内に残るデータと、外部へ送られるデータ

完全なチェックアウト、ビルドキャッシュ、マシン内の認証情報はワーカーに保持されます。コマンド、リポジトリ操作、ビルド、社内サービスの呼び出しもそこで行われます。そのため、リポジトリ全体をベンダー管理の実行VMへコピーせずに済む可能性があります。

ただし、エージェントが判断するにはコンテキストが必要です。実行中、ワーカーからCursorへ、エージェントが必要とするファイル内容、ターミナル出力、差分、スクリーンショット、ローカルMCPの結果、ルーティング用メタデータが送られます。スクリーンショット、動画、ログへの参照がCursor管理のアーティファクトストレージにアップロードされ、プルリクエストやダッシュボードに表示されることもあります。

アーティファクト用ホストへの通信を遮断してもエージェントは停止しませんが、それらのアーティファクトはプルリクエストやダッシュボードに表示されなくなります。Privacy Modeも適用されるため、ワーカーから送信されたコードがCursorやそのモデルプロバイダーの学習に使われることはありません。ただし、セッションがオフラインになるわけではありません。

ここから得られる最初の事業上の意味は明確です。セキュリティ審査では、実行場所とモデル処理を分けて承認できるようになりますが、どちらの審査も必要です。

どのチームに向き、何が変わるのか

社内サービスを使うEnterpriseのバックエンドチーム

バックエンドチームでは、プライベートなパッケージレジストリ、ステージングデータベース、マネージドVMから到達できないサービスエンドポイントが必要になる場合があります。同じ管理ネットワークにTeam Poolを置けば、Cursorから内向きの経路を開放せずにビルドを実行できます。

得られるのはアクセス制御であり、プライバシーが自動的に保証されるわけではありません。プラットフォームチームは既存のネットワークポリシーとシークレットストアを利用でき、セキュリティチームは外向き接続を越える結果を具体的に審査できます。

Macが必須のiOSチーム

Cursor管理のCloud AgentはUbuntu VM上で動きます。iOS開発にMacハードウェアが必要なチームは、Macをワーカーとして登録し、必要なコンピューター操作権限を与えることで、エージェントにクリック、入力、スクリーンショット撮影、ブラウザ操作を実行させられます。

リモートエージェントがビルドと同じ種類のハードウェアを使える点が利点です。一方、Macのビルドフリートを運用する際と同じく、イメージのばらつき、権限、稼働率、クリーンアップ、交換は自社で担います。

エージェント需要の変動が大きいプラットフォームチーム

プラットフォームチームは、Team Poolの背後にCloudflare Containersを配置できます。リファレンステンプレートは、取得したセッションごとに隔離コンテナを1つ起動し、Durable Objectでそのコンテナを管理します。リポジトリのスナップショットをR2にキャッシュすることも可能です。

ワーカーが1台も接続されていなくてもプールは維持されるため、キャパシティをゼロまで縮小できます。再び作業が入ると、コントローラーがリクエストを取得してコンテナを起動します。常時起動のフリートを抱えず、利用量に沿ってコンピュートを増減できるのが利点です。

状態を保持した開発マシンを使う個人開発者

My Machinesは、再現に手間がかかるローカルツールや状態に依存するプロジェクトに適しています。1台のマシンを複数のエージェントで共有できるため個人用途には便利ですが、機密性の高い作業では注意が必要です。

利点はセットアップの速さです。反面、CursorがセッションごとにノートPCを消去して再構築するわけではないため、前回の実行状態が残るリスクがあります。作業ディレクトリ、認証情報、プロセスのクリーンアップ、マシンの健全性は利用者が管理します。

実際に動かせるCloudflare構成

Cloudflareを使う構成は、新しい責任分界を具体的に確認できる点で有用です。必要なのは、Cursor Enterprise、エージェント権限を持つチーム用サービスアカウントキー、ContainersとR2が利用できるCloudflare Workers Paidアカウント、Node.js 20以降、Dockerです。

1. 1

   Team Poolを登録する

   Cursor CLIをインストールして動作を確認したら、一時的なローカルワーカーを接続し、Cursor上にプールを作成します。

   curl https://cursor.com/install -fsS | bash
   agent --version
   export CURSOR_API_KEY="<team service-account API key>"
   CURSOR_API_KEY="$CURSOR_API_KEY" agent worker --pool cloudflare-test start

   プールが表示されたらCtrl+Cでワーカーを停止し、続けてunset CURSOR_API_KEYを実行します。Cloudflareのテスト中はローカルワーカーを停止したままにし、先にリクエストを取得しないようにしてください。

2. 2

   Cursorのリファレンステンプレートをデプロイする

   テンプレートをクローンして依存関係をインストールし、Cloudflareへサインインして、任意のスナップショット用バケットを作成します。

   git clone https://github.com/anysphere/cloudflare-workers.git
   cd cloudflare-workers
   npm install
   npx wrangler login
   npx wrangler r2 bucket create cursor-pool-worker-snapshots

3. 3

   認証情報を保存する

   CursorのサービスアカウントキーをWorkerのシークレットに保存します。コンテナからプライベートリポジトリへ接続する場合に限り、Gitの認証情報も追加します。

   npx wrangler secret put CURSOR_API_KEY
   npx wrangler secret put GIT_USERNAME
   npx wrangler secret put GIT_TOKEN

   個人用のCursor APIキーはTeam Poolでは利用できません。コントローラーから401が返るため、インフラ障害に見えやすいセットアップミスです。

4. 4

   プールとキャパシティを設定する

   wrangler.jsoncで、CURSOR_POOLをcloudflare-testに変更します。containers[].max_instancesにはチームの開発者数ではなく、同時実行を許容できるセッション数を設定してください。

   リファレンスファイルの初期値はmax_instancesが10、コンテナはstandard-1で、0.5 vCPU、4 GiBメモリ、8 GBディスクです。実際のビルドでは、より大きな構成が必要になる場合があります。

5. 5

   デプロイして最初の実行を監視する

   デプロイ後、Cloud Agentを起動してセルフホストプールを選択する間、コントローラーとコンテナの画面を開いたままにします。

   npx wrangler deploy
   npx wrangler tail
   npx wrangler containers list

   最初のスケジュール済みコントローラーが動き始めるまで、最大5分かかることがあります。セッションを取得できても起動しない場合、コンテナのキャパシティ、リポジトリのクローン、Git認証情報のいずれかに問題があるケースが一般的です。

コストは消えず、負担先が変わる

Cursor管理のCloud Agentには実行インフラが含まれています。Self-Hosted Machinesでも、選択したモデルの利用にはCursorの料金がかかり、さらに自社ワーカーの費用が加わります。Team Poolsには価格が個別見積もりとなるEnterprise契約も必要です。

Cloudflareを例にすると、追加費用の仕組みが分かります。Containersは月額$5のWorkers Paidプラン上で提供されます。このプランには、25 GiB-hoursのメモリ、375 vCPU-minutes、200 GB-hoursのディスクが含まれます。超過分は、メモリが1 GiB秒あたり$0.0000025、アクティブCPUが1 vCPU秒あたり$0.000020、確保済みディスクが1 GB秒あたり$0.00000007です。

リファレンステンプレートのstandard-1を使い、100セッションがそれぞれ1時間稼働し、稼働中は利用可能なCPUをすべて使った後、テンプレートの5分間のアイドル待機を経ると仮定します。プラン内の利用枠を差し引いたコンテナ費用は、月額約$12です。

$5 plan + $3.15 CPU + $3.675 memory + $0.168 disk = $11.993

これはインフラ費用の試算であり、Cursor全体の請求額ではありません。WorkerとDurable Objectの利用料、ログ、外向き通信、R2、Enterprise契約、モデル利用、フリートを保守する人件費は含まれていません。また、最小のテンプレート構成で足りることも前提です。コンパイル負荷の高いリポジトリでは、より大きなコンテナが必要になる可能性があります。

実際に高くつきやすいのは、秒単位の料金ではなく、待機キャパシティの方針です。Cursorの汎用プールワーカーでは再接続ウィンドウの初期値が3,600秒ですが、Cloudflareテンプレートでは300秒に短縮されています。長くすれば後続プロンプトへの応答は速くなりますが、確保したメモリとディスクの課金が続きます。短くすればアイドル費用を抑えられる一方、コールドスタートが増えます。

キャパシティも自社の責任です。テンプレートの初期設定では、10個のコンテナを同時実行できます。設定したキャパシティ、アカウント上限、基盤ホストのいずれかを利用できなければ、次のリクエストは待機するか、起動に失敗します。Cursorはプールへ処理を振り分けられますが、用意していないキャパシティまで作り出すことはできません。

隔離も同じ考え方です。Cloudflareテンプレートでは、セッションごとに専用コンテナが割り当てられます。一方、個人用マシンでは1台のホストで複数のエージェントを実行できます。ポリシー上、実行ごとに新しいVM、消去済みディスク、テナント分離、シークレットのクリーンな境界が必要なら、その仕組みを自社で構築し、検証しなければなりません。

パッチ適用も定常的な運用作業になります。ベースイメージ、Cursor CLI、ビルドツール、証明書、依存関係、ロールアウトはチームの管理対象です。Cloudflareでは新しいコンテナイメージをデプロイすると稼働中のコンテナが停止するため、更新時にはアクティブなセッションが終わるのを待つか、中断を受け入れる必要があります。

今、取るべき対応

Cloud Agentでカスタムハードウェアや独自イメージが必要な場合、またはマネージドネットワークから届かないツールへアクセスする必要がある場合は、今週中に着手する価値があります。まずは対象を限定したプールと、リスクの低いリポジトリから始めます。実行場所を移してもモデル処理と返送されるツールデータは残るため、セキュリティ審査の対象から外してはいけません。

要件がプライベートなソース管理や社内サービスへのアクセスだけなら、導入を急ぐ必要はありません。Cursorはワーカーフリートを自社運用する前に、マネージド環境、ネットワーク制御、Tailscale、AWS PrivateLink、Cloudflare Tunnelを試すよう推奨しています。これらの方法なら、ホストのライフサイクルと隔離はCursor側に残ります。

マネージドCloud Agentがすでにポリシーを満たし、ビルドも再現できている場合は影響ありません。セルフホストでモデルの能力が増えるわけではなく、変わるのは実行場所と運用責任です。

週明けにやるべきことは具体的です。代表的なリポジトリを1つ選び、コード、シークレット、ツール出力、アーティファクトのうち、どれが境界を越えてよいかを書き出します。そのうえで、同じビルドをマネージドエージェントと上限を絞ったセルフホストプールの両方で実行してください。キュー待ち時間、コンテナ稼働時間、採用された変更、クリーンアップ失敗、イメージ保守に費やした時間を記録し、制御上の要件が追加コストに見合う場合にのみフリートを承認します。

実務で使える次のAIワークフロー解説をニュースレターで受け取る。