2026年4月23日、Anthropicは公式エンジニアリングブログに「An update on recent Claude Code quality reports」というポストモーテムを公開しました。ここ1か月ほど「Claudeの応答が悪くなった」という報告が続いていましたが、調べた結果、原因は別々に入った3つの変更だったと説明しています。影響が出たのはClaude Code、Claude Agent SDK、Claude Coworkで、APIには影響がなかったとのことです。本記事では、元記事に書かれている事実だけを使って、何が起きたか、なぜ見つけにくかったか、利用者は何を確認すべきかを整理します。
何が起きたのか
元記事では、3つの変更が次のように説明されています。
- 3月4日：推論エフォートの既定値をhighからmediumに変更
highモードで考える時間が長くなりすぎ、UIが固まったように見えることがあったため、その対策として行われました。4月7日に元に戻されています。影響を受けたのはSonnet 4.6とOpus 4.6です。 - 3月26日：1時間以上放置したセッションの古いthinkingを消す変更
再開時の遅延を減らすのが狙いでした。ところがバグのため、消去が1回で終わらず、そのセッションが終わるまで毎ターン実行されていました。4月10日（v2.1.101）に修正されています。影響を受けたのはSonnet 4.6とOpus 4.6です。 - 4月16日：冗長さを抑えるシステムプロンプト指示の追加
ほかのプロンプト変更と組み合わさったことでコーディング品質が下がり、4月20日に元に戻されました。影響を受けたのはSonnet 4.6、Opus 4.6、Opus 4.7です。
3件とも4月20日（v2.1.116）の時点で解決済みです。また、4月23日付ですべてのサブスクライバーの使用量上限がリセットされました。
Because each change affected a different slice of traffic on a different schedule, the aggregate effect looked like broad, inconsistent degradation.
（訳：変更ごとに影響を受けるトラフィックも時期も違ったため、全体としては、広い範囲でばらばらに品質が落ちているように見えた）
なぜ起きたか／何が問題か
エフォート変更の判断ミス：社内のevalでは、mediumはhighより知能がわずかに落ちる代わりに、多くのタスクで遅延が大きく減るという結果でした。そこでmediumを既定値にしましたが、ユーザーからは「賢くなくなった」という声が上がりました。Anthropicは、起動時の通知、インラインのエフォート選択UI、ultrathinkの復活といった改善を重ねましたが、ほとんどのユーザーはmediumのまま使い続けていました。元記事はこの判断を「wrong tradeoff（誤ったトレードオフ）」と認めています。現在の既定値は、Opus 4.7がxhigh、それ以外のモデルがhighです。
キャッシュ最適化のバグ：放置されたセッションはどうせキャッシュミスになるので、古いthinkingを削って送るトークンを減らす、という設計でした。実装には clear_thinking_20251015 というAPIヘッダーと keep:1 が使われています。しかし一度でもアイドルの閾値を超えると、それ以降のリクエストはすべて「直近の推論ブロック以外を捨てる」動きになりました。ツール実行中に追加のメッセージを送ると、そのターン自体の推論まで消えていたそうです。元記事では、物忘れ、同じことの繰り返し、不自然なツール選択がこのバグで説明できるとしています。さらに、キャッシュミスが続いたことが「使用量上限の減りが速い」という別の報告の原因だったと考えている、とも書かれています。
The changes it introduced made it past multiple human and automated code reviews, as well as unit tests, end-to-end tests, automated verification, and dogfooding.
再現も困難でした。社内限定のメッセージキューイング関連の実験と、thinkingの表示方法の変更という、無関係な2つの変更のせいで、ほとんどのCLIセッションではこのバグが表に出ませんでした。根本原因の特定には1週間以上かかっています。調査の一環として、問題のPRに対してOpus 4.7でCode Reviewをやり直したところ、全体の文脈を集めるのに必要なリポジトリを渡した場合はバグを発見できました。Opus 4.6では見つけられなかったそうです。再発防止策として、コードレビューに追加のリポジトリを文脈として渡せるようにする対応を進めています。
冗長さ対策のプロンプト：元記事によると、Opus 4.7は前のモデルより冗長になりやすく、難しい問題には強い一方で出力トークンが増える傾向があります。それを抑える指示が、コーディング品質を下げる方向に働きました。ただし、取得できた原文はこの節の途中で終わっており、詳しい経緯はここでは確認できていません。
読者がどう守るか
- バージョンを確認する：3件とも解決済みとされているのはv2.1.116です。それより古いバージョンを使っている場合は更新を検討してください。
- エフォート設定を自分で把握する：既定値は製品側の判断で変わることがあります。
/effortで今の設定を確認し、タスクの重さに合わせて選んでください。 - 「なんとなく劣化」は具体的に記録する：今回の劣化は、最初は普段の評価のばらつきと見分けにくかったと書かれています。どのモデルで、どんな症状が、いつから出たかを残しておけば、報告や切り分けに使えます。
- 自分でエージェントを作る場合：放置後の再開のような、めったに通らない経路やプロンプトの小さな変更でも品質は落ちえます。これは元記事から直接言える教訓です。
まとめ
- 品質低下の原因は、エフォート既定値の変更、thinkingを消すバグ、冗長さ対策のプロンプトという3つの別々の変更で、APIには影響がなかった。
- 3件は4月20日（v2.1.116）までに解決し、全サブスクライバーの使用量上限がリセットされた。
- 何重ものレビューとテストをすり抜けたバグがあったことから、めったに通らない経路の検証が難しいことがわかる。
実装家視点で言うと、一番効いたのは「人のレビュー、自動レビュー、ユニットテスト、E2E、dogfoodingを全部通ったのに漏れた」という部分です。アイドル判定のような状態フラグは、一度立ったらどこで下ろすかまで決めておかないと、普段はまず通らない経路で静かに壊れます。エージェントのコンテキスト管理を自分で書く人ほど、きれいな経路だけでなく「放置してから再開する」「途中で割り込む」といった場面もevalに入れておくべきだと感じました。
コメント