Claude Codeのencrypted_content 400エラー — ゲートウェイ経由の検索履歴が原因

Claude Codeで API Error: 400 ... Invalid encrypted_content in search_result block が出て、同じ会話では何を送っても同じエラーになる。原因は、会話履歴の中にAPIしか復号できないweb検索の結果が残っていることです。Claude Code自身のWebSearchツールは検索結果を平文で記録するので、この種のブロックは、LLMゲートウェイやプロキシが検索を実行した会話にだけ混ざります。

v2.1.282以降は、Claude Codeが該当ブロックを外して自動で1回やり直すため、多くの場合エラー自体が表に出ません。出続けるときの直し方は末尾の切り分けにまとめました。

4つの文言は何が違うのか

同じ節にまとまっている文言は4つあります。どれもHTTP 400で、APIが「復号できない暗号化フィールドがある」と返したときの表現です。

最後の encrypted_stdout だけは扱いが違います。ホスト型のコード実行プログラムが検索結果を読んで出した出力も、APIは暗号化して返します。この文言には回復処理がなく、メッセージがそのまま画面に届きます。

なぜAPIは履歴の再送を拒否するのか

APIのホスト型web検索ツールが返す結果には、encrypted_content という暗号化フィールドが付きます。引用には encrypted_index が付きます。複数ターンの会話では、アシスタントのブロックを受け取ったとおりに送り返す決まりです。encrypted_content が欠けていたり書き換わっていたりすると、400の検証エラーになります。

APIはこの暗号化内容を次のターンで復号し、検索結果をClaudeの文脈へ戻しています。つまり暗号文は、APIだけが読める「預かり証」のようなものです。復号できない内容は、たとえば別の組織向けに作られたものを含め、再送されても受け付けません。

この仕組みが、エラーの出方に2つの特徴を与えます。

• 1回起きると、同じ履歴を送る限りすべてのターンで失敗する
• /compact も同じ履歴を送るので、圧縮で逃げられない

Claude Code自身のWebSearchでは起きにくい

Claude CodeのWebSearchツールは、Anthropicのweb検索バックエンドに問い合わせ、結果のタイトルとURLを返します。検索結果のページ本文は取らず、読むときはWebFetchに引き継ぎます。会話には結果を平文で記録するため、暗号化フィールドは履歴に残りません。

では暗号化ブロックはどこから来るのか。エラー一覧のページが挙げる入口は、ホスト型のweb検索をゲートウェイやプロキシ側で実行した会話です。たとえば、社内のLLMゲートウェイが ANTHROPIC_BASE_URL の向こうで検索を代行し、その応答をAnthropic形式で返すと、暗号化された検索ブロックがセッションに入ります。

• ゲートウェイが検索を実行した応答が履歴に入る
• その後、別の経路や別の組織の鍵でその履歴が送られる
• APIが復号できず、400で拒否する

ゲートウェイの接続設定や、転送すべきヘッダーとフィールドの全体像は、Claude CodeをLLMゲートウェイに接続する方法とLLMゲートウェイの互換性に整理しています。

v2.1.282で何が変わったか

変更履歴には、同じ版の項目として「サードパーティのゲートウェイ経由のターンなど、APIが復号できないweb検索結果が履歴にある会話で、すべてのリクエストが400で失敗していたのを修正した」という趣旨の記載があります。

注意したいのは、回復の対象が「3つのweb検索文言」に限られる点です。コード実行の出力に付く encrypted_stdout は、やり直しの対象外です。このため、v2.1.282以降でもこの文言だけは画面に出ます。

直し方の切り分け

最初に版を確かめます。

claude --version
claude update

/clear した後の新しい会話でも再発するなら、原因は保存された履歴ではなく、リクエストの経路にあります。

/rewind は、プロンプトの単位で会話とコードを戻すコマンドです。会話だけを戻す選択肢があり、コードの変更を残したまま履歴だけ前の時点へ戻せます。コード側の復元の制限は、checkpointの制限にまとめています。

ゲートウェイ経由なら運用者に何を伝えるか

ゲートウェイを運用している側の視点では、疑うべき点は次の2つです。エラー一覧のページに載っているのは1つ目で、2つ目は検索ブロックの受け渡し規則からの推論です。

• ゲートウェイが、ホスト型web検索を自分で実行していないか
• 検索結果のブロックを、受け取ったとおりに次のターンへ戻しているか(APIは、書き換えられた encrypted_content を400で拒否します)

ゲートウェイが検索を代行する構成だと、検索結果のブロックは別の経路で作られたものになります。結果をAnthropicに送り返す先と、作った先が一致しないことが、復号に失敗する典型的な形です。

また、直接APIに接続して切り分けたくても、管理設定で allowedProviders に ["customEndpoint"] を指定している環境では、Claude Codeが別宛先への接続を拒否します。この設定はv2.1.285以降で使えます。切り分けは、管理者に一時的な除外を相談する形になります。

似たエラーとの区別

履歴に残ったツール内容が原因で毎ターン失敗する400は、ほかにもあります。見分けるポイントは文言です。

後者は、別のプロバイダーの応答を翻訳するプロキシ経由のセッションを再開したときに出ます。ツールの呼び出しと結果を送り返したことが原因で、暗号化フィールドは関係しません。

関連して、保存済みのセッションを読み込むときの挙動も押さえておくと混乱しません。Anthropic APIへ直接接続しているセッションでは、Claude Codeが読み込みやプレビューの時点で、APIが受け付けないツール内容を取り除きます。取り除いた場所には [Unsupported tool content removed] という行が残り(詳しくはこちら)、何もしなくてもセッションは続きます。一方、プロキシ経由や別のプロバイダー上のセッションでは、保存された履歴をそのまま読み込みます。

検索まわりのエラーコードそのものは、APIが返すエラー形式が別なので、web_searchのエラーコード一覧で確かめられます。WebSearchの回数上限に当たった場合の挙動は、WebSearchの上限を変える環境変数に書いています。

よくある質問

検索を使っていないのに出るのはなぜですか

履歴に検索ブロックが残っているかどうかが条件で、いまのターンで検索したかどうかは関係ありません。過去のターンでゲートウェイが検索を実行していた場合、あとから別の話題で話しかけても、履歴ごと再送されて拒否されます。

まとめ

• 原因は、APIが復号できないホスト型web検索のブロックが履歴に入っていること
• Claude Code自身のWebSearchは平文で記録するため、混入元はゲートウェイやプロキシの検索であることが多い
• v2.1.282以降は、3つのweb検索文言を自動で除いて再送する。encrypted_stdout だけは自動回復がない
• 出続けるときは claude update、それでも出るなら /rewind か /clear、ゲートウェイ経由なら運用者に報告する