response_inclusionは、検索結果をモデルが同一ターン内でコード実行へ渡して消費した後、APIクライアントへ返す最終レスポンスからその結果ブロックを落とすための設定である。大規模調査では出力トークンを減らせるが、クライアント側が結果ブロックを監査証跡や次ターンの文脈として使っている場合は互換性を失う。
何が変わったか
web_search_20260318とweb_fetch_20260318でresponse_inclusionを指定し、消費済みの検索・取得結果ブロックを応答から除外できるようになった
| 項目 | 内容 |
|---|---|
| 対象 | Claude API |
| API・機能 | Web Search,Web Fetch |
| 変更種別 | API変更 |
| 重要度 | 高 |
| 対応期限 | 期限なし |
変更前後の差
従来は検索・取得結果と、それを利用したコード実行・最終回答が応答へ含まれやすかった。新バージョンではfull相当の保持と、消費済み結果を除外する構成を選択できる。除外は同じターンで完了済みの結果を対象とし、検索そのものを省略する機能ではない。
誰に影響するか
調査Agent、競合分析、法規制確認、Webデータの集計、コード実行で多数ページを処理する処理に影響する。レスポンス全体をそのまま永続化して再現や引用に利用しているシステムは、除外前に保存責任を再設計する必要がある。
期限
強制移行期限はない。新しいツールバージョンを明示して段階導入でき、beta headerも不要である。
必要な対応
最終回答に必要な引用メタデータと、内部監査に必要な原文証跡を分ける。除外した結果を後から必要とする場合は、検索URL、取得日時、ハッシュ、保存先をアプリケーション側で記録する。個人情報やライセンス上保存できない本文を無条件で保管してはいけない。
実装・移行手順
- 既存レスポンスから参照している結果ブロックを洗い出す
- 同じ質問をfullと除外設定で実行する
- 入力・出力トークン、応答サイズ、レイテンシーを比較する
- 引用URLと引用箇所が欠落しないか確認する
- 会話再開・再試行・人手監査を再現する
- 証跡保存を必要最小限のメタデータへ分離する
失敗しやすい点
トークン削減だけを見て引用元を失う、除外後も完全な再現が可能と考える、同一ターンで消費されていない結果まで消えると誤解する、保存禁止情報を別DBへ無制限に複製することが問題になる。
リスク
監査証跡不足、引用の検証不能、会話再開時の文脈欠落、保存ストレージへの機密情報集中が主なリスクである。
評価方法
- 応答トークン削減率
- APIレスポンス容量
- 引用URL保持率
- 再現試験成功率
- 監査に必要なデータ欠落率
- P95処理時間
ロールバック
ツール設定を従来の保持方式へ戻す。除外方式で生成した会話は結果ブロックを復元できないため、切替前に会話形式のバージョンを記録し、新旧を混在させない。
編集部分析
これは単純な圧縮機能ではなく、APIレスポンスを記録媒体として使うか、最終成果物の搬送媒体として使うかを選ぶ設定である。監査性を外部ログへ移せる成熟した基盤ほど効果が大きい。
実務チェックリスト
- [ ] 結果ブロックの利用箇所を棚卸しした
- [ ] 引用完全性を確認した
- [ ] 会話再開を試験した
- [ ] 証跡保存の範囲を定義した
- [ ] 保存禁止データを除外した
- [ ] 旧方式へ戻すFeature Flagがある