AWSさんから 1,400万円 請求された件 bedrock-mantleエンドポイントの課金バグから学んだこと Tsumita Yuki JAWS-UG 山梨 | 2026.04.04 

積田 優生 (Tsumita Yuki) • 2025 Japan AWS Ambassador • 2025 Japan AWS Top Engineer • 2025 Japan AWS All Certifications Engineer 

おことわり 01 同じような状況に陥った方向けへの情報提供が主目的です 02 AWSさんをディスる意図はありません 03 事実ベースで資料記載していますが一部仮説も含みます 

No content

山梨だと一軒家が購入できる！！！！ 

今日話すこと 01 何が起きたか ある朝、Cost Explorerを開いたら $89,748 02 不可解なトークン比率・利用 386:1というInput:Output比率、Quotaを超えた利用 03 AWSサポートとの16日間 3つのサポートケース、侵害誤判定、そして解決まで 04 教訓 同じ目に遭わないためにできること 

2026年2月24日（月）朝8時 ある朝、Cost Explorerを開いたら $89,748 約1,400万円！！ 

そもそも何をしていたか EC2 OpenClawエージェント 5分に1回cron実行 → Bedrock Kimi K2.5 bedrock-mantle API → Slack 通知 2/18 EC2サーバー起動、OpenClaw稼働開始 2/19 動作確認完了、サーバー削除 — OpenClaw上のトークン消費: 約3Mトークン 2/24 Cost Explorerで$89,748の表示 → Billing上は約111.8Bトークン 約37,267倍...！ 

https://openclaw.ai/ https://x.com/nvidianewsroom/status/2033640956512375262?s=20 OpenClawとは？ 

Bedrock Mantleとは？ https://docs.aws.amazon.com/ja_jp/bedrock/latest/userguide/endpoints.html 

不可解なトークン比率 111.8B Input tokens Billing上のInputトークン 386:1 通常は1:1〜15:1 Input:Output比率 CloudWatch: Mantle経由の利用は出力されない... 【仮説】トークンのInput:Outpu比率が不可解...Billing上のtoken数が実際より大幅に 計上しているのでは？ 0.3B Output tokens Billing上のOutputトークン 

Quotaを超えた異常なトークン利用 Service Quota： 【仮説】 Quotaが5.4Bトークン/Dayなのに対して、OpenClawを立ち上げていた2日で 111.8Bトークン利用するのはあり得ない...バグなのでは？ 

世界中のニキからも同様の事象報告 https://github.com/anomalyco/opencode/issues/13807#issuecomment-4017213363 

原因（結論）: bedrock-mantle 課金バグ AWS製品担当部署認定（2026/3/7） bedrock-mantleエンドポイント経由のBedrock利用で、実際のトークン消費量より高い請求が Cost Explorerに表示される問題を確認。根本原因はサービス側にあり、1-2週間で修正予定。 少なくとも影響を受けたモデル（すべてProject Mantle経由） moonshotai.kimi-k2.5 zai.glm-4.7 openai.gpt-oss-120b / 20b deepseek.v3.2 mistral models 現時点で修正済み 

16日間 AWSサポート対応タイムライン 2/24 報告 請求ケース起票。同日中に受付完了 3/2-3/7 調査 技術ケース追加起票 → 3/7にバグ認定 3/7 侵害誤判定 バグ認定後にアカウント制限 3/7 制限解除 約19時間後にアカウント安全確認＆制限解除 3/9 請求調整 $89,024返金。ただしJPY 22,760の支払い要求 3/11 解決 ※ JPY 22,760の免除 AWSクレジットを持っていたため、本来であれば 課金発生し得なかった分についても全て免除 ※Billing上の表示トークン数は4/4時点で未修正... 

最大の問題: アカウント侵害の誤判定 AWSの 課金バグ → 異常な 高額請求 → 不正利用と 誤判定 → サービス 制限 Lambda: UnknownError Bedrock: ValidationException 

侵害ケースの顛末 ケース間連携の不備 技術ケースでバグ認定済みなのに 侵害ケース担当者がそれを把握せず 「不正アクティビティが原因」と断言 約19時間のサービス停止 アカウント安全確認 

最終結果 Bedrock異常課金 $89,169 全額調整済 保有AWSクレジット $600 再付与済 最終支払額 ¥0 ただし... • 約21日間の対応工数（3つのサポートケース管理） • 約19時間のサービス利用停止 • 約1,400万円の請求表示がコンソールに残存 私生活に影響が出るレベルの精神的苦痛... 

教訓 1 Budget Alertsなどコストの通知必ず設定する 異常の早期発見に繋がった 2 技術的根拠を自力で準備する BillingやCloudWatchメトリクス分析がAWSの迅速なバグ認定を後押し && 自身の精神的安定の確保 3 サポートケース間連携の限界を意識する 請求調整と技術調査を分けるとそれぞれの専門チームに繋がるが、ケース間連携に限界あり 4 論理的に交渉する 「バグがなかった場合の本来の請求額」を算出し、不合理を指摘 5 新サービス/エンドポイントには注意が必要かも Project Mantle Kimi K2.5は2026年2月ローンチ。初期は課金バグのリスク大。直近は他でも課金周りの問題複数あり.. 

まとめ AWSの課金バグは実在する 特に新しいサービスは要注意かも.. 技術的根拠を自分で準備できる知識をつける CloudWatchメトリクスとBillingの突合が決め手になり今回は精神的に少し楽に 問い合わせは論理的で感情に頼らない 「バグがなかった場合の正しい状態」を具体的に提示する ご清聴ありがとうございました