Cursorの自前実行がチーム運用へ。待機VMを減らせるプール方式に

Cursor Self-hosted machines は、CursorのAIエージェント実行を自社ネットワーク内に寄せ、Team poolsで複数ワーカーを管理しやすくする更新です。

📖 この記事で分かること

• CursorのSelf-hosted machinesで何が変わったか
• Team poolsと休止復帰が効く場面
• Linux/Macのcomputer use対応の意味
• 導入前に確認したい運用ポイント

💡 知っておきたい用語

• Self-hosted machines: Cursorのエージェント実行を自社ネットワーク内のマシンで動かす仕組み
• Team pools: チーム用に用意した複数ワーカーへ作業を割り当てる待ち行列

最終更新日: 2026年9月3日

▶ 公式ページ

• Self-hosted machines(Cursor Changelog)
• Self-hosted integrations(Cursor Docs)

CursorのSelf-hosted machinesとは

この記事のポイント

• Cursorは2026年9月2日にSelf-hosted machinesの更新を公開しました(2026年9月時点)。
• Team poolsで複数ワーカーをキュー化し、空きマシンが作業を受け取れるようになります。
• 自社ネットワーク内で実行したいチームは、接続方式と休止復帰の設計確認が先です。

Cursorは、クラウドエージェントの実行先を自社ネットワーク内に置ける「Self-hosted machines」の更新を公開しました。公式説明では、コードベース、ビルド成果物、シークレットを社内インフラ上に残したまま、エージェントのツール実行をローカルで扱えるとされています。

今回のポイントは、単に「自前の1台で動く」だけではありません。Self-hosted machinesでは、個人向けのMy Machinesに加えて、チームやエンタープライズ向けのTeam poolsが説明されています。複数のワーカーを名前付きのプールにまとめ、リポジトリに固定せず、空いているワーカーがリクエストを処理する形です。

Team poolsで待機コストを下げやすくなる

Team poolsは、AIエージェントをチームで使うときの「実行待ち」と「容量管理」に効く更新です。公式ページでは、リクエストが増えれば利用可能なワーカーが作業を受け取り、ワーカーが切断されれば容量が縮む、と説明されています。さらに、アイドル状態のマシンを休止し、後続のリクエストが来たときに再接続ウィンドウ内で復帰させる考え方も示されています。

この設計は、常に高性能なVMを温め続ける運用と相性が悪いチームに向きます。AIエージェントの実行は、短時間に集中することもあれば、レビュー待ちで間が空くこともあります。休止復帰が安定して使えるなら、次のプロンプトのためだけに高コストな実行環境を待機させる必要を減らせます。

Linux/Macのcomputer useにも対応

もう一つの実務的な変更は、Self-hosted workersがLinuxとMacでcomputer useをサポートする点です。公式説明では、必要なデスクトップパッケージを用意すれば、エージェントがクリック、入力、スクリーンショット取得、ブラウザ操作を行えるとされています。ユーザーはそのデスクトップを見たり、Cursorから制御を引き継いだりできます。

Cursorは、AWS Lambda、Coder、Cloudflare、Daytona、Modal、Namespace、Vercel、E2Bなど、既存の開発用インフラ上でクラウドエージェントを実行できる導線も案内しています。つまり、今回の更新は「Cursorのクラウド上で動くエージェント」から、「自社が管理する実行環境へ寄せるエージェント」への選択肢を広げるものです。

ただし、導入前にはネットワーク到達性、シークレットの渡し方、監査ログ、ワーカーの権限範囲を決める必要があります。自社内で動くから安全、ではなく、自社内で動くからこそ既存の権限設計にそのまま触れます。

編集部の見方

編集部は、今回の更新でいちばん大きいのは「AIエージェントの実行環境を、開発組織の既存統制に寄せられること」だと見る。

根拠は3つあります。第一に、Cursorはコードベース、ビルド成果物、シークレットを内部マシンに残せると説明しています。第二に、Team poolsでチーム用ワーカーをキュー化できるため、個人の1台運用よりも実運用に近い容量管理ができます。第三に、Linux/Macのcomputer use対応により、ブラウザやGUIを含む確認作業を自社環境側で実行しやすくなります。

この見方が変わる条件は、休止復帰やプール割り当ての失敗時に、復旧手順や監査情報が十分に見えない場合です。便利さよりも、止まったときに誰が何を確認できるかが、企業利用では採用判断を左右します。

よくある質問

Q: Self-hosted machinesは何のための機能ですか？

A: Cursorのエージェント実行を、自社ネットワーク内のマシンや既存インフラへ寄せるための機能です。コードや成果物、シークレットを外部の実行環境に置きにくいチームで検討しやすくなります。

Q: Team poolsは個人利用にも必要ですか？

A: 個人の1台運用ならMy Machinesで足りるケースがあります。Team poolsは、複数人・複数ワーカー・変動する実行容量を扱うチーム向けの仕組みです。

Q: すぐ本番開発に入れてよいですか？

A: 先に権限範囲、ログ、ネットワーク、休止復帰時の挙動を検証するのが安全です。特にシークレットへ触れるワーカーは、通常のCI/CDと同じ水準で管理する必要があります。

まとめ

CursorのSelf-hosted machines更新は、AIエージェントを「自社の外で動く便利な補助役」から「自社の管理下で動く実行基盤」へ近づけるものです。Team poolsとLinux/Macのcomputer use対応により、チーム運用の現実に合わせやすくなりました。導入するなら、便利さより先に、権限と監査の設計を確認するのがよさそうです。

【用語解説】

• ワーカー: エージェントの指示を受けて、コード実行やツール操作を行うマシンやプロセス。
• 休止復帰: 使っていないマシンを止め、必要になったときに再開する仕組み。
• computer use: AIエージェントが画面を見て、クリックや入力などの操作を行う機能。

引用元:

• [1] Self-hosted machines(Cursor Changelog)
• [2] Self-hosted integrations(Cursor Docs)

この記事について: AI 支援で執筆、編集部が事実確認・編集しています。誤りや追加情報があれば Contact よりお知らせください。