Claude Codeの品質低下：実際に何が起きていたのか

2026年の3月から4月にかけて、Claude Codeの性能が目に見えて落ちていた。モデル自体が変わったわけではない。プロダクト層への3つの変更が積み重なり、Anthropicが4月23日に公式ポストモーテムを公開するまでの6週間、推論の質が下がり続けた。

生のAPIはずっと正常だった。影響を受けたのはClaude Code CLI、Claude Agent SDK、Claude Coworkの3つ。原因はすべてv2.1.116で修正されている。

3つの変更、1つではない

それぞれの問題には独自のタイムライン、スコープ、修正日があった。これらが重なり合っていたため、再現が難しかった。

問題	発生期間	変更内容	影響を受けたモデル	修正
reasoning effortのダウングレード	3月4日〜4月7日	UIレイテンシー削減のため、デフォルトのthinking budgetを`high`から`medium`に変更	Sonnet 4.6、Opus 4.6	4月7日に差し戻し。現在のデフォルトはOpus 4.7が`xhigh`、その他が`high`
ターンごとにthinking historyがクリアされる	3月26日〜4月10日	キャッシュのバグにより、アイドル1時間後ではなく毎ターンコンテキストが消える状態に	Sonnet 4.6、Opus 4.6	4月10日にv2.1.101で修正
システムプロンプトによる冗長性の制限	4月16日〜4月20日	ハーネスのプロンプトに「ツール呼び出し間のテキストは25語以下、最終回答は必要な場合を除き100語以下」という制約が追加された	Sonnet 4.6、Opus 4.6、Opus 4.7	4月20日に差し戻し

まず reasoning effort の変更が来た。社内のevalでは、mediumは「大多数のタスクで若干低い精度だが大幅にレイテンシーが改善される」とされ、フィールドデータが届くまでは許容できるトレードオフに見えた。3週間後にキャッシュのバグが重なり、ダメージが拡大した。Claudeはより少なく考えながら、過去に何をしたかも追えなくなっていた。最後に冗長性制限が来た。Opus 4.7のローンチ準備の副作用で、アブレーションテストではそのプロンプトだけでOpus 4.6と4.7のコーディング品質が3%低下した。

AMDのデータ：推論が70%崩壊するとどうなるか

最も明確なシグナルはAnthropicの外からやってきた。AMDのAI担当シニアディレクターであるStella Laurenzoは、チームが異変に気づいた後、4月2日にGitHub issue #42796を登録した。分析対象は6,852のセッションファイル、234,760のツール呼び出し、17,871のthinkingブロックに及んだ。

読み取り対編集の比率が最も明確な行動の指標だ。正常なコーディングエージェントはコードを触る前に周辺のコードを読む。この比率は1月30日〜2月12日の6.6回（読み取り/編集）から、3月8日〜3月23日には2.0まで低下した。70%の減少。モデルはコンテキストを理解せずに編集していた。

thinking depthも同じ方向を示した。推定中央値のthinking depthは2月下旬に約2,200文字から約720文字へと約67%低下した。その後、thinking redactionにより直接的な計測が難しくなった。

stop-hookの違反が本番環境での状況を物語っている：

指標	2月	3月
APIコスト	約$12/日	約$1,504/日
APIリクエスト数	1,498	119,341
stop-hook違反	0	17日間で173件（平均10件/日、ピーク時43件）
ユーザーによる中断	ベースライン	12倍増加
「ひどい」というコメント	ベースライン	+140%
「怠惰」というコメント	ベースライン	+93%
「素晴らしい」というコメント	ベースライン	-47%
「最もシンプルな」プロンプト	ベースライン	+642%

人間の作業量は変わらず（月約5,600プロンプト）。生産性向上なしに1日のコストが$12から$1,504へ。これは緩やかな劣化ではない。崩壊だ。

BridgeBench（NS3.AI）は独自に、同じ期間でOpus 4.6の精度が83.3%から68.3%に低下し、本番コーディングモデルのランキングが2位から10位に落ちたことを計測した。AMDチームはこの数字を見て別のAIプロバイダーに切り替えた。

GitHubのissueの末尾には「Claudeからのメモ」というセクションがある。Opus 4.6自身が自分のセッションログを分析して書いたものだ。最後の一行はこうだ。「私は内側から、自分が深く考えているかどうかを判断することができません。」

Anthropicが見逃した理由

検知が遅れた要因は3つある。

各変更は異なるスケジュールで異なるトラフィックのスライスを対象にしていた。reasoning effortのダウングレードは長いセッションのthinkingに影響し、キャッシュのバグはマルチターンのコンテキストに、冗長性制限は出力の長さに影響した。単一のevalがこれら3つを同時に捉えることはなかった。

キャッシュバグの期間中、無関係な社内実験が2つ同時に走っていた。これらがバグの再現を積極的に阻害した。バグを切り分けようとするたびに実験のどちらかに当たり、一貫性のない結果ではなく系統的な障害のように見えるノイズが生まれた。

モデルの差もここで重要になる。Opus 4.7（フルのリポジトリコンテキストを読み込んだ状態）が調査中にキャッシュバグを見つけた。Opus 4.6は見つけられなかった。コンテキストが劣化した状態のモデルは、自身のコンテキストが劣化しているかどうかを信頼性高く確認できない。

構造的なギャップもあった。Anthropicの社内スタッフは公開サブスクライバーと同じビルドを一律に使っていなかった。ポストモーテムはこれを修正対象として直接指摘している。

ポストモーテムが十分に答えていない部分

3つの原因は文書化された。ポストモーテムがあまり直接的に触れていないのは、ユーザーコミュニティが提起したより広い懸念、つまりハーネス自体の問題だ。

r/ClaudeAIの詳細な投稿によれば、より深い問題はClaude Codeのハーネスが40以上のシステムリマインダーを自動注入し、v2.0.14以降158以上のシステムプロンプトバージョンを出荷し、それらのバージョン間で矛盾する指示を含み、Claudeが自分の存在をユーザーに隠すよう指示するプロンプトが含まれているという点だ。各新しい注入は、4月の3つの後退が適用される前から、有効な推論バジェットを狭めていた。

これを裏付けるデータポイントがひとつある。「Euler」と呼ばれる最小限のカスタムハーネスを使っていたユーザーは、3つの後退のいずれの影響も受けなかったと報告している。ハーネスのオーバーヘッドがなければ、ダメージが増幅されることもなかった。

Anthropicのコミットメントはプロンプト変更のガバナンスを前進させる。既存のプロンプト量を削減する計画については説明されていない。その問いは未解決のままだ。

Claude Codeで開発している人が注目すべきこと

この後退は、コストが爆発するか本番環境で出力の質が目に見えて劣化するまで、ほとんどのユーザーには見えなかった。いくつかの習慣があれば、もっと早く発見できた。

読み取り対編集の比率を追う。 AMDのデータはこれが先行する行動シグナルだと示している。エージェントが読む量より編集する量が多くなったら、上流で何かが変わっている。理由を知らなくても、何かがおかしいとわかる。

品質ゲートは原因を特定できなくても出力の失敗を捉える。 Build This Nowのワークフローでは、すべての機能が完了とマークされる前にtype check、lint、クリーンビルドに通る必要がある。後退中は、コンテキストを理解せずに編集するエージェントが、正常な状態よりも早く壊れたビルドやtype errorを生む。ゲートが失敗し、より多くのイテレーションが必要になる。これは防止ではない。構文的に正しくても論理的に間違ったコードはtype checkを通過できる。しかし、問題が出荷される前に浮かび上がる検知レイヤーにはなる。

時間帯による変動は実在する。 AMDのセッションデータは、thinking depthが太平洋時間の午後5時ごろ最も低いことを示している。高コストまたは複雑なタスクを実行するなら、現在の公開インフラストラクチャ下では1日の早い時間帯の方が安定した結果が得られる。

バージョンを固定する。 v2.1.101がキャッシュバグを修正した。v2.1.116に3つすべての修正が含まれている。自動化されたワークフローがあるなら、既知の正常なバージョンに固定し、アップグレード前にテストする。この後退はマイナーバージョンをまたいで静かにやってきた。

生のAPIはずっと正常だった。 推論の深度に関連する問題が発生しているなら、Claude Codeハーネスを使わずに同じプロンプトを直接APIに対してテストする。APIの結果が著しく良ければ、問題はモデルのウェイトではなくプロダクト層にある。

v2.1.116で修正済み

3つの原因はすべて解決された。Anthropicは4月23日にすべてのサブスクライバーの使用制限をリセットした。キャッシュバグのキャッシュミス動作により、予想以上に速く制限が消費されていたことを認めてのことだ。

ポストモーテムのコミットメント：

正確な公開ビルドを使用することが求められる社内スタッフの比率を増やす（社内/公開のギャップを埋める）
すべてのシステムプロンプト変更をカバーする、モデルごとのより広範なevalスイート
デプロイ前に行ごとの影響を計測するプロンプトアブレーション
プロンプト変更を監査する新しいツール
モデル固有の変更は意図されたモデルターゲットのみにゲート
別の指標との知能のトレードオフを含む変更にはソーク期間と段階的ロールアウト
開発者との継続的なコミュニケーションの透明性チャンネルとして@ClaudeDevsをXで開設

ポストモーテムはanthropic.com/engineering/april-23-postmortemで公開されている。AMDのGitHub issueはanthropic/claude-codeリポジトリの#42796だ。両方を並べて読む価値がある。公式の説明は何が起きたか、どんな変更が計画されているかをカバーし、コミュニティデータは外部からどう見えたかをカバーしている。