Anthropicが公開した8〜9月のClaude品質低下postmortem — 3バグと検出遅れの理由

2025年9月17日にAnthropicが公開した「A postmortem of three recent issues」は、2025年8月から9月初旬にかけてClaudeの応答品質を断続的に下げていた3つのインフラバグについての技術レポートです。早期報告が「通常のばらつき」と区別しづらく、修正までに時間がかかった経緯と、Anthropic側で何を変えるかが、ハードウェアレイヤーまで踏み込んで説明されています。

本記事は、このpostmortemをClaude / Claude Code / Claude APIの利用者目線で読み直し、「3つのバグが何だったのか」「なぜ検出が遅れたのか」「再発防止策として何が示されたのか」を1本にまとめます。8月から9月にかけて応答が変だったと感じた人にとって、それがどのバグの症状にあたるかを照らし合わせやすくする構成にしました。

冒頭で重要な一文も明確に置かれています。

We never reduce model quality due to demand, time of day, or server load. The problems our users reported were due to infrastructure bugs alone.

(訳意:需要・時間帯・サーバー負荷でモデル品質を下げることは決してない。利用者から報告された問題はインフラバグが単独の原因だった)

「ピーク時間帯に応答が雑になる」「ユーザー数が増えてから明らかにモデルが弱くなった」という観察論は今回のpostmortemで明確に否定されています。原因はあくまで3件の独立したインフラ不具合でした。

3バグの全体像

3つのバグの混入時期と修正時期、影響範囲は次の通りです。番号は本文と同じ順序で並べています。

3バグは混入時期が重なり、症状もプラットフォームによって異なって出たため、利用者側からは「何かおかしいが、原因が一つに見えない」状態が続きました。一部の報告は強い品質低下を訴える一方で、別の利用者は普段通り使えていたという矛盾した分布も、ルーティングのstickiness(後述)で説明されています。

バグ1:コンテキストウィンドウのルーティング誤り

最も影響範囲が広かったのがこのバグです。Claudeは内部的に、要求されるコンテキスト長に応じて異なるサーバープールへリクエストをルーティングしています。8月5日にデプロイされた変更で、一部のSonnet 4リクエストが、提供開始予定の1Mトークンコンテキスト向けサーバーへ誤って振られるようになりました。

初期影響は0.8%程度でしたが、8月29日の通常のロードバランシング変更で、短コンテキストのリクエストが1Mコンテキスト用サーバーへ流れる量が予期せず増加します。最悪時間帯となった8月31日にはSonnet 4リクエストの**16%**が影響を受けた、と本文に明記されています。

プラットフォーム別の影響規模は次の通りです。

注意点は、Anthropic側のルーティングが「sticky(粘着的)」だと説明されている点です。一度誤ったサーバーに振られたセッションは、続くやり取りも同じ誤サーバーで処理される傾向があります。つまり、影響を受けた利用者にとっては「ある時間帯のセッションがまるごと品質低下」という体感になります。

修正は9月4日にデプロイ。Claude APIとVertex AIへの展開は9月16日に、AWS Bedrockへの展開は9月18日に完了したと記載されています。

Claude Codeで「30%が経験」をどう読むか

Claude Code利用者の約30%が誤ルート応答を一度でも経験した、という数値は重い数字です。Claude Code側はリクエストを高頻度に投げるため、stickyルーティングの分布の中でこの割合に達したと考えられます。Claude Codeの実運用ガイドはClaude Code完全ガイド2026にまとめていますが、今回のように利用者側からは検出が難しい品質低下が起きうる構造であることは、運用の前提に置いておく価値があります。

バグ2:出力破損 — 英語の質問への返答に突然タイ語が混じる

2つ目はTPUサーバー側の設定ミスに由来するバグです。8月25日にデプロイされた構成変更により、ランタイムの性能最適化がトークン生成時に誤った高確率を与える挙動が混入しました。文脈上ほぼ出ないはずのトークンに高確率がつくため、症状は分かりやすく現れます。

本文の例示は次の通りです。

producing Thai or Chinese characters in response to English prompts, or producing obvious syntax errors in code. A small subset of users that asked a question in English might have seen "สวัสดี" in the middle of the response

(訳意:英語のプロンプトに対してタイ語や中国語が混ざって出力される、明らかな構文エラーがコードに混入する。英語で質問したのに応答の真ん中に「สวัสดี」が出る利用者もいた)

このバグの影響範囲は次のように整理されています。

修正は9月2日にロールバック完了。再発防止として「unexpected character outputs(想定外の文字出力)を検出するテストをデプロイプロセスに追加した」と明示されています。

英語のチャットの中に突然タイ文字が出る、コードに見覚えのない構文エラーが混入する、といった症状を9月初旬に経験した利用者は、このバグの直接の症状に当たっていた可能性があります。

バグ3:XLA:TPUコンパイラの潜在バグ — 8月の修正が9月の問題を呼んだ

3つ目はpostmortem本文でも最も技術的な掘り下げが行われている話で、12月の修正と8月の修正が連鎖して、XLA:TPUコンパイラに眠っていた潜在バグを露出させた構造になっています。利用者目線では「Haiku 3.5の応答品質が突然下がる」「Opus 3の挙動が変わる」という症状でしたが、技術的な経緯は段階を追って整理する価値があります。

サンプリングと混合精度の前提

Claudeは文章生成時、次トークンの確率分布を計算し、そこからランダムにサンプリングします。低確率トークンを避けるために「top-pサンプリング」を採用しており、累積確率が一定閾値(通常0.99または0.999)に達するトークンだけを候補にします。TPU上では、モデルが複数チップに分散配置されているため、確率のソート計算もチップ間で協調して行う「分散ソート」になります。

確率計算はbf16(16ビット浮動小数)で行いますが、TPUのベクトル処理ユニットはfp32ネイティブです。そのためXLAコンパイラは一部演算をfp32に変換して高速化します。この最適化は xla_allow_excess_precision フラグで制御され、既定値は true です。

2024年12月の発端 — 「温度0で最高確率トークンが落ちる」

2024年12月に、Anthropicは「temperatureが0のときに最高確率トークンがたまに消える」現象に気づきました。当時の対処はワークアラウンドのパッチでした。

原因は混合精度の不一致でした。本来同じ最高確率トークンを指すはずの演算が、片方ではbf16のまま、片方ではfp32にコンパイラが自動昇格して走り、両者で「どのトークンが最高確率か」の合意が取れず、最高確率トークンが選択候補から完全に消えるケースが発生していたわけです。

2025年8月26日の修正 — 根治のつもりが潜在バグを呼び覚ました

2025年8月26日、Anthropicはサンプリングコードの書き換えをデプロイします。精度問題を直接修正し、top-p閾値付近の確率処理を改善する内容でした。同時に、12月のワークアラウンドは「根本原因を解いたので不要」と判断して取り除きました。

ところが、この除去によって「近似top-k」演算に内在する別のバグが露出します。近似top-kは最高確率トークン群を高速に取り出す性能最適化で、12月のワークアラウンドがたまたまこの問題を覆い隠していました。本文の表現を借りると次の通りです。

This approximation sometimes returned completely wrong results, but only for certain batch sizes and model configurations. The December workaround had been inadvertently masking this problem.

(訳意:この近似は時として完全に誤った結果を返すが、これは特定のバッチサイズやモデル構成に限られていた。12月のワークアラウンドがこの問題を意図せず隠していた)

しかも症状は再現が困難で、同じプロンプトでも前後の演算や、デバッグツール有効化の有無で挙動が変わったと書かれています。

修正の流れと最終的な選択

確認された影響と対応の順序は次の通りです。

本文には「Model quality is non-negotiable, so we accepted the minor efficiency impact(モデル品質は譲れないので、わずかな効率低下を受け入れた)」と明記されています。近似演算で稼いでいた性能を放棄してでも厳密top-kに戻す判断をした、ということです。

注釈ではトレードオフにも触れられており、新しい厳密top-k実装はtop-p閾値付近のトークン採否で微妙な差が出るため、稀に利用者がtop-pを再調整したいと感じるケースがありうると説明されています。

なぜ検出が遅れたのか

利用者から見ると「8月中旬から9月初旬の品質低下」が体感として明確だったにもかかわらず、Anthropic側の最終修正は9月中旬に及びました。本文では検出遅延の原因として、以下が挙げられています。

評価指標が劣化を捕捉できなかった

通常の検証はベンチマークと安全評価、性能指標に依存しています。エンジニアによるスポットチェックと、小規模な「canaryグループ」への先行デプロイも実施されています。しかし、今回起きた劣化は評価で十分に捉えられなかったと明記されています。原因の一つは、Claudeが孤立したミスからは回復しやすい性質を持っており、評価ベンチマークでは「1問落としたか」だけ見ても全体の劣化に見えづらいことでした。

プライバシー保護とデバッグの両立

Anthropicの内部プライバシー / セキュリティ管理は、エンジニアが利用者の対話履歴へアクセスする条件を厳しく制限しています。特に、フィードバックとして報告されていない対話はエンジニアが直接参照できません。本文は次のように整理しています。

This protects user privacy but prevents engineers from examining the problematic interactions needed to identify or reproduce bugs.

(訳意:これは利用者のプライバシーを守るが、エンジニアがバグの特定や再現に必要な問題のある対話を調べることを妨げる)

報告された対話だけを足がかりに再現を試みる必要があるため、3つのバグが重なった今回のように症状が散らばっているケースでは特定難度が跳ね上がります。

プラットフォームごとに違う症状が出た

3バグはそれぞれ別のプラットフォーム、別のモデル、別の頻度で発症しました。利用者からの報告は「ランダムで一貫性のない劣化」に見え、単一原因を指していませんでした。8月29日に否定的な報告が急増した時点で、Anthropic側もそれを直前のロードバランシング変更とすぐには結び付けられなかった、と明記されています。

評価指標が「ノイジーな評価」に依存していたことが、根本の弱点として認められています。

公表された再発防止策

本文末尾で、再発防止のために変えることが3つの軸で示されています。要点だけを並べると次の通りです。

より高感度な評価

「workingな実装とbrokenな実装をより確実に区別できる評価」を新規に開発した、と明示されています。今後も評価精度を高めてモデル品質を継続的に監視する方針が示されました。

本番系での継続評価

通常の評価は定期実行ですが、今後は本番システム上で継続的に評価を回す方針です。今回のコンテキストウィンドウのロードバランシング誤りのように、本番でしか露出しない事象を捉える狙いと読めます。

デバッグツール強化とコミュニティフィードバックの活用

利用者プライバシーを犠牲にせずに、コミュニティ起源のフィードバックをデバッグできるツールを整備するとしています。今回の特注ツールを再利用することで、同様のインシデント発生時の修復時間を短縮する見通しも示されました。

加えて、利用者からの継続的なフィードバックの重要性が強調されています。Claude Codeでは /bug コマンド、Claudeアプリでは「thumbs down」ボタンで報告できるほか、評価データやモデル品質の検証手法は feedback@anthropic.com で受け付けるとされています。

2026年4月のpostmortemとの比較で見える方向性

Anthropicは2026年4月にも同種のpostmortemを公開しています。今回の2025年8〜9月分と並べて見ると、Anthropicの説明スタイルと変化させている観点が浮かび上がります。

両者に共通するのは「3つの独立した不具合が偶然重なった」「評価が劣化を十分に捕捉できなかった」「症状が一見ランダムに見えた」という構造です。Anthropicの説明姿勢として、技術的詳細をかなり深く開示する方向に寄っていることも、両postmortemに共通する特徴と読めます。詳細はClaude Code品質低下postmortem(2026-04-23)に整理しています。

評価の話題そのものを掘り下げた解説としては、エージェント評価の設計原理を扱ったAIエージェントのEval設計 — Anthropicが示す採点者3類型や、評価リソース設定によるスコア差を扱ったAnthropicが示したコーディング評価の落とし穴も合わせて読むと、今回のpostmortemで指摘されている「評価がノイジーで劣化を捉えきれなかった」問題がより立体的に見えてきます。

利用者として何を準備しておくか

postmortemから読み取れる利用者目線の準備ポイントは、次の3つに集約できます。

1. 体感の品質低下は仮説として /bug で送る

Anthropicは今後、本番系での継続評価とデバッグツール強化を進めるとしていますが、現状はプライバシー設計上、エンジニアが利用者の対話を自由に参照できない構造です。利用者からの具体的な報告がバグ特定の最短経路になります。Claude Codeでは /bug、Claudeアプリでは「thumbs down」を、症状を再現するプロンプトと合わせて送る運用が、自分の環境を守る側にも回ります。

2. プラットフォーム差を意識する

今回のバグ1ではClaude API / Bedrock / Vertex AIで影響規模が大きく違いました。バグ2 / バグ3はBedrock / Vertex AIには影響していません。「どこの経路でClaudeを使っているか」で症状の出方が変わるという事実は、今後の障害観察にも生きます。複数経路でClaudeを利用する組織では、症状が観測されたプラットフォームを明確にしてから報告すると、Anthropic側の特定速度も上がります。

3. 出力の異常パターンに対する自前のチェック

バグ2のように「英語の応答に突然タイ文字が混じる」「コードに見覚えのない構文エラーが入る」といった異常は、出力の単純なバリデーションで検出できます。プロダクション利用では、想定文字種からの逸脱や言語混在を簡易チェックする仕組みを置いておくと、今後同様のバグが再発した際の影響範囲を自前でも見られます。Anthropic自身も「unexpected character outputsの検出テストをデプロイプロセスに追加した」と書いており、同等のチェックを利用者側にも置く価値があります。

まとめ

postmortemから整理できる事実は次の通りです。

• 2025年8月から9月初旬のClaude品質低下は、3つの独立したインフラバグが偶然重なって発生した
• バグ1(コンテキストルーティング誤り)はClaude Code利用者の約30%に影響し、Anthropic直系APIで最大16%のSonnet 4リクエストに及んだ
• バグ2(TPU設定ミスによる出力破損)はOpus 4.1 / 4とSonnet 4に8月25日から最大9月2日まで影響、Bedrock / Vertex AIへの影響はない
• バグ3(XLA:TPUコンパイラの近似top-kバグ)はHaiku 3.5で確認、Opus 3 / Sonnet 4にも可能性ありとして予防的にロールバックし、近似top-kから厳密top-kへ切り替え
• 検出遅延の主因は、評価指標が劣化を捕捉できなかったこと、プライバシー設計上エンジニアが対話を直接参照できないこと、症状がプラットフォームごとに分かれて出たこと
• 再発防止は「より高感度な評価」「本番系での継続評価」「デバッグツール強化と利用者フィードバック活用」の3軸

Anthropicは冒頭で「需要 / 時間帯 / サーバー負荷でモデル品質を下げることはない」と明言しており、観察される品質変動はインフラバグに帰属させて説明する姿勢を強めています。利用者側としては、体感の品質低下を /bug などの公式チャネルで具体的に伝えることが、結果的に自分の利用環境の安定にもつながります。