Claude Code品質低下postmortem(2026-04-23)— 3バグと運用の手当て

2026年4月23日にAnthropicがengineering blogで公開した「An update on recent Claude Code quality reports」は、3月初旬から4月にかけて寄せられていたClaude Codeの品質低下に対するpostmortemです。3つの独立した不具合が重なっていたこと、検出に時間がかかった理由、再発防止のために変える運用が、日付付きで整理されています。

本記事はこのpostmortemをClaude Codeを日常的に使っている利用者の目線で読み直し、「何が起きていたのか」「何が修正されたのか」「これから同じような症状が出たときに自分の手元でどう構えるか」までを1本にまとめます。技術的な背景は公式記事から引用しつつ、運用に組み込める観点に翻訳します。

公式記事に書かれていない数値や影響範囲は本記事でも断定せず、Anthropicが明示した事実のみを軸に進めます。

何が起きたか — 公式が認めた3つの独立不具合

Anthropicは事象を3つの別々の不具合が偶然重なったものと説明しています。「the API was not impacted(APIには影響していなかった)」と明記されており、症状はClaude Code・Claude Agent SDK・Claude Coworkの3製品に出ていたとされています。

3つの内訳は次の通りです。

利用者から見える症状は、Anthropic自身が次のように整理しています。

• 物忘れ(直前のやりとりを覚えていない挙動)
• 同じ応答や同じツール呼び出しの繰り返し
• 不自然なツール選択
• 利用上限(usage limits)が予想より早く減る

「Claudeが鈍くなった」「同じことを何度も聞き返してくる」「思っていたよりすぐ上限に達する」という体感は、いずれかのバグの直接の症状だったとAnthropicは認めています。

公式タイムライン

postmortemに記載された日付を、利用者目線で並べ直すと次の表になります。

3つの不具合は混入時期も修正時期もずれており、利用者から見ると「何かおかしいが、原因が一つに見えない」状態が約1か月半続いていたことになります。

個別バグの中身

1. 推論努力の既定値が下がっていた

Anthropicは、既定の推論努力を high から medium に下げた狙いを「occasional very long tail latencies(まれに発生する非常に長い末尾レイテンシ)」の改善と説明しています。UI凍結に近い長い待ち時間を避けるための変更でしたが、内部評価では「medium effort achieved slightly lower intelligence with significantly less latency(mediumは若干知能を落として大きくレイテンシを下げる)」と認識されていたとされており、利用者は速度よりも知能を優先していたという読み方ができます。

4月7日に既定値が戻り、Opus 4.7では新設の xhigh が既定になりました。他モデルは high に戻っています。

2. キャッシュ最適化のバグ — 「一度きり」が「毎ターン」になっていた

3つの中で最も技術的に込み入った話です。Anthropicは内部で clear_thinking_20251015 というAPIヘッダーと keep:1 の組み合わせで「セッションが1時間以上アイドルだったら、再開時に直近1ブロック以外の思考履歴を1回だけ捨てる」という挙動を実装していました。

実装に混入したバグは公式が次のように記述しています。

Instead of clearing thinking history once, it cleared it on every turn for the rest of the session.

(訳意: 思考履歴を1回だけ消すのではなく、そのセッションの残りの全ターンで消し続けた)

each request for the rest of that process told the API to keep only the most recent block of reasoning and discard everything before it.

(訳意: そのプロセス内の以降のリクエストはすべて、最も最近の思考ブロックだけを残してそれより前を全部捨てるようAPIに指示した)

ツール実行の途中で利用者が追記メッセージを送ったケースについては、公式は次のように補足しています。

If you sent a follow-up message while Claude was in the middle of a tool use, that started a new turn under the broken flag, so even the reasoning from the current turn was dropped.

(訳意: Claudeがツール実行の途中で追加メッセージを受け取ると、壊れたフラグ下で新しいターンが始まり、現在のターンの思考まで捨てられた)

結果として、Claudeは「continue executing, but increasingly without memory of why it had chosen to do what it was doing(実行は続けるが、なぜそうしていたのかの記憶を失っていく)」状態に陥ったと書かれています。さらに、思考ブロックが落とされ続けることで毎ターン キャッシュミスが起き、上限消費が予想より速くなる二次症状も併発していました。

検出が遅れた理由は、Anthropic自身が次の2点を挙げています。

• 別領域のサーバー側実験(メッセージキューイング関連)が動いていた
• 思考表示の見せ方を変える別の変更が、ほとんどのCLIセッションで本バグの症状を覆い隠していた

「アイドル1時間以上」という発火条件と、無関係な2つの実験が偶然のフィルタとして機能していたために、社内の通常利用では再現しなかった形です。Anthropicは「it took us over a week to discover(発見に1週間以上かかった)」と認めています。

修正は4月10日、Claude Code v2.1.101周辺で投入されています。

3. システムプロンプトの「短く書け」指示が知能を削っていた

4月16日に追加されたシステムプロンプト行は公式に引用されています。

Length limits: keep text between tool calls to ≤25 words. Keep final responses to ≤100 words unless the task requires more detail.

(訳意: 長さ制限。ツール呼び出し間のテキストは25語以下、最終応答は100語以下を保つ。ただしタスクが詳細を要する場合を除く)

レスポンスを引き締める狙いだったと読めますが、内部のablation(寄与度分析)では、Opus 4.6 / Opus 4.7ともに3%程度のスコア低下が観測されたとされています。Anthropic自身も「after multiple weeks of internal testing and no regressions in the set of evaluations we ran(数週間の社内テストと、回しているevalで回帰が出ていなかったにもかかわらず)」と書いており、評価スイートを通過しても利用者体感を損なう変更がある事実が記録に残った形です。

該当行は4月20日に撤回され、Claude Code v2.1.116周辺で本番から消えています。

どこまで何が直ったか(利用者視点での影響範囲)

公式記述だけから確実に言える範囲を整理すると、4月23日時点で次の状態に戻っています。

• 推論努力の既定は high(Opus 4.7では xhigh)
• キャッシュ最適化のバグ修正済み、思考履歴が毎ターン捨てられる挙動は終了
• システムプロンプトの圧縮指示は撤回済み
• 全有料プラン契約者の利用上限をリセット

ここで注意したいのは、AnthropicはAPIと推論レイヤーは影響を受けていなかったことを明示している点です。「we were able to immediately confirm that our API and inference layer were unaffected(APIと推論レイヤーは影響を受けていないことを即座に確認できた)」とあり、モデルそのものの能力低下ではなく、Claude Codeのアプリケーション側で起きた3件の独立した不具合だったというのが公式の見解です。

「2月から4月にかけてClaudeのモデル自体が劣化した」という解釈は、本postmortemの内容とは整合しないことになります。

検出を支えた仕掛け — 自社モデルでコードレビュー

postmortemにはひとつ印象的な出来事が記されています。Anthropicが社内のコードレビューツールを使い、問題のあったプルリクエストを Opus 4.7 と Opus 4.6 の両方で再審査したところ、「Opus 4.7 found the bug, while Opus 4.6 didn't(4.7はバグを発見し、4.6は見逃した)」という結果が出たとされています。

これは「新モデルで過去変更を再点検する」運用が品質維持に効くという経験的な事実が、AIプロダクト企業の内部で記録された例です。利用者側にとっても、CI上で Opus 4.7 にコードレビューさせる構成はclaude-code-actionベースのGitHub Actions連携で組み立てられます。

Anthropicが公表した再発防止策

postmortem後半に書かれている再発防止策は、4つの軸に整理できます。

開発環境

• 社員が公開ビルドのClaude Codeをそのまま使う比率を上げる
• 社内のコードレビュー機能の能力を強化する

システムプロンプト変更のガバナンス

• すべての対象モデルで包括的な評価を必須化
• 1行ごとの寄与度を切り分けるablationを継続
• プロンプト変更のレビュー / 監査ツールを新規構築
• CLAUDE.md にモデル固有変更のgating要件を追記
• 知能とトレードオフしうる変更にはソーク期間 / 広い評価セット / 段階的ロールアウトを適用

コミュニケーション

• 製品意思決定の説明用にX上で @ClaudeDevs を新設
• GitHubで集約スレッドを運営

これらはAnthropic側のプロセス変更ですが、利用者にとっての受け取りどころは「Anthropicが品質に関する情報発信チャネルを増やした」点です。これまでは公式blogとchangelogが主軸でしたが、@ClaudeDevsの追加で運用上のシグナルを拾いやすくなりました。

同じような症状が出たときの自衛策

postmortemは「直った」までを書いたものなので、利用者側で次に似た症状が出たときに何を確認するかは別に持っておく価値があります。今回の3バグから引き出せる観点をまとめます。

ここで効くのは、「自分の体感が変わったタイミング」を日付付きで残しておく習慣です。/feedback で投げるときも、いつから / どのバージョンから / どんなタスクで症状が出たかを書けると、Anthropic側でも今回のような複合バグを切り分けやすくなります。

加えて、長時間セッションで運用する開発フローでは、Claude Code auto modeの整備状況や長時間エージェントのharness設計で扱われた「セッション再開時の挙動」が、今回のキャッシュバグと同じ層で利用者品質に影響することを意識しておくと、次に同種の問題が出たときの理解が早くなります。

Anthropicが残した暫定的な含意

本postmortemから、Anthropicが暗黙に認めたことが2つあると読めます。公式は明示していないため、推測として読むのが妥当です。

第一に、評価スイートを通過しても利用者体感が落ちることがある。圧縮指示の3%低下は、社内テストでは回帰として検知できなかったとAnthropicは認めています。評価指標が体感とずれるケースは、AIプロダクト全般で起きうる現象です。

第二に、実験フラグの組み合わせは複合症状を覆い隠す。2つの無関係な変更がキャッシュバグの症状を多くのCLIセッションで隠していたという記述から、フラグ間の相互作用は事前に列挙しきれないことが示唆されます。利用者側からはコントロール不能ですが、「いつもと違う」と感じたらフラグ環境が違うクライアント / セッションで再現確認するのは現実的な切り分け手段になります。

まとめ

Anthropicの「April 23 Postmortem」は、Claude Code・Agent SDK・Coworkで起きた3つの独立した不具合と、検出までに1か月以上かかった理由を、技術的な詳細レベルで公開した文書です。APIと推論レイヤーは影響を受けていなかったことが明示されており、症状はあくまでアプリケーション層の3バグの組み合わせだったというのが公式見解です。

利用者にとっての要点は次の3つです。4月23日時点で3バグはすべて修正済みで、有料プランの利用上限もリセットされています。今後同じような体感劣化を感じたときには、推論努力 / キャッシュ挙動 / システムプロンプト変更の3点に着目して切り分けると、Anthropic側へのフィードバックも具体的に書けます。Claude Codeを業務フローに組み込むほど、こうした品質シグナルを拾う運用そのものが、長期の品質を支える資産になっていきます。

Anthropicが新たに @ClaudeDevs とGitHubの集約スレッドを運用に追加したことで、品質トピックを追える情報源は増えました。普段から見るチャネルを少し広げておくのが、次回の早期把握につながりそうです。