AnthropicのApril 23 Postmortem — Claude品質低下を3つの独立バグから読み解く

背景 — 品質低下の訴えは三つの別々の変更だった

2026年4月23日、Anthropicはengineering blogに「An update on recent Claude Code quality reports」を公開しました。通称April 23 Postmortemです。3月初旬から寄せられていた「Claudeが鈍くなった」「同じことを繰り返す」「ツール選択が変だ」という報告を調べた結果、三つの別々の変更が原因だったという内容です。

影響を受けたのはClaude Code、Claude Agent SDK、Claude Coworkで、APIは対象外でした。三つの問題は4月20日(v2.1.116)までにすべて解消し、4月23日には全サブスクライバーの利用上限がリセットされています。

本稿は原文の主張を順にたどり、そのあとで日本企業の運用に置き換えられる点を編集視点としてまとめます。原文にない解釈は、後半の二つの節に分けて書きます。

推論努力の既定値をmediumにした判断と、その差し戻し

2月にOpus 4.6をClaude Codeで提供したとき、既定の推論努力は high でした。ところが high では考え込みが長くなりすぎてUIが固まったように見える利用者がいて、遅延とトークン消費も跳ね上がっていました。

そこで3月4日に既定を medium へ下げています。社内の評価では、medium は知能がわずかに下がる代わりに遅延が大きく減り、極端に長い思考も出にくいと見られていました。理由はアプリ内のダイアログで説明されています。

利用者の反応は想定と逆でした。「賢くなくなった」という声が続き、Anthropicは起動時の通知、インラインのeffort選択、ultrathink の復活といった改善を重ねています。それでも多くの利用者は medium のままでした。4月7日に既定が戻され、Opus 4.7は xhigh、ほかのモデルは high が既定になっています。影響を受けたのはSonnet 4.6とOpus 4.6です。

原文には、この判断を「誤ったトレードオフ」と認める一文があります。「簡単な作業だけ低いeffortに落とす」という選択を利用者に委ねるほうが好まれた、という整理です。

思考履歴が毎ターン消えたバグ

三つのうち、症状が最も複雑だったのが3月26日の変更です。Claudeの推論は会話履歴に残り、次のターンで「なぜその編集やツール呼び出しをしたか」を参照できます。この変更は、1時間以上アイドルだったセッションを再開するとき、古い思考を消して未キャッシュのトークンを減らすことを狙っていました。

実装には clear_thinking_20251015 というAPIヘッダーと keep:1 が使われています。再開時の1回だけ効くはずが、バグでセッションの残り全ターンで効き続けました。

物忘れ、同じ応答の繰り返し、不自然なツール選択、上限の急減という四つの症状が、一つのバグから説明されています。この変更はコードレビュー、単体テスト、E2Eテスト、自動検証、社内ドッグフーディングをすべて通過していました。

修正は4月10日のClaude Code v2.1.101で、影響を受けたのはSonnet 4.6とOpus 4.6です。修正が入ったのはクライアントであるClaude Codeなので、利用者側では該当版以降へ上げる必要があります。版の内容はClaude Code v2.1.101のリリースノートにまとめています。

ただしv2.1.101のchangelogにこのバグへ触れた項目はなく、--resume まわりの修正などが並んでいます。postmortemを先に読まないと、どの版で直ったのか分かりません。

「短く書け」の1行が評価を3%下げた

Opus 4.7は前世代より饒舌で、難しい問題に強くなる反面、出力トークンが増える性質がありました。Anthropicはリリース前の数週間、モデル訓練、プロンプト、思考表示のUXという複数の手段で冗長さを抑えており、システムプロンプトに次の指示を足しています。

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

数週間の社内テストで評価の退行は出ず、4月16日にOpus 4.7と同時に投入されました。その後、プロンプトから1行ずつ外して寄与を測るablationを行いました。より広い評価セットのうち1つがOpus 4.6と4.7の双方で3%低下を示し、4月20日のリリースで取り消されています。影響範囲はSonnet 4.6、Opus 4.6、Opus 4.7で、ほかのプロンプト変更との組み合わせも品質を下げたと書かれています。

三つの変更が時系列でどう重なったか

日付だけで見ると、3月26日から4月7日はeffortの低下と思考履歴のバグが同時に走っていました。4月16日からはプロンプト圧縮が加わります。Anthropicの言葉では、変更ごとに影響する利用者層も時期も違ったため、全体としては「ばらばらで一貫しない劣化」に見えました。

なぜ検出に時間がかかったのか

内部の利用や評価では最初、どの問題も再現しませんでした。思考履歴のバグには、これを隠した要因が二つあります。社内限定のサーバー側実験(メッセージのキューイングに関するもの)と、思考の表示方法に関する別の変更です。後者のおかげで、CLIの多くのセッションでバグが抑えられ、外部向けビルドを試しても見えませんでした。

しかも条件が「アイドルを一度越えた古いセッション」という隅のケースだったため、根本原因の特定と確認までに1週間以上かかっています。

転機になったのは、問題の変更を含むプルリクエストに対するCode Reviewのバックテストです。必要なリポジトリを文脈として与えると、Opus 4.7はこのバグを見つけ、Opus 4.6は見つけられませんでした。新しいモデルが過去のレビューの穴を突いた形です。

利用者側の入口になったのは /feedback コマンドと、再現例つきの投稿です。謝辞では、/feedback で報告した人と、再現例を公開で投稿した人が挙げられています。

公表された再発防止策

原文の「Going forward」は、次の項目を挙げています。

• 社内の使い方を揃える: 新機能を試す版ではなく、公開ビルドそのものを使う社員の比率を増やす
• Code Reviewの改善: 追加リポジトリを文脈に取り込めるようにして、改善版を顧客にも提供する
• システムプロンプトの変更管理: 変更ごとにモデル別の幅広い評価を回し、ablationを続け、レビューと監査のための新ツールを作った
• モデル固有の変更を限定する: 特定モデル向けの変更はそのモデルだけに効かせる、という指針をCLAUDE.mdに追記した
• 知能とのトレードオフがありうる変更: ソークテスト期間、広い評価セット、段階的なロールアウトを置く
• 情報の出し方: Xに @ClaudeDevs を新設し、同じ内容をGitHubの集約スレッドにも載せる

手元のClaude Codeで効き方を確かめる

postmortemで中心だったeffortは、今のClaude Codeでも利用者が直接触れる設定です。v2.1.289での出力は次のとおりです。

claude --version
# 2.1.289 (Claude Code)
 
claude --help | grep -A1 -- --effort
#   --effort <level>   Effort level for the current session
#                      (low, medium, high, xhigh, max)

選べるレベルはモデルで違います。公式docsでは、Opus 4.7・Opus 4.8・Opus 5・Opus 5.5・Sonnet 5・Sonnet 5.5が low から max までで、xhigh を含みます。Fable 5とFable 5.1も同じです。Opus 4.6とSonnet 4.6は xhigh なしの4段階で、xhigh を指定すると high で動きます。

既定値はモデルごとに決まります。Opus 4.7が xhigh、Opus 5.5とSonnet 5.5が medium、そのほかは high です。組織が組織既定モデルの既定effortを設定している場合は、そのレベルが既定になります。実際に使われるレベルは次の順に決まります。

1. 環境変数 CLAUDE_CODE_EFFORT_LEVEL、起動時の --effort、セッション中の /effort
2. 設定ファイルに保存したレベル(effortLevel キーなど。Opus 5.5ではユーザー設定のトップレベル effortLevel は対象外)
3. モデルの既定値

3月4日の変更は、この3番目を製品側が書き換えたものでした。現在の決定順では、1番目と2番目で自分の値を決めている場合はそちらが既定値より優先されます。Opus 5.5以降は /effort か /model のピッカーで選びます。品質のばらつきを抑えたい運用では、チームで値を固定するという手があります。

日本のエンタープライズが学べるオペレーション知見

ここからは原文にない編集視点です。第一に、内部利用と顧客利用のずれは静かに広がります。今回、社員が使うビルドと公開ビルドは別物で、そのずれが評価で拾えない症状を生みました。社内で生成AIを業務に組み込むなら、検証担当の使い方が現場の使い方に近いかを定期的に見直す必要があります。Claude Codeの運用設計はClaude Code auto modeの設計が参考になります。

第二に、複合バグはフラグの組み合わせで隠れます。単独では再現せず、組み合わさると壊れる症状は、実験フラグが多い組織ほど出ます。品質低下の報告が来たとき、どのフラグが同時にONだったかを遡れる一覧が要ります。

第三に、「短く」「速く」の指示は思考の質に響きます。今回の3%は評価セットの一部で見えた数字ですが、システムプロンプトに語数の上限を入れるときは、短文タスクと推論タスクに分けた評価が要ります。原文の指示にも「必要ならもっと詳しく」の但し書きが付いていました。

第四に、推論努力の既定値は契約条件に近い扱いにできます。利用者側の体感は、モデル名の違いだけでなく既定のeffortにも左右されます。どのモデルを既定でどのレベルにするかを、チームで決めて固定しておきます。xhigh の位置づけはClaude Opus 4.7 xhighとはで扱っています。

postmortem文化を社内に取り込む順番

今回のpostmortemは、三つの変更を混ぜずに節を分けて書いた構成が価値の中心です。「失敗を責めない雰囲気」の話より前に、事象を独立に切り分けて書く規律が置かれています。

現実的な導入順は、軽微なインシデントでタイムラインだけを書くところからです。それが定着したら要因の切り分けを足し、再発防止の分類を足します。公開するかどうかは最後に決めれば足ります。

まとめ

読者が手元に持ち帰る点は二つあります。推論努力、キャッシュまわりの最適化、システムプロンプトの圧縮指示は、品質を下げながら評価に出にくい三つの変更でした。自社でAIを組み込むときは、この三つを変更管理の対象に入れる価値があります。

もう一つは、体感の悪化を調べるときの順番です。使っている版と、そのときのeffortの値を先に特定すると、原因の候補が絞れます。コンテキストと推論パラメータの設計が体感品質を作るという見方は、context engineeringの考え方と地続きです。