🪙 AWSの請求画面に突然$1.7B — 単価計算バグが教えてくれた「推定値で自動化していいのは通知まで」

月$5しか使っていないAWSアカウントの請求画面に、$1.7 billionと表示されたらどうしますか。

2026年7月17日の昼(JST)、それが実際に起きた。Hacker Newsのスレッドは悲鳴と笑いの実例集になっていて、$437B、$2.5T(兆)、果てにはマイナス$3兆という報告まで並んだ。マイナスなら払ってほしいくらいだ。日本語圏ではまだ報じられていないようなので、事実関係と、笑い話で終わらせないための教訓をまとめておく。

起きたことと、起きていないこと

時系列を整理する。7月16日19:38 PDT(17日11:38 JST)頃から、Billing ConsoleとCost Explorerの「推定請求額」に異常値が出始めた。AWSの公式説明は「推定請求計算サブシステム内の単価(unit pricing)の問題」。HNでは「GBで計算すべき単価をバイトで計算した——つまり2^30倍」という推測が有力視されていた(これは未確認の推測として書いておく)。

大事なのは影響の線引きだ。壊れたのは表示層の「推定値」だけで、実際のメータリングと確定請求は無事だとAWSは明言している。カードから$1.7Bが引き落とされることはない。

ただし「表示だけ」では済まなかった副作用がひとつある。Budgetsの閾値アラートが実際に誤発報した。推定額が閾値を貫通したのだから当然で、深夜に「請求が予算を超えました」のメールを受け取った利用者が大量に発生した。そもそもHNスレッドの発端の一部もこのアラートだ。復旧も一筋縄ではなく、最初のロールバックは失敗し、全顧客の表示修正は7月19日4:00(JST)までかかる見込みとされた。

「アラートで自動停止」の人は自分事です

ここからが本題で、この事故は推定データ駆動の自動化への警告として読むべきだと思う。

コスト暴走対策として「請求アラームが発火したらリソースを自動停止する」構成は定番だ。個人の検証環境なら合理的でもある。でも今回のような誤表示が起きると、その自動化は正常稼働中の本番を自分の手で止める。今回、自動停止の誤作動が実際に起きたという報告はHNでは確認できなかったが、TechCrunchの「アカウント停止は発生したか」という質問にAWSは回答を拒否している。沈黙は少なくとも「ゼロだった」を意味しない。

原則はシンプルだ。推定(estimated)と名の付くデータは、課金の事実ではなく計算の派生値。派生値に許可していいのは通知までで、破壊的アクション(停止・削除・スケールイン)の引き金にしてはいけない。うちの業務基盤にもAPI予算の閾値で自動的に動作を絞る仕組みがあるが、この事故を見て「実測の累計値を使っているか、推定値を混ぜていないか」を確認し直した。閾値超過で”止める”のではなく”人間に聞く”に倒しておくのは、こういう日のためです。

もうひとつ、人間側の話。HNには、誤表示の巨額請求が心理に与える害を指摘する声もあった。元AWS社員の証言によれば、2010年代に$7,000の誤請求を返金させるのに14ヶ月かかったという。「どうせ直る」と頭で分かっていても、画面に出た10桁の数字は心拍数を上げる。表示バグは技術的には軽微でも、ユーザー体験としては軽微ではない。

計器が狂っても飛行機は飛んでいた、というのが今回の顛末だ。でも計器を信じて操縦桿を切る自動操縦を組んでいたら?——あなたの請求アラームの先に、何が繋がっているか。週明けにひとつ確認してみてください。