Claude CodeのWebFetchが『Unable to verify if domain is safe to fetch』で全滅した話

開発未分類

Claude CodeのWebFetchが『Unable to verify if domain is safe to fetch』で全滅した話

Micron株のニュースを調べようとして、benzinga.com、tipranks.com、finance.yahoo.com、streetinsider.comをWebFetchで取得しようとしたら、全部同じエラーで落ちた。

Unable to verify if domain {ドメイン名} is safe to fetch. This may be due to network restrictions or enterprise security policies blocking claude.ai.

フォールバック先としてhttps://r.jina.ai/経由のプロキシ取得も試したが、これも全く同じエラーで失敗した。r.jina.aiは特定サイトのボット対策を迂回するための汎用プロキシで、ドメインとしての「怪しさ」は普段は問題にならない。それでも同じエラーが出たのが引っかかったので、原因を調べた。

結論

  • WebFetchは実際にページを取得する前に、対象ドメインの中身ではなくホスト名だけをAnthropicのAPI(api.anthropic.com)に送り、安全性ブロックリストと照合している
  • この照合結果はホスト名単位で5分キャッシュされ、モデルやプロバイダに関わらず常に実行される
  • この照合(プリフライト)自体がapi.anthropic.comへの到達不良で失敗すると、渡したドメインが何であれ同じエラーメッセージで落ちる。r.jina.aiまで巻き添えになったのはこのため。ドメインが不正と判定されたのではなく、判定そのものが成立していない
  • 確認済みの対処法は、settings.jsonに"skipWebFetchPreflight": trueを設定してこのチェック自体をスキップすること。ただし安全性チェックを外すことになるため、公式にも「開放的なネットワーク環境ではオフのままにしておくべき」とされている
  • WebSearchとagent-browser(ユーザー自身のブラウザを操作するツール)がこの現象の影響を受けなかったのは、そもそもこの安全性チェックの経路を通らない別方式だから

WebFetchの安全性チェックの仕組み

WebFetchはURLを取得する前に、対象のホスト名だけをAnthropic側のエンドポイントに渡し、既知の危険なドメインでないかを照合する。ページの中身やDNS解決の結果を見ているわけではなく、ホスト名の文字列そのものをブロックリストと突き合わせているだけというのがポイントだ。この挙動はClaude Code公式ドキュメントの「WebFetch domain safety check」節に明記されている。

このチェックは以下の性質を持つ。

  • モデルプロバイダ(Anthropic API、Bedrock、Vertex AI等)に関わらず常時有効
  • 環境変数CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFICを設定していても影響を受けない(このチェック自体は「非必須通信」扱いされない)
  • 結果はホスト名ごとに5分間キャッシュされる

つまりWebFetchを使う限り、api.anthropic.comへの到達性そのものが前提条件になっている。

なぜr.jina.aiまで巻き添えになったのか

このチェックは「渡されたホスト名を1つの外部APIに問い合わせる」という単一の依存関係でしかない。そのため、問い合わせ先(api.anthropic.com)への到達自体が詰まっていれば、渡すホスト名がbenzinga.comだろうとr.jina.aiだろうと結果は同じ「確認できない」になる。

言い換えると、今回のエラーは「このサイトは危険と判定された」ではなく「安全かどうかの判定そのものが機能していない」ことを示している。個別サイトのボット対策(Cloudflareの人間確認等)とは別種のエラーで、実際に今回もagent-browser経由でstreetinsider.comやtipranks.comにアクセスしたときはCloudflareの確認画面が出ており、これはこれで別問題として区別する必要がある。

確認済みの対処法

  • ~/.claude/settings.json(または対象プロジェクトの.claude/settings.json)に次を追加すると、次回セッションからプリフライトそのものをスキップし、直接取得を試みるようになる。
{ "skipWebFetchPreflight": true }

ただしこれは安全性チェックそのものを無効化する設定であり、「開放的なネットワーク環境なら本来オフのままにしておくべき」と位置づけられている。企業のプロキシ配下やクラウド環境(Bedrock/Vertex AI/Foundry等)で送信経路そのものが制限されている場合の回避策という扱いだ。有効化するかどうかは、この判定機構自体を外すトレードオフを理解した上で判断する必要がある

  • api.anthropic.comへの到達性を確保する。ファイアウォール、ウイルス対策ソフトのWeb保護機能、VPNのTLSインスペクション等が、このAPIへの通信だけを個別に遮断していないか確認する
  • Bashツールで直接curlを叩く経路は、このプリフライトを経由しないため到達可能なら取得できる、という報告がある

未確認の対処法

  • Claude Codeの再起動・最新版へのアップデートで直ったという報告がある(一時的なAnthropic側の不調だった可能性がある)
  • ウイルス対策ソフトのWeb保護機能を一時的に無効化して切り分ける

代替手段が影響を受けない理由

  • WebSearch: 検索結果のスニペット取得はAnthropicのサーバー側で完結する別経路であり、クライアントから任意のホスト名を安全性チェックAPIに渡す処理を経由しない
  • agent-browser: ユーザー自身のログイン済みChromeを直接操作するツールで、WebFetchの安全性チェックはもちろん、Anthropicのインフラ自体をそもそも経由しない。通信経路は手元のブラウザから対象サイトへ直接、というだけになる

まとめ

「WebFetchが特定のサイトだけ取得できない」なら、そのサイトのボット対策やSSL証明書を疑うのが自然だ。しかし今回のように複数の無関係なドメインが同じ文言で一斉に失敗する場合は、個々のサイトではなく、WebFetchの前段にあるapi.anthropic.comへの到達性そのものを疑ったほうがいい。r.jina.aiのような汎用プロキシまで同じエラーで落ちたのが、この見立ての一番わかりやすい手がかりだった。

恒久的に直したい場合は、まずapi.anthropic.comへの到達性(ファイアウォール・ウイルス対策ソフト・VPN設定)を確認し、それでも解決しない、あるいは意図的に閉じた回線で運用している場合にだけskipWebFetchPreflightを検討する、という順番が安全だ。

Sources:

#Claude Code#WebFetch #トラブルシューティング#settings.json