Amazonの180万ドルClaudeコスト超過：AI支出の暴走を防ぐ方法

はじめに

アマゾンでAnthropicのClaude Sonnetを使用した社内プロジェクトが、180万ドルの請求額を積み上げ、計画予算を**860%**超過し、5ヶ月間発見されず、最終的に本番稼働に至らなかったと報じられています。

このタスク自体はごく普通に聞こえます。著者情報をアマゾンのEコマースプラットフォーム上の商品リストと照合するというものです。

この件は、アマゾンのシニアエンジニアが社内従業員会議でAI関連のコスト超過の複数の事例について議論した後、フィナンシャル・タイムズによって報じられました。これは、チャットボットを時折使用する段階から、毎日数千回から数百万回の有料モデル呼び出しを生成する可能性のある自動化ワークフローへ移行するあらゆる組織にとって有益な警告となります。

従来のソフトウェアの欠陥は、エンジニアリング時間の浪費や誤った出力の生成につながることがよくあります。一方、従量制のAIワークフローにおける欠陥は、その両方を引き起こす可能性があり、さらに稼働し続ける限り毎分トークン、ツール、ストレージ、計算コストを発生させ続けます。

教訓は、企業がAIの使用を止めるべきだということではなく、自律的または高容量のAIプロセスには、その安全性や品質管理と同様に明確な財務管理が必要であるということです。

アマゾン内部で何が起きたか

情報筋によると、アマゾンは著者情報を自社の小売プラットフォーム上の商品リストと照合することを目的としたプロジェクトでClaude Sonnetを使用しました。

報告によると、この導入は：

• 180万ドルの費用がかかった
• 割り当てられた予算を860%超過した
• 発見までに5ヶ月かかった
• 本番環境に到達しなかった

シニアエンジニアは、いくつかのAI関連のコーディングエラーを「壊滅的に高価」と表現しました。

アマゾンは、彼らは技術の使用方法（コスト効率の管理方法を含む）を実験し、学習し、改善していると回答しました。また、少数の孤立したケースを通常の慣行として提示することは、アマゾンの大規模組織全体でのAIの使用を正確に反映していないと述べました。

これらの両方の点が事実である可能性があります。

これらの出来事はアマゾンの一部の小規模チームにのみ関わるものかもしれませんが、同時に、他の組織が真剣に受け止めるべき管理上の問題を明らかにしています。

具体的なコーディング欠陥は開示されていない

当初の中国語報道では、超過の原因は呼び出し頻度制限のないプログラムが継続的にループ状にリクエストを送信したことにあるとされました。

この説明は合理的ですが、現在の公開報道では確認されていません。

フィナンシャル・タイムズは、コーディングエラー、脆弱な支出管理、検出の遅れについて説明しました。技術的な事後分析レポートは公開されておらず、以下は不明です：

• ソースコード
• 正確な欠陥
• そのプロセスが無限ループだったかどうか
• モデル呼び出し回数
• 入力または出力トークン数
• モデルが直接アクセスされたのか、Amazon Bedrock経由だったのか
• モデルバージョン
• ツール使用設定
• 費用を発生させたインフラコンポーネント

最も安全な結論はより慎重です：失敗したClaude Sonnetの導入が巨額の請求を生み出し、アマゾンの管理システムが5ヶ月間その問題を検出できなかったということです。

アマゾンが技術的事故報告書を公開しない限り、それ以上の詳細な説明は推測としてラベル付けされるべきです。

これは唯一のコスト問題ではない

コスト超過

同じ内部報告書では、少なくとも他に2つの事例が議論されたとされています。

物流のコスト超過は、2週間以上経ってから発見されたとされています。

これらの事例は180万ドルの著者照合プロジェクトより規模は小さいですが、同じパターンを指し示しています：技術的な障害がプロセスを強制的に停止させない限り、使用量ベースのAIシステムはコストを累積し続ける可能性があるということです。

従来のバッチジョブはクラッシュしたり、メモリを使い切ったり、テストに失敗したりする可能性があります。

一方、AIプロセスは技術的には健全でありながら、経済的には破綻している可能性があります。

プロジェクトが有用な結果を生成しなくなっても、APIレスポンスの成功を受け取り続け、ログを書き込み、ツールを呼び出し、タスクを再試行し、低価値のレコードを処理し続ける可能性があります。

AIコスト障害が異なる現れ方をする理由

従来のアプリケーションのコストは、通常比較的馴染みのある単位に結びついています：

• サーバー時間
• データベース容量
• ストレージ
• ネットワーク転送
• 人件費

一方、AIワークフローは複数の従量課金レイヤーを同時に追加する可能性があります：

• 入力トークン
• 出力トークン
• キャッシュおよび非キャッシュコンテキスト
• 推論トークン
• ツール呼び出し
• ウェブ検索
• コード実行セッション
• ベクター検索
• エージェントの再試行
• 並列ワーカープロセス
• 長い対話履歴
• クラウドコンピューティングリソース
• ログとストレージ出力

これにより乗数効果が生じます。

タスクが長いプロンプトを送信し、大量のレスポンスを生成し、2つのツールを呼び出し、エラー後に再試行し、完全な履歴を次のラウンドに渡すと仮定します。アプリケーションが数百万のレコードを処理する場合、小さな設計上の見落としが非常に高価になる可能性があります。

運用の観点からは、アプリケーションは異常に見えないかもしれません。リクエストは依然として200 OKを返します。ワーカープロセスはアクティブなままです。キューは減少し続けます。問題が最初に表面化するのは、しばしば請求書です。

AIワークフローのためのシンプルなコストモデル

自動化されたAIプロセスを開始する前に、完了したビジネスタスクごとのコストを見積もってください。

簡略化したモデルは以下の通りです：

重要な指標はトークンあたりのコストだけではありません。

重要なのは：

完了したビジネス成果あたりの総コスト

より安価なリクエストでも、失敗率が高く、繰り返し呼び出しが必要だったり、より多くの人的レビューを発生させたりする場合は、より高価なワークフローになる可能性があります。

同様に、より強力なモデルでも、より少ないステップでタスクを完了できれば、総コストが低くなる可能性があります。

最初の管理策：各AIタスクに財務責任者を指定する

各本番環境のAIワークフローには、技術的な動作と支出の両方に責任を持つ指名された担当者がいるべきです。

その担当者は以下を把握している必要があります：

• 予想されるビジネスボリューム
• 使用されるモデル
• 各予想コスト
• 日次および月次予算
• 単一実行の最大コスト
• 実行を停止する条件

ワークフロー

• アラートを受け取る担当者
• より高い限度額を承認するプロセス

ワーカーが継続的にリクエストを送信できる場合、曖昧なプロジェクトレベルの予算では不十分です。

予算は複数のレベルに存在するべきです：

より低いレベルが最も速く、最も効果的なブレーキメカニズムを提供します。

アプリケーション内にハードリミットを設定する

クラウドの請求アラートは重要ですが、アプリケーションレベルの管理の代わりにはなりません。

アプリケーションは設定された境界に達した時点で停止するか、承認を要求するべきです。

有用な制限には以下が含まれます：

• タスクごとの最大リクエスト数
• エージェントの最大ステップ数
• 最大再試行回数
• 最大入力トークン数
• 最大出力トークン数
• 最大コンテキスト長
• 最大ツール呼び出し回数
• 最大並列ワーカースレッド数
• 最大実行時間
• ジョブごとの最高ドルコスト
• レビュー前の最大処理レコード数

これらの管理はデフォルトでオフにすべきではありません。

コスト追跡サービスが利用できない場合、またはアプリケーションが残りの予算を決定できない場合、最も安全な動作は無期限に継続することではなく、一時停止することです。

エージェントに依存しない緊急停止スイッチを使用する

自律エージェントは、自身の最終的な支出権限を管理すべきではありません。

独立したサービスが以下を実行できるべきです：

• APIキーの無効化
• モデル呼び出しの拒否
• キューの一時停止
• ワーカーをゼロにスケールダウン
• 外部ツールのブロック
• ロールの取り消し
• スケジュールされたタスクの停止
• 再開前に人的承認を要求

エージェントが再試行ループに陥ったり、誤解を招くステータスメッセージを生成したりしても、緊急停止スイッチは利用可能な状態を維持すべきです。

本番環境の前にテストしてください。

使用されたことのない管理策は理論に過ぎません。

各モデル呼び出しを監視する

Amazon Bedrockを使用する組織は、サポートされているbedrock-runtime呼び出しに対してモデル呼び出しログを有効にできます。

AWSは、これらのログにリクエストとレスポンスデータ、メタデータ、モデル識別子、リクエスト識別子、ID情報、トークン使用量が含まれると述べています。ログの宛先には、Amazon CloudWatch LogsとAmazon S3が含まれます。

呼び出しログはデフォルトではオフです。

チームは、可観測性に必要なデータのみを有効化し、適切なプライバシー、セキュリティ、保持期間、およびマスキング制御を適用する必要があります。プロンプトと出力には、機密性の高い会社情報や顧客情報が含まれる可能性があります。

少なくとも、コスト監視レコードには以下を含める必要があります：

• タイムスタンプ
• アプリケーション
• 環境
• チームまたはコストセンター
• モデル
• ユーザーまたはテナント
• 入力トークン数
• 出力トークン数
• キャッシュ使用状況
• ツール呼び出し
• リトライ回数
• ジョブ識別子
• 推定リクエストコスト
• ビジネス結果
• エラーまたはエスカレーション理由

これにより、月次の財務レビューで巨大な総額を発見するのではなく、請求額を具体的なタスクに関連付けることができます。

AWS Budgetsを使用してBedrock上のClaude費用を追跡する

AWS Budgetsは、コストまたは使用量を設定したしきい値と比較して追跡し、通知を送信できます。予算アクションは、しきい値を超えた場合にIAMポリシーやサービスコントロールポリシーなどの制御を適用することもできます。構成に応じて、アクションは自動的に実行されるか、人間の承認を待つことができます。

見落とされがちな重要なAWS固有の詳細があります。

AWSコスト異常検出のドキュメントによると、このサービスはAWS Marketplaceを通じて販売されるサードパーティ製品を監視しません。これには、Amazon Bedrockを通じて提供されるAnthropic Claudeなどのサードパーティ製言語モデルが含まれます。

これらの費用は依然としてCost Explorerと請求書に表示されますが、AWSはこのような費用のアラートにはAWS Budgetsを使用することを推奨しています。

予算では、課金エンティティフィルターを使用して、Marketplace費用をより正確に追跡できます。

これはまさに、誤った安心感を生み出す可能性のある構成の詳細です。企業は異常検出を有効にしてすべてのモデル費用がカバーされていると考えるかもしれませんが、特定の請求カテゴリが含まれていない場合があります。

AWS Budgetsをリアルタイムのサーキットブレーカーとして使わない

AWSのドキュメントによると、予算ステータスは1日に数回更新されます。

また、ドキュメントでは、通知の送信前または送信後もコストが増加し続ける可能性があると警告しています。

これは、AWS Budgetsが財務ガバナンスには有用であるが、高スループットのエージェントを十分な速さで停止するには、単独では不十分である可能性があることを意味します。

制御スタックには以下を含める必要があります：

1. アプリケーション内のリクエストレベルのカウンター
2. ニアリアルタイムの使用量メトリクス
3. ジョブごとおよびセッションごとのハード上限
4. クラウド予算アラート
5. 適切な場合の自動化された予算アクション
6. 高リスクリリース時の毎日の財務レビュー

ワークフローがお金を使う速度が速いほど、制御は呼び出しポイントに近づける必要があります。

サービス対象範囲のコストには異常検出を使用

AWSコスト異常検出は、機械学習モデルを使用して異常な支出パターンを特定し、潜在的な根本原因の特定を支援します。

AWSによると、このサービスは処理された請求データを1日におよそ3回評価します。

AWSサービス、アカウント、リージョン、使用タイプ、およびコスト配分タグにおける予期しない増加を効果的に検出できます。

AIシステムの場合、コンピューティング、ストレージ、データベース、またはネットワークに関連するサポートコストの異常を特定する可能性があります。

ただし、チームは上記のMarketplaceの制限を覚えておき、必要に応じてサードパーティのモデル費用のために個別のAWS Budgetsを作成する必要があります。

Service Quotasを予算ではなくセキュリティ境界として使用

Amazon Bedrockは、モデル推論にサービス割り当てを適用します。これには、サポートされているモデルとエンドポイントに対するトークンベースの制限が含まれます。

割り当ては無制限のスループットを防ぐことができますが、正確な財務予算として設計されているわけではありません。

割り当ては、想定されるプロジェクト上限をはるかに超える支出を依然として許可する可能性があります。逆に、本番容量の問題を解決するために割り当てを引き上げると、意図せず有用なセキュリティ境界が取り除かれる可能性があります。

したがって、割り当ての変更には以下が必要です：

• ビジネス上の妥当性の説明
• 更新されたコスト予測
• 指名された承認者
• 更新されたアラートしきい値
• ロールバック計画
• トラフィック増加後のレビュー

レートとトークンの制限は、単なるスケーリングの障害ではなく、システムリスク設計の一部と見なされるべきです。

適切な場合はAnthropicの使用量とコストを直接追跡

Anthropicを直接呼び出すアプリケーションの場合、Anthropicコンソールはコストと使用状況のレポートを提供します。

AnthropicのAPI制限には、1分あたりのリクエスト数、1分あたりの入力トークン数、1分あたりの出力トークン数、および使用ティアに関連する支出制限が含まれる場合があります。

これらの制限は、制御されていないスループットを減らすことができますが、アプリケーションレイヤーの制御で補完する必要があります。

複数のチームを持つ組織は、アプリケーションとモデルプロバイダーの間にLLMゲートウェイを展開することもできます。ゲートウェイは、認証、使用状況追跡、予算、レート制限、モデルルーティング、監査ログを集中管理できます。

ゲートウェイは重要なセキュリティコンポーネントになるため、他の本番アクセスレイヤーと同じ慎重さで運用およびレビューする必要があります。

少数の代表的なサンプルから始める

報告によると、Amazonのプロジェクトでは大規模なデータマッチングタスクの実行が試みられたとされています。

より安全な展開パターンは次のとおりです：

1. 100件の代表的なレコードを実行する。
2. 精度とコストを測定する。
3. 1,000件のレコードを実行する。
4. エラーとトークン分布を確認する。
5. 最悪のケースの入力をテストする。
6. 停止制御を確認する。
7. 全量処理の支出を見積もる。
8. 完全なデータセットを処理する前に承認を要求する。

平均レコードだけから推定しないでください。

最も長いドキュメント、マッチングに失敗したレコード、曖昧なケース、リトライ、エージェントループが総コストを支配することがよくあります。

パーセンタイル推定値を使用します。たとえば、タスクごとのP50、P95、P99コストなどです。

有効な結果ごとに最大コスト上限を設定

追加のモデル呼び出しが経済的に合理的でなくなった場合、ワークフローは停止する必要があります。

著者マッチングシステムの場合、有用な指標には以下が含まれます：

• 著者のマッチング成功ごとのコスト
• 人間によるレビューが必要なレコードごとのコスト
• 自動的に解決されたレコードの割合
• 誤マッチ率
• 誤マッチのコスト
• 手動処理と比較した節約額
• 受け入れられた結果ごとに必要なモデル呼び出し回数

1リクエストあたり0.02ドルかかるプロセスは安価に見えるかもしれません。

50回の呼び出しを必要とし、レコードの半分が失敗し、残りが人間のレビューに回される場合、実際の経済性は悪い可能性があります。

単純なタスクをより安価な方法にルーティングする

すべてのレコードに最先端のモデルが必要なわけではありません。

コスト意識の高いパイプラインでは、以下を使用できます：

1. 完全一致
2. データベース結合
3. ルール
4. 埋め込み類似度
5. より小さいモデル
6. 曖昧な場合にのみ強力なモデルを使用
7. 高リスクの決定に対する人間によるレビュー

データマッチングプロジェクトでは、従来のソフトウェアがほとんどのケースをより低コストかつ決定論的に解決できる可能性があります。

LLMは、言語の曖昧さが実際に必要とする場合にのみ使用し、すべての行に自動的に適用するべきではありません。

Anthropic自身の価格設定ガイダンスでは、適切なモデルの選択、繰り返しコンテキストに対するプロンプトキャッシュの使用、緊急でない作業に対するバッチ処理、使用パターンの監視を推奨しています。

無制限のリトライを防ぐ

リトライは、暗黙の支出の一般的な原因です。

失敗したリクエストは、アプリケーション、キューシステム、SDK、ゲートウェイ、ワーカーマネージャー、エージェント、またはワークフローオーケストレーターによって再試行される可能性があります。

複数のレイヤーが独立してリトライする場合、1つの論理タスクが複数の有料リクエストを生成する可能性があります。

統一されたリトライ戦略を定義し、以下を含めます：

• 少なめの最大試行回数
• 指数バックオフ
• ジッター
• 再試行不可エラーに対する明確な処理
• 冪等性
• デッドレターキュー
• 繰り返しの失敗に対するアラート
• リトライ回数を含む、関連するすべてのコストを含むタスクごとの予算

エラーは無限の経済的ループを引き起こすべきではありません。

開発環境と本番環境の認証情報を分離

テストスクリプトは本番レベルの制限を継承すべきではありません。

独立したアカウントまたはワークスペース、APIキー、IAMロール、予算、割り当て、ログ、データソース、およびネットワーク権限を使用します。

開発環境には意図的に低い支出上限を設定します。

ループに入ってしまったプロトタイプは、エンタープライズレベルの本番割り当てを得るのではなく、少額の請求で失敗するべきです。

AI生成コードを本番金融インフラをレビューするようにレビューする

このインシデントにはAI支援で作成されたプロジェクトが関与していましたが、重要な問題はコードがモデルによって生成されたかどうかではありません。

重要な問題は、コードがお金を費やす可能性があるかどうかです。

有料のモデルリクエストを開始できるコンポーネントはすべて、以下のレビューを受ける必要があります：

• ループ終了
• リトライ動作
• 並行性
• キュースケーリング
• 最大コンテキスト
• ツール呼び出し制限
• タイムアウト処理
• キャンセルメカニズム
• コスト帰属
• エラーパス
• ロギング
• 予算執行
• 緊急停止動作

単体テストには、経済的な失敗シナリオを含める必要があります。

例としては、モデルが有効な回答を決して返さない、タスクが繰り返し配信される、有料呼び出し後にワーカープロセスがクラッシュする、レート制限エラーが繰り返し発生する、ターンごとにツール出力がコンテキストを増大させ続ける、コスト見積もりサービスが利用できない、などがあります。

機能的に正しい通常パスだけでは十分ではありません。

本番レベルのAIコスト制御チェックリスト

所有権と計画

• 支出責任を持つ指定されたテクニカルリーダーがいる。

• 成功した結果ごとの期待される使用量とコストが文書化されている。

[ ] 開発環境、ステージング環境、本番環境にはそれぞれ独立した予算がある。

• フル規模の処理には明確な承認が必要である。

アプリケーション制御

• 各タスクには、最大リクエスト数、トークン数、ステップ数、再試行回数、所要時間の上限がある。

• 各エージェントセッションには、米ドル建ての予算がある。

• エージェント以外のサービスがワークフローを停止できる。

• 残りの予算を読み取れない場合は、タスクを一時停止する。

• 冪等性により、重複作業を防止する。

モニタリング

• 各モデル呼び出しは、チーム、プロジェクト、ユーザー、タスクに帰属する。

• 入力、出力、キャッシュ、ツール、再試行の使用状況を記録する。

• 支出速度と総支出の両方にアラートを設定する。

• 最初の本番稼働期間中は、毎日レビューを有効にする。

• チームは異常検知の対象外となる費用項目を把握している。

品質と経済性

• 成功したビジネス成果ごとにコストを測定する。

• 適切な場合は、通常のコードとより小規模なモデルを使用する。

• 最悪ケースと高パーセンタイルのコストをテスト済みである。

• 人的レビューコストを含める。

• 追加の呼び出しに価値がなくなった時点で、ワークフローを停止する。

ガバナンス

• AI が生成したコードは人間によるレビューを受ける。

• 予算と割り当ての増額には承認が必要である。

• 緊急停止スイッチはテスト済みである。

• インシデント対応には、財務関係者と技術関係者が関与する。

• チームは、主要なモデルまたはプロンプトの変更ごとに支出をレビューする。

アマゾンの対応から得られる教訓

報道によると、アマゾンのエンジニアは将来の AI プロジェクト向けに自動化されたガードレールを構築している。

これは正しい方向性である。

しかし、自動化は複数の層に存在する必要がある。

成熟した制御システムは、アプリケーションのハードリミット、モデルとゲートウェイのクォータ、クラウド予算、自動化アクション、使用ログ、財務ダッシュボード、人間による承認、定期的なレビューを組み合わせるべきである。

同社は以前、従業員に Kiro 開発ツールの使用を最大化するよう促す社内リーダーボードも撤去した。フィナンシャル・タイムズ紙によると、このリーダーボードは「トークンマキシング」現象を助長した。これは従業員がトークン消費量を増やしてランキングを上げるというものである。

これは、インセンティブがコスト管理を損なう可能性があるという有益な注意喚起である。

測定可能なビジネス価値を生み出すのではなく、AI をより多く使うことで従業員が報酬を得るならば、成果が改善しなくても使用量は増加する。

組織は、解決した問題、品質の向上、節約した時間、生み出した収益、低減したリスク、単位産出あたりのコスト削減に報いるべきである。

トークン数は入力指標であり、生産性指標ではない。

よくある質問

Amazon は本当に Claude Sonnet に 180 万ドルを費やしたのか？

フィナンシャル・タイムズ紙は、Amazon 社内で Claude Sonnet を使用したプロジェクトが累計 180 万ドルの請求を発生させたと報じた。このプロジェクトは著者情報を EC リストと照合することを目的としており、予算を 860% 超過し、本番稼働に至らなかった。

コスト超過がなぜ 5 か月間も発見されなかったのか？

公開された報道によると、Amazon には十分な支出管理がなく、コーディングエラーが問題の一因であったとされる。Amazon は具体的な欠陥やモニタリングの失敗を特定する技術的な事後分析レポートを公開していない。

問題は無限 AI ループによって引き起こされたのか？

この説明は一部の二次報道に登場するが、主要報道では確認されていない。正確なリクエスト数、再試行ロジック、トークン量、ソースコードの欠陥は明らかにされていない。

Amazon には他にも AI コスト超過の事例があるのか？

ある。同じ社内プレゼンテーションには、約 54 万 1,000 ドルの財務監査プロジェクトの予期せぬコストと、13 万 4,000 ドルの物流プロジェクトのコストも含まれていたとされる。

AWS Cost Anomaly Detection は Amazon Bedrock 上の Claude の費用を監視できるのか？

AWS のドキュメントによると、Cost Anomaly Detection は、Bedrock 上の Anthropic Claude モデルを含むサードパーティの AWS Marketplace 製品を監視しない。AWS はこれらの費用を管理するために AWS Budgets を使用し、必要に応じて請求エンティティフィルターを使用することを推奨している。

AWS Budgets は暴走する AI 支出を即座に阻止できるのか？

それだけではできない。AWS は予算情報が 1 日に数回更新され、通知期間の前後にコストが増加し続ける可能性があると述べている。高トラフィックのアプリケーションには、リクエストレベルのハードリミットと独立した緊急停止スイッチが必要である。

レート制限は支出制限と同じか？

異なる。レート制限はスループットを制御し、予算制御は許容コストを管理する。ワークフローはレート制限内で動作しながらも、数週間から数か月で計画支出を大幅に超過する可能性がある。

AI エージェントにとって最も重要な制御手段は何か？

各エージェントセッションに、リクエスト、トークン、ツール、再試行、時間を含むハード予算を設定すること。エージェントの外部でその予算を強制し、テスト済みの方法でワークフローを即座に停止できるようにすること。

関連ツール

• AWS Budgets：コストと使用量をしきい値と比較して追跡し、通知や設定済みの予算アクションをトリガーする。
• AWS Cost Anomaly Detection：サポートされている課金カテゴリにおける異常な AWS 支出パターンを検出する。
• AWS Cost Explorer：チームが AWS サービスおよび課金ディメンションにわたる履歴コストと使用量を分析するのに役立つ。
• Amazon Bedrock モデル呼び出しログ：CloudWatch Logs または Amazon S3 に、サポートされているモデルの呼び出しと関連メタデータを記録する。
• Amazon Bedrock サービス割り当て：推論スループットを制限する可能性のあるモデルとエンドポイントの制限を表示する。
• Anthropic Console：API キー、使用量レポート、コストレポート、ワークスペース、アカウントレベルの制御を提供し、直接の Anthropic API 使用を管理する。

関連リンク

• フィナンシャル・タイムズ：アマゾンの AI 支出超過：180 万ドルのプロジェクトと追加の社内コスト超過に関する主要報道。
• AWS Budgets ドキュメント：予算に基づいて AWS コストと使用量を追跡するための公式ガイド。
• AWS Budget Actions：しきい値超過時に自動実行または人による承認が必要なアクションについて説明する。
• AWS Cost Anomaly Detection の制限：異常モニタリングと、サードパーティ Marketplace モデル料金の除外について記載。
• [Amazon Bedrock 呼び出しログ](https://docs.aws.amazon.

com/bedrock/latest/userguide/model-invocation-logging.html)：Bedrock 呼び出しログの公式設定およびデータ処理ガイドです。

• Anthropic 成本和用量報告：Anthropic コンソールにおけるコスト、使用量、トークン、モデル、ワークスペース、およびレート制限レポートについて説明しています。
• Anthropic API 速率限制：リクエスト数、入力トークン、出力トークン、および使用量階層の制限について説明しています。

まとめ

報告によると、Claude Sonnet を使用した社内アマゾンプロジェクトでは180万ドルの費用が発生し、予算を860%超過しましたが、5か月間発見されず、一度も稼働することはありませんでした。他の AI プロジェクトでも、数十万ドル単位の予期しない支出が発生したと報告されています。

公開記録では、主な事象が無限リクエストループによるものであることは確認されていません。記録が裏付けているのは、AI ワークフローの支出速度と、組織が問題を検知する速度との間にギャップがあるということです。

企業は、単一リクエストの追跡、ジョブレベルの予算、トークンおよびツールの制限、制御された再試行、モデルルーティング、クラウド予算、自動化アクション、そしてエージェントが上書きできない緊急停止スイッチを組み合わせるべきです。

**

最も安全なルールはシンプルです。いかなる AI プロセスも、依然として有用であり、予算内であり、継続が承認されていることを繰り返し証明することなく、5か月間稼働し続けるべきではありません。