はじめに

クラウドワーカー計画

ステータス

提案、リビジョン 3。未実装。方向性は 2026-07 に合意済み。リビジョン 2 では敵対的レビューの指摘（専用ワーカープロトコル、配置／環境ステートマシン、git 対応の受信同期、一方向の v1 ハンドオフ、制御された外向き通信に関するセキュリティ表現）を反映した。リビジョン 3 では同期の所有権モデル（ワーカーがコミットを作成し、Gateway が取り込んで公開）を確定し、git を使用しないプレーン同期モードを追加し、ワーカーの exec をボックス内で完全に実行するよう修正し、インターネットポリシーをプロビジョニング時に移し、エージェントディスパッチをマイルストーン 3 に戻した。

問題

OpenClaw のエージェントセッションは、1 台のマシン上にある Gateway プロセス内でループ、ツール、推論を実行する。計算能力はそのマシンによって制限され、長時間のタスクはマシンを占有し、並列作業はそのリソースを奪い合う。ホスト型製品（Cursor cloud agents、Claude Code on the web、Codex cloud）は、タスクごとの一時的なクラウドサンドボックスでこの問題を解決しているが、ベンダーのインフラストラクチャとベンダーへの信頼が必要になる。

すでに予備のマシンを所有している（または安価にリースできる）運用者には、「このセッションをあちらで実行し、他のセッションと同様にサイドバーに表示し、終了後はマシンを破棄する」と指定する方法がない。

目標

一時的なリモートマシン（「クラウドワーカー」）上で完全なエージェントセッション（ループ + ツール）を実行しながら、セッションをローカルセッションとまったく同じように Control UI に表示し、ストリーミングする。
ワーカーには常設の認証情報（プロバイダー認証やフォージトークン）を置かず、直接のネットワーク外向き通信も許可しない。ボックスに必要なのは到達可能な sshd のみ。
プロビジョニング、同期、実行、収集、破棄を完全に自動化し、プロバイダーを差し替え可能にする（最初のプロバイダー：Crabbox 形式のリース CLI）。
トランスクリプト、セッション ID、または（リクエストバイトが同等のままである場合の）プロバイダーキャッシュの親和性を失わず、ターン境界で Gateway からワーカーへ実行中の作業をディスパッチし、結果を安全に取得する。
人間（UI）とエージェント（ツール）の両方が、作業をクラウドワーカーへディスパッチできるようにする。
数日間にわたるセッションをサポートする。存続期間はポリシーであり、ハードコードされた上限ではない。

非目標（v1）

ワーカー上で外部コーディングハーネス（Claude Code、Codex CLI）を使用しない。ワーカーセッションは OpenClaw の組み込みランナーのみを実行する。ハーネスは独自の認証情報を使用して独自に推論するため、ハーネスのサポートは v2 のオプトインとする。
best-of-N／並列試行のファンアウトは行わない。
VPN／tailnet への依存は設けない。トランスポートは SSH のみ。
新しいサンドボックスランタイムは導入しない。ワーカーマシン自体を分離境界とし、後からボックス内の OS サンドボックスを重ねられるようにする。
v1 では対称的なライブマイグレーションを行わない。ディスパッチはローカル → ワーカーのみとする。ワーカー → ローカルには、停止済みのセッションと完了済みのワークスペース調整が必要になる。ライブ双方向ハンドオフは、後から同じバリア機構の上に構築する。
Gateway 上に JSON の補助状態を置かない。環境、配置、カーソル、付与状態は SQLite に保存する。

先行事例（踏襲する点、反転する点）

Cursor cloud agents：エージェントループはクラウド内で実行され、VM はツール実行対象となる。追記専用の会話ストアがすべてのクライアントへストリーミングされる。インストール後のスナップショットによるウォームスタートを行う。セルフホスト型ワーカーは外向き通信のみを行うワーカープロセスである。「会話の信頼できる唯一の情報源をオーケストレーター上に保持する」点とストリーミングモデルを踏襲し、ループの配置は反転する（以下の決定を参照）。
Codex cloud：ネットワーク接続されたセットアップフェーズと、シークレットを除去したオフラインのエージェントフェーズからなる 2 フェーズのランタイム。迅速な後続処理のためのコンテナ状態キャッシュ。外向き通信に対する姿勢としてこのフェーズ分割を踏襲し、v2 のウォームイメージ向けにキャッシュの考え方を採用する。
Claude Code on the web：セッションごとの VM。認証情報を隔離する git プロキシ（実際のトークンはサンドボックスに入らず、push はセッションブランチに制限）。セットアップ後のファイルシステムスナップショット。テレポートハンドオフ = push 済みブランチ + 再生された履歴。認証情報の隔離とハンドオフの枠組みを踏襲するが、外向き同期は Gateway から rsync で行うため、変更のある作業ツリーにも対応でき、ボックス付近のどこにもフォージトークンは存在しない。
Copilot coding agent：パッケージレジストリの許可リストを使用するデフォルト拒否の外向き通信。定常状態のデフォルトはこれより強力（直接の外向き通信を一切許可しない）である。推論とウェブ検索は SSH トンネル経由で到着するためだが、これが「外向き通信ゼロ」ではなく「制御された外向き通信」である理由については「セキュリティ」を参照。

アーキテクチャ上の決定：ループはワーカー上、推論は Gateway 経由

3 つの配置を検討した。

ループは Gateway 上に残し、ワーカーがツールを実行する（Cursor モデル）。障害領域として最も安全であり（トランスクリプト、推論、承認、再起動からの復旧がすべてローカルに残る）、レビュアーが最初のマイルストーンとして推奨した方式でもある。製品アーキテクチャとしては却下した。OpenClaw の exec 以外のツールはプロセス内のファイルシステム操作であるため、ファイルの読み取り、編集、grep のたびにネットワーク往復が発生するか、ツールサーフェスを粗粒度のワークスペース RPC へ大幅にリファクタリングする必要がある。ランタイムの動作は通信量が多く、レイテンシに制約される。この考え方はすでに構築済みの領域（Node への exec オフロード）で再利用するが、ツールのリモート化レイヤーは構築しない。
ループと推論の両方をワーカー上で実行する。障害領域は最も単純だが、モデルの認証情報（OAuth プロファイルを含む）を使い捨てマシンへ転送する必要があり、Gateway はポリシー、ルーティング、監査の制御を失い、マイグレーションによってプロバイダー呼び出し元の ID が切り替わるため、プロバイダーキャッシュが無効になる。
ループ + ツールはワーカー上で実行し、モデル呼び出しは Gateway 経由でプロキシする。これを採用する。ツール呼び出しごとではなくモデルターンごとに 1 回だけ往復し、ツールはコードの近くで実行される。Gateway は引き続き認証プロファイル、プロバイダーのルーティング、ポリシーを一元的に所有し、ワーカーはシークレットを保持しない。

選択肢 3 の代償は、各モデルターン中に Gateway へ同期的に依存すること。そのため、その耐久性ルールは後付けではなく、この決定の一部となる。

ターン途中で Gateway が失われると、アクティブなプロバイダー呼び出しは失敗する。そのターンは失敗として記録され、再接続後に新しいターンとして再試行される。処理中のプロバイダーストリームを透過的に再生することはない（二重課金／ツール呼び出しの二重実行のリスク）。
ワーカー↔Gateway 間のすべての操作は永続的な ID（「ワーカープロトコル」を参照）を伴うため、再接続時には処理が宙に浮くのではなく、再開するか、キャッシュされた終端結果を取得する。
Gateway は容量管理されるコンポーネントである。同時実行ワーカー数の制限、フロー制御、負荷遮断は v1 のスコープに含まれる（「容量」を参照）。

Gateway はトランスクリプトを保存し、すべてのプロバイダートラフィックを発信するため、セッションは場所に依存しない。ループを Gateway とワーカーの間で移動しても、プロバイダー側でも UI のデータパスでも何も変わらない。これにより、ディスパッチと取得を低コストで実現できる。

コンポーネント

1. 環境ステートマシン + プロバイダー契約

Gateway プロトコル内の environments.* は現在、ステータスのみのプロジェクションである。永続的な中核は SQLite が所有する環境レコードとステートマシンであり、RPC の形状より先に設計する。

requested → provisioning → bootstrapping → ready → (attached|idle) → draining → destroying → destroyed | failed | orphaned

プロビジョニングはクラッシュセーフである。決定論的な操作 ID とともに、プロバイダー呼び出しより前に意図を示す行を永続化するため、Gateway の再起動時に、二重プロビジョニングや有料マシンの孤立を発生させず、処理中のリースを引き継げる。
再起動時の調整と孤立リソースのスイーパー（プロバイダーの inspect とローカルレコードの比較）は、堅牢化ではなく v1 の要件である。

プロバイダー契約（Plugin で実装。コアにはプロバイダー名やポリシーを置かない）：

type WorkerProvider = {  id: string;  provision(profile: WorkerProfile, opId: string): Promise&lt;WorkerLease&gt;; // → ssh ホスト／ポート／ユーザー／鍵素材  inspect(lease: { leaseId: string; profile: WorkerProfile }): Promise&lt;LeaseStatus&gt;; // 引き継ぎ／正常性／孤立リソースのスイープ  renew?(leaseId: string): Promise<void>; // 長期セッションとプロバイダー TTL の両立  destroy(lease: { leaseId: string; profile: WorkerProfile }): Promise<void>; // 冪等。破棄の証明後にのみ返る};

RPC：environments.create、environments.destroy、拡張された environments.list/status（プロバイダー、リース ID、状態、経過時間、アイドル時間、接続中のセッション）。最初のプロバイダーは、Crabbox 形式のリース CLI ラッパー（製品向けパス）と、開発専用と明記した静的 SSH ホストプロバイダーとする。共有ホスト上のワーカーはホスト上の無関係なデータを読み取れるため、静的ホストは機能開発向けであり、デフォルトのセキュリティ方針ではない。

2. ワーカーのブートストラップ：ボックスへの OpenClaw のインストール

専用のワーカー成果物は使用せず、npm の可用性にも依存しない。

すべてのモードでの標準インストール：Gateway が生成したコンテンツハッシュ付きのワーカーバンドル（Gateway 自身のビルド出力を tarball にパッケージ化したもの）を SSH 経由で転送し、ボックスにインストールする。構造上、開発ビルドと未リリースのコミットにも対応する。
Gateway がリリース済みバージョンを実行している場合、npm i -g openclaw@<exact gateway version> は最適化として使用できるが、latest は決して使用しない。
ブートストラップは冪等である。バンドルハッシュが一致するウォームリースではインストールをスキップする。未設定のマシンにはネットワーク接続されたツールチェーンフェーズ（Node ランタイム）が必要になる場合がある。これはセットアップフェーズの一部であり、完了後に閉じる。
ハンドシェイクでは、ワーカーのビルドハッシュ、プロトコル機能セット、ランタイム互換性を検証する。既存の Gateway のバージョン／プロトコル検査では不十分である（SSH トンネル経由の Node は完全なバージョン一致の拒否対象から除外されている）ため、ワーカーの受け入れ時に独自の完全一致ビルド検査を行う。

ワーカーモード（openclaw worker）はフォークではなくエントリポイントである。接続処理と組み込みエージェントランナーを備え、セッションの永続化とモデル呼び出しは Gateway RPC によって提供される。Gateway のサーフェスを起動してはならない。チャンネルを起動せず、セッションのツールセットを除く Plugin を自動起動せず、使い捨ての状態ディレクトリを使用し、ローカル認証プロファイルを持たない。

3. トランスポート：すべて SSH 経由

接続は Gateway が所有し、ワーカーに必要なのは sshd のみ。

Gateway はワーカーへの SSH 接続を開き（認証情報はプロバイダーのリースから取得し、ホスト鍵はプロビジョニング出力から固定する。StrictHostKeyChecking=no は使用しない）、ワーカーのローカルソケットを Gateway の WS エンドポイントへ転送するリバーストンネルを確立する。
制御／モデルのトラフィックとワークスペース転送には、同じ固定済みの信頼素材を使用する別々の SSH 接続を用いる。これにより、rsync がトークンストリームの先頭ブロッキングを引き起こさないようにする。
トンネルのライフサイクル（キープアライブ、バックオフ付き再接続）は、Gateway 上の環境ランタイムが所有する。トンネルの一時的な切断はセッションレベルでは認識されない。以下の永続的なプロトコル状態により、ワーカーは再接続して再開できる。

4. ワーカープロトコル（専用。Node プロトコルではない）

現在の Node の境界に対する敵対的レビューにより、単純な再利用は不可能と判断した。保留中の Node 呼び出しは接続とともに消失するプロセスローカルな Promise であり、Node の冪等性キーは解析されるものの重複排除されない。そして決定的な点として、接続済みの Node は通常の Node イベント（エージェント実行リクエストを含む）を送出できるため、「Node の種類 + ケイパビリティ上限」は受信セキュリティ境界にならない。そのため、ワーカーには閉じたバージョン管理済みの RPC／イベント許可リストを持つ、認証済みの worker ロールを用意する。ワーカー接続から従来の Node イベントハンドラーへ到達することはできない。

ID と認証情報：プロビジョニング時に、環境 ID、ワーカー鍵、バンドルハッシュ、許可された単一セッション、許可された RPC セット、有効期限に紐づく短命のワーカー認証情報を発行する。SSH で検証されたペアリングも引き続き適用する（ボックスをプロビジョニングし、鍵を保持しているため）が、認可は宣言された Node サーフェスではなく、発行された認証情報に基づく。

永続的な操作セマンティクス（既存の ACP ランタイムとそのイベント台帳から形状を踏襲。安定したハンドル、セッション単位の直列化、永続的な (session, seq) の再生）：

すべての操作は (sessionId, lifecycleRevision, runId, ownerEpoch, streamKind, seq) にスコープされます。
所有権エポックによって古いワーカーをフェンスします。代替ワーカーがエポックを進め、古いエポックから遅れて届いた結果は決定論的に拒否されます。
永続化された ACK カーソルと SQLite にキャッシュされた終端結果による少なくとも1回の配信を行い、重複排除は決定論的です。厳密に1回の保証はありません。
キャンセル、クローズ、再開、終端結果には明示的なフレームを使用し、ストリームにはクレジット／ウィンドウベースのフロー制御を適用します。
プロトコル機能ネゴシエーションは、一般的な Node プロトコルバージョンから独立しています。

5. セッションバックエンド RPC

2つの異なる契約があります。現在のコードベースでは、永続的なトランスクリプト変更（セッションマネージャーが所有し、親／リーフ状態を持つ JSONL ツリー）と、プロセスローカルなライブイベント（ストリーミング差分、ツールのライフサイクル、承認）が分離されており、ワーカープロトコルはこの分離を維持する必要があります。

永続的なトランスクリプトのコミット：ワーカーは runEpoch とベースリーフの比較交換を伴うセマンティックな追記バッチを送信し、Gateway セッションマネージャーがエントリ ID と親 ID を生成します。ワーカーが信頼済みのトランスクリプト行、エントリ ID、親 ID、または別セッションの ID を指定することはできません。
再生可能なライブイベント：ワーカーのシーケンス番号、Gateway の ACK、制限付き保持、遅延イベントのフェンシングを備えた型付きイベントユニオンです。既存のエージェントイベントのファンアウトへ供給することで、チャットビュー、ツール行、未読／ステータスロジックがローカルセッションと同一に動作します。

推論プロキシ：既存のランタイムプロキシストリームクライアント（src/agents/runtime/proxy.ts）のイベント語彙を再利用しますが、信頼境界を移動します。ワーカーが送信するのは、セッション／実行の識別情報、承認済みモデル参照、コンテキスト、および制約付き生成オプションのみです。Gateway は自身のカタログから、プロバイダー、エンドポイント、認証、ヘッダー、ルーティング、コストポリシーを解決します。ワーカーが指定したモデルオブジェクト（例：攻撃者が制御する baseUrl）は拒否されます。リクエストサイズ制限、キャンセル、監査、終端結果の再生が適用されます。Gateway に常駐するツール（Web 検索）は Gateway 上で実行され、同じチャネルを介して結果を返します。

6. ワークスペース同期

同期アンカーは、排他的な配置所有権を持つ Gateway ローカルのワークスペースです。git ワークスペースの場合は専用の管理対象ワークツリー（既存の管理対象ワークツリーメタデータであるブランチ、ベース、スナップショット所有権が基盤）、git 以外のワークスペースの場合は Gateway が所有するターゲットディレクトリを使用します。ユーザーの使用中のチェックアウトは決して使用しません。セッションがリモートに配置されている間の排他的所有権により、受信同期は構造上競合しません。

所有権の分離 — コミットと公開：

ワーカー側のエージェントは、そのコピー内で通常どおりコミットを作成します（git commit はローカルかつ認証情報不要の操作で、作者の識別情報は Gateway 設定から投影されます）。これらのコミットは、Gateway が取り込むまで不活性なオブジェクトです。
信頼を必要とするすべての処理は Gateway が行います。受信コミットが記録済みのベースを基にしていることの検証、ローカルワークツリーの fast-forward、プッシュ、PR 作成、任意の署名／再署名を、すべて Gateway ローカルの認証情報で実行します。ワーカーが git やフォージの認証情報を保持したり、リモートにアクセスしたりすることはありません。

ワークスペースが git リポジトリかどうかに応じて、2つの同期モードから選択します。

Git モード。送信：トンネルの SSH 識別情報を使用してワークツリーを rsync し（未コミットおよび対象となる未追跡ファイルを含み、crabbox 形式の include/exclude と .worktreeinclude を尊重）、不変のベースマニフェスト（コンテンツハッシュとベースコミット）として記録します。受信：新しいコミットは、記録済みのベースに対する git bundle または一時 ref として返されます。未追跡アーティファクトは、サイズ／種類／シンボリックリンク封じ込めチェックを伴う明示的なマニフェストを介して返されます。取り込み時にベースの祖先関係を検証し、分岐していれば停止します。どちら側も暗黙には上書きしません。削除、名前変更、サブモジュール、シンボリックリンクによる範囲外への脱出は、rsync のヒューリスティクスではなくマニフェストルールで処理します。
プレーンモード（git なし。例：ボックス上でプロジェクトをゼロから構築する場合）。送信は同じ rsync とベースマニフェストです。受信では、マニフェスト差分に基づくミラーを Gateway 所有のターゲットディレクトリへ戻し、削除も反映します。git モードと同じ理由で安全です。排他的所有権によって競合する同時ローカル編集が存在せず、ベースマニフェストは予期しないローカルドリフトを引き続き検出し、上書きせずに停止します。

チェックポイントにより、数日間にわたるセッションをリース喪失から保護します。受信チェックポイントを定期的に作成し（git モードではセッションブランチのコミット、プレーンモードではマニフェストスナップショット）、頻度はプロファイルポリシーで決まります（デフォルトはターンベース）。

7. 配置ステートマシン、セッション、UI

ランタイム配置は、ばらばらの2つの行フィールドではなく、セッションをキーとする SQLite 所有のステートマシンです。

local → requested → provisioning → syncing → starting → active(worker) → draining → reconciling → local | reclaimed | failed

環境 ID、遷移世代、アクティブな所有者エポック、ワークスペースのベースマニフェスト、ワーカーバンドルハッシュ、最後の ACK カーソルを永続化します。どちらかのループがターンを開始する前に、ターン受付が配置をアトミックに取得します。そのため、古いスナップショットに基づいて受け付けられたローカルメッセージがワーカーのターンと競合することはなく、常に1つのループだけがセッションを所有します。

UI：

ワーカーセッションは、配置メタデータが付加された通常のセッション行です。通常のストアに保存され、sessions.list で一覧化され、既存のサブスクリプションを介してストリーミングされます。サイドバーとチャットに新しいデータパスは不要で、必要なのはワーカーバッジと配置／環境ステータス（provisioning / syncing / running / idle / reconciling / reclaimed）の表示だけです。
作成 UX：セッションターゲットバー（セッションサイドバーの再設計）に、Gateway と Node に加えてクラウドワーカーの宛先を追加します。設定済みのプロバイダープロファイルが必要で、設定されるまではこの機能を表示しません。
エージェントディスパッチ：セッションツールにより、人間と同じ方法でエージェントがクラウドワーカーへ作業を引き渡せます（ワーカーを利用するサブセッション、サブエージェント形式）。人間によるディスパッチと同じマイルストーンで提供し、同じオプトインのプロバイダー設定で制御します。再帰は構造的に制限されます（v1 ではワーカーセッション自体からワーカーをディスパッチできません）。支出管理には、クォータ機構ではなく環境ごとの会計／監査を使用します。

ディスパッチと引き渡し

v1 は意図的に非対称です。

ローカル → ワーカー（ディスパッチ）：後述の移行バリアを通過し、ワーカーをプロビジョニングまたは再利用して同期し、配置を切り替えます。次のターンはリモートで実行されます。
ワーカー → ローカル（引き戻し）：セッションを停止し（同じバリアに従ってワーカーをドレイン）、受信調整を完了して、配置をローカルへ切り替えます。ライブマイグレーションではありません。
対称ライブ引き渡し（稼働中のセッションを停止せずに双方向へ移動すること）は、同じバリアと調整機構を再利用し、障害注入テストによってバリアが実証された後に提供します。

移行バリア（「ターン境界」だけでは不十分です。承認、バックグラウンドプロセス、ロック解放後のトランスクリプトマージが境界をまたぐ可能性があります）：

新しいターンの受付を停止します（配置の取得）。
アクティブな実行をキャンセルまたはドレインします。
保留中の exec 承認と実行許可を取り消します。
トランスクリプトへの副次書き込みとライブイベントの ACK をドレインします。
ワーカーの子プロセスを終了します。
所有者エポックを進めて、古い所有者をフェンスします。
ワークスペースを調整します（受信、競合を考慮）。
新しい所有者をアクティブ化します。

キャッシュアフィニティ：どちらの配置でもプロバイダーリクエストは Gateway から送信されるため、シリアライズされたプロバイダーリクエストが同等であれば、キャッシュアフィニティは維持されます。同じツール順序、システム指示、プロバイダーラッパー、およびキャッシュメタデータ（Gateway 側に留まる）が条件です。これは仮定ではなく、テスト可能な特性です。ワーカーループを導入するマイルストーンには、サポート対象のプロバイダー転送方式ごとに、ローカル配置とワーカー配置間のバイト等価性テストが含まれます。

セキュリティモデル

厳密には、ワーカーには直接的なネットワーク送信経路も、常設のプロバイダー／フォージ認証情報もありません。ただし「送信経路が一切ない」わけではありません。推論と Gateway 実行ツールは制御された送信チャネルです（プロンプトインジェクションを受けたワーカーでも、ワークスペースのバイト列をモデルコンテキストや Web 検索クエリに含めることは可能です）。したがって、次のようにします。

制御された送信経路の計測：推論プロキシと Gateway ツールについて、環境ごとの監査とオペレーターが確認可能な計測を行います。レート／バイト制限はプロトコルのフロー制御（容量）として設けるもので、支出クォータ機構としてではありません。
ワーカーから Gateway への受信は、閉じたワーカープロトコル許可リストに限定されます。トランスクリプト書き込みは構造的に制約されます（Gateway が生成する ID、単一のバインド済みセッション）。
ワーカーの exec はボックス内で完全な権限を持ちます。ボックスは使い捨てで認証情報を持たないため、コマンドごとの承認は保護効果なく摩擦だけを増やします。保護対象の境界は受信調整と監査です。exec が Gateway の Node 承認パスを通ることはありません。
インターネットポリシーはプロビジョニング時のプロバイダー判断です。環境プロファイルがボックス作成時に決定します（ファイアウォール／セキュリティグループ／送信経路なしのネットワーク）。任意で、ネットワーク接続可能なセットアップフェーズを設け、エージェントフェーズの前にプロバイダーが閉じることもできます。コアはランタイムのネットワーク切り替えを実装しません。
プロビジョニング時のボックス衛生：クラウドメタデータエンドポイントをブロックするか存在しないことを検証し、インスタンスプロファイル、継承された SSH エージェント、Docker ソケットを持たず、環境変数／ホームをクリーンにします。SSH ホスト鍵はプロビジョニング出力からピン留めします。
Gateway 側で行うすべての処理（プッシュ、PR、プロバイダー呼び出し）について、承認とポリシーは引き続き Gateway 上で実行されます。

侵害されたワーカーセッションの影響範囲は、同期されたワークスペースのコピーと、監査対象のプロキシチャネルが許可する範囲です。認証情報、直接ネットワーク、許可リスト外の Gateway サーフェスにはアクセスできません。

容量

Gateway は N 個のワーカーについて、すべてのプロンプトとトークンストリームを中継します。そのため v1 では、本番環境で発覚するのを待たずに容量モデルを明示します。Gateway ごとの同時ワーカー数制限、ストリームごとのクレジットウィンドウ（現在のイベントストリームキューは無制限で、Node ソケットのバッファ上限は低速なコンシューマーを強制切断するため、どちらも変更せずには使用できません）、バースト用の容量制限付きディスクスプーリング、および UI に表示されるバックプレッシャー状態を伴う負荷制限です。ワークスペース転送には独自の SSH チャネルを使用します。

ライフサイクル

アイドル時の自動停止と TTL は、固定定数ではなくプロバイダープロファイルのポリシーです。デフォルトは余裕を持たせ、明示的なキープアライブを備えます。数日間にわたる作業を第一級でサポートします（リースベースのバックエンド向けにプロバイダー renew が存在します）。ターン実行中または最近アクティビティがあったセッションは決して回収されません。
ワーカーの停止または回収時：配置は reclaimed に移行し、セッション行は維持されます。次のメッセージで新しいワーカーをプロビジョニングし、最後のチェックポイントから再同期します。会話が失われることはありません（Gateway 側のストア）。最後のチェックポイント以降のワークスペース変更は失われ、その旨が UI に表示されます。
初日からウォームリースを再利用します（対応プロバイダーの場合）。ブートストラップ後のイメージスナップショットは、v2 の高速起動経路です。

設定サーフェス

最小限かつオプトインです。プロバイダープロファイルブロック（プロバイダー ID、認証情報／CLI 参照、同期ルール、存続期間ポリシー、予算、任意のセットアップフェーズ）と、セッションごとの配置選択で構成されます。新しい環境変数は追加しません。未設定のインストール環境には何も表示されません。

マイルストーン

実装は、小規模で個別にマージ可能な PR として投入します。以下の各マイルストーンは、1つの変更ではなく一連の PR です。

基盤：環境ステートマシン + プロバイダー契約 + crabbox 形式のプロバイダー（開発ハーネスとしての静的 SSH）、ワーカーバンドルのブートストラップ + 受け入れハンドシェイク、SSH トンネル + ホストキーピンニング、管理対象ワークツリーのスナップショット + 外向き同期（git + プレーンモード）。孤立環境のスイープ + 再起動後の引き継ぎ。
ワーカープロトコル + ワーカーループ：認証済みワーカーロール、永続的な操作／エポック／ACK カーソル、トランスクリプトのコミット + ライブイベント契約、Gateway で解決されたモデルを使用する推論プロキシ、フロー制御。プロバイダーは 1 つ、新規セッションのディスパッチは人間のみ、ハンドオフなし。障害注入テスト（トンネル分断、Gateway 再起動、ワーカー停止）を終了条件とする。
ディスパッチ + プルバック + エージェントディスパッチ：移行バリア、UI ターゲットバーに接続された配置ステートマシン、受信側の整合 + チェックポイント、環境ごとの監査、容量制限、エージェントディスパッチツール（ワーカーセッションは再帰不可）。プロンプトキャッシュのバイト等価性テスト。
マイルストーン 3 の障害注入による実証後に、対称型ライブハンドオフ。

今後：環境ごとの認証情報ハイドレーションをオプトインとしてワーカー上で動作する ACP ハーネス、スナップショット／ウォームイメージによる高速起動、ファンアウト（N 個のリース、同一プロンプト）、ボックス内 OS サンドボックス、アーティファクトスキーマを使用したより充実したアーティファクト取得。

未解決の事項

ワーカー上での Plugin／Skills の可用性：リポジトリに含まれる Skills はワークスペースと追加コストなしで同期される。Gateway で構成されたエージェントの Skills／Plugin については、明示的に同期するか除外するかを決定する必要がある（いずれの場合も、ツール／Plugin マニフェストは受け入れハンドシェイクの一部となる）。
チェックポイント頻度のデフォルト：非常に発話量の多いセッションでは、ターンベースか時間ベースか。
環境プロファイルとマルチエージェントルーティングの連携方法（エージェントごとのデフォルトプロファイルか、セッションごとの選択のみか）。

Was this useful?