配備形態 — どこに何が在るか
コアはどの形態でも同じで、変わるのは周縁のアダプタだけです。だから差は小さく具体的で、 だからこそ正確に書く価値があります。ここで「うちの配備では動く」は最も高くつく ドキュメントの誤りです。
| 形態 | ワークスペースの実体 | ホームの置き場 | 選ぶとき |
|---|---|---|---|
| docker | ホストの Docker デーモン上のコンテナ | ホスト上の bind mount したディレクトリ | オンプレの既定。1 台をチームで共有する |
| native | Docker を使わない、サンドボックスされたホストプロセス | ホスト上のディレクトリ | Docker を入れられない（素の WSL2 など）。単独利用のみ。コンテナ境界が無いので、共有モードでは起動を拒否する |
| ecs | AWS ECS / Fargate のタスク | EFS | AWS で、インスタンスを管理したくない |
| ecs-ec2 | プールから取った EC2 スロット上のタスク | ユーザー毎の EBS ボリューム | AWS で、起動レイテンシとディスク性能がインスタンス管理に見合う、または起動が多く Fargate の NAT 経由イメージ取得費用が無視できない（デプロイ先を選ぶ） |
| kubernetes | Kubernetes クラスタ上の、ワークスペース専用の StatefulSet の Pod | ユーザー毎の永続ボリューム（ブロックストレージ）。ログインと Claude の状態はもう 1 本の専用ボリューム | プレビュー。 すでに Kubernetes を運用している、または Google Cloud で、使わないときは 0 台に縮むワークスペースが欲しい。最初に検証するクラスタは GKE Standard |
プレビュー。
kubernetesランタイムはプレビューです。GKE Standard クラスタで受け入れを確かめて いますが、本番での利用はまだサポートしていません。既知の制約：このランタイムにはブラウザ機能が ありません（ブラウザペインもヘッドレス Chromium もなし）。ホームは 1 つのゾーンに置かれ、 バックアップされません。GKE では、始める前にリージョンの SSD ディスク割り当てが配備に足りている 必要があります（Preconditions）。ロードバランサは、 タイムアウトの設定にかかわらず、使用中の WebSocket を 24 時間で切ります （7. The load balancer）。切れたあとの ターミナルペインには[disconnected]と出て、クリックするかタブに戻るとつなぎ直します。シェルと その tmux セッションは動き続けます。これは接続を強制的に切って確かめたもので、1 日待って確かめた ものではありません。GKE で実測した費用は The bill に あります。試用や 1 チームで使うなら、deploy/gcp/gkeの小さなゾーン構成（1 ゾーン、データベースの 待機系なし）で、請求先アカウントの GKE の無料枠が残っていれば既定の構成の床のおよそ半分になります（ほかの クラスタが無料枠を使っていれば、およそ 3 分の 2）。請求額ではなく、実測した単価からの見積もりです。数字と その前提はdeploy/gcp/gke/README.mdの「Small profile」にあります。
Mac（Apple Silicon）では。 docker は Docker Desktop・OrbStack・colima の上で
deploy/compose/docker-compose.macos.yml を重ねて動き、native は Linux VM（Lima または OrbStack の
マシン）の中で linux-arm64 パッケージとして動きます。どちらも macOS そのものの上では動きません。
単独利用のみで、127.0.0.1 で使います。何を確認したか・いつ確認し直すかは
deploy/macos/README.md、手順は
deploy/compose/README.md の「macOS」にあります。
docker は local、ecs は aws、native は wsl、kubernetes は k8s という綴りでも通ります。
それ以外は起動時に失敗します（知らないうちに docker に切り替わったりしません）。
ecs と ecs-ec2 をフラグでなく別プロファイルにしてあるのは意図的です。EC2 プールは
「実績のある 2 リソースのワークスペース」を「6 リソースのもの」に取り替えるので、
配備は明示的に選び、コードを戻さずこの 1 つの値だけで元に戻せるようにしてあります。
| 機能 | docker | native | ecs | ecs-ec2 | kubernetes（プレビュー） |
|---|---|---|---|---|---|
| 複数ユーザーの相互不可視な利用 | ✓ | — | ✓ | ✓ | ✓ |
| ユーザー毎の CPU / メモリ上限 | ✓ | — | ✓ | ✓ | ✓ |
| ユーザー毎のディスクサイズ指定 | — | — | ✓ | ✓ | ✓¹¹ |
| アイドル自動停止 | ✓ | ✓ | ✓ | ✓ | ✓ |
| ホームを保ったまま停止 / 再開 | ✓ | ✓ | ✓ | ✓ | ✓ |
| コンテナ内のユーザーガイド | ✓¹ | ✓¹ | ✓² | ✓² | ✓² |
| ブラウザペイン | ✓ | ✓³ | —¹² | ✓ | —¹² |
| メンバー毎の費用の按分 | — | — | ✓ | ✓ | — |
| 配備が提供する画像エンジン | ✓⁴ | ✓⁴ | — | ✓⁵ | ✓⁴ |
| 配備が提供するチャットエンジン | ✓⁶ | ✓⁶ | — | ✓⁶ | ✓⁶ |
| メンバー自身による作り直し・ホームの掃除（危険な操作） | ✓ | ✓ | ✓⁷ | ✓¹⁰ | ✓¹³ |
| 管理者によるホームの掃除（退職処理） | ✓ | ✓ | ✓⁷ | ✓⁸ | ✓¹³ |
| メンバーのホームのバックアップの削除 | — | — | — | ✓⁹ | — |
| Control Plane が封じる秘密をクラウドの鍵サービス（AWS KMS）で守る | — | — | ✓¹⁴ | ✓¹⁴ | — |
¹ ホスト側でステージして、起動時に bind mount する。
² タスクへ mount できるホスト経路が無いので、コンテナが Control Plane の内部 エンドポイントから同じツリーを取りに行く。ツリーは 1 つ、配り方が 2 つ。
³ native が使う lean イメージは Chromium を焼いていないので、初回にオンデマンドで
取得する。
⁴ 自分の網の中ですでに動いている ComfyUI を、環境変数 1 つで指すか、 LAN の ComfyUI・借りたエンジン・OpenAI 互換のサーバを、エンジンの行として並べる （operate/08）。
⁵ フリート自身の GPU を、要求が来たときに買う。Fargate に相当するものは無い。 なおどの形態でも、セッションはメンバー自身の CLI のプラン（Codex / Antigravity）で画像を生成できる。この行が指すのは配備が提供するエンジンの ことである。
⁶ ecs-ec2 ではフリート自身の GPU。docker・native・kubernetes では、自分の網の中ですでに
動いている llama.cpp を環境変数 1 つで指す（operate/10）。
⁷ Control Plane 自身はメンバーの EFS のホームをマウントできないので、スタックが宣言した短い
タスク（30-ingress の HomeOpsTaskDef）を起動し、それがファイルシステムをマウントして
ファイルを消す。Fargate のタスクは起動に数分かかるので、ボタンへの応答のあとで終わる。
メンバーの作り直しとホームの掃除は、ワークスペースが再び動き出すまで起動中のダイアログ
（「作り直し・ホームの掃除で消す分を home から削除しています」）を出す。削除に失敗したら
ワークスペースは停止したままで、理由を次の起動までメンバー本人と管理者のメンバー一覧の行に
表示する（失敗のあとで Control Plane が再起動しても消えない）。管理者によるホームの掃除と
Workspace の破棄はすぐに応答し、結果はタスクが終わった時点で監査ログに記録する。
破棄はメンバーの EFS のディレクトリも消すようになり、消せなかったものとして並べることは
なくなった。このタスクより前のスタック（AF_ECS_HOME_TASK が無い）では、これまでどおり
これらのボタンを出さない。ecs-ec2 ではホーム自体は EBS にあるが、Claude の状態と、残す
ログイン・接続は EFS にある。Workspace の破棄はそれらを同じタスクで消すので、こちらでも
すぐに応答し、結果を監査ログに記録する。
タスクの実行中は、Control Plane が再起動しても、その home の起動と 2 つ目の操作を断る。
操作はタスクの起動前に Control Plane のデータベースへ記録するので、途中で再起動しても何も
失われない。戻ってから 1〜2 分のうちに Control Plane がその操作を拾い、タスクの終了を待つ
（起動の応答が失われていたら同じリクエストトークンで ECS に起動を頼み直す。ECS は 2 つ目を
起動せず、すでに起動したタスクを返す）。そのうえで残りを片付ける。メンバーのワークスペースを
起動し（その間にメンバーが削除されていれば起動しない）、失敗ならその理由を表示し、監査ログに
結果を記録し、破棄なら Workspace の行を消す。それまでの起動は上のとおり断る。タスクがどう
終わったかはタスク自身のログ（ワークスペースのロググループ、ストリームの接頭辞 home-ops）にある。
home が解放されるのは、Control Plane がそのタスクの停止を見たときだけである。ECS がタスクを
報告しなくなったときや起動の応答が失われたときは、同じトークンで ECS に頼み直す。最初の要求から
23 時間のうちなら、すでに起動したタスクが返る（それが終わっていれば削除をもう一度実行する。消すのは
その操作が消すものだけで、その間に home を起動できた者はいないので安全である）。運用者が要るのは
2 つの場合だけで、どちらも Control Plane のログが示す。このバージョンより前の Control Plane が
残した拒否（記録を持たない）と、要求から 23 時間を過ぎてもタスクの停止を見ていない場合（頼み直しが
2 つ目を起動せず同じタスクを返すことを ECS がもう保証しない）である。af-home/<membership> が
起動したタスクが動いていないことを ECS で確かめた運用者が SSM パラメータ
/af-ws/<workspace>/home-task を削除する。後者ではそのあと Control Plane が自分で操作を終える。
⁸ メンバーのホームのボリュームと、その休眠コピーを削除する。次の起動では新しいメンバーと 同じように新しいホームが作られる。この形態ではログイン・接続・Claude の状態はボリュームの外の EFS にあるので、ほかの形態と同じく残る。ただし、その中のファイルを前回の起動のあとで ツールが置き換えていた場合、そのファイルは次の起動までボリューム側にあり、ボリュームと一緒に消える。
⁹ ホームのバックアップを取るのは ecs-ec2 だけで、それも運用者がバックアップを有効にしたとき
だけ。ホームの掃除はバックアップを消さない。消すのはメンバーの詳細画面にある別の操作で、
ワークスペースの破棄でも消える。
¹⁰ 要求はホームに印を付けて戻り、それに続く起動が、ホームをマウントした後・ワークスペースが
動き出す前にファイルを消す。そのため起動中のダイアログには削除が起動の一段として出て、
ホームが大きいほどその起動は長くなる。メンバーのマシンが眠っていても、ホームが外れていても、
休眠コピーとして片付けられていても効く。削除に失敗したらワークスペースは停止したままで、
次の起動がやり直す——消すはずのものを残したまま起動することはない。起動がまだ進んでいる間は、
何も止めずにどちらも断るので、起動し終わってから押し直す。ホームの掃除はログインと
接続を名前で残し、前回の起動のあとでツールが置き換えたものも残る。ホームの掃除のあとの最初の
起動では、docker と同じくエージェント CLI を入れ直す。
¹¹ ホームのボリュームの大きさ。増やせるが、減らせない。
¹² ブラウザ機能は一切無い（ブラウザペインも、Chromium の接続も、ヘッドレス Chromium も無い）。
kubernetes では、ワークスペースの pod の Pod Security restricted レベルにより、Chromium の
サンドボックスが setuid のヘルパーもユーザー名前空間も使えない。ecs（Fargate）ではタスクに
SYS_ADMIN を足せないため、既定の seccomp が名前空間を断り、setuid ヘルパーが使える capability も
無い。サンドボックス無しで動かすことはしないと決めた（ADR 0106 の 2026-10-04 の追記）。
ecs-ec2 はブラウザを使える：docker と同じく、タスクに SYS_ADMIN を足している。Console は入り口を押せない状態にして理由を示す。軽量プレビューは使える
（browser-pane.ja.md）。
¹³ メンバーの作り直しとホームの掃除はホームに印を付けて戻り、次の起動がワークスペースが動き出す
前にファイルを消す（ecs-ec2 と同じ）。管理者によるホームの掃除は、ワークスペースを止めた状態で
その場で消す。どちらもログイン・接続・Claude の状態を残す。これらは専用の 2 本目のボリュームに
あるからだ。ホームのボリューム自体は残る。
¹⁴ 既定はオフで、運用者がスタックで有効にする（保存時の鍵を AWS KMS にする）。
有効にすると、切り替え後に Control Plane 自身が封じる秘密（MCP 接続のヘッダ、サインインのクライアント
シークレット、エンジンのトークン、セッションの引き継ぎと共有）は AWS KMS の鍵で封じられ、KMS 鍵を無効に
すると読めなくなる。メンバーが保存した資格情報の鍵が KMS で包まれるのは、切り替え後に鍵が初めて保存される
ワークスペースだけで、しかも既存のストアを開けるよう今も AF_MASTER_KEY から導かれるので、こちらは
マスター鍵だけで足りてしまう。AF_MASTER_KEY はどの配備先でも
引き続き必須。
手順の在り処
Section titled “手順の在り処”コマンドは runbook にあり、runbook は操作する対象の隣に置いています。何が起きるか、何に気をつけるかは operate/ で説明します。
| 形態 | runbook |
|---|---|
| docker（compose） | deploy/compose/README.md |
| native | deploy/native/README.md。個人の WSL2 は deploy/local/README-wsl.md |
| ecs / ecs-ec2 | deploy/aws/ecs/README.md |
| compose を EC2 1 台に載せる | deploy/aws/ec2-single/README.md |
| kubernetes（プレビュー。GKE、およびほかのクラスタ） | deploy/kubernetes/README.md |
ec2-single は別の runtime プロファイルではありません。VM 上の docker です。
「AWS を使う」と「インスタンスを自分で管理する」が独立した選択だから存在します。
どの形態でも同じもの
Section titled “どの形態でも同じもの”ワークスペースのイメージと、その中のエージェントは、どの形態でも同一の成果物です （分離の目的がまさにこれ）。本当に差が出るのは隔離の強度・ストレージ性能・egress の 統制手段で、これらは Agent Fleet の性質ではなく基盤の性質です。