生成AI APIの料金｜月額を出す5つの式
目次
PoCの会議で「この生成AI、月いくらですか」と聞かれる。料金表を開き、100万トークンあたりの単価を示す。 ところが、翌月の請求額はその場の概算から外れる。
原因はシンプルだ。料金表にはモデル単価が載っているが、あなたの業務が一日に何トークンを使い、何回やり直し、何回検索するかは載っていない。
生成AIのAPI料金は、単価比較だけでは決まらない。必要なのは、実際のリクエストを5つの式に分けることだ。ここではテキスト生成を基本に扱う。画像・音声は、後述するモデル固有費へ足す。
> 月額円 =（全試行のモデル費 + 全試行の周辺費）× 為替 × 予備係数
この形ならモデルが変わっても使い回せる。予算超過の理由も説明できる。
生成AIのAPI料金は単価表だけでは決まらない
OpenAIの公式料金表を見ると、入力、キャッシュ済み入力、出力で単価が分かれている。処理ティアや組み込みツールにも別の課金項目がある。
GoogleのGemini API料金表も同じ発想だ。有料枠では入力と出力に加え、コンテキストキャッシュ、検索によるグラウンディングなどを分けている。Batch APIは通常処理と条件が違う。
つまり、「100万トークンの価格」だけを比べても足りない。最低でも次の量を測る。
| 計測項目 | 見たい値 | 請求が膨らむ例 |
|---|---|---|
| 入力トークン | 1回あたり平均・95パーセンタイル | 会話履歴や文書を毎回すべて送る |
| 出力トークン | 1回あたり平均・上限 | 長文回答を無制限に返す |
| 成功率 | 業務上合格した件数÷実行件数 | 低品質回答を人が何度も再生成する |
| ツール利用 | 検索・ファイル取得などの回数 | 1回答の中で検索を繰り返す |
| 月間件数 | 通常日・繁忙日・異常日の件数 | 全社展開後の利用増をPoC件数で見積もる |
平均値だけでは危ない。通常日は平均でよいが、繁忙ケースには日次総費用の95パーセンタイルも使う。入力量と件数を別々に掛け合わせず、実際の日ごとの総額から出す。長い契約書や大量の問い合わせが混じると、少数の重い処理が請求額を押し上げるからだ。
月額を出す5つの計算式
月額は、入力・出力・再試行・周辺機能・利用量の5つに分けて計算する。単価改定やモデル変更があっても、変わった箇所だけ差し替えられる形にしておく。
式1・2：入力と出力のトークン費を分ける
1回のモデル利用料は、二つの式で出せる。
> 入力費 = 入力トークン数 ÷ 1,000,000 × 入力単価
> 出力費 = 出力トークン数 ÷ 1,000,000 × 出力単価
入力と出力は分ける。要約は入力が長く、文章作成は出力が膨らみやすい。同じ総トークン数でも原価が変わる。
試算には、想像上の日本語文字数ではなくAPIレスポンスのusage値を使う。50〜100件ほど流し、入力と出力を記録する。日本語、表、JSON、コードでは分割のされ方が違うためだ。Anthropicの料金資料は、Claude 4.7以降の新しいトークナイザーでは、同じ文章でもトークン数が概ね30%増える場合があると説明している。モデル更新後は再計測する。
例を置こう。以下の単価は計算方法を示すための仮値であり、採用時は各社の公式料金へ差し替える。
- 平均入力：8,000トークン
- 平均出力：1,200トークン
- 入力単価：100万トークンあたり1ドル
- 出力単価：100万トークンあたり6ドル
入力費は0.008ドル、出力費は0.0072ドル。1回の実行は0.0152ドルになる。入力の方が長くても、出力単価が高ければ負担は拮抗する。
出力には、回答を500文字以内、候補を3件まで、JSON配列を10件まで、と上限を置く。業務に必要な長さを合意し、超えた分を測れる状態にする。
式3：再試行を含む成功1件の原価を出す
APIが正常終了しても、業務が成功したとは限らない。根拠がない。形式が壊れている。担当者が再生成ボタンを押す。このやり直しも課金対象だ。
> 成功1件のモデ ル原価 = 計測期間中の全モデル費 ÷ 業務上の成功件数
全実行が同じ0.0152ドルだと仮定する。初回で業務上合格する割合が85%なら、成功1件の原価は約0.0179ドルになる。成功率が60%まで落ちれば約0.0253ドルだ。モデル単価を2割下げるより、成功率を戻す方が効く場面もある。実務では失敗した試行も含む請求実績を成功件数で割る。
成功率はHTTP 200の割合ではない。業務ごとに合格条件を置く。
- 問い合わせ回答：根拠URLがあり、担当者の修正なしで使えた
- 議事録：決定事項、担当、期限が所定の形式に入った
- データ抽出：必須項目が埋まり、型検査に通った
- メール下書き：禁止表現がなく、宛先と案件を取り違えなかった
再試行の理由も残す。モデルの能力不足なのか、渡した資料が古いのか、指示が曖昧なのかで対策が変わる。この評価設計は、生成AI PoCの成功基準と一緒に決めると整理しやすい。
式4：検索・キャッシュなど周辺費を足す
モデルの入出力だけを集計すると、請求と合わない。生成AI機能は、検索、ファイル取得、ベクトル検索、ログ保管、通信を組み合わせるからだ。失敗した試行で検索した費用も全周辺費へ入れる 。
> 成功1件の周辺費 = 計測期間中の全周辺費 ÷ 業務上の成功件数
AWSのBedrock利用料の読み方では、入力、出力、キャッシュ読み込み、キャッシュ書き込みを別の使用量として扱う。サービスティアやリージョン経路も料金照合の軸になる。請求をモデル名だけで集計しない方がよい理由がここにある。
キャッシュは書き込みにも費用がかかる。有効時間内に再利用する固定指示や共通資料へ絞る。毎回変わる顧客メールでは当たりにくい。
ツール呼び出しも上限を持たせる。たとえば、通常は検索2回まで、根拠不足なら人へ戻す。無制限に検索させるより、停止条件を決めた方が費用と回答時間を同時に守れる。
生成AIのAPI選びで見る4つの運用条件で扱ったように、データ保持や可用性、切替可能性も選定条件だ。安いモデルへ替えても、監査や障害対応のために別基盤が増えれば総額は下がらない。
式5：月額予算を3ケースで置く
1件の原価が出たら、月額へ広げる。
> 月額円 =（成功1件のモデル原価 + 成功1件の周辺費）× 1日の成功件数 × 稼働日 × 為替 × 予備係数
仮に、成功1件のモデル原価が0.0179ドル、失敗試行分も含めた成功1件の周辺費が0.0100ドル、1日500件、月22日とする。ドル建て月額は約306.9ドルだ。為替を1ドル150円、予備係数を1.2に置くと、予算は約5.5万円になる。
この5.5万円は予言ではない。意思決定の基準だ。次の3ケースを横に並べる。
| ケース | 件数・成功率 | 使い道 |
|---|---|---|
| 通常 | 直近4週間の中央値 | 月次予算の中心 |
| 繁忙 | 日次総費用の95パーセンタイル | 繁忙時の目安とアラート |
| 異常 | 成功率低下、再試行急増 | 自動停止と原因調査 |
予備係数には、為替変動、単価改定、全社展開の立ち上がりを入れる。ただし、何でも20%増しにして終わらせない。為替5%、利用増10%、再試行悪化5%のように理由を分けると、実績との差を翌月に直せる。推論トークン、画像・音声、長文料金、リージョン差、税、個別割引は「モデル固有費」として別列に置く。
料金を下げる順番はモデル変更からではない
安いモデルを探す前に、試算表の大きい項目から触る。
- 長い会話履歴や重複文書を減らす
- 出力の形式と上限を決める
- 再試行理由を直し、成功率を上げる
- 再利用される入力だけをキャッシュする
- 定型処理をBatchへ寄せる
- 難易度に応じて軽量モデルへ振り分ける
モデルの振り分けは最後でよい。定型分類は軽量モデル、契約リスクの抽出は上位モデル、と条件を決める。安さだけで切り替えると、成功率が落ちて再試行費が戻ってくる。
毎日見る指標は、費用だけでは足りない。件数、入力、出力、成功率、応答時間、ツール回数を同じ画面へ置く。費用が増えても処理件数が増えたなら正常かもしれない。件数が同じで再試行だけ増えたなら異常だ。
API以外の開発、評 価、監視、保守まで含めたい場合は、AIエージェントの費用を分ける5つの内訳もあわせて確認してほしい。
予算表に残す9項目
スプレッドシートなら、次の9列から始められる。
- 業務名と利用者
- 1日あたり成功件数
- 平均・95パーセンタイルの入力トークン
- 平均・95パーセンタイルの出力トークン
- 業務成功率と再試行理由
- 検索・ファイル・キャッシュの利用回数
- モデル、処理ティア、モデル固有費
- 為替、予備係数、月額上限
- 上限超過時の通知先と停止条件
正直なところ、単価表の転記はすぐ終わる。難しいのは、何を成功1件と数え、どこで止めるかを業務側と決めることだ。要件定義書には、usageの計測仕様、業務上の合格条件、月額超過時の制御を残す。ここまで決まれば、生成AIのAPI料金は読めない変動費ではなくなる。
Atsumellは、生成AIを組み込む業務フロー、品質条件、コスト上限を整理し、要件定義から実装・運用まで支援している。自社のログから試算表を作りたい場合は、お問い合わせから相談してほしい。
