AI APIの料金はどう決まる？トークン課金の基本

AI APIの料金は、Web版AIの月額契約とは別に計算します。多くのtext APIでは、modelが受け取るinputと返すoutputの量に応じて課金されますが、実際の請求はmodel、cache、Batch、検索・fileなどのtool、画像・音声、retryによって変わります。「100万tokensあたりの単価」だけを見ても、1つの仕事を完了する費用は分かりません。まず料金表とusage logを使って、1業務あたりの総量を見積もります。

基本式を課金単位から組み立てる

text中心のrequestでは、概算を次の形で考えます。

input cost = 通常input tokens × input単価 + cache対象tokens × cache単価

output cost = output tokens × output単価

job cost = 全requestのinput/output cost + tool・media等の追加費用

料金表が1M tokens単位なら、token数を1,000,000で割って単価を掛けます。たとえば料金ページで「1M input tokensあたりP円相当ではなくP USD」と表記され、処理がI tokensなら、inputの概算は I ÷ 1,000,000 × P です。価格はmodel、利用region、速度tier、Batch等の条件に一致する行から選びます。式の単位が違う場合はそのまま混ぜず、まず同じ通貨・同じ単位へ揃えます。

料金ページには、1 tokenが何文字かという固定換算はありません。言語、code、画像や音声の表現、tokenizerで処理量は変わります。日本語の文字数だけから請求額を決め打ちせず、response usage、providerのtokenizer、実際のusage dashboardで確認してください。

短い仕事でもinput履歴は増える

対話型APIは、直近の質問だけでなくsystem instruction、会話履歴、検索結果、参照文書などをrequestへ含めることがあります。質問が短くても、過去のhistoryを毎回再送すればinput tokensは増えます。長いpromptや参照資料を使う処理では、入力を一度だけ送るつもりでも、retryや複数stepで繰り返し請求される可能性があります。

試算時は、1回のrequestではなく、業務の開始から完了までのrequest数を数えます。入力の取得、要約、回答生成、検証、修正の各stepで別requestを行うなら、各stepのtokenとmodelを分けて記録します。Agentが必要に応じてtoolを繰り返す設計では、最大step数、retry上限、停止条件を決めないと、想定した一回分より費用が膨らみます。

仮の数字で計算の流れを確認する

次の例はproviderの実価格や実測結果ではなく、変数を使った見積もり方です。1件の問い合わせに対して、通常inputがI tokens、cache対象がC tokens、outputがO tokens、単価をそれぞれPin、Pcache、Poutとします。requestが3回発生するなら、3回分を合計します。検索toolを2回使えば検索単価を加え、途中で失敗して再送した分も加算します。

表は横にスクロールできます

処理段階	input	output	追加費用	確認先
質問の分類	instruction + query	label	なし / tool	response usage
資料の要約	file / text	summary	file処理条件	model usage
回答の生成	history + summary	answer	search等	tool log
QA retry	error後の再request	revised answer	retry回数	application log

この表を自分の処理へ合わせて埋めると、どの段階が費用の大半を占めるか見えます。出力が長い、同じ文書を何度も送る、searchを毎回使う、Agentが修正を反復する、といった条件を別々に変えられます。品質を落とさずに、不要なhistoryを送らない、適切な要約を再利用する、retryを止めるといった改善候補を発見できます。

cacheとBatchを別条件として見る

同じ長い前提情報を複数requestで再利用する場合、providerがprompt cachingやcached inputの料金を用意していることがあります。キャッシュ対象・保持期間・有効条件はproviderとAPIで異なり、すべての繰り返しinputが自動的に安くなるわけではありません。response usageにcache read/writeの内訳があるか、料金表でwriteとreadの単価がどう違うかを確認します。cache設定を変えたときは、最初の書き込み費用と後続requestの読み取り費用を別に計算します。

応答を即時に返す必要がない大量処理では、Batch APIなどの非同期処理に割引があるproviderもあります。割引率だけで判断せず、処理結果が返る時間、失敗したjobの再送、入力fileの条件、出力の検証、途中経過が必要かを確認します。夜間の文書分類のように待てる仕事と、画面で利用者へすぐ返す問い合わせを同じ方式にする必要はありません。

Tool・画像・音声はtoken以外も加える

検索、file search、code execution、container、画像生成、音声処理などは、model token料金のほかにtool call、file storage、実行時間、media単位など別の課金項目を持つことがあります。OpenAIの公式API価格ページはmodel tokensとbuilt-in toolsの価格を分けています。Anthropicもmodel単価、prompt caching、Batch、機能別料金を別に案内しています。Gemini APIもmodelや機能ごとにFree/Paidやusage条件を示すため、対象endpointを料金ページで確認してください。

たとえば1つの問い合わせを回答するために検索を行い、長い文書を参照し、最終回答を生成する場合、text tokensだけの見積もりは不足します。別のサービスがtoolを代行する場合でも、料金に含まれるとは限りません。requestごとのtool call count、検索結果のtoken、storageの利用期間を記録します。画像・音声・動画は入力の数え方がtextと異なることがあるため、公式料金表の該当するmodalityの単位を使います。

一件あたりの費用を実測に近づける手順

1. 実際のtaskを一つ定義し、入力の平均と最大サイズを用意する。

2. 使うmodel、region、速度tier、toolを固定して記録する。

3. 1件の処理中に呼ぶAPI数、retry上限、Agentの最大stepを決める。

4. 少数の安全な入力で実行し、各responseのusageとtool callを保存する。

5. 完了したtask件数で合計費用を割り、1件単価を計算する。

6. 普通の月と繁忙月の件数を掛け、固定費やstorageを加える。

7. modelやpromptを変更したら同じ計測をやり直す。

responseのusage情報と請求dashboardの期間がずれることがあります。OpenAIのUsage dashboardはUTCで表示される場合があるため、アプリ側ログのtimezoneと合わせて照合します。組織やprojectの権限によりdashboardを見られない場合もあるので、usage情報を返すAPI responseの記録も用意します。集計では失敗したrequest、未完了task、retryも落とさずに含めてください。

月額の上限と異常利用を設計する

試算した平均額だけで本番予算を決めず、異常なretry、利用者の急増、入力サイズの増大が起きた場合の上限を決めます。プロジェクト単位でusageを分けられるなら、開発用とproduction用を分け、予算通知や利用上限を設定します。アプリ側にもrequest timeout、最大出力長、最大step数、rate limit、retry backoffを設け、失敗を無限に繰り返さないようにします。

月間予算を設定できても、即時に完全停止するものか、通知だけか、反映に遅延があるかはサービスによって異なります。管理画面の説明を読み、上限を超えた際に処理が拒否されるのか、別請求が続くのかを確認します。最初は予算の小さなprojectで試し、請求が想定どおりかを照合してから本番負荷へ進めます。

AIものさしの判断

API料金は、input/output tokensを基本にしながら、model、cache、Batch、tool、media、retryまで含めた1業務の総額で判断します。料金表の単価だけでサービスを順位づけず、同じ仕事が完了する条件と、出力確認に必要な人の時間も含めて比較してください。

実装前には変数を使った概算を作り、小規模taskのusage logで数値を置き換えます。利用量を追えない設計、retry上限がない設計、tool料金が分からないままの本番移行は保留します。これなら料金表が更新されても、modelと単価を差し替えて再計算でき、過去の固定価格表に依存せず予算を見直せます。