AIコーディングツールの品質は、モデル本体が変わらなくても、設定やプロンプトの変更だけで大きく揺らぐ。2026年3月から4月にかけて、Claude Codeの利用者のあいだで「以前より浅い」「途中で忘れる」という不満が広がり、Anthropicは4月23日に公式ポストモーテムで原因を認めた。
この記事では、ユーザーが先に気づいた兆候、AMDの検証データ、Anthropicが認めた3つの変更、そして運用側が取るべき対策を整理する。
この記事でわかること
- 品質低下の具体的な症状と、ユーザー側の検証結果
- Anthropicが認めた3つの原因と修正スケジュール
- 公式発表が遅れた背景と、AIツール運用で押さえるべき点
ユーザーが先に気づいた品質低下
2026年3月初旬から、RedditやGitHub、Hacker NewsでClaude Codeの品質低下が報告された。症状は「コードを十分に読まずに編集する」「タスクを途中で放棄する」「技術的には動くが設計が雑な修正を出す」といったものだ。モデルの重みそのものは変わっていないと後にAnthropicは説明したが、利用者の体感は明確に悪化していた。
転機になったのは、AMDのAIグループシニアディレクターStella Laurenzo氏が2026年4月2日に投稿したGitHub Issue（#42796）だ。同氏のチームは6,852セッション、17,871の思考ブロック、234,760のツール呼び出しを分析した。
検証結果の要点は次のとおりだ。
- 推定される思考の深さ（中央値）は、2月初旬の約2,200文字から約73%減少
- 編集前のファイル読み取り比率（read-to-edit比）は6.6から2.0へ低下
- 読み取りなしで編集した割合は6.2%から33.7%へ増加
- 3月8日以降、タスク放棄を検知するストップフック違反が0件から173件に増加
Laurenzo氏は、思考が浅くなるとモデルは「最も安い行動」に寄ると指摘する。読まずに編集し、完了を宣言し、責任を回避する。これは利用者が感じていた症状と一致する。
Anthropicが認めた3つの原因
4月23日、Anthropicはエンジニアリングブログ「An update on recent Claude Code quality reports」で、Claude Code・Claude Agent SDK・Claude Coworkに影響した3つの変更を公表した。API本体は影響を受けなかった。いずれも2026年4月20日時点のv2.1.116で修正済みだ。
1. 推論effortのデフォルト変更（3月4日〜4月7日）
Opus 4.6のhigh effortモードでは、UIがフリーズしたように見えるほどの待ち時間が発生することがあった。Anthropicは待ち時間と利用上限の圧力を下げるため、デフォルトをhighからmediumへ変更した。
内部評価ではmediumは多くのタスクで十分だったが、実利用では「賢さが落ちた」との報告が続いた。4月7日に変更は取り消され、Opus 4.7はxhigh、その他のモデルはhighがデフォルトに戻った。影響対象はSonnet 4.6とOpus 4.6だ。
2. キャッシュ最適化のバグ（3月26日〜4月10日）
1時間以上アイドル状態だったセッションの古い思考履歴を一度だけ削除し、再開時のコストを下げる最適化が導入された。ところが実装にバグがあり、セッションが一度アイドル閾値を超えると、以降のすべてのターンで思考履歴が削除され続けた。
その結果、Claudeは直前の判断理由を失い、忘れっぽさや繰り返し、不自然なツール選択が表面化した。思考ブロックが毎回落ちるためキャッシュミスも起き、利用上限の消費が速くなるという別報告とも整合する。4月10日のv2.1.101で修正された。
3. 簡潔化のシステムプロンプト（4月16日〜4月20日）
Opus 4.7は前モデルより出力が多い傾向がある。Anthropicはツール呼び出し間のテキストを25語以下、最終応答を100語以下に抑える指示をシステムプロンプトへ追加した。内部テストでは問題なかったが、調査時のより広い評価でOpus 4.6・4.7ともに品質が約3%低下した。4月20日に撤回された。
3つの変更は時期と影響範囲が異なり、ユーザーごとに症状がばらついた。effort変更の影響を受けた人、キャッシュバグに当たった人、verbosity制限の影響を受けた人が混在し、「全体的に劣化した」ように見えた。
対応の遅れが問題を拡大した
品質低下そのものに加え、Anthropicのコミュニケーション不足が不満を深めた。3月初旬から報告が続いていたにもかかわらず、公式のポストモーテムが出るのは4月23日まで約7週間かかった。期間中、ブログやステータスページでの正式な説明はなく、月額20〜200ドルの有料ユーザーは原因不明のまま品質低下を受け入れていた。
Anthropicは内部評価とdogfoodingでは再現できなかったと説明する。内部スタッフが一般公開ビルドと異なるビルドを使っていた点、キャッシュバグがアイドルセッションという限定的条件でのみ発生した点、verbosity変更の影響が狭い評価セットでは検出できなかった点が、見逃しの背景として挙げられている。
第三者ベンチマークのBridgeBenchでは、Claude Opus 4.6の幻覚ベンチマーク精度が83.3%から68.3%へ下がったと報告され、意図的な性能低下（通称「ナーフ」）の疑いを広げた。ただし、同じ6タスクで比較した場合の差は87.6%対85.4%と小さく、テスト条件の違いによるノイズだったという批判もある（参考）。公式ポストモーテムが出るまで、利用者は推測と体験談だけで状況を判断せざるを得なかった。
Anthropicの再発防止策と補償
ポストモーテムでAnthropicは次の対策を表明した。
- 内部スタッフの多くを一般公開ビルドと同一の環境へ移行
- システムプロンプト変更ごとにモデル別の広い評価スイートを実施
- インテリジェンスとのトレードオフがあり得る変更にはソーク期間と段階的ロールアウトを導入
- コードレビューツールの改善を社内外へ展開
- 製品判断の説明用アカウント@ClaudeDevsを開設
4月23日時点で、全サブスクライバーの利用上限をリセットする補償も実施した。キャッシュバグの調査では、Opus 4.7のコードレビュー機能が原因PRのバグを特定した事例も報告されている。人間のレビューと自動検証をすり抜けた変更が、最終的に別のAI機能で発見された点は、AIプロダクトの品質管理の難しさを示す。
実務で押さえるべき教訓
今回の事例が示すのは、AIツールの品質は「モデル名」だけでは保証されないという事実だ。effort設定、プロンプト、キャッシュ、セッション管理といったプロダクト層の変更が、モデル本体を触らなくても利用体験を大きく変える。
開発チームや個人利用者にとって実用的な対策は次のとおりだ。
- セッションログやツール呼び出し比率など、定量的な指標を自分で追う
- 品質低下を感じたら
/effortで推論レベルを確認し、必要なら引き上げる - ベンダーの変更ログだけに頼らず、再現可能な報告（Issueや
/feedback）を残す - 本番ワークフローでは、品質の急変を検知するアラートやフックを用意する
Laurenzo氏の分析が議論を動かしたように、ブラックボックス型のAIサービスでは「計測しないと劣化に気づけない」ケースがある。高額なサブスクリプションでも、プロダクト層の変更は事前告知なしに入る可能性がある。ツールを信頼するなら、出力の質だけでなく、読み取り回数や思考の深さといった行動指標も監視対象に含めるべきだ。