Claude Code WebFetchが固まる問題、v2.1.268でようやく直った——半年放置された理由と対処法
Claude CodeのWebFetchが数十分〜数時間固まる不具合が2026年9月のv2.1.268でようやく修正された。半年以上直らなかった技術的な理由と、CLAUDE_CODE_WEBFETCH_DEADLINE_MSの使い方、旧バージョンでの回避策をまとめた。
エンジニアのゆとです。
競合サイトのリサーチや公式ドキュメントの確認で、Claude CodeのWebFetchを1日に何十回も叩いてる。大抵は数秒で返ってくるんだけど、たまに画面が「Fetching…」のまま完全に止まる瞬間があって、これが地味にストレスだった。Escapeでキャンセルするしかなくて、待ってる間は何が起きてるのか一切分からない。
これ、自分だけの体感かと思ったらそうじゃなかった。GitHubのIssueを漁ると、同じ症状が今年の1月から報告され続けていて、中には3時間以上ハングして課金だけ発生した事例まであった。それが2026年9月10日リリースのv2.1.268で、ようやくちゃんとした形で直っている。この記事では「なぜ半年以上直らなかったのか」という技術的な理由と、新しく入った設定項目の使い方、まだ古いバージョンを使ってる人向けの回避策をまとめる。
症状 — 「Fetching…」で無反応になり、Escape以外に止める手段がない
症状はシンプルで、WebFetchツールを呼んだ後の画面が「Fetching…」の表示のまま数分〜数時間動かなくなる。エラーも出ないし、タイムアウトメッセージも出ない。Ctrl+CやEscapeでセッションごと止める以外に復帰する方法がなかった。
GitHubのIssueにはかなり極端な事例も報告されている。
同種の報告は #8980、#17735、#24684、#34236、#34565、#35426 と、2026年1月から4月にかけて何度も上がっていた。しかもこれらのIssueはいずれも一度「closed」になっている。つまり、その都度部分的な修正は入っていたのに、症状そのものは形を変えて再発し続けていたということになる。
なぜ半年以上直らなかったのか — パイプラインの中に「タイムアウトなしの区間」が残っていた
一番詳しく原因を突き止めていたのは、Issue #34236の報告者だった。curlとNode.jsのhttps.getで同じURLに直接アクセスすると1秒未満で応答が返るのに、Claude Code経由だと固まる、という切り分けをした上で、cli.jsのWebFetch実装を実際に読んで、処理が4段階に分かれていることを突き止めている。
報告されていた内訳はこう。
- ドメインの安全性チェック — 10秒でタイムアウトする
- axiosによるHTTP取得 — ソケットの無通信状態で60秒タイムアウトする
- HTMLからMarkdownへの変換（Turndown）
- 取得内容をAIで要約する処理 —
messages.create({stream: true})を呼ぶが、ここにタイムアウトが設定されていなかった
1と2にはタイムアウトがあるのに、4のAI要約ステップだけ青天井だった。しかもストリームの監視機構（stream watchdog）自体は存在していたものの、CLAUDE_ENABLE_STREAM_WATCHDOG=1という環境変数を明示的に設定しないと有効にならない、デフォルトオフの機能だったらしい。
これが厄介だったポイントで、「取得自体は速いのに、その後の要約処理でどれだけ待たされるか誰も保証していない」という構造だった。パイプライン全体を通したタイムアウトが存在しない以上、個々のステップにタイムアウトを足しても、抜け穴になっている区間が残っていれば同じ症状が別の形で再発する。1月から4月にかけて複数のIssueが「一旦closeされては再発する」を繰り返していたのは、この構造的な問題が根本的には残ったままだったからだと考えると筋が通る。
v2.1.268で何が変わったか — パイプライン全体に300秒の上限がついた
2026年9月10日リリースのv2.1.268で、公式のCHANGELOGにはこう書かれている。
Fixed WebFetch hanging indefinitely on a server that keeps the response open without finishing; a fetch now fails after 300 seconds. Set
CLAUDE_CODE_WEBFETCH_DEADLINE_MSto override the deadline (0 turns it off)
ポイントは「個別ステップのタイムアウトを積み増した」のではなく、パイプライン全体に300秒という上限を新設したところ。ドメインチェック・HTTP取得・Markdown変換・AI要約のどこで詰まっていても、開始から300秒経てば強制的に失敗として扱われるようになった。これで「どこかの区間にタイムアウトが漏れている」という構造的な弱点そのものが塞がれた形になる。
同じv2.1.268では、WebFetchに関連する修正がもう一つ入っている。ANTHROPIC_BASE_URLを使ったサードパーティ互換エンドポイント経由で毎ターンHTTP 400エラーになる、というv2.1.265のリグレッションも同時に直っている。プロキシ経由でClaude Codeを使っている場合は、こちらの影響も受けていた可能性がある。
CLAUDE_CODE_WEBFETCH_DEADLINE_MSの使い方
新しく使えるようになった環境変数はこれ一つ。ミリ秒単位で、WebFetch1回あたりの上限時間を指定する。
# デフォルトの300秒(300000ms)より短くして、遅い取得を早めに諦めさせる
export CLAUDE_CODE_WEBFETCH_DEADLINE_MS=60000
# 大きめのドキュメントや反応の遅いサイトを扱うので伸ばしたい場合
export CLAUDE_CODE_WEBFETCH_DEADLINE_MS=600000
# タイムアウト自体を無効化する(公式は非推奨、検証用途向け)
export CLAUDE_CODE_WEBFETCH_DEADLINE_MS=0自分の運用だと、SEOの競合分析でGoogle検索結果の上位ページを何本もWebFetchで読みに行く場面が多くて、たまに反応の重いサイトに当たる。そういう用途なら、デフォルトの300秒のままにしておいて、CI的にバッチで大量のURLを流すような用途なら短めに設定して早く失敗させたほうが、ハングして待ち続けるより結果的に早く終わる。.claude/settings.jsonのenvブロックに書いておけばプロジェクト単位で固定できる。
0にしてタイムアウトを無効化する設定は、あくまで挙動を切り分けたいときの一時的な検証用と考えたほうがいい。普段使いで常時0にしておくと、今回直った問題にまた自分から戻ることになる。
まだ直っていない・古いバージョンを使っている場合の回避策
社内ポリシーやプロジェクトの都合でバージョンをすぐに上げられない場合や、アップデート後もまれに長時間の取得で引っかかる場合の回避策も並べておく。
1. バージョンを確認して、上げられるならv2.1.268以降に上げるclaude --version
claude update一番確実なのはこれ。個別のワークアラウンドを積むより、修正が入ったバージョンに上げるほうが早い。
2. どうしても上げられないなら、WebFetchを経由しないルートに逃がすcurlやwgetをBashツール経由で直接叩けば、Claude Code側のWebFetchパイプラインを通らない。
curl -sL --max-time 30 "https://example.com/docs" -o /tmp/fetched.htmlMCPのfetch系サーバー（mcp-server-fetchなど）を導入して、そちらをMCP経由で使う手もある。WebFetch内蔵のAI要約ステップを経由しない分、今回の不具合の影響も受けない。
反応が重いことが分かっているサイトなら、先にブラウザで開いてページ保存し、保存したファイルをClaude CodeのReadツールで読ませたほうが速い。WebFetchのAI要約ステップ自体を丸ごとバイパスできる。
Claude Codeの「固まる」は他にも原因がある
今回扱ったのはWebFetch固有の不具合だけど、Claude Code全体が無言になる・応答がズレる・生ログを吐き出すといった「フリーズ」はもっと広い原因で起きる。コンテキストの使いすぎによる崩壊はまったく別の話なので、症状が似ていても切り分けて考えたほうがいい。
バージョン確認・アップデート手順
# 現在のバージョンを確認
claude --version
# 最新版に更新
claude update
# 更新後、変更点が反映されているか確認
claude --versionclaude updateが動かない場合は、パッケージマネージャ経由のインストール方法によって手順が変わるので、公式ドキュメントの該当ページを確認するのが早い。
FAQ
v2.1.268より前のバージョンだと、今回の修正は入っていない?
入っていない。CLAUDE_CODE_WEBFETCH_DEADLINE_MS自体もv2.1.268で新設された環境変数なので、それより前のバージョンでは設定しても効果がない。claude --versionで確認して、古ければclaude updateで上げる必要がある。
WebFetchが403エラーになるのは今回の話と関係ある?
別の問題。403はドメインの安全性チェックやアクセス権限の話で、今回直ったのは「応答が返ってこないまま無期限に待ち続けてしまう」というタイムアウト周りの不具合。403系のエラーメッセージが出ている場合は、そもそも通信自体は成立しているので、対象ドメインの許可設定やアクセス権限を見直すほうが早い。
CLAUDE_CODE_WEBFETCH_DEADLINE_MSを短くしすぎるとどうなる?
正常に取得できるはずのサイトでもタイムアウトで失敗するようになる。反応が遅めのドキュメントサイトを日常的に触るなら、デフォルトの300秒のままにしておくのが無難。バッチ処理やCIで大量のURLを機械的に流すときだけ短く設定する、くらいの使い分けでいい。
今回の修正で、WebFetchの要約内容が変な問題も直った?
いや、それは別の問題。今回直ったのはあくまで「無期限に固まる」というタイムアウトの話で、AIによる要約が不正確・情報が欠落するという話とは原因が別になる。要約の精度に不満がある場合は、信頼済みドメインの活用や、ブラウザで保存してから読ませる方法のほうが効果がある。
WebFetchが固まって数十分単位で待たされる経験は、日常的にClaude Codeでリサーチする人ほど踏みやすい落とし穴だったと思う。半年越しでようやく構造的に塞がれた形なので、まだ古いバージョンのまま使っている人はこれを機にアップデートしておくのがいい。
