AnthropicのClaude Code障害ポストモーテム: 2025年4月23日
(anthropic.com)この1か月、一部のユーザーからClaudeの応答品質が低下したという報告が続いていました。Anthropicが追跡した結果、Claude Code、Claude Agent SDK、Claude Coworkに影響した3つの異なる変更が原因だったことを確認しました。API自体には影響はなく、2025年4月20日（v2.1.116）時点ですべての問題が解決したとしています。このポストモーテムでは、問題の原因、修正内容、そして再発防止策をまとめています。
3つの障害の原因と経緯
- 推論努力（reasoning effort）のデフォルト値引き下げ（3月4日）: Claude Codeのデフォルトの推論努力レベルを
highからmediumに変更しました。UIがフリーズしたように見えるほどの長い待ち時間を減らすための措置でしたが、ユーザーは応答品質の低下を体感し、最終的に4月7日に元へ戻しました。現在はOpus 4.7でxhigh、それ以外のモデルでhighがデフォルトに設定されています。 - キャッシュ最適化バグによる推論履歴の削除（3月26日）: 1時間以上アイドル状態だったセッションを再開する際、それまでの推論（thinking）履歴を一度だけ整理するよう設計された機能が、バグにより以後のすべての会話ターンで繰り返し削除されていました。このためClaudeは自分がなぜ特定の作業を行ったのかを記憶できなくなり、ユーザーが経験した「物忘れ」、反復応答、異常なツール選択の原因となっていました。キャッシュミス（cache miss、保存済みデータを見つけられない現象）が繰り返し発生したことで、利用量上限が想定より早く消費される副作用もありました。4月10日に修正されました。
- システムプロンプトの過度な簡潔化指示（4月16日）: Opus 4.7の冗長な出力を減らすため、「ツール呼び出しの間のテキストは25語以内、最終応答は100語以内」というシステムプロンプトを追加しました。内部テストでは問題ありませんでしたが、実際のコーディング品質に悪影響を与えることが確認され、4月20日に削除されました。
問題の発見が遅れた理由
- 3つの変更がそれぞれ異なる時点、異なるトラフィック範囲に適用され、 全体として一貫性のない品質低下のように見え、個別の原因を特定しにくくなっていました。
- 内部テスト環境と実際のユーザー環境に差異がありました。キャッシュバグの場合、内部で進行中だった別の実験やUI表示方式の違いにより、再現自体が容易ではありませんでした。
- 既存の評価体制（eval suite）が十分に広くありませんでした。 システムプロンプト変更の影響は、より多様な評価を実行した後になって初めて3%の性能低下として表れました。
再発防止のための対策
- 社内スタッフに実際の公開ビルドの使用を義務付け、 内部テスト用ビルドとの乖離を減らします。
- システムプロンプト変更に対する統制を強化します。 すべての変更でモデルごとの広範な評価を行い、各行の影響を個別に分析（ablation）し、段階的な展開と十分な検証期間（soak period）を設けます。
- Code Reviewツールを改善します。 実際にOpus 4.7に関連コードリポジトリ全体をコンテキストとして与えたところキャッシュバグを発見できた点に着目し、コードレビュー時に参照できるリポジトリ範囲を拡大します。
- ユーザー向けコミュニケーションチャネル（@ClaudeDevs）を新設し、製品判断の背景を透明に共有します。
「意図的な品質低下はなかった」という点について
- Anthropicはモデルを意図的に劣化させたことはないと述べており、APIと推論レイヤー（inference layer）には影響がなかったことを確認しています。ただし、プロダクトレイヤー（Claude Code）での設定変更とバグが複合的に作用し、ユーザー体感の品質が低下したのは事実です。あわせて、すべての購読者の利用量上限をリセットする措置も発表しました。
13件のコメント
どうして障害原因の3つ全部がコスト削減と直接関係してるんでしょうねｗｗｗｗｗ
性能が低下するほど、GPUリソースが本当にかなり逼迫しているみたいですね……
これが正解なんだけど、言い訳が長いね（笑）
これまで公開ビルドをテストもせずに配布し、配布後もテストしていなかったという話をずいぶん長々と書いていますね。実際、私は3月26日にすぐそのバグを踏んだのに、社内で確認するのに3週間もかかるなんて話になると思っているのでしょうか……
パッチが当たった直後から、それまで使い切るのに3〜4時間かかっていた5時間クォータが30分で消費されるようになったのに、社員アカウントには5時間クォータがないか、少なくとも毎回
/usageを見ながら作業しなければならないほど足りないわけではないので、気づくまでかなり時間がかかったんでしょうね。SWE-Bench-Pro daily benchmark（キュレーションされたセット）で
claude codeを見ると、興味深い点が見える。4/10〜4/20の区間ではruntimeが半分（653s→345s）、tool callが半分（3.3K→1.8K）、トークンは−18%減ったのに、pass rateはむしろ+16pp上がっている。4つの軸がすべて良い方向に同時に動くのは、よくあるパターンではない。
その過程で起きた事故3件が4/23のpostmortemだが、見ると全部「トークン/latencyを減らそうとして」起きたものだ。
一方、codex（gpt-5.4-xhigh）は同じ期間で数字がほとんど動いていない。pass rateは56%前後で固定、トークン/runtime/tool callも
claude codeの2倍水準のまま障害のポストモーテムではなく、コスト削減のポストモーテムなのでは？
社内スタッフに実際の公開ビルドの使用を義務付け、社内テスト用ビルドとの乖離を減らします。
はははは
Opus 4.7 に YAGNI を教え込んでしまったみたいですね。毎回アーキテクチャの決定で、YAGNI に従った段階的な修正だという理由付けをしているからそういうものかと思っていたら、結局やらかしてしまいました。記憶力も長くない子なのに先延ばしの癖までついてしまって、大変なことです。
最初に問題提起されたときは問題ないと言い張っていたのに、あまりに話題が大きくなって隠しきれなくなったから公開した、と考えるのは私だけでしょうか。
claude.aiのWebも全体的に細かく使い勝手が落ちている感じ…。トークンを節約するためにメモリも切りました。
この告知を見てから、むしろAnthropicをさらに信頼できなくなった感じ。
上に関連記事が2本あるけど、2本は7か月差の投稿です。問題はどちらも同じく3つずつ。
最近のClaude品質低下イシュー3件の事後分析 2025-09-19
最近のClaude Code品質報告に関するアップデート 2026-04-24
私はたった5ドル分のクレジットくらい腹が立ってる!!
話が長いな..