clawops

clawops

OpenClaw 向けの MCP ネイティブなインフラ運用ツールです。読み取り専用モード、破壊的な操作の確認、監査ログを標準で備えています。

clawops は、セルフホスト可能な OpenClaw インスタンスをデプロイして運用するための CLI と MCP サーバーです。AWS、GCP、Azure、または任意の Linux VM にプロビジョニングし、ターミナルから日々の運用を管理できます。また、Claude Code や Cursor から、明示的な安全制御を備えた型付き MCP ツールを使って操作することもできます。

---

新着情報： 2.4 リリースノートと、全変更履歴はCHANGELOG.mdをご覧ください。

---

対象ユーザー

• OpenClaw ユーザー：クラウドやローカル VM でのセルフホストを簡単に始めたい方。デプロイ、ステータス確認、ログ、バックアップ、アップグレードを単一の CLI で確実に実行できます。
• Claude Code／Cursor／MCP ユーザー：MCP を使った安全なインフラ運用の実践的なリファレンス実装をお探しの方。型付きツールスキーマ、読み取り専用モード、破壊的な操作の確認、監査ログを備えています。
• セルフホスト型 AI やローカルファーストの開発者：Kubernetes、マネージド SaaS プラットフォーム、単一のクラウドプロバイダーに依存せず、自分の AI アシスタントを実行したい方。

---

clawops の機能

• Pulumi Automation API を使って、AWS、GCP、Azure、ローカル VM 上の OpenClaw インフラをプロビジョニングおよび削除します。Pulumi をインストールする必要はありません。初回使用時に、必要な CLI を ~/.clawops/.pulumi-cli にインストールします。
• 日々の運用を管理します：ステータス、ログ、SSH、トンネル、設定、エージェント、ゲートウェイ、バックアップ。
• すべての操作を型付き MCP ツールとして公開し、AI エージェントが安全に運用できるようにします。
• クラウドへのデプロイでは、計画 → レビュー → 適用の手順を徹底します。
• すべての操作で JSON 出力（--json）に対応し、スクリプトや自動化に利用できます。
• クラウド認証情報は保存しません。環境に設定済みの CLI プロファイルから読み取ります。

clawops が行わないこと

• 高可用性やクラスタリングには対応しません。 単一ノードのデプロイに最適化されています。
• Kubernetes には対応しません。 コンテナオーケストレーションプラットフォームではなく、VM にデプロイします。
• OpenClaw のスキルやエージェントの作成は行いません。 clawops が管理するのはインフラです。その上で実行するものは、ユーザーと OpenClaw に委ねられます。
• TLS やドメインの自動化にはまだ対応していません。 リバースプロキシはご自身で用意するか、手動での手順についてはdocs/limitations.mdをご覧ください。
• 認証情報は保存しません。 clawops を使う前に、クラウド認証情報を環境に設定する必要があります。認証情報が ~/.clawops/config.json に書き込まれることはありません。
• ネイティブ Windows には対応しません。 WSL2 は完全にサポートされています。詳しくはdocs/support-matrix.mdをご覧ください。

---

クイックスタート

npm install -g @clawops/cli
clawops setup

clawops setup は、約 2 分で OpenClaw を稼働させる対話型ウィザードです。設定ファイルを手作業で作成したり、コマンドを覚えたりする必要はなく、すべての作業を一度に完了できます。

ウィザードの内容

ステップ 1．デプロイ先を選択する

SSH で接続できる既存のサーバー（Linux または macOS）か、AWS、GCP、Azure 上の新しいクラウド VM を選択します。クラウドへのデプロイでは、まだサインインしていない場合、プロバイダーの CLI で認証する手順が案内されます。

ステップ 2．LLM プロバイダーを選択する

Anthropic、OpenAI、Amazon Bedrock、Ollama などから選択します。ウィザードは API キーの入力を求め、ローカル（~/.clawops/secrets/、chmod 600）に保存します。設定の適用時に、接続先ホスト上の OpenClaw に送信される以外、キーが外部に送信されることはありません。

ステップ 3．チャット連携を追加する（任意）

Discord、Telegram、Slack、WhatsApp、Teams を任意に組み合わせて選択します。ウィザードは API キーと同じ方法で、各連携のボットトークンを収集します。トークンを貼り付けるか、環境変数を参照するか、ファイルを指定できます。

ステップ 4．AI エディターを接続する

clawops へのアクセスを許可する AI アプリを選択します。Claude Desktop、Claude Code、Cursor、Windsurf、VS Code、Zed に対応しています。ウィザードは絶対バイナリパスを使って各アプリの設定ファイルに MCP サーバーのエントリを書き込み、アプリが個別に起動できるようにします。

ステップ 5．デプロイする

ウィザードは SSH 経由で接続先ホストに OpenClaw をセットアップし（Docker のインストール、イメージの取得、コンテナの起動）、LLM と連携の設定を適用し、ゲートウェイ認証トークンを生成して、ダッシュボードの直接 URL を表示します。

✔ All done! OpenClaw is running.
ℹ Open dashboard: http://192.168.1.50:18789?token=<your-token>
ℹ Token saved to ~/.clawops/secrets/GATEWAY_TOKEN_my-stack

前提条件： Node.js ≥ 22、SSH キー、SSH 接続可能な Linux/macOS ホスト、または CLI 認証情報が設定済みのクラウドアカウントが必要です（aws configure、gcloud auth login、または az login）。Pulumi は不要です。初回のクラウドデプロイ時に、clawops が使用する CLI を ~/.clawops/.pulumi-cli にインストールし、その旨をインストール中に表示します。

出力例付きの詳しい説明については、docs/demo-script.md をご覧ください。

---

手動セットアップ：既存サーバー

手順を細かく制御したい場合や、すでに稼働しているデプロイに clawops を追加する場合：

npm install -g @clawops/cli

clawops doctor   # verify environment

clawops init --provider local --host 192.168.1.50 --user ubuntu --key-path ~/.ssh/id_ed25519
clawops up       # installs Docker + OpenClaw over SSH
clawops status

SSH の前提条件、ファイアウォールのセットアップ、トラブルシューティングについては、docs/examples/local-vm.md をご覧ください。

手動セットアップ：クラウド（AWS）

npm install -g @clawops/cli

# Requires AWS credentials in your environment (AWS_PROFILE or ~/.aws/credentials)
clawops init --provider aws

# Edit ~/.clawops/config.json: set stateUrl to your S3 bucket

clawops plan --provider aws --stack default --ssh-cidr auto --out /tmp/plan.json
clawops apply /tmp/plan.json

--ssh-cidr auto を指定すると、プランの生成時に解決され、プランに書き込まれる、このマシンのパブリック IP から SSH 接続できるようになります。この指定がない場合、プランではインバウンド接続が一切許可されず、clawops を含め、何も接続できません。

---

AI エディターに接続する

setup ウィザードが自動的に処理します（ステップ 4）。エディターをいつでも接続または再接続するには、次を実行します。

clawops mcp install

ウィザードと同じ対話型チェックボックスが開きます。Claude Desktop、Claude Code、 Cursor、Windsurf、VS Code、Zed を選択すると、clawops が正しい絶対バイナリパスを使って 各アプリの設定に MCP エントリーを書き込みます。

代わりにエントリーを手動で追加するには、次の内容をエディターの MCP 設定に貼り付けます。

{
  "mcpServers": {
    "clawops": {
      "command": "npx",
      "args": ["-y", "@clawops/cli", "mcp", "serve", "--read-only"]
    }
  }
}

この形式は $PATH 上に何も必要とせず、ディレクトリやインストーラーがコピーするものです。 すでにあるバイナリを指定したい場合は、同じ引数を使い、which clawops の出力である 絶対パスを指定します。

{
  "mcpServers": {
    "clawops": {
      "command": "/path/to/clawops",
      "args": ["mcp", "serve", "--read-only"]
    }
  }
}

どちらの場合も、引数を渡してください。プロトコルを話すのは mcp serve であり、明示的な設定は 1 年後に読み返しても内容がはっきりわかります。引数を省略したクライアントが動かなくなることはありません。 コマンドを指定せず、標準入力がパイプの場合（すべての MCP クライアントがサーバーを起動する方法）、 clawops は mcp serve を起動し、その旨を標準エラー出力に表示します。ターミナルで clawops と入力すると、 これまでどおりヘルプが表示されます。

クラウド認証情報は env で渡してください。 クライアントは設定で指定された環境変数を使ってサーバーを起動するため、 シェルでエクスポートした AWS_PROFILE はクライアントに引き継がれません。その結果、スタックを読み取るすべての ツールで「Could not read the state of stack」というエラーが発生します。サーバーの env ブロックにプロファイル名、 または状態バックエンドで必要な変数を指定してください。

{
  "mcpServers": {
    "clawops": {
      "command": "npx",
      "args": ["-y", "@clawops/cli", "mcp", "serve"],
      "env": { "AWS_PROFILE": "my-profile" }
    }
  }
}

ここに保存されるのはプロファイル名で、キーではありません。認証情報そのものはクラウド CLI が保存する場所に留まります（R6）。

設定ファイルの場所：

アプリ	パス
Claude Desktop（macOS）	~/Library/Application Support/Claude/claude_desktop_config.json
Claude Desktop（Linux）	~/.config/Claude/claude_desktop_config.json
Claude Code	~/.claude.json
Cursor	~/.cursor/mcp.json
Windsurf	~/.codeium/windsurf/mcp_config.json
VS Code（macOS）	~/Library/Application Support/Code/User/mcp.json
VS Code（Linux）	~/.config/Code/User/mcp.json
Zed	~/.config/zed/settings.json（キー：context_servers）

まずは --read-only を指定してください。ステータス、ログ、設定の読み取り、診断が可能になり、変更操作はブロックされます。 docs/security/mcp-safety.md を確認してから、この指定を外してください。

破壊的なツール（clawops_destroy、clawops_up、clawops_config_set など）は、実行前に明示的な確認が必要です。 確認なしで実行されることはありません。

HTTP モードの設定については docs/mcp/ を参照してください。

---

日常の操作

clawops status              # Stack outputs: IP, gateway URL, SSH info
clawops logs -f             # Tail OpenClaw logs over SSH
clawops ssh                 # Interactive SSH session
clawops ssh --command "docker ps"

clawops config get maxAgents
clawops config set maxAgents 8

clawops tunnel              # Port-forward gateway UI to localhost

clawops destroy --yes       # Destroy cloud-provider stack
clawops down --yes          # Destroy local-provider stack

---

コマンド

コマンド	説明
setup	初回実行ウィザード：LLM、連携機能、支出上限、デプロイ計画の生成を順を追って設定します
init	プロビジョニングせずに、スタックを ~/.clawops/config.json に登録します。既存のスタックは保持され、設定は追加されます。上書きする場合にのみ --force が必要です
up	スタックをプロビジョニングまたは更新します（プレビューには --dry-run、デフォルト以外のポートには --gateway-port を指定します）
down	ローカルプロバイダーのスタックを破棄します（--yes が必要です。--dry-run で現在の出力を表示します）
destroy	クラウドプロバイダーのスタックを確認プロンプト付きで破棄します（--dry-run で現在の出力を表示します）
status	スタックの出力（IP、ゲートウェイ URL、リージョン、プロビジョニング時刻、およびスタックのホストエージェントからのリクエスト）を表示します
plan	デプロイ計画の JSON アーティファクトを生成します（ドライランで安全に実行できます）。接続を許可する相手は --ssh-cidr <list|auto> と --gateway-cidr で指定し、リッスンする対象は --publish-gateway loopback|all で指定します。テイルネット経由で到達するスタックのパブリックアクセスを閉じるには --private-only を指定します
apply	レビュー済みの計画ファイルを適用します（--dry-run では適用せず、検証して差分を表示します）
ssh	対話型 SSH セッションを開始するか、リモートコマンドを実行します
logs	OpenClaw のログをストリーミングします（-f、--tail N、--since 5m）
tunnel	SSH 経由でゲートウェイ UI へのローカルポートフォワーディングを行います
config	リモートの OpenClaw 設定値を取得・設定します（--dry-run で書き込まれる予定の JSON を表示します）
agents	OpenClaw エージェントを一覧表示するか、1 つのエージェントのログをストリーミングします
agent install	スタックのゲートウェイホストにホストエージェントをインストールします。インストール先は、オペレーターが到達できる OpenClaw エージェント 1 つのみです（--agent、--operator <channel>:<peer>、ハンドオフツールを指定する --allow、--strict）。ゲートウェイのルーティングでオペレーターのみが許可されていない場合は拒否されます。その他すべてのエージェントに対して clawops を拒否します。--serve-peers <tag> と --peer <stack>=<tailnet name> を指定すると、ホストをフリートメンバーにできます。フリートメンバーのホストエージェントは、テイルネット経由でピアを読み取ります（2.5、ADR 0015。Operations を参照）
agent uninstall	ホストエージェントを削除し、ゲートウェイとの接続を解除します（--purge を指定すると、その監査ログも削除します）
fleet status	すべてのスタックのホストに SSH 経由でアクセスし、ホストエージェントの状態（実行中かどうか、サービス対象の OpenClaw エージェント）を一覧表示します。フリートメンバーの場合は、タグ、ピア、ファイアウォールテーブル、テイルネットの状態も表示します。動作できないピアがある場合は、それを指定しているホスト上で報告します。--stack a,b を指定すると、対象のスタックのみを読み取ります。--json で JSON を出力します。何もデプロイされていないスタックも、その旨を表示します。いずれかのホストに問題がある場合、または応答しない場合は、終了コード 1 で終了します
gateway	OpenClaw ゲートウェイサービスを再起動します
backup	OpenClaw の状態バックアップを作成・復元します（restore はステージングディレクトリに展開し、元の場所には展開しません。--activate を指定すると入れ替えを行い、ゲートウェイが起動しない場合はロールバックします）
stacks	名前付きスタックとその状態を一覧表示します
doctor	ローカルマシンを確認します。--stack を指定するとデプロイの健全性も確認し、--provider を指定するとスタックの有無にかかわらず、1 つのクラウドの認証情報とアカウント設定を確認します。--instance-type を指定すると、アカウント確認ではプロバイダーのデフォルトではなく、そのサイズについて確認します。レポートを出力するには --json を指定します。失敗があれば終了コード 1 で終了します
secret	シークレットを管理します：list、set、delete、rotate、audit
monitor	ライブダッシュボードを表示します：ゲートウェイの健全性、コンテナー統計、ログの末尾、スタック選択
mcp serve	組み込み MCP サーバーを起動します（stdio、または --http <port> --token <t> を指定した HTTP）。--host-agent を指定すると、ゲートウェイホスト自身のエージェントを提供します（ADR 0014）
mcp install	AI エディターに clawops を対話形式で接続します
mcp wire	ゲートウェイの AI を clawops の MCP クライアントとして接続します（保存前に接続を検証します）
help	すべてのコマンドとグローバルフラグを一覧表示します
harden	デプロイ済みスタックにセキュリティ強化を適用します（SSH、UFW、fail2ban、unattended-upgrades、Docker ソケット。AWS：SG 監査、SSM チェック、Flow Logs、GuardDuty）。--tailscale を指定すると、スタックをテイルネットに参加させ、応答が確認できた時点で clawops をそのアドレスに切り替えます。--tailscale-revert で元に戻します
bug	doctor のシステム情報を含む、事前入力済みの GitHub イシューを作成します
完全なフラグリファレンス：clawops <command> --help

---

Plan → Apply ワークフロー

ローカル以外のプロバイダーでは、clawops は適用前にレビューする手順を徹底します。

# 1. Generate a plan: runs `pulumi preview` internally, produces JSON
#    --ssh-cidr decides who may connect. `auto` means this machine; omit it and nobody can.
clawops plan --provider aws --region us-east-1 --ssh-cidr auto --out /tmp/plan.json

# 2. Review plan.json: the `diff` field shows projected changes at plan-generation time
cat /tmp/plan.json | jq .diff

# 3. Apply: reads and validates the plan file, then runs `pulumi up`
clawops apply /tmp/plan.json

# Without --yes, apply prompts: "Continue? (y/N)"
clawops apply /tmp/plan.json --yes    # skip prompt in automation

プラン JSON は spec/deploy-plan.schema.json に準拠しており（AJV で検証済み）、レビュー済みの意図（プロバイダー、リージョン、インスタンスタイプ、CIDR 範囲、OpenClaw のバージョン）を記録します。apply は、これらのパラメーターを使って現在のライブ状態に対して pulumi up を再実行します。ロックされた実行アーティファクトを再生するわけではありません。ドリフトのリスクを最小限に抑えるため、同じセッション内でレビューと適用を行ってください。

詳細なセマンティクス、ドリフトに関するガイダンス、安全な CI パターンについては、docs/plan-apply.md を参照してください。

---

MCP サーバー

clawops には MCP サーバーが組み込まれています。Claude Code、Cursor、および MCP 互換のエージェントは、チャットインターフェースを離れることなくデプロイを実行できます。

エディターを接続する

clawops mcp install   # interactive checkbox: writes config for selected apps

ウィザードがバイナリの絶対パスを自動的に解決するため、アプリランチャーはシェルの PATH を引き継がなくても clawops を見つけられます。設定パスを手動で指定する方法については、上記のAI エディターを接続するを参照してください。

ゲートウェイ AI を接続する

OpenClaw ゲートウェイは独自の AI エージェントを実行します。接続すると、そのエージェントはインフラストラクチャの状態を推測する代わりに、clawops を直接呼び出せます。

clawops mcp wire --stack prod   # openclaw mcp add, which connects before it saves

ゲートウェイで OpenClaw 2026.7.1-2 以降が必要です。デプロイが成功すると、clawops setup ウィザードにこの手順が表示されます。

ゲートウェイ上のすべてのエージェントが、デフォルトエージェントを含め、すべての clawops ツールを使用できます。 デフォルトエージェントは、ゲートウェイにメッセージを送信できるすべてのユーザーに応答します。OpenClaw の MCP サーバーはゲートウェイ全体に適用されます。接続後、mcp wire によって clawops を呼び出せるようになった各エージェントの名前が表示されます。特定のエージェントに clawops を使わせない場合は、そのエージェントの agents.entries.<id>.tools.deny に "clawops__*" を追加してください。破壊的な変更を実行せず、あなたに判断を委ねるエージェントには、clawops agent install を使用してください。

Stdio モード（Claude Code / Cursor / VS Code）

サーバーを手動で起動するか、設定が正しいことを確認してください。

clawops mcp serve --read-only   # safe for first evaluation
clawops mcp serve               # full mode: enables provisioning, config write, ssh exec

HTTP モード（リモート／複数クライアント）

clawops mcp serve --http 3333 --bind 127.0.0.1
# MCP HTTP server listening on 127.0.0.1:3333

追加の認証制御を設けずに、ループバック以外のアドレスにバインドしないでください。

利用可能なツール

ツール	ツールセット	説明
clawops_status	cli	スタックの出力を表示します（デプロイされている内容であり、動作しているかどうかではありません）
clawops_doctor	cli	診断を実行します：ローカルの前提条件、およびスタックがある場合はリモートのヘルス状態
clawops_logs_tail	cli	OpenClaw のログを末尾から表示します
clawops_monitor	cli	ゲートウェイとホストのメトリクスをサンプリングします
clawops_stacks_list	admin	すべてのスタックとその状態を一覧表示します。fleet: true を指定すると、clawops fleet status が報告するすべてのホストエージェントとフリートのピアも表示します
clawops_config_get	cli	リモートの設定値を読み取ります
clawops_agents_list	cli	実行中のエージェントを一覧表示します
clawops_agents_logs	cli	1 つのエージェントの最近のアクティビティをページ単位で表示します
clawops_gateway_status	cli	ゲートウェイコンテナが実行中かどうか、およびそのイメージを表示します
clawops_secret_list	cli	保存済みシークレットを名前と状態で一覧表示します（値は表示しません）
clawops_secret_audit	cli	不足しているシークレットと解決できない $secret: 参照を報告します
clawops_up	cli	スタックをプロビジョニングまたは更新します
clawops_destroy	cli	スタックを破棄します（確認を求めます）
clawops_apply	cli	プランファイルを適用します
clawops_plan	cli	デプロイプランを生成します
clawops_config_set	cli	リモートの設定値を書き込みます
clawops_config_unset	cli	リモートの設定キーを削除します
clawops_config_validate	cli	デプロイ済みの設定を OpenClaw スキーマに照らして検証します
clawops_gateway_restart	cli	ゲートウェイを再起動します（確認を求めます）
clawops_gateway_update	cli	ゲートウェイを特定の OpenClaw バージョンに更新します（確認を求めます）
clawops_backup_create	cli	ゲートウェイの状態をローカルアーカイブにバックアップします
clawops_backup_restore	cli	バックアップをステージング環境に復元します。または activate を指定するとサービスに適用します（確認を求めます）
clawops_migrate	cli	1.x のデプロイを 2.0 ランタイムに移行します（確認を求めます）
clawops_stacks_delete	admin	設定からスタックの登録を削除します。インフラストラクチャは破棄しません（確認を求めます）
clawops_secret_delete	cli	保存済みのシークレットを削除します（確認を求めます）
clawops_harden	cli	セキュリティ強化モジュールを適用します。tailnet への参加または離脱を行います（確認を求めます）
clawops_init	cli	スタックを登録し、~/.clawops/config.json に書き込みます（クラウドリソースは使用しません）
clawops_workflow_deploy_app	workflow	エンドツーエンドのデプロイを実行します：プラン → 確認 → 適用 → 状態確認
clawops_workflow_recover	workflow	異常なスタックを診断します：状態、失敗したヘルスチェック、最近のログ、および各問題を修正するツール
clawops_task_status	cli	長時間実行タスクの状態をポーリングします

read ツールセットのツールは --read-only モードでも利用できます。表の「ツールセット」列には、主なツールセットが表示されています。それ以外のすべてのツールセットではフルモードが必要です。 破壊的な操作を行うツールでは、yes: true が渡されない限り、明示的な確認（エリシテーション）が必要です。

各ツールのリスク分類の詳細については、docs/security/tool-risk-matrix.md を参照してください。

---

設定

設定は ~/.clawops/config.json にあります（$CLAWOPS_HOME で上書きできます）。

{
  "version": 1,
  "defaults": {
    "provider": "aws",
    "stack": "default"
  },
  "stacks": {
    "default": {
      "provider": "aws",
      "region": "us-east-1",
      "stateUrl": "s3://my-clawops-state"
    }
  },
  "ssh": {
    "keyPath": "~/.clawops/id_ed25519",
    "knownHostsPath": "~/.clawops/known_hosts"
  }
}

クラウドの認証情報は設定に保存されません。Clawops は環境変数から認証情報を読み取ります。

プロバイダー	認証情報の取得元
AWS	AWS_PROFILE または標準の AWS 認証情報チェーン（~/.aws/credentials）
GCP	GOOGLE_APPLICATION_CREDENTIALS または gcloud auth application-default login
Azure	AZURE_CLIENT_ID / AZURE_CLIENT_SECRET または az login
ローカル	stacks[name].localOpts で設定された SSH ホストとキー

支出上限

任意の policy ブロックを設定すると、どのツールから要求された場合でも、このマシンから clawops がデプロイできる内容を制限できます。

"policy": {
  "allowedInstanceTypes": { "aws": ["micro", "small"] },
  "maxStacks": 3
}

plan、apply、up は、そのプロバイダーの allowedInstanceTypes に含まれないサーバーサイズを拒否します （clawops のサイズ名とプロバイダー独自のタイプ名のどちらも指定できます。AWS では small と t3.small は同じです）。また、 init は maxStacks を超える新しいスタックの作成を拒否します。デプロイを行うすべての MCP ツールに、同じ制限が同じ内容で適用され、 いずれのツールも制限を変更できません。clawops setup では、制限を設定するかどうかを尋ねたあと、許可したサイズのみが提示されます。 制限はプランではなく、ここに設定します。プランはエージェントが作成するものだからです。

---

既知の制限事項

全項目については docs/limitations.md を参照してください。主な点は次のとおりです。

• 単一ノードのデプロイのみに対応しており、高可用性やクラスタリングのプラットフォームではありません。
• clawops apply は不変なプランの実行ではありません。docs/plan-apply.md を参照してください。
• 現行リリースでは TLS／ドメインの自動化に対応していません。
• MCP ツールは特権操作を実行します。初回の評価では --read-only を使用してください。

---

アーキテクチャ

clawops
├── src/cli/          citty-based commands (one file per verb)
├── src/config/       ~/.clawops/config.json management
├── src/providers/    Cloud adapters (AWS, GCP, Azure, local)
│   ├── aws/          Pulumi inline program + ProviderAdapter
│   ├── gcp/
│   ├── azure/
│   └── local/        SSH bootstrap (no Pulumi)
├── src/pulumi/       Pulumi Automation API wrapper + output helpers
├── src/transport/    SSH client (ssh2) + connection pool + tunnels
├── src/mcp/          MCP server, tool handlers, progress tracking
├── src/plan/         Maker plan generation, AJV validation, apply
├── src/output/       ASCII table, spinner, JSON, human-readable output
├── src/errors/       Typed error hierarchy with exit codes
└── spec/             Machine-readable ground truth (JSON Schema, YAML)

主な設計上の決定事項：

• Pulumi Automation API： ユーザーが Pulumi をインストールする必要はありません。Clawops は、API が操作する CLI をバンドルされた SDK に固定して ~/.clawops/.pulumi-cli にインストールし、$PATH は編集しません（ADR 0010）。Pulumi のホームディレクトリは ~/.clawops/.pulumi にサンドボックス化され、スタックプログラムはインラインの TypeScript クロージャーです。
• クラウドの BLOB ストレージに状態を保存： GCS（gs://）、S3（s3://）、Azure Blob を使用し、ローカルの状態ファイルや pulumi.yaml は使用しません。
• ssh2 による SSH： /usr/bin/ssh をシェルから実行することはありません。~/.clawops/known_hosts に対して TOFU でホストを検証し、接続プールのアイドル TTL は 5 分です。
• プラン → 適用の手順： ローカル以外へのデプロイはすべて generatePlan() → レビュー → applyPlan() の手順で行います。破壊的な変更には、必ず人間によるプラン JSON のレビューが必要です。
• MCP を優先： すべての CLI 操作に型付き MCP ツールがあり、スキーマは spec/mcp-tools.yaml から生成されます。破壊的な操作を行うツールはすべてエリシテーションを使用します。

詳細な説明は docs/architecture.md を、ADR については docs/decisions/ を参照してください。

クラウドプロバイダーのスタック

各クラウドプロバイダーは、以下のリソースを作成するインラインの Pulumi プログラムです。3 つすべてで同じ出力（publicIp、gatewayUrl、sshHost、sshPort、sshUser）を使用し、SSH レイヤーと設定オーバーレイレイヤーに渡します。

AWS

flowchart LR
    subgraph NET["Networking"]
        VPC["VPC (10.0.0.0/16)"]
        IGW[Internet Gateway]
        SUBNET["Subnet (10.0.1.0/24)"]
        RT[Route Table]
        SG["Security Group (ports 22, 18789)"]
    end
    subgraph IAM["IAM"]
        ROLE[IAM Role]
        SSM[SSM Policy Attachment]
        BED["Bedrock Policy Attachment (optional)"]
        IP[Instance Profile]
    end
    subgraph COMPUTE["Compute"]
        KP[EC2 Key Pair]
        EC2["EC2 Instance (Ubuntu 22.04, IMDSv2)"]
        EIP[Elastic IP]
    end

詳細な図 →

GCP

flowchart LR
    subgraph NET["Networking"]
        NW[VPC Network]
        SN["Subnetwork (10.0.0.0/24)"]
        FW1["Firewall: SSH port 22 (conditional)"]
        FW2["Firewall: Gateway port 18789 (conditional)"]
        ADDR[Static External IP]
    end
    subgraph COMPUTE["Compute"]
        VM["Compute Instance (Debian 12, 20 GB)"]
    end

詳細な図 →

Azure

flowchart LR
    RG[Resource Group]
    subgraph NET["Networking"]
        VNET["Virtual Network (10.0.0.0/16)"]
        SUBNET["Subnet (10.0.1.0/24)"]
        NSG["Network Security Group (ports 22, 18789)"]
        PIP["Public IP Address (Static)"]
        NIC[Network Interface]
    end
    subgraph COMPUTE["Compute"]
        VM["VM (Ubuntu 22.04, managed identity)"]
    end
    subgraph KV["Key Vault (optional)"]
        VAULT["Key Vault (RBAC, name max 24 chars)"]
        RA["Role Assignment (Secrets User)"]
        SECRET["Secret: gateway-token"]
    end

詳細な図 →

---

開発

セットアップ

git clone https://github.com/dfridkin/clawops.git
cd clawops
# Node 22+ required; use nvm: nvm use
pnpm install
pnpm dev doctor        # verify toolchain

スクリプト

pnpm dev                   # run CLI from src/ via tsx
pnpm build                 # tsup → dist/
pnpm test                  # vitest (2420 tests, ~14s)
pnpm test:changed          # vitest --changed (fast edit loop)
pnpm test:integration      # Docker-based SSH integration tests
pnpm test:e2e:local        # builds, then bootstrap, the host-touching MCP tools and a 1.x migration, in systemd containers
pnpm test:e2e:fleet        # builds, then a two-host fleet on a Headscale tailnet (about 10 GB of images; CI runs it)
pnpm typecheck             # tsc --noEmit
pnpm lint                  # eslint src/ tests/ scripts/ (--max-warnings=0)
pnpm gen:schemas           # regenerate src/providers/types.ts + src/mcp/tools/_generated.ts
pnpm gen:schemas --check   # CI guard: committed generated files match spec
pnpm graph                 # local coupling report (--base <ref> for this branch's delta)
pnpm verify:pack           # install the packed tarball elsewhere and run it (CI gate)
pnpm sync:server-json      # write package.json's version into server.json
pnpm changeset             # record a release note before merging

プロジェクト構成

パス	用途
spec/	機械可読な正となる仕様：JSON Schema、YAML。正の情報源として扱ってください。
SPEC.md	技術仕様の全容（マイルストーン、ルール、スキーマ）
DESIGN_RULES.md	コードベース全体で参照される 25 個の規範的ルール（R1～R25）
docs/architecture.md	システムの概要説明
docs/plan-apply.md	プラン／適用のセマンティクス、ドリフトへの対処、CI パターン
docs/ci.md	CI 統合ガイド：OIDC、環境変数、CI でのプラン → 適用
docs/security/	MCP の安全性モデル、ツールのリスクマトリックス、編集・監査ログ
docs/providers/matrix.md	プロバイダー別の機能マトリックス
docs/decisions/	アーキテクチャ決定記録
.claude/skills/	呼び出し可能な手順：/add-provider、/release、/tdd、/mcp-tool
.claude/rules/	Claude Code が読み込む、パスごとの Lint ルール

コード生成

以下の 2 つのファイルは spec/ から生成されるため、手動で編集してはいけません。

• src/providers/types.ts。spec/providers.schema.json から生成される ProviderAdapter インターフェース
• src/mcp/tools/_generated.ts。spec/mcp-tools.yaml から生成される Zod スキーマと型エクスポート

いずれかの仕様ファイルを変更した後は、pnpm gen:schemas を実行してください。CI では --check を使ってこれを強制します。

プロバイダーの追加

Claude Code の /add-provider スキルを使うか、src/providers/CLAUDE.md に従ってください。すべてのアダプターは src/providers/types.ts の ProviderAdapter を満たす必要があります。アダプターに合わせるためにスキーマを緩めないでください。

MCP ツールの追加

/mcp-tool スキルを使ってください。このスキルはツールを spec/mcp-tools.yaml に追加し、pnpm gen:schemas を実行して、src/mcp/tools/<toolset>/<name>.ts にハンドラーを作成し、レジストリに登録します。すべてのツールに、4 つのアノテーションヒント（readOnlyHint、destructiveHint、idempotentHint、openWorldHint）を指定する必要があります。

Conventional Commits

feat(scope): description
fix(scope): description
docs / refactor / chore / test / perf / ci

feat または fix をマージする前に、pnpm changeset を使ってリリースノートを記録してください。

---

バージョン 2.4 の新機能

ホストエージェントが追加されました。ゲートウェイホスト上の clawops で、アクセスできるのはあなただけの OpenClaw エージェントを 1 つ運用します。エージェントは自身のホストに関するすべての情報を読み取りますが、何も変更しません。破壊的な操作のリクエストがあると、実行するコマンドそのものをあなたに返します（ADR 0014）。 GCP のアップグレードに関する注意： 次回 clawops up を実行すると、VM が停止してから起動します（下記参照）。

ホストエージェント

• clawops agent install --stack prod --agent ops --operator telegram:12345
  • 最初にチェックします。 ゲートウェイのルーティングで、そのエージェントにアクセスできるのがあなただけでない限り、何も書き込まずに拒否します。
  • それ以外のエージェントを拒否します。 ほかのすべてのエージェントから clawops を削除し、ゲートウェイにその設定が反映されたことを確認します。
  • その後、インストールします。 バージョンが固定され、チェックサムで検証された Node ランタイムと、独自にビルドした clawops をインストールします。Docker ブリッジ上で clawops-agent.service として実行し、ゲートウェイから接続できるように設定します。
  • アンインストールするには、 clawops agent uninstall を実行します。
• 読み取り、引き継ぎを行います。 12 個の読み取りツールは、SSH、Pulumi の状態、ホスト上のクラウド認証情報を使わずにローカルで実行されます。--allow で指定した破壊的なツールも、何も変更しません。代わりに、各ツールは手元のマシンで実行する clawops コマンドを返します。コマンドは通常どおり確認を求めます。yes: true は無視されます。clawops_destroy、clawops_stacks_delete、clawops_migrate は全面的に拒否されます。
• 保留中のリクエストは clawops status に表示され、コピーできます。 コマンドを実行すると、そのリクエストはクリアされます。放置されたリクエストは 7 日後に期限切れになります。clawops_status でも確認できます。
• 呼び出しのたびに再チェックします。 ゲートウェイの設定が変更されてほかの人もエージェントにアクセスできるようになった場合、問題が修正されるまで、すべての呼び出しが拒否されます。グループへのバインドや、拒否設定のない新しいエージェントの追加などが該当します。再インストールは不要です。
• ゲートウェイコンテナ内のほかのエージェントについて。 デフォルトのデプロイでは、すべてのエージェントがそこでコマンドを実行したりファイルを読んだりできます。ホストエージェントのトークンやトランスクリプトも対象です。インストール時と clawops_status では、それらのエージェントが表示されます。残っているエージェントがある間、--strict は処理を拒否します。運用ガイドと開示レビューを参照してください。

GCP ホストにサービスアカウントを付与しないように変更

VM はプロジェクトのデフォルトの Compute サービスアカウントで実行されていました。このアカウントには cloud-platform スコープがあり、ほとんどのプロジェクトでは Editor ロールも付与されているため、ホスト上のプロセスはプロジェクト全体を操作できました。ホスト上では Google API を呼び出さないため、VM にサービスアカウントは付与されなくなりました。既存のスタックでは、次回 clawops up を実行するとサービスアカウントが削除されます。その際、VM は停止してから起動します。ブートディスクは変更されません。

修正

• clawops_logs_tail が、ゲートウェイ自身のログを再び読み取るようになりました。 2.0.1 以降、すべてのホストでコンテナ出力にフォールバックし、ゲートウェイが応答しているにもかかわらず、応答していないと報告していました。clawops logs には影響ありませんでした。
• clawops config set|unset --restart が、gateway restart と同じ方法でゲートウェイを再起動するようになりました。 独自の再起動処理では、すべてのインターフェースで公開されていたゲートウェイが、ループバックのみで再起動されていました。また、イメージを読み取れない場合に、変動する stable タグにフォールバックしていたほか、ゲートウェイの起動前に成功を報告していました。

2.3.1 の新機能

セキュリティ修正です。MCP 経由でゲートウェイの設定を行っている場合は、アップグレードしてください。

• 修正前： clawops_config_set は設定した値を監査ログ（~/.clawops/mcp-audit.log）に平文で記録し、代わりに設定パスを秘匿していました。そのため、エージェントが models.providers.openai.apiKey を設定すると、API キーがログに記録されていました。確認プロンプトにも値が表示されていました。
• 修正後： パスにシークレットが含まれている場合は値を秘匿し、JSON オブジェクトの値に含まれるシークレットフィールドも個別に秘匿します。パスは入力されたとおりに記録されます。秘匿処理をご覧ください。
• 既存のログは書き換えられません。 2.3.1 より前に clawops_config_set でシークレットを設定した場合は、監査ログを確認し、そのシークレットをローテーションしてください。

2.3 の新機能

エージェントが解除できない利用上限と、バックログにあった修正です。

利用上限

• ~/.clawops/config.json の任意の policy ブロックで、clawops が各プロバイダーにデプロイできるサーバーサイズと、管理できるデプロイ数を制限できます。plan、apply、up は許可リストにないサイズを拒否し、init は上限を超えるスタックを拒否します。
• デプロイを行うすべての MCP ツールに、同じ上限が同じ文言で適用され、どのツールも上限を変更できません。確認はエージェントが自分で応答できますが、上限はそうではありません。
• clawops setup で上限を設定するかどうかを尋ねた後、許可したサイズだけが提示されます。利用上限をご覧ください。

修正

• セットアップウィザードのプランは、クラウドに small という名前のマシンを要求していました。 プロバイダー独自のタイプを指定すべきところに、clawops のサイズを書き込んでいました。clawops plan と同様に、対応するタイプに変換するようになりました。
• clawops_workflow_recover はスタックのヘルスチェックを実行し、実在するツールだけを推奨します。 説明していた 4 つのステップのうち 2 つしか実行せず、最後に存在しない clawops refresh を提案していました。
• MCP 監査ログでは、認証情報の引数が秘匿されます。 GOOGLE_APPLICATION_CREDENTIALS は spec/errors.yaml で機密情報として指定されていましたが、ログには平文で記録されていました。エラークラス、終了コード、秘匿パターンについて、仕様とコードが食い違うとテストが失敗するようになりました（#185）。

---

2.2 の新機能

復旧はフラグで指定でき、エージェントは必要なすべてのコマンドを利用でき、SSH の失敗時には何が失敗したかが示されます。2.2.1 では、以下の修正が追加されています。

復元したバックアップを稼働状態にする

• clawops backup restore --file <archive> --activate は復元した状態に切り替え、その状態でゲートウェイを再起動し、応答を確認します。--activate を指定しない場合も、復元時の検証とステージングディレクトリへの展開は行われますが、稼働中の環境には触れません。
• 置き換えられる状態は削除されずに保持されます。ゲートウェイが起動しない場合、clawops は元の状態に戻して再起動します。失敗した状態は証拠として .failed-restore-<timestamp> に保持されます。
• 復元した状態は、置き換え先のディレクトリの隣にあるホスト上に配置されます。以前はコンテナー内の /tmp に残されていたため、次の gateway restart で削除されていました。
• アーカイブを展開する前に、空き容量を確認します。
• clawops backup --help から、復元が利用できないという記述を削除しました。復元は 2.0 から利用できています。

エージェントに必要なすべてのコマンドが MCP ツールに

• 10 個の新しいツールが加わり、カタログは 30 個になりました。バックアップの作成と復元（activate 付き）、ゲートウェイの状態確認と更新、特定のエージェントのログ、移行、スタックの削除、シークレットの一覧表示・監査・削除が追加されています。それぞれのツールは対応するコマンドと同じコードを呼び出すため、どちらも同じ内容を同じ文言で拒否します。
• clawops ssh と clawops secret set／rotate は意図的に CLI 専用のままです。ルートシェルやシークレットの値を、エージェントやそのトランスクリプトに渡すべきではありません。シークレットのツールが値を返すことはありません。

SSH エラーで原因がわかります

• タイムアウトは応答がなかったことを示します。clawops スタックでは通常、セキュリティグループでお使いのアドレスが許可されなくなったことを意味します。このメッセージには、問題を修正する再計画と適用の手順が表示されます。
• 接続拒否は、ホストは稼働しているものの sshd が稼働していないことを示します。鍵が拒否された場合は、clawops が提示した鍵の名前が表示されます。名前解決に失敗した場合も、共通のアルゴリズムがない状態でハンドシェイクした場合も、それぞれ何が起きたのかがわかります。すべてのメッセージで ssh2 本来の表現を維持しています。
• clawops doctor --stack <name> を実行すると、同じアドバイスが個別の行に表示されます。

実際のホストですべてのツールを実行して見つかった修正

新しいツールを MCP 経由で、systemd ホスト、clawops 1.7.9 で作成された 1.x デプロイ、AWS に対してエンドツーエンドで実行しました。その結果、単体テストでは見つけられなかった不具合が判明しました。CLI にもいくつか問題がありました。

• clawops gateway update が動作するようになりました。 アップグレードゲートの導入以降、すべての更新は何も変更する前に失敗していました。状態のスナップショットに、作成できないコンテナー内のホストパスが指定されていたためです。
• ローカルプロバイダーのホストで systemd との競合がなくなりました。 ゲートウェイは Restart=always が設定された openclaw ユニットとして実行されるため、clawops が行った再起動、更新、移行、復元が約 5 秒後に元に戻されていました。clawops は、ユニット経由でゲートウェイを変更するようになりました。
• clawops gateway、agents、config、logs がローカルスタックで動作するようになりました。 それぞれ MCP ツールでは動作していたものの、「The local provider does not use Pulumi stacks」というエラーで失敗していました。
• clawops migrate は、すでに 2.x のスタックを拒否するようになりました。 以前は新しい最小構成を作成していました。また、実行前に確認を求めるようになりました。これは --yes が常に行うと示していた動作です。さらに、1.x を停止する前に 2.x のイメージを取得するようになりました。これにより、停止時間は数ギガバイトのダウンロードではなく、再起動にかかる時間だけになります。
• シークレット名からシークレットディレクトリの外部にアクセスできなくなりました。 clawops secret delete ../config.json は clawops の設定を削除していました。
• clawops_gateway_restart は、ゲートウェイが公開されていたすべてのインターフェースで公開状態を維持するようになりました。 ループバックに移動することはありません。
• 状態を読み取れないスタックでは、その理由が表示されるようになりました。 Pulumi の code: -2 を表示するのではなく、MCP サーバーでよくある原因である、クライアント設定の env ブロックに認証情報がないことを示します。

その他の修正

• バックアップのアップロードやログの追跡など、ストリーミング形式の Docker コマンドで、無関係なコマンドで取得した sudo の判断が再利用されなくなりました。ログインユーザーが docker グループに属していない AWS では、バックアップの取得後にバックアップのアップロードが「permission denied」で失敗していました。
• バックアップとアップグレードのロールバックに関するガイドで、手動の手順ではなく --activate を説明するようになりました。また、CI でリポジトリ内のすべての Markdown リンクとアンカーをたどるようになりました（pnpm verify:docs）。
• ローカルプロバイダーのブートストラップは、モックではなく、PID 1 として systemd を実行するコンテナーに対して、e2e スイートで実際に実行されます。同じスイートで、ホストにアクセスする MCP ツールと 1.x の移行も実行するようになりました（pnpm test:e2e:local。毎晩、および e2e ラベル付きの PR で実行）。また、E2E_MCP=1 pnpm test:cloud <cloud> は、実際のクラウドホスト上で MCP 経由のバックアップと復元を行います。
• clawops.fyi に構造化データ、/llms.txt、FAQ、比較ページを追加しました。

2.2.1

• clawops config validate と config set が、固定された OpenClaw リリース（2026.9.2）で実際に使用されているスキーマに照らして検証するようになりました。 clawops に同梱されていたスキーマは別のビルドから取得したもので、毎週実行されるスキーマとの差分チェックは毎週そのずれを検出していたものの、issue ラベルが不足していたため報告に失敗していました。現在は報告されます。実際には、messages.suppressToolErrors はゲートウェイが拒否するため拒否され、transcripts.autoStart[].whenOccupied は受け入れられます。
• OpenClaw 2026.9.2 では、エージェントはデフォルトで互いのセッションを読み取れます。 エージェント間のセッションアクセス（tools.agentToAgent）とコレクターモードのサブエージェント（tools.swarm）は、無効にしないかぎり有効です。同じゲートウェイ上のエージェントがお互いのセッションを見られないようにするには、clawops config set tools.agentToAgent.enabled false を実行するか、allow リストを指定してください。

2.1 の新機能

プライベートネットワーク、すべてのクラウドでのセキュリティ強化、そして起動できなかったコマンドの修正が 2 件あります。 2.1.1 では、以下の修正が追加されています。

tailnet 経由でスタックに接続する

• clawops harden --tailscale はスタックに Tailscale をインストールし、clawops-<stack> として tailnet に参加させ、割り当てられたアドレスを報告します。
• 同じコマンドは、そのアドレスへの SSH セッションを確立してから clawops をそのアドレスに切り替えます。SSH セッションでは、すでに信頼しているパブリック接続経由でピン留めされたホストキーを使用します。
• Tailscale の認証キーは clawops secret set TAILSCALE_AUTH_KEY で設定し、SSH データチャネル経由でホストに送信します。コマンドライン、プロセス一覧、ログに表示されることはありません。
• clawops plan --private-only → clawops apply を実行すると、tailnet 経由で接続したスタックのパブリック SSH とゲートウェイへのアクセスが閉じられます。実行時点でそのアドレスから SSH に応答がない場合、どちらのコマンドも処理を拒否します（ADR 0013）。
• clawops harden --tailscale-revert はホストを tailnet から外し、clawops をパブリックアドレスに戻します。プライベートのみのスタックでは処理を拒否し、SSH を再開するコマンドを表示します。
• clawops destroy は、存在しなくなったインスタンスのパブリックアドレスをピン留めしたままにせず、tailnet 上のスタックに割り当てられた両方のアドレスのホストキーを削除します。

3 つすべてのクラウドでセキュリティ強化に対応

• Azure：NSG 監査、ディスク暗号化、Defender for Cloud、JIT VM アクセス。すべてチェックのみです。
• GCP：VPC ファイアウォール監査、Shielded VM、OS Login。すべてチェックのみです。
• GCP インスタンスは Secure Boot を有効にして起動します。既存のスタックでは、ブートディスクと OpenClaw の状態をすべて維持したまま更新されます。
• 実行できなかったチェックは、合格ではなく、何が不足しているかを示してスキップとして報告します。

プランで変更の影響を明示

• clawops plan は、置き換えの対象となるリソースの数と一覧を表示します。以前は、インスタンスとそのブートディスクを破棄するプレビューを「作成 0、更新 0」と要約していました。
• 稼働中のデプロイに変更を加えるプランでは、適用前に警告が表示されます。置き換えの場合は、影響を受けるものを明示し、clawops backup create を案内します。更新の場合は、ゲートウェイが停止することを伝えます。

修正

• npm からインストールした場合、clawops mcp serve はまったく起動できませんでした。プロトコルを何も出力しないままインポート時に終了し、すべての MCP クライアントが何も受け取れませんでした。現在、pnpm verify:pack はパッケージ化された tarball と MCP で通信するため、この種の不具合が再びリリースされることはありません。
• MCP レジストリのマニフェストである server.json は、公開時に書き換えるのではなく、パッケージとともにバージョン管理されます。コミット済みのファイルには 1.7.3 と記載されていましたが、公開版は 2.0.2 でした。
• 公開パッケージにはライセンス、キーワード、課題追跡システムが含まれるため、npm で見つけやすく、掲載情報も完全です。

2.1.1

• clawops をコマンドなしで起動し、標準入力がパイプの場合は、ヘルプを表示する代わりに MCP サーバーとして動作します。 これは、すべての MCP クライアントがサーバーを起動する方法であり、実行コマンドを推測して起動するディレクトリも同様です。いくつかのディレクトリではヘルプテキストが返され、サーバーが壊れていると報告されていました。ターミナルで clawops を入力した場合は、引き続きヘルプが表示されます。また、clawops | less でも同様です。
• MCP の設定例は、記載どおりに実行できる npx -y @clawops/cli mcp serve です。以前は /path/to/clawops と記載されていましたが、実行できず、どのディレクトリからもコピーできませんでした。
• 説明は MCP レジストリの100文字制限内に収まっています。2.1.0 に含まれていた説明は110文字だったため、npm への公開後にレジストリが 422 エラーで拒否し、2.1.0 は npm には登録されましたが、レジストリには登録されませんでした。
• clawops harden は、スタックがデプロイされていない場合や、その状態を読み取れない場合に、code: -2 とサブプロセスの出力をそのまま渡すのではなく、その旨を伝えます。
• MCP レジストリへのバックフィルでは、リリースツールが準備中のバージョンではなく、実際にリリースされたバージョンを登録するようになりました。そのため、遅れてしまったエントリーを適切に修復できます。
• Docker イメージがビルドできるようになりました。これまでビルドされたことがなく、実際にビルドもできませんでした。npm pack --pack-destination は保存先を作成しないためです。CI では pnpm verify:docker がイメージをビルドし、エントリーポイント経由と単独のバイナリとして実行中のコンテナと MCP で通信します。

2.1.2 and 2.1.3

• すべての MCP ツールが説明を送信し、すべてのパラメーターに説明が付くようになりました。これまでは、クライアントには名前とスキーマだけで説明のないツールが19個表示されていました。
• clawops_init が MCP 経由でスタックを登録するため、クライアントは何もない状態から初期設定できます。設定と SSH キーを書き込みますが、プロビジョニングは行いません。
• 確認画面を表示できないクライアントには、Client does not support form elicitation というクラッシュを返す代わりに、ユーザーに確認を求めて yes: true を指定して再度呼び出すよう伝えます。
• Docker イメージに ssh-keygen と CA バンドルが含まれるようになりました。これらがないと、キーを作成したり、HTTPS エンドポイントに接続したりできません。

---

What's new in 2.0.1

パッチリリースですが、大規模な内容です。2.0.0 では、どの方法でもクラウドへのデプロイに成功しませんでした。以下の各項目は、すべて 2.0.1 での修正または追加です。それぞれの理由はコミットメッセージに記載されており、そこから導かれた判断は docs/decisions/ に記載されています。

Deploying to a cloud

• clawops plan → clawops apply でクラウドスタックをプロビジョニングし、その上に OpenClaw をデプロイします。
• clawops up は AWS、GCP、Azure にデプロイし、plan → apply と同じ処理を実行します。
• clawops は必要な Pulumi CLI を ~/.clawops/.pulumi-cli にインストールするか、$PATH 上にある互換性のあるものを使用します（ADR 0010）。
• clawops は状態バックエンドに必要なパスフレーズを作成して保存します（ADR 0011）。
• clawops plan は --ssh-cidr、--gateway-cidr、--publish-gateway を受け取り、apply はそれらをクラウドのファイアウォールに渡します。auto を指定すると、このマシンのアドレスが解決されます。
• clawops plan は、状態バックエンドを開けない場合に停止し、原因を示します。
• --instance-type には、clawops のエイリアス（micro～gpu）か、クラウドで指定されているマシンタイプを指定でき、プランには具体的なタイプが記録されます。
• デプロイでは、プラン作成時のアカウントが固定されます。GCP では gcp:project、Azure では azure-native:subscriptionId が使用されます。

費用をかける前にアカウントを確認する

• clawops doctor --provider <cloud> は、スタックの有無にかかわらず、指定したクラウドの認証情報とアカウント設定を確認します。--instance-type を指定すると、デプロイするインスタンスタイプを対象にサイズを確認します。
• AWS。認証情報から特定されるアカウント、状態バケット、インスタンスタイプがリージョンで提供されているかを確認します。
• GCP。プロジェクト、デプロイに必要な API、状態バケットを確認します。
• Azure。サブスクリプション、リソースプロバイダー、VM サイズ、Pulumi の認証に使用する azblob 認証情報を確認します。
• clawops setup は同じ確認を実行し、安全に対応できる項目の修正を提案します。API の有効化や、バージョニングを有効にしてパブリックアクセスをブロックした状態バケットの作成を、変更内容を事前に明示してから行います。
• clawops が実行できなかった確認は、合格や失敗ではなく、エラーの内容を示す警告として報告されます。
• Azure では az login が使えます。サービスプリンシパルは不要になりました。

命名、設定、セットアップ

• clawops は名前を尋ねたりプレースホルダーを書き込んだりせず、デプロイ先のアカウントに基づいて状態バックエンドに名前を付けます （ADR 0012）。
• 入力した名前は、その名前を受け入れる必要があるクラウドのルールに照らして確認されます。
• clawops init は、設定にすでにあるスタックを保持します。
• clawops init は、clawops が読み取れる SSH キーを生成します。このリリースより前に init を実行している場合は、clawops doctor がキーを使用できるかどうかを知らせます。
• gcloud config set project の設定が反映されます。
• セットアップウィザードは、OpenClaw が受け入れるモデル設定を書き込み、選択したプロバイダーに必要なプラグインをインストールします。
• Amazon Bedrock が使えます。適切なトランスポートを使用し、デプロイ先リージョンに基づいて解決された推論プロファイルをプランに記録します。bedrock:ListInferenceProfiles が必要です。

デプロイの実行中

• apply は SSH 接続を待ってから、ゲートウェイが応答するまで待機し、その後に成功を報告します。
• apply は何分も応答がなくなるのではなく、進行状況を随時報告します。
• デプロイがタイムアウトした場合、ホストのブートストラップログから、ホストで実行されていた処理を出力します。
• Docker をインストール中のホストは、デプロイ失敗ではなく、引き続き起動中として扱われます。

運用開始後のコマンド

• clawops logs は AWS のゲートウェイからログを読み取ります。
• doctor --stack、ssh、logs、gateway、config、agents は、新たにデプロイしたスタックに対して動作します。
• clawops doctor はクラウドの認証情報を検証します。
• clawops は、拒否された Docker ソケットと存在しないコンテナーを区別し、どちらを検出したかを伝えます。
• clawops destroy はインスタンスのホストキーを削除するため、クラウドが再利用したアドレスに再デプロイしても、検証に失敗しなくなります。

ドキュメント

• GCP ガイドでは、clawops が実際に読み取る認証情報のソースを明記し、2.0 のファイアウォールの動作を説明しています。
• スモークテスト計画は 2.0 に対応しています。また、pnpm test:cloud aws|gcp|azure を実行すると、実際のデプロイに対してテストを行い、その後にデプロイを破棄します。

2.0 の新機能

clawops 2.x は OpenClaw >= 2026.9.2 を対象としています。1.x 系は、2027-03-31 まで legacy dist-tag のもとで OpenClaw <= 2026.7.1-2 に対応します：

npm install -g @clawops/cli            # 2.x
npm install -g @clawops/cli@legacy     # 1.x maintenance

CI ではタグを固定してください。latest は 2.x に移行するため、タグを固定していないパイプラインは別の系列に切り替わります。 CHANGELOG.md に全履歴を記載しています。このセクションでは、clawops の動作に関する変更を説明します。

デプロイの状態が保持されます

OpenClaw 2.0 は、セッション、トランスクリプト、認証情報を SQLite に保存します。clawops は状態を一切マウントしていなかったため、再起動のたびにそれらがすべて失われていました。gateway restart、gateway update、config set はいずれも再起動を行います。

ホスト上のディレクトリ（/var/lib/clawops/openclaw）が、OpenClaw 独自のデフォルトの場所にバインドマウントされるようになりました。ここには設定、データベース、プロバイダープラグインが保持されます。既存のデプロイは、次回の up／apply で移行されます。

clawops up / clawops apply

flowchart TD
    A["clawops plan"] --> B{"config valid<br/>against OpenClaw schema?"}
    B -- no --> B1["refuse: plan is still<br/>a file you can edit"]
    B -- yes --> C["clawops apply"]
    C --> D{"OpenClaw version<br/>in supported range?"}
    D -- no --> D1["refuse: names<br/>@clawops/cli@legacy"]
    D -- yes --> E["provision host"]
    E --> F["state dir, owned 1000:1000<br/>migrate any pre-2.0 config"]
    F --> G["write config<br/>validated before writing"]
    G --> H["install provider plugins<br/>while egress exists"]
    H --> I["start gateway"]
    I --> J{"/startupz says started?"}
    J -- no --> J1["fail with the reason"]
    J -- yes --> K{"configured providers<br/>all loaded?"}
    K -- no --> K1["warn: healthy gateway,<br/>missing model backend"]
    K -- yes --> L["done"]

この手順のうち3つは新しいもので、それぞれ、以前のフローでは問題があっても成功と報告される可能性があったため追加されました。設定は書き込まれる前に一度も検証されず、プロバイダープラグインは起動時に取得されるか（すべて拒否するホストでは、何も通知されずに欠落したままになり）、また「起動済み」は docker run が 0 で終了したことから推測されていました。

clawops gateway update

以前は、プルして実行し、成功を報告していました。docker run が 0 で終了するということは、コンテナーが 作成された という意味であり、置き換えられるコンテナーはすでに削除されています。

flowchart TD
    A["clawops gateway update X"] --> B{"X in supported range?"}
    B -- no --> B1["refuse before pulling"]
    B -- yes --> C["docker pull X"]
    C --> D["snapshot state database"]
    D -- cannot snapshot --> D1["refuse: no rollback point"]
    D --> E{"target release understands<br/>this schema?"}
    E -- no --> E1["refuse: downgrade across<br/>a schema boundary"]
    E -- yes --> F["swap container"]
    F --> G{"/startupz says started?"}
    G -- yes --> H["done"]
    G -- no --> I["one-shot doctor --fix<br/>in a throwaway container"]
    I --> J["re-run, re-gate"]
    J -- started --> K["done: reported as repaired"]
    J -- still not --> L["roll back to previous image"]
    L -- started --> M["rolled back, reason reported"]
    L -- still not --> N["failed: snapshot path named"]

スナップショットはロールバックポイントであるだけではありません。スキーマバージョンはチェックポイントが実行されるまで WAL に残るため、database preflight は稼働中のデータベースを拒否します。つまり、統合スナップショットがあって初めて互換性チェックが可能になります。

clawops gateway restart

再起動しても、デプロイ済みのバージョンも、ゲートウェイにアクセスできるユーザーも変わりません。どちらも推測せず、稼働中のコンテナーから読み取ります。

flowchart LR
    A["gateway restart"] --> B["read current image"]
    B -- no container --> B1["refuse: nothing to reuse.<br/>latest and stable point at 2.0"]
    B --> C["read current publish scope"]
    C --> D["recreate with the same<br/>version and reachability"]
    D --> E{"/startupz says started?"}
    E -- no --> E1["fail with the reason"]
    E -- yes --> F["done"]

既存の 1.x デプロイメントの移行

flowchart TD
    A["clawops migrate"] --> B{"1.x container running?"}
    B -- no --> B1["nothing to rescue: state was<br/>already lost to an earlier restart"]
    B -- yes --> C["verified backup, inside the running container"]
    C -- "backup fails" --> C1["refused: nothing touched"]
    C --> D["extract state from the RUNNING container"]
    D --> E["chown 1000:1000"]
    E --> F["stop and remove 1.x"]
    F --> G["synthesise a valid 2.0 config"]
    G --> H["start 2.0 with the state directory"]
    H --> I{"/startupz started?"}
    I -- "no: schema still migrating" --> J["restart once"]
    J --> K{"started?"}
    K -- no --> K1["failed: points at the backup"]
    K --> L["report"]
    I -- yes --> L
    L --> M["what carried over,<br/>device identity, config to review"]

この構成について、分かりにくい点が2つあります。どちらも実際の移行を実施したことで判明しました。

状態は 稼働中の コンテナーから抽出されます。 1.x ではすべての状態がコンテナー内にあり、clawops は何もマウントしていませんでした。そのため、先に停止すると、移行で救おうとしていたデータが失われます。

設定は引き継がれるのではなく、合成されます。 1.x には適用可能な設定がなく、clawops がマウントしていたファイルも何にも読み取られていませんでした。以前の設定は、盲目的に適用されることなく、確認が必要な内容 として報告されます。以前の設定にあるチャンネルブロックは、いずれにせよ 2.0 では検証に通りません。

ゲートウェイは起動を2回行う必要もあります。1回目に状態スキーマの移行が実行され、保留中として報告されます。migrate は早まって成功と宣言せず、2回目の起動を待ちます。

2.0 より前の clawops で gateway restart、gateway update、または config set を実行した場合、状態はすでに失われています。コンテナーの置き換え後も保持するためのマウントがなかったためです。migrate は救出できるふりをせず、そのことを明確に伝えます。

clawops backup restore が再び動作するようになりました。ただし、インプレースでは実行されません

v1.7.5 では、対応する OpenClaw に呼び出せる復元サブコマンドがなかったため、理由を説明して復元に失敗していました。2.0 にはそのサブコマンドがあるため、clawops はそれに処理を委ねます。

flowchart TD
    A["clawops backup restore --file X"] --> B["upload archive to the host"]
    B --> C["openclaw backup restore --target <staging>"]
    C -- "target not empty" --> C1["refused by OpenClaw"]
    C --> D["archive verified, expanded<br/>into a fresh directory"]
    D --> E["warnings printed verbatim<br/>time travel, channel relink,<br/>approvals, plugins"]
    E --> F["nothing activated"]
    F --> G["you stop the gateway, swap the<br/>state dir, restart, re-apply"]

clawops はアーカイブを自ら展開せず、インプレースで復元することもありません。最後の手順が意図的に手動になっており、再適用も重要です。アーカイブにはプラグインの node_modules が含まれないため、復元したデプロイメントはモデルプロバイダーがない状態で起動しながら、正常に見えてしまいます。

アーカイブは認証情報です。 状態データベース、mcp_oauth_stores、secret_store_entries、worker_environment_credentials、device_auth_tokens が暗号化されずに含まれます。clawops は現在、ローカルに 0600 のアクセス権で書き込みます。以前はデフォルトの 0644 を使用していました。

プラグインが必要なモデルプロバイダーは自動でインストールされます

OpenClaw 2.0 では、モデルプロバイダーは インストールが必須のプラグイン になりました。イメージには anthropic、openai、google、ollama、openrouter など24個が同梱されていますが、すべてが含まれているわけではありません。同梱されていないものをインストールせずに設定すると、ゲートウェイは起動して正常と報告するものの、モデルバックエンドがない状態になります。

clawops は apply の実行中に、設定で必要なものを正確なバージョンに固定してインストールします。

Resolving clawhub:@openclaw/[email protected]…
Downloading plugin @openclaw/[email protected] from ClawHub…
Installed plugin: deepseek

これにより、1.x 系にはなかった外部への依存先として clawhub.ai が追加されます。 これは起動時ではなく、apply の実行中に必要です。意図的にこのタイミングにすることで、アクセスが制限されたホストで午前3時に問題が起きるのではなく、コマンドの実行者にエラーが伝わります。アクセスがブロックされている場合は、次のように表示されます。

fetch failed | getaddrinfo EAI_AGAIN clawhub.ai | EAI_AGAIN

clawops はその後、インストール済みプロバイダー ID を確認し、設定済みのプロバイダーが欠落している場合はデプロイの完了を通知しません。必要な外部アクセス には、すべての接続先と、それぞれが必要となるタイミングが記載されています。

チャットチャンネルもインストールされます

OpenClaw 2.0 のすべてのチャンネルは、インストールが必要なプラグインです。clawops apply は、設定で指定されたプラグインを、外部への通信が可能なデプロイ中にインストールし、実際にインストールされているかゲートウェイに確認します。

[clawops] warning: the gateway is running, but these configured channels are not installed:
discord. They will never connect.

確認が必要です。openclaw channels add。一見すると適切なコマンドですが、プラグインのインストールに失敗しても成功を返します。そのため clawops は openclaw plugins install を使い、channels list --all --json で確認します。

チャンネルプラグインは、サポート対象のランタイムに合わせてバージョンが固定されています。現在の latest はそのランタイムにはインストールできません。plugin "discord" requires plugin API >=2026.9.3, but this OpenClaw runtime exposes 2026.9.2。モデルプロバイダーのバージョン固定が必要になったのと同じバージョンのずれです。

Telegram はインストール不要です。イメージに含まれています。

不正な設定は書き込む前に検出されます

設定は手書きのスキーマではなく、イメージから取得したOpenClaw 独自のスキーマに照らして、ホストに送信する前と、書き込みによって稼働中のファイルを置き換える前に検証されます。clawops plan は、ゲートウェイが拒否する設定を含むプランを、まだ編集できるファイルの段階で拒否します。

拒否された設定は <path>.rejected.<timestamp> に保存され、稼働中の設定はそのまま残るため、検証に失敗しても、書き込もうとしていた内容が失われることはありません。

clawops 独自のルールが 1 つあります。スキーマでは gateway.mode は省略可能ですが、実際には必須です。これを含まない設定は openclaw config validate を通過してから、終了コード 78 で終了します。

コンテナは強化されています

ゲートウェイは --cap-drop=ALL、--security-opt no-new-privileges、--init、--pids-limit 512 を指定して実行されます。状態ファイルの所有者は数値の 1000:1000 に設定され、UID が一致しない場合があるホストアカウントではなく、コンテナのユーザーに合わせられています。

バージョン固定は、変更される可能性のあるあらゆる箇所で適用されます

doctor、plan、up、apply は、サポート対象の範囲外の OpenClaw リリースを拒否します。また、gateway restart は変動するタグを解決せず、すでにデプロイされているバージョンを再利用します。再起動しても、バージョンもアクセス可能なユーザーも変わりません。

ゲートウェイがネットワークに公開されなくなりました

コンテナは 0.0.0.0:18789 ではなく 127.0.0.1:18789 でポートを公開します。clawops tunnel またはホスト上のリバースプロキシを使ってアクセスしてください。

以前はウィザードが、SSH 用に指定された CIDR を allowedGatewayCidrs に設定していました。その結果、プレーンテキストの HTTP ダッシュボードが、URL にトークンを含む状態で、無関係な質問への回答をきっかけに、シェルへのアクセス権があるネットワーク全体に公開されていました。すべてのインターフェースに意図的にバインドするには、network.publishGateway: "all" を設定してください。

次の場合は対応が必要です。 別のマシン上のクライアントまたはリバースプロキシがゲートウェイに直接アクセスする場合、または外部の監視ツールが /health にアクセスする場合です。ホスト上のプロキシには影響しません。ホスト上のコンテナ内にあるプロキシには、--network host が必要です。

ヘルスチェックが実際に失敗するようになりました

ゲートウェイは、あらゆるパスに一致するルートで Control UI を配信するため、一致しないパスはどれも HTML とともに 200 を返します。

/healthz                        200  application/json   {"ok":true,"status":"live"}
/health-typo                    200  text/html          <!doctype html>…

clawops は curl -fsS … >/dev/null でプローブしていたため、タイプミスがあっても成功していました。確認できていたのはポートで何かがリッスンしていることだけで、ゲートウェイが正常であることではありません。現在、プローブはレスポンス本文を読み取ります。また、再起動後はプロセスが起動を完了するずっと前からリッスンを開始するため、再起動ゲートではライブネスではなく /startupz を使用します。

clawops mcp wire が実際に接続できるようになりました

これは 2.0 でも、1.x のどのリリースでも、これまで一度も機能していませんでした。gateway.mcpClients を書き込んでいましたが、これは OpenClaw に存在しないキーです。2026.4.5、2026.7.1-2、2026.9.2 の設定スキーマと照合して確認しました。実際のキーはトップレベルの mcp.servers です。また、書き込まれるエントリーは、stdio 経由で command: "clawops" を実行するものでしたが、clawops がインストールされておらず、インストールする手段もないゲートウェイコンテナ内で起動します。

1.x では書き込み内容の検証が行われなかったため、clawops は誰も読み取らないキーを保存し、ゲートウェイを再起動して、次のように報告していました。「ゲートウェイの AI が clawops コマンドを実行できるようになりました。」 実際にはできませんでした。

flowchart TD
    A["clawops mcp wire"] --> B["openclaw mcp add --transport streamable-http"]
    B --> C{"gateway connects<br/>to the URL?"}
    C -- no --> C1["probe fails, nothing saved,<br/>clawops prints the reason"]
    C -- yes --> D["saved to mcp.servers.clawops"]
    D --> E["openclaw mcp reload"]

現在は openclaw mcp add に処理を委譲します。これは保存前にサーバーをプローブするため、「接続済み」とはファイルに書き込まれたことではなく、ゲートウェイが接続したことを意味します。

サーバーは自分で実行する必要があります。 clawops はゲートウェイホストにインストールされていません。

clawops mcp serve --http 18790 --bind 0.0.0.0 --token "$(openssl rand -hex 16)"
clawops mcp wire --stack prod --token <same token>

ゲートウェイホストへの clawops のインストールは、意図的に後回しにしており、2.0 には含まれません。デプロイ用の認証情報をデプロイ先のマシンに置くことになり、ゲートウェイの AI は接続されているすべてのチャネルからアクセス可能だからです。docs/security/threat-model.md の T11 を参照してください。

clawops mcp serve --http は複数のクライアントに対応し、接続相手を確認します

モックではなく実際のゲートウェイを使ったテストで、2 つのバグが見つかりました。

プロセス全体でトランスポートを 1 つしか構築していなかったため、最初に接続したクライアントがそれを占有し、後続のクライアントはすべて拒否されていました。2 つ目のエディター、再接続、ゲートウェイ自身によるプローブには、"Server already initialized" と応答していました。HTTP モードは複数クライアントに対応するモードです。

認証機能がないにもかかわらず、clawops_destroy を含むすべてのツールを公開していました。現在はベアラートークンを受け取り、定数時間で比較し、トークンがない場合はループバック以外へのバインドを拒否します。

ファイアウォールはデプロイ内容に応じて設定されます

flowchart TD
    A["clawops plan"] --> B{"publishGateway?"}
    B -- "loopback (default)" --> C{"allowedGatewayCidrs empty?"}
    C -- no --> C1["refuse: those rules would admit<br/>traffic to a closed port"]
    C -- yes --> D["SSH rules only"]
    B -- all --> E["SSH rules + gateway rules<br/>on spec.network.gatewayPort"]
    D --> F["clawops harden"]
    E --> F
    F --> G["read the container's port bindings"]
    G --> H{"published to the network?"}
    H -- no --> H1["ufw: SSH only"]
    H -- yes --> H2["ufw: SSH + the published port"]

3 つのセキュリティ制御が、説明とは逆の動作をしていました。

clawops harden はすべてのデプロイでゲートウェイポートを開いていました。 ufw モジュールは無条件に ufw allow 18789/tcp を実行していました。ゲートウェイは 127.0.0.1 で公開されているため、これによって、何も待ち受けていないポートが開放されていました。デプロイで公開される範囲を超えてファイアウォールを広げるハードニング手順でした。現在は実行中のコンテナのポートバインディングを読み取り、ゲートウェイが実際に公開されている場合に限り、公開されているポートでルールを追加します。

AWS セキュリティグループの監査では、確認対象の 2 つのポートが除外されていました。 ポート 22 と 18789 は「想定内」のリストに含まれていたため、SSH またはゲートウェイを 0.0.0.0/0 に公開しているセキュリティグループでも、「想定外のインバウンドルールは見つかりませんでした」と報告されていました。また、IPv6 ルールを一度も読み取っていなかったため、::/0 は検出されませんでした。

セットアップウィザードは SSH アクセスを 0.0.0.0/0 に設定していました。 Enter キーを押すだけで、最も多くの初回ユーザーが進む手順で、SSH がインターネット全体に公開されていました。現在はユーザー自身の IP を /32 として提示します。それを検出できない場合はデフォルトを提示せず、回答を必須とします。

clawops plan ではこれらを指定できず、apply も Pulumi に渡していませんでした。 どちらも 2.0.1 で修正されています。このセクションの冒頭にある一覧を参照してください。

ゲートウェイポートはプランから取得します

"network": {
  "allowedSshCidrs": ["203.0.113.4/32"],
  "allowedGatewayCidrs": [],
  "publishGateway": "loopback",
  "gatewayPort": 9443
}

1 つの値が、セキュリティグループのルール、コンテナの公開フラグ、デフォルトの gateway.port、ゲートウェイ URL に反映されるようになりました。以前は同じ定数が 11 か所で宣言されていたため、変更するにはすべての箇所を探す必要があり、1 つでも見落とすと、コンテナがあるポートを公開し、ゲートウェイが別のポートで待ち受け、ファイアウォールがさらに別のポートを開く状態になっていました。

ローカルデプロイでは clawops up --gateway-port 9443 を使用します。

clawops doctor は動作しているかどうかを判定し、終了コードで示します

flowchart TD
    A["clawops doctor"] --> B["local: Node, Pulumi CLI + home,<br/>config, SSH key, credentials"]
    B --> C{"--stack given?"}
    C -- no --> Z["report"]
    C -- yes --> D["container state"]
    D --> E["deployed OpenClaw version"]
    E --> F["probe /startupz<br/>and read the body"]
    F --> G["published scope, disk,<br/>log rotation, hardening drift"]
    G --> Z
    Z --> Y{"any check failed?"}
    Y -- no --> Y1["exit 0"]
    Y -- yes --> Y2["exit 1"]

変更点は3つです。

ゲートウェイに問い合わせます。 以前の doctor は docker inspect のヘルスチェックフィールドを読み取っていましたが、OpenClaw のイメージではこのフィールドが設定されていないため、「ヘルスチェックが設定されていません」と報告して処理を続けていました。コンテナが起動していることは、プロセスが開始したことを示すだけで、サービスが提供されているとは限りません。現在は /startupz にアクセスして、レスポンス本文を読み取ります。

問題が発生した場合は終了コード 1 を返します。 以前は古い Node.js の場合のみそうなっていました。読み取り不能な SSH キーや未対応のゲートウェイがあっても終了コード 0 を返していたため、clawops doctor を実行する CI ステップでは、壊れたデプロイが成功として扱われていました。警告の場合は引き続き終了コード 0 を返します。スタックがない新しいマシンは、壊れているのではなく未設定の状態です。

MCP ツールとして利用できます。 clawops_doctor は同じレポートを構造化データとして返すため、エージェントは問題が発生したときにその理由を確認できます。このツールはレポートのみを返し、openclaw doctor --fix は実行しません。--json を指定すると、CLI でも同じレポートを取得できます。

clawops agents list が空のリストをでっち上げなくなりました

このコマンドは || echo '[]' で終わっていたため、コンテナの停止中、ゲートウェイの起動中、Docker の権限エラーのいずれの場合も 「実行中のエージェントはありません。」 と表示していました。これはエラーではなく、誤った回答でした。現在はエラーで終了し、その理由も表示します。

AWS で2日目以降のコマンドが動作するようになりました

gateway restart、logs、monitor、backup、agents、config set と doctor のコンテナチェックは、すべて AWS で動作していませんでした。clawops は ubuntu として接続しますが、プロビジョニングでは clawops しか docker グループに追加していなかったため、すべての Docker コマンドが permission denied で失敗していました。GCP と Azure では clawops として接続するため、影響があったのは AWS のみです。

削除した項目

clawops agents restart と clawops_agents_restart MCP ツール。OpenClaw 2.0 にはエージェント単位の再起動機能がなく、gateway restart と daemon restart のみが用意されています。どちらもホスト上のすべてのエージェントが中断されます。clawops gateway restart を使用するか、@clawops/cli@legacy を引き続き使用してください。

clawops agents list と clawops agents logs には影響しません。

---

マイルストーン

マイルストーン	ステータス	提供内容
M0：スキャフォールド	✅	ツール、CI、スタブ、生成された型
M1：GCP MVP	✅	GCP での init / up / down / status / ssh / logs
M2：リモート管理	✅	tunnel、config、agents、gateway、SSH 接続プール
M3：AWS + Azure	✅	AWS EC2 + Azure VM アダプター、stacks list
M4：ローカル VM	✅	ローカルアダプター（SSH ブートストラップ、Pulumi 不使用）、doctor
M5：MCP レイヤー	✅	mcp serve（stdio）、すべての CLI 操作を MCP ツールとして提供、進捗の追跡
M6：プラン／適用	✅	plan + apply、デプロイ計画スキーマ、MCP HTTP トランスポート、workflow_deploy_app
M7：v1.0 の仕上げ	✅	doctor の全機能、destroy コマンド、各コマンドでの --dry-run、CI ガイド

公開ロードマップと今後の作業については、docs/roadmap.md を参照してください。

---

ライセンス

MPL-2.0。詳細は LICENSE を参照してください。