OpenClawをラズパイで動かすのは限界があった。Docker環境で高速＆セキュアに動かしてみた

AI

「ラズパイで動かせば電気代も安いし、24時間回せるじゃん」——そう思って始めたOpenClaw（旧：Moltbot /Clawdbot）のセルフホスト。ところが現実は甘くなかった。APIはタイムアウトを連発し、しかもAIは正直に「止まりました」と言わず「あと70%で終わります」と嘘をつく始末。まるで納期に追われた人間のようだった。

結論から言うと、WindowsデスクトップPC × WSL2 ×
Dockerという構成に切り替えたことで、すべてが解決した。ただし、そこに至るまでに踏み抜いた地雷の数は片手では足りない。この記事では、同じ沼にハマりかけているエンジニアのために、エラーメッセージごとの具体的な解決コマンドをすべて記録しておく。

  1. Raspberry Piの限界——「タイムアウト地獄」からの脱出
    1. なぜラズパイではダメだったのか
    2. AIが嘘をつく——衝撃の発見
    3. 移行先の選定——なぜWSL2 + Dockerなのか
  2. Docker環境の構築——docker-compose.ymlとの格闘
    1. そもそもDockerとは？——初心者向けにざっくり解説
    2. 前提条件と基本セットアップ
    3. 「allowedOrigins」の罠——AIに従ったら起動ループ地獄
    4. 解決策：CLIからallowedOriginsを設定する
  3. トークン不一致と「ペアリング」——デバイス認証の壁
    1. 「token mismatch」の正体
    2. ペアリングの手順
    3. なぜここまで厳しいのか？
  4. Discord連携——「沈黙のBot」を喋らせるまで
    1. Botは動いている、でも反応しない
    2. 原因：デフォルトで全アクセス拒否
    3. 解決策：guildsとallowFromの設定
    4. 「requireMention: true」にすべき理由
  5. 環境比較とセキュリティモデルの全体像
    1. ラズパイ vs デスクトップPC：パフォーマンス比較
    2. OpenClawのセキュリティレイヤー
  6. よくある質問（FAQ）
    1. Q1. WSL2のバージョンは関係ありますか？
    2. Q2. OpenClawのアップデートはどうすればいいですか？
    3. Q3. 複数のDiscordサーバーで使いたい場合は？
    4. Q4. APIのタイムアウトがまだ発生する場合は？
    5. Q5. セキュリティ設定を間違えてロックアウトされた場合は？
  7. まとめ——「高速 × セキュア」な理想のAIエージェント環境
    1. 踏んだ地雷を振り返る
    2. 手に入れた環境

Raspberry Piの限界——「タイムアウト地獄」からの脱出

なぜラズパイではダメだったのか

Raspberry Pi 4（RAM 4GB /
8GB）で24時間AIエージェントを稼働させる——コンセプトとしては最高だ。消費電力は数ワット、ファンレスで静音、場所も取らない。しかし、自律型AIエージェントのホスティングには致命的な弱点があった。

  • ARM アーキテクチャの互換性問題：一部のNode.jsネイティブモジュールがARM向けにビルドされておらず、ビルド時にエラーが発生するケースがある
  • microSDの読み書き速度：DockerのレイヤーキャッシュやコンテナのファイルシステムがmicroSDの遅延をモロに受ける。特にログの書き込みが重なるとI/Oがボトルネックになる
  • メモリ不足：GatewayプロセスとCLI、さらにDiscord連携用のプロセスが同時に走ると、スワップが発生してさらに遅くなる
  • API タイムアウトの頻発：上記が複合的に作用し、外部APIへのリクエストが処理内で滞留。結果としてタイムアウトエラーが頻発する

AIが嘘をつく——衝撃の発見

正直、一番驚いたのはエラーそのものではなかった。タイムアウトで処理が止まっているのに、AIが「あと70%で完了します」と平然と報告してきたこと。実際にはタスクは進んでおらず、再開後にゼロからやり直し。

これはOpenClawの問題というより、LLM（大規模言語モデル）の特性だ。応答が途切れたことを正確に認識できず、「もっともらしい続き」を生成してしまう。まるで進捗報告で水増しする人間のようだ、と苦笑するしかなかった。

💡 教訓：AIエージェントの自律運用では、ログの外部監視が必須。AIの自己申告を鵜呑みにせず、実際のファイル変更やGitコミットの有無で進捗を確認するべき。

移行先の選定——なぜWSL2 + Dockerなのか

移行先として検討した選択肢と、最終的にWSL2 + Dockerを選んだ理由を整理する。

選択肢 メリット デメリット
クラウドVPS（AWS / GCP） スペック自由、安定稼働 月額コストが高い、外部にデータを置く不安
ラズパイ5に買い替え 省電力のまま性能向上 根本的なI/O・メモリ問題は残る
WindowsデスクトップPC + WSL2 既存PCを活用、高性能CPU/RAM、SSD 電気代が増える、PCを起動しておく必要がある

すでに手元にあるデスクトップPC（Ryzen / Intel Core搭載、RAM 16GB以上、NVMe SSD）を使えば、追加コストゼロで圧倒的なスペック向上が手に入る。Docker Desktop for
Windows + WSL2バックエンドなら、Linux環境と同等の操作感でコンテナを扱える。迷う理由はなかった。

Docker環境の構築——docker-compose.ymlとの格闘

そもそもDockerとは？——初心者向けにざっくり解説

ここで「Docker」という言葉に馴染みがない方のために、ざっくり説明しておく。

Dockerとは、アプリケーションを「コンテナ」と呼ばれる箱に詰めて動かす仕組みだ。普通にソフトをインストールすると、OSの設定やライブラリがぐちゃぐちゃに混ざってしまう。が、Dockerを使えば箱の中に必要なものが全部入っているので、PCの環境を汚さずに動かせる。

イメージとしては、こんな感じだ。

  • 従来のインストール：自分の部屋（PC）に家具（ソフト）を直接置く → 引っ越し（再構築）が大変
  • Docker：段ボール箱（コンテナ）に家具を詰めて部屋に置く → 箱ごと捨てれば元通り、別の部屋にも持っていける

OpenClawのようなAIエージェントは依存関係が多く、直接インストールするとトラブルの温床になる。Docker環境で動かすことで、「壊れたら箱ごと作り直す」という気軽さが手に入る。これが最大のメリットだ。

前提条件と基本セットアップ

まず、以下が揃っていることを確認する。

  • Windows 10/11（WSL2 有効化済み）
  • Docker Desktop for Windows（WSL2 バックエンドを使用）
  • Git（WSL2内 or Windows側どちらでも可）

自分の場合は、もともと開発用にDocker環境を構築済みだったので、上記の前提条件はすべてクリア。すぐにOpenClawの導入に取りかかれた。Docker
Desktopの初期設定で苦労する方もいるが、既に環境がある人ならここまでは5分もかからない。

OpenClawの公式リポジトリをクローンし、Docker Composeで起動する。基本的な手順はシンプルだ。

# リポジトリのクローン
git clone https://github.com/openclaw/openclaw.git
cd openclaw

# Docker Composeで起動
docker compose up -d

ここまでは教科書通り。問題はこの直後に起きた。

「allowedOrigins」の罠——AIに従ったら起動ループ地獄

docker compose up -d を叩いた直後、Gatewayコンテナが永遠にRestartingを繰り返す。ログを見ると、こんなエラーが延々と吐き出されていた。

Error: non-loopback Control UI requires gateway.controlUi.allowedOrigins

実はこのループ、AIアシスタントに手順を聞きながら進めていたら陥った罠だった。AIが提示した手順通りにdocker-compose.ymlを編集して起動したのだが、肝心のallowedOriginsの設定がスキップされていた。後から公式ドキュメントを読み直すと、ちゃんと書いてある。最初から公式の手順に従っていれば、この無限ループは回避できたかもしれない。

💡
教訓：AIに聞くのは便利だが、公式ドキュメントは必ず一読すべき。AIは「もっともらしいが微妙に間違った手順」を平気で生成する。特にセキュリティ関連の設定は、公式ドキュメントが最も信頼できる情報源だ。

何が起きているのか。OpenClawのGatewayはセキュリティファーストの設計思想で作られている。ローカルホスト（127.0.0.1）以外のネットワークインターフェースからControl
UIにアクセスする場合、明示的にオリジンを許可しなければ起動すらしない。WSL2環境ではDockerのネットワークがブリッジ接続になるため、コンテナから見るとアクセス元が「ローカルホスト」ではなくなる——これが罠だった。

⚠️ 注意：このエラーが出ている間、コンテナは起動 → エラー →
再起動を無限ループする。docker compose logs -fで確認しないと、一見「動いているように見える」ので見落としやすい。

解決策：CLIからallowedOriginsを設定する

以下のコマンドを実行するだけで突破できる。コピペしてそのまま使える。

docker compose run --rm openclaw-cli config set gateway.controlUi.allowedOrigins '["http://127.0.0.1:18789","http://localhost:18789"]' --strict-json

ポイントは3つ。

  1. --rm フラグ：設定変更用の一時コンテナを立ち上げ、実行後に自動削除する
  2. --strict-json フラグ：JSON形式の値を正しくパースさせるために必須
  3. ポート番号 18789：OpenClawのControl UIのデフォルトポート。変更している場合はそれに合わせる

設定が反映されたら、コンテナを再起動する。

docker compose restart

これでGatewayが正常に起動するようになる。実際にdocker compose psでStatusがUpになっていることを確認しよう。

トークン不一致と「ペアリング」——デバイス認証の壁

「token mismatch」の正体

Gatewayが起動したので、意気揚々とブラウザからControl UI（http://localhost:18789）にアクセスした。ところが、今度はこんなエラーが返ってくる。

Error: token mismatch
Error: pairing required

OpenClawは、コンテナとホストPC間でデバイス認証（ペアリング）を要求する。初回接続時には、接続元のデバイスが信頼できるかどうかをCLIから明示的に承認する必要がある。これもセキュリティ設計の一環だ。

ペアリングの手順

ブラウザからアクセスを試みると、Gateway側にペアリングリクエストが発行される。これをCLIから承認する。

# ペアリングリクエストの一覧を確認
docker compose run --rm openclaw-cli pairing list

# 表示されたリクエストIDを承認（IDは実際に表示されたものに置き換え）
docker compose run --rm openclaw-cli pairing approve <リクエストID>

承認後、ブラウザをリロードすればControl UIにアクセスできるようになる。

💡
ヒント：ペアリングはデバイス単位で行われる。別のPCやスマホからアクセスする場合は、再度ペアリングが必要になる。セキュリティの観点からは正しい挙動だが、初見だと面食らう。

なぜここまで厳しいのか？

「ローカルで動かすだけなのに、なぜこんなに面倒なの？」と思うかもしれない。OpenClawは自律型AIエージェントだ。コマンドの実行、ファイルの読み書き、外部APIへのアクセスなど、強力な権限を持つ。もし悪意のある第三者がControl
UIにアクセスできたら——想像するだけで背筋が凍る。この厳格さは、むしろ評価すべきポイントだ。

Discord連携——「沈黙のBot」を喋らせるまで

Botは動いている、でも反応しない

ここまでクリアして、次はDiscord連携。Discord Developer
Portalで作成したBotをサーバーに招待し、OpenClawの設定にBotトークンを入れて起動。docker compose psでコンテナもUp。Discordのオンラインメンバー一覧にもBotが表示されている。

期待を胸に、チャンネルで @Bot テスト とメンション。

……沈黙。

何度メンションしても、何度リスタートしても、Botは一切反応しない。ログにもエラーは出ていない。まるで無視されているような、あの気まずさ。

原因：デフォルトで全アクセス拒否

これもOpenClawのセキュリティ設計による仕様だった。デフォルトでは、すべてのDiscordサーバー・すべてのユーザーからのアクセスが拒否されている。Botが見えていても、内部的にはメッセージを無視するように設定されている。

必要な設定は2つ。

  1. サーバー（ギルド）の許可：どのDiscordサーバーでBotを動かすかを明示的に指定
  2. ユーザーの許可：どのユーザーからの命令を受け付けるかを明示的に指定

解決策：guildsとallowFromの設定

以下のコマンドで、自分のDiscordサーバーとユーザーを許可リストに登録する。

# サーバー（ギルド）IDの登録（requireMention: trueでメンション時のみ反応）
docker compose run --rm openclaw-cli config set channels.discord.guilds '{"あなたのサーバーID": {"requireMention": true}}' --strict-json

# ユーザーIDの許可（allowFromにユーザーIDを配列で指定）
docker compose run --rm openclaw-cli config set channels.discord.allowFrom '["あなたのユーザーID"]' --strict-json

設定後、コンテナを再起動する。

docker compose restart

📝 サーバーIDとユーザーIDの取得方法：Discordの開発者モード（ユーザー設定 → 詳細設定 →
開発者モード）を有効にすると、サーバーやユーザーを右クリックして「IDをコピー」できるようになる。

「requireMention: true」にすべき理由

設定項目の中に requireMention というオプションがある。これを true
にしておくと、Botにメンションしたときだけ反応するようになる。

false
にするとチャンネル内の全メッセージに反応してしまい、APIコール数が爆発する。OpenClawのバックエンドにはClaude等の有料APIを使うケースが多いため、誤設定で数千円〜数万円の請求が来る可能性もある。正直、これは盲点だった。

環境比較とセキュリティモデルの全体像

ラズパイ vs デスクトップPC：パフォーマンス比較

項目 Raspberry Pi 4 デスクトップPC（WSL2）
CPU Cortex-A72（ARM 4コア） Ryzen / Intel Core（x86 6〜16コア）
RAM 4GB / 8GB 16GB〜64GB
ストレージ microSD（100MB/s前後） NVMe SSD（3,000〜7,000MB/s）
APIタイムアウト 頻発 ほぼゼロ
Dockerビルド時間 10分以上 1〜2分
電気代（月額目安） 約100〜200円 約500〜1,500円
24時間稼働 ◎（省電力） △（PCを常時起動）

数字で見ると一目瞭然。ストレージの速度差だけで30〜70倍。体感としても、ラズパイで3分かかっていたコンテナの再起動が、デスクトップでは10秒で終わる。タイムアウトエラーも移行後は一度も発生していない。

OpenClawのセキュリティレイヤー

ここまでの格闘を振り返ると、OpenClawには3層のセキュリティが設計されていることがわかる。

  1. ネットワーク層：allowedOrigins によるアクセス元の制限
  2. デバイス層：ペアリング（トークン認証）によるデバイスの制限
  3. アプリケーション層：guilds / allowFrom によるサーバー・ユーザー単位の制限

すべてがデフォルトで拒否（Deny by
Default）という設計。面倒だが、自律型AIエージェントを安全に運用するためには理にかなっている。自分のPCでファイルを読み書きし、コマンドを実行できるAIを野放しにするわけにはいかない。

よくある質問（FAQ）

Q1. WSL2のバージョンは関係ありますか？

WSL2であれば基本的に問題ない。ただし、WSL1はDocker Desktopのバックエンドとして使えないため、必ずWSL2を使用すること。確認コマンドは以下の通り。

wsl --list --verbose

VERSIONが「2」になっていればOK。「1」の場合は wsl --set-version <ディストリビューション名> 2 で変換できる。

Q2. OpenClawのアップデートはどうすればいいですか？

基本的にはリポジトリをgit pullしてからdocker compose up -d --buildを実行すれば最新版に更新される。ただし、設定ファイルはDockerボリューム内に永続化されているため、allowedOriginsやDiscordの設定をやり直す必要はない。

git pull origin main
docker compose up -d --build

Q3. 複数のDiscordサーバーで使いたい場合は？

channels.discord.guilds に複数のサーバーIDをJSONオブジェクトとして追加すればよい。

docker compose run --rm openclaw-cli config set channels.discord.guilds '{"サーバーID_1": {"requireMention": true}, "サーバーID_2": {"requireMention": true}}' --strict-json

ただし、サーバーが増えるほどAPI呼び出し量も増える点に注意。コスト管理は慎重に。

Q4. APIのタイムアウトがまだ発生する場合は？

デスクトップPCでもタイムアウトが発生する場合、原因はPC側ではなくAPIプロバイダー側のレートリミットの可能性が高い。使用しているLLMプロバイダー（Anthropic、OpenAIなど）のダッシュボードでリクエスト制限を確認しよう。無料枠やTier
1プランではリクエスト数に厳しい制限がかかっている。

Q5. セキュリティ設定を間違えてロックアウトされた場合は？

Dockerボリュームに保存されている設定をリセットすれば初期状態に戻せる。

# ボリュームの確認
docker volume ls

# 設定ボリュームの削除（コンテナを停止してから実行）
docker compose down
docker volume rm openclaw_config

# 再度セットアップ
docker compose up -d

注意：ボリュームを削除するとすべての設定が消えるため、allowedOrigins、ペアリング、Discord設定をすべてやり直す必要がある。最終手段として使うこと。

まとめ——「高速 × セキュア」な理想のAIエージェント環境

踏んだ地雷を振り返る

ラズパイからの移行、Docker構築、Control UI接続、Discord連携——振り返ると、4つの壁を乗り越えてきた。

  1. ラズパイのスペック不足 → デスクトップPC + WSL2へ移行
  2. allowedOriginsエラー → CLIから明示的にオリジンを許可
  3. token mismatch / pairing required → CLIからデバイスを承認
  4. Discord Botの沈黙 → guilds と allowFrom にIDを登録

どれもエラーメッセージだけでは解決の糸口が見えにくい。しかし、OpenClawの「デフォルトで全拒否」というセキュリティ設計を理解すれば、「何を許可すればいいのか」が自ずと見えてくる。

手に入れた環境

最終的に手に入ったのは、以下のような環境だ。

  • 高速：NVMe SSD + 大容量RAMでAPIタイムアウトとは無縁
  • セキュア：3層のセキュリティレイヤーで不正アクセスを遮断
  • 柔軟：DockerベースなのでOSを汚さず、環境の再構築も容易
  • Discord統合：スマホからメンションするだけでAIエージェントに指示を出せる

自律型AIエージェントは2026年現在、まだ「完璧」にはほど遠い。嘘をつくし、暴走もする。だからこそ、サンドボックスとアクセス制御で「暴走しても被害が限定される」環境を作ることが、運用の第一歩になる。

この記事が、OpenClawの構築で同じエラーに遭遇した誰かの、3時間の節約になれば幸いだ。

コメント

タイトルとURLをコピーしました