Anthropic Console 課金バグ: ロケールの小数点処理により 5.04 と入力したら 504 ドル請求される
Anthropic Console を利用している開発者が、クレジット購入金額フィールドに 5.04 と入力したところ、暗黙のうちに 504 として解釈され、クレジットカードに 504.00 米ドルが請求されたと報告しました。これは意図した金額の約 100 倍であり、取引実行前に確認画面は表示されませんでした。Hacker News のアイテム 50121562 に投稿されたこの報告は、ロケール依存の入力解析エラーと、返金を拒否した自動サポートプロセスが組み合わさった事例を説明しています。
核心となる主張は、カンマを小数点として使用するロケールのユーザーが入力した小数点区切り文字が、拒否または正規化されるのではなく削除され、その結果の金額が即座に決済ゲートウェイに送信されたというものです。
報告者が何が起こったと述べているか
投稿者は、コスタリカで開発チームを率いる法務技術弁護士であると自己紹介しています。投稿によると、彼は Anthropic API アカウントにクレジットを追加しようとし、支払い金額の入力を求められました。スペイン語圏で働いており、現地のシステムでは小数点としてカンマが一般的に使用されるため、彼は 5.04 と入力しました。
投稿によると、システムはフォーマットエラーを発生させず、値も変換しませんでした。代わりに内部で小数点を削除し、504.00 米ドルを請求しました。投稿者は、処理前に最終金額を要約する確認モーダルやレビュー画面はなかったと述べています。
報告者によるバグの再現
同じスレッドのフォローアップコメントで、元の投稿者はコンソール内で入力検証エラーを再現したと述べました。彼のメカニズムの説明は次のとおりです。
「地域設定で小数点にカンマを使用している場合（例: 残高が 430,26 と表示される）、入力フィールドは物理的にドット（0.5 や 5.04）の入力を許可します。壊滅的な UX 障害は、入力直後に Enter キーを押したときに発生します。フォームは、フロントエンドの検証レイヤーがブロックしたり正しく警告したりする前に、未検証の生の入力文字列を即座にバックエンドに送信します。」
さらに彼は、この動作がプラットフォーム自身の最低金額ルールを迂回すると主張しました。
「システムは自社の『USD 5.00 最低金額』ルールを破り、適切なエラー防止を迂回し、即座に Stripe/ゲートウェイに支払いリクエストを送信します。」
これらは報告者によるシステム動作の特徴付けであり、独立して検証された調査結果ではありません。
請求額は税込みで増加
別の更新で、投稿者はカードから引き落とされた最終金額が 504.00 ドルよりも高かったと述べました。これは、誤った基本金額に現地の VAT が計算されたためです。
「システムが誤った 504.00 ドルの基本金額を処理したため、自動的に現地の VAT（税金）を上乗せし、追加で 65.52 ドルが加算されました。このワンクリックバグにより私のカードから引き落とされた合計額は 569.52 ドルです。」
サポート体験
投稿者は同日に苦情を申し立てたが、人間ではなく自動サポートボットに回されたと述べています。投稿によると、ボットは返金を拒否し、プラットフォームのバグに起因する過剰請求という主張を人間が確認することなく、一般的なポリシーを引用してチケットを閉じました。
また、彼はコスタリカの銀行にチャージバックを申請したと述べており、現地の銀行手続きは解決に最大 120 日かかる可能性があり、その間請求は明細に残るとのことです。
反論: 合計金額は画面に表示されていた
あるコメント投稿者は、金額が表示されなかったという主張に反論しました。ユーザー striking は、platform.claude.com の「クレジットを追加」画面を確認し、合計請求額が目に見えて更新されることを観察したと報告しました。
「私は https://platform.claude.com の『クレジットを追加』画面を見ていますが、入力フィールドに
5,04と入力すると、『合計請求額』が 504.00 ドルと目立つように表示されます...」
この観察は2つの理由で注目に値します。第一に、フィールドがカンマを小数点ではなく桁区切りとして扱う可能性を示唆しており、これも 5,04 から 504 を生成する可能性があります。第二に、計算された合計が送信前にレンダリングされることを示しており、これは確認ステップよりも弱い保護ですが、無言の請求と同じではありません。報告者の立場は、表示された合計は確認モーダルではなく、入力は曖昧として拒否されるべきだったというものです。
別のコメント投稿者 merb は、入力自体に疑問を呈しました。
「5.04 で何をしたかったのですか？スペインや他のヨーロッパ諸国では 5,04 が正しいでしょう？つまり、5.04 は無効か、Claude がやったように 504 になるかのどちらかです。」
なぜこの障害モードが1件の取引を超えて重要なのか
報告者はこの問題を個人的なものではなく体系的なものとして捉えています。彼の主張は、同じ解析パスが入力された数値に応じて拡大するというものです。同じ動作で 50.00 と入力すると、5,000.00 ドルの請求が発生するでしょう。また、金融ソフトウェアは曖昧な数値入力を推測するのではなく拒否すべきだと主張しています。
「金融ソフトウェアでは、システムが明示的な検証なしに数値入力を推測したり自動的に操作したりすることは決して許されません。ロケールの違いにより入力が曖昧な場合、アプリケーションはそれを拒否するか明確化を求めるべきであり、100倍の過剰請求を実行してはなりません。」
自動サポートの非対称性
スレッドで最も広く反響を呼んだ懸念は、解析バグ自体ではなく、明らかな間違いを認識できる人間に連絡できないことでした。コメント投稿者 clickety_clack はこれを構造的な不均衡として捉えました。
「これは私が恐れる種類の間違いです。普通の人間なら『ああ、もちろんこれは間違いですね、申し訳ありません』と言えるでしょうが、あなたは人間と話すことができません。企業は解決に数ヶ月待つことができますが、個人は待てません。」
コメント投稿者 nottorp は支払い管理に関する関連質問を提起し、これらの支払い UI が使い捨ての仮想カード番号を受け入れるかどうか、ヨーロッパのカードで 3D セキュアがサポートされているかどうかを尋ねました。これらの質問はスレッド内で回答されませんでした。
あるコメント投稿者 UnlockedSecrets は、元の投稿が AI 支援で書かれたかどうかを疑問視しました。このコメントには、表示されているスレッド内で実質的なフォローアップはありませんでした。
未解決のまま残っていること
スレッドには、Anthropic からのバグを確認または否定する応答、修正がリリースされたという声明、返金が承認されたという兆候はありません。報告者の再現主張と銀行明細のスクリーンショットは自己申告です。スレッド内の唯一の独立したチェックである striking の観察は、コンソールが入力 5,04 に対して計算された合計請求額 504.00 ドルを表示することを確認しており、これは報告者の請求額の説明と一致しますが、正確な解析パスや確認ステップの存在を単独で立証するものではありません。
支払い入力を構築するすべての人への一般化可能な教訓
自由形式のテキストを受け入れる通貨金額フィールドは、小数点区切り文字を明示的に解決する必要があり、推測してはなりません。ここで説明された障害パターンには3つの分離可能な要素があり、それぞれ独立して防止可能です。
- 曖昧な入力が暗黙的に受け入れられる。 ユーザーのロケールと一致しない区切り文字を含む値は、エラーで拒否するか、解釈された値を可視的にエコーして正規化する必要があります。
- 不可逆的な請求の前に確認ステップがない。 表示された実行中の合計は、最終金額と通貨の明示的な確認と同じではありません。
- エスカレーションパスがない自動サポート。 人間によるレビューなしにボットが返金拒否を行うと、影響を受けた当事者は遅いチャージバックルートのみが残され、報告者によるとコスタリカでは最大 120 日かかる可能性があります。
メータリング API 課金を統合する開発者にとって、実用的な教訓は、チェックアウト時に表示される金額を意図した金額と照合し、ベンダーがサポートしている場合は取引ごとの制限や使い捨て番号を許可する支払い手段を優先することです。