OpenClaw未インストール？ここをクリックしてワンラインインストールコマンドを表示
curl -fsSL https://openclaw.ai/install.sh | bash
iwr -useb https://openclaw.ai/install.ps1 | iex
curl -fsSL https://openclaw.ai/install.cmd -o install.cmd && install.cmd && del install.cmd
PCへの影響が心配？ ClawTank はクラウドで実行 — インストール不要、誤削除のリスクなし
主要な知見
  • OpenClaw Gatewayはエージェントシステム全体の中枢ハブであり、デフォルトポート18789でWebSocketプロトコルを介して動作し、タスクスケジューリング、Node管理、LLMリクエストルーティングを担当する[1]
  • Gatewayにはローカルとリモートの2つの動作モードがある。ローカルモードは127.0.0.1のみにバインドし、個人開発に最適。リモートモードはToken認証によりデバイス間・ネットワーク間のアクセスをサポートする[3]
  • ヘッドレスモードとsystemdまたはDockerコンテナ化を組み合わせることで、グラフィカルインターフェースなしのクラウドサーバーで24時間365日の安定したサービスを実現できる
  • Tailscaleはゼロコンフィグの安全なVPNトンネルを提供し、ポートフォワーディングやダイナミックDNSの複雑さを排除する — 個人および小規模チームのGatewayリモートアクセスに最適な選択肢[4]
  • Gateway TokenはリモートモードにおけるTokenは唯一の認証メカニズムである。自動ローテーションを有効にし、TLS暗号化通信と組み合わせて、エージェントシステムへの不正アクセスを防止することが推奨される[5]

OpenClawチュートリアルを初めて起動すると、システムはローカルマシン上で自動的にGatewayサービスを開始します。その存在に気づかないかもしれません — バックグラウンドで静かに動作し、CLIやWeb UIから送信されるすべてのコマンドを受信し、Nodeを調整してタスクを実行し、結果を返します。一見透明なこのコンポーネントは、実はOpenClawエージェントアーキテクチャ全体の神経中枢です。[1]

ニーズが「自分のノートPCでいくつかのタスクを実行する」を超えた場合 — 例えば、スマートフォンからリモートでエージェントをトリガーしたい、クラウドVPSで24時間365日の自動化ワークフローをデプロイしたい、またはチームメンバーと単一のGatewayリソースを共有したい場合 — Gatewayのモード切替、デプロイ戦略、セキュリティ設定を深く理解する必要があります。

本記事ではGatewayのアーキテクチャ上の役割から始まり、ローカルおよびリモート両モードの設定方法、ヘッドレスクラウドデプロイの完全な手順、Tailscaleによる安全なリモートアクセス、Gateway Token認証メカニズム、そして本番環境で発生しやすい問題のトラブルシューティング戦略を体系的に解説します。OpenClawを始めたばかりの開発者から、クラウドデプロイを計画しているDevOpsエンジニアまで、本ガイドが必要な技術リファレンスを提供します。

1. Gatewayとは？OpenClawアーキテクチャにおける役割

GatewayはOpenClawエージェントシステムの統一エントリポイントでありスケジューリングコアです。ポート18789でWebSocketサーバーとして動作し、すべてのNode、Channel、外部クライアント間の通信における唯一のハブとして機能します。[1]

1.1 4層アーキテクチャにおけるGatewayの位置

OpenClawのランタイムアーキテクチャは4層で構成されています：

このアーキテクチャにおけるGatewayの責務は単なる「メッセージ転送」をはるかに超えています：スケジューリング用のTask Queueを維持し、各Workspaceのコンテキストメモリと会話履歴を管理し、異なるLLMプロバイダーへのAPIリクエストを調整（レート制限、キールーティング）し、Node接続のライフサイクル（登録、ハートビート、切断回復）を処理します。

1.2 WebSocketプロトコルとポート18789

Gatewayがコアのcommunicationプロトコルとして従来のHTTPではなくWebSocketを採用しているのは、AIエージェントのワークフローが本質的に双方向かつ長時間持続するものだからです — Nodeはリアルタイムでタスクの割り当てを受ける必要があり、Gatewayは実行の進捗と結果をリアルタイムで取得する必要があります。WebSocketの全二重通信はこの要件に完璧に適合します。[2]

デフォルトポート18789はIANA登録ポート範囲（1024-49151）に収まるため、一般的なサービスと競合する可能性は低いです。Gatewayは同じポートでヘルスチェック（/health）、ステータスクエリ（/status）、REST APIアクセス用のHTTPエンドポイントも提供します。

以下のコマンドでGatewayの実行状態をいつでも確認できます：

# Gatewayの実行状態を確認
openclaw gateway status

# 予想される出力
# Gateway Status: running
# Mode: local
# Address: ws://127.0.0.1:18789
# Uptime: 2h 15m 32s
# Connected Nodes: 1
# Active Tasks: 0
# Queued Tasks: 0

Gatewayが実行されていない場合、openclaw gateway statusはGateway Status: stoppedを返します。手動で起動できます：

# Gatewayを手動で起動
openclaw gateway start

# Gatewayを手動で停止
openclaw gateway stop

# Gatewayを再起動
openclaw gateway restart

2. ローカルモード vs リモートモード：違いと選択

OpenClaw Gatewayは、根本的に異なる2つのユースケースに対応する2つのコア動作モードを提供します。その違いを理解することが適切なデプロイの第一歩です。[3]

2.1 ローカルモード

バインドアドレス：127.0.0.1:18789（ループバックインターフェースのみ）

ローカルモードはインストール後のデフォルト状態です。Gatewayは同一マシンからの接続のみを受け入れ、外部ネットワークからのアクセスはまったくできません。攻撃対象がローカルOSレベルに限定されるため、これが最も安全な構成です。[5]

ユースケース：

制限事項：

2.2 リモートモード

バインドアドレス：0.0.0.0:18789（すべてのネットワークインターフェース）または指定インターフェース

リモートモードでは任意のネットワークからの接続が許可されます。有効にすると、Gatewayは不正アクセスを防ぐためにToken認証を要求します。[4]

ユースケース：

制限事項：

2.3 モード比較クイックリファレンス

項目 ローカルモード リモートモード
バインドアドレス 127.0.0.1 0.0.0.0または指定インターフェース
認証 なし（ローカル分離） Gateway Token必須
外部アクセス 不可 可能（認証が必要）
TLS推奨 不要 強く推奨
適切な規模 シングルユーザー、シングルマシン 複数ユーザー、複数デバイス
初期セットアップの難易度 設定不要 中程度

3. ローカルモードの設定

ローカルモードは最もシンプルな出発点です。OpenClawを新規インストールした場合、Gatewayはデフォルトでローカルモードで実行されるため、追加の設定は不要です。[2]

3.1 現在のモードを確認

# 現在のGatewayモードを確認
openclaw config get gateway.mode

# 予想される出力
# gateway.mode = "local"

3.2 ローカルモードに明示的に設定

以前にモードを切り替えたことがある場合、またはローカルモードで実行されていることを確認したい場合：

# Gatewayをローカルモードに設定
openclaw config set gateway.mode local

# 設定を反映するためにGatewayを再起動
openclaw gateway restart

3.3 Gatewayのリスニングアドレスを確認

設定後、Gatewayが確実にループバックインターフェースにのみバインドされていることを確認します：

# Gatewayステータスを確認
openclaw gateway status

# システムツールでポートバインディングを確認（macOS / Linux）
lsof -i :18789

# 127.0.0.1:18789にバインドされていることを確認
# COMMAND   PID     USER   FD   TYPE  SIZE/OFF NODE NAME
# openclaw  12345   user   8u   IPv4  0t0      TCP  127.0.0.1:18789 (LISTEN)

3.4 カスタムポート

デフォルトポート18789はほとんどの場合競合しません。ただし、環境内の別のサービスがこのポートを占有している場合は変更できます：

# Gatewayポートを変更
openclaw config set gateway.port 28789

# 変更を反映するために再起動
openclaw gateway restart

# 新しいポートを確認
openclaw gateway status
# Gateway Status: running
# Mode: local
# Address: ws://127.0.0.1:28789

ポート変更後、すべてのCLIインタラクションは自動的に新しいポートを検出します。ただし、外部ツール（カスタムスクリプトやAPIクライアントなど）を使用してGatewayに接続している場合は、接続アドレスを対応して更新する必要があります。

3.5 openclaw.jsonのGateway設定ブロック

上記のCLIコマンドは、~/.openclaw/openclaw.json内の対応するフィールドを変更することと同等です：

// ~/.openclaw/openclaw.json（Gateway関連設定）
{
  "gateway": {
    "mode": "local",           // "local"または"remote"
    "port": 18789,             // Gatewayリスニングポート
    "host": "127.0.0.1",       // ローカルモードでは自動的に127.0.0.1に設定
    "websocket_path": "/ws",   // WebSocketエンドポイントパス
    "auto_start": true,        // OpenClaw起動時にGatewayを自動起動
    "log_level": "info"        // ログレベル：debug, info, warn, error
  }
}

推奨事項：設定の変更にはopenclaw config set CLIコマンドの使用を推奨します — フォーマットの検証と依存関係チェックを自動的に処理し、手動のJSON編集による構文エラーを回避できます。[3]

4. リモートモードの設定

リモートモードは、OpenClaw Gatewayをネットワークに公開するための重要なステップです。デバイス間アクセス、クラウドデプロイ、チームコラボレーションのいずれが目的でも、以下の設定プロセスが必要です。[4]

4.1 リモートモードの有効化

# リモートモードに切り替え
openclaw config set gateway.mode remote

# システムがGateway Tokenの設定を促す（初回切り替え時）
# > Remote mode requires a gateway token for authentication.
# > Run 'openclaw doctor --generate-gateway-token' to create one.

4.2 Gateway Tokenの生成と設定

Gateway Tokenはリモートモードにおける唯一の認証資格情報です。Gatewayに接続するすべてのクライアントとNodeは、接続時にこのTokenを提供する必要があります。[5]

# 新しいGateway Tokenを生成
openclaw doctor --generate-gateway-token

# 出力例
# Generated gateway token: ogt_a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6
# Token has been saved to your configuration.
#
# To connect from another device, use:
#   openclaw config set gateway.url wss://YOUR_IP:18789/ws
#   openclaw config set gateway.token ogt_a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6

4.3 リモートURLの設定

リモートGatewayに接続する必要があるクライアントマシンで、GatewayのURLとTokenを設定します：

# リモートクライアントで設定（例：スマートフォンや別のコンピュータ）
openclaw config set gateway.url wss://your-server-ip:18789/ws
openclaw config set gateway.token ogt_a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6

# 接続をテスト
openclaw gateway health
# Gateway healthy: wss://your-server-ip:18789/ws
# Authentication: OK

4.4 クラウドデプロイ用のリモート設定

GatewayをクラウドVPS（AWS EC2、GCP Compute Engine、Linode、DigitalOceanなど）にデプロイする場合、リバースプロキシとTLSの併用を推奨します：

# クラウドサーバー上で
openclaw config set gateway.mode remote
openclaw config set gateway.host 127.0.0.1    # Gatewayはlocalhostにバインドしたまま
openclaw config set gateway.port 18789
openclaw doctor --generate-gateway-token

# NginxまたはCaddyがフロントエンドでTLSと認証転送を処理
# クライアント接続アドレス：wss://gateway.yourdomain.com/ws

重要なセキュリティ原則：リモートモードであっても、Gatewayが直接0.0.0.0でリッスンしてパブリックインターネットに公開することは推奨しません。正しいアーキテクチャは、Gatewayが引き続き127.0.0.1にバインドし、フロントエンドのNginx/Caddyリバースプロキシが外部TLS接続を受け入れてローカルループバック経由でGatewayに転送する構成です。[7]

4.5 openclaw.json リモート設定の完全な例

// ~/.openclaw/openclaw.json（リモートモードの完全設定）
{
  "gateway": {
    "mode": "remote",
    "port": 18789,
    "host": "127.0.0.1",
    "websocket_path": "/ws",
    "auto_start": true,
    "log_level": "info",
    "token": "ogt_a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6",
    "allowed_origins": [
      "https://gateway.yourdomain.com",
      "https://app.yourdomain.com"
    ],
    "rate_limit": {
      "enabled": true,
      "max_requests_per_minute": 120,
      "max_connections": 50
    }
  }
}

5. ヘッドレス運用：GUI環境のないサーバーへのGatewayデプロイ

OpenClawのデフォルトの起動プロセスはGUIコンポーネント（システムトレイアイコン、通知ウィンドウなど）の初期化を試みます。デスクトップ環境のないLinuxサーバーやDockerコンテナでは、これにより起動が失敗します。ヘッドレスモードはすべてのGUI初期化をスキップし、Gatewayのコアサービスのみを起動します。[6]

5.1 基本的なヘッドレス起動

# 方法1：フォアグラウンド実行（screen/tmuxでの使用を推奨）
openclaw gateway run

# 方法2：環境変数
export OPENCLAW_HEADLESS=true
openclaw gateway run

# 方法3：設定ファイルに書き込んでから起動
openclaw config set gateway.headless true
openclaw gateway run

5.2 screen/tmuxによる永続化

SSHセッションで起動したプロセスは、SSH接続が切断されると終了します。最もシンプルな永続化ソリューションはscreenまたはtmuxです：

# screenを使用
screen -S openclaw-gw
OPENCLAW_HEADLESS=true openclaw gateway run
# Ctrl+A、次にDを押してデタッチ
# 後で再接続：screen -r openclaw-gw

# tmuxを使用（推奨）
tmux new-session -d -s openclaw -n gateway
tmux send-keys -t openclaw:gateway \
'OPENCLAW_HEADLESS=true openclaw gateway run' Enter

# ログ監視ウィンドウを追加
tmux new-window -t openclaw -n logs
tmux send-keys -t openclaw:logs \
'tail -f ~/.openclaw/logs/gateway.log' Enter

# 再接続：tmux attach -t openclaw

5.3 systemdサービス設定（本番環境推奨）

ブート時の自動起動、自動再起動、システムログ統合が必要な本番環境では、systemdが標準的な選択です：

# /etc/systemd/system/openclaw-gateway.service

[Unit]
Description=OpenClaw Gateway Service
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=openclaw
Group=openclaw
WorkingDirectory=/opt/openclaw
Environment="OPENCLAW_HEADLESS=true"
Environment="OPENCLAW_GATEWAY_HOST=127.0.0.1"
Environment="OPENCLAW_GATEWAY_PORT=18789"
Environment="OPENCLAW_LOG_LEVEL=info"
EnvironmentFile=-/opt/openclaw/.env
ExecStart=/usr/local/bin/openclaw gateway run
ExecReload=/bin/kill -HUP $MAINPID
Restart=always
RestartSec=10
StandardOutput=journal
StandardError=journal
SyslogIdentifier=openclaw-gateway

# セキュリティ強化
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
ReadWritePaths=/opt/openclaw/data /opt/openclaw/logs

# リソース制限
LimitNOFILE=65536
LimitNPROC=4096

[Install]
WantedBy=multi-user.target
# 専用システムユーザーを作成
sudo useradd -r -s /usr/sbin/nologin -d /opt/openclaw openclaw
sudo mkdir -p /opt/openclaw/{data,logs,config}
sudo chown -R openclaw:openclaw /opt/openclaw

# サービスを有効化して起動
sudo systemctl daemon-reload
sudo systemctl enable openclaw-gateway
sudo systemctl start openclaw-gateway

# ステータスとログを確認
sudo systemctl status openclaw-gateway
sudo journalctl -u openclaw-gateway -f

5.4 Dockerコンテナ化デプロイ

Dockerは環境分離とバージョン管理の利点を提供し、クラウドデプロイの主流ソリューションです：

# Dockerfile
FROM python:3.11-slim-bookworm

RUN apt-get update && apt-get install -y --no-install-recommends \
curl git ca-certificates && rm -rf /var/lib/apt/lists/*

RUN groupadd -r openclaw && useradd -r -g openclaw -d /app openclaw
WORKDIR /app

RUN pip install --no-cache-dir openclaw

RUN mkdir -p /app/data /app/logs && chown -R openclaw:openclaw /app
USER openclaw

ENV OPENCLAW_HEADLESS=true \
OPENCLAW_GATEWAY_HOST=0.0.0.0 \
OPENCLAW_GATEWAY_PORT=18789 \
OPENCLAW_DATA_DIR=/app/data \
OPENCLAW_LOG_DIR=/app/logs

EXPOSE 18789

HEALTHCHECK --interval=30s --timeout=10s --start-period=60s --retries=3 \
CMD curl -f http://localhost:18789/health || exit 1

CMD ["openclaw", "gateway", "start", "--headless"]
# docker-compose.yml
version: '3.8'

services:
openclaw-gateway:
  build: .
  container_name: openclaw-gw
  restart: unless-stopped
  env_file:
    - .env.gateway
  volumes:
    - openclaw-data:/app/data
    - openclaw-logs:/app/logs
  expose:
    - "18789"
  healthcheck:
    test: ["CMD", "curl", "-f", "http://localhost:18789/health"]
    interval: 30s
    timeout: 10s
    retries: 3

nginx:
  image: nginx:1.25-alpine
  container_name: openclaw-nginx
  restart: unless-stopped
  ports:
    - "443:443"
    - "80:80"
  volumes:
    - ./nginx.conf:/etc/nginx/conf.d/default.conf:ro
    - /etc/letsencrypt:/etc/letsencrypt:ro
  depends_on:
    openclaw-gateway:
      condition: service_healthy

volumes:
openclaw-data:
openclaw-logs:
# ビルドして起動
docker compose up -d --build

# ログを確認
docker compose logs -f openclaw-gateway

# Gatewayを再起動
docker compose restart openclaw-gateway

# デバッグのためコンテナに入る
docker compose exec openclaw-gateway /bin/bash

6. Tailscaleリモートアクセス：ゼロコンフィグの安全なVPN

従来のリモートアクセス方法（ポートフォワーディング、ダイナミックDNS、自己署名証明書）は個人開発者にとって煩雑でエラーが発生しやすいものです。Tailscaleは極めてシンプルな代替手段を提供します：インストールしてすぐ使えるWireGuard VPNトンネルで、すべてのデバイスが同じローカルネットワーク上にあるかのように接続できます。[4]

6.1 Tailscaleを選ぶ理由

6.2 セットアップ手順

# ステップ1：GatewayサーバーにTailscaleをインストール
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

# ステップ2：Tailscale IPを確認
tailscale ip -4
# 例：100.64.0.1

# ステップ3：Tailscaleインターフェースでリッスンするようにgatewayを設定
openclaw config set gateway.mode remote
openclaw config set gateway.host 100.64.0.1
openclaw doctor --generate-gateway-token
openclaw gateway restart

# ステップ4：クライアントデバイスにTailscaleをインストールして接続
# （macOS / Windows / iOS / Androidすべて対応）
sudo tailscale up

# ステップ5：クライアントでGateway接続を設定
openclaw config set gateway.url ws://my-server.tailnet-name.ts.net:18789/ws
openclaw config set gateway.token ogt_your_token_here

# 接続をテスト
openclaw gateway health

6.3 Tailscale ACLアクセス制御

TailscaleのACL（アクセス制御リスト）を使用すると、どのデバイスがGatewayにアクセスできるかを精密に制御できます：

// tailscale ACLポリシー（Tailscale管理コンソールで設定）
{
"acls": [
  {
    "action": "accept",
    "src": ["tag:openclaw-client"],
    "dst": ["tag:openclaw-gateway:18789"]
  }
],
"tagOwners": {
  "tag:openclaw-gateway": ["autogroup:admin"],
  "tag:openclaw-client": ["autogroup:admin"]
}
}

6.4 Tailscale Funnel（上級：パブリック共有）

Tailscaleを使用していない外部ユーザーにGatewayへのアクセスを許可する必要がある場合（例：クライアントへのデモ用）、Tailscale Funnelを使用して一時的に公開できます：

# Gatewayを一時的にインターネットに公開（自動HTTPS）
tailscale funnel 18789

# 外部ユーザーは以下のアドレスでアクセス可能
# https://my-server.tailnet-name.ts.net/

# Funnelを無効化
tailscale funnel --reset

注意：FunnelはGatewayをパブリックインターネットに公開します。TailscaleのHTTPS暗号化があっても、不正アクセスを防ぐためにGateway Tokenが設定されていることを確認してください。[8]

7. Gateway Tokenのセキュリティ

Gateway Tokenは、リモートモードにおいてコンピュータ全体を保護する最後の防衛線です。OpenClawエージェントはShellコマンドの実行、ファイルシステムの操作、ブラウザの制御が可能です — つまり、Gateway Tokenを入手した人は理論的にマシンに対してあらゆることができます。[5][7]

7.1 Token生成とフォーマット

# 新しいTokenを生成
openclaw doctor --generate-gateway-token

# Tokenフォーマット：ogt_ プレフィックス + 32文字のランダム文字列
# 例：ogt_a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6

# Tokenを手動指定（特別な必要がない限り非推奨）
openclaw config set gateway.token "your-custom-token-here"

7.2 Tokenのローテーション

Tokenの定期的な変更はセキュリティのベストプラクティスであり、特に以下のシナリオで重要です：

# Tokenを再生成（古いTokenは直ちに無効化）
openclaw doctor --generate-gateway-token --force

# 接続中のすべてのクライアントとNodeが強制切断される
# 各クライアントで新しいTokenを更新する必要がある
openclaw config set gateway.token ogt_new_token_here

7.3 セキュリティベストプラクティス

# 最近の認証失敗記録を確認
openclaw logs --follow --limit 100

# 認証失敗ロックアウトを設定（5回連続失敗でソースIPを15分間ブロック）
openclaw config set gateway.security.max_auth_failures 5
openclaw config set gateway.security.lockout_duration_minutes 15

7.4 環境変数によるToken管理

自動化デプロイでは、Tokenは設定ファイルに記述するのではなく、環境変数で注入すべきです：

# .env.gateway（バージョン管理にコミットしないこと）
OPENCLAW_GATEWAY_TOKEN=ogt_a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6
OPENAI_API_KEY=sk-...
ANTHROPIC_API_KEY=sk-ant-...

# systemdでの使用
EnvironmentFile=/opt/openclaw/.env.gateway

# Docker Composeでの使用
env_file:
- .env.gateway

# .env.gatewayのファイルパーミッションを確認
chmod 600 /opt/openclaw/.env.gateway
chown openclaw:openclaw /opt/openclaw/.env.gateway

8. よくある問題とトラブルシューティング

以下は、OpenClaw Gatewayのデプロイ時に最もよく発生する問題とその解決策をまとめたものです。[3]

8.1 ポートの競合

症状：Gatewayの起動に失敗し、ログにAddress already in use: 0.0.0.0:18789と表示される

# ポート18789を占有しているプロセスを確認
sudo lsof -i :18789
# または
sudo ss -tlnp | grep 18789

# よくある原因：前のGatewayプロセスが正常に終了しなかった
# 解決策1：占有プロセスを終了
sudo kill -9 $(lsof -t -i :18789)

# 解決策2：別のポートを使用
openclaw config set gateway.port 28789
openclaw gateway restart

8.2 リモートモードの接続失敗

症状：クライアントがリモートGatewayに接続できず、Connection refusedまたはConnection timed outと表示される

# トラブルシュートステップ1：Gatewayが実行中か確認
openclaw gateway status

# トラブルシュートステップ2：Gatewayのリスニングアドレスを確認
ss -tlnp | grep 18789
# 127.0.0.1:18789と表示される場合、Gatewayはローカル接続のみ受け入れる
# リバースプロキシまたはTailscaleとの併用が必要

# トラブルシュートステップ3：ファイアウォールルールを確認
sudo ufw status
sudo iptables -L -n | grep 18789

# トラブルシュートステップ4：ネットワーク接続性をテスト
# クライアント側で実行
curl -v http://your-server-ip:18789/health
# または（リバースプロキシを使用している場合）
curl -v https://gateway.yourdomain.com/health

# トラブルシュートステップ5：Tokenが正しいか確認
openclaw config get gateway.token

8.3 WebSocket接続の切断

症状：タスク実行中に接続が切断され、ログにWebSocket connection closed unexpectedlyと表示される

# 最も一般的な原因：リバースプロキシのタイムアウト設定が短すぎる

# Nginxの修正：proxy_read_timeoutを増やす
# /etc/nginx/conf.d/openclaw.conf
location /ws {
  proxy_pass http://127.0.0.1:18789;
  proxy_http_version 1.1;
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection "upgrade";
  proxy_read_timeout 3600s;    # 最低1時間
  proxy_send_timeout 3600s;
  proxy_connect_timeout 30s;
}

# Gateway側の修正：ハートビート間隔を調整
openclaw config set gateway.websocket.ping_interval 30
openclaw config set gateway.websocket.ping_timeout 10

8.4 ヘッドレス起動の失敗

症状：GUIのないサーバーで起動時にcannot open displayまたはGtk initialization failedと表示される

# フォアグラウンドモードを使用（GUIは不要）
openclaw gateway run

# または環境変数を設定
export OPENCLAW_HEADLESS=true
export DISPLAY=    # DISPLAY変数をクリア

# Node.jsバージョンを確認（22以上が必要）
node --version

# OpenClawが正しくインストールされていることを確認
openclaw --version

8.5 Gatewayステータスクエリコマンドリファレンス

# 完全なステータスレポート
openclaw gateway status --deep

# JSON形式出力（スクリプト処理に便利）
openclaw gateway status --json

# ヘルスチェック（監視システムに適した形式）
openclaw gateway health
curl -s http://127.0.0.1:18789/health | python3 -m json.tool

9. クラウドデプロイアーキテクチャの推奨事項

チーム規模と信頼性要件に基づき、3つのクラウドデプロイアーキテクチャを推奨します。

9.1 個人/小規模プロジェクト：VPS + Caddy

最低コスト、最小のメンテナンス負担のデプロイ。個人開発者または1～3人のチームに適しています。

# アーキテクチャトポロジ
[クライアントデバイス] --wss--> [Caddy :443] --> [Gateway :18789] --> [LLM APIs]

# Caddyfile（自動TLS）
gateway.yourdomain.com {
reverse_proxy /ws localhost:18789 {
  header_up Upgrade {http.upgrade}
  header_up Connection "Upgrade"
  transport http {
    read_timeout 1h
    write_timeout 1h
  }
}
reverse_proxy localhost:18789
}

# 推奨VPSスペック：2 vCPU / 4 GB RAM / 40 GB SSD
# 月額コスト：約$5～$20 USD（Linode、DigitalOcean、Vultr）

9.2 中規模チーム：Docker Compose + Nginx + モニタリング

正式なモニタリングとロギングインフラが必要な5～20人のチームに適しています。

# アーキテクチャトポロジ
[複数クライアント] --wss--> [Nginx :443]
                          |
                    [Gateway :18789]
                          |
              +-----------+-----------+
              |           |           |
          [Prometheus] [Grafana]  [Loki]

# デプロイコマンド
docker compose -f docker-compose.yml \
-f docker-compose.monitoring.yml up -d

9.3 本番環境チェックリスト

Gatewayを本番環境にプッシュする前に、各項目を検証してください：[7][8]

セキュリティ

信頼性

パフォーマンス

リソース計画

規模 同時タスク数 CPU メモリ ストレージ
個人 1～3 2 vCPU 4 GB 20 GB SSD
小規模チーム 5～10 4 vCPU 8 GB 50 GB SSD
エンタープライズ 20以上 8以上 vCPU 16以上 GB 200 GB NVMe

9.4 自動バックアップスクリプト

#!/bin/bash
# /opt/scripts/backup-openclaw.sh
set -euo pipefail

BACKUP_DIR="/backups/openclaw"
DATE=$(date +%Y%m%d-%H%M%S)
RETENTION_DAYS=30

mkdir -p "$BACKUP_DIR"

# Workspaceデータをバックアップ
tar czf "$BACKUP_DIR/workspace-$DATE.tar.gz" \
/opt/openclaw/data/

# 設定をバックアップ（機密性の高い.envファイルを除く）
tar czf "$BACKUP_DIR/config-$DATE.tar.gz" \
/opt/openclaw/config/

# 古いバックアップをクリーンアップ
find "$BACKUP_DIR" -name "*.tar.gz" \
-mtime +$RETENTION_DAYS -delete

echo "[$(date)] バックアップ完了: workspace-$DATE.tar.gz"
# 毎日午前2時にバックアップするためのCronジョブを追加
echo "0 2 * * * /opt/scripts/backup-openclaw.sh >> /var/log/openclaw-backup.log 2>&1" \
| sudo crontab -u openclaw -

まとめ

OpenClaw Gatewayをローカルモードからリモートモードに切り替えることは、本質的に「個人ツール」から「インフラストラクチャ」への意識の転換です。ローカルモードでは、Gatewayはラップトップ上の静かなバックグラウンドサービスです。リモートモードでは、真剣に扱うべきネットワークサービスとなり、認証、暗号化、モニタリング、バックアップ、そして災害復旧計画が必要になります。

本記事で取り上げたデプロイパスは、3つの段階的なステージにまとめることができます：

どのステージを選ぶかは、具体的なニーズによります。個人開発者の自動化アシスタントであれば、Tailscaleアプローチが最適なソリューションかもしれません。エンタープライズユーザーにサービスを提供するエージェントプラットフォームであれば、Docker + リバースプロキシ + モニタリングのフルスタックが必要です。[6]

OpenClawコミュニティが成長を続ける中、[2]Gatewayの機能も急速に進化しています。クラスター協調、マルチGateway同期、Zero-Trustセキュリティモデルに関する公式ドキュメントの更新を注視することをお勧めします — これらは、OpenClawが個人の生産性ツールからエンタープライズグレードのAIエージェントプラットフォームへと進化するための重要なパスを決定します。[1]