Claudeが「バカになった」問題の全貌 — 6,852セッションの分析データと、Anthropicが認めたこと

「Claudeが明らかに頭悪くなった」

2026年4月、この感覚を言語化したのはAIに詳しい一般ユーザーではなかった。AMDのAIグループ責任者、Stella Laurenzo氏だ。

Laurenzo氏はGitHubに詳細な分析を投稿した。対象は自チームの6,852セッション、17,871件のthinkingブロック、234,760回のツール呼び出し。数ヶ月分の実データから導いた結論は明快だった。「Claude Codeは複雑なエンジニアリングタスクを信頼して任せられるレベルではなくなった」。

この投稿がきっかけで、Fortune、VentureBeat、Axios、The Registerが相次いで報道。「AIモデルは静かに劣化するのか」という問いが、業界全体に広がった。

何が起きたのか、時系列で

事の発端は3月3日のeffort level変更だ。

Anthropicはこの日、Claude Opus 4.6のデフォルトeffort levelを「high」から「medium」に変更した。effort levelとは、Claudeが応答時にどれだけ深く「考える」かを制御するパラメータで、highなら時間をかけて丁寧に推論し、mediumなら速度と品質のバランスを取る。Anthropicはこの変更を「知性、レイテンシ、コストの最適なバランス」と位置づけた。

しかし、ヘビーユーザーたちの実感は違った。

3月中旬から、X、GitHub、Redditで「Claudeが怠惰になった」「指示を無視するようになった」「ハルシネーションが増えた」という報告が増え始めた。BridgeBenchのハルシネーション評価では、Claude Opus 4.6が先週83.3%（2位）から68.3%（10位）に急落したとする分析も出た。

4月7日、Anthropicはデフォルトeffort levelをmediumからhighに戻した。対象はAPIキーユーザー、Bedrock、Vertex、Foundry、Team、Enterpriseプラン。事実上、3月の変更を撤回した格好だ。

だが、この修正が入った後も苦情は止まらなかった。

Anthropicの公式見解

Anthropicの説明はこうだ。

モデル自体は劣化していない。3月のeffort level変更によって「thinking summaries」（推論の要約表示）の内容が変わり、ユーザーがClaudeの「考えている量」を過小に見積もるようになった。つまり、実際のパフォーマンスではなく、見え方が変わったことでユーザーの印象が悪化した、というのがAnthropicの主張だ。

加えて、Anthropicは4月中旬に3件の技術的バグを公表した。誤ルーティング（リクエストが意図しないモデルに振り分けられる）、出力の一部が破損する問題、特定条件下でのレスポンス品質低下。これらは修正済みとされている。

正直なところ、この説明に全面的に納得したユーザーは少ないだろう。Fortune紙の報道によれば、Anthropicの内部分析でも4月は13日間で20件以上の品質関連問題が報告されており、3月の18件（1〜2月の3.5倍）を上回るペースだった。「見え方の問題」だけで片付けるには、数字が強すぎる。

構造的な問題が透けて見える

この騒動が単なる一時的なバグの話で終わらないのは、AIモデルの品質管理に構造的な課題があることを浮き彫りにしたからだ。

まず、effort levelの変更が事前告知なしに行われたこと。SaaS製品であれば、ユーザーに影響するパラメータの変更は通常、事前にアナウンスされる。しかし、AIモデルのeffort levelは「内部の最適化パラメータ」という扱いで、ユーザーへの通知義務があるとは考えられていなかった。

次に、劣化の検知が難しいこと。AIモデルの品質は定量的に測りにくい。ベンチマークのスコアが下がっていなくても、実務で「なんか変」と感じるユーザーは多い。この「感覚と数字のギャップ」を埋める仕組みが、現時点ではどのAI企業にも存在しない。

そして、対策として「effort levelを上げる」とコストが上がること。highとmediumの差はトークン消費に直結する。つまり、ユーザーは「品質を維持するためにより多く支払う」か「コストを抑えて品質低下を受け入れる」かの二択を迫られる。Anthropicが最初にmediumをデフォルトにした背景には、高まるコンピュート需要とサーバー負荷があっただろう。

ユーザーが今できること

現時点で取れる対策を整理する。

effort levelを明示的に指定する。 APIユーザーなら effort: "high" をリクエストに含める。Claude Codeなら .claude/settings.json でeffort levelをhighに固定できる。デフォルトに任せるのではなく、自分でコントロールする習慣をつけたほうがいい。

Opus 4.7にアップグレードする。 4月16日にリリースされたOpus 4.7は、特に複雑なソフトウェアエンジニアリングタスクでの精度が向上している。Anthropicは「最も難しいタスクで顕著なゲイン」としており、Opus 4.6で起きた問題の多くが改善されている可能性が高い。

セッションデータを記録する。 Laurenzo氏の分析が説得力を持ったのは、6,852セッションという実データの裏付けがあったからだ。Claude Code の利用ログを保存しておけば、将来的な品質変化を客観的に検証できる。

この問題が教えてくれること

Claude固有の問題と見るよりも、AIモデル全般に通じる話として捉えたほうがいい。

OpenAIのGPTも、GoogleのGeminiも、アップデートのたびに「前のほうが良かった」という声が出る。モデルの改善と品質維持を両立させることは、構造的に難しいのだ。新しいデータで学習すれば一部の性能が上がる代わりに、別の部分が微妙に変わる。しかもその変化を、ベンチマークスコアだけでは捉えきれない。

AIモデルを業務の中核に据えている組織にとっては、「モデルは変わりうる」という前提で運用を設計する必要がある。特定のモデルバージョンにロックインするのではなく、複数の選択肢を持ち、品質のモニタリング手段を確保しておくこと。それが、今回の騒動から得られる最も実用的な教訓だと思う。