Cursorが実際に公開した内容
分割を定義する1つの文
発表より：
"With Self-Hosted Machines, only the execution environment moves while the agent loop, inference, and planning remain in the Cursor cloud. Tool outputs flow back to Cursor for inference and may contain code, and agent transcripts may be processed and stored by Cursor."
1つの文に3つの主張があります。実行環境が移行すること。ツールの出力は推論のためにCursorに送り返され、コードが含まれる場合があること。トランスクリプトはCursorによって処理および保存される場合があること。
ドキュメントでも逆の視点から同じことが述べられており、何が転送されるかが列挙されているため、両方を読む価値があります：
"The full checkout, build cache, and machine-local credentials stay on your machine. During a run, the worker sends Cursor the content the agent needs, such as file contents, terminal output, diffs, screenshots, local MCP results, and routing metadata."
ファイルの内容（File contents）がそのリストに含まれています。これはCursorが隠し事をしているからではなく、ドキュメントに明記されている通り、モデルが推論を行うためにそのバイトデータが必要だからです。モデルが別の場所で実行されるアーキテクチャである以上、これを避けることはできません。
2つの半分には異なる保持ルールがある
Cursorのクラウドエージェントのセキュリティページでは、エージェントのデータをいくつかの種類に分類し、それぞれに独自の保持ルールを適用しています。ここではそのうちの2つが重要になります。
ランタイムワークスペース（runtime workspace）は、「チェックアウトされたリポジトリ、ビルド成果物、および実行中のランのツール実行コンテキスト」を保持します。その保持期間は、「ランがアイドル状態になった後に自動的にリサイクルされます。フォローアッププロンプトを送信するとタイマーがリセットされます」となっています。
会話ステート（conversation state）は、「トランスクリプトを構成するプロンプト、モデルの応答、ツール呼び出し、diffコンテキスト、およびデモ成果物」を保持します。これは「エージェントごとのキーで暗号化され、Cursorのバックエンド」に保存され、その保持期間は「過去のランを再確認して再開できるように、デフォルトで無期限に保持されます。オンデマンドで削除可能です」となっています。
つまり、エージェントが何を考えたかという永続的な記録は、移行しない側の半分にあります。Self-Hosted Machinesは、一時的な側の半分を再配置するのです。
フォローアップが記憶を保持しているかを決定するデフォルト値
ここに、実際の数値が示されている部分があります。プール設定において：
"Once a worker is matched to a request, Cursor forwards all agent tool calls directly to the machine. The connection has an idle timeout that defaults to 1 hour."
そして、そのタイマーが作動すると：
"Once a worker times out, Cursor marks it as freed. The machine can reset and re-enter the pool. If a user restarts a chat that has disconnected from its machine, the chat reconnects to a fresh machine from the pool. Workspace state from the original machine does not carry over unless the pool uses hibernation."
最後の節を2回読んでください。会話は存続します。バックエンドに無期限に保存されているからです。しかし、ワークスペースは存続しません。ドキュメントはそのコストについて率直に述べています。「マシンが解放された後に到着したフォローアップは、プールから再取得されます。エージェントは新しいマシンに着陸し、すでに持っていたワークスペースを再構築するために最初の数分を費やす可能性があります。」
ドキュメントに記載されている解決策が「ハイバネーション（一時休止）」です。マシンがアイドル状態になったときにスナップショットを作成し、再接続ウィンドウ内にフォローアップが到着した場合はそれを復元し、「ウィンドウが経過する前に同じIDを持つワーカー」を起動します。スナップショットが失われている場合は、クレームを解放し、「代替のマシンがそれをクレームする」ことができます。
プールはリポジトリにバインドされない
コンテキストに影響を与えるもう1つの設計上の詳細があります。「プールは個々のリポジトリに関連付けられていません。リクエストはプールを特定するだけでよく、利用可能な任意のワーカーがそれを処理できます。これにより、1つのプールで多くのリポジトリに対応できます。」
効率的です。しかしこれは、次のリクエストを処理するマシンが、デフォルトではプロジェクトの履歴を一切持っていないマシンであることを意味します。
これによって変わること、変わらないこと
実行環境は移行します。およびそれこそが目的です。 Cursorによると、開発チームがこれを使用するのは一般的に、「エージェントのツール実行をネットワーク内で行い、ソース管理、内部サービス、コードリポジトリに直接アクセスする必要がある場合」、エージェントが「GPUやiOS開発用のMacなどのカスタムハードウェア」を必要とする場合、またはビルドパイプラインを「Cloud Agentビルドとしてパッケージ化するのが困難な場合」です。これらは現実的な制約であり、本機能はそれを真に解決します。
推論レイヤーは移行しません。これは設計通りの仕様です。 Cursorは「エージェントのループ、推論、および計画」を実行します。ユーザーのワーカーは「ファイルの編集やターミナルコマンドを実行します。また、コンピュータ使用ツールやローカルのMCPサーバーも実行します。」
これはCursor特有の奇妙な仕様ではありません。 同様の構成は、AnthropicのManaged Agents向けセルフホスト型サンドボックスにも見られ、ほぼ並行する言葉でドキュメント化されています。セルフホストは「オーケストレーションをAnthropic側に残しつつ、ツールの実行をユーザーが制御するインフラに移行する」ものです。特にメモリレイヤーに関しては、「エージェントのスキルと、セッションにアタッチされたメモリストアの内容はAnthropicによって保存され、セッションのためにサンドボックスにコピーされます。エージェントがメモリファイルに加えた変更はストアに同期されます。」とあります。Anthropicはさらに、「AWS上のClaude Platformのセルフホスト環境のセッションにはメモリストアをアタッチできない」という明確な制限もドキュメント化しています。2つのベンダーが同じアーキテクチャ上の結論に達しています。つまり、セルフホストはサンドボックスを再配置するものであり、メモリを再配置するものではないということです。これらのホスト型ストアの仕組み自体を理解することは価値があります。それについてはClaude's agent memory storesで解説しています。
これ単体で、プライバシーの状況が悪化することはありません。 Cloud Agentsは「プライバシーモード（Privacy Mode）」で動作し、これが有効な場合、「CursorはCloud Agentsがアクセスしたコードや、その実行によって生成されたプロンプトと応答を学習に使用することは一切ありません。」オンデマンドでエージェントの会話トランスクリプトと成果物を削除する「Delete Agent API」が存在し、Enterpriseチームは「保持ポリシーを使用して会話の保持期間を制限する」こともできます。ランタイムシークレット（Runtime Secrets）は「トランスクリプト、ツールの出力、コミットから削除され、モデルに到達することはありません。」これらは有意義なコントロールであり、ドキュメント化されています。
人々が誤解しがちなポイント
「これで何もネットワークの外に出なくなった」 最もよくある解釈ですが、Cursor自身の文がそれを訂正しています。ツールの出力は推論のために送り返され、そこにはコードが含まれる場合があります。その場に留まるのは、チェックアウト、ビルドキャッシュ、およびマシンローカルの認証情報です。これは「何も外に出ない」という主張とは明らかに異なり、より限定的なものです。
「マシンが自分たちのものになったから、エージェントの記憶力が高まる」 プール型のセットアップにおいては逆効果です。マシンを所有してもエージェントの記憶は拡張されません。むしろ、ユーザーが管理しなければならない解放タイマーが導入されることになります。ハイバネーションがない場合、アイドル状態で解放されたマシンは、次のフォローアップが新しいハードウェアで開始されることを意味します。
「ハイバネーションは有効になっている」 これはユーザー自身が実装するパターンであり、自動的にオンになるスイッチではありません。アイドル解放のタイムアウトを短縮し、アイドル時にスナップショットを作成し、クレームされたがオフライン状態のキューエントリを監視し、ウィンドウが経過する前に復元します。これはユーザーが作成し、運用するコントローラーです。
「トランスクリプトも自分たちの側にある」 そうではありません。会話ステートはCursorのバックエンドに存在し、デフォルトで無期限に保持されます。オンデマンドで削除可能で、ポリシーによって制限できますが、Self-Hosted Machinesによって再配置されるわけではありません。
「1つのプールに1つのプロジェクト」 プールはどのリポジトリに対しても機能します。特定のリポジトリ用にウォームなワークスペースを維持するためにマシンのアフィニティ（親和性）を期待している場合、プールはそれを保証しません。
解決策：どのマシンが応答するかに依存せず、エージェントが知っておくべきことを決定する
ステップ 1: 各種ステートがセットアップ内のどこに存在するかを書き出す
15分時間を取って、自身のデプロイメントに関する4行の表を作成してみてください。Cursorのドキュメントは3行分を教えてくれます。4行目はあなた自身のものです。
チェックアウト、ビルドキャッシュ、マシンローカルの認証情報 — ユーザーのマシン（ワーカーのリセット時に消失）。ランタイムワークスペース — ユーザーのマシン（アイドル後にリサイクル）。会話トランスクリプト — Cursorのバックエンド（デフォルトで無期限）。永続的なプロジェクト知識 — ほとんどのチームがこの行を埋めることができません。なぜなら、その答えは「たまたまそれを含んでいたトランスクリプトの中」だからです。
この4行目こそが問題のすべてです。それより上のものはすべて、設計上一時的なものであるか、ベンダーによって保持されているかのどちらかです。
ステップ 2: タイマーを意図的に設定し、解放を1回検証する
2つのノブがあり、それらの相互作用が厄介な問題を引き起こします。デフォルトの1時間をそのまま引き継ぐのではなく、意図を持ってワーカー接続のアイドルタイムアウトを設定し、プールでハイバネーションを使用するかどうかを明示的に決定してください。
次に、実際に気になるケースをテストします。エージェントを起動し、実際のワークスペースステートを構築させ、アイドルタイムアウトが経過するまで待ち、フォローアップを送信します。エージェントが再開するか、それとも最初の数分を再構築に費やすかを観察してください。これを1回行うだけで、プールがどちらの挙動を示すかがわかります。これはドキュメントから推測するよりもはるかに価値があります。
その際、コントローラーがオフラインパスを処理しているかどうかも確認してください。Cursorは、オフラインマシンのフォローアップを、claimedWorkerId と wakeTimeoutMs を持つ「クレームされたがオフライン」のキューエントリとして通知し、対応するイベントを発行します。インフラのどこもそれを監視していない場合、ハイバネーションは実際には設定されていません。
ステップ 3: すべてのマシンとすべてのトランスクリプトの外側に、存続すべき知識を置く
ステップ1と2によって、正確なマップと予測可能なタイマーが得られます。しかし、その根底にある疑問には答えていません。新しいワーカーがフォローアップをクレームしたとき、エージェントはどうやってあなたの開発ルールを知るのでしょうか？
今日の答えは「トランスクリプトに含まれていれば、そこから」です。これにより、永続的な知識は会話履歴の副産物になってしまいます。ベンダーによって保持され、デフォルトで無期限であり、テーマ別ではなくセッション別に整理されます。これは、すべての実行において真であるべき事実を整理するためのファイルシステムとしては貧弱です。同じ論理は、あらゆるステートレスな実行レイヤーにも当てはまります。だからこそ、memory for MCP tasksも同じ結論に達しているのです。
独立した記憶（メモリ）レイヤーは、この問題からマシンを完全に排除します。どのプールで、どのリポジトリで、どのワーカーがリクエストをクレームしようとも、エージェントは同じストアを読み込みます。ハイバネーションは、フォローアップと適切な回答の間に立ちはだかる障害ではなくなり、本来あるべき姿、つまりワークスペースをウォームに保つためのコスト最適化手段になります。MemoryLakeは3つのステップでセットアップできます。
ステップ 1: APIキーを作成する
サインインし、ダッシュボードからAPIキーを生成します。この認証情報は、ワーカー、プール、またはマシンイメージではなく、ユーザー自身に紐づきます。これは、次のプロンプトに応答するマシンが、コントローラーが90秒前に起動したばかりのマシンである場合に極めて重要な特性です。
ステップ 2: 最初の記憶をアップロードする
新しいワーカーがチェックアウトから再構築する方法がない情報を入力します。アーキテクチャの決定とその理由、デプロイの規約、エージェントがアクセスを許可されている内部サービス、すでに3つの異なるセッションで入力した修正内容などです。
一時的なものは一時的なままにしておきます。ビルドキャッシュやチェックアウトはリサイクルされるべきであり、それは損失ではありません。
ステップ 3: AIとエージェントを接続する
エージェントをストアに向けます。これにより、プールされたリクエストはすでにプロジェクトの知識を持った状態で到着し、ワークスペースの再構築にかかるコストは、再説明の手間ではなく、数分間のビルド時間だけで済みます。
実務における変化
最初の変化は、プールのチューニングが「知識」の決定ではなく「経済的」な決定になることです。現状では、コスト削減のためにアイドルタイムアウトを短縮すると、エージェントが知っていることも削減されてしまいます。これらは同じレバーであるべきではありません。
2つ目は、クロスリポジトリプールを設計通り安全に使用できるようになることです。1つのプールで多くのリポジトリに対応することは、ワーカーが交換可能であるからこそ効率的です。そして、交換可能なワーカーが問題になるのは、ワーカー自体に知識が宿っている場合だけです。
3つ目は、永続的な知識が保持ポリシーの副産物ではなくなることです。会話の保持期間を制限することは優れたガバナンスですが、それによってエージェントがコードベースについて理解している内容が静かに失われるべきではありません。この2つを切り離しておくことは、製品ごとではなくsharing one memory across toolsでツール間で1つの記憶を共有するのと同じ原則に基づいています。
セルフホスト型クラウドエージェントのベストプラクティス
- 要約ではなく、実際の境界線を引用する。 移行するのは実行環境のみです。エージェントのループ、推論、および計画はCursorのクラウドに残り、ツールの出力は推論のために送り返されます。
- 意図的にアイドルタイムアウトを設定する。 接続のデフォルトは1時間です。これがチームのフォローアップの送信頻度に合致しているかどうかを判断してください。
- ハイバネーションを自身で運用するインフラとして扱う。 アイドル時にスナップショットを作成し、クレームされたがオフラインのエントリを監視し、ウィンドウ内で同じワーカーIDで復元します。
- マシンのアフィニティに依存しない。 プールはリポジトリに関連付けられていません。利用可能な任意のワーカーがリクエストをクレームできます。
- 既存の保持コントロールを活用する。 特定のトランスクリプトにはDelete Agent APIを使用し、一定期間の制限にはEnterprise保持ポリシーを使用し、トランスクリプトやコミットから値を完全に排除するにはRuntime Secretsを使用します。
- 組織全体でプライバシーモードを標準にする。 レガシーのプライバシーモードはCloud Agentsではサポートされていません。ドキュメントでは、すべてのランがその保証を継承できるように、標準モードを強制することを推奨しています。
- 新しいワーカーが何を知っているかを監査する。 もし答えが「どのトランスクリプトがアタッチされているか」に依存している場合、その知識はまだ永続化されていません。
- 変更後に再確認する。 これは2026年9月2日にリリースされ、サンドボックスプロバイダーの統合やLinuxのコンピュータ使用機能も同時に登場しました。動きの速い分野は常に変化します。
結論
Self-Hosted Machinesは、現実的な制約に対する真の解決策であり、Cursorはその境界線を周囲の報道よりも慎重にドキュメント化しました。実行環境はユーザーのネットワーク内に移行します。しかし、エージェントのループ、推論、およびトランスクリプトは移行しません。
実務上の影響は、ヘッドラインよりも限定的であり、かつ有用です。プール型のデプロイメントにおいて、インフラのタイムアウトは、エージェントが知識を持った状態でフォローアップを開始するか、それともゼロから開始するかを決定する要因になります。そのタイマーを意図的に設定し、ワークスペースのウォーム状態が重要である場合はハイバネーションを実装し、すべてのリリースを生き残るべき知識は、どのワーカーも所有しないレイヤーに保持してください。