なぜ、Fableの頭は悪くなったのか？

Fable 5が公開された直後、タイムラインは絶賛であふれていました。

「今までのモデルとは別物だ」「もう人間より賢い」。ところが、しばらくすると空気が変わります。「前より指示を無視する」「考えが浅い」「途中で仕事を投げる」。僕自身、以前なら前提を調べ、関連するファイルまで確認していた場面で、今のFableは目の前の答えだけを作って終わる、と感じることがあります。

よく言われるのは、計算資源が足りず推論量を減らしているという説です。いわゆる「サイレントナーフ」です。

Anthropicは、現在のFableに何が起きているのかを公表していません。そのため、この記事で原因を証明することはできません。

ただし、確認できる時系列と、Anthropicが過去に公表した品質事故を重ねると、可能性の高低は見えてきます。

僕の結論を先に書きます。

Fableの品質は、実際に公開直後より落ちている可能性が高い。ただし、モデルの重みを意図的に弱くした「サイレントナーフ」より、急拡大する本番環境のどこかで起きた「サイレント・リグレッション」の方が、現在の証拠にはよく合います。

Anthropic公式の説明では答えられない性能低下

まず、公開直後から現在までの変化を説明できないものは、今回の原因候補から外す必要があります。

Fableには、作業を早く切り上げる、情報が足りないまま答える、といった弱点があるとSystem Cardに書かれています。危険な依頼を検出すると別モデルへ切り替える安全分類器もあります。effortは厳密なthinking token数ではなく、思考の深さをモデルへ伝える信号にすぎません。

どれもFableの挙動を理解するうえでは重要です。しかし、公開直後から存在した性質だけでは、「同じ使い方をしているのに、数週間後から悪くなった」という変化を説明できません。

安全分類器によるfallbackも、実際にfallbackが記録された会話の説明にはなりますが、Fable自身が回答している場面まで悪くなった理由にはなりません。既定のeffortが変わっても、自分でmaxに固定している利用者には関係ありません。

利用者の期待値が上がった、難しい仕事を任せるようになった、という心理的な効果もあるでしょう。しかし、同じ仕事を同じ手順で繰り返している利用者まで、一斉に「変わった」と報告している事実を、それだけで片づけるのも無理があります。

今回の問いは、Fableが賢いかどうかではありません。

公開直後と現在の間に、何が変わったのか。

ここに答えられない説明は、今回の主因にはできません。

品質低下には、時間軸がある

Fable 5は6月9日に公開されました。ところが6月12日、米政府が新モデルへ輸出規制を適用したため、Anthropicは本人の国籍を即時に確認できないとして提供を停止しました。
規制解除後の7月1日に、新しい分類器とともに再公開されています。7月20日にはMaxプランの標準枠へ組み込まれ、7月24日にはOpus 5もClaude Codeへ投入されました。

そして7月末から8月にかけて、Fableを含むClaudeの障害や性能低下が公式statusに繰り返し記録されています。

利用者からの報告が増える時期にも、公開直後とはずれがあります。

あるClaude Code利用者は、6月の初回公開では起きなかった早期終了が、7月の再公開後から繰り返されるようになったと報告しています。
別の利用者も、公開直後は戦略立案が突出していたのに、数週間後には2、3個の作業で目的を見失い、修正のループへ入るようになったと書いています。

これは管理されたベンチマークではなく、利用者による観測です。投稿数が増えたこと自体も、原因の証明にはなりません。

報告されているのは「Fableは最初からこうだった」ではなく、同じ利用者の同じ仕事における縦の比較です。

現在起きていることを考えるなら、この時間軸を説明できる仮説が必要です。

最有力は、本番環境のサイレント・リグレッション

ここでいう「リグレッション」とは、機能を改善したり運用を効率化したりする変更によって、それまで動いていたものの品質が意図せず後退することです。コストを下げるため意図的に弱くする「ナーフ」とは区別します。

Fableの場合、固定されているのはモデルの重みとモデル設定です。利用者の入力がそのモデルへ届き、回答として返るまでの経路全体が固定されているわけではありません。

利用者の入力
  ↓
安全分類器
  ↓
request router / load balancer
  ↓
GPU・TPU・Trainium上の推論runtime
  ↓
sampling logicによるtoken選択
  ↓
利用者が読む回答

「同じFableを使っている」ときに固定されているのは、この中で使われるモデルの重みです。その前後には、Anthropicが運用上更新できる複数の層があります。

層	何をしているか	不具合が起きたときの見え方
依頼の振り分け（request router / load balancer）	依頼を処理するserver群やhardwareを選ぶ	特定の利用者や時間帯だけ品質が落ちる。会話を続けても悪い状態が残る
推論実行系（runtime）	重みをGPUやTPU上で実際に計算する	同じ重みなのに、文脈に合わない語やsyntax errorが増える
token選択（sampling logic）	計算した確率から次のtokenを選ぶ	有力な選択肢が落ち、同じpromptでも結果が不規則に崩れる
安全分類（classifier）	Fableへ通すか、拒否・fallbackするかを決める	Fableを選んだのに別モデルが答える

たとえば重みから得られた次のtokenの確率分布が妥当でも、samplingの実装が最有力候補を取りこぼせば、回答はそこで別の方向へ進みます。一語の選択がずれるだけでも、その後の推論はずれた文脈を前提に続きます。長いcoding taskでは、小さな誤差が「前提を確認しない」「間違った設計を押し切る」「早く話を閉じる」という大きな差になり得ます。

つまり、重みが同じであることと、同じ品質の回答が返ることは同義ではありません。

Anthropicも、この区別をモデルのversioningに関する説明に明記しています。Claude 4.6以降の正式なモデルIDでは、同じIDの重みとモデル設定を後から更新しません。一方で、request router、安全分類器、sampling logicなどの配信基盤は更新されます。

そのうえでAnthropicは、以前まで安定していたモデルIDに予期しない挙動の変化が現れた場合、最も可能性が高い原因は配信基盤の更新であると説明しています。これは外部の批評家による推測ではなく、Anthropic自身が示している切り分け方です。

同じ重みのClaudeが、本当に劣化した三つの事故

配信基盤の違いは、観測できる程度の小さな揺らぎしか生まないようにも思えます。しかしAnthropicは2025年、同じモデルの回答品質を実際に低下させた三つの不具合を起こしています。

公式の事後検証に書かれている内容を、今回の問いに関係する部分だけ整理すると次のようになります。

事故	実際に変わったもの	利用者に起きたこと	今回と関係する点
context windowの誤routing	短いcontextの依頼を、1M context用のserver群へ送ってしまった	回答品質が低下した。load balancing変更後に影響が拡大し、期間中にClaude Code利用者の約30%が少なくとも一度は影響を受けた	model IDとeffortが同じでも、送られるserverによって品質が変わる
TPU runtimeの設定不備	高速化のためのruntime最適化が、出るはずのないtokenへ高い確率を与えた	英語の途中にタイ語や中国語が混ざり、codeでは明白なsyntax errorが増えた	modelではなく、modelを動かす実装が出力を壊す
token選択処理の不具合	approximate top-kと数値精度の組み合わせで、最も確率の高いtokenが候補から落ちた	同じpromptが、あるrequestでは成功し、次では失敗する不規則な状態になった	「昨日は賢かったのに今日は駄目」「人によって評価が違う」を説明できる

一つ目のrouting不具合には、さらに今回を考えるうえで示唆的な性質がありました。routingが「sticky」だったため、一度誤ったserverへ送られた会話は、その後も同じserverへ送られやすくなっていました。

その結果、ある利用者には「会話の途中からずっと馬鹿になった」と見える一方、影響を受けない利用者には普段どおりのClaudeが返ります。全員が同時に壊れるわけではないため、オンラインでは「明らかに悪くなった」と「自分の環境では問題ない」が両方とも本当になります。

三つ目のsampling不具合も同じです。同一promptでも毎回失敗するとは限りません。何度か試すと良い回答が返るため、単なるモデルの確率的な揺らぎに見えます。しかし実態は、本番環境に入った不具合でした。

なぜAnthropicの評価では見つからなかったのか

これらの事故は、利用者が騒ぎ始める前に社内評価で検出されたわけではありません。

2025年8月初旬から利用者は品質低下を報告していました。しかし当初、Anthropicは通常の評価のばらつきと区別できませんでした。報告の頻度と継続性が増した8月末になって調査を始め、重なっていた三つの不具合を発見しています。

Anthropicは、通常のbenchmarkや安全評価では利用者が訴えていた劣化を捉えられなかったと認めています。Claudeが一度の間違いから立て直せること、hardwareやplatformによって発生率が違うこと、利用者の会話をprivacy上自由に確認できないことが、発見を難しくしました。

これは「公式が障害を発表していないから、現在のFableに問題はない」とは言い切れない理由でもあります。成功応答の意味的な品質低下は、error率や稼働率だけを見ても分かりません。一定期間の利用者報告が、内部調査より先に異常を捉える場合があります。

今回のFableと、過去の事故はどこまで一致するのか

現在のFableで、過去と同じ不具合が再発した証拠はありません。ここは明確に分ける必要があります。

それでも配信基盤のリグレッションを最有力と考えるのは、他の仮説より多くの観測を一度に説明できるからです。

現在報告されていること	配信基盤のリグレッションなら、なぜ説明できるのか
公開直後は良かったのに、後から悪くなった	model公開後にもrouter、runtime、samplingは更新される
max effortでも思考が浅い	effortはモデルへの信号であり、その後のroutingや計算実装の正しさまでは保証しない
Fable以外のモデルでも似た不調がある	同じ種類の配信基盤やhardware実装が複数モデルへ影響する場合がある
人によって評価が大きく違う	requestを処理したserver、hardware、時刻、routingの状態が異なる
同じpromptでも良いときと悪いときがある	samplingや特定のserverだけに起きる不具合は、requestごとに症状が変わる
errorではなく、考えが浅くなったように見える	推論処理の一部が壊れても、HTTP request自体は成功し、文章として成立した回答を返せる

最後の行は、今回の現象を考えるうえで外せません。配信基盤の不具合は、必ずservice outageとして現れるわけではありません。status pageが正常でも、返ってきた文章の判断や一貫性だけが落ちる可能性があります。

事実として言えることと、まだ推測にすぎないこと

この仮説は有力ですが、現在のFableで原因が特定されたわけではありません。証拠の境界は次のとおりです。

確度	現在言えること
確認済み	固定model IDでも配信基盤は更新されます。過去にはその更新が、同じ重みのClaudeを実際に劣化させました
有力な推測	需要と提供範囲が急拡大した時期に、FableまたはClaude Codeの配信経路へ同じ種類のリグレッションが入った可能性があります
未確認	どの変更が原因か、どの利用者が影響を受けたか、現在も継続しているかは公表されていません
現時点では根拠なし	意図的にFableの重みを弱くした、秘密の小型modelへ差し替えた、という証拠はありません

したがって、「Fableの重みは固定されているから、性能低下は気のせい」という説明は成り立ちません。固定されたモデルを取り巻く本番環境だけで、利用者がはっきり気づくほど品質を落とせることは、Anthropic自身の事後検証で確認されています。

今回も同じ種類の事故だと断定はできません。しかし、公開後の時間差、利用者ごとのばらつき、max effortでも残る浅さ、他モデルにも広がる不調を同時に説明できる点で、現時点では最も筋の通った仮説です。

計算資源不足は、品質低下とどうつながるのか

計算資源が逼迫しているという話も、単なる噂ではありません。

Anthropicは、Claudeの利用急増がインフラへ負荷をかけ、ピーク時間帯のreliabilityとperformanceへ影響していると公表しています。Fableの初回公開時にも、需要を予測することが難しく、subscriptionでの提供はcapacity次第だと説明していました。

その後Anthropicは、SpaceXからColossus 1の計算能力を調達しました。発表された規模は、22万基を超えるNVIDIA GPUと300MW超です。Anthropicが「xAIに泣きついた」とまでは言えませんが、外部の巨大な計算基盤を急いでClaudeへ接続するほど、推論需要が事業上の制約になっていたことは分かります。

では、混雑時にthinking tokenを秘密に削っているのでしょうか。

その直接的な証拠はありません。通常、capacity不足はrate limit、遅延、overloaded error、利用上限として現れます。Anthropicは過去の事後検証で、需要やserver loadに応じて意図的にモデル品質を下げることはないと説明しています。ただし、これはAnthropic側の説明であり、現在のFableで実効的な計算量が維持されていることを外部から証明するものではありません。

ただし、そこで議論を終えるのも早すぎます。

需要の急増に対応するには、新しいhardwareを加え、requestを振り分け、runtimeを最適化し、障害時のfallbackを調整する必要があります。先ほどの事後検証が示した品質事故は、まさにrouting、load balancing、hardware固有のruntime、sampling最適化から生まれました。

意図しない品質低下が起きたとすれば、次の経路が考えられます。

推論需要の急増
  ↓
capacity拡張と配信基盤の変更を急ぐ
  ↓
routing・runtime・samplingのどこかにリグレッションが入る
  ↓
errorにはならないが、成功した回答の品質が落ちる

ただし、この経路だけに決めることはできません。計算コストを抑えるため、Anthropicがthinking、tool利用、timeoutなどの実効的な予算を意図的に減らしている可能性も残ります。利用者がmax effortを選んでも、製品側のすべての計算予算を監査できるわけではありません。

公開情報から確認できるのは、推論需要が急増し、Anthropicが大規模なcapacity拡張を急いでいることまでです。その対応過程で意図しない不具合が入ったのか、計算資源を節約する調整が行われたのか、あるいは両方なのかは分かりません。

過去の公式事後検証があるぶん、配信基盤のリグレッションには具体的な前例があります。一方で、意図的な計算量削減も外部からは否定できません。ここでは、どちらか一方を事実として断定せず、二つの可能性を残します。

Claude Code側の変更も、Fableを別人にできる

もう一つの有力候補は、モデルの手前にあるClaude Codeです。

Claude Codeで利用者が触れているものは、Fableの重みだけではありません。

Claude Codeで体験するFable
= 固定されたモデル
× system prompt
× tool定義とagent loop
× context圧縮
× timeout・retry・終了判定
× 配信基盤

Anthropicのprompt cachingの説明には、Claude Codeの新しいversionでは通常、system promptまたはtool定義が更新されると書かれています。

実際、7月から8月のClaude Codeのchangelogには、auto-compactが発動しない、context表示が古い、thinkingの切替が反映されない、指定したfileが黙ってcontextから落ちる、最初のturnでMCP toolへ接続されない、といった修正が並んでいます。

こうした不具合は、benchmark上のモデル能力を変えません。しかし実務では、必要な資料を読まない、途中で考えるのを止める、前の指示を忘れるという、「頭が悪くなった」としか見えない症状になります。

過去には、回答を短くするsystem promptの変更だけで、coding性能が3%落ちたこともAnthropic自身の事後検証で確認されています。

この仮説は、Claude Codeだけで劣化を感じ、同じ固定IDをMessages APIから呼ぶと品質が戻る場合に強くなります。反対にAPIでも同じ時期から落ちているなら、Claude Codeだけが原因とは考えにくくなります。

意図的に推論量を減らした可能性はあるのか

サイレントナーフ説も、ゼロとは言い切れません。

Anthropicは過去に、応答速度とtoken消費を抑えるため、Claude Codeの既定effortをhighからmediumへ変更したことがあります。これは後に公表され、撤回されました。つまり、品質と計算コストのtrade-offを製品側で調整する動機も手段もあります。

また、利用者がeffortをmaxにしていても、製品全体を完全に固定できるわけではありません。effortは厳密なtoken予算ではなく、モデルへの行動指示です。system prompt、agent loopの上限、tool利用、timeout、context圧縮、samplingの実装までは固定しません。

そのため、表面上の設定を変えず、実効的な計算コストを下げる方法は技術的にはあります。

ただし現時点では、thinking量が時系列で一貫して減った記録も、AnthropicがFableを小さいモデルへ差し替えた証拠も、秘密の量子化版を配信した証拠もありません。

意図的な計算量削減は「可能」ですが、公開情報から最有力とは言えません。動機があることと、実行した証拠があることは別です。

可能性を、証拠の強さで並べる

仮説	時間差を説明できるか	根拠	現時点の評価
配信基盤のrouting・runtime・samplingに不具合が入った	できる	同じモデルを劣化させた過去の公式事後検証、現在も更新される層、直近の障害	最有力
Claude Codeのsystem prompt・tools・context処理が変わった	できる	version更新でpromptとtoolが変わる公式仕様、直近の複数の不具合修正	有力。Code限定なら特に強い
混雑対策として実効的な推論量を秘密に減らした	できる	capacity逼迫と、過去のeffort変更という状況証拠	可能だが直接証拠なし
固定IDを小さいモデルや低精度版へ秘密に差し替えた	できる	技術的には可能	証拠がなく、公式versioningとも矛盾するため低い
Fableがもともと苦手だった、利用者が慣れただけ	できない	一部の失敗は説明できる	現在の変化の主因にはならない

ここから見えるのは、原因が一つとは限らないことです。

需要急増を受けて配信基盤が変わる。同じ時期にClaude Codeのsystem promptやcontext処理も変わる。さらに、計算資源を節約する調整が行われている可能性もあります。それぞれが小さな劣化でも、重なると利用者には「急に考えなくなった」と見えます。

では、Fableの頭はなぜ悪くなったのか

内部の記録を持たない以上、原因を一つに確定することはできません。

それでも、「何も変わっていない。利用者の期待値が上がっただけ」という説明には納得できません。同じモデルの重みでも、本番環境の変更によって本当に品質が落ちた事例をAnthropic自身が公表しています。現在のversioning文書も、安定していたモデルIDの挙動が変わった場合、まず配信基盤の更新を疑うよう説明しています。

一方で、「計算資源が足りないので、意図的に思考を削った」と断定する証拠もありません。

現時点で最も筋が通るのは、次の説明です。

Fableの重みが摩耗した可能性は低いでしょう。需要急増の中で、Fableを動かすrouting、runtime、sampling、Claude Codeのharnessは公開後も変わっています。そのどこかで公表されていないリグレッションが起きた可能性と、実効的な計算量を意図的に抑えている可能性の両方が残ります。

現在の証拠だけで、サイレントナーフではないと言い切ることもできません。ただ、同じ重みの品質を落とした具体的な前例があるため、僕はまずサイレント・リグレッションを疑っています。

この仮説は検証できます。同じ課題を、同じFableの固定IDでClaude CodeとMessages APIから繰り返します。APIも同じ時期に崩れるなら配信基盤が濃い。Codeだけならsystem promptやtools、context処理が濃い。実際のthinkingやtool callが時間とともに系統的に減っているなら、計算量削減説が強くなります。

Anthropicが説明を出すまでは、断定はできません。

しかし少なくとも、利用者が感じている性能低下を「気のせい」や「Fableはもともとそういうモデルだった」で終わらせる段階ではありません。

今のFableは、公開直後と同じ重みかもしれません。しかし、公開直後と同じ知能体験ではありません。