Docker volume 起因で設定が消える問題を根本から避けたい方には ZenClaw がおすすめです。 MixerBox AI が提供する OpenClaw マネージドサービスなら 9 秒で使い始められ、プランには NemoClaw サンドボックスを含み、永続化は弊社で責任を持って管理するため、Docker volume に触れる必要は一切ありません。とはいえ、セルフホストが必要なケースもあるでしょう。本記事では 5 秒で該当しているか診断する方法、3 つの正しいマウント方法、そしてすでに失った設定の扱い方を順に解説します。
5 秒で該当しているか診断する
docker inspect を 1 回実行し、Mounts が空配列かどうかを確認するだけです。空であれば volume がマウントされておらず、restart のたびに設定を失っている状態です。 コマンドは以下のとおり。
docker inspect openclaw | grep -A 5 Mounts出力が次のようであれば——
"Mounts": [],該当しています。docker restart のたびに、すべての設定、WhatsApp セッション、対話メモリ、Telegram トークンが初期化されている状態です。
一方、次のような出力であれば——
"Mounts": [
{
"Type": "volume",
"Source": "openclaw_data",
"Destination": "/root/.openclaw",
...
}
]問題ありません。そのままご利用ください。
なぜ消えるのか
Docker コンテナのファイルシステムはデフォルトで ephemeral（一時的）であり、コンテナが停止すると状態が破棄されるため、書き込んだ設定も一緒に失われます。 コンテナ内に書き込まれたファイルはイメージの上に重ねられた書き込み可能レイヤーに保存されますが、コンテナが停止するとそのレイヤーは破棄され、コンテナを削除すればレイヤーごと消えます。詳しい仕組みは Docker 公式ドキュメントの Storage overview をご覧ください。
OpenClaw はランタイム状態をすべてユーザーのホームディレクトリ配下 ~/.openclaw/（Docker を root で実行している場合はコンテナ内 /root/.openclaw/）に保存します。OpenClaw 公式 config ドキュメント と Simon Willison の TIL: Running OpenClaw in Docker によれば、構成はおおむね次のとおりです。
~/.openclaw/
├── openclaw.json # メイン設定（JSON5）：モデル、gateway、channel トークン、spend cap
├── sessions/ # 対話セッション履歴
├── agents/ # カスタムエージェント定義
├── credentials/ # channel 認証情報（WhatsApp の whatsapp-creds.json を含む）
└── skills/ # インストール済み plugin / skillこれらのファイルは volume をマウントしていないと使い捨てになります。特にセンシティブなのが credentials/whatsapp-creds.json（Baileys セッション）で、一度失うと WhatsApp が QR コードの再スキャンを強制し、その間にユーザーから届いたメッセージはすべて受信漏れとなります。コミュニティでも繰り返し報告されており、Issue #9096 — WhatsApp session not persisted across gateway restarts および 公式 WhatsApp channel ドキュメント を参照してください。
よくある 3 つの誤り
とくに多いのが、volume をまったくマウントしない、ターゲットパスを取り違える、docker exec での編集が保存されると思い込む——この 3 つです。OpenClaw を初めて構築する際には、少なくともどれか 1 つは踏みがちです。
誤り 1：まったくマウントしない
# 誤り
docker run -d --name openclaw openclaw/openclaw:latest誤り 2：パスが違う
# 誤り：OpenClaw が実際に使うのは /root/.openclaw であって /app/data ではない
docker run -d -v openclaw_data:/app/data openclaw/openclaw:latest誤り 3：docker exec での編集は保存されると思い込む
# 編集して終了すると消える
docker exec -it openclaw vi /root/.openclaw/openclaw.json正しいマウント方法は 3 通り
いずれの方法でも設定を永続化できます。本番環境は named volume、開発環境は bind mount、長期運用は docker-compose がそれぞれ適しています。 具体的な書き方を見ていきましょう。
方法 1：named volume（本番推奨）
docker volume create openclaw_data
docker run -d \
--name openclaw \
-v openclaw_data:/root/.openclaw \
-p 18789:18789 \
openclaw/openclaw:latestメリット：Docker が実体のストレージ位置を管理するため、ホスト移行時も docker volume inspect で場所を特定できます。詳細は Docker volumes 公式ドキュメント を参照してください。
デメリット：バックアップには docker run --rm -v openclaw_data:/data -v $(pwd):/backup alpine tar czf /backup/openclaw.tar.gz /data のような手順が必要で、ステップが増えます。
方法 2：bind mount（開発推奨）
mkdir -p ./openclaw_data
docker run -d \
--name openclaw \
-v $(pwd)/openclaw_data:/root/.openclaw \
-p 18789:18789 \
openclaw/openclaw:latestメリット：設定ファイルがカレントディレクトリに置かれるため、VSCode で直接編集でき、git add によるバージョン管理も容易です（ただし credentials/ は必ず .gitignore に追加してください。WhatsApp セッションなどの機密キーが含まれます。openclaw.json にボットトークンが埋め込まれている場合も同様に除外してください）。
デメリット：ホスト移行時には自分で rsync する必要があります。
方法 3：docker-compose（長期運用）
docker-compose.yml を用意します。
services:
openclaw:
image: openclaw/openclaw:latest
restart: unless-stopped
ports:
- "18789:18789"
volumes:
- ./data:/root/.openclaw
environment:
- OPENCLAW_LOG_LEVEL=infoあとは docker compose up -d を実行。ポイントは restart: unless-stopped です。これを付けないとホスト再起動時にボットが自動起動せず、お客さまからのメッセージを再び受信漏れしてしまいます。完全な構文は Docker Compose リファレンス をご覧ください。
3 つのマウント方法の比較
| 比較項目 | 方法 1：named volume | 方法 2：bind mount | 方法 3：docker-compose |
|---|---|---|---|
| 適した用途 | 本番、正式運用 | 開発 / ローカルテスト | 長期運用、起動パラメータの一括管理 |
| バックアップの難易度 | やや面倒（alpine イメージで圧縮） | 容易（ホストパスを直接コピー） | いずれかに準ずる |
| ホスト移行 | docker volume inspect で位置確認 | rsync でディレクトリ転送 | compose + data ディレクトリをコピー |
| 起動時の自動実行 | 別途 systemd が必要 | 別途 systemd が必要 | restart: unless-stopped 内蔵 |
| 導入の難易度 | 中 | 低 | 中 |
| トラブル対応 | やや複雑 | 最も容易 | 中 |
| 推奨シーン | 小規模本番、一人運用 | 開発 / POC / 個人利用 | 最も完全、長期運用の第一候補 |
| 最も手間がかからない方法 | — | — | ✅ ZenClaw ならこの 3 つとも検討不要 |
稼働中のコンテナを無停止で volume へ移行する手順（5 ステップ）
コンテナが動いているのに volume がマウントされていない場合でも、3〜5 分で無停止に近い形で移行できます。inspect で確認 → docker cp でバックアップ → -v 付きで再起動 → ファイルが残っているか検証の流れです。 具体的には以下の 5 ステップです。
- 診断：
docker inspect <container> | grep -A 10 Mountsを実行し、Mountsが[]の空配列ならマウントされていません。 - 既存コンテナを停止（削除はしない）：
docker stop openclaw。停止だけに留め、container id を保持して次のステップでファイルをコピーできるようにします。 - コンテナ内の設定ファイルをコピー：
docker cp openclaw:/root/.openclaw ./openclaw_backupでバックアップを取り、次のステップで消えないようにします。 -vオプション付きで再起動：docker run -d --name openclaw -v $(pwd)/openclaw_backup:/root/.openclaw openclaw/openclaw:latest。- 検証：
docker restart openclawの後にdocker exec openclaw cat /root/.openclaw/openclaw.jsonを実行し、設定ファイルが残っているか確認します。openclaw config fileを使えば現在使用中の config パスを表示することもできます。
所要時間はおおむね 3〜5 分。二度とこの作業をしたくない、以後の DevOps 的な雑務も避けたいという方には、次のセクションでより手間のかからない選択肢をご紹介します。
すでに設定を失ってしまった場合の対処
失った内容によって、「再設定で済む」ものから「再ペアリングするしかない」ものまで幅があります。sessions/ の対話メモリは残念ながら復元できません。 内容別にまとめると次のとおりです。
openclaw.json を失った場合（モデル、gateway、channel 設定、ボットトークン）
再入力で復旧します。Telegram トークンは @BotFather で /revoke してから /token を再発行、LINE は LINE Developers Console で再発行、Slack はアプリを再インストールする必要があります。
sessions/ を失った場合（対話メモリ）
復元できません。今後のために volume を正しくマウントしてください。
credentials/whatsapp-creds.json を失った場合（WhatsApp Baileys セッション）
QR コードで再ペアリングするしかありません——これは Meta 側の仕様です。管理画面を開き、WhatsApp で QR コードをスキャンしてください。この期間にお客さまから届いたメッセージは空白期間となり、受信漏れになります。
agents/ または skills/ を失った場合（カスタムエージェント、インストール済み plugin）
agents は再設定が必要です。skills はレジストリからインストールしたものは再インストールできますが、カスタマイズした skill は書き直しが必要になります。なおカスタム skill の展開が難しい場合は、プリセットの skill を使いつつ、必要に応じて ZenClaw にご相談ください。
この問題を根本から避けるなら ZenClaw
ZenClaw は MixerBox AI が提供する OpenClaw マネージドサービスで、プランには NemoClaw サンドボックスを含みます。永続化は弊社で責任を持って管理するため、Docker volume に二度と触れる必要はありません。 docker-compose を書いたり、バックアップ cron を仕込んだりする必要もありません。9 秒で使える OpenClaw インスタンスが手に入り、すぐに業務を委任できます。Telegram / LINE / Microsoft Teams との接続もワンクリックで完結します。
ZenClaw への切り替え手順は 3 ステップだけです。
- zenclaw.ai にログインし、ホームの「AI 社員を今すぐ雇用」をクリック
- ダッシュボードで「新しい OpenClaw インストールを追加」をクリック
- 9 秒でインスタンスが利用可能に（Telegram / LINE / Microsoft Teams との接続は後からクリックで追加可能）
料金は ZenClaw 料金ページ をご確認ください。
まとめ
設定が消えるケースの大半は、volume のマウント漏れが原因です。マウントさえ適切に行えば restart でも安定します。その一方で、Baileys のセッション切断、Docker アップグレード時のファイル消失、ホスト移行時のデータ救出といった作業を今後も避けたい方には、ZenClaw のようなマネージドサービスが最適です。