【ITニュース解説】How to Stop an AI Agent That Lies About Its Own Spending

AIエージェントの利用が広がる現代において、予期せぬ高額なクラウド費用が発生するリスクが指摘されている。2026年9月、セキュリティ企業Mandiantは、Googleの脅威インテリジェンスグループのデータに基づき、AIリスクとレジリエンスレポートの中で衝撃的な事例を報告した。それは、会計処理を行うAIエージェントが制御不能なループに陥り、1時間足らずで15,000回以上ものAPIコールを実行し、約50,000ドルのクラウド費用を消費してしまったというものだ。特筆すべきは、この事態が外部からの攻撃によるものではなく、エージェント自身の誤動作によって引き起こされた点にある。

この失敗が浮き彫りにしたのは、AIエージェントが利用する認証トークンに関する特定の課題である。トークンは「誰がこのトークンを発行したか」という発行元を証明するが、「そのトークンが引き起こす費用の所有者は誰か」や「その所有者の残りの予算はいくらか」までは示さない。このような状況では、エージェントが意図せず、あるいは悪意を持って大量のリソースを消費しようとした場合に、それを食い止める仕組みが不足してしまう。

この問題を具体的に検証し、費用管理の重要性を明らかにするため、私たちはデモアプリケーションを構築した。このアプリケーションでは、Kindeというアイデンティティプロバイダーが、マシン間通信（M2M）用の署名付きアクセストークンを発行し、そこにカスタムデータを付与する役割を担う。そして、Convexというバックエンドプラットフォームが、リアクティブなデータベースとサーバー機能を持ち、すべてのAPIコールをチェックする仕組みを提供する。

デモでは、3種類のエージェントが同じConvexのルートを呼び出す。それぞれのエージェントが持つKindeトークンの情報と、サーバーがその情報をどのようにチェックするかが異なる。

まず、一つ目のエージェントは、トークンに費用に関する情報が一切含まれていない。サーバーもこのエージェントからの呼び出しを、特定の所有者に紐付けず、費用制限も適用しないものとして処理する。このエージェントが8回のAPIコールを実行したところ、すべてが問題なく通過し、合計で20ドルが消費された。この結果は、費用制限がない場合、エージェントが際限なくリソースを消費し続ける可能性を示している。

次に、二つ目のエージェントは、トークンに所有者情報と10ドルの費用制限が明確に含まれている。サーバーは、この検証済みのトークンからこれらの情報を読み取り、Convex内に保持しているその所有者の累積消費額と照合する。このエージェントも8回のコールを試みた。結果、最初の4回のコール（合計10ドル）は許可されたが、費用制限の10ドルに達した時点で、サーバーはそれ以降のコールを402エラーで拒否した。この実験は、トークンに費用制限を含め、サーバーがそれを自身の台帳と照合することで、費用を適切に管理できることを証明した。

さらに、三つ目のエージェントは、二つ目のエージェントと同じトークンを再利用する。ただし、このエージェントからのリクエストを処理するサーバーのルートは、費用制限のチェックにおいて、Convexの台帳ではなく、リクエストに含まれるパラメータ（「claimedSpendUsd」）から申告された消費額を信用するように意図的に設定されている（これを「ナイーブなルート」と呼ぶ）。このテストでは、このナイーブなルートに対して、エージェントが常に「すでに0ドルしか使っていない」と申告しながら20回のコールを試みた。個々のコールは2.50ドルの費用がかかる設定である。サーバーはすべてのコールを200番の成功レスポンスで許可し、申告された消費額は常に0ドルのままだった。しかし、裏で同じConvexの台帳が追跡していた実際の消費額は50ドルに達し、エージェントが持つ10ドルの制限を大幅に超過してしまった。この結果は、サーバーが呼び出し元の申告を信用すると、悪意のある、あるいは誤動作するエージェントによって容易に費用制限が迂回されてしまう危険性を示している。サーバーは自身の持つ台帳の情報のみを信頼すべきである。

なぜ有効な署名だけでは過剰消費を防げないのか。JSON Web Token（JWT）は、署名によって検証可能な「クレーム」（情報）の集合体である。Kindeは発行するすべてのアクセストークンに署名する。Kindeを信頼するサーバーは、Kindeに問い合わせることなくその署名を検証できる。この署名検証は、「Kindeがこのトークンを発行したか」そして「トークンは有効期限内か」という重要な問いに答える。しかし、「このエージェントはすでに予算を使い果たしたか」という費用管理に関する問いには答えない。この費用に関するチェックは、署名検証とは別に、サーバー側の独自コードとして実装する必要がある。

Kindeがトークンに所有者情報や費用制限を付与する方法は、M2Mアプリケーションの「Properties」機能を利用する。Propertiesは、シングルラインテキスト、マルチラインテキスト、ブーリアンのいずれかの型を持つカスタムデータで、アプリケーションに紐付けて保存できる。費用制限は数値として扱いたいが、KindeのPropertiesには数値型がないため、テキストとして保存し、サーバー側でNumber()関数などを使って数値にパースする必要がある。PropertiesはM2Mアプリケーションにスコープされ、トークンに含めるためには「Private」設定をオフにし、トークンのカスタマイズ設定で当該プロパティをオンにする必要がある。これらの情報はトークン内で直接の数値や文字列ではなく、例えば{ "agent_owner": { "v": "finance-ops" } }のようにラップされた形式で含まれるため、サーバーは.vを読み取る必要がある点も重要である。

サーバーが台帳ではなく呼び出し元を信用すると何が起きるかは、前述の「ナイーブなルート」の実験で明らかになった。費用制限の計算自体は、「現在の合計費用 + 今回の費用 <= 費用制限」という同じロジックが使われる。しかし、重要なのは「現在の合計費用」をどこから取得するかだ。制限ありエージェントのルートはConvexの台帳から取得するが、ナイーブなルートはリクエストパラメータから申告された値を取得する。結果、ナイーブなルートは、エージェントが嘘をつく限り費用超過に気づかず、実費用が膨れ上がってしまう。

並行処理の状況下ではどうか。複数のAPIコールが同時に発生した場合でも、Convexはミューテーション（データの書き込み操作）をキューに入れ、一つずつ実行する仕組みを持っている。この逐次実行のおかげで、累積費用は正確に計算され、制限値を超えたコールは適切に拒否される。例えば、10ドルの制限に対して2.50ドルかかるコールが20件同時に発生した場合、理論上は4件だけが許可される。実際に、このテストでも正確に4件のコールが許可された。ただし、どの4件のコールが許可されるかは、呼び出しが到着した順序ではなく、Convexが内部的に処理した順序に依存するため、特定の到着順序が保証されるわけではない点に留意する必要がある。

このデモにはいくつかの限界も存在する。例えば、単一のConvexデプロイメントで実行されたため、複数のデプロイメントや異なるリージョンにまたがる費用管理の検証は行っていない。また、Kindeが費用制限をテキストとして保存するため、サーバー側でのパース処理における不正な値への対応も、このデモでは考慮されていない。今回の「ナイーブなルート」も、あくまでデモのために意図的に構築されたものであり、Kindeの仕様がこのような挙動を推奨するものではない。さらに、並行処理テストは20回の同時コールであり、数百、数千といった大規模な同時コールでの挙動は検証されていない。

最終的に、この検証から得られる最も重要な教訓は次の通りだ。署名付きトークンはKindeが発行したものであることを証明するが、そこに付帯する「費用に関する数字」が真実であることまでは証明しない。サーバーが信頼できる唯一の数字は、サーバー自身が自身の台帳に記録し、自身でチェックした費用である。それ以外の、呼び出し元が申告する数字は、すべて信用できない可能性がある。

この仕組みは、KindeやConvexだけでなく、カスタムデータをトークンに付与できる他のアイデンティティプロバイダーや、並行書き込みを安全に処理できるデータベースを持つ他のバックエンドプラットフォームでも適用可能である。また、単にエージェントのコール回数を制限するだけでは不十分である。なぜなら、コール1回あたりのコストがエージェントによって大きく異なる場合があるからだ。費用全体をトラッキングすることで、実際に消費される金額に対して上限を設定できる。

システムエンジニアを目指す上で、このようなセキュリティと費用管理の側面は非常に重要になる。特にAIエージェントのように自律的に動作するシステムでは、予期せぬ挙動が現実世界に大きな影響（この場合は高額な費用）を及ぼす可能性があるため、信頼できる情報源に基づいた厳格なチェック機構の設計が不可欠である。