Anthropic ポストモーテム：Claude のレスポンス品質に影響を与えたインフラストラクチャのバグ

2025年8月から9月初旬にかけて、3つの異なるインフラストラクチャのバグが、Claude のレスポンス品質を断続的に低下させました。Anthropic はこれらの問題を解決済みであり、需要、時間帯、またはサーバー負荷に基づいてモデルの品質が意図的に低下させられることは決してないことを確認しています。

重複する3つのインフラストラクチャの問題

Anthropic は、タイミングが重なり、診断を複雑にした3つの個別のバグを特定しました。8月29日には、負荷分散（ロードバランシング）の変更によって影響を受けるトラフィックの量が増加し、劣化がさらに悪化しました。

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

8月5日に導入されたルーティングのバグにより、一部の Sonnet 4 リクエストが、1M トークンのコンテキストウィンドウ用に構成されたサーバーに誤ってルーティングされる原因となりました。

  • 影響: 当初はリクエストの 0.8% に影響していましたが、8月31日の負荷分散の変更後、Sonnet 4 リクエストの 16% にピークが達しました。Claude Code ユーザーの約 30% が、この期間中に少なくとも1回の誤ルーティングされたメッセージを経験しました。Amazon Bedrock への影響はピーク時で 0.18% でしたが、Google Cloud の Vertex AI はリクエストの 0.0004% 未満の影響を受けました。
  • 継続性: 「スティッキー」なルーティングのため、1回リクエストが誤ルーティングされたユーザーは、その後のフォローアップメッセージも同じ誤ったサーバーにルーティングされる可能性が高くなりました。
  • 解決策: ルーティングのロジックは9月4日までに修正され、ファーストパーティ・プラットフォーム、Vertex AI (9月16日)、および AWS Bedrock (9月18日) 全体で展開が完了しました。

2. 出力の破損

8月25日に Claude API TPU サーバーにデプロイされた設定ミスにより、ランタイムのパフォーマンス最適化のためにトークン生成中にエラーが発生しました。

  • 影響: このバグは、本来めったに生成されないはずのトークンに高い確率を割り当て、その結果、予期せぬ文字（例：英語のプロンプトに対してタイ語や中国語の文字）や、コード内の構文エラーを引き起こしました。これは、8月25日から9月初旬にかけて、Claude API 上の Opus 4.1、Opus 4、および Sonnet 4 のリクエストに影響を与えました。サードパーティ・プラットフォームは影響を受けませんでした。
  • 解決策: 9月2日に変更がロールバックされ、予期せぬ文字出力に対する検出テストがデプロイメント・プロセスに追加されました。

3. Approximate top-k XLA:TPU の誤コンパイル

トークン選択を改善することを目的とした8月25日のコード・デプロイメントにより、XLA:TPU コンパイラ内の潜在的なバグが誘発されました。

  • 影響: このバグは、Claude Haiku 3.5 および、Claude API 上の Sonnet 4 と Opus 3 の一部のサブセットに影響を与えました。サードパーティ・プラットフォームは影響を受けませんでした。
  • 解決策: Haiku 3.5 は9月4日に、Opus 3 は9月12日にロールバックされました。Sonnet 4 も予防措置としてロールバックされました。

技術的な詳細解説：XLA コンパイラ・バグ

XLA コンパイラ・バグは、「approximate top-k」操作—テキスト生成中に最も確率の高いトークンを見つけるために使用されるパフォーマンス最適化手法—における失敗に関わるものでした。

精度（Precision）の不一致とトークンの脱落

Claude のモデルは bf16 (16ビット浮動小数点) で確率を計算しますが、TPU ベクター・プロセッサは fp32 ネイティブです。XLA コンパイラは、xla_allow_excess_precision フラグを介していくつかの操作を fp32 (32ビット) に変換することで、ランタイムを最適化します。これにより、精度の不一致が生じ、異なる操作間で最も確率の高いトークンについて合意が得られず、temperature が 0 の場合に、最も確率の高いトークンが完全に脱落してしまうことがありました。

Approximate Top-k の失敗

2025年8月、サンプリング・コードの書き換えにより、根本的なコンパイラ・バグを隠蔽していた2024年12月の回避策（workaround）が削除されました。これにより、approximate top-k 操作が露呈しました。この操作は、特定のバッチ・サイズやモデル構成において、完全に誤った結果を返していました。

最終的な解決策

Anthropic は、approximate top-k から exact top-k へ移行し、追加の操作を fp32 精度に標準化しました。モデルの品質を確保するため、同社はわずかな効率性の低下を受け入れました。

検知知見と修復における課題

いくつかの要因が、これらのバグの検知を遅らせる原因となりました。

  • 評価（Evaluation）のギャップ: 標準的なベンチマークや安全性評価では、劣化が捉えられませんでした。これは、Claude が孤立したミスから回復することが多いためです。
  • プライバシーの制約: 内部セキュリティ・コントロールにより、エンジニアがユーザーとの対話内容にアクセスすることは制限されており、実際の問題のある対話を用いてバグを再現することが困難でした。
  • ノイズの多いシグナル: バグが重複しており、かつプラットフォームごとに影響が異なるため、報告が混乱を招く混合物となり、ランダムな劣化のように見えました。
  • 評価への過度な依存: 8月29日のネガティブな報告の急増は、直ちにルーティングの負荷分散変更に関連付けられませんでした。

将来の予防策

Anthropic は、同様のインフラストラクチャの障害を防ぐために、以下の変更を実施しています。

  • より感度の高い評価: 正常に動作している実装と、壊れている実装を区別できる、より信頼性の高い新しい評価手法の開発。

  • 継続的なプロダクション・モニタリング: コンテキストウィンドウのルーティング・バグのようなエラーを捕捉するため、稼働中のプロダクション・システム上で品質評価を継続的に実行すること。

  • 強化されたデバッグ・ツール: ユーザーのプライバシーを損なうことなく、コミュニート・ソースのフィードバックをより効率的にデバッグするためのインフラストラクチャの構築。

Sources

関連