Cursor、自社インフラでクラウド型AIを実行できる「Self-Hosted Machines」を発表

要点

• AIコードエディタを提供するCursorは、クラウド型AIエージェントの実行環境をユーザー自身の管理下にあるインフラへ配置できる新機能「Self-Hosted Machines」を発表した。

• エージェントの推論や計画立案はCursorクラウドで行い、ファイルの編集やコマンド実行といったツール処理のみをローカル環境や社内ネットワークに切り離す構造を採用している。

• 社内閉域網にあるソースコードや独自サービスへの直接アクセスが可能になるほか、GPUやiOS開発用のMacなど任意のカスタムハードウェア上でエージェントを動かせる。

• ユーザー環境のワーカーからCursorクラウドへ外向きHTTPS接続を確立する仕組みを採用しており、外部から社内ネットワークへのインバウンド接続を一切要求しない。

• 個人向けの「My Machines」と組織向けの自動スケール対応キュー「Pools」が提供され、AWS LambdaやVercelのサンドボックス基盤とも連携する。

• AIコードエディタを手がけるCursorは2026年9月2日（現地時間）、自社のクラウド型AIエージェントをユーザー管理下のインフラ上で稼働させられる新機能「Self-Hosted Machines」を発表した。エージェントの思考プロセスや推論処理はCursorのクラウド基盤を維持したまま、実際のコード編集やコマンド実行を行う環境のみをユーザーのプライベートネットワークや独自クラウドへ移管できる。これにより、セキュリティ上の制約や特殊なハードウェア要件を持つ開発チームでも、安全にクラウドエージェントを活用できるようになるという。

実行環境のみを手元に移すハイブリッド構造

Cursorのクラウドエージェント（クラウド上で自律的にコード生成や修正を行うAIシステム）は、これまでCursor側のクラウド内にある専用仮想マシン（VM）で実行される形態が標準だった。専用VMによる個別隔離や送信制御、シークレット情報のマスキング、署名付きコミットなどの保護機能が提供されているが、企業のセキュリティポリシーやインフラ構成によっては追加の要件が求められるケースがあった。

今回発表された「Self-Hosted Machines」は、エージェントの実行環境をユーザー管理下のマシンへと切り替える機能だ。具体的には、以下のような要件を持つチームを対象としている。

• ソースコード管理システムや社内リポジトリ、内部マイクロサービスへの直接アクセスが必要な場合
• 機械学習用のGPUやiOS開発に必要なMac環境、Kubernetesクラスタ、管理対象VMなど特定のハードウェアや基盤を要する場合
• 既存のOS構成やビルドパイプラインが複雑で、Cursor標準のクラウド環境向けにパッケージ化することが困難な場合

本機能では、エージェントの思考ループ、モデル推論、作業計画の策定は引き続きCursorのクラウド上で処理される。ツール実行の結果（コードを含む場合がある）は推論のためにCursor側へ送信され、エージェントの実行履歴（トランスクリプト）もCursor側で処理・保存される場合がある。ユーザーは従来の環境と同様に、デスクトップアプリをはじめ、Web（cursor.com）、モバイル、Slack、GitHub、Linearからエージェントを呼び出して利用できる。

インバウンド通信を排除したワーカー接続と2つの構成モード

Self-Hosted Machinesを導入する際、実際のコード配置、ファイル編集、コマンド実行はユーザー側のマシンが担当する。このマシンとCursorのクラウド基盤を橋渡しするのが「Worker（ワーカー）」と呼ばれる中継プロセスだ。

セットアップは、対象マシンにCursor CLIを導入し、コマンド agent worker start を実行することで完了する。ワーカーはCursorクラウドに向けて外向き（アウトバウンド）の長寿命HTTPS接続を確立する。エージェントが作業を開始すると、Cursor側からワーカーへツールの実行指示が送られ、ワーカーが手元で実行した結果をクラウドへ返却して次の推論へと進める。Cursor側からユーザーネットワークへ直接通信を仕掛けるインバウンド接続（外部ネットワークから内部に向けて確立される通信）は発生しないため、社内ファイアウォールの設定変更を最小限に抑えられるとしている。

利用形態としては、利用規模や目的に応じた2つの構成モードが用意されている。

1. My Machines: 単一のノートPCや仮想マシンを個人のアカウントに紐付けるモード。個人のローカル開発ワークフローに適している。
2. Pools: チームや組織全体で共有するワーカーキュー。開発者からのリクエスト増減に合わせてキャパシティを柔軟に増減できる。

需要に応じた自動スケーリングと休止状態からの高速復帰

チーム向け構成の「Pools」では、バースト的に発生しやすいエージェントへの要求に対して、プール内のリソースが自動調整される。チームが設定した起動スクリプト（スポーンスクリプト）とリクエストキューを監視するコントローラーが連動し、負荷に応じてマシンをオンデマンドで立ち上げる仕組みだ。

プール内に空きワーカーが存在する場合は即座にリクエストが割り当てられ、空きがない場合は新たなマシンが起動するか既存の処理が終わるまでキュー内で待機する。これにより、管理者は常に大量のマシンを待機させておくコストを抱えずに済む。

また、ワーカー接続にはアイドル状態のタイムアウト時間を設定できる。指定時間を経過したマシンは初期化されてプールへ再投入されるほか、後続の指示に備えて作業ディレクトリを保持することも可能だ。マシンの稼働を継続するとコストが嵩む一方で、マシンを完全に破棄すると再開時に作業環境の再構築に時間がかかるという課題に対し、スナップショットを活用したハイバネーション（作業状態を一時保存して休止し、後から即座に復元する機能）を活用できる設計となっている。

クラウド基盤との連携とプラットフォームの拡充

今回の機能拡張に合わせ、主要なクラウドサービスやサンドボックス基盤との連携および機能強化も案内された。

AWS LambdaのMicroVMをコンピュート層として活用する場合、スナップショットからの即座な立ち上げやアイドル時のサスペンド、状態を保持したままの高速再開が可能となり、フリート管理不要で独自のAWSアカウント内でエージェントを動かせると説明されている。また、Vercel Sandboxとの連携により、リクエストごとに隔離されたサンドボックスをオンデマンドで立ち上げる構成にも対応した。

さらに、これまでMac向けに提供されていた「Computer Use」（AIが画面操作や入力を自律的に行う機能）について、新たにLinux環境への対応が追加されたことも併せて公表されている。

Cursorによると、同社の社内開発においてはマージされるPull Requestの60%以上がクラウドエージェントによって作成されており、大規模エンタープライズ顧客での利用も急速に拡大しているという。実行インフラをユーザー自身が柔軟に選択・管理できる手段を提供することで、多様な開発要件に対応していく構えだ。