OpenClawダッシュボードのtokenとは？認証と使い方

OpenClawのダッシュボードは、基本的に http://127.0.0.1:18789/ から開くControl UIですが、認証まわりでtokenが絡むと少し分かりにくいです。特にopenclaw dashboardを実行してもtoken付きURLが出ない、unauthorizedや1008が表示される、どこにtokenを入れるのか迷う、という流れでつまずきやすいかなと思います。

tokenは、ダッシュボードやWebSocket接続を守るための共有シークレットとして扱われます。ただし、SecretRef管理や環境変数の使い方によっては、CLIがあえてtoken値をログやURLに出さない設計になっています。焦りますよね。ここでは、公式ドキュメントで確認できる範囲をもとに、tokenの役割、確認方法、リモート接続時の注意点を整理します。

OpenClawダッシュボードtokenとは

OpenClawダッシュボードのtokenは、ざっくり言うとControl UIへ安全に接続するための認証情報です。ダッシュボード自体はブラウザーで開く管理画面ですが、そこにはチャット、設定、実行承認など、操作権限の強い機能がまとまっています。

そのため、単にURLを知っていれば誰でも入れる画面として扱うのは危険です。特にリモート環境や別端末から開く場合は、token、パスワード、Tailscale、SSHトンネルなどの認証・接続方法を分けて理解しておくと迷いにくいですよ。

Control UIの役割

Control UIは、OpenClaw Gatewayが提供するブラウザー上の管理画面です。公式情報では、標準では / に提供されるブラウザーのコントロールUIとして説明されています。つまり、OpenClawの動作状況や接続先、設定まわりを確認する入口ですね。

ここで大事なのは、Control UIがただの閲覧画面ではないことです。チャット、設定変更、実行承認などに関わるため、管理者向けの操作画面として扱う必要があります。外部にそのまま公開するものではなく、基本はローカル環境、Tailscale、SSHトンネルなどを使って限定的に開く考え方です。

OpenClawを仕事やAI活用の検証で使う人にとっては、Control UIは「いまGatewayがどう動いているか」「認証が通っているか」「どの接続方法を使っているか」を見る場所になります。エラーが出たときも、いきなり設定ファイルを触る前に、まず入口の状態を整理するのが現実的です。

Control UIで確認したい主な領域

Control UIは便利ですが、便利な分だけ扱いも慎重にしたいところです。あなたが個人で試す場合でも、会社やチームの環境で使う場合でも、公開範囲を広げる前に認証の仕組みを確認するのが基本になります。

デフォルトURLとポート

OpenClawダッシュボードのローカルGatewayは、標準では http://127.0.0.1:18789/ で開く形です。http://localhost:18789/ でも案内されています。ここで出てくる 18789 が、OpenClaw Gatewayのデフォルトポートとして扱われています。

127.0.0.1 や localhost は、自分のPC自身を指すアドレスです。つまり、最初の使い方としては「自分のPC上でGatewayを動かし、自分のブラウザーで開く」という前提になります。ここが分かると、リモートサーバーで動かしたときにそのまま手元のブラウザーで開けない理由も見えてきます。

TLSが有効な場合は、URLの扱いも変わります。gateway.tls.enabled: true の設定では、ダッシュボードやステータスリンクは https://、WebSocketの接続は wss:// を使う形になります。HTTPとHTTPS、WSとWSSの違いで詰まることもあるので、設定とURLの組み合わせはセットで確認したいところです。

URLと接続方式の目安

なお、ダッシュボードの提供パスは gateway.controlUi.basePath で変更できるとされています。標準の / から変えている環境では、URLだけを見て判断せず、設定値も確認してください。正確な情報は公式サイトをご確認ください。

tokenの使い道

OpenClawダッシュボードでいうtokenは、主にGatewayへ接続するための共有シークレットとして使われます。AIモデルの入力・出力で消費する「使用量のトークン」とは別物です。ここを混ぜるとかなり分かりにくくなるので、まず分けて考えるのがおすすめです。

認証tokenは、Control UIがGatewayへWebSocket接続するときの認証に関わります。公式情報では、WebSocketハンドシェイク時に connect.params.auth.token や connect.params.auth.password などを通じて認証が行われる説明になっています。つまり、ブラウザー画面が開いても、認証が通らなければ中身の操作には進めません。

openclaw dashboard コマンドは、可能であればダッシュボードを開いたり、リンクをコピーしたりします。ただし、token値をいつでもURLやログに表示するわけではありません。むしろ、tokenを不用意に出さない設計が入っているため、「tokenがURLにない＝必ず異常」とは言い切れません。

tokenの種類を分けて理解

公式ドキュメントでは、tokenはURLフラグメントのキー token として一度だけ渡せる場合があり、Control UIは読み込み後にURLから取り除く流れが説明されています。また、保存先もlocalStorageではなく、現在のブラウザータブセッションと選択されたGateway URLに対するsessionStorageです。ここは安全面でかなり大事なポイントです。

認証方式の基本

OpenClawダッシュボードの認証は、ひとつの方法だけではありません。共有シークレットtoken、共有シークレットパスワード、Tailscale ServeのIDヘッダー、trusted-proxyのIDヘッダーなど、設定に応じて使われるルートが変わります。

ローカルで試すだけなら、まず http://127.0.0.1:18789/ を開く流れが基本です。ただし、UIが共有シークレット認証を求める場合は、設定済みのtokenまたはパスワードをControl UI設定へ入力する必要があります。ここで入力する情報は、ログやスクリーンショットに残さないようにしたいですね。

Tailscale Serveを使う場合は、gateway.auth.allowTailscale: true の設定により、IDヘッダーでControl UIやWebSocket認証を満たせる場合があります。また、gateway.auth.mode: "trusted-proxy" の場合は、信頼済みプロキシのIDヘッダーを使う構成もあります。これは少し上級寄りなので、個人検証ならまずローカルかSSHトンネルから入るのが分かりやすいです。

認証方式の比較

HTTP APIについては、ダッシュボードとは別に共有シークレット認証が関わる場合があります。private-ingressで意図的に gateway.auth.mode: "none" を使う、またはtrusted-proxy HTTP認証を使うような構成は、公開範囲や運用ルールをきちんと決めてから扱うべきです。会社環境や本番に近い環境では、最終的な判断は専門家にご相談ください。

SecretRef管理の注意点

SecretRef管理のtokenは、OpenClawダッシュボードまわりで特につまずきやすい部分です。ポイントは、SecretRefで管理されたtokenは、CLIがあえてtoken付きURLとして表示・コピー・起動しない場合があることです。

これは不便に見えるかもしれませんが、理由ははっきりしています。外部管理されているtokenが、シェルログ、クリップボード履歴、ブラウザー起動引数などに残るのを避けるためです。認証情報を扱ううえでは、むしろ自然な安全設計だと考えると納得しやすいかなと思います。

gateway.auth.token がSecretRefとして設定されていて、現在のシェルで解決できない場合でも、openclaw dashboard は無効なtokenプレースホルダーをURLに埋め込むのではなく、tokenなしのURLと認証設定の案内を出す流れになります。つまり、URLにtokenがないからといって、すぐ設定ミスと決めつけないことが大切です。

️ SecretRef管理時の見方

✅ SecretRefまわりで先に見るポイント

• gateway.auth.token が通常値かSecretRefか
• 現在のシェルで OPENCLAW_GATEWAY_TOKEN が解決できるか
• Control UIがtoken入力を求めているか
• URLにtokenが出ない挙動が仕様なのか
• ログや共有画面にtoken値が残っていないか

SecretRefは、認証情報を安全に扱うための仕組みです。面倒に感じる場面もありますが、ダッシュボードが管理者画面であることを考えると、tokenを見せない・残さない設計は重要です。設定値やCLIの挙動はバージョンで変わる可能性もあるため、正確な情報は公式サイトをご確認ください。

OpenClawダッシュボードtokenの使い方

OpenClawダッシュボードtokenを使う場面は、大きく分けると「ダッシュボードを開く」「認証エラーを直す」「リモート環境から安全に接続する」の3つです。tokenそのものを探す前に、どの接続方法で開こうとしているのかを整理すると、かなり迷いにくくなります。

ここでは、openclaw dashboard コマンドの基本、tokenがURLに出ない理由、unauthorized や 1008 が出たときの確認順をまとめます。OpenClawはバージョンや設定で挙動が変わる可能性があるため、実際の設定変更前には正確な情報は公式サイトをご確認ください。

dashboardコマンド

openclaw dashboard は、現在の認証設定を使ってControl UIを開くためのコマンドです。ローカル環境では、基本的に http://127.0.0.1:18789/ または http://localhost:18789/ に接続する流れになります。まずはこのコマンドが、ブラウザーを開くための入口だと考えると分かりやすいです。

CLIは、可能であればリンクをコピーし、ブラウザーを開きます。ヘッドレス環境のようにブラウザーを開けない場合は、手動で開くための案内やSSHのヒントが出る形です。つまり、ブラウザーが自動で立ち上がらなくても、それだけで失敗とは限りません。

--no-open を付けると、ブラウザーを開かずにダッシュボードURLの確認をしやすくなります。リモートサーバーや検証環境では、勝手にブラウザーを起動させず、URLや認証案内だけ見たい場面もありますよね。その場合に使いやすいオプションです。

️ dashboardコマンドの基本

ただし、token値はログに出ないよう配慮される場合があります。特にSecretRef管理のtokenは、ターミナル出力やクリップボード履歴に残さないため、token付きURLとして表示されないことがあります。ここは「不親切」ではなく、認証情報を守るための挙動として見た方がいいです。

tokenが出ない理由

openclaw dashboard を実行しても、URLにtokenが付いていないことがあります。ここで慌てがちですが、OpenClawではtokenを出さないこと自体が仕様として説明されているケースがあります。特にSecretRefで管理されたtokenは、外部シークレットを不用意に露出しないため、あえて非トークン化URLを表示・コピー・起動する設計です。

また、CLIがクリップボードやブラウザーへの配信に失敗した場合でも、token値そのものをログには出さず、OPENCLAW_GATEWAY_TOKEN や gateway.auth.token、URLフラグメントキー token を使う案内にとどめる形が説明されています。認証情報がシェルログに残ると、あとから見られてしまう可能性があるためです。

古いメモや個人記事では、?token= のようなURL例を見かけることがあります。ただ、公式情報では、URLフラグメントキー token として扱う説明が中心です。どの形式が使えるかはバージョンや設定に依存する可能性があるので、手元のOpenClawの表示と公式ドキュメントを優先してください。

tokenがURLに出ない主なパターン

✅ まず確認したいこと

• gateway.auth.token がSecretRef管理か
• 現在のシェルで OPENCLAW_GATEWAY_TOKEN が読めるか
• Control UI側にtoken入力欄が出ているか
• Gatewayがそもそも起動しているか
• URLだけでなくWebSocket認証まで通っているか

tokenが出ないと「設定ミスかも」と感じますが、OpenClawの場合は安全設計の可能性があります。大事なのは、URLにtokenが見えるかどうかだけで判断せず、Gatewayの起動状態、認証方式、SecretRefの解決状態を順番に見ることです。

unauthorized対処

ダッシュボードで unauthorized や 1008 が出る場合は、WebSocket接続時の認証で止まっている可能性があります。ブラウザーで画面が開いても、Gatewayとの接続認証が通らなければ操作には進めません。まずは「画面が開くこと」と「認証が通ること」を分けて考えるのがコツです。

最初に確認したいのは、Gatewayへ到達できているかです。ローカルなら openclaw status を実行し、Gatewayの状態を見ます。リモートなら、SSHトンネルなどで 127.0.0.1:18789 に転送できているかを確認します。接続先が間違っている状態でtokenだけ探しても、なかなか解決しません。

AUTH_TOKEN_MISMATCH の場合は、Gateway側の共有tokenと、クライアント側が使っているtokenがずれている可能性があります。公式情報では、Gatewayが再試行ヒントを返す場合に、キャッシュ済みデバイスtokenで1回だけ信頼済み再試行を行う流れも説明されています。ただし、それでも失敗するなら手動でtokenのずれを直す必要があります。

AUTH_SCOPE_MISMATCH の場合は、デバイスtoken自体は認識されているものの、ダッシュボードが求めるスコープを持っていない状態です。この場合、共有Gateway tokenをむやみにローテーションするより、再ペアリングや要求されたスコープ承認を確認する方が筋が良いです。

unauthorized時の確認順

復旧時に見るコマンド

• openclaw status
• openclaw config get gateway.auth.token
• openclaw doctor --generate-gateway-token
• openclaw dashboard --no-open

共有シークレットがない場合は、openclaw doctor --generate-gateway-token でGateway tokenを生成する案内があります。すでにtokenやpasswordが設定されているなら、Control UIの認証欄に正しい値を入力して再接続します。認証情報は強い権限につながるため、共有範囲や保存場所には十分注意してください。

SSHトンネルで開く

リモートサーバー上でOpenClaw Gatewayを動かしている場合、いきなりGatewayをインターネットへ公開するのはおすすめしにくいです。Control UIは管理者向けの画面なので、外部公開よりもSSHトンネルでローカル接続のように扱う方法が安全寄りです。

公式情報でも、リモート接続の例として ssh -N -L 18789:127.0.0.1:18789 user@host のようなSSHトンネルが案内されています。このコマンドは、手元PCの 127.0.0.1:18789 を、リモート側の 127.0.0.1:18789 に転送するイメージです。

SSHトンネルを張ったあとは、手元のブラウザーで http://127.0.0.1:18789/ を開きます。リモートのGatewayを直接公開しなくても、SSH経由で安全に通せるのがポイントです。会社環境や本番に近い環境で使う場合は、最終的な判断は専門家にご相談ください。

SSHトンネルの流れ

SSHトンネルのメリットは、Gatewayのbind設定を広げずに済むことです。0.0.0.0 にbindして外部から直接アクセスさせる構成は便利ですが、その分だけ認証やファイアウォールの管理が重要になります。まず安全寄りに試すなら、SSHトンネルはかなり現実的な選択肢です。

Tailscale利用時の注意

Tailscaleを使うと、別端末やリモート環境からOpenClaw Gatewayへアクセスしやすくなります。公式情報でも、localhost、Tailscale Serve、SSHトンネルが推奨寄りのアクセス方法として扱われています。外部公開ではなく、限定されたネットワーク内でつなぐ考え方ですね。

gateway.auth.allowTailscale: true の場合、Tailscale ServeのIDヘッダーによって、Control UIやWebSocketの認証を満たせる場合があります。この構成では、ダッシュボード側に共有シークレットを貼り付けなくてもよいケースがあります。ただし、設定が正しくないと認証エラーになるので、token不要と決めつけない方がいいです。

Tailscale利用時も、Control UIが管理画面である点は変わりません。Tailscaleに入れる端末やユーザーの管理、Serve設定、Gateway側の認証設定をそろえて見る必要があります。ネットワークに入れる人が増えるほど、権限管理の重要度も上がります。

Tailscale利用時の確認ポイント

非同期のTailscale Serve経路では、同じスコープやIPで失敗した試行が重なると、2回目の不正な再試行で retry later のような状態になる場合があるとされています。何度も連打するより、設定値と認証方式を確認してから再試行する方が早いです。

パスワード認証との違い

OpenClawダッシュボードでは、tokenだけでなくパスワード認証も出てきます。共有シークレットpasswordは、gateway.auth.password または OPENCLAW_GATEWAY_PASSWORD で扱われる説明になっています。tokenと同じく認証情報ですが、保存や扱われ方に違いがあります。

tokenは、URLフラグメント経由で一度だけ渡され、Control UI側では現在のブラウザータブセッションと選択されたGateway URLに対してsessionStorageに保持される説明があります。一方、パスワードについては、ダッシュボードがリロードをまたいで永続化しないとされています。ここはかなり大きな違いです。

どちらを使うかは、Gateway側の設定に依存します。token認証が中心の環境もあれば、passwordを設定してControl UIに貼り付ける運用もあります。大事なのは、画面に出た認証要求に対して、設定済みの方式と一致する値を入れることです。

token認証とパスワード認証の違い

保存されないのは少し手間ですが、安全面では意味があります。特に共有PCや画面共有のある環境では、認証情報をブラウザーに残し続けない方が安心です。どちらの方式でも、tokenやpasswordをチャット、メモ、スクリーンショットに残さないようにしてください。

OpenClawダッシュボードtokenのまとめ

OpenClawダッシュボードtokenは、Control UIを安全に開くための認証情報です。単なるURLパラメータではなく、Gateway、WebSocket、SecretRef、リモート接続方法まで関わるため、最初は少しややこしく見えます。

特に大事なのは、tokenがURLに出ないことが異常とは限らないという点です。SecretRef管理やCLIの安全設計により、token値をログやクリップボードに出さない挙動があります。ここを押さえるだけでも、かなり落ち着いて対応できます。

要点まとめ

1. openclaw dashboard はControl UIを開く基本コマンドです
2. 標準のローカルURLは http://127.0.0.1:18789/ です
3. tokenはGateway接続を守る共有シークレットです
4. SecretRef管理ではtoken付きURLが出ない場合があります
5. unauthorized や 1008 は認証や接続先を順番に確認します
6. リモート接続ではSSHトンネルやTailscaleを優先して検討します
7. password認証はtokenとは保持のされ方が異なります

仕事用のAI活用や検証環境で使うなら、まずはローカルで動作確認し、次にSSHトンネルやTailscaleを検討する流れが扱いやすいです。公開範囲を広げる前に、認証方式、tokenの保存先、接続元の管理を確認してください。

設定項目やCLIの挙動は、OpenClawのバージョンによって変わる可能性があります。実際に運用へ乗せる前には、正確な情報は公式サイトをご確認ください。セキュリティや社内ネットワークに関わる判断は、必要に応じて専門家にご相談ください。

記事作成にあたり参考にさせて頂いたサイト

• ダッシュボード · OpenClaw
• Dashboard · OpenClaw
• OpenClaw Dashboard Command Tokenの完全ガイド：AIエージェントの可視化と最適化
• Openclaw (旧Moltbot) を試したよ｜YGPuzzleGTANT
• ダッシュボード · OpenClaw
• Reddit – Please wait for verification
• openclaw dashboard doesn’t include token in URL · Issue #7749 · openclaw/openclaw
• OpenClaw Dashboard Token Control UI Settings 完全ガイド：AIコスト管理と最適化
• OpenClaw Gateway Commands: Port 18789 Setup, Start/Stop & Token Auth | Meta Intelligence

当サイトについて

当サイトでは、インターネット上に散らばるさまざまな情報を収集し、AIを活用しながら要約・編集を行い、独自の切り口で見解を交えながらわかりやすい形でお届けしています。 情報の整理・編集にあたっては、読者やオリジナル記事の筆者へご迷惑をおかけしないよう、細心の注意を払って運営しておりますが、万が一、掲載内容に問題がある場合や修正・削除のご要望がございましたら、どうぞお気軽にお問い合わせください。 迅速に対応をさせていただきます。 その際には、該当記事の URLやタイトルをあわせてお知らせいただけますと、より速やかに対応 することができますのでそちらもご協力いただけますと大変幸いでございます。 今後とも当サイトをよろしくお願いいたします。