OpenClawで詰まる6ポイント：Control UIとVPS

OpenClawを入れてみたはいいけど、「最初の一歩」で止まってしまう人は意外と多いです。インストール自体は進んだのに、dashboard（Control UI）が開かない。127.0.0.1:18789 にアクセスしても反応がない。VPSでdaemon運用にしたら、動いてるのか止まってるのか分からない。エラーは出ているのに、どこを直せばいいのか見当がつかない──そんな状態になりやすいのが、導入直後です。

この手のトラブルは、実は「難しいバグ」よりも「前提のズレ」で起きることがほとんどです。たとえばNode22のバージョンが足りない。Gatewayは動いているのに、Control UI側がトークンを持っていない。初回接続のペアリング承認が終わっていない。VPS側のポートをうっかり外に公開してしまって怖くなる。チャネル別設定を広げすぎて、意図しない入口が増える。こういう“ありがちポイント”が重なると、症状がバラバラに見えて混乱します。

そこでこの記事では、Node22、dashboard（Control UI）、18789、VPS（daemon）、チャネル別設定、doctorの6つに話を絞って、「どこを見れば原因にたどり着けるか」を順番に整理します。焦って全部を触るより、チェックする場所を減らしたほうが、結果的に早く直ります。読み終わるころには、いま詰まっている場所が「直す手順」に変わるはずです。

導入前にここで止まる（Node22と基本環境）

OpenClawを触り始める前に、いちばん先に片づけたいのが「Node22」と「基本環境」です。ここがズレたままだと、あとで出るエラーが全部バラバラに見えてしまい、原因探しが一気に難しくなります。逆に言うと、最初に土台を整えておけば、dashboard（Control UI）やVPS（daemon）までの道がスッと通ります。

このパートでは、Nodeのバージョン確認、npmの導入方法の選び方、PATHや権限（sudo）で止まりやすい場所、そしてプロキシやDNSなどネットワーク要因までをまとめて整理します。「まずはここだけ押さえる」を決めておくと、導入のストレスがかなり減ります。

Node22が必要な理由と確認コマンド

OpenClawの導入でいちばん最初に「地味に効く」のが、Node22（Node.js 22以上）です。ここがズレていると、あとから出るエラーが全部バラバラに見えて、原因が追いづらくなります。

公式の要件として、OpenClawのランタイムは Node ≥22 が前提になっています。だから「とりあえず動けばOK」で古いNodeのまま突っ込むと、オンボーディングやGateway起動のタイミングで詰まりやすいです(GitHub)

確認はこの1行で十分です。

node -v

v22.x.x（またはそれ以上）ならひとまず合格です。v20やv18が出たら、先にNodeを上げた方がトータルで早いです。

もし「Nodeを入れ直すの怖い…」なら、公式のインストールスクリプトを使うのが無難です。Node検出を含めて導入の流れをまとめて面倒見てくれる、という扱いになっています(OpenClaw)

npmで入れる？インストーラで入れる？迷った時の選び方

結論から言うと、迷ったらインストールスクリプトがラクです。導入の「詰まるポイント」をまとめて回避しやすい導線になっています。

一方で、すでにNode運用に慣れていて「グローバルに入れて管理したい」なら、npm（またはpnpm）で入れる方法もアリです。公式のREADMEでも npm install -g openclaw@latest の手順が示されています。

npm install -g openclaw@latest
openclaw onboard --install-daemon

このあとに出てくる openclaw onboard --install-daemon が重要で、ここで認証・Gateway設定・チャネルなどをまとめてセットアップしていきます。

「どれを選んでも最終的に同じでしょ？」と思いがちですが、詰まり方が変わります。スクリプトは最短ルート、npmは自由度が高い代わりに自分で整える場所が増える、というイメージです。

権限（sudo）とPATHでハマる典型例

導入時の“あるある罠”が、権限とPATHです。エラー文だけ見ると難しそうなのに、原因はだいたいこの2つだったりします。

まず、openclaw コマンドが見つからないときは、PATHが通っていないパターンが多いです。npmでグローバルインストールした場合、環境によってはグローバルのbinがPATHに入っていないことがあります。

次に、オンボーディングでデーモン登録（常駐化）を行うと、OS側の仕組みに触ります。Linuxならsystemdのユーザーサービス、macOSならLaunchAgentが関わるので、途中で権限に絡む挙動が出るのは自然です。

特にLinuxでは、ログアウト後も動かすために “linger” を有効化しようとして、sudoが必要になるケースがある、とドキュメントに書かれています。ここで「急にsudo？」となって手が止まりやすいので、そういうものだと思って先に進むとラクです。

プロキシ／DNS／証明書で詰まるパターン

ネットワーク系の詰まりは、症状が派手なのに原因が地味です。たとえば「インストールが途中で止まる」「ダウンロードが失敗する」「認証が通らない」など、いろんな顔をします。

OpenClaw自体は、オンボーディングでモデルやチャネルの設定を行うので、外部サービスに繋がる前提の導入になりがちです。つまり、社内ネットワークやプロキシ環境だと、まず“外に出られるか”がボトルネックになります。

ここでのコツは、いきなりOpenClawを疑わないことです。まずは「その端末（またはVPS）から普通に外部へアクセスできるか」を確認して、DNSや証明書の問題を先に潰します。

そして、Control UI（dashboard）も、Gatewayに繋がらないと画面がそれっぽく見えても動きません。接続の基本が 127.0.0.1:18789 である点を覚えておくと、切り分けが速くなります。

「まずは隔離」：ローカル実行とVM/VPSの判断軸

ここは少しだけ真面目な話です。OpenClawは便利なぶん、動かす場所の選び方が大事です。

Microsoftのセキュリティチームは、OpenClawのようなランタイムを “永続的な資格情報を持つ、信頼できないコード実行” として扱うべき、そして通常の個人端末や社内端末での運用は避け、隔離環境（専用VMなど）で評価すべき、という趣旨の注意喚起を出しています。(Microsoft)

OpenClaw公式のセキュリティガイドでも、信頼境界を分けたいならゲートウェイを分ける（またはOSユーザー/ホストを分ける）という考え方が示されています。

なので判断軸はこうです。

普段使いのPCに入れるより、まずはVMやVPSに入れて「捨てても痛くない環境」で動作確認するほうが安心です。

設定より前に止まる人が多いのは「実行環境」。ここが整うと、手順が一気に素直になる。

まずは“動く土台”から。ConoHa VPSの公式ページを見てみる。👉　【1.3円/時間】GMOインターネットの「ConoHa VPS」

Dashboard（Control UI）を起動して動作確認

OpenClawの導入がひと通り終わったら、次にやるべきはDashboard（Control UI）を開いて「本当に動いているか」を目で見て確かめることです。ここが開けるだけで安心感が一気に増えますし、逆にここで詰まると「何が悪いのか分からない」状態に入りやすいです。だからこのパートは、できるだけ最短で“正常ルート”に乗せるための確認手順をまとめます。

ポイントは、Control UIだけを疑わないことです。多くの場合、原因は 127.0.0.1:18789 の接続、Gatewayの稼働状況、トークン認証、初回ペアリングのどれかにあります。順番にチェックすれば、無駄に回り道をせずに「開く」「入れる」「操作できる」まで到達できます。

openclaw dashboard で最短スタート

導入が済んだら、次に詰まりがちなのがdashboard（Control UI）です。ここが開くと「動いた！」感が一気に出ます。

基本はこのコマンドです。

openclaw dashboard

公式ドキュメントでも、オンボーディング後にいつでも再オープンできる手段として案内されています。

そして重要なのは、Control UIは「単なる画面」ではなく、Gatewayに接続して初めて意味があるという点です。画面が出たのに操作できない場合、たいてい接続や認証のどこかで止まっています。

“最短スタート”のコツは、先に openclaw gateway status でGatewayが生きているかを見ることです。UIを疑う前に、土台を確認する感じです。

127.0.0.1:18789 に届かない時のチェック

OpenClawのControl UIは、基本的にローカルの 127.0.0.1:18789 で開く前提です。ここが “入口” になります。

届かないときのチェックは、順番が命です。

まず、Gatewayが起動しているか。

openclaw gateway status

次に、ログで何か言っていないか。

openclaw logs --follow

そして、ポートを自分で指定して起動しているなら、そのポートが 18789 かどうかを再確認します。Gatewayのランブックでは --port 18789 が例として書かれています。

openclaw gateway --port 18789 --verbose

ここまでやってもブラウザが「接続できません」のままなら、URLを打ち間違えているか、別プロセスが握っているか、またはGateway自体が落ちている可能性が高いです。まずは“Gatewayが動いているか”に戻るのが最短です。

URL末尾のトークンの意味と安全な扱い

Control UIでよく見るエラーが unauthorized です。これは「トークンがない」「トークンが違う」「ペアリングが必要」など、認証側の問題で起きます。

公式のdashboardページでは、UIが認証を求めたら gateway.auth.token（または OPENCLAW_GATEWAY_TOKEN）のトークンをControl UIの設定に貼る、という流れが説明されています。

つまり、URLにトークンが付く・付かないは“挙動の差”であって、本質は「Control UIがGatewayトークンを持てているか」です。GitHubのIssueでも、トークンがURLに含まれず認証で落ちる例が報告されています。

安全面のポイントはシンプルです。

✅ トークンは“鍵”なので、スクショ共有や貼り付け共有は避ける

✅ どうしても画面共有するなら、先にトークンが見える部分を隠す

✅ UIが保存したトークンはブラウザ側（localStorage）に残るので、共有PCならログアウトやプロファイル分離を意識する

VPSから開く：SSHポートフォワードの基本

VPS（daemon運用）で一番おすすめの開き方は、SSHトンネルです。理由は簡単で、GatewayやControl UIを不用意に外へ晒さずに済むからです。

基本形はこれです。

ssh -N -L 18789:127.0.0.1:18789 user@your-vps

この形は公式のdashboardページでもヒントとして示されていて、ローカルの 127.0.0.1:18789 にアクセスすると、裏側でVPSの18789へ繋がります。

ここでの“感覚”は、「VPSの画面をローカルに引っ張ってくる」ではなく、「ローカルに偽の入口を作って、そこからVPSへ専用線で繋ぐ」です。

Control UIは強い権限を持つ管理画面なので、公開サーバのノリで 0.0.0.0 にバインドして公開するのは避けるべきだ、という注意も複数のガイドで繰り返されています。

ブラウザが真っ白／入れない時の切り分け

画面が真っ白、あるいは入れたけどすぐ切れる。ここでの切り分けは、原因を3つに分けると楽です。

1つ目は「Gatewayに届いていない」。つまりポートやトンネルの問題です。まず openclaw gateway status で稼働確認し、トンネルなら -L 18789:127.0.0.1:18789 が合っているか見直します。

2つ目は「認証（トークン）がない」。この場合はUIにトークンを貼るか、openclaw config get gateway.auth.token で取得して貼ります。必要ならdoctorでトークン生成もできます。

3つ目は「ペアリングが必要」。このときはUI側に pairing required と出ることがあります。初回接続のブラウザ/端末は承認が必要で、openclaw devices list で保留を見て、openclaw devices approve <requestId> で承認します。

この3分割で見ると、「真っ白」も「切れる」も、だいたい落ち着いて直せます。

UIが開かないときは、原因を当てにいかない。VPS＋SSHトンネルで再現性を取るのが堅い。

VPSで再現性を作るなら、ConoHa VPS公式で構成をチェック。👉

★☆★　VPSで色々なことを試したいなら【ConoHa】がお薦め！　★☆★

【ConoHa】は、開発やテスト環境に最適！サーバーの運用に必要な機能がすべて揃っています。

VPS（daemon）運用で起きがちな落とし穴

OpenClawをVPSでdaemon運用にすると、「毎回起動しなくていい」「どこからでも使える」という便利さが手に入ります。その一方で、ローカル実行では起きなかった落とし穴が一気に増えます。たとえば、起動しているはずなのに反応しない。再起動したら勝手に止まっていた。ログの場所が分からず、原因が見えない。Control UIを外に出しそうになって怖くなる。こういう“運用あるある”は、最初に知っておくだけで回避しやすくなります。

このパートでは、--install-daemon が何をしているのか、自動起動の仕組みのどこで詰まりやすいのか、そして「公開してはいけないもの」をどう守るかまでを、手順ベースで整理します。VPS運用は、設定を増やすほど強くなる反面、ミスも起きやすいです。だからこそ、最小構成で安全に回すための考え方を先に固めていきましょう。

--install-daemon がやっていること（自動起動の仕組み）

VPSで「常に動くOpenClaw」にしたいなら、導入で必ず出てくるのが --install-daemon です。

openclaw onboard --install-daemon

公式ドキュメントでは、オンボーディングの一環としてこのフラグを使い、Gatewayをバックグラウンドで動かす流れが紹介されています。

仕組みとしては、OSのサービス機構に登録します。

macOSはLaunchAgent、Linux（WSL2含む）はsystemdのユーザーサービス、という形が明記されています。

ここでの“落とし穴”は、常駐化すると「ターミナルを閉じても動く」反面、「どこで動いてるのか分からなくなる」ことです。

だから、覚えておくと救われるのが openclaw daemon 系のコマンドです。サービスの状態確認や起動停止をまとめて扱えます。

起動しているのに反応しない：ログの見方

「gateway statusはrunningなのに、Control UIが繋がらない」。このパターン、体感かなり多いです。

まず、公式ランブックにある“健康状態の基準”を使います。Runtime: running と RPC probe: ok が目安、とされています。

openclaw gateway status
openclaw status

次にログです。ログは「何が起きたか」の答えがほぼ書いてあります。

openclaw logs --follow

ログでよく見るキーワードは unauthorized と pairing required です。前者はトークン、後者は端末承認。Control UI側のエラーに見えて、実はGatewayの認証が原因、ということがよくあります。

最後に、チャネル周りが原因で詰まることもあります。そういう時は openclaw channels status --probe が便利です。Gatewayが動いているだけでなく、チャネルが“使える状態か”まで確認できます。

更新で壊れやすいポイント（設定・依存関係）

アップデート後に「昨日まで動いてたのに…」となるのは、OpenClawあるあるです。理由は、GatewayとControl UI、チャネル接続、モデル設定など、動いている要素が多いからです。

特に壊れやすいのは、認証まわり（トークン）と、サービス設定（常駐設定）です。dashboardのドキュメントでも、トークンが必要になったときの取得や再生成の手順が用意されています。

そして「おかしくなったらdoctor」が公式に用意されています。doctorは修復や移行のためのコマンドで、推奨修正を自動適用する --repair などが説明されています。

アップデート後の不調で大事なのは、闇雲に消して入れ直す前に、まずdoctorで“ズレ”を直すことです。

それでも直らないときに、gateway install --force のような強い手段がある、とドキュメントに書かれています。いきなり強制上書きするとカスタムが消える可能性があるので、段階を踏むのが安全です。

公開してはいけないもの／公開していいもの

ここははっきり言います。

🚫 Control UI（dashboard）とGatewayのポートを、そのままインターネットに公開するのはおすすめしません。

公式のGitHubセキュリティポリシーにも「公開インターネットに露出させない（0.0.0.0 への直バインドや公開リバプロは避ける）」という趣旨が書かれています。

OpenClaw公式のセキュリティページも、信頼境界を分けるならゲートウェイを分けるなど、運用モデルとして“隔離”を強く意識した書き方です。

✅ 公開していい（現実的）なのは、「SSHで自分だけが入れる」「Tailscaleなどの閉じたネットワークだけでアクセスできる」状態です。

VPSで運用するなら、原則は「外に見せない」「必要なときだけトンネルで覗く」でいくのが安全で、詰まりも減ります。

事故を防ぐ権限設計（専用ユーザー・鍵・トークン）

VPS運用の“詰まるポイント”は、技術より運用で起きます。たとえば「トークンをどこかに貼ってしまった」「管理画面を誤って公開した」「同じ環境に個人アカウントが混ざった」などです。

Microsoftのブログでも、OpenClawのようなものは“そのマシンと、そのアイデンティティ（資格情報）の信頼を丸ごと継承する”という考え方が強調されています。つまり、混ぜると危ないです。

OpenClaw公式のセキュリティガイドも、「同じエージェントに複数人が触れると、同じ権限セットをみんなで押せる状態になる」というリスクをはっきり書いています。

なので設計はシンプルに。

専用のOSユーザーで動かす

必要最小限の鍵・トークンだけ置く

普段の個人ブラウザやパスワード管理と混ぜない

Control UIはトンネルや閉域でしか開かない

この4つを守るだけで、“致命的な事故”の確率がグッと下がります。

「起動してるはず」が一番危ない。ログが追える場所に置くと、切り分けが速い。

ログ前提で運用するなら、ConoHa VPSを公式で確認。👉　【1.3円/時間】GMOインターネットの「ConoHa VPS」

チャネル別設定で「用途ごとに使い分け」

OpenClawの強みは、DiscordやTelegramなど複数のチャネルから使えることです。だからこそ、導入直後にやりがちなのが「とりあえず全部つなぐ」です。気持ちは分かるのですが、ここで一気に入口を増やすと、権限や承認フローが混ざってしまい、反応しない原因が見えなくなったり、意図しない人が触れる状態になったりしやすいです。チャネル設定は、便利さと安全のバランスを取る場所だと思うと、迷いが減ります。

このパートでは、まず“全体像を見える化”して、次に「用途ごとに入口を分ける」考え方を紹介します。チーム共有、個人用、通知用など、役割を分けるだけで運用が安定しますし、トラブルが起きても切り分けが簡単になります。最初は最小の1チャネルから始めて、動作が確認できたら段階的に増やす。この順番が、結局いちばん早いです。

Chat Channelsの全体像（Discord/Telegram/WhatsAppなど）

OpenClawは「好きなチャットアプリから使える」のが売りです。公式ドキュメントでも、WhatsAppやTelegram、Discordなど多チャネル対応が前提になっています。

ただ、導入直後にやりがちなのが「全部つなぐ」ことです。気持ちは分かるんですが、詰まりやすくなります。

おすすめは、最初は Control UI（dashboard）で動作確認 → 1チャネルだけ接続 → 安定したら増やす です。

チャネル周りの状態確認には、openclaw channels が中心になります。一覧やステータス、機能確認（capabilities）などが揃っていて、切り分けがしやすいです。

openclaw channels list
openclaw channels status
openclaw channels capabilities

“全体像が見える”だけで、焦りが減って詰まりも減ります。

最初に詰まる：Bot権限・トークン・ペアリング

チャネル接続で詰まる理由は、だいたいこの3つです。

トークンが違う／入れ忘れた

ペアリングが必要なのに承認していない

チャネル側（Discord等）の権限や設定が足りない

OpenClawの公式チャネルガイドでは、たとえばTelegramやWhatsAppは ペアリングの承認フロー が出てくることが説明されています。

openclaw pairing list telegram
openclaw pairing approve telegram <CODE>

openclaw pairing list whatsapp
openclaw pairing approve whatsapp <CODE>

また、openclaw channels add は、トークンなどをフラグで渡す方法も、対話形式で進める方法も案内されています。ここで「どこに何を入れるんだっけ？」が整理されます。

詰まりやすい人ほど、最初は“対話形式”で進めた方が早いです。

チャネルごとに設定を分ける設計パターン

「チャネル別設定」という言葉を聞くと難しそうですが、考え方はめちゃくちゃ単純です。

用途が違うなら、入口（チャネル）も分ける。

たとえば、

Discord：チーム用（共有・議論）

Telegram：自分用（個人のメモや指示）

WhatsApp：通知用（短文・緊急）

みたいに役割を分けると、運用が安定します。

OpenClawのセキュリティモデルでも、同じエージェントに複数人が触れると、同じ権限で操作できる、というリスクが説明されています。だから共有するチャネルほど、権限を絞ったり、別ゲートウェイに分けたりが効きます。

また、公式ガイドでも「敵対的な利用者の分離が必要なら、信頼境界ごとにゲートウェイを分ける」という発想が提示されています。

“設定を分ける”は、便利さよりも安全と運用のため、と思うと腹落ちします。

DMポリシー／承認フローのポイント

チャネルで事故が起きる瞬間って、だいたいDM（個別メッセージ）です。

「知らない人が話しかけた」

「グループに入れたら全員が触れた」

「うっかり権限を広げた」

こういうのが起きます。

OpenClaw公式のセキュリティガイドは、共有Slackの例などで“誰でも触れるボット”が持つリスクをかなり具体的に書いています。言い換えると、入口を絞るだけで事故が減ります。

また、Control UI自体も“端末の初回接続はペアリング承認が必要”という仕組みになっています。これも同じ発想で、入口を一段絞っているわけです。

DMを開くなら、

最初は自分だけ許可

慣れてから少人数

チーム利用は別環境（別ゲートウェイ）も検討

この順番が現実的です。

“勝手に動く”を止める運用ルール（公開範囲）

OpenClawを触っていると、便利さの勢いで「どこでも使えるようにしたい！」となります。

でも、運用ルールを決めずに公開範囲だけ広げると、“勝手に動く”が起きます。正確には「誰かが動かせる」状態です。

Microsoftのブログは、スキル導入が“特権コードの導入”に近い、という考え方でリスクを整理しています。つまり、範囲が広いほど想定外が起きやすいです。(Microsoft)

OpenClaw公式のGitHubセキュリティポリシーも、公開インターネットへの露出を避け、必要ならSSHトンネル等を使う方向を推しています。

だからルールはこうです。

Control UIは公開しない（トンネルか閉域）

チャネルは最小から始める（いきなり全社はしない）

共有チャネルは権限を絞る（または環境を分ける）

この3つを決めるだけで、「怖さ」が「道具」に変わります。

世界に晒すのは事故の入口。外に出すなら“鍵と境界”を先に設計する。

安全側に倒すなら、ConoHa VPS公式で運用イメージを掴む。👉　★☆★　VPSで色々なことを試したいなら【ConoHa】がお薦め！　★☆★

【ConoHa】は、開発やテスト環境に最適！サーバーの運用に必要な機能がすべて揃っています。

doctorで原因特定を最短にする

OpenClawの導入や運用で詰まったとき、いちばんつらいのは「何が原因か分からない」状態です。エラーが出ているのに、Nodeなのか、ネットワークなのか、権限なのか、トークンなのか、チャネルなのか……候補が多すぎて手が止まります。そんなときに最短ルートになりやすいのが、診断用コマンドの doctor です。闇雲に入れ直す前に、まず“体調チェック”をして、ズレている場所を絞り込みます。

このパートでは、openclaw doctor が何を見てくれるのか、修復オプション（--repair など）をどんな順番で使うと安全か、そしてControl UIや18789、トークン周りのトラブルをどう切り分けるかを整理します。困ったらdoctor、でも強い修復は慎重に。このルールさえ守れば、詰まりポイントの多くは短時間でほどけます。

openclaw doctor で何を診断する？

導入やアップデートで詰まったとき、最後に頼るのが openclaw doctor です。名前の通り、“診断して、直せるところは直す”方向のコマンドです。

openclaw doctor

公式ドキュメントでは、doctorが修復や移行（アップグレード後のズレなど）を扱うこと、そして修復時にプロンプトで確認することが説明されています。

doctorが便利なのは、エラーの原因を“人間が探し回る”前に、まず機械的に矛盾を洗い出せるところです。

たとえば「トークンがない」「Dockerが必要なのに無い」「設定がズレている」など、手作業だと見落とすポイントをまとめて拾ってくれます。

詰まりポイントが多いOpenClawだからこそ、doctorは“最短の近道”になりやすいです。

--repair は便利だけど注意すべき点

doctorには自動修復系のオプションがあります。代表が --repair です。

openclaw doctor --repair

公式の説明では、--repair は推奨修正をプロンプト無しで適用し、さらに --repair --force はカスタムした supervisor 設定を上書きする、とあります。

ここが注意点です。

便利だからといって、いきなり --force を叩くと、自分が手で調整した設定が戻る可能性があります。

おすすめの順番はこうです。

まず openclaw doctor（確認しながら）

次に openclaw doctor --yes（デフォルト修正を受け入れる）

それでもダメなら --repair

最後に --force（覚悟して上書き）

この段階を踏むだけで、「直ったけど別の場所が壊れた」が減ります。

Node／ネットワーク／権限：よくあるNG例まとめ

doctorを使う前でも使った後でも、結局よくあるNG例は似ています。

そこで“導入で詰まるポイント”を、原因別にまとめます。

表にすると「やること」が減ります。

詰まりって、情報が多すぎて固まることが多いので、こうやって選択肢を減らすのがコツです。

Control UIのトラブル切り分け（ポート・トークン）

Control UI（dashboard）の不調は、ほぼ「ポート」か「トークン」か「ペアリング」です。逆に言うと、この3点を見れば大体片付きます。

ポートは 18789 が基本です。Gatewayがloopbackにバインドされる前提や、WebSocketが ws://127.0.0.1:18789 という前提がドキュメントで説明されています。

トークンは gateway.auth.token（または OPENCLAW_GATEWAY_TOKEN）が基本です。UIが認証を求めたら、Control UIの設定に貼る流れが明記されています。

そしてペアリング。新しいブラウザ/端末から繋ぐときに、Gateway側で承認が必要です。ここを飛ばすと “なんか繋がらない” の正体になります。

詰まったら、3つのどれかに戻る。

このループが、一番速いです。

最後に必須：セキュリティのチェックリスト

doctorで直せるのは“壊れ”です。でも、事故は“設計”と“運用”で起きます。

最後に、VPS（daemon）運用をするなら最低限これだけはチェックしておくと安心です。

✅ Gatewayは基本loopback（外に直公開しない）

✅ Control UIはSSHトンネルか閉域（Tailscale等）で開く

✅ トークンを共有しない（画面共有でも注意）

✅ 共有チャネルは権限を絞る、または環境を分ける

✅ “隔離環境で動かす”という前提を忘れない(Microsoft)

この5つが守れると、OpenClawは「怖いもの」から「強い道具」に変わります。

詰まりの正体は、手順じゃなく環境の混線。検証場所を分けるだけで、問題は小さくなる。

検証用の土台が欲しいなら、ConoHa VPS公式へ。👉　【1.3円/時間】GMOインターネットの「ConoHa VPS」

まとめ

OpenClawの導入で詰まるポイントは、派手なバグよりも「前提のズレ」で起きることが多いです。

Node22の不足、Control UI（dashboard）への接続（18789）、トークン認証と端末ペアリング、VPSでのdaemon常駐化、そしてチャネル別設定の公開範囲。

このあたりを順番に整えると、急にスムーズになります。

そして困ったら openclaw doctor。壊れを直す道具が公式で用意されているのは、素直に頼ってOKです。

もしここまでの内容で「まずは隔離できる環境で試したい」「VPS運用も視野に入れたい」と感じたら、次に読む記事として 初期費用0円の高性能サーバー、本当に良い？ConoHa WINGを検証してみた もあわせてチェックしてみてください。OpenClawを動かす土台づくりのイメージが、より具体的になります。