Opus 5.5はナーフされたのか — 体感を計測に変えようとするlivenerfの設計
Opus 5.5はナーフされたのか — 体感を計測に変えようとするlivenerfの設計
ホスティングされたモデルが「リリース後に静かに劣化する」という疑いは陰謀の問題なのか、それとも顧客側に観測手段がないという問題なのか?
導入
2026年9月29日(UTC)、Hacker Newsに「Livenerf: Has Opus 5.5 been nerfed yet?」という投稿が上がり、926ポイントを集めた。リンク先はGitHubリポジトリninjahawk/livenerfである。リポジトリの説明は一行だけだ。リリース後のモデル能力を追跡するベンチマーク。READMEは自らを「小さく、退屈で、追記のみ(append-only)のベンチマーク」と呼び、ただ一つの問いに答えようとしていると書く。モデルはリリース後に劣化するのか。
背景はおなじみのものだ。新しいモデルが出ると最初の数日は「アインシュタインと働いているようだ」という称賛があふれ、一、二週間後には「最近バカになった」という投稿が現れる。一週間前の9月21日にも「Fable 5 – Median thinking declined in August」という投稿が428ポイントを集め、同じ論争を引き起こした。READMEの問題提起はこの繰り返しを正確に狙っている。劣化は量子化かもしれないし、同じ名前の裏にある小さなモデルかもしれないし、推論努力(effort)の縮小やルーティング変更かもしれない。あるいは何も起きておらず、人々がノイズの中にパターンを見出しているだけかもしれない。しかし誰もクリーンな「0日目のベースライン」を持っていなかったため、あらゆる議論は「感覚対感覚」で終わる、というのである。
Claude Opus 5.5は2026年9月22日にリリースされた。livenerfはその日に時計を動かし、30日間毎日同じ問題セットを回すと宣言した。本稿はlivenerfが何を測るかよりも、なぜそう測らねばならないかに注目する。ホスティングされたモデルのドリフトは結局オブザーバビリティの問題であり、livenerfの設計上の選択の一つひとつがその難しさを示しているからだ。
現象分析: livenerfは何を、どう測るのか
まず事実関係を整理する。以下は9月29日時点のREADMEと、同じ方法論を維持しているそれ以降の版で確認した内容である。
測定対象は「APIのOpus 5.5」ではない。v0はAPIキーなしで、Claude Maxサブスクリプションを使ってheadlessのClaude Code(claude -p)を呼び出す。READMEはこの点を太字で強調している。livenerfが測るのはサブスクリプション経由でClaude Codeを通じて提供されるOpus 5.5であり、それこそが大半のナーフ報告が実際に指しているものであって、生のAPIモデルとは同じではない、と。フレームワークは英国AI Security InstituteのオープンソースのevalフレームワークであるInspectで、統計はAnthropicのEvan Millerによる「Adding Error Bars to Evals」に従う。READMEの言い方では「自家製のものがないので、議論の余地もない」。
スケジュールは次のとおりだ。1日目はリリースから約2.5日後の9月24日22:10 UTCだった。一日一回、30日間回す。1〜10日目がベースラインで、その後に10日間のウィンドウが二つ続く。したがって「変化した」と判定できる最も早い時点は10月24日前後になる。9月29日のREADMEの進捗記録は、30日中6日分を収集、欠損なし、6日すべてが同一のハーネスハッシュと固定されたCLI 2.1.280で90サンプルをフル実行、であった。
最も興味深いのは問題セット(パネル)の選び方である。GPQA Diamond、MMLU-Pro、競技数学、AIME 2025–26から2,336問を選び、各問を4回ずつ解かせた。Opus 5.5は初回で約93%を正解し、97%の問題は「常に正解するか常に不正解か」だった。残った78問、すなわち「ときどき正解する」問題だけがパネルになる。理由は情報量だ。常に正解する問題は低下を示し得ず、回すほどトークンを浪費するだけである。READMEは、通過率pの問題が1サンプルあたりp(1−p)の情報を持つというロジットシフトモデルを根拠に挙げる。
ここで作者は自らの選択バイアスまで測定している。「ときどき正解する」という理由で選ばれた問題は、実際よりも五分五分に近く見える。新たにサンプリングすると、これらの問題の通過率は54.7%から62.0%に上がり、検出力の計算には新しい値を使った。その結果、一日一回パネル全体を回せば10日ウィンドウごとに約7.5ポイントの正答率変化を検出でき、コストは週間プランの約3.6%だという。
次は検証である。READMEは「既知の劣化を検出できると証明する前は、いかなる変化なしの結果も信用しない」と書く。一種の陽性対照だ。effortをhighからlowに下げると、出力トークンは62%減り、正答率は8.3±4.5ポイント下がった。mediumに下げるとトークン26%減、正答率4.2±3.9ポイント低下だった。同時に限界もそのまま書いている。Opus 5.5の代わりにOpus 5を入れた場合、99%水準では区別できなかった(−3.8±6.3ポイント、トークン−23%)。同系統モデルへのこの程度の差し替えは、検証分のサンプルでは捉えられないという告白である。
判定ルールは事前登録(pre-registration)されている。変化と呼ぶには、99%区間が連続する二つの10日ウィンドウでゼロを除外し、効果が3ポイント以上であり、対照群が同じ方向に動かないことが必要だ。対照群はclaude-opus-5で、同じハーネスでパネルのGPQA問題を毎日一緒に回す。両者が一緒に動けば、変わったのはOpus 5.5ではなくハーネスかプラットフォームだという論理である。採点は完全一致のみで、LLMによる採点者は決して使わない。採点者もドリフトするからだ。改善も低下と同じ大きさで報告し、変化なしの結果も公開すると約束している。
深層分析: なぜここまでやる必要があるのか
livenerfの設計を一つずつ分解すると、各選択が「第三者がホスティングされたモデルの回帰を監視するとき何が難しいのか」への答えになっていることが見えてくる。
第一に、非決定性。READMEはOpus 5.5から同じ答えを二度得ることはできないと断言する。サンプリングパラメータはなくなり、thinkingもオフにできない。だからモデルを決定的にする代わりに、それ以外のすべてを決定的にする。プロンプトの凍結、CLIの固定、厳密な採点器、生ログの永久保存。9月21日のFable 5スレッドで、あるユーザーが「同じプロンプトを送るたびに違う答えが返るシステムで、再現可能なテストをどう作るのか」と問うていたが(直接の引用ではなく、コメントの要旨の要約)、livenerfの答えは「単一の出力ではなく分布を測り、その分布が動くかを見る」である。今回のスレッドでLeoPantheraが残した「n=1は無意味だ、出力は決定的ではない」という短いコメント(直接の引用ではなく、コメントの要旨の要約)は、体感報告全般に対する最も簡潔な反論だった。
第二に、ハーネスのドリフト。READMEはCLIの固定を「オプションではない」と書く。Claude Codeのアップデートはハーネスを変え、変わったハーネスは変わったモデルとまったく同じに見えるからだ。この警告は抽象論ではない。Anthropicが2026年4月23日に公開したポストモーテムは、Claude Codeの品質低下報告を三つの変更に突き止めた。3月4日にデフォルトの推論努力をhighからmediumに下げた決定(4月7日に差し戻し)、3月26日にアイドルセッションの古いthinkingを消す最適化にバグがあり毎ターン消してしまった問題(4月10日に修正)、4月16日に冗長さを減らすために入れたシステムプロンプトの指示がコーディング品質を損なった問題(4月20日に差し戻し)である。同じ記事はAPIは影響を受けなかったと明言している。つまり「モデル」はそのままだったのに、ユーザーが体験する品質は明らかに落ちた。livenerfがハーネスハッシュとCLIバージョンを毎回記録し、hermeticな呼び出し(ツール、MCP、設定、フック、CLAUDE.md、メモリなしの1ターン)に固執する理由はここにある。
第三に、測定指標そのものの選択。READMEが正答率の次に最も気にかけていると明かす二次シグナルは、サンプルあたりの出力トークン数だ。モデルが静かに考える量を減らし始めると、正答率より先にトークンに現れるという。検証結果がこれを裏付けている。effort mediumは正答率を4.2ポイント下げたが、そのエラーバーは3.9ポイントで、トークンは26%も減った。正答率ではかろうじて見える変化が、トークンでは鮮明である。Fable 5スレッドのタイトルが「thinkingの中央値の減少」だったこと、そしてそこで「thinkingトークンはクライアントに返されないのにどう測るのか」という質問(直接の引用ではなく、コメントの要旨の要約、CamperBob2)が出ていたことを並べると、何が見えるかがそのまま何を監視できるかを決めていることが分かる。ただし該当ツイートの原文は今回確認できなかったため、その数値はここでは扱わない。
第四に、サービング経路のノイズ。READMEによれば、安全性分類器がときどきOpus 5で回答したり、生物学や一部の数学の問題を拒否したりする。こうしたサンプルは棄却して集計し、影響を受けた問題は除外する。「Opus 5.5に聞いたのに答えたのは別のモデル」というケースが実際に存在し、それが測定器から見えるという事実は、ユーザーの体感をめぐる議論でしばしば抜け落ちる要素である。
Hacker Newsの反応は大きく三つに分かれた。一つ目は「ナーフなど存在しない」派である。solenoid0937は、モデルがナーフされているのではなく人々が新しい知能水準に慣れているだけだという「ホットテイク」を残し(直接の引用ではなく、コメントの要旨の要約)、johnfnは新モデルごとに扱える複雑さの天井があり、リリース直後は何でもできる気がするが数日後にはその天井にぶつかるという説明を示した(直接の引用ではなく、コメントの要旨の要約)。GPUからチャットUIまで自前のスタックを運用し、何も変えていないのに「ナーフされた」という苦情を受けていたというnsarrazinの経験談(直接の引用ではなく、コメントの要旨の要約)は、この派の最も強い根拠だった。semiquaverは、自社はAzureとAWS Bedrock経由でのみClaudeを使っているが、ナーフ系ベンチマークはなぜ他の推論プロバイダーを比較対象にしないのかと問うた(直接の引用ではなく、コメントの要旨の要約)。
二つ目は「ナーフはある」派だ。その根拠の大半は個人の体験で、一部はAnthropicが過去にハーネスのバグを認めたことを挙げた。gobdovanは、実際の回帰事例はあるが、それはナーフというより「インシデント」と呼ぶのが正確だとして、先述の4月23日のポストモーテムをリンクした(直接の引用ではなく、コメントの要旨の要約)。HawtAdsは、上流のプロバイダーを詳しく追跡しているが、GPUランタイム層のバグやアップデート一つで出力が壊れることがあり、重みが変わったり量子化されたりする必要はないと書いた(直接の引用ではなく、コメントの要旨の要約)。
三つ目が方法論への批判である。zeroonetwothreeは、README自身がOpus 5と5.5を区別できないと言っているなら役に立たないと指摘した(直接の引用ではなく、コメントの要旨の要約)。10日ウィンドウは長すぎるという質問にはninjahawk1アカウントが答えた。ウィンドウ長は感度と検出速度のトレードオフで、短ければノイズが大きく、長ければ数週間かかる。ウィンドウは毎日ずれていき、二つのウィンドウ連続で事前登録された99%基準を超えて初めて判定する。10日は神聖な数字ではなく、データが溜まれば見直す、という内容だった(直接の引用ではなく、コメントの要旨の要約)。攻撃的な批判もあった。octoberfranklinとquikoaは、一定間隔で同じリクエストが来ればプロバイダーは容易に検知し、そのリクエストだけナーフしないことができると述べ、nullbioはキャッシュが測定を汚染する可能性を提起した(いずれも直接の引用ではなく、コメントの要旨の要約)。パネルの問題を非公開にしてハッシュだけを公開するlivenerfの方針は一つ目の懸念をいくらか和らげるが、毎日同じ時間帯に同じ問題を送るというパターンそのものは隠せない。
展望と示唆: 顧客が観測手段を持つということ
livenerfが最終的に示しているのは「ナーフがあるかないか」の答えではなく、その問いに答えるのにかかるコストである。2,336問をふるいにかけて78問を残し、ハーネスを凍結し、陽性対照と対照群を置き、判定ルールを事前に公開コミットし、30日待つ。それでも同系統モデルの差し替えは捉えられないかもしれないと自ら書いている。個人の開発者が「今日はちょっとバカだな」と感じることとこれとの間には、途方もない隔たりがある。
この隔たりは信頼の非対称性をそのまま映している。プロバイダー側は公式見解を繰り返してきた。Anthropicは2025年9月17日のポストモーテムで「需要、時間帯、サーバー負荷を理由にモデル品質を下げることは決してない」と書き、2026年4月の記事でも「モデルを意図的に劣化させることはない」と明言した。同時に、その同じ二つの記事は実際に品質が落ちた事例を詳細に公開している。2025年8〜9月の三つのインフラバグのうち、コンテキストウィンドウのルーティングエラーは当初Sonnet 4リクエストの0.8%に影響していたが、8月29日のロードバランシング変更で拡大し、最悪の時間帯だった8月31日には16%に達し、その期間にリクエストしたClaude Codeユーザーの約30%が少なくとも一度は誤ったサーバーにルーティングされた。どちらの記事も、初期の報告は「ユーザーフィードバックの通常の変動と区別しにくかった」と書いている。プロバイダー内部でもシグナルとノイズを分けるのは難しかったということだ。
ならば意図の有無にかかわらず、顧客は「品質が変わったか」を独立に確認する手段を必要とする。サーバー運用で応答時間やエラー率を顧客自身が測るように、モデルの出力品質も顧客側の観測対象であるべきだということだ。livenerfのREADMEが「ナーフ」という言葉の代わりに「ドリフト」や「変化」という言葉を使い、リリース週こそが最悪の週かもしれないとして両側検定にこだわるのは、この観点と通じている。原因を仮定せず、変化だけを測る。原因はその次の問題である。
ただし、いくつかの限界は残る。第一に、livenerfが測るのは知識問題の正答率だ。ユーザーの不満の多くは、長時間のコーディングセッション、権限確認の頻度、使用量の消費速度に関するものだった。スレッドでも、同じ作業でもクォータメーターの減り方が違うという観察(user3939382)、コードベースが大きくなって同じモデルがより多くのトークンを読むようになったのをナーフと誤認しているという指摘(throwitaway222)、クォータが尽きかけたときにより悪いモデルが来るのかこそが本当の問いだという問いかけ(saejox)が出ていた(いずれも直接の引用ではなく、コメントの要旨の要約)。これらはlivenerfのパネルの外にある。第二に、単一アカウント、単一ハーネス、単一時間帯の測定である。アカウント単位や負荷時間帯単位の差別があったとしても、この設計では見えない。第三に、リリースから約2.5日後に開始しているため「本当の0日目」ではない。codr1はベースラインはリリース後3〜5日であるべきだと述べたが(直接の引用ではなく、コメントの要旨の要約)、livenerfのベースラインはそれより広い10日間である。
それでも、このプロジェクトが残す形式は再利用可能だ。「ときどき正解する問題だけを選ぶ」「正答率と一緒にトークンを見る」「ハーネスを固定してハッシュを残す」「同じハーネスで対照モデルを一緒に回す」「判定ルールをデータより先にコミットする」。自社製品にLLMを組み込んでいる企業にとって、この五行はプロバイダー契約書のSLA条項よりも実質的な防護策になり得る。
(10月17日追記: READMEの10月17日の進捗記録によれば、30日中25日分が収集され、1〜10日目のベースラインは780サンプルで0.584±0.036、11〜20日目の最初のウィンドウは780サンプルで0.592±0.037、ベースライン比+0.007±0.018、対照群+0.035±0.049で、判定は「変化なし」だった。出力トークンの中央値は588から606だった。ベースラインから実現した最小検出効果はウィンドウあたり6.6ポイントで、予測値の7.5より小さかった。19日目はMaxの週間メーターが尽きたため、APIクレジットで回したと記録されている。)
結論
「Has Opus 5.5 been nerfed yet?」という問いに対する9月30日時点の誠実な答えは「まだ判定できない」である。livenerf自身が最初の判定可能時点を10月24日前後に置いているからだ。しかしこのリポジトリが926ポイントを集めた理由は、答えではなく問いの形式を変えたことにあるのだろう。「感覚対感覚」の論争を「事前登録されたルール対データ」の問題へと移したのである。
その過程で明らかになったのは、ナーフ論争の両側がともに不完全な情報の上に立っているという事実だ。ユーザーはn=1の体感で劣化を主張し、プロバイダーは「意図的に下げてはいない」と言いながらも、ハーネス変更やインフラバグで品質が落ちた事例を事後になって公開してきた。意図がなかったという言葉は、結果がなかったという言葉ではない。
READMEには、このリポジトリのかなりの部分が測定対象であるClaudeの助けを借りて書かれたという告白がある。だから採点器は純粋関数であり、閾値は事前登録され、生データは公開されるのだという。「作者を信用する必要があってはならない、人間であれそうでないものであれ」。ホスティングされたモデルとその顧客の関係にもそのまま当てはまる一文である。あなたのチームは、いま使っているモデルが先月と同じモデルであることを確かめる手段を持っているだろうか。
出典: