OpenClaw をリモート Macで動かしているのに回答が「オフライン気味」なのは、組み込み Web 検索がまだ配線されていないことが多いです。2026 年のスタックでは web_search で広く、web_fetch で単一 URL、必要なら Firecrawl 系のフォールバックで JS 重いページに対応します。本稿は v2026.3.28 プラグイン承認 や ブラウザ MCP とは切り分け、プロバイダ選定、有効化の順序、API キー、allowlist、/approve、429／空結果、ログの見方と VNC チェックリストに絞ります。検索は動くのに返信が無いときは 無応答の切り分け と launchd デーモン も参照してください。
ドキュメント貼り付けに頼りがち、デモ直後に 429、.env にキーがあるのに web search disabled などは、単一トグルではなく 手順全体（doctor → configure → launchd 環境 → allowlist → チャネルでの試験 → 承認 UI → 段階的な負荷下げ）で解くのが近道です。
対象と境界
macOS 上で OpenClaw を本番運用し、公開 Web の取得を安定させたい向けです。初回インストール手順ではありません。プラグイン承認／ブラウザ MCP の記事と役割が被らないよう、検索プロバイダとクォータに焦点を当てます。
検索がクリティカルパスに乗ったら、設定の版管理・現在有効なエージェントプロファイルの記録・インシデント時に allowlist を狭めるロールバック手順まで含めて運用設計してください。
つまずきポイントと境界
- ツールの混同: ブラウザ MCP は実 Chrome プロファイル、組み込み検索はプロバイダ API。境界なしだとコストと引用が二重化します。
- allowlist のドリフト: アップグレードでツール名が増えても、
web_searchやgroup:webがプロファイルに無いと幻覚が増えます。 - シークレットの載せ方: 対話シェルだけに export しても launchd 経由の Gateway に届かないことがあります。
- 承認のデッドロック:
requireApprovalが検索を止めることがあります。チャネル別の /approve 手順は承認記事を参照。 - クォータの形: 429 は並列サブエージェントやリトライが原因のことが多く、先に並列度を下げます。
- 空ヒット: フィルタや言語ヒントが厳しすぎると HTTP 200 でも行がゼロになります。
- 可観測性の穴: モデルの会話ログしか無いとツールの HTTP ステータスが見えません。ベンダ切り替え前に、プロバイダ名・レイテンシ・ステータスが残る Gateway／ツールトレースを有効化してください。
- マルチテナントなキー混在: ステージングと本番で同じ API キーを共有すると 429 の原因特定が不可能になります。環境ごとにキーを分け、カナリアにはラベルを付けます。
ログ、ポリシー面、アップグレードに耐えるランブック
web_search・web_fetch・クロール系フォールバックを分離する
「検索が壊れた」と言われても、実際は単一 URL の取得タイムアウト、TLS インスペクション、Firecrawl 側クォータ切れかもしれません。会話 ID かリクエスト ID を一つ決め、プロバイダ名・HTTP コード・リトライ回数・モデル側の並列再試行まで一気通貫で追跡してください。複数サブエージェントのログを混ぜると、429 を認証問題と誤認しやすくなります。
企業出口と DNS がクォータに似た挙動をする
スプリット DNS やキャプティブポータル、TLS 検査は「HTTP 200 だが本文空」や極端な遅延を生み、レート制限に見えます。Gateway ホストのエグレス経路をプロバイダ表とセットで文書化し、VNC 上の Safari や、サービスと同一ユーザ文脈の curl で到達性を確認してください。対話 SSH と launchd ではプロキシや環境変数が一致しないことがあります。
ランブックの順序：PID 環境 → allowlist 差分 → 最小再現 → 並列
まず実行中 Gateway PID に見える環境変数を確認し、リリースノートと有効 allowlist を突き合わせ、方針が許すなら LLM の外で最小クエリを再現し、最後にツール並列とサブエージェントを下げます。アップグレード後に group:web が欠けているのにキーだけ回し続けるパターンが最も時間を浪費します。
ダッシュボードを超えたコスト・安全ガードレール
コンソールは月次集計を見せますが、エージェントはバーストを作ります。プロバイダ上限に加え、会話あたりの最大並列検索、類似クエリの重複排除、機密チャネル向けの「検索オフ」モードをオーケストレーション側で持ちましょう。理由は SOUL/MEMORY に残し、半年後もなぜ厳しい allowlist なのか分かるようにします。
検索プロバイダの判断表（目安）
| パターン | 向いている場合 | 注意 |
|---|---|---|
| Brave Search（よくある既定） | 汎用検索、プライバシー寄りの既定 | 月間上限と引用ポリシー |
| Tavily 等の AI 向け API | エージェント向け JSON スニペット | 有料帯；include_domains でノイズ抑制 |
| Perplexity 系 | リンク付き要約 | コスト；コンプラに合う引用形式か |
| Gemini / Google キー | Google AI 課金に統一済み | リポジトリに置かない；SecretRef でローテ |
| fetch 側の Firecrawl | 単一 URL の深掘り／ボット対策ページ | 検索とは別クォータで見る |
| Bing / 広い SERP API | 従来型ブルーリンクや地域依存 SERP が必要 | コンプラとキャッシュ方針；生 SERP の長期保存が禁止される場合あり |
| 自前検索／イントラ索引 | 公網検索がポリシーで不可またはオフライン要件 | 鮮度・SLO・埋め込みパイプラインまで自前——「タダの検索」ではない |
九段階：有効化と検証
doctor のベースライン保存
openclaw doctor で web / search / tools に触れる行を残し、バージョンとセットで保管。
web セクションの設定
openclaw configure --section web。ファイル派は tools.web.search に同じ項目を反映。キーはコミットしない。
デーモンと同じ経路でキーを載せる
TAVILY_API_KEY 等を plist／サービスが読む環境に。再起動試験で確認。
allowlist を実プロファイルに合わせる
web_search と必要なら web_fetch を有効リストまたは group:web に。
本番チャネルでカナリア質問
リポジトリではなく公開ウェブの事実確認を求め、Gateway ログの遅延とエラーを見る。
承認ゲートを意図的に通す
before_tool_call があるならチャネル UI で承認し、再実行でキャッシュ挙動を確認。
順序立てて切り分け
401/403→キーと ACL；429→バックオフと並列；timeout→経路；空 JSON→フィルタ緩和；TLS→プロキシ文書。
再現パッケージを残す
マスク済みログと tools.web 相当の設定断片（秘密情報なし）、allowlist 抜粋をインシデントごとに保存し、アップグレード後と差分比較できるようにする。
劣化モードを事前定義
検索を読み取り専用／低頻度にするユーザー向け文言、サブエージェント停止、許可されるなら小型モデルへの切替を文書化。当日の即興ではなく手順化する。
運用メモ（引用可）
チケット前チェック
- Doctor output archived with version
- Provider block present in JSON or wizard transcript
- Effective allowlist contains web tools
- Secrets visible to the running Gateway process
- Canary query reproduced from the same channel users rely on
VNC リモート Mac：コンソールと権限
リモート Mac で Gateway UI を開きつつ SSH でログを tail。時刻合わせ、HTTPS の MITM の有無、メニューバー同伴アプリの状態を確認。ネットワーク拡張や自動化の同意は GUI セッションで処理しないと、検索プロバイダのせいにしがちです。
キーチェーンやシークレット管理 UI をグラフィカルセッションで開き、plist が参照する資格情報が実在し期限切れでないか確認してください。ローカル端末検証と本番サービスを混在させる場合、運用者用とサービスアカウントに近い文脈でブラウザを二系統に分け、取り違えた「疎通証明」を避けます。
関連記事
承認：プラグイン承認と Grok。ブラウザ：Chrome DevTools MCP。沈黙：無応答の切り分け。常駐：launchd チェックリスト。
FAQ
- UI がまだ disabled と言う allowlist・provider ブロック・Gateway プロセス環境のどれか。env 修正後に doctor を。
- 検索が動くのに Firecrawl は？
web_fetch難所向け。予算とエラーは search と分けて見る。 - 429 でベンダー替えたくない 並列と指数バックオフ、オーケストレーション層のキャッシュを先に。
- MCP の方が安全？ 脅威モデルが違う。タスクごとに選び SOUL/MEMORY に明記。
- 手元 Mac とリモート Mac で結果が違うのはなぜ？ DNS、PAC、システム言語／地域、IPv6 優先度が SERP を変えます。必ず Gateway ホストで再現してください。
- 検索結果をワークスペースにキャッシュしていい？ コンプラと保持ポリシーが許す場合のみ。SERP は鮮度が落ちやすいので短い TTL とプロバイダメタデータの保存を推奨。
まとめ
Linux VM やヘッドレスだけでは同意ダイアログやコンソールの欠落が隠れ、誤ったユーザ文脈での「疎通テスト」も起きやすいです。VNC で実際の macOS デスクトップを触れると、キー読み込みから Gateway オーバーレイまで一気通貫で追え、承認やキーチェーン、ブラウザ隣接デバッグが絡む場面で特に効きます。短期検証なら VNCMac の VNC 対応 Mac と本サイトのチェックリストの方が、不適切なホスト形でログの断片だけ追うより時間を節約できることが多いです。