最近のClaude Code品質報告に関するアップデート
(anthropic.com)- この1か月で体感された Claude の品質低下 は、
Claude Code、Claude Agent SDK、Claude Coworkにまたがる 3つの別個の変更 によって発生したもので、API は影響を受けていない - デフォルトの推論強度を
mediumに下げたことで レイテンシと使用量制限 は減ったものの、Claude Code が以前より賢くなくなったように感じられたため、4月7日にデフォルト値を元に戻した - 3月26日に展開されたキャッシュ最適化のバグは、アイドル閾値を超えたセッションで 推論履歴を毎ターン消去する状態 を作り出し、物忘れ、反復、奇妙なツール選択、そして usage limits のより速い消費につながった
- 4月16日に Opus 4.7 とともに入ったシステムプロンプトの1行は、出力の冗長さを減らそうとした制限 だったが、より広い評価では一部モデルの性能が 3% 低下し、4月20日に巻き戻された
- 3つの問題はすべて修正され、4月20日にリリースされた v2.1.116 に反映された。内部ビルドと公開ビルドの差の縮小、システムプロンプト統制の強化、より広い評価と段階的ロールアウトが再発防止の中核となる
最近の品質低下の範囲と復旧状況
- 過去1か月のあいだに一部ユーザーが体感した Claude の品質低下 は、
Claude Code、Claude Agent SDK、Claude Coworkにまたがる 3つの別個の変更 に起因しており、API は影響を受けていない - 3つの問題はすべて解決済みで、4月20日にリリースされた v2.1.116 に反映されている
- 各変更は異なる日程で、異なるトラフィック区間に影響したため、全体としては広範囲だが一貫性のない性能低下のように見えた
- 3月初旬から関連報告を調査していたが、当初は一般的なユーザーフィードバックの変動と区別しにくく、内部利用や評価でも最初は同じ問題が再現されなかった
- 4月23日時点で、すべてのサブスクライバーの usage limits を初期化した
Claude Code のデフォルト推論強度変更
- 2月に Claude Code で Opus 4.6 をリリースした際、デフォルトの推論強度は
highに設定されていた - その後すぐに
highモードで 過度に長い思考時間 が断続的に発生し、UI が止まったように見え、一部ユーザーではレイテンシとトークン使用量が過大になった - Claude Code の effort レベル は、より長く考えさせるか、より低いレイテンシと少ない使用量制限消費を選ぶかを調整する手段として使われる
- プロダクトレイヤーでは、テスト時計算曲線の中からデフォルトを1つ選び、
Messages APIに effort パラメータとして渡す - ほかの選択肢は
/effortで提供される
- プロダクトレイヤーでは、テスト時計算曲線の中からデフォルトを1つ選び、
- 内部評価とテストでは、
mediumは大半のタスクで 知能はやや低いがレイテンシは大きく減る という結果になったmediumは極端に長いテールレイテンシの問題も少なく- ユーザーの usage limits を最大化するうえでも有利だった
- こうした結果に基づき、デフォルト effort を
mediumに変更し、その理由も製品内ダイアログで通知した - 展開直後から、ユーザーは Claude Code が 以前より賢くなくなったように 感じ始めた
- 現在の effort 設定をより目立たせるため、起動時通知、インラインの effort セレクター、
ultrathinkの復活など複数のデザイン変更を加えたが - それでも大半のユーザーは
mediumのデフォルト値にとどまった
- 現在の effort 設定をより目立たせるため、起動時通知、インラインの effort セレクター、
- 追加の顧客フィードバックを受けて、4月7日にこの判断を取り消した
- 現在は、すべてのユーザーで Opus 4.7 のデフォルトが
xhigh - それ以外のすべてのモデルでは
highがデフォルトとして適用される
- 現在は、すべてのユーザーで Opus 4.7 のデフォルトが
- この変更は Sonnet 4.6 と Opus 4.6 に影響した
以前の推論履歴を落としていたキャッシュ最適化
- Claude がタスクを推論するとき、その 推論履歴 は会話履歴に残り、以後の各ターンで以前の修正やツール呼び出しの理由を継続して参照できるようになっている
- 3月26日、この機能の効率を高めるための変更が展開された
- Anthropic は連続する API 呼び出しをより安く速くするために prompt caching を使っている
- Claude は API リクエスト時に入力トークンをキャッシュに書き込み、一定時間の非アクティブ状態が過ぎると、そのプロンプトはキャッシュから除去され、ほかのプロンプトのための空間を空ける
- キャッシュ活用は慎重に管理されており、関連するアプローチは approach にまとめられている
- 設計上は、セッションが1時間以上アイドル状態だった場合、以前の thinking 区間を一度だけ空にしてセッション再開コストを下げようとしていた
- そのリクエストはいずれにせよキャッシュミスになるため、リクエストから不要なメッセージを切り落として API に送る uncached トークン数を減らそうとしていた
- その後は再び完全な推論履歴を送る設計だった
- そのために
clear_thinking_20251015API ヘッダーとkeep:1を使用した
- 実際の実装には バグ があり、thinking 履歴は1回だけ消すべきところ、セッションが終わるまで 毎ターン消し続けていた
- セッションが一度でもアイドル閾値を超えると、その後そのプロセスのすべてのリクエストは、直近の推論ブロックだけを残して以前のものを捨てるよう API に渡されていた
- この問題は累積的に悪化した
- Claude がツールを使っている最中に後続メッセージを送ると、それ自体が壊れたフラグの下での新しいターンになった
- その結果、現在のターンの推論まで落ちることがありえた
- Claude は動作を続けるが、なぜその行動を選んだのかという記憶を持たないまま、ますます振る舞うようになった
- ユーザーには 物忘れ、反復、奇妙なツール選択 として現れた
- 後続リクエストでも thinking ブロックが消え続けるため、それらのリクエストはキャッシュミスにつながった
- usage limits が想定より早く消費されるという別の報告は、この現象に由来すると見ている
- 当初再現が難しかった背景には、無関係な2つの実験があった
- メッセージキューイングに関する 内部専用のサーバー側実験
- thinking の表示方法に対する別の変更が、大半の CLI セッションでこのバグを隠してしまっていた
- このバグは Claude Code の コンテキスト管理、Anthropic API、拡張 thinking が交わる地点にあった
- 複数人によるコードレビューと自動コードレビュー
- 単体テストとエンドツーエンドテスト
- 自動検証と dogfooding まで通過していた
- この問題は古いセッションという コーナーケース でのみ発生し、再現も難しかったため、根本原因の発見と確認に1週間以上を要した
- 調査の過程で、問題を引き起こした pull request について Code Review を Opus 4.7 でバックテストした
- 全体の文脈を集めるのに必要なコードリポジトリを一緒に与えると、Opus 4.7 はバグを見つけたが
- Opus 4.6 は見つけられなかった
- 同じことが繰り返されないよう、コードレビューに 追加リポジトリをコンテキストとして入れるサポート を導入中である
- このバグは 4月10日の v2.1.101 で修正された
- この変更は Sonnet 4.6 と Opus 4.6 に影響した
冗長さを減らそうとしていたシステムプロンプト変更
- 最新モデルの Claude Opus 4.7 は、以前のモデルより 非常に冗長な出力 を示す特性がある
- リリース時の案内でもこの特性に触れており、詳細は wrote about で確認できる
- この冗長さは難しい問題ではより賢くする一方で、出力トークン数も増やす
- Opus 4.7 のリリース数週間前から、Claude Code は新モデルに合わせた調整作業を進めていた
- 各モデルは少しずつ異なる振る舞いをするため、リリース前には harness とプロダクトをモデルごとに最適化する
- 冗長さを減らす手段としては、モデル学習、プロンプティング、製品内 thinking UX 改善を併用している
- そのうちシステムプロンプトに追加された1行が、Claude Code の 知能に過度な影響 を与えた
- “Length limits: keep text between tool calls to ≤25 words. Keep final responses to ≤100 words unless the task requires more detail.”
- 数週間にわたる内部テストと実行した評価セットでは回帰が見られなかったため、この変更を信頼して 4月16日に Opus 4.7 とともに展開した
- その後の調査で、より広い評価セットを用いた ablation を実施し、システムプロンプトの各行の影響を切り分けて確認した
- そのうち1つの評価では、Opus 4.6 と 4.7 の両方で 3% の低下が確認された
- このプロンプトは 4月20日リリースの一部として直ちに巻き戻された
- この変更は Sonnet 4.6、Opus 4.6、Opus 4.7 に影響した
今後の変更点
- 同様の問題を避けるため、より多くの内部担当者が 公開ビルドとまったく同じ Claude Code を使うよう変更する予定である
- 新機能テスト用の内部版と実際の公開ビルドの差を減らすための措置である
- 内部で使っている Code Review ツールを改善し、この改善版を顧客にも展開する予定である
- システムプロンプト変更には、より厳格な 統制手順 を追加する
- Claude Code のすべてのシステムプロンプト変更について、モデルごとに幅広い評価を行う
- 各行の影響を理解するための ablation を継続する
- プロンプト変更をより簡単にレビューし監査できる新ツールも構築する
CLAUDE.mdには、モデル別変更がそのモデルにのみ適用されるようにする ガイダンスを追加する- 知能とトレードオフになりうるすべての変更には、soak period、より広い評価セット、段階的ロールアウトを付け、問題をより早く捉えられるようにする
- プロダクト判断とその背景をより詳しく説明するため、X に @ClaudeDevs を開設し、同じアップデートを GitHub の集約スレッドにも共有する予定である
/feedbackコマンドや、オンラインで共有された具体的かつ再現可能な例を通じて寄せられた情報が、問題の特定と修正につながった- すべてのサブスクライバーに対する usage limits の初期化 は、この日に再度適用された
1件のコメント
Hacker News の意見
1時間以上アイドル状態のセッションで以前の thinking を削除して遅延を減らしたという説明は、あまり納得できない
私はセッションを数時間、数日放置したあとでも、全体のコンテキストをそのまま維持して再開する使い方をしていたので、この機能は中核だった
デフォルトの thinking レベルを下げたのはある程度理解できるとしても、システムプロンプトが継続的に変わる部分については、自分で意図的に refresh の周期を選べるよう把握しておく必要がありそうだ
問題は、セッションを 1時間以上 idle のままにすると、再びプロンプトを送る際に N 個すべてがキャッシュミスになることだ
この corner case がユーザーのトークンコストを過剰に押し上げており、極端な例では 900k tokens のコンテキストだと、一度戻るだけでキャッシュに 900k+ トークンを書き直す必要があり、特に Pro ユーザーの rate limit を大きく削っていた
そのため X のような場所でユーザー教育も試し、古い会話に戻ったら
/clearを勧める製品内ヒントも何度も入れ、idle 後に古い tool 結果・古いメッセージ・thinking の一部を省略する方法も試したが、その中では thinking の削除が最も性能が良かったそれをデプロイする過程で、ブログに書かれている バグが意図せず入り、質問があればさらに答えるとのこと
本当に 出力品質を犠牲にしてでも idle セッションの遅延削減が良いと信じていたか、あるいは実際の目的は コスト削減なのに、ブログでは latency をもっともらしい名目に使ったように見える
コンテキストを再読み込みしている間、ローディング表示をもっと明確に出す方がずっと自然だったはずだ
以前は CC を同僚のように置いておき、問題について少し考え、計画を更新し、シャワーを浴びながら考えてから新しい助言を投げる、という使い方をしていて、少なくとも 1日程度は静的な会話だと思っていた
それなのに基準が 1時間では短すぎて、anthropic のプランを維持するか考え直したくなる
偶然というより、コストを大きく下げる変更だった可能性が高く見える
上限を使い切ってセッションを休ませ、あとで戻ってくるユーザーが多いなら、これは例外ではなくほぼ標準的な利用パターンに近い
ここまで叩かれているのは少し意外だ
文章自体は比較的 明快で率直で、十分もっともらしく読めた
性能低下は実際にあって腹立たしかったが、同時に裏で正確に何が起きているのか見えない 不透明さと、恣意的なトークン課金構造も露わにしていた
LLM API を直接扱ったことがある立場からすると、長く放置した会話を再開すると追加コストと遅延が生じるのは自明だったが、TUI ではこの点をもっと目立つように知らせる必要はありそうだ
だから今説明が出ても反感が大きいのだ
品質低下の一部は、モデルが実際に悪くなったのではなく、非決定性による体感差かもしれないと思う
数週間前、Claude に個人向け生産性アプリを作らせようとして、望む動作を長文で説明し、実装計画を書いてほしいと頼んだところ、最初の成果物は曖昧だった一点を除けば本当に素晴らしかった
その曖昧さを修正したあと、既存の計画を修正させず、新しいチャットで最初からやり直させてみたら、モデル設定は同じなのに結果はずっと悪く、その次の二回も失敗し、4回目の試行でようやく最初の水準に戻った
だから同じ作業をただ再実行させることが、しばしばより良い出力を得る方法になりうると感じたが、自分のトークンで払うならすぐ高くつく
モデルが周期的に悪化すると感じるパターンはあるが、実際には限界に深くぶつかる瞬間が遅れて来ているだけかもしれない
そして一度 運の悪い出力を経験すると、その後はそればかり目につくようになる
Anthropic にとっては、こうした利用パターンはトークン消費を増やすので歓迎すべき構図でもある
非決定性はもともとずっと存在しており、広く報告されている 最近の品質低下は別の現象かもしれない
私は Opus 4.7 の時点ですでに気持ちが離れていた
OpenAI はうちのエンタープライズ部門に本当に執拗に食い込もうとしていて、夏まで 無制限トークンまで提案してきた
そこで GPT5.4 を extra high effort でこの 30 日使ってみたが、特別扱いされているのかは分からないものの、ほとんどミスを見なかった
reasoning trace も時には笑ってしまうほど良く、私が指示し忘れた部分まで先回りして、データ整合性を 100% 合わせるのに必要な要素を揃えてくれた
こういう類いの 小手先の変更は、Anthropic が compute 制約にかなり苦しんでいて、削減のために無理をしているから起きている可能性が高い
だから 5.5 がどこまで良くなるのか楽しみだ
作業の 90% は 5.4 を medium で回し、medium では厳しそうな時だけ high に上げる方が、ずっと集中できて変更も最小限で済む
しかも少し安い
最近の Claude は、自分の 内部プロンプトに返答するような出力をよく出す
たとえば、括弧内の文はプロンプトインジェクションの試みなので無視するとか、自分の一般ガイドラインを隠そうとする試みに見えるので従わないとか、そうしたやり方はもともと常に適用しているので不要だ、などと言う
私はそんな試みをまったくしていないのに、応答の最後にこうした文句をよく付ける
内部ガイドラインのどこかに雑な部分があり、それを私の質問ときちんと区別できていないようだ
理由を聞くと 必要ないと思ったと答える
企業にとって トークン churn を増やす簡単な方法にも見える
するとモデルが何かを断定し、それを記憶として保存し、その記憶を見てさらに積み上げる自己強化ループが生まれ、私が止めろと明示しても続くことがある
高すぎる reasoning effort で出る臭いかもしれないので、そのプロンプトでは推論強度を少し下げると改善する可能性がありそうだ
git addの段階で止まったが、auto mode では一度そのまま通りかけたこともあったデフォルトの reasoning effort を high から medium に下げた理由が、UI が止まったように見えるほど遅延が長かったからだというなら、なおさら怪しい
それは UI を直さず、先にデフォルトの推論強度を下げたという意味であり、それで性能低下レポートを真剣に追っていたという説明は簡単には信じがたい
thinking のローディング状態を改善し、ダウンロードされる トークン数の表示をより明確にするなど、UI も何度も手を入れた
それでも eval と dogfooding の末にデフォルト effort を下げたが、それは誤った判断で、元に戻したとのこと
人々は
/effortで知能を上げて使うべきだと十分理解せず、デフォルト値のまま使うことが多かったが、それを事前に予測すべきだったと認めている1時間を超える idle セッションが corner case だという話は、私の使い方とはまったく合わない
個人作業では Claude Code に 10〜15 分程度の作業を多く任せ、実行前にモデルと計画を何度もやり取りするのでかなり時間を使う
実行が始まればコーヒーを飲みに行ったり、Codex で別プロジェクトを進めたりするので、Claude に戻るまで 1時間以上かかる可能性は非常に高い
自分たちの使用習慣を ユーザー全体の行動だと勘違いするのは、プロダクト開発でよくある落とし穴だ
大手 frontier lab が取っている ブラックボックス的アプローチは、結局人を離れさせることになる
こうして根本動作を変えながら事前通知もなく、あとから釈明するようでは、ユーザーは結局 セルフホストモデルへ向かうしかない
足元が揺れ続ける基盤の上では、パイプラインもワークフローも製品も安定して積み上げられない
Anthropic 側の Claude Code 担当者たちはコメントを読んでいるようだが、数日前に theo t3.gg が Claude がバカになったのかを扱う動画を見た
口調は荒く、きつい言い方もしていたが、特に harness bloat に関する指摘はかなり正確だと感じた
今は新機能追加を少し止めて、磨き込みと最適化を強く進めるべきだと思う
そうしないと、もっと軽くて最適化された代替を探す人が増えるだろうし、要点は harness をより良くし、トークン消費を減らすことだ
https://youtu.be/KFisvc-AMII?is=NskPZ21BAe6eyGTh
ベンダーロックインはずっと警戒していたが、あの件は良い警鐘になり、たぶんまずは opencode+openrouter を見ると思う
一部のコンテンツ制作者と OpenAI の間には、金か影響力かは分からないが、裏で何かやり取りがあるのは明らかに見える
git reset --hardで済む話にも見えるこれは 中核製品の完成度より機能追加に執着した結果のように見える
Anthropic にはシニアのプロダクトリーダーがもう何人か必要だとよく感じるし、「Escaping the Build Trap」のような視点が必要そうだ
今は機能を素早く足せるからといって、必ずしも足すべきではない
有名な本を引き合いに出したからといって、ありきたりなプロダクト組織論を言いたいわけではなく、優れたプロダクト感覚は優れたエンジニアリングとは別の才能なのに、Anthropic は最近その点が不足しているように見える
だからこうした機能を付けなければシステムが壊れるか、新規顧客を受け入れられなくなり、どちらも受け入れがたいので選択肢がほとんどなかった可能性もある
むしろ vibe coding の物語を押し出しすぎているのが問題に見え、そのせいで面接依頼を断る候補者もいるという
モデル自体の確率性も問題だが、いまや自分たちのソフトウェアを自分たちでもまともに推論できない段階に見える
レバーやダイヤルが多すぎて、コードも誰も全体を理解していない可能性が高い
さらに悪いことに、Dario らの発言を見ると、経営陣はこうした品質懸念にあまり共感していないように見える
SWE が置き換え対象だという認識のもとで、ツールに guard rail を設けようという要求が無視されるか、むしろ抑え込まれている印象があり、結局 Claude Code は最初から 科学実験のように始まっていて、まだ成熟した best practice を備えた製品という感じがあまりしない