浮動小数点の数字の壁を見つめていると脳が溶けるように感じたことはありませんか？そんな感覚が、元Solidityリードで現在CantinaのCEOであるHari Krishnaswamyの最近のX投稿から伝わってきます。彼は行列アルゴリズムのデバッグ地獄について語っており、そのスレッドはAnthropicの発表（Claudeで3つの重複したバグを修正したというもの）を引用し、彼らの詳細なポストモーテム報告からのこの珠玉の画像を投下しています。特に厄介だった問題の深掘りで、TPU実装のバグが原因でClaudeのAIが時々自分の最有力トークンを見落としてしまうという話です。

数値的なバグと格闘したことがある人には、Hariの見解は刺さります。「行列アルゴリズムのデバッグはひどい」と彼は書いています。「浮動小数点の数の羅列を眺めて、壁に頭をぶつけるんだ」。まさにその通り。彼はかつて行列ルーチンのために拡張精度のソルバーを作り、それが浮動小数点誤差を追跡する際の命綱になったと語ります—微小な不正確さが蓄積して大きな失敗に発展する、あの厄介なやつです。AIのトークン生成のような高リスクな計算では、小さな小数点のずれが全てを狂わせることを改めて思い知らされます。

ではバグそのものに寄りましょう。これはAIエンジニアリングが魔術と錬金術を兼ねる理由を示す教科書的事例です。2024年12月、AnthropicのチームはTensor Processing Unit（TPU：AI演算を高速にこなすGoogleのハードウェア）環境で、temperature（出力のランダム性を制御するノブ）がゼロに設定されているときに、最も確率の高いトークンを時折落とす挙動を見つけました。彼らはとりあえず素早い回避策を当てて稼働を続けました。

あの画像？それが決定的証拠です。コードのハックは、確率比較が狂う端ケースを回避するために、各行のトップロジット（確率に変換する前の生のスコア）を手動で保持するものです。しかし時間が進んで2025年8月、あるコード変更が誤ってXLAコンパイラ（TPU向けのコード最適化を行うツール）に潜むより深い問題を露呈させました。

根本原因を簡単に説明します：Claudeは次トークンの確率をbf16（メモリ節約と速度重視の16ビット浮動小数点形式）で計算します。一方TPUは本来fp32（より高い精度の32ビット）をネイティブに使います。コンパイラは機会を見つけて、xla_allow_excess_precisionというフラグ（デフォルトはtrue）を通じて一部の演算を自動的にfp32にアップグレードしました。賢そうに聞こえますよね？ところがこれが誤りでした。こうして「top-kを見つける」数学の一部が異なる精度で動くことになり、どのトークンが“ボス”かで意見が食い違ってしまったのです。結果――最も確率の高い選択が争点から消えました。

この問題は2025年8月25日以降、Claude Haiku 3.5に深刻な影響を与え、Sonnet 4やOpus 3にも波及しました。ユーザーは文字化けや英語テキストへの奇妙な文字混入、コードの構文のずれといった生成不良を目撃しました。AnthropicはHaikuの変更を9月4日にロールバックし、Opusは9月12日にロールバック、Sonnetについても事前に対処しました。現在、彼らはXLAチームと協力してコンパイラの正式な修正を進めつつ、精度を上げたexact top-kを一時策として導入しています（速度はわずかに落ちますが、まずは精度優先です）。

これは単なるAIのやらかしに留まりません—ブロックチェーン開発者への警鐘でもあります。考えてみてください：ミームトークンのスマートコントラクトやDeFiのアルゴリズムは、価格決定やイールドファーミング、あるいは生成型NFTアートのために確率モデルや行列演算に依存することがよくあります。浮動小数点のミスは資金の損失や不正なトークンドロップを意味するかもしれません。Hariの拡張精度トリック？SolidityやRustでの監査におけるエッジケース探しには宝のような技です。

Anthropicの透明性は見事でした。彼らは重複するバグ（ルーティングの不具合や出力の破損も含む）を認め、XLAチームに再現手順を共有し、テストを強化しました。暗号の前線にいる私たちにとっては、精度チェックと多様なハードウェアシミュレーションを強化する合図です。次にモデルの挙動が怪しいときは、精度を上げて何が出るか確かめてみてください。

どう思いますか？dAppで浮動小数点の幽霊バグをデバッグしたことはありますか？あなたの武勇伝を下に書いてください。