きっかけ：話題のOpenClaw、まずHeadlessから試した
このところ界隈で話題のOpenClaw（旧ClawBot）。AIエージェントフレームワークとして急速に広まり、作者のピーター・シュタインベルガー氏がOpenAIに合流するというニュースも飛び込んできた。
気になって試してみることにした。
まずは最初から難易度の高いHeadless環境（常時稼働するLinuxサーバ）で構築しようとした。が、これが思うように動かない。管理コンソールは起動して、HealthOKになっても、すぐHealth NGになる。原因がどこにあるのか、AIに投げても、解消されず、正解パターンがないのでAIの出すコメントも自分の中で腹落ちしない。Discord設定の複雑さ、環境依存の問題、そもそもOpenClaw自体の理解が不足していた。Headlessでいきなり始めるのはAI使っても無理があったわけだ。それと、OpenAIのサブスク認証も使えず、API利用になることもあり課金の面でもハードルが高い。
方針転換：MacBook Proで動作確認してから移行する
そこで方針を変えた。まず手元のMacBook Pro M1で動かして、OpenClaw自体の動作と設定を理解する。その上でHeadLessのLinuxへの移行にトライするという順番だ。LinuxOSはUbuntu24.04、GUI無しのサーバー版である。
MacBook Pro上での構築は比較的スムーズに進んだ。OpenAIのサブスクプランも認証で使えるのが大きい。Discordの設定でOpenclawでエラーが出ていたことも認識した。
Discord側ともうまく連携でき、KITTというキャラクター名でエージェントを設定。「KITT入力中……」がDiscordに表示された瞬間、本当に動いているという実感が来た。
しかしすぐに問題が出た。MacBookがスリープすると、KITTが無反応になる。 常時稼働させるにはPCを起動し続けるしかない。これは現実的な運用ではない。
MacBook上で動作確認できたことで、Headlessへの移行に必要な設定の全体像も見えてきた。満を持してLinuxへの移行にトライした。
移行後の構成
| 項目 | 内容 |
|---|---|
| ホスト | HP800G5 mini（Ubuntu 24.04） |
| OpenClaw | 2026.2.23 |
| Gateway | systemd常駐 |
| バックアップ | S3（ホスト名付きパス） |
| 管理UI | CaddyでHTTPSリバースプロキシ |
| アクセス | MacからLAN経由でWeb管理 |
前提：OpenClawができることとできないことの境界線
移行を通じて、OpenClawの能力の輪郭がはっきり見えてきた。
スクリプトの作成・実行・テスト、設定ファイルの修正、Cronの登録、バックアップの自動化——PC内部でできる作業はすべて指示だけで完結した。 エディタもターミナルも開かなくていい。
一方で、PC外部の環境は人間が用意する必要がある。 AWS CLIのインストール、IAMの認証情報設定、CaddyのインストールとCA証明書のクライアントへのインポート、DiscordのBot設定——これらはOpenClawには触れない領域だ。
この境界線を最初に理解しておくと、「なぜここだけ手動なのか」という混乱がなくなる。OpenClawはPC内部の優秀な自律エージェントであり、外部環境の設定代行ツールではない。
移行の流れ
Step1：MacBookの設定をバックアップして持ち込む
MacBook上でS3バックアップを取得し、Linux側に展開した。
詰まりどころ①：Macのパスがそのまま残っていた
openclaw.jsonやセッションファイルに/Users/UserNameというMacのパスが大量に残っていた。Linuxで動かすと即座に「EACCES: permission denied, mkdir ‘/Users’」というエラーが出る。
対処法その1：openclaw.jsonのパスを修正する
bash
sed -i 's|/Users/UserName|/home/UserName|g' ~/.openclaw/openclaw.json対処法その2：セッションファイルと実行承認ファイルをリセットする
バックアップを取った上でリセットした。
bash
cp ~/.openclaw/agents/main/sessions/sessions.json \
~/.openclaw/agents/main/sessions/sessions.json.bak
cp ~/.openclaw/exec-approvals.json \
~/.openclaw/exec-approvals.json.bak
echo '[]' > ~/.openclaw/agents/main/sessions/sessions.json
sed -i 's|/Users/osmaniax|/home/osmaniax|g' \
~/.openclaw/exec-approvals.json詰まりどころ②：gateway.modeの設定ミス
Headless運用に向けてgateway.modeをserverに変更したところ、「Invalid input」というエラーが出た。OpenClawが受け付ける値ではなかった。modeはlocalのままでいい。
Gatewayはローカルループバック（127.0.0.1:18789）で動く設計なので変更不要だ。
詰まりどころ③：S3バックアップが通らない
バックアップスクリプトを実行したところ2つのエラーが出た。
1つ目はaws: command not found。AWS CLI未導入だった。これは外部環境の準備なので人間が対応する。sudo apt install awscli -yでインストールした。
2つ目はThe config profile (default) could not be found。AWS CLIは入っていても認証情報が未設定だった。aws configure --profile defaultでアクセスキー、シークレットキー、リージョンを設定して再実行。最終的に s3://openclaw-settings/openclaw-backup/PCNAME/<timestamp>.tar.gz というパスへの保存を確認した。
またバックアップスクリプトにMac専用コマンドscutilが残っていた。これはPC内部の作業なのでOpenClawへの指示で修正できる。HOST="$(hostname)"への書き換えで対応した。
詰まりどころ④：管理UIへの接続（最大の山場）
Discordとの連携はスムーズに開通した。設定を入れてテスト送信すると、あっさり動いた。
しかしDiscordだけでなく、Web UIでも状態確認や設定変更ができるようにしたかった。 ここから苦労が始まった。
OpenClawのWeb UIはセキュリティ上の理由から、SSL通信（HTTPS）でないと正常に動作しない。 HTTPで接続しようとすると、secure contextエラー、gateway token missing、pairing required、origin not allowedといったエラーが次々と出る。ブラウザのセキュリティポリシーとOpenClaw側の要件が重なっており、HTTPでは突破できない構造だ。
解決策：LinuxにCaddyでリバースプロキシを構築する
CaddyのインストールはPC外部の環境準備なので人間が対応する。OpenClaw自体はloopback（127.0.0.1:18789）のまま触らず、前段にCaddyをリバースプロキシとして置く構成にした。CaddyはLinux内部でHTTPS終端を担い、自己署名証明書を自動発行する。アクセスの流れはこうなる。
Mac（ブラウザ） → https://192.168.xxx.xxx → Caddy（自己証明書） → 127.0.0.1:18789（OpenClaw）
自己署名証明書はそのままではブラウザに弾かれるため、MacにCaddyのローカルCAをインポートして信頼登録した。これも外部環境の準備なので人間が対応する作業だ。最終的にtoken入力とdevice pairing承認を通すことで、MacブラウザからWeb UIへの安定接続を確立した。
この構成のポイントはOpenClawをインターネットに直接晒さない点だ。Caddyが前段で受けてloopbackに流すため、セキュリティを保ちながらLAN内からWeb管理が可能になる。
OpenAIサブスクの引き継ぎとOllamaとの併用構成
サブスク認証はHeadlessにそのまま持ち込める
MacBook Pro上でローカル認証したOpenAIのサブスクリプションは、設定ごとLinuxに持ち込むことで認証を引き継げることがわかった。API課金なしでHeadless運用できる可能性がある点は、コスト面で大きなメリットだ。
ただしセッション期間が切れると再認証が必要になる。 更新の自動化については現在調査中だ。またレポートする。
セッション切れ時のバックアップとしてOllamaを並行運用する
セッション切れのリスクに備えて、ローカルLLMのOllamaをOpenAIサブスクと並行運用する構成を想定している。移行先のHP800G5にはOllamaが既に稼働しており、API応答も確認済みだ。運用の切り分けはDiscordチャンネルで分ける設計だ。
| チャンネル | モデル | 用途 |
|---|---|---|
| メインチャンネル | OpenAI Codex（サブスク） | 重い判断・重要な運用 |
| サブチャンネル | Ollama（ローカル） | 軽い処理・サブスク切れ時のバックアップ |
この構成により、サブスクのセッションが切れても完全に無反応になるリスクを回避できる。
お試しスキル作成、ジョブの登録
まずは試しにこんなスキルを作成した。更新有無を確認し、更新があれば#openclaw-logチャンネルにDiscord通知するというものだ。毎日6時に実行するようジョブを設定した。
通知内容は現在のバージョン、対象バージョン、updateコマンド、ChangeLog URLの4点だ。これで手動チェック忘れを解消した。
移行完了後のチェックリスト
これから同じ移行をする人向けに、最短確認リストをまとめる。
- openclaw status が正常
- Gateway service が enabled/running
- S3バックアップが1回成功
- openclaw cron list で更新監視ジョブ確認
- 管理UIはHTTPS経由で接続
- token/pairingを通してWS接続が確立
まとめ
今回の移行で、OpenClaw運用は「ノートPC依存のスポット運用」から「常時稼働の実運用基盤」に変わった。
振り返ると、最初からHeadlessで始めようとして詰まったのは、OpenClaw自体の理解が足りていなかったからだ。MacBook Proで動作確認してから移行するという順番が正解だった。 同じように試みる人にはこの順番を強く勧める。
そしてもう一つ重要な気づきがある。OpenClawはPC内部の作業は指示だけで完結するが、外部環境の準備は人間がやる必要がある。 この境界線を最初に理解しているかどうかで、躓き方が大きく変わる。
特に効いた3点はこれだ。バックアップの自動化（S3）、更新監視の自動通知（Cron + Discord）、HTTPS化された遠隔管理UI（Caddy + token/pairing）。
同じようにmacOSからLinuxへ移す人は、「バックアップ」「認証」「HTTPS」を先に固めると、移行後のトラブルが激減する。
※筆者の運用する別サイトでも記事を書いています。
