Claudeの「品質低下」問題の調査結果を発表：原因はモデル劣化ではなく製品層の3つの変更

Anthropicは2026年4月23日、Claudeの品質低下を巡るユーザー報告について、原因を説明するポストモーテムを公開した。結論は、基盤モデルやAPI、推論レイヤーの性能劣化ではなく、Claude Code、Claude Agent SDK、Claude Coworkにまたがる3つの製品層の変更が、時期と対象をずらしながら重なったというものだ。

対象となったのは、Claude Codeの推論努力量デフォルト変更、長時間アイドル後のセッションで思考履歴を誤って消し続けるキャッシュ関連バグ、そしてツール呼び出し間と最終応答を短くするシステムプロンプト変更である。Anthropicによれば、APIと推論レイヤーは初期確認の時点で影響を受けていないと判定された。

修正は段階的に行われ、Claude Codeでは2026年4月20日までにすべて解消され、バージョンv2.1.116で反映された。Anthropicは4月23日に、全サブスクライバーの使用制限もリセットした。影響人数、使用制限リセットの実際の利用規模、API顧客への補償有無などは公表されていない。

3つの製品層の変更が別々の時期に別々の症状を生んだ

Anthropicが挙げた3件は、いずれも「Claude全体が一様に悪くなった」という単純な現象ではない。異なる日付、異なる製品面、異なるモデルの組み合わせで発生したため、ユーザー側からは広範で不安定な品質低下に見えた。

最初の変更は、Claude Codeで高努力量モード利用時に「遅い」「UIが固まる」といった報告があったことへの対処だった。Anthropicは3月4日、デフォルトの推論努力量をhighからmediumに下げた。だが同社は、長く考える設定は一般に出力品質を改善すると説明しており、コーディングのように複数手順の推論やツール利用が重要な作業では、速度改善がそのまま品質低下として現れやすい。

2件目は、より分かりにくい。3月26日に導入されたキャッシュ最適化は、1時間以上アイドルだったセッションで古い思考を一度だけ消すことを意図していた。しかし実際には、その後の同一セッションまたはプロセスの各ターンで思考履歴を消し続けた。Anthropicは、この問題が「忘れる」「同じことを繰り返す」「奇妙なツールを選ぶ」といった症状につながったと説明している。

3件目は、4月16日のClaude Opus 4.7一般提供と同時期に入ったシステムプロンプト変更である。ツール呼び出し間のテキストを25語以下、タスクが詳細を必要としない限り最終応答を100語以下に抑えるという趣旨の指示が追加された。この変更はSonnet 4.6、Opus 4.6、Opus 4.7に影響した。さらにAnthropicがアブレーションを広げ、評価を追加した過程で、Opus 4.6とOpus 4.7については1つの評価で3%の低下が確認された。3%という数字は、このプロンプト変更に関する一部評価の結果であり、Sonnet 4.6に同じ測定値が出たことや、全ての苦情を単独で説明することを意味しない。

推論努力量は「速さ」と「エージェント品質」の交換条件だった

Claude Codeは、コードベースを読み、ファイルを編集し、コマンドを実行するエージェント型のコーディングツールである。単発のチャット応答よりも、計画、探索、ツール呼び出し、再確認の連鎖に品質が左右される。

Anthropicのeffortドキュメントでは、努力量はトークン消費と徹底度を制御し、テキスト、ツール呼び出し、拡張思考に影響すると説明されている。低い努力量では、より直接的な行動や少ないツール呼び出しにつながり得る。これは高速化や使用量抑制には効くが、未知のコードベースを読む、失敗したテストを追う、複数ファイルの副作用を確認するといった作業では、必要な探索が浅くなる可能性がある。

Anthropicの説明で焦点となるのは、モデル自体の劣化ではなく、Claude Codeのデフォルト設定変更が問題の1つとして切り分けられた点である。Opus 4.7ではxhighという新しい努力量が導入され、Anthropicはコーディングやエージェント用途にOpus 4.7のxhighを推奨している。一方、APIのデフォルトはhighのままであり、Claude Code側では現在、Opus 4.7がxhigh、その他のモデルがhighをデフォルトに戻している。

この差は、同じモデル名でも利用面によって体験が変わることを示す。APIで明示的にeffortを管理している開発者と、Claude Codeのデフォルト挙動に依存しているユーザーでは、同じ時期の品質変化を同じ原因として扱えない。AnthropicがAPIと推論レイヤーを影響範囲から外したことは、少なくとも今回の説明上、モデル重みやAPI提供基盤の劣化を示す材料ではない。

API利用者にとっての実務上の含意は、モデル名だけで品質を管理しないことにある。長いコーディングタスク、複数ツールを使う業務フロー、レビューや修正を反復するワークロードでは、effortを明示し、変更前後の品質、遅延、トークン使用量を分けて見る必要がある。Claude Code利用者の場合は、モデル更新だけでなく、CLIやアプリ側のバージョン、デフォルト設定、リリースノートが品質変動の原因になり得る。

キャッシュ最適化のバグは長時間セッションほど見えやすい

2件目のキャッシュ関連バグは、エージェント型ツール特有の脆さを示している。Claude Codeのような製品では、単一プロンプトの正答率だけでなく、長いセッションの文脈保持、過去の判断の継続、ツール利用の一貫性が品質を左右する。3月26日の最適化は、1時間以上アイドルだったセッションで古い思考を整理し、キャッシュを効かせることを狙ったものだった。

Anthropicのプロンプトキャッシュ機能は、反復的なプロンプトや長いマルチターン会話で処理時間とコストを下げるための仕組みである。標準のキャッシュ寿命は5分で、追加コストを伴う1時間キャッシュも用意されている。今回のバグでは、clear_thinking_20251015とkeep:1を使った処理が、古い思考を一度だけ消すのではなく、セッション内で毎ターン思考履歴を消す挙動になった。

その結果として、エージェントは直前までの検討を十分に引き継げず、同じ探索を繰り返したり、以前の文脈と合わないツールを選んだりする可能性があった。Anthropicは、キャッシュミスと使用制限の消費増加も起き得たと説明している。ユーザーから見ると、これは「賢さが下がった」というより、「長く一緒に作業しているほど急に記憶が薄くなる」挙動に近い。

この種の問題は、短い評価セットや社内の通常利用だけでは再現しにくい。Anthropicも、当初の内部利用と評価では特定された問題を再現できなかったとしている。長時間アイドル、既存プロセスの継続、キャッシュ最適化、エージェントの思考履歴という条件が重なるため、品質問題として表に出るまでの経路が複雑だった。

自社でエージェントを構築する開発者にとっては、キャッシュを単なるコスト削減機能として扱うだけでは足りない。キャッシュキー、TTL、思考や中間状態の削除条件、セッション再開時の扱いは、エージェントの判断品質そのものに関わる。特にアイドル後に再開する業務エージェントでは、短い単発ベンチマークとは別に、数十分から数時間をまたぐセッション評価が必要になる。

短く答える指示はコーディングエージェントの説明力を削った

4月16日の変更は、Claude Opus 4.7のローンチと重なった。AnthropicはOpus 4.7を、Opus 4.6より高度なソフトウェアエンジニアリングや長時間タスクに強いモデルとして一般提供し、新しいxhigh努力量も導入した。ただし、同社は高い努力量ではトークン使用量が増える点にも触れている。

同じタイミングで入った簡潔化のシステムプロンプトは、コーディング品質には逆方向に働いた。ツール呼び出しの間に短く話すこと自体は、通常のチャットでは読みやすさにつながる場合がある。しかしエージェント型コーディングでは、短すぎる中間説明が、作業仮説、失敗理由、次の検証手順、ファイル間の関係を十分に保持しにくくする。プロンプトがツール利用や最終応答の長さに強く介入すれば、モデル本体の能力とは別に、製品としての振る舞いが変わる。

Anthropicは、この変更と他のプロンプト変更の組み合わせが、Sonnet 4.6、Opus 4.6、Opus 4.7のコーディング品質に悪影響を与えたと説明した。広範なアブレーションと評価拡張の中では、Opus 4.6とOpus 4.7について1つの評価で3%の低下が確認された。4月20日に差し戻され、Claude Code v2.1.116で全ての修正が入った。

この点は、Opus 4.7そのものの評価と切り分ける必要がある。4月16日の公式発表では、Opus 4.7は高度なソフトウェアエンジニアリングや長時間作業で強化されたと位置づけられた。一方で、同時期の製品プロンプトが品質を下げたため、ローンチ直後の一部ユーザー体験はモデル改善と逆の印象を与えた可能性がある。公開情報だけでは、3%低下が確認された評価セットの詳細や、実利用での影響規模は分からない。

Claude Code利用者にとっては、最終応答が短くなることだけが問題ではない。中間説明が短くなると、ユーザーが作業意図を監査しにくくなり、エージェントがなぜ特定のファイルを触ったのか、なぜテストを選んだのか、どこまで確認したのかが見えにくくなる。自社エージェントでも、簡潔さを強制するプロンプトは、作業ログ、監査性、失敗時の復旧可能性と同時に評価する必要がある。

見落としの原因は公開ビルドと評価環境のずれにあった

Anthropicは、今回の問題を受けて複数の開発・評価プロセスを変更するとしている。対策には、正確な公開Claude Codeビルドをより多くの社員が使うこと、Code Reviewの評価に追加リポジトリを文脈として入れること、システムプロンプトの管理を厳しくすること、モデル別の評価とアブレーションを広げることが含まれる。

また、監査ツールの整備、モデルごとのCLAUDE.mdガイダンス、ソーク期間、段階的ロールアウトも挙げられている。これらは、基盤モデルのベンチマークだけでは検出できない製品層の退行を捕捉するための措置である。特にClaude Codeのようなエージェント製品では、モデル、プロンプト、キャッシュ、セッション管理、ツール権限、UI応答性が1つの体験として現れる。

Claude Agent SDKとClaude Coworkも、この文脈では同じ制御面を共有する。Agent SDKはClaude Codeのエージェント基盤を開発者向けに提供するもので、ツール、権限、セッション管理、監視、プロンプトキャッシュを扱う。Coworkは同様のエージェント機能をデスクトップの知識作業へ広げる製品であり、ローカルファイルと複数ステップのタスクを扱う。つまり今回の問題は、Claude Code単体の不具合報告にとどまらず、モデルを長い作業手順に接続する製品群の品質管理問題でもある。

実務上の教訓は、ClaudeのAPI利用者全体に「モデルが劣化した」と広げることではない。APIユーザーはeffort、キャッシュ、システムプロンプト、ツール設計を変更履歴として管理し、モデル更新とは別に回帰テストを走らせる必要がある。Claude Codeユーザーは、モデル名やベンチマークだけでなく、製品ビルド、デフォルト努力量、セッション継続条件を確認する必要がある。自社エージェント開発者は、短い正答率評価に加えて、長時間セッション、アイドル復帰、ツール呼び出し間の説明、キャッシュミス時の挙動を評価項目に入れるべきである。

Anthropicの説明が正しければ、今回の品質低下はモデル供給そのものの事故ではなく、エージェント製品のリリースエンジニアリングと制御面の事故である。Claude Code、Claude Agent SDK、Claude Coworkのように、モデルを長い作業手順へ接続する製品では、基盤モデルの更新よりも、デフォルト努力量、キャッシュ寿命、思考履歴、短文化プロンプトのほうが、ユーザーの「賢さ」の体感を直接動かす場合がある。今後の焦点は、Opus 4.7の性能評価だけでなく、公開ビルド上での長時間エージェント評価と、モデル別に異なる制御設定をどう検証するかに移る。

---

Sources

Anthropic:

• April 23 postmortem
• Claude Opus 4.7
• Building agents with the Claude Agent SDK

Claude:

• Claude Code docs
• Claude Cowork

Anthropic Docs:

• Effort
• Prompt caching
• Extended thinking