【完全解説】OpenClawにブラウザ操作させる設定手順 (WSL+Windows Chrome+CDP)

AI

OpenClawにブラウザ操作させるための設定まとめ（WSL + Windows Chrome + portproxy）

構成: Windows（Chrome）+ WSL（OpenClaw Gateway / Docker）
① Chromeを--remote-debugging-port=9222付きで起動
② Windowsでnetshによるportproxyを作成（9223→9222中継）
③ vEthernet (WSL)のIPアドレスを確認（例: 172.27.96.1）
④ Dockerコンテナ内でopenclaw browser create-profile --name remote --cdp-url http://172.27.96.1:9223を実行
⑤ Discordから「remote プロファイルを使って〇〇して」と明示して指示

以下、「AIに調べ物をさせたい」という動機から始まった、ブラウザ設定の試行錯誤の全記録。

なぜブラウザ操作を試みたのか

OpenClawをDiscordと連携させ、AIエージェントとチャットで会話できるようになった。次に試したかったのが「AIに調べ物をさせる」こと——つまり、ウェブを自律的に検索・参照させることだ。

OpenClawはブラウザ操作機能を持っているが、それを使うにはブラウザとの接続設定が必要だった。何も設定しない状態では、エージェントはブラウザを見ることができない。

最初の想定：Brave Browserは有料の壁があった

コミュニティの情報を漁ると、OpenClawのブラウザ操作にBrave Browserを使う方法が自然と目に入った。しかし調べていくうちに、AI関連の連携機能には有料のサブスクリプションが絡んでくる可能性があると判明した。

毎月のAPIコストがかかるOpenClawの運用に、さらにブラウザのコストを乗せるのは現実的でない。そこで無償の方法を探すことにした。

現行の公式推奨：Browser Relay拡張ではなく「remote CDPプロファイル」

ChatGPTに詳細を確認しながら設定を進めた結果、重要な前提が判明した。

OpenClawのブラウザ接続方式は最近アップデートされており、旧来の「Browser Relay拡張」は現行の主流ではなくなっている。openclaw doctorを実行すると、旧来の拡張設定はexisting-sessionに正規化されると明記されているほどだ。

さらに、今回の構成——WSLでOpenClaw（Docker）、WindowsでChrome——という「split-host」構成では、userやexisting-sessionではなく、remote CDPプロファイルを使うのが公式の筋ということが分かった。

接続方法 適した構成 備考
user (existing-session) GatewayとChromeが同じホスト上 ❌ WSL+Windowsでは不適切
Browser Relay拡張 （旧来の方法） ❌ 現行の主流ではない・不安定
remote CDPプロファイル ✅ WSL2 Gateway + Windows Chrome 公式推奨。今回採用した方法

設定手順：全9ステップの試行錯誤

Step 1. ChromeをCDPポート付きで起動する

Windows側のPowerShellをAdmin権限で開き、まずChromeを完全終了してからフラグ付きで起動した。

# Chromeをすべて終了
taskkill /F /IM chrome.exe

# CDPポート＋専用プロファイルで起動（普段使いChromeと分離するため--user-data-dirも指定）
& "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --remote-debugging-port=9222 --user-data-dir="C:\temp\chrome-openclaw"

起動後、Windows側のブラウザでhttp://127.0.0.1:9222/json/versionを開くとJSONが返ってきた。これでChrome側のCDP公開は成功。

{
   "Browser": "Chrome/146.0.7680.80",
   "Protocol-Version": "1.3",
   "webSocketDebuggerUrl": "ws://127.0.0.1:9222/devtools/browser/..."
}

Step 2. 最初のハマりポイント：WSL側からは届かない

「Windowsで見えたのだからWSLからも見えるだろう」——この思い込みが最初の罠だった。

# WSL側からWindows側IPへのcurlを試みる
cat /etc/resolv.conf
# → nameserver 10.255.255.254

curl http://10.255.255.254:9222/json/version
# → curl: (7) Failed to connect to 10.255.255.254 port 9222 after 0 ms: Connection refused

Windows側でnetstatを確認すると、こうなっていた。

TCP    127.0.0.1:9222    0.0.0.0:0    LISTENING    26008

9222ポートはWindowsのlocalhost（127.0.0.1）にしか開いていない。つまりWindows自身からは見えるが、WSLからは届かない状態だった。

⚠️ ハマりポイント①：127.0.0.1:9222が見えてもWSLから届くとは限らない

--remote-debugging-address=0.0.0.0を起動オプションに追加しても、環境によっては外向きbindにならないことがある。Chrome起動オプションだけで解決しようとすると詰まる。

Step 3. portproxyで橋渡しを作る

方針を変え、Windows側で「橋渡し（ポートフォワード）」を作ることにした。netshコマンドで、外から届く9223ポートを内部の127.0.0.1:9222に転送する設定だ。

# 管理者PowerShellで実行
netsh interface portproxy add v4tov4 listenaddress=0.0.0.0 listenport=9223 connectaddress=127.0.0.1 connectport=9222

# 確認
netstat -ano | findstr 9223
# → TCP    0.0.0.0:9223    0.0.0.0:0    LISTENING    4828

0.0.0.0:9223 LISTENINGが出た。外向きに受け口ができた。

Step 4. Windowsファイアウォールで9223ポートを許可

New-NetFirewallRule -DisplayName "OpenClaw Chrome CDP 9223" -Direction Inbound -Action Allow -Protocol TCP -LocalPort 9223

Step 5. 二つ目のハマりポイント：resolv.confのIPでは届かない

ファイアウォール設定後にWSLから試みたが、まだ届かなかった。

curl http://10.255.255.254:9223/json/version
# → curl: (7) Failed to connect to 10.255.255.254 port 9223 after 0 ms: Connection refused

さらにWindows PowerShellから自分自身でcurl http://10.255.255.254:9223を試しても届かなかった。つまり/etc/resolv.confのnameserverがそのまま今回の接続先IPになるとは限らないことが判明した。

⚠️ ハマりポイント②：resolv.confのIPをそのまま信じてはいけない

WSLのネットワーク構成によっては、resolv.confのnameserverとvEthernet (WSL)のIPが異なることがある。

Step 6. 正解は vEthernet (WSL) のIPアドレスだった

Windows PowerShellでipconfigを実行すると、WSL用の仮想NICのIPが見つかった。

イーサネット アダプター vEthernet (WSL (Hyper-V firewall)):
   IPv4 アドレス . . . . . . . . . . . .: 172.27.96.1

このIPでcurlを試すと——

# Windows PowerShell側
curl.exe http://172.27.96.1:9223/json/version
# → StatusCode: 200  "Browser": "Chrome/146.0.7680.80"

# WSL側
curl http://172.27.96.1:9223/json/version
# → {"Browser": "Chrome/146.0.7680.80", "Protocol-Version": "1.3", ...}

WSLからWindowsのChromeへの経路が開通した。使うべきエンドポイントはhttp://172.27.96.1:9223だ。

Step 7. 三つ目のハマりポイント：WSLから直接openclawコマンドは打てない

いよいよOpenClawへのプロファイル登録を試みたが——

openclaw browser create-profile --name remote --cdp-url http://172.27.96.1:9223
# → openclaw: command not found

今回の環境はOpenClawをDockerコンテナで動かしているため、WSLのホスト側にはopenclawコマンドが存在しない。コンテナの中で打つ必要があった。

docker exec -it openclaw-openclaw-gateway-1 sh

Step 8. コンテナ内でremote プロファイルを作成

$ openclaw browser create-profile --name remote --cdp-url http://172.27.96.1:9223

🦞 Created profile "remote"
  cdpUrl: http://172.27.96.1:9223
  color: #0066CC

続けて状態を確認。

$ openclaw browser profiles

◇
remote: running (3 tabs) [remote]
  cdpUrl: http://172.27.96.1:9223, color: #0066CC
openclaw: stopped
  port: 18800, color: #FF4500
chrome: running (0 tabs) [default]
  port: 18792, color: #00AA00

remote: running (3 tabs)——OpenClawがWindowsのChromeに接続し、3つのタブを認識できている！ここでブラウザ接続は完成だ。

Step 9. Discordから使わせる：最後の落とし穴

Discordで「ブラウザの設定をしたけどどう？」と確認すると、意外な返答が来た。

いま確認した。まだ接続できてない状態です（tabs: 0）。
たぶん最後の1ステップだけ未実施👇
Chrome で OpenClaw Browser Relay の拡張アイコンをクリック
バッジが ON になるのを確認

CLIではremote: running (3 tabs)なのに、なぜ「未接続」と言うのか。

原因は、Discordから指示するとき「プロファイル名を明示しないと、デフォルトプロファイルを見にいく」という仕様にあった。Discordから「ブラウザを見て」とだけ言うと、remoteではなくopenclawやchromeという別のプロファイルを参照してしまうのだ。

そこで明示的に伝えた。

Relay拡張は使っていません。WSL2 + Windows Chromeのremote CDPで接続しています。
browser profileはremoteです。remote プロファイルを使って、現在のタブ一覧を確認してください。

AIの返答：

確認できた。remote プロファイルで接続OK。
いま見えてるタブ一覧はこれです：
・Omnibox Popup
・新しいタブ
・Example Domain (https://example.com/)

Discord → OpenClaw → remote profile → Windows Chrome の接続が完全に通った。

今回の接続構成の全体像

Discord（スマホ/PC）
    ↓
OpenClaw（WSL / Docker コンテナ）
    ↓  browser profile "remote"

http://172.27.96.1:9223
172.27.96.1

    ↓  Windows portproxy（9223→9222中継）

http://127.0.0.1:9222
127.0.0.1

    ↓
Chrome（Windows側 / 専用プロファイル）

ハマりポイント総まとめ

# ハマったこと なぜ起きたか・解決策
① Relay拡張 / existing-sessionを使おうとした WSL+Windows(split-host)構成ではremote CDPプロファイルが正解。旧来の方法は現行では非推奨
② 127.0.0.1:9222が見えたのにWSLから届かない Chrome CDPはWindowsのlocalhost専用。netsh portproxyで9223→9222の橋渡しを作って解決
③ resolv.confのnameserver（10.255.255.254）では届かなかった ipconfigでvEthernet (WSL) のIPv4アドレス（172.27.96.1）を確認して解決
④ WSL直接でopenclawコマンドが見つからない Docker運用の場合、CLIはコンテナ内で実行。docker exec -it openclaw-openclaw-gateway-1 shで入ってから実行
⑤ Discordから「ブラウザ見て」と言うと別プロファイルを見に行く プロファイルを省略するとデフォルトが使われる。「remoteプロファイルを使って〇〇して」と明示的に指定する必要あり

実際にブラウザ操作させてみて分かった限界

接続に成功した後、さっそくAIに旅行サイトで空室を調べさせてみた。「3/28 伊豆で露天風呂付き客室、夕朝食付きで空きを探して」という依頼だ。

候補の宿を複数抽出してくれたが、日付をカレンダーで絞り込む部分が正確に動かなかった。自身も「カレンダー操作、いまの自動操作だと取りこぼしてる」と認めていた。

ブラウザ操作AIの得意・不得意はこんな感じだ。

✅ 得意なこと ❌ 苦手なこと
一覧ページから複数候補を拾う カレンダーUIを正確に操作する
検索結果の上位件を要約・比較する 複数条件をUIで厳密に設定する
人が途中で準備した画面の続きを引き継ぐ ログイン・同意ポップアップをまたぐ
タブ一覧の把握・ページ内容の読み取り リアルタイム変動する在庫・価格の確定

つまり、URL直打ちで済む単純作業ならブラウザ操作の意味は薄い。「検索結果を見て、どれを選ぶか判断する」「一覧から条件を絞る」「複数ページを渡って比較する」——そういった「Webを読んで判断するプロセス全体」を代行させるときにこそ、価値が出る。

まとめ

OpenClawにブラウザ操作をさせるために、無償でできる方法としてWindowsのportproxyを使ったCDP中継という方法にたどり着いた。

設定そのものは難しくないのだが、「ポートが開いているのにWSLから届かない」「resolv.confのIPが使えない」「Dockerコンテナの中からコマンドを打つ必要がある」など、WSL + Docker + Windows Chrome という組み合わせ特有のハマりが多かった。

同じ構成で詰まっている人の参考になれば幸いだ。

※2026年3月時点。OpenClaw 2026.3.2 (unknown) / Windows 11 + WSL2 + Docker環境で検証。Chrome 146.0.7680.80。vEthernet (WSL)のIPアドレスは環境によって異なる。

コメント

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