$ cat ./blog/claude-code-quality-postmortem-202604.md
Claude Code 品質劣化のポストモーテム(2026-04-23)— 3 つの独立変更が重なった顛末と対応 Anthropic が 2026-04-23 に Claude Code の品質劣化を公式に認めるポストモーテムを公開しました。原因は 3 月〜4 月にかけて入った 3 つの独立した変更(既定 effort の引き下げ、セッションキャッシュのバグ、システムプロンプトの語数制限)が重なったもの。Claude API は影響対象外。全サブスクライバの usage limit がリセットされています。事実関係と、ユーザー側で確認すべき行動、再発防止策をまとめます。
author r43
date 2026-04-25 (2026年4月25日)
reading 5 min
commit 5eda8d5 Anthropic が 2026-04-23 に「An update on recent Claude Code quality reports 」を公式 engineering blog に掲載しました。最近 Claude Code が調子悪い と感じていた開発者の体感を裏付ける内容で、3 つの独立した変更が 3 月〜4 月に重なって品質を押し下げていた ことが公式に認められました。2025-09 の API 品質劣化ポストモーテムに続く 2 度目の公式謝罪 という位置づけです。
本記事では、事実関係の整理、影響範囲の切り分け、ユーザー側で確認すべきこと、そして運用上の教訓をまとめます。
到達点
何が劣化していたか 、いつ発生し、いつ直ったかを把握する影響範囲 を正しく切り分ける(Claude API は対象外)自分のアカウントが受けた影響と、いま取るべき行動
Anthropic 側の再発防止策から拾える、LLM プロダクト運用の教訓
影響範囲 — ここが一番大事
公式発表で明示的に区別 されています。
サーフェス 影響 Claude Code (CLI / IDE 拡張)✅ 影響あり Claude Agent SDK ✅ 影響あり Claude Cowork (Claude.ai 内のエージェント製品)✅ 影響あり Claude API (直接呼び出し)❌ 非該当
つまり、自作アプリから Claude API を直叩きしている場合は影響なし 。Claude Code などの Anthropic 製エージェントハーネスを経由していた場合だけ品質劣化が起きていました。自分のサービスの品質問題を疑う前に、まずどの経路で Claude を呼んでいるか を確認すると切り分けが速いです。
3 つの独立した原因
原因 1: デフォルト reasoning effort の引き下げ(3/4 導入 → 4/7 revert)
UI が固まるほどの長レイテンシ苦情を受け、Claude Code の既定 reasoning effort を high → medium に下げた のが最初の変更。しかしユーザーは速度よりも知性を好む というフィードバックが多数寄せられ、4/7 に revert されました。
現在の既定値は公式に Opus 4.7 = xhigh、それ以外のモデル = high に明示されています(本ブログ #12「Opus 4.7 の破壊的変更」でも触れた値)。
原因 2: セッションキャッシュのバグ(3/26 導入 → 4/10 修正)
「1 時間以上アイドルだったセッションでは古い thinking ブロックをクリアする」最適化が 3/26 に投入されました。しかしバグにより、条件に一致したセッションで以降の全ターンでも毎回 thinking がクリアされ続ける 状態に陥り、Claude が以前の推論を保持できず、“forgetful / repetitive” の症状を示しました。
影響モデル: Claude Sonnet 4.6 / Opus 4.6
ユーザーへの副作用: 同じ説明を繰り返す、文脈を取り戻すために使用量上限を無駄に消費
修正: 4/10
原因 3: システムプロンプトの語数制限(4/16 導入 → 4/20 revert)
「tool 呼び出しの合間のテキストを 25 words、最終応答を 100 words に抑える」指示を 4/16 に追加(Opus 4.7 のリリースに合わせて投入)。冗長な前置きを減らす意図でしたが、他のプロンプト変更と組み合わさって、Anthropic の社内評価で Opus 4.6 と Opus 4.7 でそれぞれ約 3% のコーディング品質低下 が観測されました。
影響モデル(公式に数値が明記): Opus 4.6 / Opus 4.7
修正: 4/20 の Claude Code v2.1.116 で revert
タイムライン
2026-03-04 ─ 原因 1 投入 (effort high → medium) 2026-03-26 ─ 原因 2 投入 (セッションキャッシュ最適化のバグ) 2026-04-07 ─ 原因 1 revert (effort の既定を戻す) 2026-04-10 ─ 原因 2 修正 (キャッシュクリアのバグ fix) 2026-04-16 ─ 原因 3 投入 (語数制限プロンプト追加、Opus 4.7 リリースと同時) 2026-04-20 ─ 原因 3 revert (v2.1.116) 2026-04-23 ─ 公式ポストモーテム公開 + 全サブスクライバの usage limit リセット ユーザー側で確認すべきこと
Claude Code を v2.1.116 以降に更新
原因 3 の revert を含むバージョン
古いまま残っていると、挙動の一部が旧プロンプトベースのまま
usage limit はリセット済
期間中に原因 2 の影響で消費された分を Anthropic 側で補償
明示的な申請は不要、サブスクライバ全員が対象
ログを振り返って、期間中の出力を信頼しすぎない
特に 3 月下旬〜4 月中旬に Sonnet 4.6 / Opus 4.6 を使った複雑なタスクで、成果物を「なんとなく微妙」と感じていたなら、条件を揃えて再実行 してみる価値あり
Claude API を直叩きしていたなら影響なし
自作の Anthropic SDK 経由のコードは、このインシデントの影響対象外
「Claude が最近調子悪い」という SNS の声
4/10 以前の発言 → 原因 2 を疑う
4/16 〜 4/20 の発言 → 原因 3 を疑う
4/7 以前の「遅いのにボケてる」発言 → 原因 1 + 2 の重なり
Anthropic 側の再発防止策
公式発表で明示された 3 つ:
評価スイートの拡充
段階的ロールアウトの導入
新しいプロンプトや設定変更を一気に 100% 展開しない
内部 Code Review ツールの改善
今回の原因 2 のようなバグを merge 前に捕まえる仕組みの強化
LLM プロダクト運用の教訓
このインシデントから外部の開発者が拾える学びは、3 点あるように思えます。
複数の品質変数は独立して小さく変更する 。3 つの独立変更が重なって初めて顕在化した劣化は、それぞれ単独ではテストで通っていた可能性が高い。同時期に複数の “見えない” 変更を入れると原因の切り分けが爆発的に難しくなる 「短く答えさせる」は思考量そのものを削ることがある 。原因 3 はその典型で、出力長の制限はコーディング品質とトレードオフになりうる 。本ブログ #12 でも触れた effort / xhigh の存在とあわせて、“短く” より “効率的に長く” を積極的に選ぶ設計のほうが安定しやすいセッションを長く回す最適化はキャッシュの等価性を壊しやすい 。「古い情報を消す」最適化は、何が “古い” かの判定を間違えると、必要な情報を捨てる 方向に暴走しうる。本ブログ #14「Context Compaction」でも同系統の footgun を扱ったばかりで、セッション永続系の最適化は慎重に評価する のが今の業界の共通認識になりつつある
まとめ
今回のポストモーテムは、自分の観測が気のせいではなかった と確認したい開発者にとっては朗報であり、同時に Anthropic が品質問題を公式に認めて透明性を示すという点で意味のあるアナウンスでした。ユーザー側で必要なのはClaude Code を v2.1.116 以降に更新 しておくこと、あとは 4/23 リセット済みの usage 枠の範囲で普段の使い方に戻るだけです。
release notes タグで Anthropic のリリース解説を追っています。次の候補は Programmatic Tool Calling または Memory Tool を予定しています。
参考
$ tree ./repo/
記事で登場したコードをひとつの最小リポジトリとしてまとめました。ファイルツリーから切り替えて、全体の構造をそのまま確認できます。
┌─ claude-code-quality-postmortem-202604 ────────── files 05 ────────────────────── ● ● ● ─┐ $ cat ./README.md markdown
# 影響マトリクス — モデル × 期間 × 症状 Claude Code / Agent SDK / Cowork 経由での利用に限定した影響範囲。 **Claude API を直接呼んでいる場合は全項目 "影響なし"。** ## 表 | モデル | 3/4 - 4/7 (原因 1) | 3/26 - 4/10 (原因 2) | 4/16 - 4/20 (原因 3) | |---|---|---|---| | **Claude Opus 4.7** | (4/16 リリース、対象外) | — | ✅ ≈3% 低下(公式実測) | | **Claude Opus 4.6** | ✅ effort 低下 | ✅ forgetful / repetitive | ✅ ≈3% 低下(公式実測) | | **Claude Sonnet 4.6** | ✅ effort 低下 | ✅ forgetful / repetitive | ⚠ 公式に数値記載なし | | **Claude Sonnet 4.5** | ✅ effort 低下 | — | ⚠ 公式に数値記載なし | | **Claude Haiku 4.5** | ✅ effort 低下 | — | ⚠ 公式に数値記載なし | > 原因 1 は Claude Code 全体の既定 effort を下げたため、Claude Code 経由で動いた全モデルに共通して影響(Opus 4.7 は 4/16 リリースのため対象外)。 > 原因 2 は長時間セッションの thinking キャッシュに関するバグで、公式は Sonnet 4.6 / Opus 4.6 を対象として明記。 > 原因 3 のシステムプロンプトは Opus 4.7 リリース(4/16)と同時に投入された全 Claude Code 利用モデル横断の変更だが、 **公式が "3% 低下" と数値を出しているのは Opus 4.6 / Opus 4.7 のみ** 。Sonnet / Haiku 系の影響度は本ポストモーテム公開時点で言及なし。 ## 「いつから調子悪い」の声をどう読むか - **3/4 〜 4/7** の間に「レスポンスは速いが雑になった」系の発言 → 原因 1 の可能性が高い - **3/26 〜 4/10** の間に「会話の序盤と終盤で別人のようになる」「同じ説明を何度もされる」 → 原因 2 - **4/16 〜 4/20** の間に「一言だけで済ませる」「コード説明が異様に短い」 → 原因 3 - **4/7 以前** から続いていた「遅い上にボケる」 → 原因 1 + 2 の重なり ## 影響が **なかった** もの - **Claude API を直接叩いているコード** (raw HTTP / 公式 SDK を直接使用) - モデルの重み自体は変わっていない(ハーネス側の挙動変更) - 課金・データ保持ポリシー・プライバシーポリシー等の契約面 # LLM プロダクト運用側の教訓 このインシデントから、自分で LLM を使ったプロダクトを運用している側が 再利用できる学びを 5 点に絞ってまとめます。 ## 1. 複数の品質変数は独立して小さく変更する 3 つの独立変更が重なって初めて顕在化した劣化は、 **単独ではテストで通っていた** 可能性が高い。 品質が目に見えにくい LLM プロダクトでは、 **同じ日に 2 つ以上の挙動変数を動かさない** のが基本の防御。 - Claude のモデル変更 - システムプロンプトの変更 - reasoning effort / thinking の既定値変更 - セッション管理・キャッシュ戦略の変更 - tool 定義・順序・数の変更 上記 5 軸は「どれか 1 つだけを動かす」と決めておくと、回帰の原因特定が圧倒的に速い。 ## 2. 「短く答えさせる」は思考量そのものを削ることがある 原因 3 はその典型で、 **出力長の制限 = コーディング品質とのトレードオフ** になりうる。 `effort: "xhigh"` の存在とあわせて、 **"短く" より "効率的に長く"** を積極的に選ぶ設計のほうが安定しやすい。 - tool 合間の前置きを消したい → システムプロンプトで `prose_budget = N words` のような数値強制は危険 - 代わりに **effort を下げる** 、または **プロンプトを具体的な例示で誘導** する - 最終応答の長さは **UI 側でトリミング** する方が安全(モデルに "短く考える" ことを要求しない) ## 3. セッション永続系の最適化はキャッシュの等価性を壊しやすい 「古い情報を消す」最適化は、 **何が "古い" かの判定を間違えると必要な情報を捨てる** 方向に暴走しうる。 本ブログの Context Compaction(claude-context-compaction)でも同系統の footgun を扱ったばかりで、 **セッション永続系の最適化は慎重に評価する** のが今の業界共通認識。 - thinking キャッシュの無効化タイミングは、 **副作用が必ず「忘れる」方向** であることを意識 - アイドル時間ベースの無効化なら、 **無効化発火頻度を metric に出す** - ユーザーが明示的に "続き" を要求していたら、キャッシュを強制的に保持する例外経路を用意 ## 4. 段階的ロールアウト(canary)を "プロンプト変更" にも適用する インフラの段階ロールアウトは当たり前のように使われているが、 **システムプロンプトの変更** も同じ段階ロールアウトの対象にする価値がある。 - まず 1% のユーザーに適用、品質メトリクスを監視 - 有意な劣化が出なければ 10% → 50% → 100% と広げる - Anthropic 自身も再発防止策として「段階的ロールアウトの導入」を挙げている ## 5. 品質メトリクスを「タスク分類別」に持つ 全体の平均スコアでは、 **特定のタスクタイプだけ落ちている** ことに気づきにくい。 - コーディング - 数学推論 - 要約 - 分類 / 抽出 - エージェント長期タスク 最低このくらいの軸で **定期ベンチ** を走らせ、変更ごとに差分を観察する。 原因 3 の「コーディング品質 ≈3% 低下」は、こういうタスク分類別メトリクスでないと気づきにくい量。 --- ## 参考 - [ An update on recent Claude Code quality reports ]( https://www.anthropic.com/engineering/april-23-postmortem ) — 一次ソース - [ A postmortem of three recent issues (2025-09) ]( https://www.anthropic.com/engineering/a-postmortem-of-three-recent-issues ) — 前回の API 品質ポストモーテム、背景文脈として有用 # claude-code-quality-postmortem-202604 — 補助資料 [ 記事本文 ]( https://r43lab.com/blog/claude-code-quality-postmortem-202604 ) の補助資料です。 このスニペットはコードではなく、 **ユーザーが自分の状況を点検するためのチェックリストとタイムライン** を記述ファイルで提供します。 ## 含まれるもの - `TIMELINE.md` — 原因 1 / 2 / 3 の導入・修正日付をカレンダー順に整理 - `USER_CHECKLIST.md` — 読者が自分のアカウント・プロジェクトで確認すべき項目の一覧 - `AFFECTED_MATRIX.md` — 「どのモデル × どの期間」に何の影響があったかを一覧化 - `LESSONS.md` — LLM プロダクト運用側の教訓を再利用できる形で切り出したメモ すべて Anthropic の公式ポストモーテム (< https://www.anthropic.com/engineering/april-23-postmortem >) の記述を一次ソースとし、 r43lab 側で日本語の運用視点に翻案したものです。 **公式発表の代替ではなく補助** としてご利用ください。 # タイムライン(2026-03-04 〜 2026-04-23) Anthropic 公式ポストモーテム < https://www.anthropic.com/engineering/april-23-postmortem > に基づく、 3 つの独立した変更がもたらした Claude Code 品質劣化の時系列。 ## 概観 ``` │ Mar Apr │ ─ 04 ─── 26 ── 07 ── 10 ───── 16 ── 20 ── 23 ── │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ └─ ポストモーテム公開 + usage リセット │ │ │ │ │ │ └─ 原因 3 revert (Claude Code v2.1.116) │ │ │ │ │ └─ 原因 3 投入 (システムプロンプトの語数制限) │ │ │ │ └─ 原因 2 修正 (セッションキャッシュのバグ fix) │ │ │ └─ 原因 1 revert (effort の既定を戻す) │ │ └─ 原因 2 投入 (セッションキャッシュ最適化のバグ) │ └─ 原因 1 投入 (effort high → medium) ``` ## 日付別 | 日付 | 出来事 | 影響 | 対応 | |---|---|---|---| | 2026-03-04 | 原因 1 投入 — Claude Code の既定 reasoning effort を `high` → `medium` に変更 | レイテンシ改善と引き換えに知性が落ちた(遅延苦情 → ユーザーは速度より知性を選好) | — | | 2026-03-26 | 原因 2 投入 — アイドル 1h 以上のセッションで古い thinking をクリアする最適化。 **バグあり** | Sonnet 4.6 / Opus 4.6 で "forgetful / repetitive" な挙動。使用量を不当に消費 | — | | 2026-04-07 | **原因 1 revert** — effort の既定を戻す | 既定値は Opus 4.7 = `xhigh` 、他は `high` | ユーザー側対応不要 | | 2026-04-10 | **原因 2 修正** — セッションキャッシュクリアのバグ fix | forgetful 症状は収束 | ユーザー側対応不要 | | 2026-04-16 | 原因 3 投入 — tool 合間テキスト 25 words / 最終応答 100 words のシステムプロンプト追加 | Sonnet 4.6 / Opus 4.6 / Opus 4.7 でコーディング品質 ≈3% 低下 | — | | 2026-04-20 | **原因 3 revert** — Claude Code **v2.1.116** リリース | 語数制限を除去 | **v2.1.116 以降に更新を推奨** | | 2026-04-23 | 公式ポストモーテム公開 + **全サブスクライバの usage limit リセット** | 期間中に原因 2 で消費された分を補償 | 追加申請不要 | # ユーザー側チェックリスト Claude Code / Claude Agent SDK / Claude Cowork を使っていた場合、 以下を一度通して確認すると状況が整理できます。 ## 必須 (即時) - [ ] **Claude Code を v2.1.116 以降に更新** - 例(CLI): `npm install -g @anthropic-ai/claude-code@latest` または `brew upgrade claude` - IDE 拡張は Marketplace から最新を適用 - [ ] **現在の既定 effort を確認** - Opus 4.7 を使っているなら `xhigh` 、それ以外なら `high` が既定で戻っている想定 - [ ] **使用量上限(usage limit)のリセットを確認** - 明示的な申請は不要(4/23 にサブスクライバ全員へ一括適用) - ダッシュボード / 請求画面で残量が通常レベルに戻っているか目視 ## 自分の影響範囲を切り分ける - [ ] **Claude API を直接呼んでいる自作アプリは対象外** (今回は影響なし) - [ ] **Claude Code / Agent SDK / Cowork 経由のワークフローは対象** - 3/26 〜 4/10 → 原因 2(キャッシュバグ)の影響を受けた可能性 - 4/16 〜 4/20 → 原因 3(語数制限)の影響を受けた可能性 - 3/4 〜 4/7 → 原因 1(既定 effort 低下)で全体的に知性が落ちていた可能性 ## 過去のアウトプットの見直し(任意) - [ ] 期間中に **Sonnet 4.6 / Opus 4.6** で回した複雑なコーディングタスクをリストアップ - [ ] 「なんとなく微妙」だった成果物を、 **同じプロンプト・同じ条件** で再実行して比較 - [ ] 大きな差分が出た作業は、ドキュメントを更新 ## 今後の運用(推奨) - [ ] **定期的に Claude Code の changelog を確認** する習慣 - < https://code.claude.com/docs/en/changelog > - [ ] 業務利用なら **Claude Status のサブスクリプション** を購読 - < https://status.claude.com/ >(RSS あり) - [ ] 品質変動を感じたら、 **Claude API を直叩きする形** で同プロンプトを試して切り分け - Claude Code ハーネス側の設定が変わったのか、モデル自体が変わったのかを判別しやすくなる slug claude-code-quality-postmortem-202604│ files 5 click a file in the tree to switch