Claude Codeの性能低下追跡用デイリーベンチマーク

• Claude Code Opus 4.5 のSWEタスク性能を毎日測定し、統計的に有意な性能低下を検出する追跡システム
• SWE-Bench-Pro の選別されたサブセットを用いて、毎日50件のテストインスタンスを評価し、結果は CLI環境で直接実行された実際のモデル性能を反映
• 直近30日間の 平均通過率54%、ベースライン58%に対して 統計的に有意な4.1%の低下が検出
• 日次および週次の結果は、95%信頼区間と**有意性しきい値（±14.0%、±5.6%）**を基準に分析され、短期的な変動と長期的な傾向を区別
• 独立した第三者機関が運営し、モデルまたは実行環境の変化による性能低下を早期検出するツール

---

概要

• このトラッカーの目的は、Claude Code Opus 4.5 のSWEタスク性能における 統計的に有意な低下 を検出すること
  • 毎日 SWE-Bench-Pro の汚染耐性サブセットを使って評価を実施
  • Claude Code CLI で直接実行し、別個のカスタムハーネスなしで実際のユーザー環境を反映
• 独立した第三者機関であり、フロンティアモデル提供者との提携はない
• 2025年9月の Anthropicの性能低下に関するポストモーテム 以降、今後の類似事例を早期に検出するためのリソースとして運用

性能サマリー

• ベースライン通過率: 58%
• 直近30日の通過率: 54%（655回の評価に基づく）
• 直近7日の通過率: 53%（250回の評価に基づく）
• 直近1日の通過率: 50%（50回の評価に基づく）
• 30日間の性能低下 は p < 0.05 の水準で統計的に有意
  • 30日の変化幅: -4.1%
  • 有意性しきい値: ±3.4%
• 1日（-8.0%）および7日（-4.8%）の変化は 統計的に有意ではない

日次および週次の傾向

• 日次傾向（Daily Trend）
  • 直近30日間の日別通過率を可視化
  • ベースライン58%、有意性しきい値範囲 ±14.0%
  • 95%信頼区間 を表示可能で、標本数が少ないほど区間は広くなる
• 週次傾向（Weekly Trend）
  • 7日移動平均により日次の変動性をならした傾向を提供
  • ベースライン58%、有意性しきい値範囲 ±5.6%
  • 同様に 95%信頼区間 を表示可能

変化概要（Change Overview）

• 1日の変化（昨日比）: -8.0%、統計的に有意ではない
  • 50回の評価基準で、±14.0%の変化が必要（p < 0.05）
• 7日の変化（先週比）: -4.8%、統計的に有意ではない
  • 250回の評価基準で、±5.6%の変化が必要（p < 0.05）
• 30日の変化（先月比）: -4.1%、統計的に有意
  • 655回の評価基準で、±3.4%の変化が必要（p < 0.05）

方法論（Methodology）

• 各テストを ベルヌーイ確率変数 としてモデル化し、95%信頼区間 を計算
• 日次、週次、月次の通過率の統計的差異を分析し、有意な性能低下の有無を報告
• 毎日50件のテストインスタンスで評価を実施するため、短期的な変動性が存在
• 週次および月次の集計結果 は、より安定した推定値を提供
• モデル変更 または 実行ハーネス変更 による性能低下のいずれも検出可能

通知機能

• 性能低下が統計的に検出された場合、メール通知を送信
• ユーザーはメールアドレスを登録して購読可能
• 購読確認後に通知を受信でき、エラー発生時には再試行案内あり

---

[iolothebard]

Claude Code がバカになったわけじゃなくて……使う人のほうが Claude をもっと上手く活用できるようになった……のかも……

[GN⁺]

Hacker Newsのコメント

• Claude CodeチームのThariqです
  1月26日に発生したharnessの問題を修正しました。1月28日にロールバックも完了しているので、claude updateコマンドで最新版に更新することを勧めます

  • Claude 2.1.xは頻繁にフリーズしたりCPUを100%使い切ったりして、実質的に使い物にならない状態です。関連イシューはGitHub #18532にあります
  • Claudeがトークンを無駄遣いした件について、補償があるのか気になります
  • “harness issue”が正確に何を意味するのか、そしてどんな影響があったのかをもっと知りたいです
  • 問題は1月26日以前からありました。その頃からClaudeが「改善」だとして計画を勝手に書き換え始めました
  • モデル自体よりも品質管理の仕組みが気になります。実際の出力サンプルを定期的に点検したり、ベンチマークで性能劣化を監視したりする社内プロセスがあるのか疑問です。AI安全性の観点でも、こうした検証は必須です

• SWE-benchの共同著者です
  現在のテストは50件のタスクだけを対象に、1日1回しか実行されていないようです。精度を上げるには、300件のタスクに対して1日5〜10回テストして平均を取るべきです。サーバー負荷のようなランダム要因が結果に大きく影響し得ます

  • サーバー過負荷による性能低下も測定対象であるべきでは？ モデル蒸留だけを測りたいのでなければですが
  • モデル実行コストが問題なのでしょう。Anthropicが少しクレジット支援をしてくれるか、寄付リンクを設けてくれるとよいと思います
  • 時間帯による性能差のほうが大きい可能性もあります
  • SWE-benchの実行コストが高すぎて、十分に回せないという悩みがあります。mafia-arena.comでも似た問題が起きています
  • 「サーバーが過負荷だから測定が正確ではない」というのは妙に聞こえます。では、Claudeがちゃんと動く勤務時間でもあるのでしょうか？

• Anthropicがユーザーにより悪いモデルを提供しているとは信じない理由をまとめます

  1. 精度の低下幅が小さく、振動するように上下している
  2. Sonnet 4.5との比較基準がなく、GPU負荷時にはOpusがSonnet水準まで落ちる可能性がある
  3. 複数のチェックポイントをA/Bテストしている可能性が高い。Claude Codeのバージョン更新やトークンサンプリングの非決定性も原因になり得る
  • 科学的な説明は理解できますが、毎日使っていると確かに性能が悪化している感覚があります
  • 私もA/Bテストが主因だと思います。コンテキストウィンドウの制限やシステムプロンプト変更などを透明に公開してほしいです。ユーザーが直接バージョンを選んでフィードバックできる形が理想です
  • グラフが1月8日から始まっている理由が気になります。その日が異常に高かった日だった可能性もあります
  • 負荷に応じて性能とコストの調整を自動で変える仕組みなのかもしれません。最初は高性能で始め、徐々にコスト削減のためにモデルを縮小したり、MoEの専門家数を減らしたりする形で調整している可能性があります
  • 「低下幅が小さすぎる」という主張は、統計的有意性を無視した主観的判断にすぎません

• 統計手法がおかしいです
  彼らは以前の値の信頼区間だけを見て、新しい値がその外にあるかを確認するやり方ですが、これは差の統計的有意性を検証する正しい方法ではありません。両方の測定値に不確実性があるので、差そのものの信頼区間を計算すべきです。また月次比較なら、60〜31日前のデータと30日前〜昨日までのデータを比較する必要があるので、グラフは最低でも2か月分を示すべきです

• 1週間ほど前、Claudeが約1時間ダウンしたことがありました。復旧直後はユーザー数が減っていたせいか、速度が3倍以上速くなっていました。その1時間の間に、普段なら半日かかる仕事量を片付けました。資源制約のない未来を少しだけ見たような気分でした

  • アメリカの祝日期間中も利用制限が緩和されて、すべてがずっと滑らかに動いていました
  • 私も数日前に同じ経験をしました。あまりに速くて「claude speed boost」と検索したほどです。昔モデムをアップグレードしたときのような一瞬の電光石火の速さでした
  • 速すぎると逆に少し寂しいです。今はモデルが一生懸命働いている感じがして、それはそれで好きです

• ユーザープロンプト内の罵倒語の頻度を測れば、モデル性能が落ちたときのユーザー敵意の上昇を検知できるかもしれません

  • でも、Claudeのユーザープロンプトを「単純に」スキャンする方法なんてあるのでしょうか？
  • “How’s Claude Doing This Session?” のようなフィードバック依頼の直後に、罵倒語が増える相関関係があります
  • 私はもともと悪態をよくつくので、データが歪むかもしれません
  • 私もそういうタイプなので安心しました
  • ときどきあまりに間抜けな答えをされると悪態が出ます。期待値が高いから起きる反応です

• 時間の経過とともに**モデルを段階的に量子化（quantization）**している可能性があります。そうすればスケーラビリティ向上やコスト削減がしやすくなり、新バージョンがより「良く見える」効果も出ます

  • 毎日5〜10時間使っていますが、最近1週間は確かに前より間抜けになった感じがあります。彼らが否定しても、体感として変化があります
  • わざわざ量子化しなくても、会話長の短縮や推論時間の短縮などで負荷を下げることはできます
  • オープンモデルのGPT-OSSやKimi K2.xも4bitレイヤーで学習されています。Opus 4.5はトークン単価が8倍高いのでより大きなモデルである可能性が高いですが、サブスクリプションの価格体系のため単純比較は難しいです
  • Anthropicがインフラコストにそこまで制約されている会社には見えません。競争が激しい状況で品質を意図的に下げるのは悪い戦略です。おそらくユーザーが**「ハネムーン効果」**の後で欠点に気づきやすくなっただけかもしれません
  • それでも、この種の段階的劣化戦略は十分あり得るように思えます。新モデルの相対的な改善効果を最大化できますから

• APIモードでは、Claudeは一定のトークン数を超えると急に間抜けになり、「23行目にバグがある」と言いながら機能全体を削除するような的外れな振る舞いをします。ChatGPT 3.5でもできる単純な修正すら失敗します。なぜこうなるのか理解できません

  • おそらくリソース制約が原因でしょう。一部のユーザーに優れた回答を返すより、より多くのユーザーにそこそこの回答を返すほうを選んだ可能性が高いです
  • 私も同じ経験をしました。Claudeがどんどん怠け者になっている感じです

• この1週間ほどで、Claudeのコード品質が目に見えて悪化しました。たとえばEnumにfrozenを使えと言ったり、すでにurlparseを使っている関数に再びurlparseを提案したりします。以前はこうした基本的なミスはしませんでした

• LLMプロバイダーの推論能力の一貫性のなさが大きな不満です。ChatGPTでも同様で、45kトークンを超える入力では知能が急激に落ちたり入力が切り捨てられたりします。いっそ「拒否」メッセージを出してくれたほうがよく、こっそりダウングレードされるのは信頼を失います。透明性が本当に重要です

  • おそらくMaximum Effective Context Window現象と関係しているのでしょう