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ステータスだけではタスク完了の証明になりません。同じ拒否済みタスクを繰り返し送らず、結果を明示的に処理してください。

本番切り替え前の検証

通常テキスト、ツール呼び出し、複数ターン会話、編集履歴、ストリーミング更新、拒否処理の小さなテストセットを保ちます。リクエスト形式、応答パーサー、ツール結果の対応関係、ユーザーに見える出力を検証し、結果ごとにクライアント版と正確なモデルIDを保存します。調査中は旧連携に戻せる設定を残してください。

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