ここ一ヶ月ほど、SNSや開発者コミュニティにおいて「Claude Codeが急に馬鹿になった」「同じことを何度も繰り返す認知症エージェントと化した」という怨嗟の声が散見されていた。LLM（Large Language Model）界隈では日常茶飯事の「プラシーボ効果的な劣化報告」として処理されがちな話題だが、今回ばかりは気のせいではなかったようだ。
先日、AnthropicはClaude Codeの品質低下に関する詳細なポストモーテム（事後検証報告）を発表した。結論から言えば、彼らのAPIレイヤーそのものが劣化したわけではなく、Claude Codeや関連ツール（Claude Agent SDK、Claude Cowork）の裏側で行われていた「良かれと思った」アップデートが三つ連鎖し、見事なまでにユーザー体験を破壊していたという、まさに人災と呼ぶべきインシデントであった。過度なコンテキストエンジニアリングがはらむリスクが最悪の形で表面化した形だ。
本稿では、このポストモーテムから読み取れる技術的背景を整理しつつ、AIエージェントを安定したプロダクトとして運用することの困難さ、そして開発プラットフォームとしてのAnthropicの姿勢について分析していく。
三つの「余計なお世話」が招いたUXの崩壊
Anthropicの報告によれば、事の発端から収束までの期間（3月4日から4月16日）において、独立した三つの変更が悪魔的なシナリオを描いて重なり合っていた。それぞれの変更は、レイテンシ改善やコスト削減といった真っ当な動機に基づくものだったが、結果として見事に裏目に出ている。
一つ目は、Reasoning effort（推論エフォート）のデフォルト値引き下げである。今年2月にOpus 4.6がリリースされた際、Claude Codeのデフォルト推論エフォートはhighに設定されていた。しかし、推論に時間がかかりすぎてUIがフリーズしたように見えるという報告を受け、Anthropicは3月4日にデフォルトをmediumへと引き下げた。確かにレイテンシは改善されただろうが、複雑なコーディングタスクにおける知性は明確に低下した。結局、ユーザーの不満を受けて4月7日にはこの決定を覆し、大多数のモデルでhighを、Opus 4.7に至ってはxhighをデフォルトに戻すという迷走ぶりを見せている。推論エフォートを上げれば精度は10〜30%向上する一方で、コストとレイテンシが跳ね上がるというトレードオフの舵取りを見誤った典型例である。
二つ目は、致命的とも言えるPrompt cachingの最適化バグだ。Claudeが推論過程（thinking）を保持し続けるとコンテキスト長が膨張するため、Anthropicは3月26日に「1時間以上放置されたセッションを再開する際、過去のthinking履歴をクリアしてAPI呼び出しの無駄を省く」という効率化パッチを当てた。ここまでは良い。しかし、実装されたコードには、一度セッションがアイドル状態になると、その後は毎ターンthinking履歴を消去し続けるという致命的なバグが潜んでいたのだ。結果としてClaudeは直前の推論すら忘却し、なぜそのツールを呼び出したのか分からないまま同じ動作を繰り返すという、鳥頭な振る舞いを連発することになった。さらに最悪なことに、この履歴の連続消去によってPrompt cachingの恩恵が受けられなくなり、キャッシュミスが頻発。ユーザーのUsage limits（利用枠）を猛烈な勢いで溶かすという二次災害まで引き起こしている。
そして三つ目が、System promptによる冗長性の抑制である。最新モデルであるOpus 4.7は非常に雄弁な性格（verbosity）を持っており、これが賢さの源泉であると同時に、出力トークン数の増大を招いていた。これを抑え込むため、Anthropicは4月16日のリリースに合わせてSystem promptに「ツール呼び出し間のテキストは25 words以内、最終回答は100 words以内に収めよ」という指示を追加した。これがトドメを刺した。他のプロンプト変更と組み合わさった結果、文字数制限に引っ張られてコーディングの思考プロセスそのものが劣化し、わずか数日後の4月20日にロールバックされる事態となった。
これら三つの事象は、それぞれ異なるトラフィックとスケジュールで展開されたため、結果として「全体的に一貫性がなく、なんとも言えない品質低下」としてユーザーの目に映ることになったのである。
コンテキストエンジニアリングの泥沼化と失われた信頼性
今回のポストモーテムを読んで、Pi coding agentの生みの親であるMario Zechnerが自身のYouTube動画で発していた警告を思い出した読者も多いだろう。当ブログでも「Pi coding agentの考察」で言及した通り、Zechnerは「Claude Codeの裏側は複雑化しすぎており、開発陣が頻繁にコンテキストエンジニアリングの実験を繰り返すせいで、ユーザーとしては一貫して信頼できる挙動を期待できなくなっている」と喝破していた。今回のインシデントは、まさに彼の指摘が100%正しかったことを裏付けるものである。
LLMを用いたエージェント開発において、context engineeringはかつてのソースコードと同等の重みを持つ。System promptのわずかな変更はモデルの出力に非線形な影響を与え、思いもよらないバグ（今回のような知性の劣化や挙動の不安定化）を引き起こす。本来であれば、System promptは厳密なEvals（評価データセット）を用いた自動テストによる品質担保が不可欠だ。
Anthropicも社内でEvalsを回し、Code Reviewを行い、ドッグフーディング（自社製品を社内で使うこと）を実施していたと弁明している。しかし、特定のCLIセッションでの表示バグや内部のサーバーサイド実験が影響し、本番環境でユーザーが遭遇している問題をすぐには再現できなかったという。これは言い換えれば、彼らのテスト環境と評価指標が、現実の複雑なエージェント・ワークフローにおける動的な振る舞いをカバーしきれていなかった証左である。
「APIレイヤーには影響がなかった」と胸を張る姿勢も、視点を変えれば恐ろしい事実を示唆している。我々が叩いているAPIの裏にいる素のClaudeモデルは賢いままだったが、その手前に被せられたClaude Codeという「皮」の内部で、AnthropicのエンジニアがSystem promptやパラメータをこねくり回した結果、ユーザー体験が崩壊したということだ。プロダクトとしての手軽さを提供する対価として、我々はいつの間にかAnthropicの過剰最適化A/Bテストの被験者にされていたのである。
透明性の向上は免罪符となるか
もちろん、Anthropicをただ批判して終わるつもりはない。問題を隠蔽せず、詳細なポストモーテムを公開した透明性そのものは高く評価されるべきだ。
彼らは今後の対策として、社内スタッフの公開ビルド使用割合の引き上げ、Code Reviewツールの改善、そして何よりSystem prompt変更に対する厳格な統制（広範なモデル別Evalsの実行、Soak periods（評価期間）の確保、段階的なロールアウト）を約束している。また、CLAUDE.mdのガイダンスを改善し、モデル固有の変更が適切に管理されるようにもするという。
さらに、X上で @ClaudeDevs アカウントを開設し、プロダクトの意思決定背景をより深く説明していく方針を打ち出し、全サブスクライバーのUsage limitsをリセットするという実利的な補填にも踏み切った。これらは、プラットフォーム企業として信頼を取り戻すための正しい第一歩と言える。
しかし、B2Bの開発者やヘビーユーザーの視点からすれば、一抹の不安は拭えない。我々が求めているのは、最先端のモデルを用いた派手なデモンストレーション以上に、Predictable（予測可能）で安定したツールである。裏側でこっそりと推論エフォートを下げられたり、System promptに文字数制限を仕込まれたりしては、自社のワークフローにClaude Codeを深く組み込むことを躊躇せざるを得ない。
AIエージェントのプロダクト化競争は熾烈を極めている。その中で、ユーザーの手間を省くための「自動化されたコンテキスト最適化」は必須の武器となるが、それは諸刃の剣でもある。今回のインシデントは、どれだけ賢い基盤モデルを持っていようと、その上に乗るソフトウェアエンジニアリングの実装が杜撰であれば、AIエージェントは容易に「少し頭の足りないポンコツ」へと転落するという痛烈な教訓を残した。
Anthropicがこの手痛い失敗からDevOpsのベストプラクティスを真に組織へ根付かせることができるのか。それとも、再び我々を壮大なプロンプト実験のモルモットとして扱うのか。次なるアップデートの行方を見守りたい。