OpenClaw(Moltbot/Clawdbot)最新版へのアップデート方法

OpenClaw (旧 Moltbot/Clawdbot) は急速に進化しています。この速度は機能の追加には素晴らしいことですが、それは同時に以下の頻繁な変更も意味します。

エージェントオーケストレーションの挙動
ハートビートロジック（まず安価なチェックを行い、必要な場合にのみモデルを呼び出す）
環境変数名
永続化スキーマとマイグレーションフロー
プラグインとツールのコントラクトの前提

安易にアップデート（git pull && restart）すると、サイレントな破損のリスクがあります。ワーカーは健全に見えてもタスクを完了しなくなったり、スキーマドリフトによりツールアダプターが失敗したり、ハートビート/モデルのしきい値が変更されたためにコストが急増したりする可能性があります。

このガイドでは、具体的なコマンドと検証ステップを含む、本番環境で安全なアップデート戦略を提供します。

ボタン

アップデート前に：インストールトポロジーを特定する

ほとんどの実際のOpenClawデプロイメントは、以下のいずれかのパターンに当てはまります。

シングルノードDocker実行（クイックなセルフホスト）
Docker Composeスタック（OpenClaw + DB + Redis + サイドカー）
Systemd + venv（VPSへのソースインストール）
ハイブリッドエッジセットアップ（EC2 + Tailscale + プライベートコントロールプレーン）

ロールバックのメカニズムが異なるため、アップデート計画はトポロジーと一致させる必要があります。

Docker/Compose：イメージタグの再ピン留めによるロールバック。
ソースインストール：gitタグ+依存関係ロックによるロールバック。
マネージドDB：スキーマのロールバックは簡単ではない場合があります。

現在のトポロジーを文書化していない場合は、まずそれを行ってください。

ステップ1：現在のバージョンをピン留めし、ランタイム状態をキャプチャする

これを復元ポイントとして扱います。

A. バージョン/ビルドのメタデータを記録する

コンテナイメージ

docker ps --format 'table {{.Names}}\t{{.Image}}'

OpenClawがバージョンエンドポイントを公開している場合

curl -s http://localhost:8080/version | jq

Gitベースのインストール

cd /opt/openclaw git rev-parse --short HEAD git describe --tags --always

B. 環境と設定をスナップショットする

cp /etc/openclaw/.env /backups/openclaw-env-$(date +%F).bak cp -r /etc/openclaw/config /backups/openclaw-config-$(date +%F)

また、シークレット参照（生シークレットではない）をエクスポートし、トークンプロバイダー、モデルルーティング設定、ハートビートしきい値を確認してください。

C. 永続データをバックアップする

Postgresの場合：

pg_dump -Fc -h  -U   > /backups/openclaw-$(date +%F).dump

## Redisの場合（ステートフルキュー/チェックポイントが重要なら）：
redis-cli -h  BGSAVE

このステップをスキップした場合、ロールバック計画はありません。

ステップ2：マイグレーションフラグと挙動変更についてリリースノートを読む

最近のOpenClawの進化（名称変更に伴うリファクタリングを含む）を考慮すると、リリースノートには以下のような一度限りの要件が含まれることがよくあります。

環境変数名の変更（CLAW_* から OPENCLAW_* パターンへ）
マイグレーションコマンドの変更
ハートビートスケジューラのデフォルト
ツール/プラグインマニフェスト形式の更新
古いモデルアダプターインターフェースの非推奨化

リリースノートから短いチェックリストを作成します。

必要な設定名の変更
マイグレーションコマンド
キュー/トピックの変更
新しいヘルスエンドポイントのセマンティクス
デフォルトのタイムアウト/コストガードの変更

ステップ3：プレプロダクション環境でアップデートをステージングする

本番環境で最初にテストすることは絶対に避けてください。デプロイメントの形状をクローンします。

最低限のステージング忠実度：

同じOpenClawバージョンギャップ（現在 → ターゲット）
同じDBエンジンのメジャーバージョン
同じキューバックエンド
同じモデルプロバイダーアダプター
代表的な実際のワークフロー（少なくとも5～10個）

チームがOpenClawの周りにAPI（カスタムツール、ウェブフック、ジョブコントロール）を持っている場合、Apidogがすぐに役立ちます。

Apidogを使用して以下を実行します。

OpenAPI定義をインポート/更新する
ツールエンドポイントのリクエスト/レスポンスコントラクトを検証する
ロールアウト前にシナリオベースの回帰テストを実行する
変更されたエンドポイントのインタラクティブなドキュメントを公開し、フロントエンド/QAチームが迅速に連携できるようにする

これにより、「OpenClawはうまくアップグレードされたが、連携が壊れた」というインシデントを防ぐことができます。

ステップ4：デプロイメントタイプ別にアップデートする

オプションA：Docker Compose

docker-compose.ymlで明示的なタグをピン留めします（本番環境ではlatestを避けます）。

yaml services: openclaw: image: ghcr.io/openclaw/openclaw:v1.14.2 env_file: - .env depends_on: - postgres - redis

アップデートプロセス：

docker compose pull openclaw docker compose up -d openclaw

マイグレーションが分離されている場合：

docker compose run --rm openclaw openclaw migrate

その後、ワーカーを再起動します。

docker compose up -d worker scheduler

オプションB：プレーンDocker

docker pull ghcr.io/openclaw/openclaw:v1.14.2 docker stop openclaw docker rm openclaw

docker run -d   
--name openclaw   
--env-file /etc/openclaw/.env   
-p 8080:8080   
ghcr.io/openclaw/openclaw:v1.14.2

必要に応じてマイグレーションコマンドを実行します。

オプションC：ソース + systemd

cd /opt/openclaw git fetch --tags git checkout v1.14.2

環境を再構築

source .venv/bin/activate pip install -r requirements.txt

マイグレート

openclaw migrate

再起動

sudo systemctl restart openclaw-api openclaw-worker openclaw-scheduler

systemdユニットのオーバーライドが新しいCLI引数と引き続き一致していることを確認します。

ステップ5：「プロセスが起動している」以上の健全性を検証する

実行中のプロセスが健全なエージェントシステムであるとは限りません。

すぐに実行すべきヘルスチェック

APIの活性/準備状況


# サービスヘルス状態をチェック
curl -f http://localhost:8080/health/live    # 生存プローブ（Liveness）
curl -f http://localhost:8080/health/ready   # 準備プローブ（Readiness）

# 両方200を返す = サービス正常 ✅
# いずれか失敗 = サービス異常 ❌

キューのスループット

テストジョブをキューに入れる
ワーカーの取得を確認する
完了の遅延を確認する

ハートビートの挙動最近のハートビート設計トレンド（まず安価なチェック）を考慮し、以下を確認します。

安価なプローブがスケジュールどおりに実行されること
モデルによるチェックが予想されるしきい値でのみトリガーされること
意図しない常時稼働のLLM呼び出しがないこと

コストと遅延のガードレール同じテストワークロードに対して、アップデート前後のトークン/コストテレメトリを確認します。

プラグイン/ツールの呼び出し重要なツールアダプターごとに少なくとも1回の呼び出しを実行します。

ステップ6：ApidogでAPIコントラクトと回帰テストを実行する

多くのOpenClawオペレーターがここで信頼性を迅速に向上させることができます。

OpenClawが内部API（タスクAPI、ツールAPI、コールバックエンドポイント）と連携する場合、Apidogを品質ゲートとして使用します。

設計：OpenAPIファーストのワークフローでエンドポイントスキーマを整合させます。
テスト：成功、タイムアウト、再試行、不正なペイロードのための自動テストシナリオを構築します。
モック：スマートモックエンドポイントを使用して、ダウンストリームツールがオフラインの場合でもOpenClawの動作をテストします。
ドキュメント：変更されたコントラクトのドキュメントを自動生成し、チームが古い例を使用するのを防ぎます。
CI/CD：デプロイメント昇格前に、バージョン更新ごとに回帰スイートを実行します。

実践的なパターン：

現在のコレクション/スペックをApidogにインポートします。
OpenClawが依存するフィールド（task_id、status、tool_result、correlation_id）のアサーションを追加します。
ネガティブケース（429、500、タイムアウト）を追加します。
アップグレードブランチでCIで実行します。
コントラクトを破壊する差分が見つかった場合はリリースをブロックします。

これは、再起動後に2つのエンドポイントを手動でテストするよりもはるかに安全です。

ステップ7：本番環境へのロールアウト戦略

シングルノードのセットアップの場合、短いメンテナンス期間を計画します。

マルチインスタンスのセットアップの場合、ローリング/カナリーロールアウトを行います。

1つのAPIインスタンスを更新する
1つのワーカープールセグメントを更新する
エラー率、キューラグ、トークン消費を15〜30分間監視する
安定していればロールアウトを続行する

以下のメトリクスを監視します。

タスク成功率
リトライ量
デッドレターキューの増加
P95タスク完了時間
LLMリクエスト率/トークン使用量

微妙な設定変更でもヘルスチェックはパスしても、スループットが低下する可能性があります。

一般的なアップグレードの問題と修正

1) API起動成功後、ワーカーがアイドル状態になる

原因：キューの名前空間/トピックが変更されたか、環境変数名の変更が見落とされた。

修正：古い環境ファイルと新しい環境ファイルを比較し、キュープレフィックス設定を確認する。

2) ハートビートが過剰なモデル呼び出しをトリガーする

原因：デフォルトが変更された。安価なチェックのしきい値が設定されていない。

修正：設定でハートビート層とモデルエスカレーションの制限を明示的に設定する。

3) スキーマエラーによるツール/プラグインの失敗

原因：アップグレード後のペイロードコントラクトのずれ。

修正：Apidogコントラクトテストを実行し、新しい必須フィールドに合わせてツールアダプターを更新する。

4) アップグレード後のトークンコストの急増

原因：リトライポリシー + ハートビートの変更 + 長いコンテキストウィンドウ。

修正：リトライを制限し、予算ポリシーを強制し、リクエストトレースを以前のバージョンと比較する。

5) 名称変更の混乱 (Moltbot/Clawdbot/OpenClaw)

原因：混在したパッケージ名、コンテナタグ、古いドキュメント。

修正：内部のランブックを1つの規範的なアーティファクトソースとタグ規則で統一する。

セルフホスト者向けのセキュリティとネットワークの注意事項

多くの開発者は、プライベートメッシュアクセス（例：Tailscaleのようなトポロジー）でOpenClawをEC2/VPSにデプロイしています。アップデート中には、以下を確認してください。

ファイアウォールルールが後退していないか確認する
管理エンドポイントがプライベートのままであることを確認する
アップデートにシークレット処理の変更が含まれる場合、APIキーをローテーションする
コンテナ/イメージの入れ替え後にTLS終端を検証する

また、ウェブフックコールバックの許可リストが引き続きエグレスIPまたはトンネルIDと一致していることを確認してください。

推奨される本番環境アップデートチェックリスト

毎回これを使用してください。

現在のバージョン/タグ/コミットを特定する
DB + 設定 + 環境参照をバックアップする
リリースノートを読み、必須のマイグレーションアクションを抽出する
現実的なプレプロダクション環境でアップデートをステージングする
Apidogの回帰テストとコントラクトテストを実行する
管理された本番ロールアウト（カナリー/ローリング）を実行する
キュー、ハートビート、ツール実行、コストメトリクスを検証する
テスト済みのロールバックコマンドシーケンスを準備しておく
最終バージョンと設定差分をランブックに文書化する

速度よりも一貫性が重要です。

最後に

OpenClawを安全にアップデートすることは、単一のコマンドではなく、エンジニアリングの規律です。Moltbot/ClawdbotからOpenClawへの名称変更の道のりは、プロジェクトが急速に進化していることを反映しており、運用プロセスもそれに合わせて進む必要があります。

堅実なロールアウト/ロールバック方法とAPIコントラクトテストを組み合わせれば、ほとんどのアップグレードの苦痛を回避できます。Apidogはここで自然に適合します。APIコントラクトを設計およびバージョン管理し、自動回帰チェックを実行し、ステージング中に依存関係をモックし、OpenClawが触れるすべてのインターフェースの正確なドキュメントを公開します。

現在のアップデートワークフローがほとんど手動である場合、まずは小さなことから始めましょう。今週、1つのステージングゲートと1つの自動Apidogテストスイートを追加してみてください。この一つの変更が、次のリリースまでに通常、効果を発揮します。

ボタン