skipWebFetchPreflightでBedrockのWebFetch確認を外す — Claude Code設定

Amazon Bedrock経由でClaude Codeを使っているのに、WebFetchだけが「Unable to verify if domain ... is safe to fetch」で失敗する。モデルへの通信はBedrockに向いているので、原因はそこではありません。skipWebFetchPreflightは、WebFetchが取得の前に走らせるドメイン安全確認を外す設定キーです。trueにすれば、api.anthropic.comに届かない環境でもWebFetchが動きます。

代わりに、Anthropicのブロックリストとの照合も消えます。外す前に、何が送られ、何が失われるかを押さえておく必要があります。

skipWebFetchPreflightとは何を省く設定か

WebFetchは、URLを取得する前に、そのホスト名をapi.anthropic.comへ送ってAnthropic管理の安全ブロックリストと照合します。送られるのはホスト名だけで、URL全体・パス・ページの中身は含まれません。skipWebFetchPreflightはこの照合を丸ごと省く設定です。

設定の形は次のとおりです。

{
  "skipWebFetchPreflight": true
}

falseを明示した場合も挙動は既定と同じで、確認が走ります。

置き場所の選び方は目的で変わります。自分の端末で試すだけなら.claude/settings.local.json、リポジトリを使う全員に共有するなら.claude/settings.json、組織の端末に一律で配るなら管理設定です。

なぜBedrockを使っていても確認だけAnthropicへ出ていくのか

Bedrock、Agent Platform、Foundry、サインイン済みのClaude apps gatewayでは、モデル通信と認証が各プロバイダーかゲートウェイへ向かいます。api.anthropic.comは経路から外れます。

ところがWebFetchの確認だけは例外です。この確認はモデルプロバイダーに関係なく実行されます。しかもCLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFICでも止まりません。この環境変数はテレメトリやアンケートなど非必須の通信をまとめて落とす用途ですが、WebFetchの確認は対象外です。

プロバイダー別の既定は、公式の一覧では5つの利用形態すべてで同じです。

テレメトリやエラー報告はこれらのプロバイダーで既定オフです。WebFetchの確認とアンケートは例外としてオンで動く点が、閉域網では見落としやすい部分です。ネットワーク全体の設計はClaude Codeはオフライン環境で使えるかで、許可すべきホストと合わせて扱っています。

設定を入れる前に症状で切り分ける

確認の失敗は、取得前のエラーとしてツール結果に現れます。公式のエラー一覧にあるメッセージは2種類です。

• Unable to verify if domain example.com is safe to fetch: 確認の通信が失敗、タイムアウト、またはその他のステータスを返した。ネットワークがapi.anthropic.comを遮断している典型例
• The safety check for domain example.com is rate-limited: 確認エンドポイントがHTTP 429を返した。同じネットワークからの確認が多すぎる場合に出る

前者は到達性の問題、後者は混み具合の問題です。解決策が違います。遮断が原因ならapi.anthropic.comの許可か本設定、429が頻発するなら本設定が選択肢になります。429のメッセージは、ループで再試行せず、そのページを諦めて報告するようモデルに指示する文面です。失敗した確認はキャッシュされないため、次の取得で改めて確認が走ります。

v2.1.285より前は、429もUnable to verifyとして報告されていました。v2.1.286より前の429メッセージは、1分ほど待って再試行するよう促す別の文面でした。古いバージョンのログと突き合わせるときは、この差に注意が要ります。

確認を外す代わりに許可リストで済ませる手もある

外す以外に、api.anthropic.comをプロキシや境界の許可リストに入れる道があります。この場合、確認は生きたままなので、ブロックリストによる保護が残ります。

Bedrock利用でegressを絞る理由が「Anthropicのホストへ一切出さない」という方針なら、許可リストの選択肢は最初から使えません。その場合に本設定が実質の唯一の手段になります。

外した後に残る穴と、権限ルールでの埋め方

確認を外すと、WebFetchはブロックリストを参照せずにあらゆるURLの取得を試みます。公式は、取得先を絞りたい場合はWebFetchの権限ルールと併用するよう書いています。

管理設定で、Bedrock環境の全端末に次のような組み合わせを配る形が考えられます。公式の例ではなく、ルールの書式に沿った例示です。ドメインは自社に合わせて置き換えます。

{
  "skipWebFetchPreflight": true,
  "permissions": {
    "allow": [
      "WebFetch(domain:docs.example.com)",
      "WebFetch(domain:*.internal.example.com)"
    ]
  }
}

ここでの考え方は、確認を外したぶんの歯止めをルールで取り戻すことです。ドメイン指定はdomain:の後にホスト名を書き、*.で始まるワイルドカードはサブドメインに一致しますが、親ドメイン自体には一致しません。許可に載せたドメインは確認なしで取得でき、載っていないドメインはManualとacceptEditsモードでは取得のたびにプロンプトが出ます。autoとbypassPermissionsでは原則プロンプトが出ないため、これらのモードを使う環境では明示的なdenyやaskのルールが必要です。ルールの優先関係や、組み込みの事前承認ドメインとの兼ね合いはWebFetch権限ルールにまとめてあります。

配布前に手元で、許可したドメインが通り、それ以外が想定どおり止まる(または確認される)ことを確かめてください。

管理設定で配布し、利用者に上書きさせたくない場合は許可ルールを管理設定だけに限る設定が関わります。

確認が実際に外れたかを確かめる

設定したつもりでも、別のファイルに書いたままだったということがあります。置き場所は4種類のどのファイルでもよいので、まず書いた場所を洗い出します。

grep -rn skipWebFetchPreflight \
  ~/.claude/settings.json \
  .claude/settings.json \
  .claude/settings.local.json

その後、Claude CodeでWebFetchを一度走らせます。Unable to verifyが消え、通常の取得結果が返れば確認が外れています。同じ失敗が続く場合は、確認以外の原因です。WebFetchのキャッシュ、ダウンロードの期限、リダイレクトの扱いはWebFetchのキャッシュとタイムアウトが詳しく、症状ごとの切り分けに使えます。

api.anthropic.comへの通信はこの設定だけでは消えない

skipWebFetchPreflightが止めるのはWebFetchの確認だけです。api.anthropic.comは、Claude APIの呼び出し、機能フラグの取得、テレメトリのイベント送信にも使われると、ネットワーク設定のページに載っています。

Bedrockなどを使う構成では、このうちモデル呼び出しはプロバイダーへ向かい、テレメトリは既定でオフです。それでも残る通信を洗い出す作業は、設定一つでは終わりません。たとえばLLMゲートウェイ経由の構成では、fast modeの利用可否チェックがANTHROPIC_BASE_URLではなくapi.anthropic.comを呼びます。WebFetchの確認とは別物なので、skipWebFetchPreflightでは消えません。

egressを全面的に閉じる運用では、WebFetchの確認、非必須通信、fast modeの可否チェックを別々に扱う必要があります。WebFetchの確認の止め方がこの記事の設定で、非必須通信はCLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFICの領分です。

確認の頻度はドキュメントで食い違っている

公式の記述には、確認がいつ走るかについて二つの書き方があります。

• 設定リファレンス: セッション内の各ホスト名への最初の取得の前に走り、過去の確認がブロックまたは失敗したホストでは再度走る
• データ利用のページ: 通ったホスト名を5分間キャッシュし、ブロックされたホストや失敗したホストは次のリクエストで再確認する

「セッション中ずっと1回」か「5分ごと」かは、これだけでは決められません。確認が通ってしまえば後は静かだと見込んで許可リストを細く設計すると、長いセッションでは再び通信が出る可能性があります。確認を外すか許可するかを決める際は、遮断環境での失敗が一度きりでなく繰り返す前提で考えるのが安全です。

向く環境と向かない環境

向くのは、Anthropicのホストへ出られず、取得先を権限ルールで管理できる環境です。Bedrock、Agent Platform、Foundryのegressを閉じている組織が典型です。

向かないのは、api.anthropic.comを許可できるのに、ブロックリストの保護を捨ててしまう場合です。個人の開発機では、ホスト名の送信を避けたい理由がなければ既定のままで困りません。

ゲートウェイ経由の構成で、さらに通信を絞るときはClaude apps gatewayの脅威モデルが、残る通信の洗い出しに役立ちます。サービスティアなど別の観点でBedrock側の設定を整えるなら、Bedrockサービスティアも参照してください。

まとめ

skipWebFetchPreflight: trueで消えるのは、ホスト名だけを送る安全確認と、その結果に基づくブロックリスト照合です。api.anthropic.comを許可できるなら許可が穏当で、出せないなら本設定とWebFetchの権限ルールを組み合わせます。ルールなしで外すと、取得先の歯止めがなくなります。