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

ZDR契約でweb_searchを使うときの結論

ZDR(Zero Data Retention)の契約下で web_search_20260209 以降を使うなら、ツール定義に "allowed_callers": ["direct"] を書きます。書かなければ既定でdynamic filtering側が動き、ZDR対象外の構成になります。web_search_20250305 のままなら、dynamic filteringが存在しないので何も要りません。

dynamic filteringは、Claudeが検索結果をそのままコンテキストウィンドウへ読み込まず、コードを書いて実行して絞り込む仕組みです。関連する部分だけが渡されるので、検索の多いリクエストほどトークン消費を抑えられます。Claude 4.6以降のモデルとClaude Mythos Previewで使えます。

バージョンごとに何が変わるか

既定が変わった結果、リクエストに code_execution ツールを自分で足さなくても、dynamic filteringが動くたびにAPI側が必要なコード実行環境を用意します。この分の追加課金はなく、コストは通常のトークン課金に収まります。

既定のままだとエラーにならずZDRの外へ出る

怖いのは、何も起きないことです。公式のデータ保持ページによると、ZDR対象外(表で「No」)の機能を使ってもAPIはリクエストを止めません。使えば、その機能のデータ保持ポリシーに従ってZDRの外へ出る選択になります。

HIPAA対応の準備契約では扱いが逆です。「No」の機能を含むリクエストはAPIが400で止めるのが原則で、ZDRのように黙って通ることはありません。web_searchの行には、dynamic filteringがZDRにもHIPAAにも対象外と明記されています。

web_searchの基本版は、ZDRもHIPAAも対象です。web_fetchは、基本版でもHIPAAは対象外で、ZDRだけが対象です。

ZDRの「Yes」は、30日保持が必要になるモデル(Covered Models)を使わないことも前提です。ツール側を direct に直しても、モデル側の条件は別に見る必要があります。

なぜ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.

コード実行ツールのページには、コンテナーのデータ(実行成果物・アップロードしたファイル・出力)を最大30日間保持すると書かれています。データ保持ページでも、コード実行は「No」です。

Advanced Tool Useで扱うプログラム的なツール呼び出し(Programmatic Tool Calling)も、同じコード実行コンテナーの上で動くためZDR対象外です。コード実行を挟む機能は、同じ理由でZDRの外に出ます。

ツール自体をZDR契約下で使っていても、既定のままでは _20260209 以降の構成はZDR適格になりません。

directとcode_executionで何が分かれるか

allowed_callers は ["direct", "code_execution_20260120"] のように両方を並べても書けます。ZDR適格として示されているのは ["direct"] 単独の指定だけなので、code_execution系の値を残した構成はZDR対象として扱わないのが安全です。

ZDRを維持するには何を書くか

ツール定義に allowed_callers を明示します。

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

この設定は呼び出しを直接のものに限り、内部のコード実行ステップを迂回します。

プログラム的なツール呼び出しに対応しないモデルでは、そもそもこの指定が必須です。書かずに送ると、APIは allowed_callers を設定するよう求める400エラーを返します。ZDRのためでもモデルの都合でも、書く値は同じ ["direct"] です。

自分の構成を確かめる手順

web_fetchには別の注意点もあります。ZDR適格な構成で使っても、取得先サイトの運営者がURLに渡したパラメーターを保持する場合があります。これはAnthropic側のZDR設定とは独立した、取得先の挙動です。

レスポンスで経路を見分ける

設定が効いているかは、返ってきたレスポンスで確かめられます。directで走った検索は、server_tool_use と web_search_tool_result のブロックが応答の最上位に並ぶだけです。

dynamic filteringで走った検索では、応答にコード実行ツールの結果ブロックが加わります。入れ子になった server_tool_use と web_search_tool_result の組には caller フィールドが付き、どのコード実行の呼び出しが検索を行ったかを示します。

ZDR契約下のテスト環境で direct を指定したのに、コード実行のブロックや caller が応答に出てくるなら、意図しない経路が動いています。

response_inclusion の excluded が省くのは、コード実行が完了した呼び出しの検索結果だけです。directの呼び出し結果は、excluded にしても常に全量が返ります。コード実行が途中で一時停止した呼び出しの結果は、次のターンで送り返すために常に全量で返ります。

directに戻すとトークン削減を手放す

検索を多用するリクエストほど、direct ではトークン消費が絞り込みなしの水準に戻ります。

web_searchの料金は、1,000検索あたり10ドルと、検索結果由来のコンテンツ分の標準トークン課金です。allowed_callers の値で変わるのは後者の量だけで、検索の単価は変わりません。

差が大きく出るのは、検索回数の多いリクエストです。そうした用途をZDR契約下で direct 固定にするなら、絞り込まれない検索結果がそのまま積み上がる前提でコストを見積もります。

web_fetchでは影響がさらに分かりやすく出ます。dynamic filteringは長い文書から特定の節を抜き出す、ウェブページの構造化データを処理する、PDFから必要な情報だけを拾うといった用途で効くとされています。direct に固定すると、取得した文書やPDFの全文がそのままコンテキストに入ります。web_fetchのdynamic filteringもコード実行ツール上で動き、tools に自分で足す必要はありません。付け外しの判断はweb_searchと同じく allowed_callers だけです。

max_uses で、1リクエストあたりの検索回数に上限をかける方法もあります。上限を超えると、web_search_tool_result が max_uses_exceeded のエラーになります。

組織のZDRとツール単位の設定は別のレイヤー

allowed_callers はツール1つごとの設定です。Claude Zero Data Retentionが有効になる契約形態は、組織単位で決まります。Claude for Enterpriseでの個別有効化か、コンシューマー以外のAPIキー利用のいずれかです。

この条件を満たす組織でも、web_search_20260209 以降を既定のまま使えば、そのツール構成はZDR適格になりません。組織でZDRが有効なことと、個々のツール呼び出しが適格な経路を通っていることは、別々に確かめる事実です。

SDKヘルパーを使っていても設定は同じ

web_searchはサーバーツールなので、実行はAPI側で完結し、tool_result を返す必要はありません。アプリ側で扱うのは pause_turn での継続リクエストくらいです。Tool RunnerのようなSDKヘルパーを使っていても、allowed_callers はツール定義のフィールドなので、同じ設定が効きます。

クライアントツールであるBashツールを自前実装するときと同じく、web_searchでも既定のまま使うこと自体が設計判断になります。

まとめ

ZDR契約下では、_20260209 以降のweb_searchとweb_fetchに allowed_callers: ["direct"] を付けるかどうかが分かれ目です。付け忘れてもエラーにならないので、確認はリクエストを送る前の定義側で行います。引き換えにトークン削減は手放します。組織のZDRが有効でも、ツール単位の設定は別に確かめます。