Cursor の変更点

• ツールの実行が企業マシン上に: ファイルの読み書き、ターミナルコマンドの実行、ブラウザ操作、ローカル MCP の呼び出しが対象です。
• エージェントの制御は Cursor クラウドが継続: タスクの理解、ステップの計画、モデル推論、セッション状態、ツール呼び出しは、企業のイントラネットには移行されません。

Cursor のエージェントシステム全体が企業内にデプロイされるわけではありません。クラウド上のエージェントが、企業管理下の実行環境を使用するという構成です。

Cursor クラウド制御面

タスクの理解と次のステップの決定を担当

• エージェントループとセッション状態
• モデル推論とプランニング
• インターフェース、タスク管理、結果表示

指示 ⇄ 結果

企業ネットワーク内の実行面

ローカルツールの実行を担当

• 完全なチェックアウト、ビルドキャッシュ、ローカル認証情報
• ファイル、ターミナル、ブラウザ、ローカル MCP
• Mac、GPU、社内サービス、既存のパイプライン

接続はワーカーから外部へ能動的に確立されます。受信ポートは不要です。ファイル内容、ターミナル出力、差分、スクリーンショット、ローカル MCP の結果は、タスクの必要性に応じて送信される可能性があります。

Cursor は、社内で統合された PR のうち 60% 以上がクラウド上のエージェントによって作成されたと述べています。ただし、これは Cursor による自己申告であり、他の企業の生産性を推測するために使用することはできません。

Self-Hosted Machines の仕組み

システムは主に三つの要素で構成されます。

• Cursor クラウド: 推論と計画を実行し、ツール呼び出しを送信します。
• ローカル worker: リポジトリの作業コピーを保持し、ローカルでツール呼び出しを実行します。
• HTTPS アウトバウンド接続: worker が Cursor に能動的に接続して結果を送り返します。企業側でインバウンドポートを開放する必要はなく、パブリック IP や VPN も不要です。

Cursor CLI をインストールして worker を起動します。

agent worker start

タスクの実行プロセスは次のとおりです。Cursor がツール呼び出しを送信し、worker がローカルで実行して結果を返し、Cursor が次のステップを決定します。

タスクの開始方法は変わりません。チームはこれまで通り、Cursor デスクトップアプリ、cursor.com、モバイルアプリ、Slack、GitHub、Linear から Cloud Agents を起動および管理できます。

worker がエージェントのセッションを維持するには、api2.cursor.sh と api2direct.cursor.sh へのアクセスが必要です。また、スクリーンショット、ビデオ、ログなどの Cloud Agent の成果物をアップロードするには、cloud-agent-artifacts.s3.us-east-1.amazonaws.com へのアクセスも必要です。三つ目のドメインをブロックすると成果物のアップロードは無効になりますが、ツール呼び出しと結果の送信は継続できます。

完全なチェックアウト、ビルドキャッシュ、マシンローカルの認証情報は企業マシン上に保持できます。タスク実行時には、推論に必要なファイルの内容、ターミナル出力、diff、スクリーンショット、ローカル MCP の結果、ルーティングメタデータが Cursor に送信されます。デスクトップ共有が有効な場合は、デスクトップ画面も転送されます。

セルフホストマシンを利用する理由

セルフホスティングは、主に三つの制約を解決します。

1. 実行環境に関するポリシー制約: 完全なチェックアウト、ツールの実行、ビルド成果物が、企業のアカウントまたは指定されたネットワーク内に存在する必要がある場合。
2. 内部システムへのアクセスが必要なタスク: プライベートなコードリポジトリ、パッケージリポジトリ、テストクラスタ、データベース、業務サービスなどに、Cursor のホスト環境から安全にアクセスできない場合。
3. 専用ハードウェアや既存環境に依存するタスク: 例えば、iOS/macOS ビルドに Apple Silicon Mac が必要な場合や、モデルやグラフィックスタスクに GPU が必要な場合。また、ビルドが永続ディスク、カスタムシステム、Kubernetes に依存する場合もあります。

これらの制約がない場合は、Cursor のホスト環境の方が一般的には簡単です。Cursor が仮想マシンの分離、ネットワーク制御、容量を管理するため、チーム側で worker インフラストラクチャを維持する必要がありません。

主な機能と技術的な特徴

Self-Hosted Machines には、二種類のマシン整理方法があります。

• My Machines: 個人のノートPC、開発機、単体の仮想マシンを接続します。個人のタスクに適しています。
• Team Pools: サービスアカウント、統一イメージ、名前付きリソースプールを使用して、チームに共有容量を提供します。ユーザーはリソースプールを選択するだけで、特定のマシンやリポジトリを指定する必要はありません。

Team Pool に空き worker がある場合、その worker がリクエストを引き受けます。空き容量がない場合、リクエストは待機キューに入ります。チームが運用するコントローラーがキューを監視し、チームが提供する spawn スクリプトを呼び出して、仮想マシン、コンテナ、サンドボックスを起動します。

• タスク終了時: worker はプールにリセットするか、スナップショットを保存してスリープ状態にすることができます。再接続ウィンドウ内に後続のメッセージが届いた場合は、同じ ID で復元できるため、アイドル状態の実行コストやワークスペースの再構築にかかる待ち時間を削減できます。
• リソースプールのグループ化: オペレーティングシステム、ハードウェア、ネットワーク範囲、セキュリティレベルごとにプールを分けることができ、単一のリポジトリに紐付ける必要はありません。

• デプロイ方法: エンタープライズサーバー、永続ホスト、Docker、Kubernetes、および AWS Lambda、Cloudflare、Coder、Daytona、E2B、Modal、Namespace、Vercel などのプラットフォームに対応しています。公式インテグレーションが接続方法を提供しますが、実際のイメージ、シークレット、分離、スケーリング、本番環境での検証はチームの責任で行われます。
• Computer use: Linux と Mac に Chrome や Chromium などのデスクトップ依存関係をインストールすると、ブラウザの制御、会社の SSO セッションの利用、社内サイトの操作、Mac での Xcode ビルドが可能になります。ユーザーはデスクトップをリアルタイムで表示し、操作を引き継ぐこともできます。
• 現在の制限: Cursor のドキュメントによると、現在のところ、ユーザーあたり最大200の worker、チームあたり最大1000の worker を接続できます。それ以上の規模が必要な場合は、Cursor への問い合わせが必要です。また、Team Pools を利用するには、Enterprise プラン、サービスアカウントの API キーが必須で、管理者による関連設定の有効化も必要です。

得られるものと、引き受けるべきもの

セルフホスティングにより、Cloud Agents は企業がすでに保有するコード、イントラネット、キャッシュ、ビルドチェーン、テストサービス、Mac、GPU、デスクトップ環境を直接利用できます。その一方で、企業はマシン、ネットワーク、権限、容量、コストの管理を引き受けることになります。

採用前に、次の三点を確認してください。

• 企業環境に留めておく必要があるアセットはどれか。
• Cursor に送信してもよいタスク内容はどれか。
• worker に必要なローカル権限は何か。