セルフホストの全体像

Agent Fleet を自分の基盤で動かすときに、何ができて、何を用意し、運用する人が何に責任を持つのかをまとめています。採用を判断する前と、初めて建てる前に読んでください。

全体像

運用する人がやること	Agent Fleet がやること
ホストを用意し、設定と秘密を決めて起動する	Control Plane がサインイン・テナントとメンバーの管理・ワークスペースの起動と停止を受け持つ
サインインの方法と、入れる人を決める	許可リストと名簿に載っていない人を入れない
バックアップを取り、鍵を守り、アップグレードする	永続データをすべて `DATA_DIR` の下に置く
メンバーを迎え入れる	各メンバーに隔離されたワークスペースを用意する。エージェントの席は各メンバーが自分でログインする

できること

チームが CLI のコーディングエージェントをブラウザから使えます
各メンバーは隔離された環境（専用のコンテナ）を持ち、リポジトリをクローンして、エージェントやシェルのセッションを動かします
端末に触りたくない人向けに、チャット中心の使い方もあります
管理者はブラウザから、メンバーの追加・上限の設定・使用状況と監査ログの確認・外向き通信先の観測ができます
部署を テナント で分けると、ワークスペースは完全に隔離されます。既定は 1 テナントです

用意するもの

もの	用途
Docker の動く Linux ホスト（Docker Engine と `docker compose`）	1 台で足ります
公開ドメインと、そこを指す DNS	TLS の証明書を自動で取得します。公開 DNS を用意できない閉域の配備には、自己署名の代わりがあります（テナントとプロビジョニングの方式を決める）
サインイン用のプロバイダ	Google の OAuth クライアント、または Entra ID・Okta・Keycloak・Auth0・Cognito・GitLab の OIDC アプリ。いくつ有効にしても、登録するリダイレクト URI は 1 つです
エージェントの席	各メンバーが持ち込みます。初回の起動のあと、各自が自分の席でログインします。個人プランより、会社の Team / Enterprise の席をおすすめします

ほかの形態（AWS・Kubernetes・Docker のない機械）はデプロイ先を選ぶで選びます。

1 社 1 配備で守る

各社が自社の基盤に、独立した配備を建てます
会社どうしの隔離は、配備が別であること で保証します。プロセスの中の境界には頼りません。侵害されても、影響はその配備の中に閉じます
AWS では、配備ごとに AWS アカウントを分けている場合に限ります（脅威モデルと残るリスクを知る）
ワークスペースの中の境界は、エージェントが 任意のコードを実行する 前提で作っています。守っているのは、ほかのユーザーのデータ・Control Plane とホスト・秘密・持ち出しです

採用の前に読むリスク

残るリスクが 4 つあり、脅威モデルと残るリスクを知ると SECURITY.md に書いています。採用を判断する前に、必ず読んでください。

リスク	意味
`docker.sock`	触れる人はホストの root と同じことができます
`AF_MASTER_KEY` の紛失	保存した資格情報がすべて、二度と復号できなくなります
バックアップ	中身は機微な情報です
ホストへのアクセス	すべての権限を持つのと同じです

頭に入れておく最小のモデル

1 台のホストで docker compose が管理するのは、次の 2 つのサービスだけです。

サービス	役目
Control Plane	サインインの認証、テナントとメンバーの管理、ワークスペースの起動と停止、すべての API の中継
Caddy	入口。TLS の証明書を自動で取得・更新し、背後の Control Plane へ流します

メンバーのワークスペースのコンテナは、compose の管理下にありません。 Control Plane が実行中に起動します。そのため、次のことが起きます。

docker compose down や Control Plane の再起動では、ワークスペースは止まりません。メンバーの接続も切れません
バックアップのために Control Plane を一時停止しても、動いているワークスペースには影響しません
compose を止めても全部は止まりません。全ワークスペースを強制停止するのは別の操作です（アイドル停止と強制停止を使う）

データの置き場所

永続データはすべて DATA_DIR の下にあります。データベース、各メンバーのホーム、暗号化した資格情報、Caddy の証明書です
バックアップするのはこのディレクトリです
例外は AF_MASTER_KEY だけです。DATA_DIR にもバックアップにも入れません

破ると気づかないうちに壊れる 3 つの制約

コンテナからホストの Docker を動かすので、次の 3 つを守る必要があります。compose の定義が守っていますが、手で変えるときは注意してください。

ホストネットワーク
DATA_DIR の絶対パスが、ホストとコンテナで同じであること
docker グループの GID

症状から読む説明は症状から原因を探すにあります。

責任のチェックリスト

AF_MASTER_KEY を データとは別の金庫 に置き、独立にバックアップした。なくすと、保存した資格情報がすべて復号できなくなる
backup.sh を定期的に実行し、保管先を権限と暗号化で守っている
復元の手順を 一度は実際に試した（DATA_DIR の basename の制約も含めて）
アップグレードの前に、毎回バックアップを取っている。ダウングレードはできない
サインインの許可リストを設定した。空のままだと、誰もサインインできない
Entra ID を使うなら、issuer を自社テナントの GUID に固定した。common のエンドポイントのままだと、すべての Microsoft アカウントがサインイン画面まで進める
ホストで SSH・sudo・docker を使える人を最小限にした。これはホストの root と同じ権限になる
外向き通信の統制を入れるなら、段階を理解した。まず log-only で観測し、それから enforce にする
脆弱性を見つけたときの報告の手順を知っている（SECURITY.md）

コマンドの場所

この棚ではコマンドを繰り返しません。コマンドは操作する対象の隣にある runbook にあり、リリースのバンドルにも入っています。ワークスペースの中では、同じファイルが operate/runbooks/ に置かれ、コンテナからも読めます。

形態	runbook
compose（既定）	deploy/compose/README.md
native	deploy/native/README.md
個人の WSL2	deploy/local/README-wsl.md
ecs / ecs-ec2	deploy/aws/ecs/README.md
ec2-single	deploy/aws/ec2-single/README.md
kubernetes（プレビュー）	deploy/kubernetes/README.md

この棚の説明と runbook のスクリプトが食い違ったら、正しいのはスクリプトです。

エージェントが自律して動くことについて

エージェントはメンバーに代わって、コマンドの実行・ファイルの編集・コミットとプッシュをします
人が見ていないとき（停止中のワークスペースを起こす定時実行）、権限の確認を省くモード、受け取った文字列をそのまま実行するシェルや SSM のセッションでも動きます
その操作は破壊的なことや取り消せないことがあり、つないだ AI プロバイダやクラウドのアカウントに費用がかかることもあります
運用する人と各メンバーは、自分がつないだワークスペース・資格情報・リポジトリ・基盤と、エージェントのしたことを確かめる責任を持ちます。権限を絞った資格情報を使い、バックアップを取り、破壊的な操作には承認を挟んでください
Agent Fleet は Apache License 2.0 で配布され、無保証です。使って生じた損害・データの消失・停止・費用について、作者は責任を負いません。LICENSE と、同梱の OSS の表示は NOTICE を見てください

エージェント向け

この指示をエージェントに送ると、このページを読ませられます。

https://agent-fleet.org/docs/ja/operate/overview/index.md を読んで