この投稿は、ユーザーが約 1 か月にわたって Claude の応答が悪くなったと報告していた理由と、Anthropic が突き止めた内容についての同社の説明である。中心となる主張は、単一のリグレッションは存在しなかったというものである。3 つの別々の変更が、異なるトラフィックの一部に、異なるスケジュールで適用され、それらの影響が重なり合ったために、全体としては広範で一貫性のない劣化に見えたのだという。3 つとも、4 月 20 日時点でバージョン 2.1.116 において解決済みとされている。
この投稿は、影響範囲と意図について明確に述べている。変更の影響を受けたのは Claude Code、Claude Agent SDK、Claude Cowork であり、API は影響を受けていないとされる。Anthropic は、API と推論レイヤーが影響を受けていないことをすぐに確認したこと、そして意図的にモデルの品質を落とすことは決してないことを述べている。最後のセクションではシステムプロンプトの変更方法に対する管理の強化が説明され、投稿の締めくくりでは、/feedback コマンドで問題を報告したユーザーと、具体的で再現可能な事例をオンラインに投稿したユーザーの双方に謝意を示し、4 月 23 日付ですべてのサブスクライバーの利用上限をリセットすることを告知している。
要点
- 投稿は原因を 1 つではなく 3 つの別々のものとして提示し、単一の広範なリグレッションのように見えたのは、それらが異なるトラフィックの一部とスケジュールで重なり合ったためだとしている。
- 3 月 4 日、UI がフリーズしたように見えることもあった非常に長いレイテンシーに対処するため、Claude Code のデフォルトの推論エフォート（Reasoning Effort）が
highからmediumに引き下げられた。Anthropic はこれを誤ったトレードオフだったとし、ユーザーから、デフォルトは高い知能にしておき、単純なタスクでは自分で下げるほうがよいという声を受けて、4 月 7 日に元に戻した。 - 現在のエフォート設定をわかりやすくするための設計上の改善（起動時の通知、インラインのエフォート選択 UI、ultrathink の復活）は、大半のユーザーを medium のデフォルトから移行させるには至らなかった。Anthropic は、より多くの顧客からのフィードバックを聞いたうえで 4 月 7 日にこの決定を覆したと述べている。
- 3 月 26 日、1 時間以上アイドル状態のセッションから古い推論を一度だけ消去するはずだった最適化が、実際にはセッションの残りの期間中、毎ターン推論を消去してしまった。そのためエージェントは、なぜ今の行動を選んだのかを覚えていないまま行動し続けた。投稿によれば、これは物忘れ、繰り返し、奇妙なツール選択として表面化し、4 月 10 日にバージョン 2.1.101 で修正された。
- 同じバグが、利用上限が想定より早く消費されるという別の報告の原因である可能性が高いとされている。推論ブロックを落とし続けたことで、キャッシュミスも発生していたためである。
- 投稿によれば、このバグは複数の人間および自動のコードレビュー、ユニットテストとエンドツーエンドテスト、自動検証、ドッグフーディングをすり抜け、根本原因の確認には 1 週間以上かかった。当初再現を難しくしたものとして、無関係な 2 つの変更が挙げられている。メッセージキューイングに関する社内限定のサーバーサイド実験と、思考の表示方法に関する直交する変更であり、後者は大半の CLI セッションでこのバグを抑制していたと投稿は述べている。
- Anthropic は、問題のプルリクエストに対して自社の Code Review ツールをバックテストしたと報告している。完全なコンテキストに必要なリポジトリを与えると、Opus 4.6 では見つけられなかったバグを Opus 4.7 は見つけた。これを受けて、コードレビューのコンテキストとして追加のリポジトリを扱えるようにする対応を進めている。
- 4 月 16 日、Opus 4.7 の冗長さを抑えるためのシステムプロンプトの指示が、同モデルとともに出荷された。ツール呼び出し間のテキストを 25 語、最終応答を 100 語に制限するもので、後者には、タスクがより詳細を必要とする場合を除く、という条件が付いていた。この指示は数週間の社内テストを通過し、当時実行されていた評価セットではリグレッションは見られなかった。しかし調査中に実施されたより広範なアブレーションでは、Opus 4.6 と 4.7 の両方で 1 つの評価において 3% の低下が示され、4 月 20 日に元に戻された。
- 示されたプロセス変更は次のとおりである。機能テスト用のバージョンではなく、公開ビルドそのものを使う社内スタッフを増やすこと。社内の Code Review ツールを改善し、顧客にも提供すること。Claude Code のシステムプロンプトを変更するたびに、モデルごとの広範な評価スイートを実行し、行ごとのアブレーションを継続するとともに、プロンプト変更をレビュー・監査するための新たなツールを整備すること。モデル固有の変更をその対象モデルに限定するための CLAUDE.md への追記。そして、知能とのトレードオフになりうるあらゆる変更に対して、ソーク期間、より広範な評価、段階的なロールアウトを設けること。
背景
この投稿はベンダーが自社製品について語ったものであり、その根拠は内部的なもの（評価結果、アブレーション、同社自身によるコードの読解）である。最も他に応用できる知見は、製品についての主張ではなく、評価の限界についての告白である。冗長さを抑える指示は、当時使われていた評価セットでの数週間の社内テストを通過しており、リグレッションはより広範なセットを行ごとに実行して初めて現れた。これが、今後のすべてのシステムプロンプト変更に対して行ごとのアブレーションを約束する理由となっている。
推論エフォートの件は、モデルの問題というよりはプロダクトのデフォルト設定の問題として読める。その能力は終始利用可能であり、投稿自身の説明によれば、大半のユーザーは単にデフォルトのままにしていたにすぎない。キャッシュのバグは、通常のコストの議論とは逆の方向からトークンキャッシュに関わっている。ここでは、推論が落とされたことがキャッシュミスを引き起こしたのであってその逆ではなく、ユーザーに見える症状はレイテンシーではなく消費量だった。