【ITニュース解説】The $500M Bill Was Always Going to Happen

2023年7月、あるクラウドサービスで非常に大きな請求額が表示されるバグが発生した。これは、通常1ドル程度の月額料金が数十億ドル、あるいは数兆ドルと表示されるという異常な事態だった。幸いにも、これはデータ単位の変換ミスや小数点の位置の間違いによる表示上のバグであり、実際に課金されることはなく、クラウドベンダーによって一日以内に修正された。

しかし、この数時間の間に、多くのエンジニアは信じられないような数字を前にしてパニックに陥り、表示が正常に戻ることを期待して何度も画面を更新した。中には、クラウドベンダーがディスプレイのバグだと確認する前に、慌てて自分たちのシステムやサーバーを削除し始める者もいた。

このように現実離れした高額な数字は、金銭的な損失だけでなく、会社が存続できるのかどうかといった深刻な不安を引き起こす。

この事例は表示バグだったが、もしこの高額な請求が現実のものだったとしたらどうだろうか。これは、AIを活用したコーディングツールの利用費用が暴走する可能性を示唆している。

このような高額な請求が発生するのは、小数点の入力ミスのような単純な間違いが原因ではない。多くの場合、費用を制御するための仕組みが「利用可能」な状態にはあるものの、誰もそれを有効にしていないために、想定外の費用が発生してしまうからである。

クラウドベンダーのバグであれば、ベンダー側が迅速に修正する。しかし、もしAIツールの利用費が数億ドルに達したとしても、それはシステムが正常に動作した結果であり、誰も修正してくれるわけではない。システムは、そのような高額な費用が発生するように設計されているのだから、これはバグではなく「機能」と見なされる。

現在のAIコーディングにおけるコスト管理の現状は、このような状況にある。「コントロールが利用可能」なだけで、それが費用を強制的に停止させることはない。

ほとんどの予算管理ツールは、設定した上限に達しても、実際に利用を停止するわけではない。その代わりに、チャットツールに通知が届いたり、管理画面に警告が表示されたり、月間予算の80%を超過したというメールが届いたりするだけである。

しかし、その間もAIへのリクエスト（トークン）は流れ続け、利用は止まらない。これは、火災を検知して報告するだけの「煙探知機」のようなものであり、火災そのものを止める「消火器」ではない。警告は、費用が設定ラインを超えたことを知らせるだけで、何かが起きた後に報告するだけである。

重要なのは、警告と「上限（キャップ）」は全く異なる機能だという点だ。上限（キャップ）は、設定したラインで確実に利用を停止させる。この違いは、セキュリティチームが脆弱性の情報を得るだけでは実際の侵害を防げないことを経験から学んだのと似ている。情報があることと、強制力があることは同じではない。脆弱性スキャナーが、単なる現状把握のツールなのに「防御策」として扱われるのと同じ間違いを、予算管理ツールが犯しているのだ。

ベンダーは通知機能を提供することを好む。なぜなら、通知機能は見栄えが良く、責任を利用者側に転嫁できるからだ。しかし、通知にはリクエストの実行を停止させる権限がない。例えば、150人のエンジニアが一日中AIエージェントを使用した場合、「予算の80%に達しました」という通知が来てから、実際に予算を超過するまでの時間は、人間が通知に反応して対応できるよりもはるかに短い。通知は予定通りに発せられたとしても、その時点で既に費用は大きく発生している可能性がある。

これが、5億ドルの高額請求が繰り返し発生する実態である。

主要なAIコーディングツールが、この問題にどう対応しているかを見てみよう。 例えば、Copilotにはガバナンスの管理画面があるが、利用停止機能はデフォルトで無効になっている。予算は警告として機能し、明示的に設定しない限り強制力を持たない。従量課金はデフォルトで有効で、未使用のクレジットは毎月失効する。デモンストレーションでは上限があるように見えるが、実際の運用では超過を監視する速度計のようなものだ。

Claude Codeでは、ユーザーごとの利用料はクレジットを有効にしないと課金されない。また、リアルタイムでのユーザー別費用帰属機能もない。どのエンジニアが、どのAPIキーが、現在予算を消費しているのかを知るには、自分たちで監視システムを構築する必要がある。費用暴走を防ぐための仕組みは「利用可能」だったが、強制されていなかったのである。

Cursorでは利用状況の分析は可能だが、費用に直接結びつく情報は得られない。請求は遅れて発生するため、設計上、明確な上限は存在せず、損害が発生した後に請求書が届くだけだ。そして、本格的なコストガバナンス機能は最上位のエンタープライズプランでのみ提供されるため、最も予算超過しやすいチームほど、その安全策を利用できない状態にある。

これらのベンダーは皆、ガバナンス機能が「利用可能」だと胸を張って言える。しかし、その強制力のある部分が、利用者側での設定や、上位プランへのアップグレードによってのみ得られるようになっているため、結果的にベンダーは恩恵を受けている。

では、「強制力のあるガバナンス」とは具体的に何を意味するのだろうか。最低限、以下の二つの要素が必要である。

一つ目は、**あらゆるレベルでの確実な予算上限（ハードキャップ）**である。ユーザー、チーム、APIキー、組織といった各階層で、単なる通知ではなく、設定された予算を超えたら利用を強制的に停止させる機能だ。 「強制する」とは、例えば、AIへのリクエストがシステムの中継点（プロキシ）を通過する際に、そのリクエストが予算内であるかをチェックし、もし予算を超過していれば、そのリクエストは実行されずに拒否される（HTTP 429エラーが返される）。これにより、AIの処理に費用がかかる「トークン」が消費されることはなく、費用はそこで確実に停止する。これが本当の「キャップ」である。 この上限は階層的に適用される。組織全体の予算が最上位にあり、その下にチーム、ユーザー、APIキーごとの上限が設定される。最も厳しい上限が優先され、例えば特定のAIモデルの利用に厳しい制限が設けられていれば、それが上位の予算設定よりも優先して適用される。これにより、自動化されたシステムが、誰も気づかないうちに組織全体の予算を使い果たしてしまうような事態を防ぐことができる。

二つ目は、リアルタイムでのユーザー別コスト帰属である。現在、どのユーザーが、どのチームが、どのAPIキーが、どの組織が、いくら費用を使っているのかを、即座に確認できるべきである。翌週になってログから情報を再構築するようなものであってはならない。 これは、後からダッシュボードを追加するのではなく、システムが根本的にそのように設計されているからこそ実現できる。AIへのリクエストがプロキシを通過する際に、利用されたAIモデルと実際のトークン数に基づいて費用が計算される。チームごとの可視性を得るには、リクエストにチームの識別子（ヘッダー）を付与するだけで、そのチームの費用が自動的に表示される。特別な管理設定や登録は不要で、エンジニアが普段使っているツールを通じて機能する。

この二つの要素、すなわちリアルタイムでのユーザー別コスト帰属とハード予算上限を組み合わせることで、単なる監視ダッシュボードではなく、真に管理されたAIコーディングプラットフォームが実現できる。

ここで一つの誤解を解消したい。「管理されている」とは、ガバナンス機能が最初から自動で有効になっているという意味ではない。予算上限は、サービスに登録した瞬間に有効になるわけではない。それらは初日から利用可能であり、他のシステム設定と同様に、信頼して利用する前に設定を有効にする必要がある。この違いは非常に重要である。なぜなら、「デフォルトでガバナンスが有効」と過剰に宣伝するツールほど、顧客が予期せぬ高額請求に直面するケースが多いからだ。

筆者たちのチームが開発したAIツールの事例が、その効果を証明している。筆者たちの会社では、150人のエンジニアがこのシステムを利用し、毎月約360億トークンものAI処理を行っている。これは、単なる性能測定ではなく、実際の業務利用に基づいた数字である。このシステムを利用することで、最先端のAIモデルを単独で利用した場合と比較して、同じエンジニアが同じ品質の作業を行いながら、費用を12分の1に抑えることができた。

この費用削減は、単に安価なAIモデルに切り替えたからでも、AIの出力品質をこっそり低下させたからでもない。これは、賢いリクエストの経路選択と、本当に機能するガバナンスを組み合わせた結果である。上限を強制し、リアルタイムでの費用帰属を可能にすることで、通常の月間費用を大幅に膨らませ、会社の経営問題に発展させてしまうような「暴走する利用」を確実に止めることができたのだ。

費用ガバナンスは、開発者の作業を遅らせるものだと誤解されがちだが、そうではない。そのように捉えてしまうと、誤った管理策を導入し、かえってエンジニアの生産性を損なう結果になる。 開発者は予算管理画面には関心がない。彼らが重視するのは、AIエージェントが実際の業務で信頼できるほど十分に優れているかどうかであり、これは譲れない条件である。AIエージェントが本当に役立たなければ、他のどんな機能も意味がない。

費用ガバナンスは全く別の問題である。 それは開発者の問題ではなく、ツールを導入する会社の責任である。この役割分担は明確である。エンジニアには最高のAIエージェントを使わせ、会社は請求額を確実に管理する。この二つの目標は、本来、対立するものではなかった。これらが対立するように見えたのは、既存のツールが費用管理の強制力を高価な選択肢にしたり、オプションにしたりしたため、開発者の体験を犠牲にして費用を削減するしか方法がなかったからである。組織、チーム、APIキー、ユーザーレベルで強制力のある上限を設定すれば、エンジニアがその存在に気づくことなく、請求書を管理できる。

AWSで発生した高額請求はバグだったが、AIコーディングツールの法外な請求は、設計段階から意図的に放置され、設定されていないために、いずれ会社の危機を引き起こす可能性がある「機能」として存在している。

したがって、もし今期AIコーディングツールを選ぶのであれば、ベンダーに一つの質問をし、明確な答えを求めるべきだ。それは、「あるチームが予算に達したとき、利用は実際に停止するのか、それとも後になってその旨が通知されるだけなのか」である。これ以外の詳細な機能は、その後の問題に過ぎない。

重要なのは、単なる通知ではなく、強制力を持つ上限設定である。そして、自分で構築する必要のないリアルタイムの費用帰属機能。これらが揃って初めて、エンジニアが実際に活用できる最高のAIエージェントと、会社が確実に管理できる請求書の両立が実現するのだ。