2026年 OpenClaw Playwright skill-browser ヘッドレス Mac VPS デプロイ：Chromium 同一アカウントインストール、並列上限とエラー対照 Runbook（意思決定表と FAQ）
Mac VPS で OpenClaw が IM チャネルを 7×24 回しているのに、Agent に Web ページを開かせたりフォーム入力や競合スナップショット取得を任せたいとき、「ノート PC で一時的に Chrome を開く」運用では監査可能な本番能力になりません。OpenClaw の skill-browser は Playwright ヘッドレス Chromium を基盤に、ブラウザ操作をゲートウェイのツール面へ接続します。本稿は SSH のみ・デスクトップなしの Mac クラウド運用者とプラットフォーム責任者向けに、典型四痛みの分解、ヘッドレス Mac VPS vs ローカル有画面 Mac vs Docker browser の意思決定表、前提チェックリスト、並列パラメータ表、七步 Runbook、三つの引用可能な判定、エラー対照表、業務例までを一連の Runbook にまとめます。ゲートウェイ install、Docker 7×24、バージョン固定、ClawHub 監査の内部リンクへ誘導し、Apple Silicon Mac クラウド上で再現可能なデプロイを目指します。
目次
- 1. 痛みの分解：Chromium 欠落、OOM、モーダルブロック
- 2. 意思決定表：ヘッドレス Mac VPS vs ローカル Mac vs Docker browser
- 3. Mac VPS 前提：Node 22、18789、同一アカウント HOME
- 4. skill-browser パラメータ表：headless、並列、タイムアウト
- 5. 七步 Runbook：アカウント → インストール → Chromium → プローブ → スモーク → launchd
- 6. 三つの判定：コールドスタート、RSS、スナップショット成功率
- 7. エラー対照表と層別排障
- 8. 業務例：フォーム入力、監視、IM 連動
- 9. FAQ
- 10. まとめ
1. 痛みの分解：Chromium 欠落、OOM、モーダルブロック
skill-browser は障害面をブラウザ子プロセスまで拡張します。ゲートウェイが online でも、初回 navigate で失敗するケースは珍しくありません。本番で繰り返し見る典型パターンを四つに整理します。
- Chromium が同一アカウントで未インストール：CLI と launchd のユーザが不一致だとキャッシュが分裂し、ログに実行ファイルが見つからないと出ます。SSH セッションだけで
npx puppeteerを実行しても、常駐ゲートウェイからは別ユーザの HOME を参照していることがあります。 - Exit 137：parallel contexts を上げすぎると Chromium が OOM Kill され、ゲートウェイ側には tool timeout だけが残ります。メモリ 8 GB 未満のノードで context 4 以上を試すと再現しやすいです。
- HOME 分裂：SSH ではスモーク成功、launchd では失敗。設定ディレクトリが書き込み不可、または profile がロックされたまま残る典型です。
echo $HOMEと plist のEnvironmentVariablesを必ず突合してください。 - モーダルブロック：
blockedByDialog未設定時に evaluate がハングし、空スナップショットが返ります。Cookie 同意や SSO ダイアログが原因のことが多く、fail-fast と dismiss の方針を先に決めておく必要があります。
2. 意思決定表：ヘッドレス Mac VPS vs ローカル Mac vs Docker browser
selector デバッグや UI 確認はローカル有画面 Mac が向きます。7×24 とポート 18789 同機ならヘッドレス Mac クラウドが第一候補です。Docker 内 browser の運用詳細は7×24 Runbookを参照してください。
| 観点 | ヘッドレス Mac VPS | ローカル有画面 Mac | Docker 内 browser |
|---|---|---|---|
| レイテンシ | ゲートウェイ同機で RTT が低く、本番向き | 開発しやすいがスリープで切断 | ネットワーク・ボリューム権限が一段増える |
| ディスク | Chromium キャッシュ約 300–500 MB | パス統一が難しい | 再ビルドのたび再ダウンロード |
| 権限 | 純 headless、launchd と整合 | 手動でモーダル操作可能 | 137 と反 bot 検知が起きやすい |
| 運用 | ゲートウェイ Runbook参照 | 7×24 不可 | 排障チェーンが長い |
| 用途 | フォーム入力、スナップショット、IM 連動 | selector デバッグ | 短時間バッチ |
3. Mac VPS 前提：Node 22、18789、同一アカウント HOME
skill-browser を入れる前に、ゲートウェイ本体が安定していることを確認します。半インストール状態のまま browser skill だけ足すと、障害の切り分けが一層難しくなります。
- ランタイム：Node.js 22 以上。
openclaw doctorとopenclaw --versionで半インストール警告がないこと。 - ゲートウェイ：
lsof -i :18789またはopenclaw gateway statusで待受確認。失敗時はゲートウェイ install Runbookで修復。 - アカウント整合：launchd plist の
UserNameとHOMEを記録。Chromium インストールと skill 設定は必ず同一ユーザで行う。 - リソースと監査：メモリ 8 GB 以上、ディスク 20 GB 以上を推奨。ClawHub から pull する前にサードパーティ Skill 監査を完了する。
openclaw gateway status
echo "USER=$USER HOME=$HOME"
4. skill-browser パラメータ表：headless、並列、タイムアウト
skill-browser は Playwright ヘッドレス Chromium を基盤に動作します。下表はレビュー用の骨格です。アップグレード後は openclaw doctor で再確認してください。本番では parallel contexts を段階的に上げ、各段階で RSS とスナップショット成功率を記録することを推奨します。
| 設定キー | 推奨方向 | よくある誤設定 |
|---|---|---|
headless |
デスクトレス環境では true | false で display が見つからない |
parallel contexts |
初期 1–2、context あたり約 400–600 MB | 4 以上で OOM 137 |
timeout-ms |
navigate 3–6 万 ms | 短すぎて失敗、長すぎてキュー占有 |
blockedByDialog |
モーダル dismiss または fail-fast | 未設定で evaluate がハング |
npx puppeteer browsers install chromium
5. 七步 Runbook：アカウント → インストール → Chromium → プローブ → スモーク → launchd
以下の七步を変更票テンプレートに固定し、各ステップで toolCallId または doctor 出力を残してください。ロールバック時も同じ順序で再検証できます。
- アカウントと HOME 整合：launchd plist の
UserNameを確認。SSH は同一ユーザでログインし、echo $HOMEが plist と一致すること。 - バージョン固定と doctor：
openclaw.jsonをバックアップしopenclaw doctorを実行。アップグレードは5月バージョン列車 Runbookに従う。 - skill-browser インストール：監査後
openclaw skills install skill-browser。 - Chromium インストール：同一アカウントで
npx puppeteer browsers install chromium。 - パラメータ記述：headless、parallel contexts、timeout-ms、blockedByDialog を設定。
- プローブとスモーク：18789 待受、固定 URL スナップショット、toolCallId を記録。
- launchd 検収：launchctl で plist をロードし、再起動後にスモークを再実行。
launchctl bootstrap gui/$(id -u) ~/Library/LaunchAgents/com.openclaw.gateway.plist
openclaw doctor
openclaw gateway status
6. 三つの判定：コールドスタート、RSS、スナップショット成功率
本番宣言前に次の三つをダッシュボード化し、インシデント時は閾値で切り分けます。いずれもゲートウェイ JSONL の toolCallId と突合してください。
- Chromium コールドスタート：Mac クラウド初回 launch は 8 秒未満を目安。15 秒超はディスク IO を先に調査。
- メモリ使用量：単一 context スモーク後、ゲートウェイと Chromium 合計が利用可能メモリの 60% 未満であること。
- スナップショット成功率：固定 URL を 20 回連続実行で 95% 以上。90% 未満ならモーダル戦略を先に見直す。
7. エラー対照表と層別排障
「browser ツール失敗」は層ごとに切り分けます：Chromium の存在 → 同一アカウント HOME → headless/並列パラメータ → モーダルと timeout。各層で JSONL の toolCallId を揃え、感覚的な再起動だけに頼らないでください。
| 症状 | 根因 | 修復 |
|---|---|---|
| Chromium が見つからない | 未インストールまたはユーザ不一致 | 同一ユーザで browser 再インストール + doctor |
| Exit 137 | 並列過多 / OOM | parallel contexts を下げる |
| blockedByDialog | モーダル未処理 | dismiss または fail-fast |
| evaluate タイムアウト | timeout 過短 / 反 bot | timeout 調整または URL 変更 |
8. 業務例：フォーム入力、監視、IM 連動
サポートページ自動入力：Agent が Telegram でチケットを受け、skill-browser が社内フォームを開きフィールドを埋めてスクリーンショットを返送。SSO モーダルは fail-fast に設定。競合監視：cron で固定 selector のスナップショットを JSONL に書き込み、parallel は 1 のまま OOM を防ぐ。閲覧後返信：ユーザーが @bot でドキュメントを尋ねたとき、先に navigate して要約。ログイン必須や動的レンダリングページに向きます。
9. FAQ
質問：skill-browser は Ollama や複数 Provider と共存できますか？ 可能です。browser 子プロセスは独立しており、tools.profile で並列上限を設け RSS を観測してください。
質問：v2026.5.x アップグレード後に再検証が必要ですか？ doctor、同一アカウント Chromium 再インストール、最小スナップショットスモークが必要です。バージョン列車 Runbookを参照。
質問：Mac クラウド vs Linux VPS/Docker の選び方は？ 7×24 とゲートウェイ同機なら Mac クラウド。短時間バッチは Docker も可ですが、OOM と権限の排障が長くなります。
10. まとめ
成功基準は skill-browser → 同一アカウント Chromium → 18789 スナップショット再現の連鎖です。ノート PC と WSL2 は 7×24 に不向き。Linux VPS 上の Docker browser は /dev/shm と headless 検知で排障が長くなりがちです。browser skill と IM チャネルを並行常駐させるなら、VPSMAC Apple Silicon Mac クラウドでゲートウェイ、Chromium キャッシュ、launchd を一本の Runbook に収める方が安定します。Docker は短時間バッチ向きですが、本番ヘッドレス Mac スタックの代替にはなりません。Docker 7×24とSkill 監査も併読してください。