2026-06-11 の Claude API 更新で、エージェント型ワークフローのトークン・コンテキスト効率に効く 2 つの変更が入りました。web search / web fetch に web_search_20260318 / web_fetch_20260318 が追加され、response_inclusion パラメータで「消費済みの検索結果ブロックを応答から落とす」制御ができるようになりました。同時に code execution に code_execution_20260521 が入り、1 セル 90 秒の実行時間制限がツール説明に明示されて、Claude が長時間セルを予算化できるようになっています。いずれも ベータヘッダ不要。本記事では、この 2 つを「エージェントの Web 検索を軽くする部品」として実装目線で整理します。
到達点
- agentic な Web 検索がなぜトークンを食うのかを、課金の仕組みから理解する
- dynamic filtering(code execution が検索結果を絞る)との関係を押さえる
response_inclusion: "excluded"が効く条件と効かない条件を正確に区別するcode_execution_20260521の 90 秒/セル制限の明示が実務に与える影響- 3 つの部品(dynamic filtering / response_inclusion / 90 秒予算)の組み合わせ方
まず「なぜ重いのか」から
Web 検索は トークン集約的なタスクです。Claude は検索結果をコンテキストに取り込み、複数サイトの HTML を読み、それらを推論してから答えに至ります。ここでコストが二重に乗ります。
| コスト | 内訳 |
|---|---|
| 検索回数課金 | Web 検索は $10 / 1,000 検索。結果数に関係なく 1 検索 = 1 カウント |
| トークン課金 | 取り込んだ検索結果は input トークンとして計上され、同一ターン内の検索反復でも、後続のターンでも繰り返し乗る |
特に効くのが 2 つめです。マルチターンのエージェントでは、過去ターンで取り込んだ検索結果が会話履歴として input トークンに乗り続ける。検索を多用するエージェントほど、履歴の肥大がそのままコストとレイテンシに跳ね返ります。
補足:Web 検索の citation フィールド(
cited_text/title/url)は input/output トークンに計上されません。重いのは引用そのものではなく、取り込んだ検索結果の本体です。ここを削るのが今回のテーマです。
前提:dynamic filtering(code execution での絞り込み)
今回の response_inclusion を理解するには、先に dynamic filtering を押さえる必要があります。これは web_search_20260209 以降で使える仕組みで、Claude が検索結果をコンテキストに載せる前に、code execution でコードを書いて後処理(絞り込み)するというものです。
- 生の HTML を全部読んで推論する代わりに、関連部分だけ残して捨てる
- これにより精度が上がり、同時にトークン消費が減る
- 技術文書の検索・文献レビュー・引用検証・回答の根拠付けで特に効く
ポイントは、dynamic filtering は code execution ツールが有効でないと動かないこと。逆に言えば、web search / web fetch と一緒に使う code execution は無料(標準の input/output トークン課金のみ)です。つまり「検索結果を code execution で絞る」構成は、課金面のペナルティなしに組めます。
response_inclusion — 消費済みブロックを応答から落とす
ここからが 2026-06-11 の新機能です。web_search_20260318(および web_fetch_20260318)以降で response_inclusion が使えます。
{
"tools": [
{
"type": "web_search_20260318",
"name": "web_search",
"response_inclusion": "excluded" // 既定は "full"
}
]
}これは、同一ターン内で「完了した code execution 呼び出し」に消費された検索結果ブロックが、API 応答にどう現れるかを制御します。
| 値 | 挙動 |
|---|---|
"full"(既定) | 消費済みでも、ネストした server_tool_use と結果ブロックのペアを応答にそのまま含める |
"excluded" | それらのペアを応答から丸ごと落とす。生の検索内容をクライアントに返す必要がないエージェントのoutput トークンを削減 |
つまり「Claude が code execution で絞り込んで使い終わった検索結果を、わざわざクライアントにエコーバックしない」ための設定です。検索結果の生データを UI に出さず、最終回答だけ使うエージェントでは、これが出力トークンの無駄を直接削ります。
excluded が効かないケース(重要)
excluded は何でも消すわけではありません。次の 2 つは常に full で返ります。
- 直接呼び出しの結果(code execution を経由せず、そのまま使われた検索結果)
- 完了せず pause した code execution 呼び出しの結果
理由は明確で、これらは次のターンに送り返す必要があるから。マルチターンのサーバツール・ループでは、pause_turn で中断した呼び出しの結果やまだ使われていない結果を、こちらが次のリクエストで戻してやらないと会話が続きません。excluded はあくまで 「同一ターンで完結し、消費し終わったもの」だけを対象にします。
ここを誤解すると「
excludedにしたのに結果が返ってくる」と混乱します。“消し残し” はバグではなく仕様で、「次ターンに必要だから残している」と理解するのが正解です。
code_execution_20260521 — 90 秒/セルの明示
もう一方の更新が code execution です。code_execution_20260521 は ランタイムとしては code_execution_20260120 と同じで、違いは 「1 セルあたりの実行時間制限がツール説明に明示された」 点です。
- 各セルは 90 秒の wall-clock 制限
- 超過したコードは
detection_timeoutの結果を返す - 制限がツール説明に書かれたことで、Claude 自身が長時間セルを分割・予算化できるようになった
地味な変更に見えますが、エージェントの失敗の質が変わります。これまでは「重い処理を 1 セルに詰め込んで 90 秒に当たり、こけてから対処」だったのが、最初から 90 秒に収まる粒度でセルを割る判断を Claude ができる。dynamic filtering のように「検索結果を code execution で処理する」構成では、重い後処理を分割して投げることでタイムアウト由来の取りこぼしが減ります。
| 観点 | 従来(制限が暗黙) | code_execution_20260521(明示) |
|---|---|---|
| 長時間処理 | 90 秒に当たって detection_timeout | 事前にセルを分割して回避しやすい |
| エラー対処 | こけてからリトライ | 予算内に収める設計が前面に |
| 失敗の見え方 | 突然のタイムアウト | 想定内のコスト管理 |
3 つの部品をどう組むか
エージェント型 Web 検索を軽く・安定して回すなら、今回の更新は次のように噛み合います。
- 検索結果は code execution で絞る(dynamic filtering) —
web_search_20260209以降 + code execution 有効化。生 HTML をコンテキストに載せない。 - 使い終わった結果は応答から落とす(
response_inclusion: "excluded") —web_search_20260318以降。生データを UI に返さないエージェントの output トークンを削減。 - 重い後処理は 90 秒に収める(
code_execution_20260521) — Claude がセルを予算化できる版を使い、タイムアウト取りこぼしを減らす。
この 3 つは独立した設定ですが、「検索 → code execution で絞る → 結果は履歴に残さない」という 1 本の流れに乗ります。検索ヘビーなエージェントほど、3 点セットの効果が積み上がります。
注意点
- バージョン指定が前提:
response_inclusionはweb_search_20260318/web_fetch_20260318以降、90 秒明示はcode_execution_20260521が必要です。typeの日付バージョンを上げないと有効になりません。ベータヘッダは不要です。 excludedは “同一ターン・完了・消費済み” 限定:直接呼び出しや pause した呼び出しの結果は常に full。次ターンに送り返す責務はこちら側に残ります。- モデル対応を確認:dynamic filtering や新ツールバージョンは対応モデルが決まっています(Fable 5 / Opus 4.8 / Sonnet 4.6 など)。古いモデルにそのまま載せ替えると効きません。
- プラットフォーム差:web search の提供範囲はプラットフォームで差があります(例:dynamic filtering は Vertex AI では基本検索のみ、Bedrock では web search 非対応)。本番の実行先に合わせて確認を。
- ZDR 非対象:code execution は Zero Data Retention の対象外です。データ保持要件が厳しい用途では、この構成自体が使えるかを先に確認してください。
まとめ
2026-06-11 の更新は、「エージェントの Web 検索を軽くする」一点に効きます。response_inclusion: "excluded"(web_search_20260318+)で使い終わった検索結果を応答から落とし、code_execution_20260521 の 90 秒/セル明示で重い後処理を予算内に収める。どちらも既存の dynamic filtering(検索結果を code execution で絞る)と組み合わせて初めて本領を発揮します。
実装の勘所は 3 つ — 検索結果はコンテキストに載せる前に絞る、使い終わったら履歴に残さない、重い処理は 90 秒に割る。検索ヘビーなエージェントを運用しているなら、type のバージョンを上げ、response_inclusion を excluded にするだけで、出力トークンと履歴肥大の両方に効きます。ベータヘッダ不要で踏み込めるので、まず検証環境で前後のトークン差を測ってみるのがおすすめです。