上限を置くだけでは、外れても気づけない
生成AIを自社のサービスに組み込んだとき、最初に置いたのは利用回数の上限でした。1人あたりの上限、全員合計の1日の上限、連打の制限などです。ただ、上限は「止める」ための仕組みで、正しく効いているかは教えてくれません。どこかの入口で上限が外れていても、そのことに気づく手段がありませんでした。
クラウドの請求アラートもありますが、反映が数時間遅れます。そこで、請求アラートより前に自分で数えた数字を置くことにしました。使った分を毎日数えて目で見るところまでやり、上限とあわせて歯止めにする、という考え方です。
毎朝のダイジェストに1行足した
新しい定期実行も、新しい課金リソースも作っていません。決まった時刻に1回動いて社内チャットへ投稿している「毎朝の日次ダイジェスト」があったので、そこに1行足しただけです。
1行に入れたものと、それぞれの値の取り方は次のとおりです。
| 出すもの | どこから取るか |
|---|---|
| 何回呼んだか・モデル別の入出力トークン | 上限の歯止めが既に書いている同じ1件のカウンタに相乗り |
| 推定費用 | 上のトークン × 公開単価。単価が分からないモデルは金額に混ぜず「単価不明」と書く |
| 上限で断った回数（理由別） | 同じ1件（連打・新しい口座・1日の上限・全体の上限・数えられず・長すぎ） |
| 全体の枠の消化 | 同じ1件の回数 / 1日の上限（300） |
| 課金がまだ付いているか | クラウドの請求情報を2つのプロジェクトに問い合わせる。外れていれば「自動停止が働いた」の知らせ |
推定費用の扱いでは一つ判断をしています。公開単価が分からないモデルについては、推測の単価で金額に足すことをやめ、「単価不明」と明記しました。推測で足せば合計は埋まりますが、実際より安く見えるおそれがあります。分からないものは分からないと出すことにしました。
2026-10-13 に、実際に社内チャットへ送りました（HTTP 200）。届いた1行は次のとおりです。
Gemini 10回 ≒ $0.0037（一部のモデルは単価不明で未算入）
・断り6回（連打2 / 新しい口座2 / 長すぎ2）・全体の枠 18/300
・課金 AI鍵のプロジェクト=付いている / アプリのプロジェクト=付いている
この日の費用は、Geminiを10回呼んで約 $0.0037 でした。ただし単価の分からないモデルの分はこの金額に入っていません。
数えるのは1か所にする
一番大事だったのは数える場所です。AIを呼んでいる場所は、5ファイル・10か所以上ありました。呼び出しのたびに「1回足す」を書いていく方法だと、足し忘れた分だけ費用が少なく見えます。しかも、少なく見えていることには誰も気づけません。
そこで、通信の戻り値を1か所で受け取り、そこだけで数えるようにしました。呼び出し元が増えても、同じ出口を通る限り数え漏れは出ません。
ただ、通信ライブラリを通らない経路が1つだけ残っていました。そこは直接数える呼び出しを足し、本番でカウンタが 30→31 に増えることを実際に確かめて、抜けが無いと判断しています（2026-10-13）。「1か所で数えている」と言えるのは、例外の経路まで数に入ったと確認できてからです。
数え始めた初回に、上限の穴が見つかった
毎朝の1行を出し始めた最初の回で、全員合計の上限が一部の入口にしか入っていなかったことが分かりました。口座をいくつも作れば、その入口を通らない機能は何回でも使えました。「全体の枠 n/300」にもその分は入っておらず、実際より少なく見えていました。
直し方は次のとおりです。
- 3つの機能を、同じ全体上限の下に通す。
- 順番は「利用者ごとの上限を通った呼び出しだけが、全体の枠を消費する」に揃える。逆の順だと、自分の上限を超えている人が全体の枠を食ってしまう。
- 断ったときは利用者の枠を減らさない（払い戻す）。
確かめ方も残しておきます。上限を1に下げた環境で、断る側の確認が 4/4（断られ、全体の枠も本人の枠も減らない）。上限を大きくした対照で 2/2（通り、全体の枠が 18→19）。本番でも 19→20 と 30→31 の増え方を確認しました。断る側と通る側の両方を見ないと、「断っている」のか「何も動いていない」のかを区別できないためです。
見張りが黙って止まる形を、公開前に塞いだ
もう一つ、出す前に見つけた穴があります。毎朝動く仕組みの環境変数に、請求情報を問い合わせるコマンドの置き場所が入っていませんでした。コマンドを名前だけで呼んでいたら、毎朝「取得不可」と出し続けていたはずです。見張りが止まっていても、1行自体は毎朝届くので気づきにくくなります。
実体の場所を探して絶対パスで呼ぶように直し、毎朝の仕組みと同じ環境で動かして確かめました。手元のシェルで動いても、定期実行の環境で動くとは限りません。
業務に置き換えると
業務にAIを入れるときに点検できる項目を挙げます。
- 上限（止める）と、日次の1行（数える）を同時に置いているか。 片方だけだと、上限が外れても気づけません。
- 数えている場所は1か所か。 呼び出しのたびに足す方法は、足し忘れた分だけ安く見えます。例外の経路が数に入ったかも、実際に数が増えるのを見て確かめます。
- 単価が分からないものを金額に混ぜていないか。 推測の単価で合計を埋めると、安く見えるおそれがあります。「単価不明」と分けて書きます。
- 全体の上限がすべての入口に効いているか。 数え始めると、上限が一部の入口にしか入っていなかったことが見えることがあります。
- 見張りそのものが動いているか。 毎朝「取得不可」が続いていないかを見ます。確認は、本番の定期実行と同じ環境で行います。
この記事は、TechAthletes が自社のサービスを作る中で記録した実測をもとに書いています。業務への導入のご相談は 仕事の窓口 で受け付けています。