一、$17億の請求書、元の月額は$5未満
2026年7月17日、nprateem という名の AWS ユーザーが Hacker News に投稿した。彼の AWS 月次推定請求額は $1,700,000,000——17億ドルだった。一方、彼の通常の月額利用料は5ドル未満だ。
目を疑った。だが疑いはなかった。
彼はすぐに緊急チケットを起票し、スレッドで「他にも同じ状況の人はいますか？」と問いかけた。
答えは：いる、しかも大勢。
Reddit や X（旧 Twitter）には、瞬く間に大量のスクリーンショットが溢れた。先月たった $0.19 しか使っていなかったユーザーが、約25億ドルの推定請求を受け取った。別のユーザーは X にこう書いた：「AWS の請求書に 1.5 兆ドルって表示されてて、魂が身体から抜け出した」この投稿は130万回の閲覧と約1.9万のいいねを集めた。
パニックのあまりアカウント上の全リソースを消去してしまったユーザーもいた——「言うまでもなく、私は慌てて、そのアカウント上のすべてをぶっ壊した」
とはいえ、これらの数字は実際の引き落としではなかった。AWS はすぐに、「問題が起きていたのは実請求ではなく『推定請求』だ」と確認した。それでもなお、あの数字を見た瞬間、冷静でいられた者は誰もいない。
二、そもそも何が起きたのか？
AWS 公式は発生から90分以内に根本原因を説明した：「推定請求計算サブシステムにおける単位単価の問題」。もごもごした言い回しだが、要するに——単位を一つ書き間違えただけだ。
この件を真正面から解き明かしたのは、donavanm という元 AWS エンジニアだ。彼は Hacker News のコメント欄に、こう書き込んでいる（筆者訳・引用）：
“I’ve dealt with this error at AWS. It’s a unit error. In my case we meant to charge like 5¢/GB, but missed the unit (GB), and then the billing system defaults to bytes. 5¢ per Byte of data transferred meant some customers were seeing MM bills within hours. Got paged by support around 2am, had it fixed and amendments issues by 3-4am, apology emails shortly after. Services emit metering values that aren’t directly tied to prices. Every SKU/line item is defined in a ‘pricing plan’, with a unit type, regions, and price per unit. The metering records are joined to a pricing plan based on account id, region, sku, etc. mess up the unit type in the pricing plan and the metering data conversion doesn’t work, and you get crazy bills.”
この一文から、いくつかの決定的な情報が読み取れる。
第一に、これは初めてではないということ。同じ種類のミスは以前にも起きている——筆者が言う「以前」とは、おそらく一度や二度ではない。
第二に、その誤差の倍率が桁外れだということ。1 GB = 1,073,741,824 bytes。もし「GB」を書き忘れれば、システムはデフォルトで byte 単位で計算し、請求額は一瞬にして 10億倍 に膨れ上がる。$0.05 の利用料が、$53,687,091.20 になるのだ。
第三に、このミスはリリース前の自動チェックでは捕捉されないということ。開発・テスト・デプロイの各関門をすり抜け、ユーザーが請求書のスクリーンショットを見て恐慌状態になり、投稿して助けを求めて初めて発覚した。
三、なぜ「単位を一つ書き忘れる」だけで全ての防波堤を突破できるのか？
ここが、この事件で最も不安を抱かせる部分だ。
donavanm は AWS の課金システムの仕組みをさらに説明している。利用量（どれだけリソースを使ったか）の計測データと、単価（単位あたりいくらか）の料金情報は、別々に格納されている。各 SKU（一つ一つの課金項目）は「料金プラン」と呼ばれる定義に含まれ、単位の種類・適用リージョン・単価などの情報を持つ。計測記録と料金プランは、アカウント ID・リージョン・SKU 番号といった項目で照合される。
もし料金プランの単位の種類が間違っていれば——本来 GB であるべきところが空欄になっていたり byte と書かれていたりすれば——計測データと料金の変換が狂う。そしてこのエラーを止められる自動チェックは、どこにも存在しない。
Hacker News の別のユーザーのコメントが、核心を突いている：
“No tests? Just mess up some mundane detail [1] and voila! Wake-up calls and heart attacks for 100,000s of administrators?”
これに別のユーザーが答えている：
“Test 1 will verify that the new system/product emits billing entries in some expected way (‘We did 100 bytes of operations and we see we called the billing system for 100 bytes of stuff, yay, test pass’). Test 2 will be in the billing system (‘We provide an incoming bill for SKU#12345 for 100 gigabyte-units and we see it costs $17, yay, test passes’). But they won’t test the two things together because it will be harder to do and the teams will have different management chains. Somebody will have said at some point ‘we should actually have the tests charge money’ and somebody else will have said ‘well we can’t have the tests actually charge money, that’s a legal/accounting problem, it might even be a crime’ and then nobody would have asked what the next best thing was.”
筆者はこの説明に鋭い洞察があると思う。そこにはよくあるエンジニアリング管理の問題が浮かび上がっている：各工程は単体で正しくても、組み合わせると壊れる。 さらに別の HN ユーザーが補足している。「誰かが会議で『テストで本当に課金フローを通すべきだ』と言って、誰かが『テストで本当に課金請求を発生させるのは法的・会計的な問題になりかねない、犯罪になるかもしれない』と言って——そして誰も次善の代替案を問い続けなかった」
四、真の「悪役」：クラウド課金の複雑さ
この事件を単に「あるエンジニアがうっかり設定を書き間違えた」と捉えるのは、本質を見誤っている。
真の悪役は クラウド課金システムそのものの複雑さ だ。
AWS には約 30万種類の SKU（課金単位）が存在する。300 ではなく、30万だ。一つ一つの SKU が独自の料金ロジック——時間単位、通信量、リクエスト回数、保存容量、リージョン——を持つ。そしてそれらは互いに重なり合う：一つの単純なウェブリクエストが、計算費・ネットワーク転送費・ストレージ読み出し費・ログ記録費・監視データ費……を引き起こす。各項目が独自の単位とルールを持つ。
利用量データの生成と料金データの設定は、完全に独立した二つのシステムだ。両者の照合は項目の関連付けであって、ハードコードされた検証ではない。この設計自体は悪くない——AWS に計測システムを変えずに料金を調整するという巨大な柔軟性を与えている。だがその代償として：「自分のこの操作が最終的にいくらかかるか」を完全に理解できる者は誰もいない。
実際、AWS の請求書は複雑すぎて、それを読み解く専門職——クラウドコスト最適化コンサルタント——まで生まれている。年商1000億ドル超の事業において、顧客が一体いくら払っているかを伝えるための専門の「通訳」が必要なこと自体が、何かを物語っている。
AWS 自身のエンジニアでさえ、HN の議論ではいくつかの気味の悪い事実を認めている。元社員を名乗る一人はこう書いた：「会社全体がルーブ・ゴールドバーグ・マシン（過剰に複雑に意図的に設計された機械装置）のようで、自分の担当する小さな歯車の外で何が起きているかを気にする人はほとんどいない——気にする動機がないからだ」
別の元社員が付け加えている：「私は Focus（パフォーマンス改善プログラム）に入れられた。理由は『私の貢献が経営層に伝わっていなかった』からだ。そうした環境では、同僚のコードに潜む問題を見つけても、それを進んで指摘して直す動機は何もない——直したところで、年末の評価ランクでは一定割合の人間が『低パフォーマンス』枠に振り分けられるのだから、ではなぜその枠にバグを残した同僚ではなく私がならないのか？」
もちろん異論もある。別の元マネージャー級社員は反論する：「この程度の顧客影響なら、必ず COE（エラー是正）レポートが発行される。つまり再発防止の必須アクション項目のリストが作られ、少なくとも一人月の労力を食う。COE 自体がチーム全体にとって巨大な厄介ごとなのだから、それだけで問題を未然に防ぐ強い動機になる」
筆者はどちらにも与しない。この二つの主張は同時に真であろう——部門や管理階層によって文化の差は劇的だ。だがそれこそが示唆するものだ：数万名のエンジニアを擁する組織であっても、全員が善をなそうとしていても、システム的な脆弱性はそのまますり抜けていける。
五、AWS はどう対応したか？
AWS Health Dashboard の公開タイムラインによれば：
- 7月17日 午前3:52（PDT）：AWS が根本原因を「推定請求計算サブシステムにおける単位単価の問題」と確認し、請求推定の計算を停止。
- 午前4:58：二つの修復ルートを同時並行で試行——直近の変更をロールバックするか、最後の正確なデータへ復旧するか。
- 午前5:54：内部監視により課金サブシステムが正しい推定を生成できることを確認、さらに検証中。
- 午前7:53：悪い知らせ——ロールバックは問題を解決せず、両ルートとも進行中。推定請求の更新は停止したまま。
- 午前9:59：根本原因を特定・修正し、全顧客向けに請求データの再計算を開始。一部の顧客は3時間以内に復旧、全顧客は7月18日正午までの復旧を見込む。
- 午後12:56：想定より遅れている。全部復旧は7月19日未明へ延期。声明はこう強調した：「表示されている請求推定は実際の利用・課金を反映していない。顧客は何も行う必要がない」
「単位の書き忘れ」というバグの修正に、AWS は24時間以上を要した——しかも最初の修復試行は失敗した。これは逆説的に示している：AWS 自身のエンジニアでさえ、自らのシステムのバグを直すのは簡単なことではないと。
六、このことは何を意味するか？
この事件は最終的に、実質的な経済損失を一切引き起こさなかった——誰も過剰請求されなかった。だが浮き彫りになった問題は、「あるエンジニアがうっかりした」よりもずっと深い。
第一、クラウド課金はすでに「誰にも完全には理解できない」システムになっている。 AWS はその極端な例に過ぎず、Google Cloud も Microsoft Azure も同じ問題に直面している。システムの複雑さが単一の人間の理解力を超えたとき、それはもはや制御可能な道具ではなく、「観察し、推測し、うまくいくだろうと祈る」しかないブラックボックスになる。
第二、AI 時代がこの問題の stakes（賭け金）を引き上げている。 まさに先週、AWS は顧客向け AI エンジニアチームに10億ドルを投じると発表したばかりだ。単一の AI 学習タスクの月額請求は、すでに数億ドル規模に達しうる。本物の請求の規模がこれほど巨大になると、課金エラーがたとえ「推定表示」だけであっても、引き起こす社会的パニックと信頼の損失はかつてないほど深刻だ。
第三、このバグは初めてではなく、最後にもならない。 元 AWS エンジニアの donavanm 自身が全く同じエラーを経験し、午前2時に呼び出されて緊急修復している。これはこの脆弱性が AWS のシステムに少なくとも数年は存在し、少なくとも二度は発生し、しかも二度とも大規模なユーザーのパニックを招いたことを意味する。だが、今に至るまで体系的に塞がれることはなかった。
ここまで書いて、筆者は donavanm が AWS の課金アーキテクチャについて語ったあの言葉を思い出す：「サービスの計測データは価格に直接紐付いていない」。平たく言えば——あなたの利用量とあなたの請求書の間には、人手で設定が必要なマッピングが少なくとも二層ある。どの層か一つでも書き間違えれば、結果はこうなる：$5 が $17億に。
参考リンク
- HN ディスカッション：AWS の推定請求データの不正確さについての Hacker News 投稿。元ポストの nprateem が $17億の請求書スクリーンショットを公開し、992ポイント・618コメントの活発な議論を呼んだ（item?id=48945241）
- 元 AWS エンジニア donavanm の根本原因分析コメント：単価単位の設定ミス（byte vs GB）が請求額を10億倍に膨張させる仕組みと、計測データと料金が分離した AWS 課金システムのアーキテクチャ設計を詳解
- AWS Health Dashboard の告知：「Billing Console - 推定請求データの不正確さ」についての AWS 公式ステータスページ。根本原因の確認から修復完了までの全更新記録
- The Next Web の報道：Reddit ユーザーの反応（$0.19 の月額が $25億に）や AWS の修復スケジュールを含めた総合報道
- Cyber Kendra の報道：X 上のユーザー @Bharath_uwu が公開した $1.5兆ドル請求のスクリーンショットや、AWS Support の公式回答を引用
- TechRadar の報道：「私の魂が身体から抜け出した（my soul left my body）」という見出しで、全クラウドリソースを削除した極端な事例を含む複数のユーザーの恐慌反応を紹介
