この記事の位置づけ
日本語圏の OpenClaw 情報を検索すると、ほぼ全てが「OpenClaw とは何か？」という紹介記事です。概要、ユースケース、海外事例の翻訳紹介。それ自体は間違っていません。
しかし、実際に自分のサーバーで動かそうとした瞬間に必要になる情報は、そのどこにも書いていません。
この記事は、OpenClaw を LAN 上のクロスホスト構成で動かし、Discord Bot と連携させた実体験に基づく運用メモです。紹介記事を読んで「よし、動かしてみよう」と思った人が次に読むべきものとして書いています。
紹介記事と実態のギャップ
紹介記事が伝えていること
- OpenClaw はオープンソースの AI エージェントプラットフォームである
- Gateway 経由で複数のエージェントにアクセスできる
- Discord / Telegram / Slack などと連携できる
- CLI（TUI）で対話できる
これは正しいです。
紹介記事が伝えていないこと
| 現実の問題 | 紹介記事に載っているか |
|---|---|
Gateway はデフォルトで 127.0.0.1 にしか bind しない | ❌ |
| 別マシンから繋ぐには bind 設定の変更と firewall の開放が必要 | ❌ |
| リモート接続にはトークン認証が必要 | ❌ |
| 新しいデバイスは「ペアリング承認」されないと接続できない | ❌ |
| ペアリング承認のタイミングを間違えると詰む | ❌ |
custom bind にすると同一マシンの TUI が壊れる | ❌ |
| Discord 連携は「Discordで承認」ではなくサーバー側の CLI 操作 | ❌ |
これらは全てバグではなく仕様です。しかし、ドキュメントの網羅性が追いついておらず、自力で解決するしかない状況になります。
なぜこの情報が必要なのか
OpenClaw を「同一マシン上でデフォルト設定のまま」使うなら、上記の問題にはほぼ遭遇しません。openclaw tui を起動するだけで動きます。
問題が顕在化するのは、以下のようなケースです。
- GPU マシンと Bot マシンを分けたい
- LAN 上の別ホストから接続したい
- Discord Bot を独立したプロセスとして動かしたい
- 自動起動の systemd ユニットで運用したい
つまり、本番運用しようとした瞬間に全部踏む罠です。
実構成の全体像
このリポジトリで実際に動かしている構成はこれです。
Host A (Linux) Host B (Linux)
┌──────────────────────┐ ┌──────────────────────────┐
│ python src/main.py │── WebSocket ──>│ OpenClaw Gateway │
│ (Discord Bot) │ LAN │ ws://192.168.0.108:18789│
│ 192.168.0.15 │ │ ↓ │
└──────────────────────┘ │ Agent: main │
↑ └──────────────────────────┘
Discord API
↑
ユーザー (Discord)
