AI APIの料金を調べるときは、料金表の単価だけで判断しないようにします。月に何件処理し、1件にどれだけの入力と出力があり、失敗時に何回やり直すかで、実際の費用が変わるためです。
まず利用するAPI、モデル、対象プロジェクトを決め、料金表、利用状況、制限設定を対応させて確認します。チャットサービスの契約とAPIの課金を同じものとして扱わず、使うサービス側の請求条件を確認してください。
件数と1件当たりの使用量を分ける
テキスト処理なら、入力トークンと出力トークンの単価をそれぞれ確認します。日本語の文字数を、そのままトークン数として計算しないことが必要です。画像、音声、検索、保存などを使う場合は、その機能の課金項目も加えます。
基本的な見積もりは次の形で作れます。適用する単価の単位や通貨は、公式料金表に合わせます。
月の処理回数 = 対象件数 × 1件当たりの平均要求回数
入力料金 = 入力トークン合計 ÷ 単価の基準単位 × 入力単価
出力料金 = 出力トークン合計 ÷ 単価の基準単位 × 出力単価
見積額 = 入力料金 + 出力料金 + その他の機能料金
再生成、試験、失敗時の再試行も、想定する要求回数に含めます。キャッシュなどの割引を使う見込みがあっても、適用条件を確かめるまでは通常の単価で別計算を残すと、前提を確認しやすくなります。
通知と利用停止を区別する
OpenAIの利用額制御の資料では、通知を送るspend alertと、要求を止めるhard spend limitを区別しています。通知の設定だけでは、上限に達しても通信は続きます。
同資料では、hard spend limitの適用は瞬時ではなく、記録額が設定額を少し超える場合もあると説明されています。設定値を「絶対に1円も超えない保証」として扱わず、アプリ側の件数制限や停止手順も用意します。利用できる設定や権限は、自分の組織・プロジェクトで確認します。
| 確認するもの | 分かること |
|---|---|
| 公式料金表 | モデルや機能の課金単位と単価 |
| 利用状況 | 実際に記録された使用量と費用 |
| 通知設定 | 誰がどの段階で費用増加を知るか |
| 利用額の制限 | どの範囲の要求が停止対象か |
| アプリの件数上限 | 短時間の大量処理をどこで止めるか |
ログには費用を説明できる項目を残す
処理ID、日時、用途、モデル、プロンプトの版、入力・出力の使用量、試行回数、結果を記録します。要求の本文やキーを保存しなくても、費用増加の原因を調べられる形を目指します。
見積もりと実績が違うときは、単価、件数、入力の長さ、出力の長さ、再試行、追加機能の順に比較します。エラーが増えた月に、成功件数だけを分母にすると、失敗した要求の影響を見落とします。
レート制限は利用額の上限とは別です。OpenAIのレート制限資料で、要求数やトークンの制限も確認します。429が出たときは、頻度の制限か、課金・利用額の問題かをエラーコードで切り分けます。
使いすぎを止める条件を決める
新しい処理を本番へ入れる前に、1回の最大件数、入力サイズ、出力枠、再試行の回数を決めます。上限に達したときは未処理を保留し、担当者へ知らせる形にします。停止後に未処理が一斉に再実行されないよう、再開する件数も決めておきます。
この記事では特定モデルの単価や月額を固定していません。見積もる日に公式料金表を開き、確認日、モデルID、通貨、課金単位を表へ残してください。
処理単位の考え方は長文要約のプロンプト、API設定の点検方法はGemini APIキー確認ツールも参考になります。
