TL;DR: 複数のAIモデルAPIを併用していると、無料枠だから安心と思っていても「実際どれだけの経済価値を消費しているか」は感覚では分からなくなる。自作の使用量算出ツールで、記録に成功した呼び出し分を料金テーブル上の単価に当てはめて試算したところ約¥3,735だった。ところが同じ月のベンダー公式コンソールが示す無料枠消費数は2,611リクエストで、ツール側の記録は935回。両者が同じ単位を数えているかは検証できておらず、単純に「935/2611=カバー率」と読むことはできない。それでも数字を並べたことで、可視化ツールが返す金額は「見えている範囲だけの試算値」であって「公式が把握している消費量」とは一致しない、という境界線がはっきりした。
結論から: 出てきた金額と、公式の消費数は噛み合わなかった
複数のAIモデルAPIを日常的に使い分けていると、ベンダーごとに管理画面が分かれていて、「今月AIにいくら使っているか」を横断的に把握する手段が、少なくとも自分の運用環境にはなかった。無料枠のあるベンダーは、枠内にいる限り請求書が来ないので、消費している経済価値そのものが見えにくい。
そこで、個人開発のAIエージェント運用基盤に、各ベンダーAPIクライアントの呼び出しを記録する使用量算出ツールを組み込んである。ある無料枠ベンダーについて、このツールが記録した当月分の呼び出しを、料金テーブルに登録済みの単価に当てはめて試算すると、約¥3,735だった。「無料枠を使い切りそうで心配」という体感の重さに対して、この金額だけ見ると意外と小さい。
ところが、同じ月のベンダー公式コンソールを確認すると、無料枠(月3,000リクエストまで)の消費数は2,611リクエストになっていた。一方、算出ツールが記録していた呼び出し回数は935回。「公式コンソールの消費数」と「自作ツールの記録件数」が厳密に同じ単位を数えているかは検証できていないため、この差を単純な捕捉率として扱うことはできない。ただし数字を並べただけでも、ツール側が公式の消費実態を完全には反映していない可能性は見えてくる。
**¥3,735は「今月使った金額」ではなく、「記録に成功した呼び出し分に、料金テーブル上の単価を当てはめた試算値」**というのが正確なところだ。
ツールの設計: ログ層とレポート層を分ける
このツールは大きく2つの部品でできている。
-
ロギング層: 各ベンダーAPIクライアントは、成功時や一部のエラー応答時など複数の経路で共有のロギング関数を呼び、「ベンダー名・モデル名・入力トークン数・出力トークン数」をローカルのSQLite DBへ記録する。ただし認証情報が未設定のケースなど、記録されない経路も残っている。ロギング自体がDB書き込みエラー等で失敗してもAPI呼び出し本体を壊さないよう、
OSErrorやsqlite3.Errorなど想定される永続化系の例外は握りつぶして無視する設計にしている。観測性のためだけの仕組みが、本業のAPI呼び出しの信頼性を下げては本末転倒になりかねない。ただしこれは裏を返すと、その種の永続化エラーが起きた呼び出しは静かに欠落するということでもある。935という数字自体、「記録に成功した経路」の値であって、直接計装した呼び出しの総数を保証するものではない。 -
レポート層: DBに溜まったログを読み、ベンダー・モデルごとに呼び出し回数とトークン量を集計し、料金テーブルに基づいてUSD換算する。ここでの設計判断が1つある。保存済みのコストを信用せず、レポート出力のたびに現在の料金テーブルで再計算する。 理由は実際に踏んだ失敗にある。ある時、料金テーブルにまだ登録していないモデルの呼び出しがログに記録され始め、そのモデルの単価を料金テーブルへ追加するまでに数時間のタイムラグが生じたことがあった。その間に記録された呼び出しは「未価格設定」のままDBに保存され、後から料金テーブルにそのモデルを追加しても、保存済みの値は更新されなかった。同じモデルが何時間も「価格不明」のままレポートに出続けていた。都度再計算する方式に直せば、この種のズレは構造的に起きにくくなるだろう。
料金テーブルの単価は、ベンダーによって扱いが違う。JPY建てで公表しているベンダーの分は、料金テーブルに登録する時点で仮のレート(1USD=150円)を使ってUSD単価に変換してある。もともとUSD建てで公表しているベンダーの分は、そのままの単価を使っている。レポート自体はどちらもUSDで出力し、最終的に円へ戻すのは、その出力を見た人間側の手動計算だ。為替の変動は反映していないし、レートを当てる場所もベンダーによって異なる。ここは今のところ、割り切っている部分だと言えるかもしれない。
定額サブスク側は別の考え方が必要だった
従量課金のベンダーだけでなく、コーディングエージェント系の定額サブスクサービスも使っている。こちらは請求が固定額なので、「実際の請求額」を求める用途には直結しない。使用量が急増しても、その分はサブスクの上限枠を早く使い切るだけで、追加の請求が発生するわけではない。むしろ見ておきたいのは逆で、使用量が急減したときだ。今のプランを維持する必要があるのか、もっと下位のプランで足りるのか、あるいは定額をやめて従量課金のAPIプランに切り替えた方が安いのか——その判断材料として、「もし従量課金だったら」という仮想コストを見ている。
この仮想コスト推定では、セッションのログファイルからトークン数を集計する。最初のプロトタイプはキャッシュ関連のトークンも通常の入出力トークンと同じ単価で計算しており、1日あたり約216ドルという数字が出た。キャッシュトークンを計算から除外する方式に変えたところ、1日あたり33〜42ドル程度になった。ただし、どちらの数字も独立した請求額やベンダーの詳細な課金仕様と突き合わせて検証したわけではない。除外によって数字が実態に近づいたと証明されたわけではなく、あくまで推定の前提を変えた結果として扱っている。
詰まった点
- 「記録できている金額」と「公式の消費数」を単純比較しかけた。 → ベンダー公式コンソールの消費数(2,611)と、ツールが記録していた呼び出し回数(935)の差に気づいたが、両者が同じ単位を数えている保証がないため、「◯%しか捕捉できていない」という言い方はできない。算出ツールが返す金額は常に「見えている経路だけの試算値」として扱う必要がある。
- ロギングの例外握りつぶしや、一部経路の記録漏れにより、直接計装した呼び出しの一部も静かに欠落しうる。 → 未解決。公式コンソールとの数字の差が、丸ごと「未計装の外部経路」由来だと決めつける根拠はまだない。
- 保存済みコストを信用すると、料金テーブル更新のタイムラグでズレる。 → レポート出力時に都度再計算する方式に変更して解消。
- キャッシュトークンを含めて計算すると、定額サブスクの仮想コストが跳ね上がる。 → キャッシュトークンを明示的に除外する方針にして数字は下がったが、除外後の値が実態に近いとは未検証。「除外している」こと自体を出力に明記しないと、後で見た人が前提を見落とす。
使い分けの目安
| 状況 | この手のツールが向くか |
|---|---|
| 無料枠を使い切りそうで漠然と不安なとき | 向いている。まず自分の呼び出しを計装し、体感を具体的な金額に変換する第一歩にはなる |
| 複数ベンダーを併用してコスト感覚を統一したいとき | 向いている。直接計装できた経路同士は横並びで比較できる。ただし公式の消費数とは別物として扱う必要がある |
| 「実際の請求額」や「今月の全消費量」を正確に知りたいとき | 向いていない。記録に成功した経路に限定された試算値でしかなく、公式コンソールの数字と一致する保証はない |
| 為替変動を反映した精密な円換算が必要なとき | 向いていない。一部ベンダーは仮のレートで単価をUSD化しており、最終的な円換算も見る側の手動計算 |
| 出てきた金額を「これが全コストだ」と思い込みたいとき | 向いていない。ベンダー公式の消費数と定期的に突き合わせない限り、どれだけ見えていないかも分からない |