2026年3月から4月にかけて、「Claudeが劣化した」という声がコミュニティで続出した。SNSでもフォーラムでも「前の方が賢かった」「バカになった」という報告が相次ぎ、Anthropicは全面的な調査に乗り出した。
その結果、3つの独立した変更が複合的に影響していたことが判明。影響を受けたのはClaude Code、Agent SDK、Cowork——API自体は無関係だった。2026年4月23日、Anthropicは詳細なポストモーテム(事後分析)を公開した。
この記事では、何が起きたのか、なぜ気づくのが遅れたのか、そして何を学んだのかを整理する。
最初の問題は、Reasoning Effort(推論努力度)のデフォルト変更だった。
2月にOpus 4.6がリリースされた際、デフォルトの推論努力度はhighに設定されていた。しかし、一部のユーザーから「思考時間が長すぎてUIがフリーズする」というフィードバックが届く。Anthropicはこれを受けて、3月4日にデフォルトをhighからmediumに変更した。
内部評価では、mediumでも「十分な知性」を維持しつつレイテンシとトークン消費を大幅に削減できると判断されていた。UI上で努力度を変更できる告知も出した。
しかし、大多数のユーザーはデフォルトのまま使う。結果として——
ユーザーの声:「Claudeが賢くなくなった」
フィードバックが蓄積する中、Anthropicは設計を何度か反復した。起動時の通知、インラインの努力度セレクター、ultrathinkの復活など。それでも多くのユーザーはmediumのままだった。
最終的に4月7日、決定は撤回された。現在はOpus 4.7がxhigh、それ以外がhighにデフォルト設定されている。
教訓:「速さ」より「賢さ」を優先するユーザーが多い。レイテンシ削減は重要だが、知性の低下と引き換えにするべきではない。トレードオフの選択はユーザーに委ねるべきだ。
2つ目は、最も厄介だったキャッシュ最適化のバグだ。
Claudeがタスクを推論する際、その「思考プロセス」は会話履歴に保持される。次のターンで「なぜその編集をしたのか」を参照できる仕組みだ。
3月26日、Anthropicはこの仕組みに効率改善を導入した。セッションが1時間以上アイドル状態だった場合、古い思考セクションをクリアする——という設計だった。プロンプトがキャッシュから追い出された後の再開コストを下げるためだ。
しかし実装にはバグがあった。1回だけ消すはずが、セッションの残りすべてのターンで毎回思考履歴を消し続ける状態になっていたのだ。
// 期待される動作
clear_thinking_20251015 + keep:1
→ 1回だけクリア、その後は通常通り
// 実際の動作(バグ)
→ 毎ターン実行され続ける
→ 思考履歴が毎回リセットされる
→ 「なぜこれをしているか」を忘れる
このバグが引き起こした症状:
発見が遅れた理由も興味深い。2つの無関係な実験が偶然このバグを隠していたのだ——メッセージキューイングのサーバーサイド実験と、CLIでの思考表示変更。これらが「マスク」になり、外部ビルドでのテストでも再現しなかった。
コードレビュー、ユニットテスト、E2Eテスト、自動検証、ドッグフーディング——すべてを通過したバグ。
調査の過程で、AnthropicはOpus 4.7を使ってバグの原因となったPRを事後レビューした。結果:Opus 4.7はバグを発見できたが、Opus 4.6は発見できなかった。コードレビューAI自体の進化を示す興味深いエピソードだ。
4月10日、v2.1.101で修正された。
3つ目は、Opus 4.7のリリースに合わせたシステムプロンプトの変更だった。
Opus 4.7には「かなり冗長になる」という行動特性があった。難しい問題では高い性能を発揮するが、出力トークン数も増える。Anthropicはこれを制御するため、システムプロンプトに指示を追加した:
Length limits: keep text between tool calls to ≤25 words. Keep final responses to ≤100 words unless the task requires more detail.
数週間の内部テストで回帰は検出されず、自信を持って4月16日にリリースされた。
しかし——。
今回の調査で、より広範な評価セットでアブレーションテスト(プロンプトの各行を削除して影響を測る手法)を行った結果、この1行がOpus 4.6と4.7の両方で3%の性能低下を引き起こしていたことが判明した。
4月20日、即座にrevertされた。
教訓:「25語以内」という単純な制約が、コーディング品質に予期せぬ影響を与える。AIのプロンプトエンジニアリングにおいて、小さな指示の変更が大きな結果をもたらす。評価セットの選び方が、検出力を左右する。
3つの変更は、それぞれ異なるタイミング、異なる対象、異なる症状で現れた。
これらが重なり合った結果、全体像は「広範で一貫性のない劣化」に見えた。内部の使用や評価では再現が難しく、ユーザーフィードバックの「ノイズ」と区別しづらかった。
最終的に特定の鍵となったのは、具体的で再現可能な例を提供してくれたユーザーたちの声だった。
Anthropicは以下の改善を約束した:
このポストモーテムで最も印象的なのは、Anthropicの透明性だ。
「ユーザーのせい」でも「モデルの限界」でもなく、「私たちが3つの変更を重ね、それが複合的に問題を起こした」と正直に説明している。具体的な日付、コードレベルの原因、なぜ見逃されたのか、どう直したのか——すべてが公開されている。
AI開発の現場では、小さな変更が予期せぬ相互作用を起こすことがある。Reasoning Effortの変更、キャッシュ最適化のバグ、25語制限のプロンプト——どれも単独なら「些細な改善」のつもりだった。それが3つ重なって、ユーザー体験を大きく損なった。
これはAI企業に限らない教訓だ。ソフトウェア開発全般で言えること——変更の影響は個別には測りきれない。重なり合った時の全体像を見る仕組みが必要だ。
「Claude Codeが劣化した」という声に真摯に向き合い、詳細な事後分析を公開したAnthropicの姿勢は、責任あるAI開発のモデルケースと言える。僕自身、Claude Codeを日常的に使っている身として、この透明性は信頼につながる。
最後に、Anthropic自身の言葉を引用する:
We're immensely grateful for your feedback and for your patience.
フィードバックを送ってくれたユーザー、再現可能な例を投稿してくれたコミュニティ——それが問題解決の最大の力だった。AIの品質を守るのは、企業だけじゃない。使う人たちとの共犯関係なのだ。
← ブログ一覧に戻る