まだ OpenClaw をインストールしていませんか?
パソコンへの影響が心配?ClawTank なら60秒でクラウドデプロイ、ファイルへのリスクゼロ。
OpenClaw インスタンスが起動を拒否するほどイライラすることはありません。openclaw start を実行して待っていると、次のエラーが表示されます:
FAIL gateway did not become ready within 60s
このエラーは、ゲートウェイプロセスが起動したものの、初期化が完了しなかったことを意味します。OpenClaw で最もよく見られる問題の一つですが、ほぼすべてのケースで5分以内に修正できます。このガイドでは、既知の原因すべてを解説し、それぞれの具体的な解決手順を紹介します。
ゲートウェイの起動プロセスを理解する
修正方法に入る前に、ゲートウェイ起動時に実際何が起きているか理解しておくと役立ちます。OpenClaw ゲートウェイはいくつかの初期化フェーズを経ます[1]:
- 設定の読み込み --
openclaw.json を読み取り、キーを検証します
- ポートバインド -- 設定されたポート(デフォルト 3001)でリッスンを試みます
- データベースの初期化 -- メモリとセッション用のローカル SQLite ストアをセットアップします
- プラグインの読み込み -- 設定されたスキルと MCP サーバーを初期化します
- ヘルスチェックの登録 --
openclaw doctor が使用するヘルスエンドポイントを公開します
「did not become ready」エラーは、タイムアウトウィンドウ(デフォルト60秒)内にステップ5が完了しなかった場合に発生します。注目すべきキーログ行は:
[gateway] listening on :3001
[entrypoint] Starting OpenClaw gateway は表示されるが「listening」行が表示されない場合、ゲートウェイは先行フェーズのいずれかで停止しています。
ステップ1:まずログを確認する
必ずログから始めてください。ゲートウェイがどこで停止したかが正確にわかります。
# 直接実行している場合
openclaw logs --tail 50
# Docker で実行している場合
docker logs <container_name> --tail 50
出力が停止する直前の最後の行を確認してください。よくあるパターン:
| 最後のログ行 |
考えられる原因 |
[entrypoint] Starting OpenClaw gateway |
ポートバインド前にクラッシュ |
[gateway] loading config... |
設定ファイルの問題 |
[gateway] binding port 3001... |
ポート衝突 |
[gateway] initializing database... |
ディスク容量またはパーミッション |
[gateway] loading plugins... |
プラグインのタイムアウトまたはクラッシュ |
ステップ2:openclaw doctor を実行する
openclaw doctor コマンドは、起動失敗の診断専用に作られています[2]:
openclaw doctor
これは一連のヘルスチェックを実行し、OK、WARN、FAIL のタグ付きで結果を出力します。ゲートウェイの準備完了の問題では、通常1つ以上の FAIL エントリが表示されます。
検出されたすべての問題を自動修正するには:
openclaw doctor --fix
--fix フラグは、トークンの再生成、不足している設定値の設定、古いロックファイルのクリアなど、安全で非破壊的な修復を試みます。
ステップ3:具体的な原因を診断する
原因1:ポート衝突
最も頻繁に発生する原因です。別のプロセス、またはクリーンにシャットダウンされなかった以前の OpenClaw インスタンスがゲートウェイポートを占有しています。
# ポート 3001 を使用しているものを確認
lsof -i :3001
# lsof がない Linux の場合
ss -tlnp | grep 3001
修正方法:
# オプション A:競合しているプロセスを終了
kill <PID>
# オプション B:ゲートウェイポートを変更
openclaw config set gateway.port 3002
openclaw restart
原因2:メモリ不足
ゲートウェイの起動にはおよそ 256 MB 必要です。メモリの少ない VPS インスタンス(512 MB または 1 GB)では、OOM キラーがゲートウェイプロセスの初期化完了前に終了させることがあります。
# 利用可能なメモリを確認
free -h
# OOM キラーが作動したか確認
dmesg | grep -i "oom\|killed"
修正方法:
# スワップ領域がない場合は追加
sudo fallocate -l 1G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
# 永続化する
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
Docker で実行している場合は、コンテナに少なくとも 512 MB が割り当てられていることを確認してください:
docker run -d --memory=512m openclaw-stack
原因3:Docker での起動の遅延
コンテナ化された環境では、ゲートウェイの完全な初期化に通常30〜40秒かかります。デフォルトの60秒タイムアウトで通常は十分ですが、負荷の高いホストやスペックの低いハードウェアでは足りないことがあります。
修正方法:
ゲートウェイの準備完了タイムアウトを延長します:
openclaw config set gateway.startupTimeout 120
openclaw restart
これにより、ゲートウェイに60秒ではなく120秒の猶予が与えられます。
原因4:設定の不足または不正
gateway.mode の設定がないと、起動が完全にブロックされます。
# 現在の設定を確認
openclaw config get gateway.mode
空またはエラーが返される場合:
openclaw config set gateway.mode local
openclaw restart
リバースプロキシの背後にある Docker デプロイメントでは、信頼済みプロキシの設定も必要です:
openclaw config set gateway.trustedProxies '["127.0.0.1"]'
原因5:古いロックファイル
OpenClaw がクラッシュしたり強制終了されたりすると、再起動を妨げるロックファイルが残ることがあります。
# ロックファイルを確認
ls -la ~/.openclaw/*.lock
# 削除する
rm ~/.openclaw/*.lock
openclaw restart
原因6:プラグインまたはスキルのタイムアウト
動作不良のプラグインは、ゲートウェイ全体の起動をブロックすることがあります。ログにゲートウェイがプラグイン読み込みフェーズで停止していると表示されている場合:
# プラグインを無効にして起動を確認
openclaw start --no-plugins
# 正常に起動した場合、プラグインが原因です
# プラグインを1つずつ有効にして原因を特定してください
ステップ4:最終手段 -- クリーンリスタート
上記のいずれも機能しない場合、クリーンリスタートが原因不明の状態破損の問題を解決することがよくあります:
# すべてを停止
openclaw stop
# ランタイム状態をクリア(設定とメモリは保持)
openclaw reset --keep-config --keep-memory
# 再起動
openclaw start
Docker の場合:
docker stop <container>
docker rm <container>
# 同じ環境変数で再作成
docker run -d --name openclaw \
-e OPENCLAW_GATEWAY_TOKEN=your_token \
-v openclaw_data:/data \
openclaw-stack
OPENCLAW_GATEWAY_TOKEN 環境変数の設定は Docker では非常に重要です。これがないと、ゲートウェイは再起動のたびにトークンを再生成し、デバイスペアリングが壊れます[3]。
ステップ5:修正を確認する
修正を適用した後、ゲートウェイが正常であることを確認します:
# ステータスを確認
openclaw status
# 完全なヘルスチェックを実行
openclaw doctor
# テストメッセージを送信
openclaw send "hello"
以下のように表示されるはずです:
OK gateway is connected
OK gateway version: x.x.x
OK all health checks passed
セルフホスティングに疲れたら
ゲートウェイの起動問題を繰り返しデバッグしている場合、特に共有環境やリソースの少ない VPS では、マネージドホスティングでこれらの問題を完全に排除できます。ClawTank は、コンテナのプロビジョニング、リソース割り当て、リバースプロキシの設定、自動再起動を処理します。インフラストラクチャが事前に設定・監視されているため、ゲートウェイ準備完了エラーは発生しません。
とはいえ、セルフホスティングは完全な制御を提供し、多くのユーザーにとって正しい選択です。上記の手順で「did not become ready」エラーの大半は解決できるはずです。すべて試しても問題が解決しない場合は、OpenClaw の GitHub ディスカッションボードが迅速で有用です[4]。
クイックリファレンスチェックリスト
参考文献
- OpenClaw Gateway Architecture Documentation
- OpenClaw Doctor Command Reference
- OpenClaw Docker Deployment Guide
- OpenClaw GitHub Discussions
OpenClaw をデプロイしませんか?
Docker・SSH・DevOps 不要。1分以内でセットアップ。
無料トライアルを始める