「Unsupported tool content removed」とは — Claude Codeの再開時の表示
Claude Codeのセッション再開時に出る[Unsupported tool content removed]の意味と、除去される条件を扱います。プロキシ経由では除去されない点と、v2.1.246より前の400エラーも説明します。
保存済みのセッションを開いたとき、thinkingブロックの間に [Unsupported tool content removed] という1行が挟まっていることがあります。これはエラーではなく、Anthropic APIが受け付けないツール内容をClaude Codeが取り除いた跡です。表示だけなら対処は要りません。気をつけるのは、この除去が働かない古いバージョンと、プロキシ経由の接続です。
「Unsupported tool content removed」は何を示す行か
Claude Codeは、Anthropic APIへ直接つないでセッションを読み込むかプレビューするとき、APIが受け付けないツール内容を履歴から取り除きます。取り除いた場所がふたつのthinkingブロックの間だった場合、次の1行が代わりに残ります。
[Unsupported tool content removed]この行は履歴の見た目に残るだけの印です。セッションはそのまま続けられ、除去された内容を戻す操作もありません。
除去が働く条件と働かない条件
除去は接続先によって変わります。ドキュメントの記述を表にまとめます。
| 接続のしかた | v2.1.246以降 | v2.1.246より前 |
|---|---|---|
| Anthropic APIへ直接接続 | v2.1.246以降受け付けない内容を除去し、プレースホルダー行を残す | v2.1.246より前除去せず、ツール使用とその結果をAPIへ送り返す |
| プロキシ経由、または他のプロバイダー | v2.1.246以降保存された履歴をそのまま読み込む | v2.1.246より前除去せず、そのまま送る |
プロキシを通すセッションでは除去が働かない点がこの表の要点です。プロキシや他のプロバイダーの経路では、履歴に残ったツール内容をそのまま扱う設計になっています。つまりこの行が出るのは、除去が働く直接接続で履歴を開いたときだけです。同じ履歴でも、プロキシを通して開いている間は除去されないので、行は現れません。
受け付けない内容がセッションに残る経路
このツール内容がセッションファイルに入るのは、Anthropic API以外の何かがAPIの形式で応答したときです。典型例は ANTHROPIC_BASE_URL で指定したサードパーティのプロキシで、他のプロバイダーのツール呼び出しをAPI形式に変換して返す構成を指します。変換後の応答はAnthropic APIの形式をしていますが、中身はAnthropic APIが生成したものではありません。
この履歴をあとで直接接続のセッションに持ち込むと、APIは未知のツール内容を拒否します。たとえば ANTHROPIC_BASE_URL を外したシェルから --resume で開く、といった場面です。
v2.1.246より前は再開のたびに400になった
v2.1.246より前のClaude Codeは、該当するツール使用とその結果をAPIへ送り返していました。再開したセッションは毎ターン400で失敗し、メッセージは次のような形でした。
messages.1.content.0.server_tool_use.name: Input should be 'web_search', 'web_fetch', ...v2.1.246(2026年8月25日)のchangelogには、「保存された履歴にAnthropic APIが受け付けないツールブロックが含まれると、再開したセッションが毎ターン400で失敗する問題を修正」とあります。ブロックは、典型的にはサードパーティのAPIプロキシが書き込んだものとされています。修正後は、失敗する代わりに除去と1行の印で済むようになりました。
画面に出たときの確認手順
見かけたときは、まず次の3点を確認します。
この行を見かけたときの確認
- 1
毎ターン400になっていないか見る
プレースホルダー行だけで会話が進むなら、対処は不要です。
- 2
バージョンを確認する
400が毎ターン出るなら、v2.1.246より前の可能性があります。
- 3
更新して再開する
claude updateのあと、同じセッションを再開します。
claude --version
claude update更新後も同じセッションで失敗する場合は、会話履歴の別の食い違いが疑われます。復旧の手順はthinking block mismatchエラーの原因とrewindでの直し方にまとめています。
接続先を確かめるには、ANTHROPIC_BASE_URL が設定されているかを見るのが早道です。
echo "${ANTHROPIC_BASE_URL:-未設定}"値が空でなければ、そのシェルで起動したClaude Codeはプロキシやゲートウェイを通っています。ゲートウェイ用の認証情報を設定せずにこの変数だけを置いた場合も、リクエストはゲートウェイを通ります。ただし保存済みのclaude.aiログインが有効な認証情報のままなので、その利用上限と課金が適用されます。この変数の役割はANTHROPIC_BASE_URLの設定で扱っています。
同じ400系に見える別のエラーとの切り分け
プロキシが絡む再開エラーは、文言の違いで原因が分かれます。errorsページにある隣り合う項目を並べます。
| 表示の手がかり | 原因の筋 | 現行バージョンでの動き |
|---|---|---|
server_tool_use.name: Input should be が毎ターン | 原因の筋受け付けないツール内容が履歴に残っている | 現行バージョンでの動きv2.1.246以降は直接接続で除去し、1行の印を残す |
Invalid data in redacted_thinking block | 原因の筋以前のターンが持つ redacted_thinking ブロックをAPIが受け付けない | 現行バージョンでの動きv2.1.282以降は以前のthinkingを外して1回再試行する |
Invalid encrypted_content in search_result block など | 原因の筋プロキシが実行した検索の暗号化内容を、APIが復号できない | 現行バージョンでの動きv2.1.282以降は検索の呼び出し・結果・引用を外して1回再試行する |
Invalid encrypted_stdout in encrypted_code_execution_result block | 原因の筋コード実行の出力が暗号化されていて、APIが復号できない | 現行バージョンでの動き自動の回復はなく、エラーがそのまま表示される |
role 'system' must precede an 'assistant' message | 原因の筋プロキシが独自のシステムメッセージを挟んだ | 現行バージョンでの動きClaude Code自身が送った分はv2.1.280以降で再試行される。プロキシが挟んだ分は残る |
どの項目も、プロキシやゲートウェイを通す構成で起きやすい点は共通です。ただし回復のしかたは違います。redacted_thinkingと検索の暗号化内容のエラーは、v2.1.282より前は毎ターン失敗し続け、検索側は /compact も失敗しました。今回の行は、エラーになる前に履歴側で取り除く点が異なります。検索の暗号化内容がセッションに入る経路も別です。Claude Code自身のWebSearchツールは検索結果をプレーンテキストで記録するため、この型のブロックは、プロキシやゲートウェイがホスト型のWeb検索を自分で実行した場合に入り込むのが通常です。
更新しても直らないときの操作
claude update で済むのは、バージョンが古いことが原因の場合です。更新後もエラーが続く場合の逃げ道は、エラーごとに違います。
encrypted_stdoutの文言:/rewindで、その内容が加わったターンより前のチェックポイントまで戻るか、/clearで内容を持たない新しい会話を始めますrole 'system'の文言をプロキシ越しに繰り返す場合: プロキシを外して直接つなぎ、原因の場所を確かめます。/clearで新しい会話にしても出るなら、原因は保存された会話ではなくリクエストの経路にあります- 再開自体が
Failed to resume the conversation.で終わる場合: 保存された会話を読み込めていません。メッセージに出るコマンドでclaude --resume <セッションID>を再実行します。v2.1.285より前では、読めないエントリを含む会話の再開が同じ形で失敗するため、更新してからやり直します。なお、動作中のセッション内の/resumeから開いて失敗した場合は、終了せずに会話の中へFailed to resume conversationと表示され、いま使っているセッションはそのまま続きます
[Unsupported tool content removed] の行は、この中のどれにも当たりません。エラーではなく、再開に成功した結果として画面に残る印です。
プロキシを運用する側が押さえること
LLMゲートウェイの仕様ページによると、Claude Codeは ANTHROPIC_BASE_URL のゲートウェイをAnthropic形式のエンドポイントとして扱います。Anthropic APIへ送る内容に近いものがそのまま届く前提です。
ゲートウェイがリクエスト本文を書き換えたり、上流の別形式へそのまま転送したりすると、400が出る条件が増えます。同ページの自動再試行の節によると、再試行の判定は上流のエラー文言との照合で行われるため、エラー本文は書き換えずに返す必要があります。上流のエラーを独自の封筒で包むと、ステータスコードを保っても回復の経路が壊れます。
再試行の対象は、拒否された内容によって分かれます。thinkingフィールドや会話途中のシステムメッセージが拒否されたときは、その機能を会話の残りの間オフにして再試行します。thinkingの署名が拒否されたときは、以前のthinkingブロックを外して再試行します。一方、context managementやツールスキーマのフィールドの拒否は再試行されず、400がそのまま利用者に届きます。
BedrockやGoogle Cloudのエージェント基盤のような別形式の上流へ、Anthropic形式の本文をそのまま転送すると、Extra inputs are not permitted を含む400が出ます。ヘッダーと本文のフィールドは対で送られるため、片方だけ落とすと起きる型です。
エラーが繰り返されるとき、errorsページはプロキシを外して直接つなぎ、原因の場所を切り分けるよう案内しています。そのうえで運営者に報告します。
thinkingの署名が bound to a different conversation と拒否される400も、ゲートウェイが原因になりえます。この拒否は、system、tools、以前の messages の内容が、thinkingを生成したリクエストと食い違うと起きます。ゲートウェイがこれらを書き換えると、拒否を自分で引き起こします。ゲートウェイ側の考え方はLLMゲートウェイのプロトコル解説が詳しいです。
エラーが出ない形で崩れる機能もあります。cache_control を落とすゲートウェイでは、会話が毎ターン未キャッシュの入力として課金され、usage に input_tokens が多くキャッシュの動きが少ない形で現れます。count_tokens のエンドポイントを公開していなければ、/context の数値は文字数ベースの概算になります。再開時の400とは別に、こうした静かな劣化も同じゲートウェイが原因になりえます。
ゲートウェイに固定された環境ではどうなるか
管理設定で allowedProviders を ["customEndpoint"] にし、ANTHROPIC_BASE_URL をその設定の env に置くと、Claude Codeはそれ以外の接続先を拒否します(v2.1.285以降)。この構成のセッションは常にゲートウェイ経由なので、除去は働きません。履歴にプロキシ由来の内容が残っていても、そのまま読み込まれます。ANTHROPIC_BEDROCK_BASE_URL のようにプロバイダー固有のエンドポイント変数でゲートウェイにつなぐ場合は、allowedProviders の項目でどの変数を固定するかを指定します。
反対に、同じ履歴を持ち出して個人の環境から直接つなぐと、除去とプレースホルダー行が現れます。環境をまたいでセッションを引き継ぐ運用では、この違いが表示の差として見えます。
まとめ
[Unsupported tool content removed] は警告ではなく、直接接続のときに履歴を整えた記録です。プロキシ経由では除去されず、v2.1.246より前では毎ターン400の原因になりました。毎ターン失敗する場合に限り、claude update で更新してセッションを再開してください。