Cursorが「セルフホストマシン」に対応、自社ネットワーク内でのツール実行や画面操作が可能に
要点
- AIコードエディタ「Cursor」が、ツール実行環境をユーザー自身のネットワーク内で運用できる「セルフホストマシン（Self-hosted machines）」のサポートを発表した。
- ソースコードやビルド成果物、シークレット情報を社内インフラに留めたまま、エージェントによるツール処理を安全に実行できる。
- 個人向けの「My Machines」に加え、需要に応じた自動伸縮やマシンの休止が可能なチーム向け機能「Team pools」を提供する。
- AWS LambdaやVercelなど主要な外部サンドボックス環境に対応するほか、LinuxおよびMac上での「Computer use（画面操作）」もサポートする。
AIコードエディタを提供するCursorは2026年9月2日、公式Changelog（更新履歴）を公開し、ユーザーが管理するインフラ上でツール実行を完結させられる「セルフホストマシン（Self-hosted machines）」機能の提供を開始したと発表した。
今回の機能追加により、エージェントによるツール呼び出しが手元や社内のネットワーク内で直接処理されるようになり、外部環境に機密情報を送信することなくCursorの高度な自動化機能を利用できるようになるという。
社内インフラで処理を完結させるセキュリティ基盤
セルフホストマシンは、AIエージェントが実行するコマンドやスクリプトなどのツール処理を、すべてユーザー自身のネットワーク内部で動作させる仕組みだ。
従来のようなクラウド側での処理とは異なり、開発対象のコードベース、ビルドによって生成された成果物、各種アクセスキーや環境変数といったシークレット情報が、社内インフラ上で稼働するマシン内部に保持される。エージェントはツール呼び出し（Tool calls）をローカル環境で直接ハンドリングするため、厳格なセキュリティ要件が求められる企業やプロジェクトでも安全に導入できると説明している。
個人の作業環境からチーム向けの動的プール管理まで対応
接続形態としては、個人の用途とチームや組織での利用のそれぞれに向けた機能が用意されている。
個人向け機能の「My Machines」では、1台のノートPCや仮想マシン（VM）を個人のアカウントに直接紐付け、個々の作業フローに合わせて利用できる。
一方、組織やエンタープライズ向けには「Team pools」と呼ばれるワーカーキューの仕組みが提供される。Team poolsでは名前を付けたワーカー群をプールとして管理し、以下のような柔軟なリソース制御が可能となっている。
- 需要に応じたスケーリング: リクエストの増加に合わせてワーカーの処理能力を拡大し、ワーカーが切断されれば縮小する動的なキャパシティ調整に対応する。
- リポジトリ非依存の設計: プールは特定のリポジトリに固定されておらず、プール名を指定するだけで空いている任意のワーカーが即座にリクエストを処理できる。
- アイドル時のハイバネーション（休止）: 使用されていないマシンを一時的に休止させ、フォローアップのリクエストが届いた際には再接続ウィンドウ（Reconnect window）内で速やかに復帰させる。次の指示を待つ間だけのために高価な計算リソースを常時稼働（ウォーム状態）させておく無駄を防ぐ仕組みだという。
既存のサンドボックス基盤との連携
Cursorのクラウドエージェントは、開発者がすでに利用している各種クラウドサービスやサンドボックス環境上でも実行可能になった。
対応する連携先として、AWS Lambda、Coder、Cloudflare、Daytona、Modal、Namespace、Vercel、E2Bの各プラットフォームが挙げられている。既存のインフラ資産や使い慣れた開発基盤をそのままエージェントの実行環境として流用できる構成となっている。
Linux・Mac上での「Computer use」とリモート制御
さらに、セルフホストされたワーカー環境において、GUIを自動操作する「Computer use」機能がLinuxおよびMac向けにサポートされた。
適切なデスクトップ関連パッケージを導入することで、エージェントが自律的にマウスクリックやキーボード入力、画面のスクリーンショット撮影、Webブラウザの操作を実行できるようになる。作業中の様子はCursorのエディタ上からデスクトップ画面としてリアルタイムに監視できるほか、必要に応じてユーザーがCursor側から直接操作を引き継ぐことも可能だとしている。