Claude Code v2.1.156 — Opus 4.8の思考ブロックが改変されAPIエラーになる問題を修正

このリリースで何ができるようになるか

Claude Code v2.1.156は、直前のv2.1.154で公開されたOpus 4.8において、思考ブロックがターン間で改変されてしまい結果としてAPIエラーで会話が止まる不具合を、ピンポイントで潰すホットフィックスです。新機能はなく、修正はOpus 4.8の思考ブロックに関する1件のみですが、該当する環境では「Opus 4.8がほぼ使えない」状態からの復旧を意味します。

修正されたのは、Opus 4.8の利用中に拡張思考(Extended Thinking)で生成された思考ブロックがClaude Code側で改変され、次のターンでAPIに送り返した時点でエラーになるという不具合です。Anthropic APIは拡張思考を有効にしたセッションで、過去ターンの思考ブロックを受け取った形のまま次のリクエストに含めて返すよう要求します。この内容が完全一致していないと、APIは整合性検証で失敗を返し、会話は次の応答に進めません。

本版より前のv2.1.154およびv2.1.155(欠番)期間のOpus 4.8では、Claude Code側が思考ブロックに何らかの変更を加えてからAPIに渡していた経路があり、その結果として2ターン目以降に進もうとした瞬間にAPIエラーが返る状態が発生していました。v2.1.156に更新すると、思考ブロックがそのままの形で渡るようになり、Opus 4.8でも長い会話を続けられる状態に戻ります。

なお、この不具合は全ユーザーではなくOpus 4.8を使っているセッションに限定して発生していました。Opus 4.7以前やSonnet系、Haiku系のモデルで運用していた環境では今回の症状を踏んでいないため、本版の差分は体感されません。

あなたの開発フローはどう変わるか

Opus 4.8でAPIエラーに当たっていたチーム

v2.1.154で公開されたOpus 4.8を実際に走らせて、数ターン目で唐突にAPIエラーが返って会話が止まる症状に当たっていた場合は、v2.1.156に更新したうえで新しいセッションを開始するだけで通常運用に戻ります。設定変更や思考オプションの切り替えは不要で、/model claude-opus-4-8で選び直してから普段どおりに使えます。

自分の環境がこの不具合に当たっていたかどうかは、次の3点で切り分けられます。

• claude --versionがv2.1.154である(v2.1.155は欠番のため、番号上の直前はv2.1.154です)
• /modelでOpus 4.8を選択していた
• 2〜3ターン目以降に、Claudeの応答ではなくAPIエラーの形で会話が止まり、エラーメッセージに思考ブロック(thinking)の整合性に関する記述が含まれていた

このうち1つ目と2つ目が当てはまり、かつ会話の中断が応答ではなくAPIエラーの形で起きていたなら、本版が直接効きます。更新後は、同じ作業フローでOpus 4.8を3〜4ターン続けて回し、途中でAPIエラーが返らないことを確認すれば、復旧したと判断できます。

Opus 4.7以前で運用しているチーム

本版で修正された経路はOpus 4.8固有です。Opus 4.7、Sonnet 4.6、Haiku 4.5などで運用しているチームは、本版に更新しても挙動の変化を体感しません。緊急性は低く、Opus 4.8への移行を予定していないなら、次の機能追加版とあわせて更新する選択肢があります。

ただしv2.1.154では、Opus 4.8の登場と同時にleanシステムプロンプト(軽量化されたシステムプロンプト)(Opus 4.7以前を除くモデルでの既定化)、Fast modeのOpus 4.8対応(標準料金の2倍で2.5倍の速度)、/effort xhighの新設、/effortスライダのラベル変更(Faster / Smarter)、動的ワークフロー(/workflows)など、Opus 4.8まわりの新機能がまとまって入っています。Opus 4.8をいずれ試したいチームでは、本版に上げておくことで「最初の動作確認でAPIエラーに当たって戻る」というつまずきを回避できます。

CIやヘッドレス運用でOpus 4.8を呼んでいる環境

CIパイプラインやスクリプトからClaude Codeをヘッドレスで起動して、モデルにOpus 4.8を指定していた運用は、本版の影響を最も強く受ける構成のひとつです。ヘッドレス実行では、対話的なやり直しが効かないため、2ターン目以降のAPIエラーがそのままジョブ失敗として積み上がります。

v2.1.154をCIで固定してOpus 4.8を走らせていた期間は、Opus 4.8を使うジョブが軒並み中断していた可能性があります。本版に更新すれば、以降のジョブではOpus 4.8でも複数ターンの会話を完走できる状態になります。バージョンを固定する運用であれば、固定先をv2.1.156以降に切り替えておくと安全です。Opus 4.8を使わない構成、たとえばSonnet 4.6でCIを回している場合は、今回のリグレッションは踏まないため急いで上げる理由は薄いと言えます。

Opus 4.8の動作確認をこれから始めるチーム

v2.1.154のリリースを受けてOpus 4.8をこれから試そうとしているチームでは、まず本版に上げてから検証を始める選択肢が現実的に効きます。v2.1.154の段階で動作確認を行うと、Opus 4.8側のモデル能力ではなくClaude Code側のリグレッションでAPIエラーに当たり、評価判断にノイズが入ります。本版で素のOpus 4.8の挙動を確認したうえで、必要な/effort設定や/workflows構成の検討に進む流れのほうが、判断材料が整理しやすくなります。

主な変更点

本版の変更は次の1件です。

Opus 4.8で思考ブロックが改変されAPIエラーになる問題を修正

Opus 4.8の利用中に、思考ブロックがClaude Code側で改変されてしまい、結果としてAPIエラーが返っていた問題を修正しました。Anthropic APIは拡張思考を有効にしたセッションで、過去ターンの思考ブロックを受け取った形のまま次のリクエストに含めることを要求します。v2.1.154およびv2.1.155(欠番)期間のClaude Codeでは、Opus 4.8の思考ブロックに対して何らかの変更を加えてからAPIに渡す経路があり、その結果として整合性検証でエラーが返っていました。本版でその経路が修正され、Opus 4.8でも会話を継続できる状態に戻っています。

公式の変更履歴では内部的な原因までは説明されていないため、思考ブロックのどのフィールドが変更されていたのかは明示されていません。Opus 4.8で新たに扱う必要が出たフィールドや、leanシステムプロンプトの既定化と合わせて入った周辺整備のいずれかが、本リグレッションの混入経路と読むのが自然そうです。

Opus 4.8登場から本版までの1日の流れと、思考ブロック整合性検証が示すもの

直近のリリースを並べると次のようになります。

v2.1.154は、Opus 4.8の公開とあわせて/effortスライダのラベル変更や動的ワークフロー(/workflows)、Fast modeのOpus 4.8対応、leanシステムプロンプトの既定化など、v2.1系後半で最大規模の同時変更が入った機能追加版でした。1日の間をおいて本版がOpus 4.8の思考ブロック経路にピンポイントの修正を当てる流れになり、結果としてOpus 4.8の安定運用に必要な版がv2.1.156にずれた格好になります。

このパターンは、過去にも繰り返し観察されてきた構造です。v2.1.147で30件超の整備が入った翌日にBashツールが全コマンドで失敗するリグレッションがv2.1.148で潰され、v2.1.131でWindows + VS Code拡張のリグレッションが直された3日後に再びv2.1.137で同種の症状が修正される、といった例が直近1ヶ月だけでも何度か続いています。広い範囲に手が入った機能追加版の翌日〜数日後に、その一部経路を狙ったホットフィックスが続く、というリリースサイクルが定着しつつあると読めそうです。

なぜ拡張思考(Extended Thinking)の思考ブロックは「完全一致」を要求されるのか

今回のリグレッションが拡張思考(Extended Thinking)に集中している点は、Anthropic APIの設計を踏まえると理解しやすくなります。拡張思考を有効にしたセッションでは、モデルが応答前に内部的な思考過程を生成し、その思考過程がthinkingコンテンツブロックとしてレスポンスに含まれて返ります。アプリケーション側は次のリクエストで、過去ターンのアシスタント応答をそのまま会話履歴として渡すことが求められ、その際に思考ブロックも改変せずに保持して返す必要があります。

この「完全一致での返送」要件は、思考過程の取り扱いに対するAnthropic側の安全策のひとつとして設計されているもので、Claude Code側で文字列の正規化やエンコーディングの調整を行うと、その時点で整合性検証に引っかかります。Opus 4.8のように新しいモデルで思考ブロックのフォーマットや属性が拡張されたとき、その差分を踏んでClaude Code側の経路がブロックを改変してしまう、というのは混入経路として自然な構図です。本版の修正は、Opus 4.8で扱う思考ブロックを過去モデルと同じ「素通し」の経路に揃え直したもの、と読めそうです。

Opus 4.8をいま使い始めるチームへの実務的な意味

Opus 4.8は、v2.1.154でhighエフォート既定+leanシステムプロンプト既定という強めの組み合わせで登場しました。これらの設定はモデルに対して長めの思考過程を生成させる方向に効くため、思考ブロックの分量も従来モデルより増える傾向があります。生成される思考ブロックが増えれば、それが次のリクエストでAPIに送り返される回数も増え、整合性検証の対象になる場面が広がります。今回のリグレッションがOpus 4.8で目立った形で表面化した背景には、こうした「思考ブロックを大量に行き来させる前提のモデル」と、「思考ブロックを素通しで扱う必要があるAPIの仕様」のあいだに、Claude Code側の経路が間に合っていなかった、という構図が見えてきます。

実運用上の含意としては、Opus 4.8のような拡張思考を多用するモデルを採用するときは、思考ブロックの取り扱いに関わるホットフィックスが続く可能性を前提に、固定範囲を狭くしすぎない運用が現実的に効くと言えそうです。v2.1.154を出た当日に本番固定したチームは、ちょうど本版までの1日のずれの分だけリグレッションを踏んだ版に留まることになりました。CIでバージョンを固定している場合は、パッチバージョン単位で広めの範囲を許容し、数日以内のホットフィックスが自動で乗るようにしておくか、claude updateを週次以上の頻度で回しておくと、本版のような単発の修正に長く巻き込まれずに済みます。

まとめ

• Opus 4.8でAPIエラーに当たっていたチーム: 本版に更新し、新しいセッションでOpus 4.8の会話が複数ターン続くことを確認すれば復旧します
• Opus 4.8の動作確認をこれから始めるチーム: 評価判断にClaude Code側のリグレッションが混じらないよう、本版に上げてから検証を始める選択肢が効きます
• CI・ヘッドレス運用でOpus 4.8を使うケース: v2.1.154を固定で使っていた期間のジョブ結果を見直し、固定先をv2.1.156以降に切り替える価値があります
• Opus 4.7以前で運用しているチーム: 急いで更新する理由は薄いものの、Opus 4.8をいずれ試す予定があるなら本版に上げておくと最初のつまずきを避けられます

v2.1.156は新機能を含まないホットフィックスで、本版単独で読み始める価値は限定的です。直前のv2.1.154がOpus 4.8の登場とlean既定化を同時に持ち込んだ機能追加版だったこと、その整合性検証の経路で発生したリグレッションが翌日にピンポイントで潰された、という流れの中に位置付けると、Claude CodeのリリースサイクルとOpus 4.8まわりの調整の方向性が追いやすくなります。