技術 約7分で読めます

Claude Codeの品質劣化とコスト圧力は同じ原因だった

Claude Code Anthropic AIエージェント 品質 クォータ Prompt Caching
いけさん目次

Anthropicが4月の公式postmortemで品質問題を3件に分解した流れと、DEV記事がMax週次枠の消失を実運用目線で潰していく流れは、同時に起きたのに切片でしか読まれなかった。
同じ現象を「品質」と「コスト」で分けて読むと、実際には同じインフラ側の制約意識が効いてくる。
HNスレッド（item?id=47878905）でも「品質報告」と「クォータ枯渇」の論点は同時に再燃していて、1本線で追う方が分かりやすい。

まず同じソースを置いておく。

結果として「同じ話」を別軸で再構成すると、次の図式で整理できる。
品質の低下は、内部状態の一部を意図せず削る変更と直交する。
一方、コスト爆発は、コスト監視の見えにくさと設定最適化の失敗が同時に起きる。
ここで共通なのは、どちらも長時間セッションでの挙動を前提にしない設計を前提に、ユーザー体験が後追いで壊れていったことだ。

同じ期間の時系列を重ねる

4月7〜20日のAnthropic修正の流れは、記事としては質の高い情報公開だった。

  • 3月4日: デフォルトeffortが high から medium に変わる（3月中に問題指摘）
  • 3月26日: 1時間以上アイドル後に思考消去を行う改善が、毎ターン継続適用される不具合として混入
  • 4月7日: 全ユーザーを xhigh/high へ戻す
  • 4月10日: 3/26バグ修正
  • 4月16日: Opus 4.7用のverbosity制約プロンプト追加
  • 4月20日: コーディング性能劣化を招く効果が再現で確認され、ロールバック

それぞれ別起点だが、結果は「同じセッション履歴に対する圧縮・推論配分・観測不在」が増幅していた。
Claude Codeの品質劣化を17,871件のThinkingブロックと234,760件のツール呼び出しで立証したIssueでも、品質劣化を「2〜3月にかけて段階的に現れた長期的な低下」としてデータ化しており、今回のpostmortemはその背景と整合する。
同記事で触れた現場感（編集精度の悪化、繰り返し、simplest へ寄る傾向）が、今回の3/26バグと medium + 高思考の扱いと重なる。

2つの起点は違う、でも被害は同型

まず切り分ける。
1つ目は品質劣化で、effort 設定・thinkingの扱い・system promptの文脈で「賢さが下がった」というユーザー体験として現れる軸。
2つ目は使用量で、cache・context・長時間セッションが cache miss 連鎖を作るたびに使用量の観測不能性を増幅する軸。

ここまで別に書くと分かりやすい。
ただ、現場では2つが交差する。
長く使うほど思考履歴やコンテキストを使って品質を維持しようとし、その肥大分が再計算コストと再試行回数の双方を増やす。
結果として「品質を取り戻すための操作」がさらにコストを増やし、コストを抑えるための最適化が再試行や単純化を招いて品質が落ちる、という循環が起きる。

HNではAnthropic側も「アイドル時は再開で全Nメッセージのキャッシュ処理が走ると900k近い履歴では5時間窓で跳ねる」と説明している。
つまり、ユーザー体感としては「中断して戻ったら説明不能に高くなる」という現象に繋がる。
この説明はCLIの透明性不足を埋めるもので、「問題はあるかないか」より前に「見える化の順序」を再設計しないと再発しやすい、という警告でもある。

コスト境界を潰すと、品質事故は見えにくくなる

長時間セッションでcontextが増えると、1回のツール呼び出しの基準コストが下がらず、むしろ増える。
DEV記事が示す 100k コンテキスト時の2倍課金感覚は、品質的にも危ない。
思考が浅くなる変更（effort低下や思考履歴削除）と再試行リトライ増大は、同じ「やり直しループ」に収束する。
AnthropicのキャッシュTTL無告知変更とClaude Codeクォータ枯渇の構造で整理したとおり、キャッシュTTLの見えなさは5分窓の仕様変更だけでユーザー側の課金感覚を一晩で崩した前例がある。今回も観測点が追いつかないまま設定変更が走った点は同根だ。

結果は次の2パターン。

  • 1回で通る作業が、4〜6回で通る
  • 1回の問題対処が次の品質劣化を招く

だからDEVで CLAUDE_CODE_AUTO_COMPACT_WINDOW や CLAUDE_CODE_DISABLE_1M_CONTEXT を下げるのは単なる節約でなく、品質安定化にも効く。
逆に、思考量制限だけをコスト最適化で強くすると、再試行が増えて品質も落ちる。effort トレードオフが循環する構造だ。

運用優先順位は「観測可能性→設定境界→変更追従」

1番先に確認すべきは観測可能性だ。
Usageバケツの中身が分からないまま「高品質」「低コスト」の両立を狙うのは、運転席の情報なしで両ハンドルを同時に捻るのと同じだ。

その次が設定の境界制御。
DEV側の設定要約では、CLAUDE_CODE_AUTO_COMPACT_WINDOW を200kに下げる、CLAUDE_CODE_DISABLE_1M_CONTEXT=1、alwaysThinkingEnabled=false が効果的だったとされる。
これ自体が万能ではないが、「どこまで文脈を積むか」を固定するだけで、トークン膨張と長時間セッションでの劣化を両方抑えられることを示している。

3番目が変更の追従運用。
effortやsystem promptは最初のデフォルト値の都合だけで決めるべきでなく、実タスク別に固定してA/Bしやすい形にする。
xhigh を常時固定したまま使うのではなく、タスク難度に応じた見取り図を持つほうが費用対効果が上がる。

実装の具体

まず effort を戻す

品質事故の一次修正としては、high 以上を維持したまま再試行しやすい基準を取るのが早い。
今回のpostmortemが示した通り、mediumへの一方的寄せはlatency優先ではなくなった。
Anthropicも4/7に既定値を戻している。

次に長時間セッション設計を崩す

長寿命セッションは開発効率が高いが、キャッシュやコンテキストの見える化が弱いと、品質コストが同時に悪化する。
1日8時間級のパイプラインは1セッションあたり50以上のツール呼び出しが想定される。
contextとtool呼び出しが自己増殖すると、品質も枠も先に限界に達する。
この構造は、Compresr Context GatewayはAIエージェントのコンテキスト枯渇をどう解決するかで紹介したプロキシ層の発想、つまり「エージェントから見えるcontext」と「課金対象のcontext」を分離する設計が一つの回答になる。

最後に「自動最適化」要件を見直す

alwaysThinkingEnabled や自動アップデート、冗長なcache設定は、初期設定のまま放置するとコスト・品質双方の不確実性を上げる。
DEVの実践例で最も効いたのは、alwaysThinkingEnabled: false と CLAUDE_CODE_AUTO_COMPACT_WINDOW の明示化で、ここは現場向けに再現性が高い。

GPT-5.5に発表をぶつけにきた説

4/24のpostmortem＋使用量リセットは、同じ日にOpenAI側のGPT-5.5関連の情報が出ることを把握したうえでタイミングを合わせたのでは、という憶測がHN・X上でそこそこ目立っている。
真偽は分からないが、「品質劣化」と「クォータ枯渇」でユーザー不信が積み上がっているまさにそのタイミングに、リセットという物量でまとめて流しにきた動きは、広報としては確かに強い。
postmortem本文は真面目な内容だが、日付を切った判断まで含めて読むなら、純粋な技術事象として受け取るか広報イベントとして受け取るかは、読者側で分けておいたほうが混乱しない。

横展開で読みたい記事

今回のテーマは記事を重ねると強い。

この順で読むと、「なぜ品質事故が起きたか」→「なぜコストが突然増えるように見えたか」→「なぜ境界値が説明されにくいか」まで連続する。