AnthropicがClaudeをこっそり低下させた論争 — パワーユーザー反発の本当の文脈

「なぜ急にClaudeがおかしくなったんだろう?」

3月中旬から、AI開発者コミュニティでこんな声が頻繁に聞こえるようになった。Redditのr/ClaudeAI、Hacker News、Xで似たような不満が積み重なった。モデルが指示を無視したり、以前はうまく処理できていた複雑なワークフローでエラーが増えたという報告が続いた。最初は「自分のプロンプトが悪いのかな?」と思って見過ごす人が多かった。私もその一人だった。

このブログはClaudeで自動化されている — リサーチ、投稿作成、内部リンク挿入、多言語翻訳、ビルド、デプロイまで。3月中旬から指示をスキップしたり、翻訳品質が突然揺らいだり、内部リンク条件が抜けるケースが目立って増えた。そのたびにSKILL.mdを見直し、プロンプト構造を修正した。指示をより明確に書き直し、ファイル量を減らし、コンテキストを整理した。効果はなかった。

4月14日、Fortuneがこの現象を記事にした。2日後、Axiosが追加分析を出した。VentureBeatも「Anthropicはclaudeをnerfingしているのか?」というタイトルで参戦した。Gizmodoは「Anthropic Is Jacking Up the Price for Power Users Amid Complaints Its Model Is Getting Worse」という直接的なタイトルの記事を出した。そこでようやくパズルのピースが合わさった。

自分のプロンプトの問題ではなかった。そしておそらく、あなたのプロンプトの問題でもなかったはずだ。

3月に、Anthropicが静かに変えたこと

3月初め、AnthropicはClaudeのデフォルト「effort」レベルを静かに引き下げた。従来のデフォルト値は「high effort」だったが、これを「medium effort」に変更した。

この事実を公に認めたのは、Claude Codeを率いるAnthropicの幹部Boris Chernyだった。彼はこの変更が「ユーザーからClaudeがトークンを使いすぎるというフィードバックがあったため」と説明した。そして、この変更が「changelogで公開され、ユーザーへのダイアログでも表示された」と付け加えた。「sneakyなものではなく、obviousでexplicitな変更だった」という主張だ。

この説明は技術的には正しいかもしれない。しかし多くのユーザーがそのダイアログを見逃したり、changelogを読んでいなかった。その事実自体が、すでにコミュニケーションの失敗を意味する。「公開した」という事実と、「ユーザーが実際に認識した」という事実は別の話だ。

effortレベルについて整理しておこう。Claudeは応答を生成する際に「どれくらい深く考えるか」を調整する内部パラメータを持っている。High effortはより多くの演算を使い、指示に細かく従い、複雑なリクエストをより適切に処理する。 Medium effortは速くてコスト効率が良いが、その分指示を簡略化したりスキップしたりする可能性が高くなる。このパラメータはAPIを使う開発者が明示的に設定できた。問題は、デフォルト値が変わったことだ。自分で「high effort」を指定していない人は、自動的にmediumに引き下げられた。

ここで重要なポイントがある。エンタープライズ契約を持つ企業顧客の立場で考えてみよう。数十人の従業員がClaudeを業務で使っており、チームごとに様々なワークフローが構築されている。この状況でAPIのデフォルト値が変わったからといって、全員がその事実を認識して設定を調整することを期待するのは現実的ではない。ユーザーが直接触れていないデフォルト値は「そのまま維持される」という信頼の上で運用されるのが正常だ。

実際にこの変更がいかに静かに行われたかを見ると、ChernyがRedditでこの問題に直接回答するまで、「Anthropicがどんな変更をしたか」を公式チャンネルで積極的に伝えようとする動きはなかった。ユーザーが問題を提起し、記事が出て初めて幹部が直接説明に出た。この順序が多くの人に「こっそり変えた」という印象を与えた。

「Medium Effort」が実際のワークフローで意味すること

抽象的に聞こえるかもしれないので、具体的な例を挙げよう。

Claude Codeで複雑なリファクタリングを依頼したとしよう。High effortなら、ファイル間の依存関係を丁寧に追跡し、影響範囲を把握してから変更を進める。型エラーが複数のモジュールに伝播するか、変更がテストを壊すかを事前に確認する。Medium effortなら？「このファイルだけ変えればいいだろう」という判断が増える。テストを実行して初めて発見される種類のバグが生まれる。

直接体感した例もある。このブログの自動化ワークフローはかなり複雑な指示体系を持っている。投稿作成ルール、内部リンク挿入基準、言語別翻訳方法が複数のファイルに書かれている。3月中旬以降、これらの指示が部分的に無視される頻度が増えた。「内部リンク最低2個」という条件が抜けたり、翻訳が機械的に感じられたり、投稿の分量が突然減ることが起きた。当時の私の診断は「プロンプトが長くなりすぎて後半を読み取れていないのかな?」だった。今振り返ると、3月初めのeffortレベル変更とタイミングがぴったり一致する。

より興味深いパラドックスもある。パワーユーザーの一部はこの期間にトークン消費が4倍〜10倍に増えたと報告した。理由は単純だ。パフォーマンスが下がると回答が不正確になり、リトライが増える。 指示に適切に従えなければユーザーが再要求しなければならず、そのプロセスでより多くのトークンが消費される。「トークン節約」のためにeffortを下げたのに、逆の結果が出たケースが生まれた。The Registerはこれとは別に「Anthropic admits Claude Code quotas running out too fast」という記事を出した。Anthropic側も「想定より遥かに早く使用制限に達しているのがチームの最優先課題」と認めた。

自動化パイプラインでこのような異常動作を検知するのは難しい。単一のリクエストで目立つエラーが出るのではなく、長い時間をかけて成果物の品質が徐々に低下するという形で現れるからだ。この変化を素早く気づいた人たちは、ほとんどの場合、成果物を定期的にベンチマークしたり、品質評価の自動化を備えていた。

Claude Codeを使う開発者たちの間では具体的な事例が共有された。マルチファイルリファクタリングで以前は漏れなかった依存関係の更新をスキップするケース、テストファイルを更新せずソースだけ変えるケース、エラーハンドリングコードを単純化してしまうケースが報告された。あるユーザーは「以前は自動的に処理していたエッジケースを、今は自分で明示しないといけない」と表現した。モデルが「proactive」でなくなったという印象だ。

この違いは単純なタスクではほぼ検知されない。複雑な指示体系を持つワークフロー、複数のステップを経る自動化パイプライン、数十のファイルにまたがる作業で顕著になる。つまり、最も大きなコストを支払い、Claudeを最も複雑に使っている人たちが最大のダメージを受けた。

パワーユーザーが怒った理由 — 透明性の問題

技術的な変更自体よりも、より多くの人が怒ったのは透明性の問題だった。

LLMサービスを使うということは、ある程度「ブラックボックス」を受け入れる契約だ。モデルが正確にどう動くかわからなくても、期待水準のパフォーマンスが維持されるという前提で、サブスクリプション料を払いワークフローを構築する。チームをトレーニングし、ツールを統合し、プロセスを設計する。

Anthropicはこの期待水準を通知なく変更した。ユーザーが自分で設定したものではなかった。企業がデフォルト値を引き下げ、その事実をchangelogに埋めた。

Claude Codeの使用量分析で整理したように、Claude Codeをプロダクションワークフローに統合するほど、モデル動作の予測可能性が重要な要素になる。昨日と今日の結果が異なれば、それが自分のコードの問題なのかモデルの変更なのかデバッグするのに時間がかかる。自動化パイプラインほど、そのコストは大きい。

Boris Chernyの反論が逆効果を生んだ。「obvious and explicit」と言った時点で、すでに何百人ものユーザーが「知らなかった」と公に言っていた。企業の立場では「公開した」という事実が重要かもしれないが、それが実際にユーザーに伝わったかどうかがより重要だ。二つは別の話だ。

多くの企業顧客は毎週changelogを読まない。彼らは「APIを呼べば以前と同じように動く」という暗黙の契約を信じている。今回の変更はその契約を壊した。もっと正確に言えば、その契約が最初からなかったということを、今回多くの人が認識することになったというほうが正確かもしれない。

コミュニティの反応の中に興味深いパターンがあった。多くの人が「この変化に気づいた方法」を話していたが、ほとんどの場合、成果物がおかしくなったことを先に発見してから原因を遡って追跡したということだ。「コードレビューを依頼したら以前より浅くなった」「複雑な文書を要約させたら重要な内容が抜けた」という経験が繰り返され、その後の検索でeffortレベル変更の事実を知った。ユーザーがモデルの行動変化を追跡するツールが事実上ないことが、今回改めて確認された。

価格引き上げが火に油を注いだ

タイミングが最悪だった。

パフォーマンス低下論争が真っ最中だった4月16日、Anthropicはエンタープライズのサブスクリプション政策を変更した。従来はユーザーあたり月最大$200の定額制だったが、「$20/ユーザー/月の基本料金 + コンピュート使用量ベースの料金」へ転換すると発表した。

The Registerはこれを「Anthropic ejects bundled tokens from enterprise seat deal」と表現した。バンドルトークンをなくし従量制に転換したのだ。使用量が予測可能で限定的なチームには逆に安くなる可能性があるが、ヘビーユーザーや自動化パイプラインを大規模に運用するチームにはコストが大きく上がる可能性がある。

パフォーマンスは下がったのに、料金体系はより複雑で大規模使用時には高くなりうる構造に変わった。Gizmodoのタイトルが多くのユーザーの感情を正確に表していた: 「Anthropic Is Jacking Up the Price for Power Users Amid Complaints Its Model Is Getting Worse.」

もちろんAnthropicの立場も理解はできる。フラットフィー構造はヘビーユーザーに絶対的に有利で、サービス提供者としては持続不可能な可能性がある。従量制への転換自体は合理的なビジネス上の決定かもしれない。使用量の予測が難しいフラットフィーモデルより、使った分だけ払う構造のほうが長期的に公正という論理もある。問題はタイミングだ。信頼が揺らいでいる時期に価格引き上げを発表すれば、その合理性は適切に伝わらない。

タイミングを変えていたらどうだっただろう。effortレベルの変更を十分に告知し、ユーザーのフィードバックを反映してデフォルトを改善してから、価格政策の変更を別途発表したとしたら? 3つの問題が同時に爆発することはなかっただろう。それぞれの決定が独立して評価を受けられる機会があっただろう。今は3つが一つにまとめられ、「Anthropicが退行している」というフレームで読まれている。

コンピュート不足説とAIサービスの構造的プレッシャー

この論争には、もう一つ大きな文脈がある。

LLMインフラ事業はお金を燃やすビジネスだ。Anthropic、OpenAI、Google DeepMindはすべてデータセンター容量の確保に数十億ドルを注ぎ込んでいる。Fortune の記事によれば、Anthropicは競合他社と比較してデータセンターの確保規模が相対的に小さいという分析がある。この点は私が直接確認できる内容ではなく、公式発表ではなく分析だ。Anthropicの公式財務開示やインフラ投資の詳細は非公開だ。ただし、FortuneとAxiosのような媒体がこの文脈を一緒に取り上げたことは注目に値する。単純なコミュニティの推測ではなく、業界取材に基づいた分析という点でだ。

ここから出てきた推測が「Anthropicがコンピュート不足のためeffortレベルを調整した」というものだ。内部的にMythosのような次世代モデル開発にコンピュートを集中投入し、既存サービスのeffortレベルを下げて運用コストを削減したという解釈だ。Anthropicはこの推測を公式に否定していない。

私が確信できることではない。しかし「コストプレッシャーによりサービス品質が静かに調整される」ことが、この業界でほとんど議論されない領域であるのは事実だ。

Claude Codeのエージェント的ワークフローパターン5種類を執筆する際も感じたが、エージェントシステムを複雑に構築するほど、モデルの小さなパフォーマンス変化がワークフロー全体に与える影響が指数関数的に大きくなる。Orchestrator-subagent構造を複数のレイヤーに重ねると、effortレベル一つがパイプライン全体の信頼性を低下させる可能性がある。今回、多くのClaude Codeユーザーが直接確認したことになる。

ユーザーは「モデルがアップグレードされるたびに良くなる」という期待を持っている。実際には、コストプレッシャーによってサービス品質が変わることがある。この二つの事実は同時に真実でありえる。新バージョンのモデルがより強力になる一方で、現在運用中のバージョンのサービス品質がコスト上の理由で調整されることがある。バージョンがアップグレードされないまま基本的な動作方式だけが静かに変わること — このAIサービス業界がこの構造的な乖離にどう対処するかが、今後この産業の信頼性を決定する重要変数になるだろう。

開発者が今すべきこと

この問題から実質的な教訓を引き出すとすれば、3点ある。

第一に、effortレベルを明示的に設定する。 Claude APIを直接呼び出す開発者なら、デフォルト値に依存せず、パラメータで直接effortを指定しておくべきだ。例えばClaude Codeの設定ファイルでdefault-model-settingsに"thinking": { "type": "enabled", "budget_tokens": 10000 }のような形で明示的に処理の深さを固定できる。デフォルト値はいつでも変わりうるということを今回確認した。重要なワークフローほど、すべてのパラメータを明示的に固定すべきだ。

第二に、成果物の品質を定期的に測定する。 LLMサービスの品質が静かに変わった際に素早く検知するには、基準点が必要だ。主要タスクのサンプルを一定周期で自動実行し、成果物を以前と比較する簡単なベンチマークがあるだけで、今回のような変化をずっと早く気づけた。完璧な評価システムは必要ない。例えば「指示した条件が成果物にすべて反映されているか」を自動的にチェックするスクリプトがあるだけで、今回の論争より2週間早く異常を検知できたはずだ。変化の検知が目的なので、過度に複雑なシステムを作る必要はない。

第三に、プロバイダー依存度を分散させることを真剣に検討する。 単一のLLMプロバイダーにすべてのワークフローを依存させると、そのプロバイダーの価格政策やパフォーマンス調整がそのままインフラリスクになる。まだ多くのチームが「ClaudeかOpenAI」で一元化して使っている。それは短期的には便利だが、長期的には交渉力もリスクヘッジもない構造だ。すべてを二重化する必要はないが、重要なワークフロー一つくらいは別のモデルでも動くように設計しておくといい。今回のように主要プロバイダーがパフォーマンスを調整したり価格を変えた際に、代替手段があることは交渉で有利になり、障害対応でも有利になる。LiteLLMのような抽象化レイヤーを使えば、プロバイダー切り替えコストを大きく下げられる。

私の立場: 透明性がなければ信頼もない

私はこの問題について明確な立場を持っている。

Anthropicの技術的な決定自体よりも、その決定をコミュニケーションした方法が間違っていた。

ユーザーのフィードバックに対応してトークン使用量を減らそうとした名目は理解できる。effortレベルを下げればトークンが減るのも正しい。この決定が悪意あるものだったとは思えない。しかし、デフォルト値が変わった際、特にパフォーマンスに直接影響するデフォルト値が変わった際には、すべてのユーザーにメールで通知するか、製品内のバナーで明確に伝えるべきだ。Changelog一行がコミュニケーションのすべてであれば、それは基準を満たしていない。既存のユーザー期待を下げる変更は、どんな理由があっても積極的な通知が必要だ。おそらくAnthropicも今回、その基準を改めて設定するだろう。

より根本的な問題は別にある。AIサービスプロバイダーがパフォーマンスとコストのトレードオフをユーザーに知らせることなく調整できる構造自体だ。これはAnthropicだけの問題ではない。OpenAIも、Googleも同じような構造を持っている。私たちは単一プロバイダーに深く依存したAIインフラを構築しており、そのプロバイダーがサービスレベルを静かに変えても、これを検知して対応する手段がほとんどない。

今回の論争は静かに収まるだろう。Anthropicがeffortレベルの設定オプションをより明確に提供するか、デフォルト値変更時のユーザー通知ポリシーを強化すれば良い。すでにいくつかの改善措置が発表されたという報道もある。おそらく数ヶ月後には、今回の問題は「かつて論争があった」という脚注程度に記憶されるだろう。

しかしAIインフラを構築する人であれば、今回の問題を一つのシグナルとして見るべきだ。LLM APIの上にプロダクションシステムを構築することが日常になった。その上に乗る責任も日常になりつつある。プロバイダーのSLAを自分でモニタリングすることが、選択ではなく必須になりつつある。

「AIはどんどん良くなっている」というナラティブは正しい。同時に、すでに使っているAIが静かに変わりうることも正しい。LLMサービスがインフラとして定着するほど、インフラに適用してきた管理原則 — 変化の検知、SLAモニタリング、プロバイダーの多様化 — をそのまま適用すべきだ。二つの話が共存するということを、今回の論争が示してくれた。