Sonnet 5.5への更新後にAPIが400を返すときの直し方

モデルIDだけを変えると、それまで動いていたSonnet 5の連携が壊れる場合があります。 Sonnet 5.5では、使えるthinking設定、強制ツール選択、思考履歴の扱い、一部ツールの互換性が変わりました。更新後にHTTP 400が出たら、認証を変更したり同じデータを再送したりする前に、エラー本文と実際の送信内容を確認します。

本記事は2026年9月29日に確認したAnthropicのSonnet 5.5移行ガイドと変更点の資料に基づきます。例は資料に沿ったリクエスト形式であり、Ofoxが実APIですべてのエラーを再現したという主張ではありません。401、429、事業者固有の404は別の調査が必要です。

互換性のない項目を特定する

computer useの行を全事業者に当てはめないでください。同じ公式ページには、Amazon Bedrockは古いcomputer_20251124を受け付けるとあります。対象プラットフォームも修正条件の一部です。

disabled thinkingを置き換える

ツールなしの最小テキストリクエストでは、ネイティブClaude APIのPOST /v1/messages本文を資料に沿って次のように書けます。

{
  "model": "claude-sonnet-5-5",
  "max_tokens": 1024,
  "thinking": {"type": "between_tools"},
  "output_config": {"effort": "high"},
  "messages": [{"role": "user", "content": "Return a one-sentence summary of this task: verify a CSV total."}]
}

本文だけではHTTPクライアントとして完成していません。Messages APIが要求する認証ヘッダーとAPIバージョンヘッダーが必要です。認証情報は自分の環境に置き、コピーする例やログに含めないでください。

between_toolsは冒頭の思考を無効にしますが、すべてのツール処理から思考ブロックが消えるという意味ではありません。ツール間の進捗メモにもそのブロック型が使われる場合があります。対応effortはlow、medium、highで、xhighとmaxには対応しません。displayやbudget_tokensの追加項目も受け付けません。xhighやmaxにはadaptive thinkingを使います。非対応の設定を組み合わせた検証エラーは、再試行では直りません。

強制呼び出しを置き換えても検証は残す

tool_choiceをautoにすると、モデルが呼び出すかどうかを選ぶ動作に変わります。対応するツール定義にstrict: trueを加えると入力の形式を検証できますが、そのツールの選択は強制できません。期待した呼び出しがあったかをアプリ側で確認する必要があります。スキーマ関連の機能もプラットフォーム依存です。移行資料ではAmazon BedrockのSonnet 5.5で、strict tool useを含む構造化出力は利用できないとされています。

抽出サービスなら、そもそもツール呼び出しが必要かを検討しましょう。結果が操作ではなくデータなら、構造化出力が適している場合があります。有効な結果、必須データ欠落、拒否、想定外の自然文応答をテストします。400が消えただけで移行完了とは判断できません。

会話履歴を保つ

Sonnet 5.5の思考ブロックはモデルと会話に紐付きます。以前のシステムプロンプト、ツール定義、メッセージを編集してから後続ブロックを再送すると、紐付けエラーになる場合があります。公式の既定強制は、指定プラットフォームで2026年8月31日00:00 UTC以降に作成されたアカウントに適用されます。古いアカウントと明示的なオプトイン設定は別に確認してください。

最も単純なのは、履歴を追記のみで管理する設計です。返されたブロックは変更せず、会話途中の変更には文書化された仕組みを使います。意図的に履歴を編集するなら、影響するブロックとbeta制御の扱いを移行資料に従ってください。万能な対策として全リクエストから思考ブロックをすべて削除すると、会話を変え、有用な文脈まで失う場合があります。

モデル切り替えには別の規則があります。移行先が読めないブロックを破棄する処理と、編集されたプレフィックスによる紐付けエラーは別です。すべてを「invalid signature」と呼ばず、実際のエラーや変換メタデータを記録します。以前の事例はthinking署名エラーの対処ガイドを参照してください。

成功レスポンスも確認する

HTTPエラーにならない不具合もあります。ツール間の長い進捗メモが思考ブロックに入り、adaptiveの既定表示動作で本文が省略される場合があります。textブロックだけを描画するUIでは、有効なリクエストでも無言に見えます。adaptive thinkingのthinking.display、または対応するbetween_toolsの表示動作を確認してください。

拒否と通信障害も区別します。資料にはHTTP 200でstop_reason: refusalと追加情報を返す場合が説明されています。成功HTTPステータスだけではタスク完了の証明になりません。同じ拒否済みタスクを繰り返し送らず、結果を明示的に処理してください。

Agent のループから切り離して失敗を再現する

本番の連携を変える前に、秘密情報と非公開の入力を除いた失敗リクエストを保存します。endpoint のホスト、モデル ID、SDK のバージョン、HTTP ステータス、エラーの type と message、取得できれば request ID を記録してください。元の応答はローカルに保持します。「400 Bad Request」だけでは、thinking の非互換とメッセージ順序の問題を区別できません。切り分け中はアプリ側の自動再試行を止めます。同じ無効な JSON を繰り返すより、問題の設定を直す必要があります。

上の最小 JSON を request.json として保存し、新しい会話で試します。以下は Anthropic のネイティブ endpoint を呼ぶコマンドで、実行すれば API 使用量が発生します。承認済みのアカウントと、環境に設定済みの ANTHROPIC_API_KEY が前提です。コマンドにキーを直接書いたり、保存した応答を公開したりしないでください。これは診断手順であり、編集部によるモデル実行成功の記録ではありません。

curl --silent --show-error \
  --dump-header response.headers \
  --output response.json \
  --write-out 'HTTP %{http_code}\n' \
  https://api.anthropic.com/v1/messages \
  --header "x-api-key: $ANTHROPIC_API_KEY" \
  --header 'anthropic-version: 2023-06-01' \
  --header 'content-type: application/json' \
  --data-binary @request.json

端末に表示される HTTP ステータスと JSON 本文を別々に確認します。curl の終了コードがゼロでも、HTTP エラーを失敗にするオプションがなければ転送が完了しただけです。API が受理したとは限りません。最小構成が成功したら、元の system prompt、ツール、履歴を一組ずつ戻します。初めて失敗する追加部分が分かれば、モデルと SDK とツール定義を一度に変更するより原因を絞れます。

最小構成でも 400 になる場合は、実際にシリアライズされた JSON を比較します。アプリの設定から thinking.type: disabled、手動 token budget、強制 tool choice を削除しても、SDK のラッパーが再挿入する場合があります。設定オブジェクトだけでなく送信本文を見る必要があります。ゲートウェイ経由では、そのネイティブ API 互換仕様も確認し、全フィールドがそのまま転送されると仮定しないでください。

リクエストと応答パーサーを一緒に修正する

変更前後の確認には、JSON の有効性だけでなく動作の差も含めます。

経費登録アプリなら、文章に「保存しました」とあるだけでレコードを作ってはいけません。許可した tool_use の名前を確認し、入力と必要な業務上の承認を検証します。結果を返すときは assistant content を保持し、該当する tool-use ID に対応付けます。複数の呼び出しがある場合、すべての結果を最後の呼び出しに結び付けず、個別に対応させます。

auto ではツールを呼ばない応答も正常に扱う必要があります。未完了であることをユーザーに示すか、不足情報を求めます。tool_choice: any に戻して再試行すると同じ非互換が再発します。対応プラットフォームで strict: true を使っても、入力形式を制約するだけで、金額、受取人、日付の正しさまでは証明しません。schema 検証後も業務検証が必要です。

新しい会話と履歴の問題を分ける

system 指示 A で成功した会話で、A を B に編集した後、A の下で生成された署名付き thinking を再送するケースを考えます。文書化された binding 規則では、その thinking は新しい会話の前半に対応しません。max_tokens を増やしても直りません。古い block を再利用しない新しい会話で同じ課題を試し、成功すれば token 上限ではなく履歴の変更を調べます。

元の会話は変更しない記録として保持します。代わりの署名を作ったり、別アカウントの thinking をコピーしたりしないでください。意図的な履歴編集では、影響を受ける block と対応する制御について公式の移行手順を実装します。診断のための新規会話を、そのまま全ユーザーの文脈を黙って捨てる本番処理にしてはいけません。追記だけの会話と、実際のアプリが行う履歴編集をそれぞれテストします。

モデル切り替えも別の試験です。読めない block は破棄されて 200 が返る場合がありますが、binding 違反では失敗する場合があります。「リクエスト失敗」と「履歴の扱いが変わった成功」をログで区別してください。再開した課題と新規の課題は、表示されるユーザーメッセージが同じでも文脈まで同じとは限りません。

本番切り替え前に応答の受け入れ条件を定める

最小のテキスト例では、HTTP 成功、利用できるテキスト、適切な終了理由、入力に合う要約が必要です。ツール処理では名前、schema、結果の対応付け、最終的な業務完了も確認します。max_tokens による終了は上限到達です。途中までの JSON や指示を完成品として扱わないでください。拒否も独立した結果であり、一時的な通信障害と同じ自動再試行経路には入れません。

新規テキスト、有効なツール動作、ツールを呼ばない応答、追記だけの 2 ターン目、意図的に変更した履歴の前半、複数 block 型を含むパーサー用 fixture の 6 件を用意します。最後の fixture は合成 JSON でローカル実行でき、検証対象は自作パーサーです。Sonnet の動作試験ではありません。まずローカルで確認し、承認済み入力による小規模なオンライン試験で旧版と新版を比べます。

HTTP エラー率が改善しても、無効な業務操作や必要な文脈の消失があればロールバックします。受け入れ完了までは旧リクエストアダプターと新アダプターを区別して保持してください。リクエストと業務結果の両方が条件を満たして初めて移行完了です。

本番切り替え前の検証

全体の展開手順はアップグレード判断ガイド、CLIのモデル選択はClaude Code設定ガイドを参照できます。本記事はネイティブAPIの変更を扱います。第三者ゲートウェイには独自の変換やエラーがある場合があります。