Claudeは8月から9月にかけて断続的に品質低下が発生していました。この問題に関して、2024年9月17日、Anthropicは自社ブログで詳細な技術レポートを公開しました。

多くのユーザーが体感していた応答の質の揺らぎの裏側で、何が起きていたのでしょうか。今回は、最先端のAIが経験した三重苦ともいえる障害の全貌を解説します。

3つのバグが同時発生。連鎖し、原因特定を困難にさせた障害の正体

Anthropicの報告によると、今回の品質低下は単一の原因によるものではなく、驚くべきことに3つの独立したインフラ関連のバグが、ほぼ同時期に発生したことによるものでした。それぞれが異なる症状を引き起こし、しかも互いに影響を及ぼし合うことで、原因の特定を著しく困難にしていたそうです。

前提として、Anthropicは「需要や時間帯、サーバー負荷によって意図的にモデルの品質を低下させることは決してない」と断言しました。ユーザーが報告した問題は、純粋にインフラのバグのみに起因するものです。

最初の問題は、コンテキストウィンドウのルーティングエラーでした。Claudeは、短いコンテキストと長いコンテキストを処理するために、それぞれ最適化された異なるサーバー群(サーバープール)を使用しています。

ところが、このリクエストを振り分けるロジックにバグが発生しました。長いコンテキストを持つリクエストが、誤って短いコンテキスト用のサーバーに送られてしまう事態が起きてしまったのです。

さらに問題を深刻化させたのが、「スティッキールーティング」と呼ばれる仕組みです。一度特定のサーバーに接続したユーザーは、その後のやり取りでも同じサーバーに接続し続けます。つまり、一度でも運悪く間違ったサーバーに割り当てられてしまうと、その後の会話全体で品質の低い応答を受け取り続けることになったのです。

この問題は9月4日に修正が展開され、AWS BedrockやGoogle CloudのVertex AIを含め、9月18日までに全プラットフォームでの展開が完了しました。

応答が文字化けする不具合と、TPUに潜んでいた根深いコンパイラ問題

2つ目のバグは、モデルの出力が破損するという、より直接的な問題でした。ユーザーからの報告によると、応答の途中で文字化けのような、あるいは予期せぬ文字が出力されるケースがあったそうです。

調査の結果、特定の条件下で発生する文字エンコーディングの問題であることが判明しました。非常に稀なケースではあったものの、ユーザー体験を大きく損なうこの問題に対し、Anthropicは迅速に対応しました。

9月2日には問題のある変更をロールバックし、さらに再発防止策として、予期せぬ文字出力を検知するテストをデプロイプロセスに組み込んだそうです。今後のアップデートで同様の問題が入り込むリスクを低減させるためです。

そして3つ目のバグが、今回の障害の中で最も複雑で、根が深いものでした。Googleが開発したAIアクセラレータであるTPU(Tensor Processing Unit)上で発生した、コンパイラの誤動作です。具体的には、「approximate top-k XLA:TPU miscompilation」と名付けられたこの問題は、モデルが次に出力する単語の候補を選ぶ「top-kサンプリング」という処理において、XLA(Accelerated Linear Algebra)コンパイラが誤ったコードを生成してしまうというものでした。

この結果、モデルは最適でない単語を選択してしまい、応答全体の論理一貫性や創造性が損なわれることになったのです。このバグは特に捉えどころがなく、再現性が低かったため、特定に長い時間を要しました。最終的に、9月4日にHaiku 3.5モデルで、9月12日にはOpus 3モデルで、それぞれ問題のあった変更のロールバックが行われています。

複数のバグが原因を覆い隠した。発見を遅らせた評価とプライバシーの壁

これほど深刻な3つの問題が、なぜすぐに対処されなかったのでしょうか。Anthropicはその理由についても、誠実に説明しました。最大の要因は、前述の通り、異なる原因を持つバグが同時に発生し、その症状が複雑に絡み合っていたことでした。

あるユーザーが報告した問題が、ルーティングエラーによるものなのか、それともTPUのバグによるものなのか、切り分けることが難しかったのです。

さらに、同社が実施していた従来の評価手法では、ユーザーが報告するような品質の低下を十分に検知できていなかったという事実も明かされました。モデルは単一の間違いからはうまく回復することが多いため、細かなニュアンスの損失や一貫性の欠如といった問題が、自動評価の網の目をすり抜けてしまっていたのです。

加えて、Anthropicが徹底している厳格なプライバシー保護の取り組みも、今回はデバッグの障壁となりました。同社の内部プライバシーおよびセキュリティ管理では、エンジニアがユーザーとClaudeとの対話にアクセスできる状況を厳しく制限しています。これはユーザーのプライバシーを守る上で極めて重要ですが、一方で、問題が発生している具体的なやり取りをエンジニアが直接確認できないため、バグの特定や再現を困難にするという側面も持っていました。これらの複合的な要因が重なり、問題解決までに時間を要することになったのです。

AIを選ぶ新たな基準。完璧さより、問題に向き合う誠実な姿勢が重要

今回の障害報告を受けて、Anthropicは再発防止に向けたいくつかの重要な変更を約束しています。まず、評価システムの強化です。問題の根本原因をより確実に特定できるよう、正常な実装と壊れた実装を明確に区別できる、より感度の高い評価方法を開発しました。モデルの品質を常に厳しく監視していく構えです。

また、デバッグツールの高速化にも取り組んでいます。再現性の低いバグであっても、より迅速に原因を特定し、修正できるような環境を整備することで、将来同様の問題が発生した際の影響を最小限に抑えることを目指します。

通常、企業にとって自社のインフラの技術的な問題をここまで詳細に公開することは稀です。しかし、Anthropicは今回の問題の規模と複雑さを鑑み、包括的な説明責任を果たすことが重要だと判断しました。この透明性の高い姿勢は、多くのユーザーや開発者から称賛を集めています。

AIという技術が社会に深く浸透していく中で、その作り手である企業には、ただ高性能なモデルを開発するだけでなく、その安定性や信頼性に対しても誠実であることが求められます。今回のAnthropicの事後検証は、AI開発の最前線で日々どのような課題と向き合っているのかを私たちに示してくれると同時に、失敗から学び、それをオープンに共有することの価値を教えてくれる、貴重な事例と言えます。

最先端の技術がいかに複雑で、予測不能な問題と隣り合わせであるか。そして、ひとたび問題が発生した際に、企業が取るべき姿勢とは何か。

私たちは、完璧なAIを求めるのではなく、問題が起きた時にいかに誠実に向き合えるか、という点を、これからのAIサービスを選ぶ上での一つの重要な指標とすべきなのかもしれません。Anthropicが見せたこの姿勢が、業界の新たなスタンダードとなることを期待したいですね。

この記事の監修