【ITニュース解説】Your bugs used to burn CPU. Now they burn money.

ソフトウェア開発において、プログラムの不具合（バグ）は避けられない要素だ。従来のシステムでは、例えば無限ループなどのバグが発生すると、コンピューターのCPU（中央演算処理装置）が過剰に使用され、システムが一時的に遅延したり停止したりすることが多かった。これは通常、担当者がすぐに検知し対処するため、その日の業務が少し滞る程度のコストで済むことが多かった。

しかし、大規模言語モデル（LLM）のようなAI技術を組み込んだシステムでは、バグの影響が根本的に異なる。AIシステムでは、LLMへの問い合わせやデータ処理のたびに外部のAPI（アプリケーション・プログラミング・インターフェース）が呼び出され、その回数や処理量に応じて料金が発生する課金モデルが一般的である。そのため、不具合のある処理が繰り返されると、それがすべて有料のAPIコールとなり、気づかないうちに金銭的なコストが膨大になる危険性がある。これはバグがCPUを消費するだけでなく、直接的にお金を消費する状況だと言える。

LLMを利用した機能は、チュートリアルでは一度の呼び出しと応答で完結する単純なものに見えるかもしれない。しかし、実際に製品として運用されるシステムでは、より複雑な処理が伴う。例えば、求める結果が得られない場合の再試行（リトライ）、モデルの出力内容を修正させる自己修正ステップ、あるいはエージェントと呼ばれるプログラムが複数のツールやモデルを連携して呼び出すといったプロセスが含まれる。これら多段階の処理が、多数のユーザーから同時に実行されると、一つ一つの処理が課金の対象となり、コストが想定以上に増大する可能性がある。

AIシステムにおいて、コストが予期せず膨らむ主要な失敗パターンは三つ挙げられる。

一つ目は、「収束しない自己修正ループ」だ。これは、プログラムが自身の出力ミスを検知し、それを修正しようとするループ処理が無限に継続してしまう状況を指す。具体的な例として、AIエージェントが特定の形式のデータ（例えばJSON）を生成し、そのデータが正しい形式であるか検証するケースを考える。もし検証に失敗した場合、エージェントはエラー情報をモデルに送り、修正を依頼する。このプロセスは通常であれば有効だが、仮にシステムのデータ形式定義（スキーマ）が変更され、モデルがいくら修正を試みても満たせない条件になってしまった場合、モデルは修正を繰り返すが、バリデーターはそれを拒否し続けるという無限ループが発生する。この時、システムはクラッシュせず、エラーアラートも発生しないため、異常に気づかないまま課金だけが進んでしまう。この問題への対策として、すべての再試行や自己修正のループ処理に明確な上限を設けることが不可欠だ。具体的には、試行回数や、モデルが消費するトークン（LLMがテキストを処理する際の最小単位で、課金の基準となる）の総量に上限を設定する。そして、この上限に達した場合は、そこでループを強制終了させ、「失敗」としてシステムログに記録し、担当者に通知する仕組みが必要である。黙って処理を続けるのではなく、明確な失敗として扱うことが重要となる。これは、エージェントがツールやモデルを呼び出す際にも同様に適用すべきで、タスクごとの呼び出し回数にも上限を設けるべきだ。

二つ目は、「トラフィックの増加とコストの非線形な関係」である。従来のシステムでは、アクセス数の急増（トラフィック増）はサーバーの計算資源（コンピューティングリソース）の増加で対応できることが多く、コストが急激に跳ね上がることは少なかった。しかしAIシステムでは、一回のユーザー操作が内部で複数のモデル呼び出し（例えば、テキストの要約、分類、埋め込み生成など）をトリガーすることがあり、リクエスト一つあたりのコストはこれら全てのAPIコールの合計となる。ユーザー数が倍になれば、各モデル呼び出しも倍になり、リトライ処理なども加われば、コストは単純な比例関係以上に膨れ上がる。この問題の対策は、「リクエストあたりのコスト」を正確に把握することだ。システム開発者は通常、リクエストあたりの応答時間（レイテンシー）を厳密に管理するが、同様に、各機能がどれだけの費用を消費しているかを明確にすべきである。そして、機能ごとに予算を設定し、その予算を超過した場合の対応策を事前に決めておく。例えば、より安価な性能のモデルへの切り替え、AIが処理するテキストの短縮、以前の処理結果のキャッシュ利用、あるいはAIによる出力自体の一時停止など、柔軟な対応策を計画しておくことが重要だ。

三つ目は、「ユーザーごとの利用制限がない」ことだ。システム全体の利用量を制限する「グローバルレートリミット」は、AIサービスのプロバイダーから割り当てられた利用枠の超過を防ぐが、特定のユーザーが全体の利用枠の大部分を独占的に消費してしまう事態は防げない。例えば、ユーザーごとの利用回数制限がないチャット機能があったとする。この時、誤って本番環境に接続されたテストスクリプトが、週末を通して無限ループでリクエストを送信し続けた場合、システム全体の制限には達しないため、異常を示すアラートは一切発生せず、誰も気づかないまま高額な請求が発生する可能性がある。この問題への対策として、「ユーザーごと」「APIキーごと」「テナント（企業やグループ）ごと」に、リクエスト回数やトークンの利用量に制限を設けることが求められる。これらの制限は、ユーザー認証の仕組みと同等に重要であり、プログラムの深い部分ではなく、システムへの入口（エッジ）で厳格に実施されるべきだ。

これらの状況から、AIシステムにおける「監視」の考え方も変化する。従来の稼働状況を示すダッシュボードは、システムが正常に動作しているかを知るには十分だったが、AI機能においては、「過去一時間でシステムを維持するためにいくらかかったか」という情報も必要となる。具体的には、機能ごと、ユーザーごと、テナントごとに、トークンの使用量とそれにかかる費用をリアルタイムに近い形で把握し、エラー発生率だけでなく、「費用発生率」に対するアラートを設定することが不可欠だ。さらに、設定した閾値を超えた場合に、そのAI機能を自動的に停止させる「キルスイッチ」のような仕組みも重要となる。

LLMへの呼び出しは、単なるプログラムの関数呼び出しとは異なり、「何かを購入する行為」だと認識すべきだ。そのため、システム設計においては、ループ処理、再試行、複数の処理に分岐するファンアウトといった一つ一つのプロセスを、明確な上限を伴う「支出の決定」として扱う意識が求められる。本番環境でこのような厳格なコスト管理の仕組みがなければ、機能提供が意図せぬ高額な請求につながるリスクを常に抱えることになるだろう。