「金曜の夜に AI に書かせた Lambda をデプロイして帰宅。月曜の朝、請求ダッシュボードを開いたら、先月の月額予算を 1 日で使い切っていた――」 バイブコーディング (vibe coding = AI に書かせて雰囲気で作る開発スタイル) で運用する中堅企業にとって、クラウドの従量課金 (pay-as-you-go) は 「動いているうちは見えないコスト」 です。サービスは落ちていない、エラーも出ていない、監視ダッシュボードは全部グリーン。それでも請求額だけが静かに膨らんでいく――この現象は近年 「Denial of Wallet (DoW / 財布の枯渇攻撃)」 という名前で呼ばれるようになりました。
従来の DoS (Denial of Service) はサービスを止めて損害を与えます。これに対し DoW は サービスを止めずに、従量課金とオートスケールを悪用して財務を枯渇させる 攻撃概念です (arXiv: Denial of Wallet — Defining a Looming Threat to Serverless Computing)。そして厄介なのは、攻撃者がいなくても、自社の AI 生成コードが「自分で自分の財布を攻撃する」 という形でまったく同じ事故が起きることです。
「サーバーレスだから安い」「使った分だけだから無駄がない」「クラウドが勝手にスケールしてくれる」――この 3 つの油断こそが、AI 時代の中堅企業の高額請求リスクです。本記事は連載「バイブコーディング危機」第 16 回として、暴走 6 パターン、なぜ AI 生成コードで起きやすいのか、悪い例 / 良い例のコード比較、コストガードレール (AWS Budgets / サービスクォータ / レート制限 / タイムアウト / dev-prod 分離 / タグ可視化 / IaC)、30 分チェックリスト、いつ GXO に相談すべきか を、AWS 公式ドキュメントと学術論文を一次ソースに整理します。
本記事は連載「バイブコーディング危機」第 16 回です。 AI で自社システムを開発する中堅企業向けに、専門家不在で起きるリスクを整理しています。 第 1 回（概論 + 7 リスク類型） 第 9 回（バックアップ検証の現実） 第 19 回（テスト無し・回帰の現実） 第 20 回（ログ・可観測性の欠如）
目次
- Denial of Wallet とは何か（DoS との違い）
- クラウド課金が暴走する 6 パターン
- なぜ AI 生成コードで暴走が起きやすいのか
- 悪い例 / 良い例のコード比較
- コストガードレール 7 種（中堅企業向け実装）
- 中堅企業向けチェックリスト（30 分）
- いつ GXO に相談すべきか
- まとめ
- 参考一次ソース
Denial of Wallet とは何か（DoS との違い）
Denial of Wallet (DoW) は、サーバーレスやオートスケールの 従量課金モデルを悪用して、可用性を落とさずに財務的損害を与える 攻撃概念です。学術的には 2021 年の論文 (arXiv 2104.08031) で定義され、その後 Oxford Academic の Journal of Cybersecurity に掲載された DoWNet 論文 (2024) などで攻撃トラフィックの分類・検知手法が研究されています。2025 年にはサーバーレス環境での包括的レビュー論文 (arXiv 2508.19284) も公開されました。
DoS と DoW の違い
| 観点 | DoS（従来） | DoW（Denial of Wallet） |
|---|---|---|
| 狙い | サービスを 止める | サービスを止めずに 請求を膨らませる |
| 症状 | 503 / タイムアウト / 落ちる | サービスは正常、請求額だけ増える |
| 監視で気づくか | エラー率・死活監視で検知しやすい | アプリ監視はグリーンのまま 見逃しやすい |
| 攻撃手段 | 大量リクエストで枯渇 | 低速・少量でも従量課金を着実に積む |
| 自爆の有無 | 基本は外部攻撃 | 自社コードのバグで自爆 が頻発 |
最大のポイントは「自爆」です。DoW は外部攻撃者の概念として生まれましたが、中堅企業で現実に多いのは AI 生成コードのループ・再帰・リトライによる自損事故 です。攻撃者がいなくても、無限ループする Lambda や暴走するエージェントが、自分の会社のクレジットカードを毎秒叩き続けます。AWS 自身、この種の事故 (recursive loop) を防ぐためのガードレールを 2023〜2024 年に標準機能として追加しています (AWS: Use Lambda recursive loop detection)。逆に言えば、クラウド事業者が標準で対策を入れるほど現実に多発している事故 ということです。
AI ASSESSMENT
PoC の前に「そもそも使えるか」を30分で見極めませんか？
情シス部門の稟議書作成をサポートする無料の30分壁打ち。ROI 試算シート・失敗要因チェックリストをその場で共有します。
クラウド課金が暴走する 6 パターン
AI 生成コードが従量課金を暴走させる典型を 6 つに整理します。いずれも「動く」コードであり、止まらないことが問題です。
パターン 1: Lambda の再帰呼び出し（自己トリガ無限ループ）
典型: AI に「処理が終わったら同じ関数をもう一度呼んで」と頼むと、終了条件のない再帰を書きます。あるいは SQS / SNS / EventBridge を介して関数 A → B → A と循環する構成を作ります。
AWS は、同一リクエストチェーンで 約 16 回 関数が呼ばれると recursive loop と判定し、次の呼び出しを自動停止する機能を 全顧客でデフォルト有効・無償 で提供しています (AWS: Detecting and stopping recursive loops in AWS Lambda functions)。ただし対象は Lambda・SQS・SNS・S3 の間の循環に限られ (公式ドキュメント)、自前 API を介した循環や、毎回 異なるリクエストチェーン として発生するループは検知されません。「標準機能があるから安心」は誤りです。
パターン 2: S3 イベントの自己トリガ
典型: 「S3 にファイルが置かれたら Lambda で加工して S3 に書き戻す」処理を、入力と出力で同じバケット にしてしまうパターンです。書き戻したファイルが再びイベントを発火し、Lambda が再び書き込み、無限に循環します。
AWS は 2024 年 10 月に Lambda と S3 の間の再帰ループ検知 を追加しました (AWS: Lambda now detects and stops recursive loops between Lambda and Amazon S3)。AWS 公式ブログは恒久対策として 入力用と出力用でバケットを分ける、またはプレフィックス / メタタグで初回イベントのみ反応させる「ポジティブトリガ」を推奨しています (AWS: Avoiding recursive invocation with Amazon S3 and AWS Lambda)。
パターン 3: 無制限オートスケール（スケール上限を書かない）
典型: ECS / Kubernetes (HPA) / Lambda の同時実行 / Auto Scaling Group で、最大値 (max) を設定せず にスケールアウトを許す構成です。負荷スパイクやリトライ嵐が来ると、コンテナ / インスタンスが青天井で増え、請求も青天井になります。サーバーレスのレビュー論文も、オートスケールが「財務的な武器」になり得る点を DoW の中核に挙げています (arXiv 2508.19284)。
パターン 4: リトライ嵐（指数バックオフ・上限なしの再試行）
典型: 「失敗したらリトライして」とだけ指示すると、AI は 間隔を空けない・上限回数のないリトライ を書きがちです。下流が落ちている時に上流が全力で再試行し、復旧を妨げながら呼び出し回数（＝課金）を積み上げます。さらにキューに失敗メッセージが滞留し、再処理のたびに課金が発生します。
パターン 5: LLM API のトークン暴走（エージェントループ）
典型: AI エージェントが「タスクが終わるまで考え続ける」ループに入り、毎ターン 会話履歴・ツール出力・推論トレースを丸ごと再送 します。多くの LLM API は 1 回の呼び出しごとに会話全体の入力トークンを課金 するため、ステップ数 N に対しコストが概ね二乗 (O(N²)) で増えていきます。リトライ・自己反省ループが終了条件なく回ると、トークン消費と請求が指数的に膨らみます。
この種の事故はベンダー各社が「runaway agent cost」「token spiral」として警告しており、夜間や週末に走らせたエージェントが、戻ってきた時には想定外の請求になっていた という報告が複数あります（いずれもベンダー記事ベースの事例で、具体額は会社・モデルにより大きく異なります）。LLM を組み込む際の上限設計は、第 19 回で扱う テスト不在 や第 20 回の 可観測性欠如 と並ぶ、AI 開発特有の落とし穴です。
パターン 6: dev / 検証環境の消し忘れ放置
典型: AI と一緒に検証用の環境（NAT Gateway・RDS・GPU インスタンス・ロードバランサ等）を立て、動作確認後に消し忘れる パターンです。アイドル状態でも時間課金され続け、誰も使っていないのに毎月固定費のように請求されます。アタッチされていない Elastic IP や放置 EBS ボリュームのような「使っていないのに課金される」リソースも、AWS が unexpected charges の典型として挙げています (AWS: Understanding unexpected charges)。
6 パターンの整理
| # | パターン | 主因 | 効くガードレール |
|---|---|---|---|
| 1 | Lambda 再帰ループ | 終了条件・循環設計の欠如 | 同時実行上限 / 再帰検知 / DLQ |
| 2 | S3 自己トリガ | 入出力同一バケット | バケット分離 / ポジティブトリガ |
| 3 | 無制限オートスケール | max 未設定 | スケール上限 / サービスクォータ |
| 4 | リトライ嵐 | 上限なし再試行 | 指数バックオフ + 上限 + サーキットブレーカ |
| 5 | LLM トークン暴走 | ループ・履歴再送 | トークン/コスト上限 + ステップ上限 |
| 6 | dev 消し忘れ | ライフサイクル管理欠如 | タグ + 自動停止 + dev/prod 分離 |
なぜ AI 生成コードで暴走が起きやすいのか
「人間が書いても起きるのでは？」という疑問はもっともです。しかし AI 生成コードには、暴走を 構造的に招きやすい 5 つの特性 があります。
特性 1: AI は「動く最短コード」を優先し、上限を書かない
AI に「画像をリサイズする Lambda を書いて」と頼むと、機能するコードは返ってきます。しかし reservedConcurrency（同時実行の上限）、リトライ回数の上限、タイムアウトの妥当な値、予算アラートといった 「暴走しないための装備」は、明示的に指示しないと付きません。これは第 5 回で扱った データ削除スクリプトに dry-run / confirm が付かない 現象とまったく同じ構造です。
特性 2: タイムアウトがデフォルト最大値のまま
AI が生成する IaC やコンソール手順では、Lambda のタイムアウトや API のタイムアウトが 見直されないまま長い値で放置 されがちです。1 回の処理が長引けば、その分だけ実行時間課金が膨らみ、ループ時の被害も大きくなります。
特性 3: 予算アラート・課金モニタを「アプリの一部」と認識しない
AI はアプリのロジックは書きますが、AWS Budgets・Cost Anomaly Detection・課金 CloudWatch アラーム は「アプリの外側の運用設定」のため、依頼に含めない限り絶対に出てきません。結果、請求が膨らんでも誰にも通知が飛ばない 状態が放置されます。
特性 4: dev と prod の分離・ライフサイクルを設計しない
AI と素早く試作すると、検証リソースが本番アカウントに混在し、タグも付かず、誰がいつ消すかも決まりません。「作ったら消す」ライフサイクルの設計 は、人間が運用視点で意識しないと生まれません。
特性 5: 「無限に回る」前提の終了条件を書かない
エージェントやポーリング処理で、AI は「タスクが完了するまで」と書きますが、「最大 N ステップ」「最大 ¥X」「最大 T 秒」で必ず止まる という外側の制約を入れないと、判断を誤ったループが永遠に回ります。
要点: 暴走の原因は AI の能力不足ではなく、「コスト上限・タイムアウト・予算アラートは明示的に依頼しないと書かれない」 という性質です。プロンプトに「上限・タイムアウト・予算アラートを含めて」と書くだけで、6 パターンの多くは初手で防げます。
FREE DOWNLOAD
AI導入チェックリスト（PoC 失敗要因 10項目）
情シス部門が PoC 前に押さえるべき失敗要因を10項目に整理した無料チェックリスト。
悪い例 / 良い例のコード比較
例 1: S3 → Lambda → S3（自己トリガ）
悪い例（AI 初期生成・同一バケットに書き戻す）
# 入力と出力が同じバケット。書き戻したファイルが再びイベントを発火 → 無限ループ
import boto3
s3 = boto3.client("s3")
def handler(event, context):
for record in event["Records"]:
bucket = record["s3"]["bucket"]["name"]
key = record["s3"]["object"]["key"]
body = s3.get_object(Bucket=bucket, Key=key)["Body"].read()
resized = resize(body)
# ← 同じバケットに書き戻し。これがまたイベントを発火する
s3.put_object(Bucket=bucket, Key=f"resized-{key}", Body=resized)
良い例（入出力バケット分離 + 冪等ガード）
import boto3
s3 = boto3.client("s3")
OUTPUT_BUCKET = "myapp-images-output" # ← 出力は別バケット
def handler(event, context):
for record in event["Records"]:
bucket = record["s3"]["bucket"]["name"]
key = record["s3"]["object"]["key"]
# 二重防御: 既に処理済みプレフィックスは無視（ポジティブトリガ）
if key.startswith("resized-"):
continue
body = s3.get_object(Bucket=bucket, Key=key)["Body"].read()
resized = resize(body)
s3.put_object(Bucket=OUTPUT_BUCKET, Key=f"resized-{key}", Body=resized)
ポイント: 出力先を別バケットにするのが恒久対策、プレフィックス判定が二重防御です。さらに関数に 同時実行の予約上限（後述）を設定し、AWS の再帰ループ検知を有効のまま運用します。
例 2: リトライ（外部 API 呼び出し）
悪い例（上限なし・間隔なしの無限リトライ）
def call_api():
while True: # ← 上限なし。下流が落ちている間ずっと叩き続ける
try:
return requests.post(URL, json=payload, timeout=None) # ← timeout も無し
except Exception:
continue # ← 即座に再試行。リトライ嵐の温床
良い例（指数バックオフ + 上限 + タイムアウト + サーキットブレーカ）
import time, random, requests
def call_api(max_retries=5, base=0.5, cap=8.0):
for attempt in range(max_retries):
try:
return requests.post(URL, json=payload, timeout=5) # ← タイムアウト必須
except requests.RequestException:
if attempt == max_retries - 1:
raise # ← 上限到達で諦める（DLQ / アラートへ）
sleep = min(cap, base * (2 ** attempt)) + random.uniform(0, 0.3) # ジッタ付き指数バックオフ
time.sleep(sleep)
ポイント: リトライは 回数上限・間隔・タイムアウト・ジッタ の 4 点セットが必須です。連続失敗時はサーキットブレーカで一時停止し、失敗メッセージは DLQ（デッドレターキュー）に逃がして課金の連鎖を断ちます。
例 3: LLM エージェントループ
悪い例（終了条件なし・履歴を丸ごと再送）
messages = [{"role": "user", "content": task}]
while True: # ← 止まる条件がない
resp = llm.chat(messages) # ← messages 全体を毎回送る（履歴が膨張）
messages.append(resp.message)
if needs_more_work(resp): # ← この判定をモデル任せにすると永遠に回る
messages.append(tool_result(resp))
良い例（ステップ上限 + トークン/コスト予算 + 履歴の刈り込み）
MAX_STEPS = 12
MAX_TOKENS = 200_000 # このセッションで許容する累計入力トークン
spent_tokens = 0
messages = [{"role": "user", "content": task}]
for step in range(MAX_STEPS): # ← 必ず止まる
messages = prune_history(messages) # ← 古い・不要な文脈を刈り込む
resp = llm.chat(messages)
spent_tokens += resp.usage.input_tokens
if spent_tokens > MAX_TOKENS: # ← 予算超過で安全停止
raise BudgetExceeded(spent_tokens)
messages.append(resp.message)
if resp.is_final:
break
ポイント: エージェントは 「最大ステップ数」「累計トークン/コスト上限」「履歴の刈り込み」 で必ず止まる設計にします。LLM API ゲートウェイ側でレート制限と日次/月次のコスト上限を二重に張れば、フレームワークを問わず暴走を止められます。GXO の AI開発・LLM導入支援 では、こうした上限設計とコストガードレールをセットで支援します。
コストガードレール 7 種（中堅企業向け実装）
「コードを直す」だけでは足りません。コードの外側にガードレールを張り、暴走しても被害が頭打ちになる構成にします。
ガードレール 1: 予算アラート（AWS Budgets / Cost Anomaly Detection）
AWS Budgets は、日次 / 月次の予算に対し 実績 (actual) と 予測 (forecasted) の両方でアラートを出せます。公式のベストプラクティスは 50% / 80% / 100% の段階アラート に加え、月初に異常を捕まえる 低めの閾値（例: 10%） の設定です (AWS: Best practices for AWS Budgets)。さらに AWS Cost Anomaly Detection は機械学習で平常時の支出パターンを学習し、逸脱を検知します。
注意点: AWS Budgets は 利用と課金反映の間に遅延 があり、通知前に閾値を超過し得ます (公式)。アラートは「事後の保険」であり、上限設定（後述）と併用 してこそ意味があります。
ガードレール 2: サービスクォータ・同時実行上限（ハードな天井）
アラートだけでは止まりません。増えない天井を物理的に設定します。
- Lambda: 関数ごとに
reservedConcurrency（予約同時実行）を設定。暴走しても同時実行数で頭打ちになります。 - オートスケール: ECS / HPA / Auto Scaling Group の max を必ず設定。青天井を禁止します。
- サービスクォータ: アカウント・リージョン単位の上限を把握し、不用意な引き上げをしない。
ガードレール 3: レート制限・スロットリング
公開エンドポイントには API Gateway / WAF のレート制限 を設定し、ブルートフォース的な呼び出し（DoW の典型攻撃ベクトル）を抑えます。LLM 連携は API ゲートウェイ層でトークンバケット・サーキットブレーカ・フォールバックを張るのが定石です。
ガードレール 4: タイムアウトの明示
Lambda・HTTP クライアント・DB 接続・LLM 呼び出しの すべてに妥当なタイムアウト を設定します。デフォルト最大値のまま放置しない。1 回の実行が短く確実に終わることが、課金とループ被害の両方を抑えます。
ガードレール 5: dev / prod のアカウント分離
検証と本番を 別アカウント（または別プロジェクト） に分け、dev 側には低い予算上限と自動停止を設定します。AI と素早く試作する dev 環境ほど、本番の財布から隔離します。アカウント分離・ガードレール設計は DX・システム開発支援 や システム開発・内製化支援 の初期設計で固めるのが効率的です。
ガードレール 6: タグ付けによるコスト可視化（FinOps の基礎）
全リソースに env / project / owner / expire のタグを必須化し、Cost Explorer でタグ別に按分します。「誰の・何の・いつ消す」リソースかが見えれば、消し忘れ放置（パターン 6）は激減します。タグ無しリソースは作成を禁止する IaC ルールが理想です。
ガードレール 7: IaC でのガードレール強制（SCP / Policy as Code）
最も効くのは、ガードレールをコードで強制 することです。Terraform / CloudFormation のレビューで「max 未設定」「タイムアウト未設定」「タグ無し」を弾き、組織レベルでは SCP（Service Control Policy） で高額リソースの作成自体を制限します。AI 生成の IaC こそ、レビューと Policy as Code でゲートを通します。こうした「コードの安全性をパイプラインで担保する」発想は、DevSecOps の体制づくり と同根です。
7 ガードレールの優先順位
| 優先 | ガードレール | 実装コスト | 効果 |
|---|---|---|---|
| 1 | 予算アラート（Budgets） | 低（30 分） | 異変を最速で検知 |
| 2 | 同時実行上限・スケール max | 低〜中 | 被害を頭打ちに |
| 3 | タイムアウト明示 | 低 | ループ被害・課金を圧縮 |
| 4 | dev/prod 分離 | 中 | 試作の暴走を隔離 |
| 5 | タグ可視化 | 中 | 消し忘れ・犯人特定 |
| 6 | レート制限 | 中 | 外部 DoW・ブルートフォース対策 |
| 7 | IaC ガードレール強制 | 高 | 再発を構造的に防止 |
優先 1〜3 は今週中に、4〜7 は四半期計画で整備します。
中堅企業向けチェックリスト（30 分）
情シス 1〜3 名でも 30 分で着手できる項目に絞りました。
| # | チェック項目 | 所要 | 危険サイン |
|---|---|---|---|
| 1 | AWS Budgets で月次予算 + 50/80/100% アラートが設定済みか | 10 分 | 予算が未設定 |
| 2 | 低閾値（10% 等）の早期アラートを 1 本足したか | 5 分 | 月末まで気づけない |
| 3 | Cost Anomaly Detection を有効化したか | 5 分 | 異常スパイクを検知できない |
| 4 | Lambda 関数に reservedConcurrency 上限があるか | 5 分 | 同時実行が無制限 |
| 5 | オートスケール（ECS/HPA/ASG）の max が設定済みか | 5 分 | スケール上限なし＝青天井 |
| 6 | S3→Lambda→S3 で入出力バケットが分離されているか | 5 分 | 同一バケット＝自己トリガ |
| 7 | 外部呼び出し・LLM・DB にタイムアウトがあるか | 5 分 | timeout 未設定 |
| 8 | リトライに上限回数 + 指数バックオフがあるか | 5 分 | 無限リトライ |
| 9 | LLM エージェントにステップ上限 + コスト上限があるか | 5 分 | 終了条件なしのループ |
| 10 | dev/検証リソースに expire タグと自動停止があるか | 5 分 | 消し忘れ放置 |
3 つ以上に「危険サイン」が付いたら、月末の請求が暴走する構造的リスクがあります。まず項目 1・4・5（予算アラートと上限）から潰すと、最悪のケース（一晩で年間予算を焼く）を構造的に防げます。
いつ GXO に相談すべきか
こんな時は早めの相談を
- AI 生成の Lambda / サーバーレスを本番に入れたが、同時実行上限・予算アラートを設定した記憶がない
- 先月の請求が前月比で大きく跳ねたが、原因（どのリソース・どのループか）を特定できていない
- AI エージェント / LLM API を製品に組み込んだが、トークン・コストの上限設計をしていない
- dev と prod が同じアカウントに混在し、誰がどのリソースを消すべきか分からない
- クラウドのコスト最適化（FinOps）やガードレールを、設計レベルで一度整理したい
GXO の支援内容
GXO は中堅企業（年商 30〜300 億・情シス 1〜3 名）向けに、以下を段階的に支援します。
- クラウドコスト暴走の緊急診断: 請求の異常スパイクの原因リソース・ループ箇所を特定し、止血策を提示。
- コストガードレール設計: AWS Budgets / Cost Anomaly Detection / 同時実行・スケール上限 / タイムアウト / レート制限を一括設計（DX・システム開発支援）。
- AI 生成コードのレビューと上限実装: 再帰・リトライ・エージェントループに上限・タイムアウト・予算ガードを実装（システム開発・内製化支援）。
- LLM 導入のコスト設計: トークン/コスト上限、ゲートウェイ層のレート制限、フォールバック設計（AI開発・LLM導入支援）。
- IaC ガードレールと体制整備: Policy as Code・SCP・タグ運用を、パイプラインで強制する DevSecOps 体制 として整備。
- LLM セキュリティの準備度確認: 導入前後のリスクを棚卸し（LLMセキュリティ準備度診断）。
連載の関連回として、上限・テスト・監視が抜けるとどうなるかは 第 7 回（特商法・電子記録の法令対応）、第 19 回（テスト無しの回帰事故）、第 20 回（ログ・可観測性の欠如） でも扱っています。連載全体は 特集ハブ からたどれます。
まとめ
本記事の要点を 7 行でまとめます。
- Denial of Wallet (DoW) = サービスを止めずに従量課金とオートスケールを悪用して財務を枯渇させる概念。中堅企業では AI 生成コードの自爆 が現実の主因です (arXiv 2104.08031)。
- 暴走 6 パターン = Lambda 再帰 / S3 自己トリガ / 無制限オートスケール / リトライ嵐 / LLM トークン暴走 / dev 消し忘れ。
- AI で起きやすい理由 = 上限・タイムアウト・予算アラート・ライフサイクル・終了条件を 明示しないと書かれない から。
- AWS の標準ガードレール（Lambda 再帰検知・約 16 回で停止）は Lambda/SQS/SNS/S3 限定 であり万能ではありません (AWS 公式)。
- コードの良い例 = バケット分離 / 上限付き指数バックオフ + タイムアウト / ステップ・トークン上限。
- コストガードレール 7 種 = 予算アラート / 同時実行・スケール上限 / レート制限 / タイムアウト / dev-prod 分離 / タグ可視化 / IaC 強制。
- 30 分チェックリスト で今日から着手可能。予算アラート + 上限設定は「事後の保険」と「事前の天井」の両輪で張ります。
「サーバーレスだから安い」「クラウドが勝手にスケールする」――この油断こそが、AI 時代の中堅企業の高額請求リスクです。サービスが落ちていなくても、財布は静かに枯れていきます。
次回（連載第 17 回）は ハルシネーションされた依存パッケージと slopsquatting を取り上げ、AI が存在しないライブラリ名を提案し、攻撃者がその名前を先回りで登録する新種のサプライチェーン攻撃を整理します。
参考一次ソース
本記事の事実認定で参照した一次 / 公式ソース一覧です。
Denial of Wallet（学術）
- arXiv: Denial of Wallet — Defining a Looming Threat to Serverless Computing (2021)
- Oxford Academic / Journal of Cybersecurity: DoWNet — classification of Denial-of-Wallet attacks (2024)
- arXiv: A Comprehensive Review of Denial of Wallet Attacks in Serverless Architectures (2025)
AWS 公式（Lambda 再帰ループ検知）
- AWS Lambda: Use Lambda recursive loop detection to prevent infinite loops（公式ドキュメント）
- AWS Compute Blog: Detecting and stopping recursive loops in AWS Lambda functions
- AWS What's New: Lambda now detects and stops recursive loops between Lambda and Amazon S3 (2024-10)
- AWS Compute Blog: Avoiding recursive invocation with Amazon S3 and AWS Lambda
AWS 公式（コスト管理・請求）
- AWS Cost Management: Best practices for AWS Budgets
- AWS Cost Management: Managing your costs with AWS Budgets
- AWS Budgets / Cost Anomaly Detection（製品ページ）
- AWS Billing: Understanding unexpected charges
国内公的機関（クラウド・セキュリティ全般）
CWE（関連弱点）
- CWE-1265: Unintended Reentrant Invocation of Non-reentrant Code
- CWE-400: Uncontrolled Resource Consumption
- CWE-770: Allocation of Resources Without Limits or Throttling
「先月の請求、なんでこんなに高いの？」――原因が特定できないなら、暴走している可能性があります。
GXO は中堅企業（年商 30300 億・情シス 13 名）向けに、外部 CTO / セキュリティ顧問、AI 生成コードの脆弱性・コスト診断、運用ルール整備までを段階的に支援します。
※ 営業電話はしません | オンライン対応可 | 相談だけでもOK
著者: GXO株式会社 初回公開: 2026 年 6 月 9 日 最終更新: 2026 年 6 月 9 日 連載: バイブコーディング危機 第 16 回