最近のClaude品質低下に関する3件の事後分析

• 8月から9月初旬にかけて、Claudeの応答品質低下が3つのインフラバグによって発生
• 問題の主な原因はそれぞれ、コンテキストウィンドウのルーティングエラー、出力破損、そしてXLA:TPUの近似top-k未コンパイルエラー
• 各バグはさまざまなハードウェアやデプロイ経路で相互に重なって発生し、診断をさらに難しくした
• 検知と解決が遅れた要因には、検証プロセスの抜け穴や、プライバシーポリシーに基づくアクセス制約などがあった
• Anthropicは、評価とモニタリングの強化、より迅速なデバッグツールの開発などを通じて、同様の事故の防止に取り組んでいる

---

概要と背景

• 8月から9月初旬まで、Claudeの応答品質が断続的に低下する現象が報告された
• 当初はユーザーフィードバックの中で通常の変動と見なされていたが、報告が継続的に増加したことで調査が始まった
• Anthropicは、需要やサーバー負荷ではなく、インフラバグのみが問題の原因であることを明確にした
• Claudeは数百万人のユーザーに対し、複数のプラットフォーム（APIs、Amazon Bedrock、Google Vertex AIなど）を通じて提供されており、AWS Trainium、NVIDIA GPU、Google TPUなど多様なハードウェア上で同等の結果を保証するため、厳格な検証基準を持つ
• 今回の事後分析では、バグの原因、診断と解決の遅延理由、そして再発防止策を説明する

Claudeの大規模サービス体制

• Claudeのサービスは複数のハードウェア（Trainium、GPU、TPU）を通じてグローバル展開を維持している
• 各プラットフォームごとの同一品質保証に向けた実装同等性の基準は厳格である
• インフラ変更時には、すべてのプラットフォームと設定において精密な検証プロセスが必要となる

主要な問題発生のタイムライン

• 8月5日: 1つ目のバグ。Sonnet 4リクエストの約0.8%に影響
• 8月25日、26日: 2つ目、3つ目のバグがそれぞれデプロイされた
• 8月29日: ロードバランシング変更により問題のあるトラフィックが急増し、より多くのユーザーが影響を受けるようになった
• 各バグは症状が重なり、診断難易度が非常に高かった

3つの重複バグと解決過程

1. コンテキストウィンドウのルーティングエラー

• 8月5日、一部のSonnet 4リクエストが1Mトークンのコンテキストウィンドウ向けサーバーに誤ってルーティングされた
• ロードバランシング変更後は、最大16%のSonnet 4リクエストに影響し、Amazon BedrockとGoogle Vertex AIにも軽微な影響が発生した
• ルーティング方式が"sticky"だったため、一度誤ったサーバーに接続されると、その後も同じサーバーに接続され続ける問題があった
• 解決: ルーティングロジックを改善し、9月4日に自社プラットフォームへパッチを適用、Google Cloudには9月16日までにデプロイ、Bedrockには段階的に適用中

2. 出力破損（bug）

• 8月25日、Claude APIのTPUサーバーに誤った設定が適用され、トークン生成時にエラーが発生
• 英語の質問にタイ語や中国語など無関係な文字が混ざって出力されたり、コードに明白な文法エラーが挿入されたりする現象が発生
• Opus 4.1、Opus 4、Sonnet 4のみに影響し、サードパーティープラットフォームには影響しなかった
• 解決: 9月2日に変更をロールバックし、異常文字出力を検知するテストをデプロイプロセスに追加した

3. 近似top-kのXLA:TPU未コンパイルエラー

• 8月25日、トークン選択方式の高度化の過程で、XLA:TPUコンパイラの潜在的なバグが表面化した
• Claude Haiku 3.5、一部のSonnet 4、Opus 3に影響
• サードパーティープラットフォームには影響なし
• 解決: Haiku 3.5は9月4日、Opus 3は9月12日にそれぞれロールバックし、Sonnet 4では直接再現されなかったものの予防措置としてロールバックした
• 並行してXLA:TPUチームと協力してコンパイラバグを修正中であり、正確なtop-k方式への切り替えを進めている

XLAコンパイラバグの詳細分析

• Claudeはトークン生成過程で各候補に対する確率計算とサンプリングを行う
• TPUは分散環境で動作するため、トークン確率計算の同期が必要であり、複雑さを伴う
• 2024年12月、bf16-32ビット混合精度の使用に伴う誤差により、最上位確率のトークンが欠落する問題が見つかり、これに対する暫定修正がデプロイされた
• 8月26日、根本原因を解決するためのサンプリングコード改修中に、近似top-k演算で特定条件下に完全に誤った結果が出力される、より深刻なバグが露呈した
• このバグは、それ以前の暫定修正によって問題が隠されていた
• また、近似top-k演算のバグは本番環境やバッチサイズによって症状が不規則に変化した
• 近似top-kの代わりに、最近では性能負荷が大幅に減ったexact top-kへ切り替えており、主要な演算をfp32標準化で改善している

検知遅延の原因

• 定期的な自動評価や事前グループデプロイなどの手順を運用していた
• 今回の事件では評価プロセスの抜け穴が明らかになった。たとえば、問題状況をうまく検知できない評価項目や、社内のプライバシー保護方針（エンジニアが具体的なユーザーリクエストにアクセスできない）によって迅速な分析が難しかった
• 症状がプラットフォームやバージョンごとに多様に現れたため、単一の原因を特定することが難しかった
• オンライン報告が急増した際も、標準的なロードバランシング変更との関連を即座に認識できなかった

今後の改善と対応策

• 感度の高い評価項目を開発し、破損状態と正常実装をより明確に判別できる自動評価を強化
• 実運用環境全体に評価とモニタリングシステムを拡大し、たとえばコンテキストウィンドウのルーティングエラーのような本番環境中心の評価を実施
• より迅速で精密なデバッグツールを新設し、コミュニティフィードバックをプライバシーを維持しつつ迅速に分析できるよう、インフラとカスタムツールを開発
• 内部評価だけでなく、ユーザーフィードバックの継続的収集の信頼性も強調。予測しにくいエラーやバグでは、実際のユーザー報告が重要なシグナルとなる
• "/bug"コマンドやthumbs down機能の活用、メールを通じたモデル品質評価方法の報告を積極的に奨励している

参考説明

• XLA:TPUはXLAの高水準最適化言語コードをTPU命令へ変換するコンパイラである
• モデルサイズが大きいため、1つのチップではなく複数のチップに分割配置され、sortingオペレーションなどはベクトル化された形で実装する必要がある
• 近似top-k演算は性能向上のために使われるが、確率が最も高いトークンを欠落させるなどの深刻な問題を内包しうる
• 現在は正確なtop-k方式を導入しており、top-pしきい値に近いトークンの含まれ方に微細な変化が生じる可能性がある。場合によってはユーザーがtop-p値を調整する必要があるかもしれない

[GN⁺]

Hacker Newsの意見

• 最近注目すべき点として、ユニットテストの欠如が見えてきた。XLAコンパイラのバグに対するテストも、単に出力をプリントする程度で、実際のテストハーネスで実行してカバレッジを追跡する本物のユニットテストとは程遠い。対処方針としては、Evalにもっと依存しろという話になっているようだ。現時点でLLM全体に対するユニットテストは非現実的だが、これまで明らかになったバグの多くはシステムの小さな決定的部分にあった。たとえばロードバランシング、top-k確率計算などは、どれも他のソフトウェアと変わらないエンジニアリングされた部分なので、原理的にはユニットテスト可能だ。必要なら注入可能なPRNGが1つあれば十分だろう。非決定的な最適化バグが厄介なのは確かだが、従来のアプリのテストスイートでも、過去にコンパイラやデータベースのバグを見つけた経験がある。CIで多数のテストを繰り返し実行すれば、まれなイベントも表面化しうる。個人的に進めているプロジェクトでは、すべてのユニットテストを同じプロセス内で並列実行しており、この方法でまれに起きるスレッドセーフティの問題やデータベースのデッドロックも効果的に見つけられた。数日前のJavaの立ち上げに関するスレッドでも、JavaがPythonより「エンタープライズ」っぽく見られる理由は、コードがユニットテスト重視で書かれるからだと述べたことがある。依存性注入などへの欲求により、抽象化も多く行われる。一方でスクリプト言語の文化では、テストがまったくないか、表面的にしか行われないことが多かった（例: 型だけをアサートする）。PyTorchを学んだときも似た印象があり、チュートリアルは段階的に複雑な内容まで扱うが、テストやコード構造への言及はほとんどない。これはMLリサーチでは評価スコアを上げることが目標だからで、大規模な本番投入には向かないアプローチだ。AI研究所にも、SREやHAソフトウェアエンジニア出身の人材がもっと必要なのではないかと考えている。個人的には、本番環境でEvalだけを積極的に回すやり方が、バグ防止の最善策なのかには懐疑的だ
  • AIにPythonで自分の望む形のユニットテストを書かせるには、詳細なプロンプトと例を与えなければならなかった経験がある。型に対するアサーションしか書かない例もよく見た。自分が欲しいのは値そのものに対するアサーションだ。AIは何でもモック化しすぎる傾向があるが、モックも有用とはいえ、ユニットテストで実際のコード全体を呼ぶほど、コード間の相互作用やインターフェース上のリスクまでカバーできる。ところがAIが生成したPythonのユニットテストは、モックに執着しすぎて、自己充足的な（tautological）コードだけを確認して終わることが多い。なので、モックを警戒するような注意と、丁寧なテスト例を積極的にプロンプトへ含めている。ちなみにPythonにも、依存性注入のような構造化されたコードを書くための優れたツールは多い
• 記事に、AnthropicがAWS Bedrockインフラへ直接影響を与えられるかのように書かれていたのは驚きだった。これはAWSの元々の約束とも食い違う。Google Vertex AIも同様だと思うが、まだコンプライアンス面では確認していない。

社内のプライバシーおよびセキュリティポリシー上、エンジニアがClaudeのユーザーとのやり取りにアクセスできるのは限定的だという点には共感する。 ユーザーが自分でフィードバックを送ることが依然として最も役立つという点と、Claude Codeで/bugコマンドを使えるという案内には同意する。そのコマンドで報告すれば、エンジニアが文脈を確認できるのだろうが、ユーザーの立場としては、この手順を非常に明確に告知してほしい（私はClaude Codeユーザーではない）。 Claudeアプリの"thumbs down"ボタンの案内はやや気になる。大半のユーザーは、このボタンを押すことがプライバシー放棄と同じ重みを持つとは考えないだろう

• （Anthropic社員、個人の立場で発言）

AWS BedrockインフラをAnthropicが直接管理しているという話は事実ではない。現在はAWSが直接運用している。 "thumbs down"ボタンのプライバシー案内については、そのモーダルに「このフィードバックを送信すると、現在の会話全体がAnthropicに送られ、モデル改善に利用されます」と明記している。もしこの案内文をもっとわかりやすく改善する方法があれば知りたい

• "thumbs down"をクリックすると、「このフィードバックを送信すると、会話全体がAnthropicに送られます」というメッセージが表示されるので、案内はかなり明確だと思う
• Anthropicほどの研究所がインフラの詳細を共有するくらいなら、状況はかなり厳しいのだろう。実際、FMA（積和演算）まわりの精度バグは相当に痛いし、数値問題はしばしば非常に混乱を招き、まだAIでは解けない領域だ。競合がリアルタイムで市場シェアを奪っていくような超高圧の状況では、結局は人間の介入が不可欠で、原因特定に数週間かかることもありうる
• 「8月29日のロードバランシング変更が、偶然1Mコンテキストサーバーにより多くの短コンテキスト要求を送ることになり、8月31日の1時間の間にSonnet 4リクエストの16%が影響を受けた」という説明があるが、これは1Mコンテキストサーバーのほうが短いコンテキスト入力でむしろ性能が落ちるようにも見える。おそらくこれらのサーバーでは、KVキャッシュ圧縮、エビクション、sparse attentionなど、別の対策が適用されている結果なのだろうか？
  • これはRoPE（回転位置埋め込み）のスケーリングが理由だ。有名なオープンソースフレームワークの大半はstatic YaRNを実装しているが、これは入力長に関係なくスケーリング係数が固定されるため、短いテキスト処理時の性能に影響しうる。長いコンテキストが必要なときだけrope_scaling設定を追加することを勧めるし、アプリケーションの平均入力長に合わせて係数も調整したほうがよい。たとえば52万トークン前後なら、factor 2.0に設定するほうがよい。 出典（Qwen3-Next-80B説明ページ）
  • 彼らのポストモーテム報告で重要なのは、3つの問題のうち2つは正確な原因が出ていないということだ。私の理解では、自分のリクエストは今この瞬間でも3つのまったく異なるコードパスのどこに送られてもおかしくなく、それぞれ別個のスタックとチューニングが施されている。この最適化はモデルのバージョンアップとは無関係に突然変わることもあり、昨日うまくいっていたものが今日壊れることもある。こうしたポストモーテムが称賛されているのを見ると、むしろ余計にフラストレーションがたまる
• Anthropicチームへの敬意はあるが、Claude statusページの品質は、社内的にはコードレッド級の警報が鳴るレベルだ。7月に50件、8月に40件、9月には21件のインシデントがあった。以前、これの半分の数字でも、全員がアップタイムと品質に集中するよう強く舵を切った経験がある。それでもClaudeはいまだに素晴らしい製品なので、有料契約を続けている。APIを使ってみて、すぐにMaxメンバーシップを契約した。そのおかげで生産性は急上昇した。だが、ここ数週間の品質低下の繰り返しのせいで、購読を続けるべきか悩み始めている。問題の現状を率直に共有してくれたことには感謝しているが、顧客としては不満が大きい。まだロードバランシング問題などは完全には検出も解決もされていないと思う。具体的には12時（東部）/9時（西部）ごろになると、Claude Codeの品質が体感でかなり落ちる。チームには引き続き問題を見つけて解決してほしい。自宅でローカルモデルを回していても複雑なバグに数多く遭遇した経験があるので、これらの問題が簡単ではないことは理解している。 statusページのリンク
  • 他社と比べてClaudeが優れているとも劣っているとも断言できないが、ひとつ確かなのは、多くの会社のstatusページには嘘が多いということだ。実際には頻繁に障害が起きているのに、statusページには載らないことが非常に多い。むしろ最近では、問題を正直に知らせてくれると驚く。個人的にはClaudeで深刻な問題を経験していないが、単に運が良かったのかもしれない。私の見方では、むしろClaudeのほうが障害報告をよりきちんとしているように見える。もちろん、これも単なる偶然かもしれないが
  • さらに懸念されるのは、status pageから小さな事故が大量に漏れていることだ。どのAIプロバイダーも似たようなものだ。リアルタイムのトークン待ち時間、失敗リクエスト、毎秒トークン処理速度のような統計グラフを公開したら、かなり衝撃的だと思う。OpenRouterのデータを見ると、APIのアップタイムが決して良くないことがわかる。Claude Codeもよく極端に遅くなり、手動で中断して再試行しなければならないことが多い。特に午後4～6時（英国時間）はひどく遅い（ヨーロッパ、米国東部、西部が全部重なる時間帯だ）。今日もGemini AI studioでモデル過負荷による503エラーが発生したが、status pageには何も表示されなかった。Claudeなどがオフピーク時間帯の安価な料金プランを導入すれば、需要を平準化できるのではないかと思う。ただ、そのようなプランは見た目にはネガティブに映るかもしれない。加えて、GB200 GPUの導入は想像以上に遅く、ハードウェア/ソフトウェアの欠陥も多数あったように見える。液冷の問題も軽くなかったようだ（失敗すると致命的だ）
  • 「それでもClaudeが良すぎるから課金する」という言葉自体が重要な示唆だ。現時点では、AIの品質がサービス信頼性よりも顧客（私を含む）にとって重要だということだ。もちろん各社も将来的には信頼性に注力するだろうが、なぜ今、品質より信頼性を優先すべきなのだろうか？
  • 最近の品質急落でかなり不安になっている。幸い、私はまだ本番サービスにAIを使っていないが、開発過程でモデルが突然「バカになる」状況は、本当に回避しづらい。現時点では、openrouterの複数ベンダーが信頼を裏切って、こっそりコンテキストを減らしたり、量子化の数値を下げたり、専門家数を減らしたりと、計算資源を密かに削るトリックを使っているのではないかと疑ってしまう
  • こういう理由で、statusページに記載するインシデント数を最小化する戦略が取られる。顧客評価は一時的に悪化するが、時間が経てばその悪影響は消える。しかしstatusページを継続的に運用すれば、問題の「証拠」が明確に残る。むしろ欺いたほうが長期的には有利だ。実際、S3は何度もエラーなどの障害があったが公開しなかったし、誰も問題視しなかった。人は色々言うが、実際の行動は隠した側に報酬を与える構造になっている。すべてのスタートアップのグロースハッカーは、すでにこの事実をよく知っている
• 8月25日にClaude APIのTPUサーバーで誤った設定がデプロイされ、トークン生成中にエラーが発生したと説明されている。コードバグなら馴染みがあるが、LLMは人間が直接書くのではなく、大規模な自動学習で生まれるのに、こうしたバグがどう発生するのか気になる。たとえばモデルが英語の質問に対して、真ん中あたりで突然「สวัสดี」（タイ語）を出してくる場合、人間の感覚では、構造上どうやってそんなバグが注入されうるのか知りたい
  • LLMは結局、人間が書いたコードによって動作している。最後の段階では、モデルが全トークン（語彙は約20万）に対する確率分布を生成する。その後、実際に次のトークンをどう選ぶかは人間が決める。たとえば常に最も確率の高いトークンを選ぶこともできるし、top-kからランダムに選んで創造性を高めることもできる。このtop-kサンプリングを効率よく処理するためにXLAでカーネルをコンパイルするが、このカーネルにバグがあって、たまにtop-k外のトークンが選ばれる問題があったようだ
  • LLMは次トークンの確率分布を吐き出し、実際の結果はサンプリング方式例によって変わる。たとえば「最も確率の高い4つからランダムに選ぶ」処理で、演算子（不等号）が間違っていれば、本文のような現象が起こる
  • ユーザーとモデルパラメータの間には、人間が書いたコードのレイヤーが何層もある
  • 簡単に言えば、トレーニングと推論の2段階がある。トレーニングは長時間の自動化処理だが、推論はユーザーのプロンプト入力が来ると即座に実行される別個のソフトウェアスタックだ。このスタックが継続的に性能改善のアップデートを受ける中で、このような推論関連の問題が生じる
  • AIカーネルは浮動小数点演算なので、通常の実数の範囲では負でない値が奇妙に負になることもある。性能のためにオーバーフローチェックなどを切っていて、負の値が出たらそれを非常に大きい数として扱うことがある（ちょうど配列の-1番目を要求すると最後の要素が返るようなものだ）
• LLM推論過程を決定論的（deterministic）にしようと考えることは、問題追跡に役立つかもしれないと思う。最近、「浮動小数点の結合順序のせいだという通説は、実はまったく核心的原因ではない」という論文も出ていた。 関連論文の紹介
  • ネットワークトラフィックやマシン負荷は本質的に非決定的だ。近いうちに完全な決定性（たとえば監査のため）を実現できるのは、コストに敏感でないバッチ処理くらいだろう。実際、Google検索もソーシャルメディアのおすすめ読み込みも、まったく決定的ではない。分散システムではgraceful degradation（部分的なサービス維持）が重要な指針だが、完全に決定論的なシステムではこうした対応が不可能になる
  • 決定論的な設計は性能に悪影響を与える。結局、もう1つモデルを作って、既存モデルの品質を監視・通知する「IQテスト」的アプローチが残ることになる
• 「Google Cloud Vertex AIでは8月27日～9月16日の間に誤ルーティングは0.0004%未満だった」という話には納得感がある。実際、業務でそのアカウントからCCを使っているが、質の低下を体感したことはない。全体として、こうしたバグは深刻ではあるものの、オンラインのレビューで語られているほどはるかに頻繁ではなかったと感じた。問題発生期間も、実際には1～2週間に大半が集中していた。全リクエストに対する影響割合も比較的小さい
  • ただし会社の記事自体にも「Claude Codeユーザーの30%が少なくとも一度は誤ったサーバーにルーティングされ、応答品質の低下を経験した」とある。ルーティングが「sticky」なので、一度誤ったサーバーに割り当てられると、その後も連続して同じサーバーへリクエストが送られる。Claude Code利用者の30%が品質低下を経験したなら、かなり大きなバグだ
  • 最近は、世界規模の障害が起きても企業が「一部の少数ユーザーでエラーが増加した」といった婉曲表現しか使わず、CTOの承認後にようやくstatusページを更新することが多いので、企業を簡単には信用できない。本当に率直なコミュニケーションをする企業があるなら、市場で強みになるだろう
• LLMサービスを決定論的に動作させれば、問題追跡に役立つという意見だ。最近、floating point演算の結合順序だけに帰していた原因について、実際にはもっと多様な決定性崩壊要因があるという論文も言及されている。 論文リンク
• ウェブアプリのデザインで、最近claudeがDOMにランダムなテキストを勝手に表示させる現象が深刻に起きているのを経験した。これはsvelteと組み合わせて使うと特に発生したように思われ、この問題が本文の現象群と関係しているかは確信がないが、以前はこんな深刻な品質低下を経験したことはなかった
• 実際の失敗ケースが何だったのか、投稿に含めてほしかった。Claude Codeでツール呼び出し後に完全に停止する現象を頻繁に経験したが、これが今回言及されたバグの1つだったのか気になる
  • 私もここ数日でまったく同じ問題をますます多く経験している。おそらく本文のバグとは別件（それでもなおバグだが）なのだろうと思うが、予想が外れていてほしい。「なぜ止まったのですか？ 続けてください」といった依頼を繰り返し送る頻度が目に見えて増えている