0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Claude Sonnet 5で400エラーになる3つの指定:2026年7月のLLM移行チェックリスト(Opus 4.7 fast mode退役・GPT-5.6の新しい「努力度」制御)

0
Posted at

Abstract gradient illustration of branching model-migration paths

2026年6月30日、AnthropicはClaude Sonnet 5(claude-sonnet-5)を公開した。「Sonnet 4.6のドロップイン後継」と案内されているが、リクエストの書き方によっては移行直後に 400 エラーになる挙動変更が3つある。さらに同じ7月のウィンドウで、Opus 4.7の fast mode が7月24日に退役し、OpenAIは GPT-5.6(Sol / Terra / Luna)で「推論の努力度」と「サブエージェント並列(ultra mode)」という新しい制御軸を出してきた。

この記事は、本番でLLM APIを叩いているエンジニア向けに「2026年7月に実際に直す箇所」を一次情報ベースで整理したものだ。共通する流れは1つ——選ぶ対象が「どのモデルか」から「どのモデル × どの思考/速度/並列度か」へ移っている。

結論

確認項目 ニュースの含意 7月に直すこと
temperature / top_p / top_k の指定 Sonnet 5では非デフォルト値が 400 既定値に戻すか送らない。挙動はシステムプロンプトで誘導
thinking: {type: "enabled", budget_tokens: N} Sonnet 5で削除され 400 thinking: {type: "adaptive"}effort パラメータへ
max_tokens の値 Sonnet 5は adaptive thinking が既定ON+新トークナイザで約30%増 出力長ギリギリの上限を見直し、トークンを測り直す
Opus 4.7 の speed: "fast" 2026-07-24に削除(モデル本体は標準速度で存続) fast modeはOpus 4.8へ移行
「速いモデルが欲しい」要件 推論は努力度・並列度で制御する時代に effort/fast/サブエージェントをコストと合わせて設計

Claude Sonnet 5:6月30日公開、移行で壊れる3つの指定

確認できる事実

Anthropicの公式リリースノートおよびモデル解説ページより、claude-sonnet-5 は2026年6月30日に公開された。仕様は1Mトークンのコンテキスト(既定かつ最大)、最大出力128kトークン、Priority Tierは非対応。価格は標準で入力 $3 / 出力 $15(per MTok、Sonnet 4.6と同額)で、2026年8月31日までは導入価格 $2 / $10 が適用される。

公式は「Sonnet 4.6のドロップイン後継」としつつ、3つの挙動変更を明記している。

  • adaptive thinking が既定でON。 Sonnet 4.6では thinking 未指定なら思考なしで動いたが、Sonnet 5では同じリクエストが adaptive thinking で動く。オフにするには thinking: {type: "disabled"} を渡す。
  • サンプリングパラメータが非対応。 temperature / top_p / top_k を非デフォルト値にすると 400 エラー。原文では次のように説明されている。

原文: "Setting temperature, top_p, or top_k to a non-default value returns a 400 error."
日本語訳: 「temperaturetop_ptop_k を非デフォルト値に設定すると 400 エラーを返す」(Anthropic「What's new in Claude Sonnet 5」)

  • 手動の extended thinking が削除。 thinking: {type: "enabled", budget_tokens: N}400 になる。代わりに adaptive thinking と effort パラメータを使う。

加えてトークナイザが新しくなり、同じテキストでも約30%多くトークンが出る。これはAPIの形(リクエスト/レスポンス/ストリーミング)は変えないが、usage のトークン数・コンテキストに収まる文章量・max_tokens の実効・1リクエストの実コストに効いてくる。また、Sonnet系で初めてリアルタイムのサイバーセキュリティ・セーフガードが入り、拒否は 400 ではなく stop_reason: "refusal" を持つ HTTP 200 で返る点も挙動として押さえておきたい。

実務解釈

「ドロップイン」という言葉に引きずられてモデルIDだけ差し替えると、temperature を固定しているコードや、budget_tokens で思考量を制御していたエージェントが移行直後に落ちる。どちらも「400 で即死」なので、ステージングでまず叩けば検知はしやすい——逆に言えば、検証なしで本番のモデルIDだけ切り替えるのが一番危ない。

地味に効くのが新トークナイザだ。価格はトークン単価が同じでも、同じ入力で約30%トークンが増えるため、コストとコンテキスト消費は実質的に変わる。過去にSonnet 4.6で測った見積もりは再利用せず、token countingで測り直すのが安全だ。max_tokens を「想定出力ぴったり」に詰めている場合は、思考分(adaptive thinking)と増えたトークンで途中切れする可能性がある。

Opus 4.7 の fast mode は2026年7月24日に退役

確認できる事実

公式ドキュメント(Fast mode)によると、fast mode は対応Opusモデルで出力スループット(OTPS)を最大2.5倍にする research preview の機能で、speed: "fast" と beta ヘッダ fast-mode-2026-02-01 でオプトインする。対応はOpus 4.8とOpus 4.7のみ。

そのOpus 4.7の fast mode が 2026年6月25日に非推奨化、2026年7月24日に削除される。削除後は claude-opus-4-7speed: "fast" を送るとエラーになる。Opus 4.6のように標準速度へフォールバックはしない(モデル本体は標準速度で存続)。継続利用にはOpus 4.8への移行が案内されている。fast modeの価格は次の通り。

モデル 入力 出力
Claude Opus 4.8 $10 / MTok $50 / MTok
Claude Opus 4.7 $30 / MTok $150 / MTok

なお fast mode は Batch API・Priority Tier とは併用できず、専用のレート制限を持ち、超過時は 429retry-after 付き)を返す。

実務解釈

Opus 4.7で speed: "fast" を使っているなら、7月24日が実質の期限だ。フォールバックしない仕様なので、放置すると当日から該当リクエストが落ちる。移行先のOpus 4.8は fast mode 価格が $10/$50 とOpus 4.7($30/$150)より安く、移行はコスト面でも妥当だ。

設計上の注意は2つ。1つはキャッシュ——fast と standard でプロンプトキャッシュのプレフィックスを共有しないため、速度を切り替えるとキャッシュミスになる。もう1つは fast mode が標準速度へ自動フォールバックしないこと。レート上限超過時は 429/529 で返るので、待つのか標準速度で再送するのかを呼び出し側で決めておく必要がある。

OpenAI GPT-5.6:推論の「努力度」と「並列度(ultra mode)」という制御軸

確認できる事実

OpenAIは2026年6月、GPT-5.6として Sol(フラッグシップ)/ Terra(日常向けバランス)/ Luna(高速・低コスト) の3モデルをプレビュー公開した。当初は約20の組織に限定提供され、一般提供は数週間後を予定とされている(OpenAI公式「Previewing GPT-5.6 Sol」、およびVentureBeat等の報道)。

開発者向けに新しいのは2つの制御だ。1つは max reasoning effort——Sol により長く「考える時間」を与え、待ってでも精度を取りたい難問向けの新しい努力度。もう1つは ultra mode——単一エージェントを超えてサブエージェントを並列に走らせ、複雑なタスクを分割して加速するモード。

実務解釈

ここで重要なのは個別のスコアより構図だ。Anthropic側も effort パラメータと fast mode で「思考量」と「速度」を分離してきた。OpenAIの max effort / ultra mode も方向は同じで、「どのモデルを選ぶか」だけでなく「どれだけ考えさせ、どれだけ並列に走らせるか」がコストとレイテンシを左右する設計変数になったということだ。

実務的には、エージェントを組むときに「モデル名を1つ決めて終わり」ではなく、タスクの難易度に応じて努力度(effort / reasoning effort)を上げ下げし、定型・大量処理は低努力+高速、難所だけ高努力+必要なら並列、という出し分けが前提になる。並列(ultra/サブエージェント)は速いがトークン消費が増えるため、コスト見積もりは「1リクエスト」ではなく「1タスクが裏で何回モデルを呼ぶか」で立てる必要がある。

実装チェックリスト

Claude Sonnet 5へ移行する

  • temperature / top_p / top_k の非デフォルト指定を洗い出し、削除またはデフォルトへ戻す
  • thinking: {type: "enabled", budget_tokens: N}thinking: {type: "adaptive"}effort に置き換える
  • 思考なしで動かしたい箇所は thinking: {type: "disabled"} を明示する
  • token countingでプロンプトを測り直し、約30%増を前提に max_tokens とコスト見積もりを更新
  • まずステージングで叩き、400 が出ないことを確認してから本番のモデルIDを切り替える

fast mode(Opus)を点検する

  • claude-opus-4-7speed: "fast" の利用箇所を grep し、7月24日までにOpus 4.8へ移行
  • fast↔standard 切替時のキャッシュミスと、429 時の再送/フォールバック方針を実装

推論の制御軸を設計に入れる

  • エージェントの各ステップを「努力度(低/高)× 速度 × 並列の要否」で分類し、コストと合わせて出し分ける

失敗パターン

  • 「ドロップインだから」とモデルIDだけ差し替える。 Sonnet 5は temperature 固定や budget_tokens 指定が 400 になる。検証なしの一括置換が一番危ない。
  • トークナイザ変更を「価格据え置き」と読み違える。 単価は同じでも同じ入力で約30%トークンが増えるため、実コストとコンテキスト消費は増える。旧モデルで測った見積もりを使い回さない。
  • fast modeが標準速度に落ちると思い込む。 Opus 4.7の fast mode は7月24日以降フォールバックせずエラーになる。Opus 4.6の挙動(標準速度で続行)と混同しない。
  • 拒否レスポンスをエラー扱いする。 Sonnet 5のセーフガードによる拒否は 400 ではなく stop_reason: "refusal" の HTTP 200。例外処理だけ見ていると取りこぼす。
  • ultra(並列)のコストを1リクエスト単価で見積もる。 サブエージェントが裏で複数回モデルを呼ぶ前提で、タスク単位のトークン消費を見積もる。

参考リンク

この記事を書いた人✏️@YushiYamamoto
ITPRODX.com代表 / AIアーキテクト
Next.js / TypeScript / n8nを活用した自律型アーキテクチャ設計を専門としています。
日々の自動化の検証結果や、ビジネス側の視点(ROI等)に関するより深い考察は、以下の公式サイトおよびnoteで発信しています。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?