【OpenAI API】料金が急に増えた時の調べ方|Usage・トークン・上限設定

OpenAI APIの料金が昨日から急に増えた時は、モデルを変更する前に、どのプロジェクトの、どの時間帯の利用が増えたかを確認します。料金表の単価だけを見ても、同じ処理を何度も送ったのか、入力が長くなったのか、別の機能の料金が加わったのかは分かりません。

使うのはAPI PlatformのUsageです。ChatGPT Plusの月額料金とは別に集計します。金額が増えた期間を絞り、モデル名・呼び出し回数・入力と出力のトークンを照合して、修正すべき処理を見つけます。

まず組織・日付・プロジェクトをそろえる

Usage Dashboardを開きます。閲覧には組織の所有者またはUsage Dashboardの権限が必要です。表示できない場合は、APIキーを作り直すのではなく、必要な組織の利用記録を閲覧できるか管理者に確認します。

1. 対象のAPI組織を選びます。別の組織の利用量とは合算されません。
2. 増加に気付いた日と、その前の通常だった期間を選びます。
3. Usage内のプロジェクト選択を確認します。API Platformの別画面で選んだプロジェクトとは独立しています。
4. 組織全体を調べる場合はプロジェクトの絞り込みを解除し、増加しているプロジェクトを探します。

公式のUsage説明では、時刻はUTCで表示されます。日本時間の10月10日0時から24時を調べるなら、UTCでは10月9日15時から10月10日15時に当たります。日付単位の画面ではまたぐ両日を確認し、細かい時刻はアプリ側の記録と照合します。

モデル名と料金区分を、実際の記録から拾う

料金が増えたプロジェクトで、どのモデルと機能を使ったかを確認します。アプリの画面に「高性能モード」と表示されるだけでは、課金されたモデル名は特定できません。APIへ送ったモデル名や応答の記録を調べ、公式料金表の該当する行と照合します。

テキストの価格が「1M tokens」単位なら、100万トークン当たりの料金です。1000トークンのつもりで掛け算しないでください。通常入力、キャッシュされた入力、出力を同じ単価で計算することも避けます。長いコンテキストや処理モードによる区分がある場合は、その条件も合わせます。

料金表にCache writesなど別の項目があるモデルや、Web検索、ファイル検索、保存領域、コンテナなどを使った処理では、その費用も確認します。すべての増加を「出力の文字数が多いから」と説明せず、利用した機能の明細まで見てください。

1件の応答にあるusageと、アプリの呼び出し回数を比べる

Responses APIでは主にusage.input_tokensとusage.output_tokens、Chat Completionsではusage.prompt_tokensとusage.completion_tokensを確認します。エンドポイントによってフィールド名が違うため、片方の名前をすべてのログで探さないようにします。

例えば、画面上では1回「要約」を押しただけでも、アプリが分割処理や再試行で複数回APIを呼んでいることがあります。操作1回に対応する開始・終了時刻、呼び出し回数、モデル名、usageをまとめ、通常だった処理と比べます。プロンプト本文やAPIキーを公開する必要はありません。

タイムアウトで画面に答えが出なかったことだけでは、トークン使用量がゼロだったとは判断できません。特にストリーミングが途中で切れると、最後のusage情報を受け取れない場合があります。エラー種別だけで一律に課金あり・なしを決めず、Usageとリクエストの記録を照合します。

キャッシュ分を二重に数えず、料金を試算する

以下は計算方法を確認するための架空の単価です。実際のモデル価格ではありません。通常入力が100万トークン当たり2ドル、キャッシュ入力が0.50ドル、出力が8ドルで、入力合計100万のうち20万がキャッシュ利用、出力が10万だったとします。

入力合計にはキャッシュされた入力も含まれます。合計100万を通常単価で計算してから、さらにキャッシュ20万の費用を足すと二重計上になります。キャッシュの適用は応答の使用量情報で確かめ、同じ文章を送ったから必ず安くなるとは見込まないでください。

この例にツール料や保存料、別の料金区分は含めていません。試算と明細が違う時は、その差額を説明する区分を探します。クレジット購入額、APIの利用額、カードの円建て請求額も、それぞれ同じものではありません。

増加原因に合わせ、同じ処理で変更前後を比較する

再試行が増えていたなら、その処理の回数と停止条件を見直します。入力が膨らんでいたなら、重複した資料や不要な履歴を外します。単に短くするのではなく、回答に必要な条件が残っているかを確かめてください。

モデルや出力上限を変える場合は、同じ入力の小さな検証用データで、料金と結果を比べます。要約なら必要な事項が欠けていないか、分類なら判定が変わっていないかを確認します。複数の条件を一度に変えると、何が費用や品質へ影響したか分からなくなります。

通知だけの上限か、APIを止める上限かを確認する

Spend limitsの公式ガイドでは、Spend alertは通知用で、APIの処理を止めません。対象プロジェクトのLimitsからSpendの「Edit spend limit」を開き、月額の値を設定したうえで「Enforce a hard limit」を有効にすると、記録された利用額が上限に達した後の対象API処理が制限されます。

Hard limitに達すると、そのプロジェクトではproject_spend_limit_exceeded、組織の上限ならorganization_spend_limit_exceededを伴う429エラーが返ります。本番の処理も止まるため、検証用と本番用のどちらへ設定するかを確認します。反映は瞬時ではなく、設定額を少し超える場合もあります。

最後に、増えたプロジェクトと処理、変更した条件、変更前後の呼び出し回数・トークン・費用を残します。総額が下がっただけで終わらず、必要な結果が得られ、意図した費用制御が設定されていることまで確認してください。

🤖

生成AIトラブル完全解決データベース ChatGPT・Claude・Gemini・Midjourneyなど主要生成AIの基礎/料金/セキュリティ/著作権/社内ルール/業務活用/依存防止/比較選びを横断網羅。最新機能ではなく長期に陳腐化しにくい実務リファレンスとしてご活用ください。