Claude Codeの品質低下は気のせいではなかった：Anthropic公式ポストモーテムで分かった3つの原因¶

対象 / ポイント

対象: 2026年3月以降にClaude Codeが急に雑になった、または使用量が速く減る現象を経験した開発者・AIコーディング初心者。

ポイント:

Anthropicは2026年4月23日、Claude Code品質低下の原因を3つの変更として説明した
問題は「モデル本体の意図的な劣化」ではなく、Claude Code側の推論設定・キャッシュ最適化・システムプロンプト変更だった
以前のトークン消費記事は方向性として正しかったが、原因断定の一部は公式情報に合わせて補正が必要

2026年3月から4月にかけて、Claude Codeを使っていた開発者の間で声が増えた。「急に雑になった」「読まずに編集する」「使用量だけ速く減る」といった声だ。

結論から言うと、これは単なる気のせいではなかった。 Anthropicは2026年4月23日、Claude Code、Claude Agent SDK、Claude Coworkに影響した3つの問題を公式に説明した。そして、4月20日までに解消したと発表した¹。

この記事の問いは1つだ。結局、Claude Codeでは何が起きていたのか。

まず何が公式に認められたのか¶

Anthropicが認めたのは、Claude Codeの利用体験が一部ユーザーで実際に悪化していたという点だ。

ただし、公式説明では「Claude APIや推論基盤そのものは影響を受けていない」とされている¹。つまり、モデルの中身をこっそり弱くした話ではない。 Claude Codeという製品の周辺レイヤーで問題が重なった、という整理になる。

初心者向けに言い換えると、車のエンジンそのものではなく、アクセル設定、ナビの記憶、運転ルールが同時に変わったようなものだ。エンジンが同じでも、運転感覚はかなり変わる。

公式が挙げた原因	何が変わったか	ユーザーの体感
推論努力レベルの引き下げ	`high` から `medium` へ	考えが浅い、雑に見える
thinking履歴削除バグ	過去の推論メモを毎ターン捨てた	忘れる、繰り返す、変な判断をする
短文化プロンプト	返答を短く抑える指示が強すぎた	説明不足、コード品質低下

ここからは、この3つがどう品質低下につながったのかを順番に分解する。

原因1：考える量の初期値を下げた¶

最初の原因は、Claude Codeの「考える量」の初期値が下がったことだ。

Claude Codeには effort という設定がある。これは、ざっくり言えば「速さと深さのつまみ」だ。低くすると返答は速くなりやすいが、難しい実装では判断が浅くなりやすい。

Anthropicは2026年3月4日、Claude Codeのデフォルト推論努力レベルを high から medium に変えた。理由は、高い設定だと考え込みすぎてUIが固まったように見えたり、使用量に強く響いたりするケースがあったためだ¹。

この判断は、後から見ると悪いトレードオフだった。公式ポストでも、ユーザーは「低レイテンシより高い知能を初期値にしてほしい」と望んだため、 4月7日に戻したと説明されている¹。

ただし、Changelogを見ると戻し方はアカウント種別ごとに段階的だった。 4月7日のv2.1.94ではAPIキー、Bedrock、Vertex、Foundry、Team、 Enterprise向けに medium から high へ変更されている。 4月22日のv2.1.117では、Pro/Max購読者向けにもOpus 4.6とSonnet 4.6のデフォルトが high へ戻っている²。

短く言えば、「前より考えない設定」が一時的に標準になっていた。 これだけでも、複雑なコード修正では大きな差になる。

原因2：過去のthinkingを捨て続けるバグがあった¶

最も重要なのは、2つ目の原因だ。Claude Codeは、過去の推論メモを失い続ける状態になっていた。

Claude Codeはコードを読む、編集する、テストする、また修正する、という作業を何ターンも続ける。このとき重要なのは、直前までの「なぜその判断をしたか」という作業メモだ。 Anthropicはこれをthinking履歴として会話に残していたと説明している¹。

2026年3月26日、Anthropicはアイドル状態が1時間を超えたセッションを再開するとき、古いthinkingを一度だけ削って軽くする最適化を入れた。狙いは、再開時の遅さとコストを減らすことだった¹。

問題は実装だ。一度だけ消すはずが、そのセッションでは毎ターン、古いthinkingを消し続ける状態になった。しかも、ツール実行中に追加メッセージを送ると、そのターンの推論まで落ちることがあった¹。

これは実務ではかなり痛い。たとえば「さっきA案を捨ててB案にした理由」を忘れたまま、次のファイルを編集する。すると、同じ調査を繰り返したり、すでに否定した方針に戻ったり、読まずに手を入れたりしやすくなる。

そしてこのバグは、使用量にも関係した。 Anthropicは、thinkingブロックが継続的に落ちることでキャッシュミスが起きた可能性を説明している¹。キャッシュミスとは、前の会話を安く再利用できず、新しい入力として処理し直す状態のことだ。その結果、使用制限が予想より速く減る別報告につながった可能性がある。

つまり、「品質が落ちた」と「トークンが速く溶けた」は別々の話ではない。 少なくとも一部では、同じバグの表と裏だった。

原因3：短く答えさせる指示がコード品質を落とした¶

3つ目は、短く答えさせるためのシステムプロンプト変更だ。

Anthropicは2026年4月16日、Claude Codeに対して、ツール呼び出しの間の説明や最終回答を短く抑える指示を追加した。背景には、Opus 4.7が前モデルより冗長になりやすく、出力トークンが増えやすいという事情があった¹。

短くすること自体は悪くない。問題は、コード作業では「短さ」と「正しさ」が衝突する場面があることだ。

たとえば、複数ファイルにまたがる変更では、なぜその設計にしたのか、どの前提を置いたのか、どこまで検証したのかが重要になる。説明を短くしすぎると、モデル自身の作業も「雑な近道」に寄りやすくなる。

Anthropicは追加評価で、問題のプロンプト行がOpus 4.6とOpus 4.7の両方で3%の低下を示したと説明し、4月20日のリリースで取り消した¹。

ここでの教訓は単純だ。AIコーディングでは、短い返答が常に良い返答とは限らない。

ユーザー側の定量レポートは何を示していたか¶

公式発表の前に、GitHub Issueではかなり詳しいユーザー側レポートが出ていた。公式説明だけでは「ユーザーが何に困っていたのか」が見えにくいため、ここで体感側の記録も確認しておく。

代表的なのが、2026年4月2日に投稿されたIssue #42796だ。投稿者は、6,852個のClaude Codeセッションファイル、17,871個のthinkingブロック、234,760件のツール呼び出しを分析した。そのうえで、1月末から3月にかけて「調査してから編集する」動きが大きく減ったと報告している³。

このレポートは、すべてが公式に検証されたわけではない。とくに「thinkingの深さ」をローカルログから推定する部分には、表示上の非表示処理と実際の推論量を混同するリスクがある。

それでも、ユーザーが見ていた症状は公式ポストモーテムとよく重なる。

読まずに編集する
途中で理由を忘れる
同じ作業を繰り返す
使用量だけ速く減る
「簡単な修正」に逃げる

さらにHacker Newsでは、Claude CodeチームのBoris Cherny氏が、提出されたfeedback IDを読んだうえで、adaptive thinkingに触れている⁴。 adaptive thinkingは、ターンごとに必要な推論量を自動で調整する仕組みだ。 Cherny氏は、その仕組みが特定ターンで推論を少なく割り当てていた可能性を示した。この点は4月23日の公式ポストでは中心論点になっていないが、当時のユーザー体感を理解する補助線にはなる。

一次情報を読むときは、公式ポスト、Changelog、GitHub Issue、HNコメントの重みを分ける必要がある。 公式に確定した原因と、ユーザー観測からの仮説を混ぜないことが大事だ。

以前のトークン消費記事はどこまで正しかったか¶

ここで検証しているのは、過去に公開した「Claude Codeのトークン消費が異常に速い──3つの原因とソースコード流出が裏付けたキャッシュバグ」という記事だ。結論から言うと、方向性としてかなり当たっていた。

特に、Claude Codeのコスト構造がプロンプトキャッシュに強く依存しており、キャッシュが効かないと同じ会話でも使用量が跳ね上がる、という説明は公式ポストモーテムで補強された。 Anthropic自身が、thinking削除バグによってキャッシュミスが起き、使用制限が速く減る報告につながった可能性を認めている¹。

GitHub Issue #34629にも、--print --resume で cache_read が伸びない再現報告がある。会話履歴が毎回新規処理される、という内容だ。このIssueは area:cost、regression、bug として扱われ、2026年4月1日に完了扱いで閉じられている⁵。

一方で、記事内の「ソースコード流出でキャッシュバグの技術的原因が裏付けられた」という表現は、今なら弱めた方がよい。

ソースコード流出自体は、Anthropic広報が「リリースパッケージの人為ミスで内部ソースコードが含まれた」と認めている⁶。しかし、流出コードから読み取られたattestationやanti-distillationのような仕組みが、今回の公式ポストモーテムで説明された根本原因だとAnthropicが認めたわけではない。

現時点で安全な言い方はこうだ。

以前の記事は「キャッシュが壊れると使用量が異常に速く減る」という構造を正しく捉えていた。ただし、流出コードから推測された原因候補は公式確認済みではない。 4月23日の公式説明では、thinking履歴削除バグが主要原因として示された。

この補正を入れれば、過去記事はむしろ今回の記事への良い導線になる。

いまClaude Codeユーザーが確認すべきこと¶

まず確認すべきなのは、Claude Codeのバージョンとeffort設定だ。

Anthropicは、3つの問題は2026年4月20日のv2.1.116時点で解消済みと説明している¹。その後のChangelogでは、4月22日のv2.1.117で Pro/Max購読者向けのデフォルトeffort変更も記録されている²。

実務では、次の4点を見ればよい。

最新版に更新する。少なくともv2.1.116以降を前提にする
/effort を確認する。複雑な実装では high 以上を使う
古い長時間セッションを疑う。挙動が変なら新規セッションで再現を見る
体感だけで判断しない。/usage、/bug、再現手順を残す

ここで大切なのは、Claude Codeを「全部信用する」か「全部捨てる」かの二択にしないことだ。今回の問題は、AIコーディングツールがモデル性能だけでなく、CLI、キャッシュ、プロンプト、リリース運用の上に成り立っていることを示した。

まとめ¶

今回の件で一番重要なのは、AIモデルの品質と、AIコーディング製品の品質は同じではないという点だ。

Claude Codeは、モデル、ツール実行、ファイル編集、セッション管理、プロンプトキャッシュ、システムプロンプトを組み合わせた製品である。どれか1つが少しズレるだけで、ユーザーには「モデルが劣化した」と見える。

これはAnthropicだけの問題ではない。 Codex、Cursor、GitHub Copilot、Gemini CLIでも、同じように「モデルそのもの」と「ハーネス」の切り分けが必要になる。ここでいうハーネスとは、モデルを動かすCLI、ツール実行、セッション管理、プロンプトなどの周辺実行環境のことだ。

次に同じような違和感が出たときは、まずこう考えるとよい。

モデルが変わったのか
effortやthinking設定が変わったのか
キャッシュやセッション再開が壊れていないか
システムプロンプトやツール方針が変わったのか

「AIが急に賢くなった／急にダメになった」という話は、これからも出る。そこで必要なのは、感情を否定することではない。 体感をログ・設定・リリースノートに接続して検証する習慣だ。

Claude Codeの品質低下は、気のせいではなかった。だが、単純な陰謀論でもなかった。今回見えたのは、AI開発ツールが本番インフラとして扱われ始めたときに避けられない、品質保証の難しさそのものだ。