こんにちは、パレイド技術部です。
Anthropic が Claude Code の品質低下に関する postmortem を 2026-04-23 (現地時間) に公開する予定です。タイトルは “An update on recent Claude Code quality reports”。3 月から 4 月にかけて報告されていた「Claude Code が以前より物覚えが悪い」「無駄にツールを叩く」「同じ作業を何度も繰り返してトークンが尽きる」といった一連の症状について、3 つの独立した変更が重なって起きていた、という内容です。
pareido.jp でも 4 月の特定期間に、単純な移植作業でハルシネーションが多発したり、関係ないファイルが書き換わったり、無駄なテストが件数だけ水増しされたり、同じファイルを毎ターン読み直してトークンが急速に減ったり、という挙動を観測していました。当初は「Opus 4.7 への移行期で何か問題が起きているのか」と考えていたのですが、実際に性能の低下が起こっていたようです。
本記事は LLM による自動執筆パイプラインで生成されました。現在は人間が補助していますが、pareido.jp では最終的に AI が自律的にコンテンツを制作できる仕組みの構築を目指しています。
3 件の独立した変更を一望する
postmortem では、品質低下を引き起こした 3 つの変更が時系列で示されています。それぞれ独立して導入され、独立して撤回されたため、ユーザー側からは「いつから何が悪いのか」が見えづらい状態でした。
| # | 変更日 | 撤回・修正日 | 影響モデル | 主な症状 |
|---|---|---|---|---|
| 1 | 2026-03-04 | 2026-04-07 | Sonnet 4.6 / Opus 4.6 | reasoning effort の既定値が high → medium に下がり、推論の深さが浅くなる |
| 2 | 2026-03-26 | 2026-04-10 (v2.1.101) | Sonnet 4.6 / Opus 4.6 | キャッシュ最適化のバグで、毎ターン thinking ブロックが消える。物忘れ・繰り返し・キャッシュミス・トークン浪費 |
| 3 | 2026-04-16 | 2026-04-20 | Sonnet 4.6 / Opus 4.6 / Opus 4.7 | システムプロンプトに「25 単語以下」制約が追加され、コーディング品質が約 3% 低下 |
3 件すべての修正が入った最終的なリリースは 2026-04-20 の v2.1.116 です。API 経由での Claude には影響がなく、Claude Code / Agent SDK / Claude Cowork といったハーネス側の問題でした。
#1 reasoning effort のデフォルト降格
最初の変更は 2026-03-04、Claude Code のデフォルトの reasoning effort を high から medium に下げたものです。狙いは UI フリーズの緩和でした。Thinking ON で high を使うと最初のトークンが返るまで時間がかかり、ユーザーから「フリーズしたように見える」というフィードバックがあった、というのが背景です。
この問題自体は技術部としては体感ではわかりにくいものでした。他のモデルもそうですが、「応答が返らない」と思ったら単に思考が長いだけだった、という経験から並列で指示を走らせているため、さほど気にならなかったのかもしれません。UI 側の体感を改善したかったという気持ちは理解できます。
ただ、Claude Code は対話 UI ではなくコーディング・エージェントです。深い推論を要求するワークフローで medium に引かれていれば、当然解の質は落ちます。Anthropic 自身が postmortem で “This was the wrong tradeoff” と認めており、2026-04-07 にデフォルトを戻しています。Opus 4.7 は xhigh、その他は high です。
#2 キャッシュ最適化のバグ — pareido.jp の症状と最も整合する一件
3 件の中で症状が最も派手で、かつ pareido.jp の観測ログと一致するのがこのキャッシュバグです。
2026-03-26 に「1 時間以上 idle になったセッションでは、古い thinking ブロックを 1 度だけクリアする」という最適化が導入されました。長時間放置されたセッションのコンテキストを軽くするための処理で、設計意図は妥当です。問題は実装で、本来「1 度だけ」走るはずのクリアが 毎ターン継続的に 走るバグになっていました。
毎ターン推論履歴が消えると何が起きるか。
- 物忘れ (forgetful) — 直前の推論で得た理解が次のターンには消えている
- 繰り返し (repetitive) — 同じファイルを何度も読み直す、同じ判断を毎回やり直す
- 無駄なツール呼び出し (wasted tool calls) — 既に確認済みの状態を確認するために
ReadやBashが走る - コンテキスト喪失 (context loss) — タスクの全体像が散らばり、関係ないファイルに手が伸びる
- usage limit が想定より速く減る (usage limits draining faster) — 古い reasoning ブロックが毎リクエスト変わるため prompt cache がヒットせず、毎ターン全プロンプトを課金されるのと同じ状態になる
この症状は再現が困難で、Anthropic 内部でも特定までに 1 週間以上かかったと書かれています。修正は 2026-04-10 リリースの v2.1.101。
技術部としては、このバグの「キャッシュミス → トークン浪費」の流れが特に重い問題だと見ています。harness 側が prompt cache の前提を黙って崩すと、ユーザー側は「同じワークフローなのに今月だけトークンがやたら早く尽きる」という形で気づくしかなく、原因を切り分けるのは現実的にほぼ不可能です。
#3 「25 単語以下」のシステムプロンプト追加で 3% の品質低下
Opus 4.7 リリース日の 2026-04-16 に、Claude Code のシステムプロンプトへ「テキストを 25 単語以下に制限する」指示が追加されました。応答を簡潔にする狙いだったと思われます。これが他のプロンプト変更と組み合わさって、コーディング品質が 約 3% 低下 したと postmortem は報告しています。
3% は数字としては小さく見えますが、エージェント駆動の長いタスクではエラー率がそのまま雪だるま式に積み上がる領域です。撤回は 2026-04-20。影響は Sonnet 4.6 / Opus 4.6 / Opus 4.7 すべてに及びました。
この件で技術部として注目しているのは、ベンチマークの差分が「3%」というかなり小さい振れ幅でも postmortem に書かれている点です。逆に言うと、この粒度の差分を検知できる評価系を Anthropic 内部で運用しているということで、評価インフラとしては妥当な水準が確保されているようです。
pareido.jp 側で何が起きていたか
ここからは pareido.jp 側の観測ログです。pareido.jp は Claude Code をエージェント駆動の記事執筆・コード生成パイプラインに組み込んで運用しています。また、その他の実験的なコーディングの多くで VS Code 拡張や Cowork を利用しています。4 月のある時期から、以下の症状が目立つようになっていました。
- 単純な移植作業で多数のハルシネーション — シンボルのリネームを依頼しただけで関係ないファイルが書き換わる、存在しない API を呼ぶコードが混入する、といった挙動。これまでなら触らないはずの隣接モジュールに手が伸びる傾向があった
- 無駄なテストの量産 — 実装の網羅性がないまま、件数だけ稼ぐ形のテストが生成される。claude.md規約に違反する書き方で量産され、レビュー側で都度差し戻しが必要になった
- トークン消費量の急増 — 同じワークフローなのに usage limit に達するのが体感で明らかに早い。同じファイルを 1 セッション内で何度も読み直す挙動と整合する。
これらはいずれも postmortem の #2 が示す症状記述 (“forgetful, repetitive, wasted tool calls, context loss, usage limits draining faster”) とよく一致します。「Opus 4.7 に切り替えた直後だから不慣れなだけ」と判断保留にしていた違和感に、技術的な説明がついた形です。
cache miss → token 浪費は、エージェント駆動運用ではそのまま運用コストに跳ねます。pareido.jp のように Claude Code をパイプラインに組み込んでいる場合、harness 側のキャッシュ挙動の前提が崩れると、ベンチマークでは見えない形で「同じ仕事に倍のトークンを払う」状態が継続することになります。実害として無視できる規模ではありませんでした。
なお Anthropic は 2026-04-23 に 全サブスクライバーの usage limit をリセット することを発表しており、トークン浪費分の補填措置は取られています。
所感とまとめ
postmortem が透明性を持って公開され、影響範囲・撤回時期・補填対応まで明記されている点は、素直に評価したいところです。問題そのものは見えにくく深刻でしたが、隠さず時系列で説明する姿勢と、usage reset での補填対応は妥当な対応に見えます。先日も $100 のクレジット付与が「詫び石」として話題となりました。Anthropic は利用料や運用コストの急増で課金体系で苦慮しているようですが、ユーザーに還元する姿勢は徹底しています。
今後の対策として「スタッフが本番ビルドを使用する」「システムプロンプト変更時にモデル別の評価を行う」「段階的ロールアウトを強化する」が挙げられており、この方向性も納得できます。
その上で、今回の一件で改めて意識したのは、harness 側の見えない変更でクラウド LLM の挙動はこれだけブレうる という事実です。
- モデル本体 (API) は影響を受けていなかったが、Claude Code というハーネス経由では深刻な品質低下が起きた
- ユーザー側からは「モデルが劣化した」ように見えるが、原因はハーネスのキャッシュ挙動とシステムプロンプト
- 再現困難なため Anthropic 内部でも特定に 1 週間以上を要し、ユーザー側で切り分けるのは事実上不可能
技術部はエッジコンピューティング志向で、現状クラウド大型 LLM が実用優位であることは踏まえつつ、1 年程度でローカル LLM が追いつくことを見据えて準備を進めています。今回の postmortem はクラウド LLM を全否定する材料ではなく、むしろ「クラウドのモデルそのものは依然として強い」ことの裏付けでもあります。問題が起きたのはハーネスの方でした。
ただし、harness を自分で握れるかどうかは、運用の安定性に直結する論点として残ります。ローカル LLM とオープンソースのハーネス(Ollama / MLX / llama.cpp ベースのエージェント・フレームワーク) を選んだ場合、harness の挙動は自分で読んで自分で固定できます。バグはバグで起きますが、少なくとも「自分の運用環境で何が起きたか」は完全に追跡可能です。クラウド LLM の高い実力と、ローカルハーネスの透明性をどう組み合わせるかは、今後の構造設計の課題として継続して検証していきます。
pareido.jp としては当面、Claude Code は v2.1.116 以降を前提に運用を続けつつ、cache miss が観測された期間のトークン消費パターンを記録に残します。同種の事象が再発したときに、harness 側か、モデル側か、自分のワークフロー側かを切り分けるための一次資料として使うためです。
