ハクソク

世界を動かす技術を、日本語で。

最近の三つの問題の検証

234日前原文(anthropic.com)

概要

  • 2024年8月から9月初旬にかけて、Claudeの応答品質がインフラバグにより断続的に低下
  • 三つの異なるインフラバグを特定し、すべて修正完了
  • バグの発生原因、検知・解決の遅れ、今後の対策を詳細に説明
  • Claudeの品質は需要やサーバ負荷ではなく、バグのみが原因で低下
  • ユーザーからの継続的なフィードバックの重要性を強調

Claudeの応答品質低下と原因

  • 8月初旬より一部ユーザーからClaudeの応答品質低下の報告
  • 通常のフィードバック変動と区別が難しく、8月下旬に調査を開始
  • 調査の結果、 三つの独立したインフラバグ を特定
  • Claudeの品質は 需要やサーバ負荷 により意図的に下げることは一切なし
  • 一連のインシデントについて、 ユーザーへの説明責任 を重視

Claudeの大規模提供体制

  • Claudeは 自社API、Amazon Bedrock、Google Cloud Vertex AI を通じて数百万人に提供
  • AWS Trainium、NVIDIA GPU、Google TPU など複数ハードウェアで運用
  • プラットフォームごとに最適化が必要だが、 品質の均一性 を厳格に維持
  • インフラ変更時には 全環境での慎重な検証 が必須

インシデント発生のタイムライン

  • 8月5日：Sonnet 4リクエストの0.8%に影響する最初のバグ発生
  • 8月25-26日：追加の二つのバグが新たに発生
  • 8月29日： ロードバランシング変更 により影響範囲が拡大
  • 問題が重なり、 診断を困難 にする要因に

三つの重複するインフラバグ

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

    • Sonnet 4の一部リクエストが誤ったサーバ（1Mトークン対応）にルーティング
    • 8月31日には最大16%のSonnet 4リクエストが影響
    • "スティッキー"なルーティングで影響が継続
    • 9月4日に修正、順次各プラットフォームへ展開中

  • 2. 出力の破損

    • 8月25日、TPUサーバへのミスコンフィグによりトークン生成時に誤った確率割当
    • 英語プロンプトにタイ語や中国語の文字が混入、コードに構文エラー
    • Opus 4.1, Opus 4, Sonnet 4が対象、サードパーティは無影響
    • 9月2日にロールバック、異常文字検出テストを導入

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

    • 8月25日、トークン選択改善コードの展開でXLA:TPUコンパイラの潜在バグが顕在化
    • Haiku 3.5, 一部Sonnet 4, Opus 3に影響、サードパーティは無影響
    • 9月4日と12日に順次ロールバック、XLA:TPUチームとバグ修正を進行中

XLAコンパイラバグの詳細

  • Claudeのトークン生成時、 確率計算とサンプリング で複雑な分散処理
  • 2024年12月、TPU実装で最頻トークンが消失するバグを発見しワークアラウンドを実装
  • bf16（16bit）とfp32（32bit）の混在計算 による精度不一致が原因
  • 8月26日、サンプリングコードの書き換えで根本原因に対応したが、別のバグが露呈
  • Approximate top-kの最適化が特定条件下で誤った結果を返す問題
  • Exact top-k への切り替えと fp32標準化 で品質優先の対応

検知が困難だった理由

  • 通常はベンチマーク・安全評価・パフォーマンス指標で検証
  • Claudeは 単発ミスからの回復力が高く、劣化を検出しにくい
  • プライバシー保護 のため、エンジニアがユーザーのやりとりを直接確認できない
  • バグごとに症状や発生率が異なり、レポートが分散
  • 評価指標のノイズ に依存しすぎ、ユーザー報告との紐づけが遅延

今後の対策

  • より高感度な評価指標 の開発・導入
  • 本番環境での継続的な品質評価 の実施
  • デバッグツールの強化 とユーザープライバシー両立
  • ユーザーからの 具体的なフィードバック の重要性を再認識
  • 例外的な挙動や変化の報告が、問題特定に非常に有用

ユーザーへのお願い

  • Claudeの応答品質に異常や変化を感じた場合、 具体的な例や状況を含めてフィードバック 送信を推奨
  • 継続的なユーザー協力が、 品質維持と迅速なバグ修正 に不可欠

Hackerたちの意見

8月27日から9月16日の間に、誤ったルーティングがGoogle CloudのVertex AIのリクエストの0.0004%未満に影響を与えました。私の経験とも一致します。企業のVertex AIアカウントを通じてCCを使っているけど、劣化には気づかなかったです。一般的に、これらのバグは深刻ではあるものの、オンラインでの噂ほどには広がっていなかったように感じます。実際、ここで話しているのは、ほとんどの問題が集中していた約1〜2週間のウィンドウで、全体のリクエストやユーザーに対しては比較的小さな割合です。

└

これが「オンラインの噂よりも少ない」とは言えないと思います。彼らの記事から: > 「約30%のClaude Codeユーザーが、少なくとも1つのメッセージが間違ったサーバータイプにルーティングされ、応答が劣化しました。」 > 「しかし、一部のユーザーはより深刻な影響を受けました。なぜなら、私たちのルーティングは「スティッキー」だからです。」 つまり、一度間違ったサーバーからリクエストが処理されると、その後のフォローアップも同じ間違ったサーバーから処理される可能性が高いということです。30%のClaude Codeユーザーが劣化した応答を受けるのは大きなバグです。

└

もう企業は信じられない。世界的な障害が起きるたびに、「少数のユーザーに対してエラーが増加しているのを観察しています」みたいなソフトスピークを使うし、CTOがステータスページの変更を承認した数時間後には、正直に顧客に接する企業には大きな市場の隙間があると思う。

8月25日に、トークン生成中にエラーを引き起こす設定ミスをClaude APIのTPUサーバーにデプロイしました。ランタイムパフォーマンスの最適化によって引き起こされた問題が、文脈に対してほとんど生成されるべきでないトークンに高い確率を割り当てることがありました。例えば、英語のプロンプトに対してタイ語や中国語の文字を生成したり、コード内で明らかな構文エラーを生成したりすることです。英語で質問した少数のユーザーは、例えば応答の中に「สวัสดี」が見えたかもしれません。こういうことがLLMでどうして可能なのか、素人に説明できる人いますか？普通のコードでは、もちろんバグはよく起こります。条件文でオフバイワンエラーをうっかり入れたり、余分なgoto failを追加したりすることもあります。でも、LLMは人間が書いたものじゃないですよね！モデルは、自動プログラムによって数ヶ月にわたり、計り知れないほど巨大なデータセンターで訓練されます。人間がTFAで説明されたようなバグをどうやって引き起こすのでしょうか？

└

あなたと重みの間には、多くの人間が書いたコードの層があります。

└

LLMは、次のトークンが何であるかの確率分布を生成します。実際に次に印刷される単語をその確率分布から選ぶのは、サンプリングアプローチを使います[1]。もしあなたのサンプリングアプローチが「上位4つの可能性から次の単語をランダムに選ぶ」だとしたら、> 記号をひっくり返すと、OPで説明されたような動作になる可能性があります。[1] こちらが2つの一般的なアプローチの例です: https://www.reddit.com/r/AIDungeon/comments/1eppgyq/can_some...

└

LLMは、次のトークンが何であるかの確率分布を生成します。その確率分布から実際に次に印刷される単語を選ぶのは、サンプリングアプローチを使います[1]。もしあなたのサンプリングアプローチが「上位4つの可能性から次の単語をランダムに選ぶ」だとしたら、> 記号をひっくり返すと、OPで説明されたような動作になる可能性があります。[1] こちらが2つの一般的なアプローチの例です: https://www.reddit.com/r/AIDungeon/comments/1eppgyq/can_some...

└

AIのカーネルは浮動小数点だから、実際の数値ではあり得ないようなマイナスの計算ができちゃうんだよね。パフォーマンスの理由でオーバーフロー状態のチェックが無効になってる可能性もあるし、マイナスの値がすごく大きくなっちゃうこともある。例えば、配列の-1番目のアイテムを要求したら、最後のアイテムが返ってくるみたいな感じ。

└

簡単に言うと、ここにはトレーニングと推論という二つのプロセスがあるんだ。トレーニングは始まると、ほぼ放置で長期間行われるけど、推論は別のプロセスで、トレーニングされたモデルを使って応答を生成する、実行時のプロセスなんだ。プロンプトを送って、推論が実行されて、応答が返ってくる。これは全く別のソフトウェアスタックで、パフォーマンスを改善するために常に更新されてる。これらの問題は推論プロセスで発生したんだよ。

8月29日に、ルーチンの負荷分散の変更が意図せず、1Mコンテキストサーバーにルーティングされる短いコンテキストリクエストの数を増加させました。8月31日の最も影響を受けた時間帯では、Sonnet 4のリクエストの16%が影響を受けました。興味深いことに、これは1Mコンテキストサーバーが低コンテキストで最もパフォーマンスが悪いことを示唆しています。もしかしたら、これが1Mコンテキストサーバーに適用されているKVキャッシュの圧縮や排除、またはスパースアテンションスキームによるものかもしれませんね。

└

これはRoPEスケーリングによるものです。> すべての注目すべきオープンソースフレームワークは静的YaRNを実装していて、つまりスケーリングファクターは入力の長さに関係なく一定で、短いテキストのパフォーマンスに影響を与える可能性があります。長いコンテキストを処理する必要がある場合のみ、rope_scaling設定を追加することをお勧めします。また、必要に応じてファクターを変更することも推奨されます。例えば、アプリケーションの典型的なコンテキスト長が524,288トークンであれば、ファクターを2.0に設定するのが良いでしょう。 https://huggingface.co/Qwen/Qwen3-Next-80B-A3B-Thinking

この記事が示唆しているように、AnthropicがAWS Bedrockのインフラに直接影響を与えることができるとはちょっと驚きです。それはAWSの約束に反しますよね。Google Vertexでも同じことが言えると思いますが、コンプライアンスの観点からはまだ詳しく調べていません。> 私たちのプライバシー慣行も、報告の調査において課題を生み出しました。私たちの内部のプライバシーとセキュリティの管理は、特にフィードバックとして報告されていないユーザーとのやり取りに対して、エンジニアがどのように、いつアクセスできるかを制限しています。なるほど、理解しました。嬉しいです。> ユーザーが直接フィードバックを送ることは特に役立ちます。Claude Codeで/bugコマンドを使ってください。なるほど、理解しました。その場合、人間がコンテキストを確認できると思いますが、エンドユーザーにはまだ非常に明確であることを願っています（私はClaude Codeのユーザーではないのでコメントできません）。> また、Claudeアプリの「サムズダウン」ボタンを使ってもできます。これはかなり心配です。普通の人がこのボタンを押すことがプライバシーを放棄することと同じだとは思えません。

└

これはかなり心配です。普通の人がこのボタンを押すことがプライバシーを放棄することと同じだとは思えません。「サムズダウン」をクリックすると、「この報告を送信すると、現在の会話全体がAnthropicに送信され、私たちのモデルの将来の改善に役立ちます。」というメッセージが表示されます。報告を送信する前に、私はそれがかなり明確だと思います。

└

（Anthropicの社員、個人的な立場で発言）> この記事が示唆しているように、AnthropicがAWS Bedrockのインフラに直接影響を与えることができるとはちょっと驚きです。私たちは現在、AWS Bedrockのデプロイを直接管理していません。それはAWSが管理しています。> 普通の人がこのボタンを押すことがプライバシーを放棄することと同じだとは思えません。私たちは「この報告を送信すると、現在の会話全体がAnthropicに送信され、私たちのモデルの将来の改善に役立ちます。」とサムズダウンのモーダルに明記しています。このコピーを改善する簡単な方法はありますか？

Anthropicチームには敬意を表しますが、Claudeのステータスページ[1]は品質のために内部でコードレッドを出すべきだと思います。7月には50件、8月には40件、9月にはこれまでに21件のインシデントがありました。私は以前、これらの数字の半分に近づくと、常に稼働時間と品質に焦点を当てるための大きな転換がありました。それにもかかわらず、私はまだ顧客として支払いを続けています。Claudeは素晴らしい製品で、私は多くの価値を得ています。APIを試した後、20倍のMaxメンバーシップを購入するのは当然のことになりました。Claudeで達成したことは素晴らしいです。ここ数週間は、私のサブスクリプションについて強く疑問を持つようになりました。この投稿のオープンさには感謝しますが、顧客としては不満です。これらの問題がすべて発見されて解決されているとは信じられません、特に負荷分散の問題については。少なくとも私の経験では、ETの12時頃（太平洋時間の午前9時）に、私のClaude Codeセッションの質が明らかに低下することに気づきます。チームがこれらの問題を見つけて修正し続けられることを願っています。自宅のマシンでローカルモデルを実行していても、複雑なバグに常に直面しています — これが簡単な問題だとは思いません、見つけて修正するのは難しいです。[1] https://status.anthropic.com/history

└

これらの突然の品質低下について非常に不安を感じています。幸いにも、私はまだAIを使った製品を持っていませんが、自分の開発経験から言うと、モデルが突然劇的にバカになるのは非常に対処が難しいです。この時点で、オープンルーターの異なるベンダーが信頼を悪用して、コンテキストを無視したり、量子化レベルを変更したり、専門家を減らしたりしているのではないかと驚いています。

└

彼らが他の会社より良いか悪いかはわかりません。確実に言えるのは、多くの会社がステータスページで嘘をついていることです。私は頻繁に、ステータスページで報告されていない障害に遭遇します。最近では、彼らが自ら問題を報告することに驚くことが多いです。個人的には、これまでClaudeで深刻な問題には遭遇していませんが、単に運が良かっただけかもしれません。私の視点では、彼らは障害をより誠実に報告しているように思えますが、それは完全に偶然かもしれません。

└

それにもかかわらず、私はまだ顧客として支払いを続けています。Claudeは素晴らしい製品で、私は多くの価値を得ています。それが全てを物語っているのでは？今のところ、AIの品質が顧客（あなたや私）にとって信頼性を上回っています。もちろん、彼らはそれに焦点を当てるべきですが（そして私はそうなると確信しています）、なぜ今、モデルの品質よりも信頼性を優先するのでしょうか？

└

さらに悪いのは、ステータスページが小さなインシデントをすべてカバーしてないこと。これは全てのプロバイダーに共通してる。もしリアルタイムでトークンのレイテンシーや失敗したリクエスト、トークン数とかのグラフを提供してたら、かなりひどいことになると思う。このOpenRouterのデータを信じるなら、これらのAPIの稼働率は…あまり良くないよね: https://openrouter.ai/openai/gpt-5/uptime どのプロバイダーも大規模な課題を抱えてるのは明らかだよ。Claude Codeはしばしば遅くなって、途中で止めて再試行させる必要がある。特にイギリス時間の午後4時から6時頃（ヨーロッパ、東海岸、アメリカ西海岸が一斉に使う時間）に顕著だね。今日もGemini AIスタジオから503エラーが出て、モデルがオーバーロードしてたけど、ステータスページには何もなかった。Claudeたちが需要を平準化するために、安いオフピークプランを提供する価値があるかもしれないけど、見た目が良くないかもしれないね。追記すると、GB200sが業界の予想よりもずっと遅れて登場してるのも一因だと思う。ハードウェアやソフトウェアのコンポーネントに多くの欠陥があって、液体冷却がうまくいってないんじゃないかな（もっとひどい故障状態があるし！）。

└

だから、ステータスページにはできるだけ少ないインシデントを載せるべきなんだ。人々の意見は下がって、ネガティブな影響は時間とともに薄れていく。でも、ステータスページがあると、それは否定できない証拠になる。嘘をついた方がいいよ。みんな忘れるから。例えば、S3は何度もエラー率が増加したけど、報告しない。誰もS3について何も言わない。人々はいろいろ言うけど、彼らの行動は嘘を報いることなんだ。成長ハックを狙うスタートアップの人たちは、これをみんな知ってるよ。

もしAnthropicがインフラの詳細を共有するなんて、彼らは本当に大変な状況なんだろうね。実際の精度のバグについては、FMA側にとってかなり残念なことだよ。数値の問題はしばしば非常に混乱を招くもので、今のところどのAIも解決できない。競争相手が毎日あなたのランチを食べてるような超厳しい状況では、何が間違ったのかを理解するために人間が必要で、それでも修正には数週間かかることもあるんだ。

これで一番興味深いのは、ユニットテストが明らかに欠けていることだね。XLAコンパイラのバグのテストは出力を表示するだけで、テストハーネスで実行されてカバレッジが追跡されるユニットテストというよりは再現ケースに近い。アクションアイテムは、より積極的に評価に取り組むことだけ。今のところ、全体のLLMをユニットテストするのは現実的ではないけど、これらのバグはシステムの小さな決定論的な部分にあったんだ。負荷分散やtop-k確率計算など、他のソフトウェアと同じように設計された部分で、原則的にはすべてユニットテスト可能なはず。せいぜい、注入可能なPRNGが必要だよ。そう、非決定論的な最適化バグはひどいけど、過去に普通のアプリテストスイートを使ってコンパイラやデータベースのバグを見つけたことがある。CIを使うと多くの実行ができるから、まれなイベントもフレークを調査すれば表面化することがある。今やってるプロジェクトの一つは、同じプロセスで全てのユニットテストを並行して実行していて、これはまれなスレッドセーフの問題やデータベースのデッドロックを解消するための優れた安価な戦略だと証明されてる。数日前、Javaのローンチについてのスレッドで、JavaはPythonに比べて「エンタープライズっぽい」と感じることが多いってコメントしたんだけど、これはJavaのコードが通常、ユニットテストしやすく書かれているからだよね。多くの抽象化は依存性注入の欲求から生まれてる。これをスクリプト言語の文化と対比すると、テストが欠けていたり、表面的なレベルにとどまっていることが多いと感じる。数年前にPyTorchを学んでいたときも同じことに気づいた。チュートリアルは簡単なものから複雑なものへ進むけど、テストやコードの最適な構造についてあまり話さない。これは明確な目標がないML研究には理にかなってるけど、大規模なプロダクション展開には合わないよね。AIラボには、こういうことに焦点を当てるためにSREやHA SWEのバックグラウンドを持つ人がもっと必要なんじゃないかな。もっと積極的なローリング評価がバグを避ける最善の方法だとはちょっと懐疑的だな。

└

Pythonで欲しいようなユニットテストを生成するために、詳細なプロンプトや例をいくつか書かなきゃいけなかった。型に対するアサーションだけも見たことがある。値に対するアサーションやもっと多くのものが欲しいんだ。それ以上に、AIはすべてをモックする傾向がある。モックは便利だけど、ユニットテストが呼び出す実際のコードが多いほど良い。なぜなら、リスクはコードそのものだけでなく、その相互作用やインターフェースにもあるから。だけど、PythonのAIはモックが多すぎて、コード自体すらほとんどテストしない、同義反復のような文になってしまう。モックを避けるように強く警告して、徹底したテストの例を示すようにプロンプトを出したこともある。ちなみに、Pythonには注入のための優れたツールがあって、非常にきれいに構造化されたコードを書くことができるよ。

実際の失敗モードが何だったのかを含めてほしかったな。Claude Codeがツールコールを実行した後にハングする問題があったんだけど、これもこれらのバグのせいだったのかな？

これが関係あるかは分からないけど、最近ウェブアプリのデザインで大きな問題を見つけたんだ。クラウドがDOMにランダムなテキストのストリームを作っちゃうんだよね。Svelteを使おうとした時に特に関係してる気がするけど、これまで気づかなかった大きな劣化だよ。

その通りだね！