Claude Code 品質劣化の真相｜Anthropic公式ポストモーテムで判明した3つの原因と今やるべきこと

結論から言うと、2026年3〜4月のClaude Code品質低下は「基盤モデル（Sonnet 4.6 / Opus 4.6 / Opus 4.7）の劣化」ではなく、製品層（Claude Code / Claude Agent SDK / Claude Cowork）で起きた3つの独立した変更が重なった結果です。 Anthropicは2026年4月23日に公式ポストモーテムを公開し、3件すべてを v2.1.116（2026年4月20日リリース） で修正済み、加えて全サブスクライバーの使用制限（ratelimit）をリセットしたと発表しました。API直利用者は今回の3件すべてから影響を受けていません。

この記事でわかること

• Anthropic公式ポストモーテム（april-23-postmortem）で特定された3つの原因の内訳
• 「物忘れ」「思考が浅い」「回答が短くなった」などの症状から原因を逆引きする方法
• Claude Code / Agent SDK / Cowork / API のどれが影響を受けたかの影響範囲
• v2.1.116以降の確認手順と /effort スラッシュコマンドの使い方
• Anthropicが公表した5つの再発防止策と、ユーザー側が取るべきアクション

こんな方に向いています

• 2026年3〜4月にClaude Codeの応答品質が落ちたと感じた開発者・チームリーダー
• 社内でClaude Code導入を検討しており、今回の事象をベンダー評価に活かしたい方
• 「モデルがナーフ（性能調整）されたのか」「API経路なら無事だったのか」を正確に把握したい方
• v2.1.116以降で本当に直ったのか、自分の環境で確認する手順を知りたい方

出典: Anthropic Engineering Blog

まず確認：あなたが感じた違和感はどれか（症状 → 原因 逆引き表）

読者の多くは「なんとなくClaude Codeが賢くなくなった」と感じてこの記事にたどり着いているはずです。そこで、体感症状から3つの原因のうちどれに該当したかを特定できる逆引き表を先に示します。

※複数の症状を感じた場合は、期間的に重なっている原因が複合していた可能性があります。例えば4月16〜20日は ③ と（Pro/Maxでは）① が同時に効いていました。

Anthropic公式ポストモーテムの結論

Anthropicは2026年4月23日（米国時間）、エンジニアリングブログで「An update on recent Claude Code quality reports」を公開しました。結論は次の3点に集約されます。

1. 基盤モデル（Claude Sonnet 4.6 / Opus 4.6 / Opus 4.7）の重み（weights）そのものに変更はない。 モデルは劣化していない。
2. 製品層（Claude Code / Claude Agent SDK / Claude Cowork）で起きた3つの独立した変更が重なり、体感品質が低下した。
3. API直利用（自前のコードでAnthropic APIを叩いていた場合）は今回の3件のいずれにも影響を受けていない。

ここでいう「製品層」とは、モデルを実際のアプリケーション（Claude Code等）として動かすための ハーネス（harness） やシステムプロンプト、セッション管理ロジックなどの総称です。AIの世界では「モデルの品質」と「モデルを載せた製品の品質」は別レイヤーであり、今回はまさにこの「製品の品質」側で起きた事故だったと位置づけられます。

3つの原因：何が起きていたのか

① reasoning effort デフォルト降格（high → medium）

• 発生: 2026年3月4日
• 対象: Claude Code（主に Opus 4.6 / Sonnet 4.6）
• 背景: Opus 4.6のUIが高負荷時に「凍結」したように見えるほどレイテンシが長くなる問題があり、デフォルトのreasoning effortを high から medium に下げて応答速度を優先した
• 結果: 複雑なリファクタリングや多ファイル横断の実装で、思考の浅さが露呈。体感として「急にコードレビューが甘くなった」「細部への注意が減った」という症状が出た
• 修正: 4月7日にAPIキー利用向けで high に復帰、Pro/Maxプランでは4月22日の v2.1.117 で完全復帰
• 現状（2026年4月下旬）: Opus 4.7は xhigh、その他のモデル（Opus 4.6 / Sonnet 4.6 等）は high がデフォルト

reasoning effortとは、モデルがどれだけ深く考えるか（= 内部thinkingトークンをどれだけ使うか）を制御するパラメータです。medium は high に比べてthinkingトークン量がおおむね半分程度となるため、複雑なタスクほど精度差が出やすい設計になっています。

② セッションキャッシングバグ（thinking履歴の毎ターン消去）

• 発生: 2026年3月26日（キャッシング最適化のデプロイ時にバグ混入）
• 対象: Claude Code / Claude Agent SDK / Claude Cowork
• 想定していた動作: 「1時間以上アイドル状態だったセッション」で、古いthinkingブロックを 一度だけ 削除してレイテンシを下げる
• 実際の挙動: バグにより、1時間アイドル後のセッションで 毎ターン thinking履歴を削除し続けた
• 体感症状: 「物忘れが強い」「同じ調査を繰り返す」「前のターンでの気づきを忘れている」
• 副次被害: プロンプトキャッシュのミス率が上昇 → 入力トークン消費が加速 → 使用制限への到達が早まった
• 修正: 2026年4月10日 v2.1.101 にて修正

この問題は「長いセッションを1時間以上置いてから再開する」使い方をする開発者で特に顕著でした。短時間で閉じるスクリプト実行型のユースケースでは踏みにくい構造でした。

③ 冗長性抑制のシステムプロンプト（≤25語 / ≤100語制約）

• 発生: 2026年4月16日
• 対象: Opus 4.7（一部、Sonnet 4.6などにも波及）
• 内容: システムプロンプトに「ツール呼び出しの間のテキストは 25語以下、最終応答は 100語以下 にせよ」という制約を追加
• 背景: Opus 4.7が冗長に応答しがちだったため、UX改善を目的に導入
• 結果: Anthropic社内のコーディング評価で 約3%の精度低下 を確認。応答が唐突に短くなり、説明が途切れる症状が顕在化
• 修正: 2026年4月20日 v2.1.116 でプロンプトを撤回

モデルに対して「短く答えろ」と強い制約を与えると、説明のスキップや推論の打ち切りが発生しやすくなります。良かれと思って入れた簡潔化の指示が、結果としてコーディング品質を落とすという古典的な失敗事例と言えます。

タイムライン：発生から修正・ポストモーテム公開まで

この表を見ると、① と ② は4月10日までにほぼ修正済みでしたが、4月16日に新たに ③ が追加で導入され、結果として「ようやく直ったと思ったらまた違和感が出た」という読者感覚につながっていました。

影響範囲：どの経路を使っていた人がどの問題を踏んだか

Anthropicは「API直利用は無影響」と明言しています。利用経路ごとに、3件のどれが影響したかを整理すると以下のとおりです。

API直利用の開発者が「何も感じなかった」のは偶然ではなく、今回の3件がすべて Claude Code等の製品層（ハーネス）側 に閉じた変更だったためです。これは裏を返せば、API直利用は製品層のバグの影響を受けにくい という運用上の示唆にもなります（ただし、自前でセッション管理やキャッシュ制御を実装する負担は増えます）。

AMD Stella Laurenzo氏の独立監査が示した定量的劣化

ポストモーテム公開前、AMD AI部門のシニアディレクター Stella Laurenzo氏 が大規模な独立監査を実施し、品質低下の存在を定量データで示したことで注目を集めました。

• 監査対象: 6,852セッションファイル / 234,760ツール呼び出し / 17,871 thinkingブロック
• 主な発見:
  • 思考深度（thinking depth）が 約67%低下
  • ファイル編集前の読み込み数（reads-per-edit）が 6.6 → 2.0（約70%減少）
  • 劣化期間中、3回に1回の編集が「直近読んでいないファイル」に対して行われていた
  • 既存コード破壊、コメントブロック途中へのコード挿入、ロジック重複等のリグレッションが多発

この監査が意義深かったのは、ユーザーの「体感」を客観データで裏付けた 点です。個々の開発者が「何かおかしい」と感じていたものが、セッションログの大量解析によって「thinking depth 67%低下」という具体数値として可視化され、結果的にAnthropicのポストモーテム公開を後押しする形になりました。

Anthropicが公表した5つの再発防止策

ポストモーテムでAnthropicは以下の再発防止策を提示しています。

1. 内部利用の強化 — 全従業員が公開ビルド（production build）を日常業務で使用するよう運用を変更。社内で先に違和感を検知できる体制へ
2. Code Reviewツール強化 — 複数リポジトリを横断的にコンテキストとして扱える改修。影響範囲検出の精度向上
3. システムプロンプト変更の管理強化 — すべての変更に包括的な評価（evaluation suite）を必須化、モデル固有の変更には厳格なゲーティング
4. 段階的ロールアウトの導入 — 知能（intelligence）に影響しうる変更には「ソーク期間（soak period）」と段階的展開を実施
5. 透明性の向上 — 開発者向け公式X（旧Twitter）アカウント @ClaudeDevs を新設し、リアルタイムで変更情報を発信

ここで使われている用語を補足します。ハーネス（harness） はモデルを製品として動かすための外側の仕組み全般、ソーク期間（soak period） は変更を本番にフル展開する前に一部環境で時間をかけて観測する期間、evaluation suite は品質を自動検証する評価基準の集合を指します。

いま読者がすべきこと：実務チェックリスト

3件すべてが修正済みとはいえ、読者自身の環境が本当に最新かを確認しておくことを推奨します。

1. Claude Codeのバージョンを確認する

ターミナルで以下を実行します。

claude --version

v2.1.116 以上 になっていれば、3件すべての修正が入っています。もし古ければ次のコマンドで更新します。

claude update
# または npm 経由でインストールしている場合
npm install -g @anthropic-ai/claude-code@latest

2. /effort スラッシュコマンドで reasoning effort を確認する

Claude Codeのセッション内で以下を打鍵し、現在のreasoning effortを確認します。

/effort

• Opus 4.7を使っている場合: xhigh が期待値
• Opus 4.6 / Sonnet 4.6 を使っている場合: high が期待値
• 明示的に下げたい場合は /effort medium などで切り替え可能

3. 使用制限リセット後の計画的な使い方

Anthropicは2026年4月23日に全サブスクライバーの使用制限（ratelimit）をリセットしました。これは金銭補償ではなく「使える量がいったん全量に戻った」形の実質的な補填です。具体的な値（何日分 / 何トークン分）は公式に明示されていないため、普段より余裕があるうちに 検証しておきたかったプロンプト や 保留していた大きなリファクタ を計画的に消化するとよいでしょう。

4. 過去1〜2ヶ月のセッション成果物を再検証する

特に以下に該当する成果物は、②のキャッシュバグ期（3月26日〜4月10日）と ③ の冗長性プロンプト期（4月16日〜4月20日）に作成されていれば再レビューを推奨します。

• 多ファイル横断のリファクタリング結果
• 既存コードへの機能追加で、Claude Codeが「読まずに書いた」可能性があるファイル
• 説明が唐突に短く打ち切られている実装ドキュメントや設計メモ

実務上、Stella Laurenzo氏の監査で指摘された「コメントブロック途中へのコード挿入」「既存コード破壊」は、コンパイルや単体テストが通っても潜在不具合として残ることが多いため、人間によるコードレビューが特に重要です。

ベンダー透明性の観点で見た今回の対応

今回のAnthropicの対応は、AIベンダーとしては 透明性の高い部類 に入ります。

• ポストモーテムの具体性: 3件の変更内容・日付・影響範囲・修正バージョンまで明示
• 補填の実行: 全サブスクライバーの使用制限リセットを同日内に実施
• 継続的な情報発信チャネルの新設: @ClaudeDevs によるリアルタイム発信
• 再発防止策の明文化: evaluation suite強化、soak period導入など5項目

一方で、以下のような課題や読者から残された疑問もあります。

• 遡及的な補償: ポストモーテム公開以前に消費された使用量は返還されていない
• v2.1.116未満の古いクライアントを使い続けていたユーザーの状態: サーバー側も絡むため、クライアント側だけで完全判定ができない
• 「APIなら無傷だった」問題: API経路に切り替えていた組織だけが実質的に損をしなかったという指摘

一般論として、AIベンダーを評価する際の観点として、今回の事例は次のチェックリストを参考にできます。

• ポストモーテムを公開する文化があるか
• 変更情報を事前・事後に発信する専用チャネルを持っているか
• ソーク期間や段階的ロールアウトを運用しているか
• 影響を受けたユーザーへの実効的な補填手段を持っているか

今回の事象から向いている読者 / 向いていない読者

今後もClaude Codeを使い続けるのに向いている方

• 透明性とポストモーテム公開の文化を重視する開発者・組織
• v2.1.116以降で復旧しており、基盤モデルの品質は変わっていない ことを重視する方
• /effort で明示的にreasoning effortを制御できる運用に慣れている方
• エージェント系機能（Claude Agent SDK / Claude Cowork 等）を活用したいチーム

慎重な検討が必要な方

• プロダクション業務で 停止時間をゼロにしたい チーム（今回のような製品層事故は他社でも起こりうる）
• 変更通知を即時に追える体制がなく、バージョン管理やアップデートを自動化していない 個人・小規模チーム
• 契約上SLAが絶対要件で、「ベストエフォート型」の透明性対応では不足する領域
• APIを直接叩く構成に寄せることで内製の品質管理を徹底したい組織（この場合はClaude API + 自前ハーネスが選択肢になる）

関連記事

• Claude Code自体の概要を先に押さえたい方は「Claude Codeとは」を参照してください
• 料金体系の最新情報は「Claude Code 料金」にまとめています
• 使い始めの方は「Claude Code 使い方ガイド」で基本操作を確認できます
• 基盤モデル側の情報は「Claudeとは」をどうぞ
• 類似のコーディングエージェントとの比較は「Claude Code vs GitHub Copilot 比較」「Cursor vs Claude Code 比較」を参照ください

まとめ

• 2026年3〜4月のClaude Code品質低下は、基盤モデルの劣化ではなく製品層（Claude Code / Agent SDK / Cowork）で起きた3つの変更の複合 が原因
• 3件は ①reasoning effort降格 ②セッションキャッシングバグ（thinking消去）③冗長性抑制プロンプト で、すべて v2.1.116（2026年4月20日） で修正済み
• API直利用の経路は今回のいずれの影響も受けていない
• Anthropicは4月23日に公式ポストモーテムを公開し、全サブスクライバーの使用制限をリセット、@ClaudeDevs 新設などの再発防止策も提示
• 読者側のアクションは「claude --version で v2.1.116 以上を確認」「/effort で reasoning effort を確認」「劣化期間中の成果物を再レビュー」の3点が基本

FAQ

Q1. Claude Code本体のモデル（Sonnet 4.6 / Opus 4.6 / Opus 4.7）は劣化していたのですか？

いいえ。Anthropicは公式ポストモーテムで、モデルの重み（weights）そのものには変更がなく、今回の品質低下はすべて製品層の変更が原因だったと明言しています。

Q2. 返金はありますか？

金銭的な返金は公表されていません。代わりに2026年4月23日時点で 全サブスクライバーの使用制限（ratelimit）がリセット され、使える容量がいったん全量に戻った形で実質的な補填が行われました。具体的な日数・トークン数の明示はありません。

Q3. v2.1.116未満を使い続けていた場合、今も劣化を踏みますか？

一部はクライアント側、一部はサーバー側の変更だったため、クライアントだけで完全には判定できません。安全のため v2.1.116以上へのアップデート を推奨します。claude update で最新版に上げられます。

Q4. API経路（自前コードで api.anthropic.com を呼ぶ構成）は本当に無傷だったのですか？

公式ポストモーテムは3件すべてが Claude Code / Claude Agent SDK / Claude Cowork の製品層に閉じた問題 だったと説明しています。つまり、API経路はいずれの影響も受けていないことになります。ただし、自前でセッション管理・キャッシュ制御・システムプロンプトを実装する場合は、今回と同種の実装ミスを自分で踏む可能性がある点には注意が必要です。

Q5. Claude.ai（Webチャット版）にも影響はあったのですか？

公式ポストモーテムの対象は Claude Code / Agent SDK / Cowork の3製品であり、Claude.aiのWebチャット / デスクトップアプリは対象に含まれていません。

Q6. 過去のセッション成果物はどう扱うべきですか？

特に 2026年3月26日〜4月10日（キャッシュバグ期）と 4月16日〜4月20日（冗長性プロンプト期）に作成された成果物は、人間のコードレビューで再検証することを推奨します。多ファイル横断のリファクタ結果、読まずに編集された可能性のあるファイル、唐突に短く打ち切られた説明ドキュメントが主なチェック対象です。

Q7. 同じことがまた起きる可能性はありますか？

ゼロではありません。Anthropicは再発防止として evaluation suite の強化・ソーク期間の導入・@ClaudeDevs の新設を発表しましたが、本質的には「製品層の変更で品質が落ちるリスク」は他のAIベンダーでも共通して存在します。読者側の対策としては、クライアントの自動アップデート体制を整え、@ClaudeDevs や公式ステータスページを定期的に確認する運用が有効です。

Q8. /effort コマンドはどこまで細かく指定できますか？

現行のClaude Codeでは low / medium / high / xhigh の4段階が利用可能です。Opus 4.7はデフォルト xhigh、その他モデルはデフォルト high です。タスクの難易度に応じて明示的に切り替えることで、トークン消費と思考深度のバランスを取れます。