web_searchのdynamic filteringがZDR対象外になる仕組み

web_searchのdynamic filteringとは何か

Anthropic APIのweb_searchツールは、通常の使い方では検索結果をそのままClaudeのコンテキストウィンドウに読み込みます。検索対象のページが長いほど、関係のない部分まで丸ごとトークンとして消費されます。web_search_20260209 以降のバージョンはここにdynamic filteringという仕組みを追加しました。Claudeが検索結果をそのまま受け取るのではなく、コードを書いて実行し、結果を先に絞り込んでから関連する部分だけをコンテキストへ渡します。検索が多いリクエストほどトークン消費を抑えられる設計です。dynamic filteringはClaude 4.6以降のモデルとClaude Mythos Previewで利用でき、web_search_20260318 はここに response_inclusion によるエージェント向けの応答制御を追加しています。

この判断が必要になるのは web_search_20260209 以降にアップグレードする実装だけです。web_search_20250305 のような基本版のままであれば、dynamic filtering自体が存在しないため、allowed_callers を気にする必要はなくZDR対象のままです。ZDRとdynamic filteringのどちらを取るかという選択は、バージョンを上げた時点で初めて発生する判断であり、既存の実装をそのまま使い続ける限りは関係ありません。

allowed_callersの既定値が変わった理由

dynamic filteringは内部的にコード実行ツールを経由して動きます。この呼び出し経路を制御しているのが allowed_callers フィールドです。web_search_20260209 より前のバージョンではこのフィールドは既定で ["direct"]、つまりClaudeが直接web_searchを呼ぶだけでした。web_search_20260209 以降は既定値が ["code_execution_20260120"] に変わり、リクエストに code_execution ツールを自分で追加しなくても、dynamic filteringが動くたびにAPI側が必要なコード実行環境を自動でプロビジョニングします。この自動プロビジョニング分の追加課金は無く、コストは通常のトークン課金の範囲に収まります。

dynamic filteringがZDR対象外になる理由

ここが実装者が見落としやすい点です。基本版の web_search_20250305 と web_fetch_20250910 はZero Data Retention(ZDR)の対象になりますが、_20260209 以降のdynamic filtering対応バージョンは既定でZDR対象外になります。理由は明快で、dynamic filteringが内部でコード実行に依存しているためです。公式ドキュメントは次のように明記しています。

The _20260209 and later versions with dynamic filtering are not ZDR-eligible by default because dynamic filtering relies on code execution internally.

ZDRは「Anthropicがプロンプトと生成結果を応答後に保存しない」契約上の設定です。公式ドキュメントが示す理由はdynamic filteringが内部でコード実行に依存していることのみで、それ以上の機序は説明されていません。ツール自体をZDR契約下で使っていても、既定のままでは_20260209以降のツール構成自体がZDR適格でなくなります。

ZDRを維持するにはdirectに戻す

ZDR契約下でdynamic filteringを使わずweb_searchだけを使いたい場合は、allowed_callers を明示的に ["direct"] に設定します。

{
  "type": "web_search_20260209",
  "name": "Web Search",
  "allowed_callers": ["direct"]
}

この設定は「直接呼び出しのみに制限し、内部のコード実行ステップを迂回する」という効果を持ちます。プログラム的なツール呼び出しに対応していないモデルでは、そもそもこの設定が必須です。指定しないままリクエストを送ると、APIは allowed_callers を設定するよう求める400エラーを返します。ZDRを理由に direct を選ぶ場合と、モデルの対応状況を理由に direct を選ぶ場合とでは動機が異なりますが、設定するフィールドと値はどちらも同じです。

allowed_callers は ["direct", "code_execution_20260120"] のように両方を並べて指定することもできます。ただし公式ドキュメントがZDR対象の設定として示しているのは allowed_callers: ["direct"] 単独の指定のみです。code_execution系の値を残したままでは、公式が明記する「ZDR適格になる設定」の条件を満たさないため、ZDR対象として扱うべきではないと考えられます。ZDRを取り戻すには、リストからcode_execution系の値を完全に外し ["direct"] だけにする必要があります。

directに戻すとトークン削減効果を失う

allowed_callers: ["direct"] は「ZDRか効率か」の二択そのものです。dynamic filteringを止めると、検索結果は絞り込まれずにそのままコンテキストへ流れ込み、検索を多用するリクエストほどトークン消費が元の水準に戻ります。web_search自体の課金体系(1,000検索あたり10ドルの利用料に加えて、検索結果由来のコンテンツ分の標準トークン課金)は allowed_callers の設定に関係なく変わりません。変わるのは、その標準トークン課金の対象になる検索結果の量です。ZDR組織にとってこれは、コンプライアンス要件を優先するか、検索ヘビーなワークロードのコストを優先するかという明示的なトレードオフになります。

web_fetchも同じ設計を共有する

同じ構造はweb_fetchツールにも当てはまります。基本版の web_fetch_20250910 はZDR対象、_20260209 以降はdynamic filteringに対応する代わりに既定でZDR対象外になり、ZDRを保ちたい場合は同じく allowed_callers: ["direct"] を設定します。web_fetchにはもう1つ別の注意点もあります。ZDR適格な設定で使っていても、Claudeが取得先のサイトからコンテンツを取得する際、そのサイトの運営者がURLに渡されたパラメータを保持する可能性がある点です。これはAnthropic側のZDR設定とは独立した、取得先サイト側の挙動です。

プラットフォームでdynamic filteringが使えない場合

この判断はAnthropicのClaude API、Claude Platform on AWS、Microsoft Foundryのいずれでも同じように発生するわけではありません。Microsoft FoundryのうちAzureホスティングのデプロイは基本版のweb_search(web_search_20250305、dynamic filteringなし)しか対応しておらず、Anthropicホスティングのデプロイはすべてのバージョンに対応します。Google Cloudでは基本版のみが利用でき、Amazon Bedrockではweb_searchツール自体が提供されていません。ZDRとdynamic filteringのトレードオフを検討する前に、そもそも自社の実行環境がdynamic filtering対応バージョンを使えるプラットフォームかどうかを確認しておく必要があります。

なぜAnthropicはコード実行前提の設計を既定にしたか

Advanced Tool Useで扱ったTool Search ToolやProgrammatic Tool Callingと同じく、Anthropicのサーバーツールはコンテキスト圧迫とトークンコストを、コード実行を挟むことで解消する方向に寄っています。web_searchのdynamic filteringもこの流れの一部で、大半のユーザーにとっては「検索結果を賢く絞り込んでコストを下げる」明確な改善です。ZDR対象外という副作用は隠された仕様ではなく、コード実行を内部で使う以上の必然的な帰結であり、公式ドキュメントも理由を明記したうえで direct への戻し方を用意しています。既定値を効率側に振り、ZDRが必要な組織には明示的なオプトアウトを求める設計だと読むのが妥当です。

組織単位のZDR設定とは別の話

ここまでの allowed_callers はツール1つ単位の設定です。Claude Zero Data Retentionが有効になる契約形態自体は、Claude for Enterpriseでの個別有効化か、コンシューマー以外のAPIキー利用のいずれかで組織単位に決まります。この2条件を満たしてZDRが有効な組織であっても、web_search_20260209 以降を既定値のまま使えば、そのツール構成自体がZDR適格でなくなります。組織レベルでZDRが有効なことと、個々のツール呼び出しがZDR適格な経路を通っていることは、別のレイヤーで確認する必要がある事実です。

サーバーツールを直接叩く実装との関係

allowed_callers の値をどちらに振っても、Claudeがサーバーツールを呼び出す往復自体はアプリケーション側で処理する必要がある点は変わりません。この往復を自分で書かずTool RunnerのようなSDKヘルパーに任せている場合も、allowed_callers はツール定義に含めるフィールドなのでヘルパーの有無に関係なく同じ設定が効きます。クライアントツールであるBashツールを自前実装するときと同じく、web_searchのようなサーバーツールでも「デフォルトのまま使う」こと自体が1つの設計判断になっている点は共通しています。

検索量が多いワークロードほど判断の重みが増す

トークン削減効果は検索の呼び出し回数と結果の長さに比例するため、単発の質問応答よりも、比較調査や複数エンティティを横断的に調べるようなリクエストで差が大きくなります。1回のリクエストで数十件の検索を積み重ねるようなユースケースをZDR契約下で direct 固定で運用する場合、絞り込まれない検索結果がそのままコンテキストに積み上がることを前提にコスト試算をしておくと、切り替え後に想定外のトークン消費に気づくことを避けられます。

まとめ

web_search_20260209 以降は、allowed_callers の既定値が ["direct"] から ["code_execution_20260120"] に変わり、dynamic filteringが標準の挙動になりました。この変更はトークンコストを下げる一方で、コード実行を内部で使うためZDRの対象から外れます。ZDR契約下で運用する場合は allowed_callers: ["direct"] を明示し、その代わりにdynamic filteringの効率化は失われることを前提に設計します。web_fetchツールも同じ仕組みを共有しており、_20260209 以降のバージョンでは同じ判断が必要です。