生成AI APIのコスト削減｜キャッシュ・バッチ・モデル振り分け

生成AI APIのコスト削減は、安いモデルへの一括変更ではなく、入力・出力・再試行が増えた業務要求を特定し、キャッシュ、非同期バッチ、モデル振り分けを適所へ割り当てる取り組みです。 削減率だけでなく、品質、待ち時間、認証、停止条件、切り戻しまで一組で設計します。

生成AI APIのコスト増を30分で切り分ける

請求額だけを見てモデル変更へ進むと、再試行や長い出力が原因だった場合に品質を落としただけで終わります。最初に比較期間を固定し、Project、API経路、モデルのスナップショット、業務種別、成功・失敗を同じ粒度で集計します。前日比では曜日や一括処理の偏りが出るため、通常は直近7日とその前の7日を比較し、件数差と1件当たり差を分けます。

1. 利用額の増加を「要求数×1要求当たり費用」に分け、どちらが増えたか確認します。
2. 費用を入力、キャッシュ済み入力、出力、再試行に分解し、モデル変更日時と重ねます。
3. 成功した業務要求だけでなく、429、500系、タイムアウト、利用者の再生成も集計します。
4. 上位10件のトレースから、長大入力、長い出力、ツールのループ、重複送信を確認します。

2026年7月30日に確認したOpenAI公式モデル資料では、gpt-5.4-mini-2026-03-17の標準料金は100万トークン当たり入力0.75米ドル、キャッシュ済み入力0.075米ドル、出力4.50米ドルです^[1]。単価は参照時点の値として台帳へ保存し、過去利用量を現在単価だけで再計算しません。

料金改定やモデル切替があった期間は、各要求に適用された単価表の版で分けます。

切り分け結果は、件数要因、単価要因、使用量要因、失敗要因の四区分へ置きます。たとえば総額が40％増えても要求数が50％増え、成功要求当たり費用が7％下がっているなら、異常というより利用拡大です。反対に件数が一定で費用だけ増えた場合は、モデル構成、トークン、試行回数の順に掘ります。調査時点の為替換算額とAPIの米ドル利用額を混ぜず、まず原通貨で比較します。

請求を業務要求まで分解する

費用の基本式は、入力トークン×入力単価＋キャッシュ済み入力×キャッシュ単価＋出力トークン×出力単価です。実務では、ここへ失敗試行、再試行、画像や検索など別料金の機能を加えます。集計キーをAPI request IDだけにすると、同じ利用者操作から三回再送された事実が見えません。自社の論理要求IDを発行し、その配下に全API試行を紐付けます。

API資格情報は費用責任の境界でもあります。OpenAIのAPI概要はBearer認証を示し、APIキーをクライアント側コードへ露出しないよう求めています^[4]。本番とステージングのProject、サービスごとの資格情報、利用額上限を分け、ブラウザーは自社バックエンドだけを呼びます。

ログにはキー本体ではなくProject、サービス、鍵の識別子、要求者を残します。

プロンプトキャッシュを実装する

プロンプトキャッシュは、自社で回答を保存して再利用する仕組みではありません。OpenAIの公式資料では、対応モデルで1,024トークン以上のプロンプトに自動適用され、応答のusage内にcached_tokensが示されます^[2]。

毎回共通するシステム指示、ツール定義、長い参照例を先頭へ置き、顧客名、日時、質問など変動部分を末尾へ寄せます。共通部分の一文字変更でも一致範囲が縮むため、テンプレート版を固定します。

messages = [
  { role: "system", content: POLICY_V3 },
  { role: "developer", content: TOOL_RULES_V2 },
  { role: "user", content: `customer=${customerId}\nquestion=${question}` }
]
log({
  promptVersion: "policy-v3",
  inputTokens: usage.input_tokens,
  cachedTokens: usage.input_tokens_details?.cached_tokens ?? 0
})

効果はキャッシュ対象になった要求数ではなく、キャッシュ済み入力÷総入力で測ります。想定例として月10万件、1件当たり共通入力1,600、変動入力400、出力300トークンを前記単価で計算します。キャッシュなしは入力150ドル＋出力135ドル＝285ドルです。共通部分が全件キャッシュされるなら、キャッシュ12ドル＋通常入力30ドル＋出力135ドル＝177ドルとなり、差額108ドル、削減率は108÷285×100＝約37.9％です。再試行や他機能の料金は含まない想定値です。

本番では、テンプレート版ごとに総入力、キャッシュ済み入力、要求数を集計します。キャッシュ率が高くても、共通指示を過剰に長くして総入力が増えれば逆効果です。「成功要求当たり入力費用」と「キャッシュ率」を並べ、両方が改善した版だけを残します。新しい指示へ切り替える際は旧版をすぐ削除せず、機能フラグで戻せる期間を一週間確保します。

品質評価に失敗した版は、料金効果に関係なく配信を止めます。

Batchとモデル振り分けを選ぶ

即時応答が不要な評価、分類、夜間集計はBatch APIの候補です。OpenAIの公式ガイドは、同期APIに対して50％の料金割引、24時間以内の完了枠、JSONL入力と各要求のcustom_idを示しています^[3]。処理順と結果順が一致する前提を置かず、業務要求IDをcustom_idへ対応させます。

翌朝までに必要なジョブは、24時間枠ぎりぎりではなく業務締切から逆算して投入します。

モデル振り分けは文字数だけで決めません。業務種別、入力の不確実性、過去の評価結果からルートを決め、理由をログへ残します。新ルールは5％のカナリアから始め、品質合格率が従来比2ポイント以上低下、重大誤りが一件、またはP95が1.5倍を超えたら従来設定へ戻します。

キャッシュとBatchの削減額を合算する場合も、同じトークンへ割引を二重計上せず、実際のusageと請求区分で確認します。

Batchの想定例として、月10万件、入力2,000、出力300トークンを前記の標準単価で同期処理すると285ドルです。同一の使用量がすべて50％割引の対象なら142.50ドルになります。ただし、これはキャッシュ、再投入、保存、運用人件費を含まない比較です。

実際の採否では、期限超過時の同期振替費用と、翌日確認に必要な作業時間も足します。割引額より運用増が大きければ同期処理を維持します。

自動最適化を止める条件

費用異常が資格情報の漏えい、意図しない公開エンドポイント、顧客をまたぐ処理に関係する場合は、キャッシュ率の調整では済ませません。対象資格情報を無効化し、Projectの送信を止め、セキュリティ担当とサービス責任者へ引き継ぎます。

入力本文やAPIキーを通常の障害チケットへ貼らず、request ID、発生時刻、Project、モデル、利用額、呼び出し元だけを保全します。

自動停止の想定条件は、1時間の費用が同曜日同時間帯中央値の3倍、日次予算の80％到達、論理要求当たり試行数が1.2超過、キャッシュ率が前日比20ポイント低下、または高性能モデルへの昇格率が設計値の2倍です。停止後は新規の低優先度ジョブを保留し、リアルタイムの必須経路だけに日次上限を割り当てます。品質基準を下げて請求だけを抑える変更は行いません。

OpenAIの本番運用資料は、ステージングと本番をProjectで分け、Projectごとにアクセス、レート、利用額上限を管理する考え方を示しています^[5]。上限引き上げ、高性能モデルの全件適用、失敗バッチの全量再投入は、予算責任者と業務責任者の承認対象です。利用額とトークン記録が一致しない場合は自動再開せず、請求期間と単価版を照合します。

費用台帳の記録項目を決める

削減施策を比較するには、請求期間の合計をAPI経路まで割り戻せる台帳が必要です。一行を一回のAPI試行とし、論理要求IDで業務成果へ束ねます。金額は送信時に推定し、確定後に請求データと照合します。単価はモデル名だけで引かず、モデルのスナップショットと料金表の参照日を組にします。再計算できるよう、入力、キャッシュ済み入力、出力のトークンを別列で保持します。

入力本文そのものを費用台帳へ複製すると、個人情報と機密情報の保管範囲が広がります。本文はアクセス制御された元ログへ置き、台帳にはハッシュ、長さ、文書数、分類だけを記録します。保存期間は障害調査と請求照合に必要な期間へ限定し、閲覧権限を開発者全員へ配りません。集計基盤が欠損した場合は「0円」とせず不明として扱い、最適化実験を停止します。

削減策の障害と回避策

キャッシュ率が上がらない典型例は、日時や顧客IDを共通指示より前へ置く、ツール定義の並びが毎回変わる、同じ意味のJSONを異なる空白で生成することです。テンプレート版と先頭部分のハッシュを記録し、同じ版なのにcached_tokensが急落したときだけ実装差を調べます。短い要求は適用下限に届かないため、キャッシュ目的で無意味な文章を足しません。

Batchでは、JSONLの一行不正、custom_idの重複、投入遅延、期限切れ、部分失敗が起こり得ます。全件再投入すると成功済み要求まで二重処理するため、結果をIDで突合し、不足分だけ新しいバッチへ入れます。外部送信やデータ更新はバッチ結果の生成と分け、業務側の冪等性キーで一度だけ実行します。

24時間を待てないジョブを料金だけでBatchへ移さないことも重要です。

モデル振り分けでは、小型モデルが特定の言語、長文、曖昧入力だけで誤る場合があります。全体平均が合格でも、契約判断や顧客通知の重大誤りは許容しません。品質評価セットを通常、長文、境界、拒否、悪意ある入力へ分け、区分別に合格線を設けます。ルーター障害時に最安モデルへ倒す設計は避け、既知の従来モデル、保留、人の確認のどれかへ戻します。

実装と切り戻しの手順

三つの削減策を同時に入れると、費用差と品質差の原因を特定できません。まず台帳を整備し、現行設定を二週間測ります。次にキャッシュ用の接頭辞固定、Batch移行、モデル振り分けの順で一つずつ試します。各変更には機能フラグと設定版を付け、アプリを再配布しなくても旧経路へ戻せるようにします。

API資格情報やProjectを施策ごとに増やす場合も、最小権限と利用額上限を先に設定します。

1. 基準取得: 同じ曜日構成で14日間、件数、費用、P95、品質、再試行を保存します。
2. 固定評価: 通常60件、長文20件、境界10件、停止対象10件の100件を凍結します。
3. ステージング: 本番と分離したProjectで、単価計算、認証、失敗時の記録を検証します。
4. カナリア: 対象要求の5％へ適用し、15分ごとに費用と品質の停止値を確認します。
5. 段階拡大: 25％、50％、100％へ一営業日ずつ進め、評価票を承認します。
6. 切り戻し: 新規ルートを止め、旧設定へ戻し、処理中バッチと状態不明をIDで照合します。

切り戻し時は設定だけでなく、途中データも扱います。キャッシュの接頭辞は旧版へ戻し、モデルは従来スナップショットへ戻します。Batchは投入済み、処理中、完了、失敗を分け、完了結果を破棄して同期APIで全件やり直しません。旧経路へ戻した後、固定評価100件の重大誤り0、成功率99％以上、P95が基準の1.5倍以内を確認して障害を閉じます。

品質を含む100点評価票

費用だけを100点にすると、回答を短くし過ぎる、小型モデルへ寄せ過ぎる、期限を過ぎてもBatchへ送るといった誤った最適化が起きます。採否は品質40点、費用25点、性能15点、運用10点、安全10点で評価します。評価条件と配点は実験開始前に固定し、従来設定と固定評価100件、再試行上限、実行時間帯をそろえて比較します。

85点以上かつ必須条件を全て満たせば段階導入、70〜84点は原因を直して再評価、69点以下は見送りとします。合計点が高くても、重大誤り、期限超過、資格情報露出、費用計算不能が一件あれば不採用です。削減率は「従来の成功要求当たり費用－新方式の成功要求当たり費用」を従来値で割ります。失敗要求を母数から消さず、失敗に使った費用も新方式側へ含めます。

費用欄の算定では、公式料金表が分ける入力・キャッシュ済み入力・出力の単価を使います^[1]。キャッシュ効果は応答のcached_tokensで確かめ^[2]、Batchは公式ガイドが示す割引と完了枠を前提に期限超過を別判定します^[3]。20％削減や85点という閾値は公式値ではなく、本稿の評価例です。

人の確認時間も補助指標として測ります。想定例で、従来は100件を1件30秒確認し50分、新方式は安価でも1件50秒かかり約83分なら、33分の追加作業が生じます。API差額と確認担当の実測時間を別々に示し、金額換算する場合は社内で承認された原価だけを使います。

確認者が見つけた修正件数、差戻し理由、再生成回数を保存し、API請求だけが下がって作業が増えた状態を合格にしません。

費用異常を監視する

監視画面は総額、件数、単価の三段で構成します。総額には時間・日・月の実績と予算消化率、件数には論理要求とAPI試行、単価には成功要求当たり費用を表示します。モデル、機能、Project、同期・Batch、設定版で絞り込み、費用が上がった時刻から該当トレースへ移れるようにします。

Project単位の利用額上限は公式の本番運用資料にも示されています^[5]。入力本文やAPIキーは画面へ表示しません。

一時的な要求増と単価異常を区別するため、警告には費用額だけでなく、要求数、トークン中央値、試行増幅率を添えます。利用額上限へ達してから気付く設計では遅いため、50％、70％、80％で通知先を変えます。通知を受けた担当者はルート設定、直近デプロイ、資格情報の利用元を確認し、原因不明のまま上限だけを引き上げません。月次には推定額と確定額の差もレビューします。

推定額の精度は、絶対誤差÷確定額で管理します。想定例で推定950ドル、確定1,000ドルなら誤差率は50÷1,000×100＝5％です。誤差率が二請求期間続けて5％を超えた場合は、料金表版、追加機能、失敗試行、通貨換算の不足を調査します。

確定前のダッシュボードには推定値であることを明示し、予算残を過大に見せないよう保守的な係数を設定します。モデル単価の変更を検知した日は単価表を更新し、承認履歴を残します。

削減策のテストケース

正常な短文だけでは、キャッシュ不一致、Batchの部分失敗、モデル境界の品質差を見つけられません。ステージングでは本番と同じテンプレート生成処理、キュー、費用台帳を使い、資格情報だけを分離します。各ケースで期待モデル、期待キャッシュ量、最大費用、期限、品質判定を事前に記載し、実行後の数値を書き換えて合格にしないようにします。

合格は100件を三回実行し、重大誤り0、期限超過0、台帳欠損0、資格情報露出0を満たすことです。費用差は三回の中央値で比較し、削減率が目標未満でもプロンプトを不自然に長くしたり回答上限を一律に削ったりしません。再試行を注入した回では、論理要求当たり試行数と失敗費用も含めます。

切り戻し試験では30分以内に旧モデルと同期経路へ戻り、処理中IDを失わないことを確認します。

適用する処理と見送る処理

プロンプトキャッシュは、長い共通指示、固定したツール定義、同じ例示を多数の要求で使う処理に適します。入力の大半が毎回異なる短文、テンプレートを要求ごとに生成する処理では効果が限定的です。キャッシュ率を上げるため顧客データを共通部分へ移すと分離境界を壊すため、機密性を削減より優先します。

出力内容の再利用が目的なら、別の業務キャッシュとして鮮度と権限を設計します。

Batchは、夜間分類、評価、索引作成、翌日利用する下書きなど、24時間以内の完了を許容できる処理に向きます。チャット応答、本人確認、決済前判定、数分以内の顧客通知には適しません。期限を越えた際の手作業がなく、失敗分の再投入もできない業務は移行を見送ります。同期からBatchへ移す前に、依頼元が結果待ち状態を扱えるか確認します。

モデル振り分けは、難易度を入力前後の検証で判定でき、誤りを評価セットで測れる業務に使います。一件の誤判定が重大な法的・金銭的影響を持つ処理、正解データがなく品質差を判別できない処理、自動実行を止められない処理には向きません。その場合は従来モデルを維持し、人の承認、入力削減、出力上限、重複防止から費用を下げます。

小さな経路で検証を始める

最初は月間費用が最大の経路ではなく、固定評価を作りやすく副作用のない一経路を選びます。直近14日分から、論理要求数、API試行数、入力・キャッシュ済み入力・出力トークン、成功要求当たり費用、P95、品質合格率を基準値として保存します。足りない列があれば削減実装より先に費用台帳を追加し、推定額と請求額の差を確認します。

その経路で共通接頭辞を一版だけ固定し、5％のカナリアを一営業日動かします。100点評価票で85点以上、重大誤り0、期限超過0、認証事故0を満たしたら25％へ進めます。停止値へ触れた場合は機能フラグを戻し、処理中IDを照合してから原因を修正します。キャッシュが適さない経路なら無理に続けず、期限に余裕がある処理をBatch候補として別の実験へ切り分けてください。

参考文献・出典

1. OpenAI公式ドキュメント「GPT-5.4 mini」―生成AI APIのコスト計算に使う入力・キャッシュ済み入力・出力の単価（スナップショットgpt-5.4-mini-2026-03-17、ページ更新日表記なし、2026-07-30参照）
2. OpenAI公式ドキュメント「Prompt caching」―プロンプトキャッシュの適用条件とcached_tokensの確認方法（版表記・更新日表記なし、2026-07-30参照）
3. OpenAI公式ドキュメント「Batch API」―非同期バッチの割引、完了枠、JSONL入力と結果照合（版表記・更新日表記なし、2026-07-30参照）
4. OpenAI公式ドキュメント「API Overview」―生成AI APIのBearer認証とAPIキーの管理（REST API v1、API仕様版openai-version: 2020-10-01、ページ更新日表記なし、2026-07-30参照）
5. OpenAI公式ドキュメント「Production best practices」―本番Projectの分離、アクセス制御、レート・利用額上限（版表記・更新日表記なし、2026-07-30参照）