AIREITERファイアウォールの内側にワーカーを置いても、ソースコードの断片やターミナル出力、差分、スクリーンショットがCursorに送られることはあります。Cursor Self-Hosted Machinesは実行環境を自分で管理する仕組みであり、エージェント全体をセルフホストしたり、Cursorをエアギャップ環境で動かしたりするものではありません。
この記事では、どのデータが境界を越えるのか、各種コントロールで何が変わるのかを、Cursorの2026年9月2日の発表、Self-Hosted Machinesのドキュメント、データ利用ポリシーをもとに確認します。
データ境界を一気に把握する表
Cursorでは、Cloud Agentの処理をCursorのクラウドとユーザー管理のワーカーに分担させます。「Self-Hosted」と呼ばれているのは実行場所であって、すべてのシステムやデータ経路が自社側に移るという意味ではありません。
| データまたはシステム | 実行・保存される場所 | Cursorに届く可能性 | 関係する制御・制限 |
|---|---|---|---|
| エージェントループ、推論、計画 | Cursorのクラウド | もともとCursor側で処理 | Self-Hosted Machinesでは移動しない。 |
| ファイル編集とターミナルコマンド | 自社ワーカー | 結果が返される可能性がある | ツールを実行するのはワーカー。 |
| 完全なチェックアウトとビルドキャッシュ | 自社ワーカー | 本質的には転送されない | 完全な作業コピーはローカルに残る。 |
| マシン上の認証情報 | 自社ワーカー | 本質的には転送されない | コマンド、出力、成果物に秘密情報を含めない。 |
| ファイル内容と差分 | 自社ワーカー、その後エージェントのコンテキスト・結果へ | 必要に応じて送られる | Privacy Modeが対象にするのは学習利用であり、転送そのものではない。 |
| ターミナル出力とローカルMCPの結果 | 自社ワーカー、その後ツール結果へ | 返却時に送られる | 結果にコードや機密データが含まれる可能性がある。 |
| スクリーンショットとデスクトップストリーム | 自社ワーカー、その後生成・共有時にCursorへ | 送られる | Computer-useセッションではエージェントのデスクトップをストリーミングできる。 |
| 動画、スクリーンショット、ログへの参照 | Cursorが管理する成果物ストレージ | デフォルトで送られる | 成果物ホストをブロックすればアップロードを無効化できる。 |
| APIキーを使ったモデルリクエスト | Cursorの処理経路 | 送られる | BYOKでもCursorのバックエンドは迂回できない。 |
重要なのは、リポジトリ全体を自分のマシンに残したままでも、その一部のコンテキストが推論のためにネットワークを越える可能性があるという点です。これは実行場所を部分的にコントロールできる仕組みであり、外部送信が一切ないことを保証するものではありません。
Cursorが実際に自社インフラへ移すもの
Self-Hosted Machinesが自社管理のマシンへ移すのは、ツールの実行です。ワーカー上ではファイル編集、コマンド実行、社内サービスへのアクセス、ブラウザ操作、ローカルMCPサーバーへの接続ができます。一方、エージェントループ、推論、計画、セッションのオーケストレーションはCursorのクラウドに残ります。
ワーカーはCursor CLIのagent worker startコマンドで起動します。その後、Cursorに対して長時間維持される送信方向のHTTPS接続を開きます。Cursorによれば、この接続はワーカーから外向きに確立されるため、受信ポートやパブリックIPアドレス、VPNトンネルは必要ありません。
ドキュメントに記載されているセッションの流れは次のとおりです。
- Cursorの画面でCloud Agentセッションを開始する。
- Cursorのクラウド上にあるエージェントループが次のアクションを計画する。
- Cursorがワーカー接続経由でツール呼び出しを送る。
- ワーカーがコマンド、編集、ブラウザ操作、MCP処理を実行する。
- ワーカーが結果を返し、次の推論ステップに渡す。
ワーカーからはapi2.cursor.shとapi2direct.cursor.shへの外向きアクセスが必要です。CLIの更新や一部のComputer-useセットアップでは、downloads.cursor.comへの接続も必要になる場合があります。外部からネットワークへ入る経路を作らずに済む設計ではありますが、ワーカーがオフラインのモデル実行環境になるわけではありません。
Cursorはこの分離を、プライベートリポジトリやホスト型ワーカーから到達できないサービス、GPUやMacなどの専用ハードウェア、独自のOSやビルドイメージに適した構成として説明しています。要件がプライベート接続だけなら、Cursorのランタイム選択ガイドは、まず許可リスト付きのマネージドCloud Agents、Tailscaleに類するネットワーク、AWS PrivateLink、Cloudflare Tunnelを検討するよう案内しています。
ワーカーの外へ出るデータと、Privacy Modeで変わること
Cursorのドキュメントには、ワーカーが送信する可能性のあるデータとして、ファイル内容、ターミナル出力、差分、スクリーンショット、ローカルMCPの結果、ルーティングメタデータが明記されています。プライバシーを考えるときは、何が転送されるのか、学習に使われるのか、どの程度の期間保持されるのかを分けて考える必要があります。
Privacy Modeは学習制御であり、外部送信を止めるスイッチではない
2026年8月28日に更新されたCursorのData Use & Privacy Overviewによれば、Privacy Modeを有効にすると、Cursorによる顧客データの学習利用が防止されます。また、Cursorはプロバイダーとゼロデータ保持契約を結んでいると説明しています。ただし同じページでは、リスク分類器が調査のためにプロンプトや会話を保持する場合があること、レイテンシーやネットワーク効率のためにファイルが一時的にキャッシュされる場合があることも明記されています。
Cursorの説明では、キャッシュされたファイルはクライアントが生成した鍵で暗号化され、その鍵はリクエスト中、Cursorのサーバー上で保持されます。これは保持方法と保護に関するCursor側の説明であり、リクエストがCursorのサーバーに到達しないことを示すものではありません。
APIキーに関する点も見逃せません。Cursorは、自分のプロバイダーAPIキーを使ってもバックエンドを迂回できないと説明しています。最終的なプロンプト構築のため、リクエストは引き続きCursorを経由するからです。BYOKによってモデル利用の認証主体は変えられても、クライアントからプロバイダーへ直接つながるプライバシー経路になるわけではありません。
このアーキテクチャ上の違いについて、実際のユーザーも次のように指摘しています。
「重要な境界線はここです。Cursorのセルフホスト環境が移すのは実行処理であって、エージェント全体ではありません。Cursorの説明では、推論と計画はクラウドに残り、コードを含む可能性のあるツール出力が返されます。セキュリティレビューでは、これをセルフホストされたエージェントではなく、セルフホストされた実行環境として扱うべきです。」 — @ham_zax、X
成果物の切り替えは、データのエアギャップではない
Cursorには、成果物のアップロードを止めるための限定的な方法があります。cloud-agent-artifacts.s3.us-east-1.amazonaws.comへの外向きHTTPS通信をブロックする方法です。ツール呼び出しとツール結果は引き続き動作しますが、スクリーンショット、動画、ログへの参照はプルリクエストやCursorのダッシュボードに表示されなくなります。
ビジュアル成果物が不要な組織にとっては有効な設定です。ただし、完全なプライバシー対策ではありません。ファイル内容、ターミナル出力、差分、推論中に使われるスクリーンショット、MCPの結果は、エージェントセッションの接続経由で引き続き返される可能性があります。
MCPのトランスポートにも注意が必要です。CursorのTeam Poolsのドキュメントによると、コマンドベース、つまりstdioのMCPサーバーはワーカー上で実行され、プライベートネットワークへアクセスできます。一方、HTTP/SSEのMCPサーバーは、OAuth、セッションキャッシュ、認証のためにCursorのバックエンドで処理されます。プライベートなMCPエンドポイントを評価する際は、ホストの場所だけでなく、通信方式まで確認しなければなりません。
ラベルではなく、要件でランタイムを選ぶ
Cursorには3つのランタイム選択肢があります。実行境界やハードウェア、環境が単なる好みではなく、明文化された要件である場合に、セルフホスティングが適しています。
| ランタイム | ツール呼び出しの実行場所 | 適したケース | 主な責任 |
|---|---|---|---|
| Cursor管理のCloud Agents | Cursorが管理する分離VM | マネージドネットワークと標準的なUbuntuベース環境を利用できる大半のチーム | 環境設定後のVMライフサイクル、キャパシティ、分離、終了処理をCursorが管理する。 |
| My Machines | 個人ユーザーのノートPC、開発用マシン、Mac、VM | 個人のワークフロー、ローカル状態を持つリポジトリ、短時間の概念実証 | 稼働状態、認証情報、依存関係、クリーンアップ、チェックアウトを自分で管理する。 |
| Team Pools | 組織が管理するワーカー | エンタープライズのワーカーフリート、GPU、Mac、Kubernetes、ラベル付きルーティング、集中管理されたキャパシティ | ホスト、イメージ、秘密情報、スケーリング、監視、リセット、障害対応をチームが管理する。 |
要件がプライベートアクセスだけなら、マネージドCloud Agentsを選ぶ
リポジトリ権限、ネットワークの許可リスト、Tailscaleに類するクライアント、対応済みのプライベート接続で境界を定義できるなら、マネージドCloud Agentsで十分かもしれません。Cursorのランタイムガイドも、大半のチームにはマネージドインフラを推奨し、運用負荷が低い選択肢として説明しています。
これならワーカーフリートを運用せずに、Cursorが管理するVMのライフサイクルと弾力的な同時実行性を利用できます。ただし、マネージドエージェントがデータを外へ出さないという意味ではありません。実行環境をチームではなくCursorが運用する、という違いです。
1ユーザー・1環境で完結させるならMy Machines
My Machinesは、個人のマシンを個人のCursorアカウントに接続します。すでに依存関係を整えたMac、開発用マシン、リモートVMがあり、ローカル状態やネットワークアクセスを別の環境で再現するのが面倒な場合に便利です。
一方で、運用上の負担はユーザー側にあります。アクティブなセッション中はマシンをオンラインにしておく必要があり、クリーンアップ、チェックアウトの鮮度、ディスクの状態、認証情報、依存関係の修復も自分で担います。Cursorのセルフホストドキュメントでは同じマシン上で複数のエージェントを実行できると説明されていますが、中央集約型のチーム向けフリートとは異なる運用です。
フリート管理の負担に見合う場合だけTeam Poolsを選ぶ
Team PoolsはEnterpriseチーム向けの機能です。サービスアカウント認証、共有ワーカーキャパシティ、ラベル、コントローラーによるスケーリングを利用します。gpuプールならGPUマシンへ、iosプールならMacへ処理を振り分けられます。Cursorはユーザーあたり最大200ワーカー、チームあたり最大1,000ワーカーを案内しており、それを超える展開にはスケーリングについての相談が必要です。
プールはゼロまでスケールダウンでき、永続型、コンテナ型、Kubernetes型、パートナーのホスト環境で動かせます。Cursorによれば、解放されたワークスペースの復元には数分かかる場合があります。柔軟性は高いものの、イメージ管理、ワーカーのリセット、キャパシティ計画、秘密情報のローテーション、監視はユーザー側の責任になります。
コストはインフラ費用とモデル利用料の合算で考える
Self-Hosted MachinesのドキュメントとCursor Models & Pricingページでは、モデル、プラン、インフラに関する責任分担が説明されていますが、Self-Hosted Machines専用のワーカー単位料金は掲載されていません。示されているコスト構造は、Cursor経由で選択したモデルの料金を支払い、それに加えて、ユーザーが運用するマシン、コンテナ、クラスター、ストレージ、ネットワーク、監視、運用の費用も負担するというものです。
そのため、特別なネットワーク要件やハードウェア要件がない場合、セルフホスティングをコスト削減策として選ぶメリットは小さくなります。動的プールや休止によってアイドル時のコンピュート費用を抑えられる可能性はありますが、損益分岐点はワークロードの形、起動時間、再構築が必要な状態の量に左右されます。Cursorは一律に適用できる数字を公開していません。
有効化する前に確認したいセキュリティチェックリスト
「セルフホスト」という言葉だけで承認せず、セキュリティ、プラットフォーム、コンプライアンスの担当者と次の項目を確認してください。
- 境界要件を具体化する。 完全なチェックアウト、ツール実行、認証情報、推論リクエスト、成果物のどれを、あるいはすべてを境界内に残す必要があるのかを決める。Self-Hosted Machinesが自社管理下に置くのは、実行ワーカーとローカルの完全な状態だけ。
- 返却されるコンテキストを分類する。 ファイル内容、差分、ターミナル出力、スクリーンショット、MCPの結果がCursorへ送られる可能性がある。これらにソースコード、顧客データ、トークン、社内URL、本番環境のレスポンスが含まれ得るかをテストする。
- Privacy Modeを意図的に有効化する。 Cursorが説明する学習利用とプロバイダー保持に関する扱いは変わるが、リクエスト処理、一時キャッシュ、リスク検知の処理まで止めるものではない。
- BYOKを正しく理解する。 Cursorのデータ利用ページによれば、APIキーを使ってもリクエスト経路からCursorのバックエンドは外れない。
- 成果物の外部送信は別途判断する。 PRやダッシュボードに表示されるスクリーンショット、動画、ログへの参照を許容するかどうかで、
cloud-agent-artifacts.s3.us-east-1.amazonaws.comへの通信を許可・ブロックする。ファイアウォールが対応しているなら、正確なホスト単位のルールを優先する。 - 外向き通信の許可リストを使う。 ドキュメントに記載されたCursorのエンドポイントと、意図的に有効化した更新用・Computer-use用のホストだけを許可する。ワーカーに受信ポートやパブリックIPは必要ないはず。
- MCPの通信方式を確認する。 プライベートサービスへアクセスする必要があるサーバーには、ワーカー側のstdio MCPを使い、返される結果も評価する。サービス自体がプライベートだからといって、HTTP/SSEのMCPエンドポイントまでネットワーク内に留まるとは限らない。
- ワーカーを分離し、リセットできるようにする。 Team Poolsでは、エージェント間でマシンをどう消去・再作成するか、認証情報をどう注入するか、ログをどう監視するかを決める。Cursorのガイドとテンプレートは参考アーキテクチャであり、完全に管理された本番フリートではない。
- 障害時の動作をテストする。 Cursorのエンドポイント、成果物ストレージ、ワーカー、プライベートレジストリ、MCPサーバーが利用できなくなった場合の挙動を確認する。成果物ホストのブロックとエージェントセッションのブロックを混同しない。
- エアギャップ用途では採用しない。 モデルコンテキストの外部送信を認めない、あるいは第三者クラウドでの推論を認めない要件には、このアーキテクチャは適合しない。エージェントループはCursorのクラウドに残る。
| 実際の要件 | 判断 |
|---|---|
| コマンド、ローカル状態、独自ハードウェアを自社環境で動かす必要がある | Self-Hosted Machinesを使い、コンテキストと成果物の外部送信を制御する。 |
| エージェントからプライベートサービスへ接続する必要があるが、実行場所はマネージドVMでよい | まずマネージドCloud Agentsと対応済みのプライベート接続を検討する。 |
| モデルコンテキストをネットワーク外へ出せない、または推論をオフラインで行う必要がある | このアーキテクチャは採用しない。Cursorのクラウドへの依存が残る。 |
Cursor Self-Hosted MachinesのプライバシーFAQ
Cursor Self-Hosted Machinesは完全なセルフホストですか？
いいえ。エージェントループ、推論、計画、オーケストレーションはCursorのクラウドに残ります。自分のマシンでホストするのは、ツールの実行とローカルの作業状態です。
ソースコードはセルフホストワーカーの外へ出ますか？
ファイル内容、差分、ターミナル出力、スクリーンショット、ローカルMCPの結果の一部は、エージェントへの入力またはツール結果としてワーカーの外へ出る可能性があります。Cursorは完全なチェックアウトとビルドキャッシュはワーカーに残ると説明しているため、境界は全面的なものではなく、部分的なものです。
Privacy Modeでネットワーク越しのデータ送信を止められますか？
いいえ。Privacy Modeは、CursorおよびCursorが定める保持条件下のモデルプロバイダーによる学習利用を防ぐものとして説明されています。推論に必要なコンテキストをワーカーが送信すること自体は止めません。
BYOKでCursorを迂回できますか？
いいえ。Cursorのデータ利用ページによれば、最終的なプロンプト構築のため、APIキーを使ったリクエストもCursorのバックエンドを通ります。BYOKを、ワーカーからモデルプロバイダーへの直接接続と考えるべきではありません。
スクリーンショットや動画のアップロードを止められますか？
cloud-agent-artifacts.s3.us-east-1.amazonaws.comへの外向きアクセスをブロックできます。ツール実行は継続しますが、成果物はプルリクエストやCursorのダッシュボードに表示されません。その他のエージェントセッションデータは、引き続きCursorへ返される可能性があります。
ワーカーに受信ファイアウォールルールやVPNは必要ですか？
Cursorは外向きHTTPSモデルを案内しています。受信ポート、パブリックIP、VPNトンネルは不要としていますが、ワーカーには、ドキュメントに記載されたCursorのエンドポイントと、利用する必要のある各種サービスへの外向きアクセスが必要です。
個人プランや下位プランでTeam Poolsを使えますか？
Cursorのドキュメントでは、Team PoolsはEnterprise向けで、サービスアカウントのAPIキーが必要とされています。個人用ワーカーの選択肢はMy Machinesです。個人用APIキーでTeam Poolワーカーを起動できるとは考えないでください。
Cursor Self-Hosted Machinesを完全オフラインで動かせますか？
いいえ。エージェントループと推論はCursorのクラウドに残り、ワーカーには外向き接続が必要です。オフラインまたはエアギャップが要件なら、オーケストレーションとモデル推論をローカルに配置した別のアーキテクチャが必要です。
Cursor Self-Hosted Machinesは、ユーザーが管理する実行環境、プライベートネットワークへの接続、独自ハードウェア、常時利用できる環境が必要なチームに向いています。AIの通信自体をクラウドの外へ出したくないなら、別の設計を選ぶべきです。この機能が変えるのはコマンドの実行場所であって、エージェントが思考する場所ではありません。