Claudeの「Invalid signature」：thinking署名のエラーを確認する手順

Claudeがthinkingブロックの署名を無効と判定したら、送り返した構造化された会話を調べます。画面に表示された文字列から再構成せず、元のthinkingブロックと署名を保存してください。エラーが「異なる会話」を明示している場合は、その前にあるシステムプロンプト、ツール、メッセージの変更も確認します。

これらは異なる種類の失敗です。署名の文字列が存在し、変更されていなくても、会話に紐付くブロックが編集後の先行履歴に対して無効になることがあります。本記事は2026年9月14日に確認したthinkingのトラブルシューティング文書に沿ったプロトコルの診断です。すべてのモデルが同じ紐付けルールを適用するという説明ではありません。

履歴を変更する前に、エラーを読む

エラーの種類と全文、リクエストID、モデルID、クライアントのバージョンを残します。最初のリクエストから失敗したのか、ツール呼び出し、会話の復元、履歴編集の後にだけ失敗したのかを確認します。その境目を調べると、状態を失ったり変更したりした処理を絞れます。

非公開の会話履歴や不透明な署名値を、公開issueに貼り付けないでください。通常は、機密情報を除いたブロックの種類と変換処理の説明から始める方が適切です。自分のリクエスト経路を比較する必要があれば、変更していない診断用コピーをローカルに保管します。

assistantのcontent全体を保存する

ネイティブのthinkingブロックにはthinkingの値と、不透明なsignatureが含まれます。redacted_thinkingブロックはdataを使い、通常の表示テキストとして扱ってはいけません。画面に見えるthinkingの文字列が空であることだけでは、ブロックの破損は判断できません。

公式のthinkingとツールの処理ガイドは、これらのブロックがツールターンの継続でどう使われるかを説明しています。assistantの残りの応答とともに、元の値と順序を保ちます。thinkingブロックを要約したり、署名を置き換えたり、画面のテキストだけの履歴からメッセージを再構成したりしないでください。

次のPython断片は、応答を取得した後にcontentを保持する考え方を示しています。完全なリクエストでも、実APIテストでもありません。インストール済みSDKに合わせてシリアライズ部分を調整し、テキストだけでなく返されたcontent全体を保持します。

assistant_content = [block.model_dump(exclude_none=True) for block in response.content]
messages.append({"role": "assistant", "content": assistant_content})
# Append the real tool_result message next, following the native tool protocol.

サンプルリクエストに架空の署名を入れてはいけません。もっともらしい文字列でも、プロバイダーが発行した有効なブロックとは限りません。元のcontentを失ったら、欠けた状態を作り上げず、なぜ失われたのかを調べます。

ストリーミングではテキスト差分だけでは足りない

ストリーミング実装は、対応するcontent-blockイベントを組み立てる必要があります。Messages APIリファレンスには、対応するcontent_block_stopより前に届くsignature_deltaが記載されています。text_deltaや表示されるthinking文字列だけを保存する収集処理では、完全なSDKレスポンスオブジェクトと同じ構造を保持できません。

早い段階の切断、キャンセル、画面の再描画により、組み立て途中のブロックを完了扱いにしていないか確認します。デバッグ時には、ブロックのインデックスとイベント順序を残してください。途中の回答が画面で読めるからといって、未完成のブロックを送り返してはいけません。

公式SDKの対応するストリーム処理を使えば、自前で組み立てる部分を減らせます。ただし、その後アプリケーションが履歴を単純な文字列に変換したり、フィルターで削除したりする場合までは保護しません。メモリ内の応答と、次にシリアライズされたリクエストを比較します。二つのオブジェクト間の変換は、有力な調査箇所です。

会話との紐付けは別に確認する

現在の文書では、Claude Fable 5.1の会話に紐付く署名について、2026年8月31日以降に作成されたアカウント、および文書にある紐付け制御を指定したリクエストに適用するルールを説明しています。これはモデル固有のルールです。異なる会話を明示するエラーでは、ブロック自体を触っていなくても、その前の変更が影響することがあります。システム指示、ツール、先行メッセージの書き換えなどが該当します。

この処理手順では、履歴を追記のみで扱うか、文書にあるサーバー側のコンパクションやコンテキスト編集を利用します。署名を保持しているから大丈夫だと考え、ローカルで履歴全体を書き換えないでください。公式文書にはモデル固有の復旧用制御もありますが、すべてのClaudeリクエストにコピーする汎用設定ではありません。

本記事では、特別な復旧用ベータ機能を最初の対処として勧めていません。まず、選択したモデルとエラーが、その機能の適用範囲に一致するか確認します。ブロックを削除する復旧オプションは保持状態を変える可能性があるため、アプリケーションの設計として判断する必要があります。

モデル変更が必ず無効になるとは限らない

現在のトラブルシューティング文書では、別のモデルが読めないブロックは削除される場合があり、必ず会話の紐付けエラーになるわけではないと説明しています。そのため「モデルを切り替えると必ずthinking署名が壊れる」という説明は広すぎます。プロバイダーをまたぐ経路がすべて本質的に非互換だという主張も同様です。

元のモデル、移行先の経路、エラー全文を記録し、該当する互換性文書を確認します。ネイティブClaudeメッセージと別のAPI形式を変換するクライアントでは、万能なフィールド対応を推測せず、必要なメタデータが保存されているか調べてください。

ツール結果の対応関係は、さらに別の検証項目です。エラーが対応のないツールIDを指しているなら、署名を変えるのではなくtool_result不足のガイドに進みます。Geminiには独自のthought-signatureフィールドがあり、Claudeのネイティブsignatureとは置き換えられません。

よくある質問

署名の値を書き換えれば直せますか？

いいえ。内容を解釈せず保持する、プロバイダー発行の状態として扱います。元の完全なブロックがあれば復元し、変更・破棄した変換処理を調べます。

最初は成功したのに、2回目のリクエストが失敗するのはなぜですか？

継続処理で構造化thinkingデータを失ったか、会話に紐付く先行履歴を変更した可能性があります。表示された文章だけでなく、最初の応答全体と実際の次のリクエストを比較してください。

新しい会話が成功すれば、修正できたと判断できますか？

いいえ。壊れた履歴の影響を切り分けることはできますが、必要なフィールドを削るアダプターは次のツールラウンドで再び失敗する可能性があります。問題を解決済みにする前に、保存から送信までの処理を検証します。