予算予測 request volume API 運用

毎月の LLM API 支出を予測する方法

毎月の LLM API 支出を予測する方法の実践ガイド。request volume、token ratio、model mix、本番判断、結果確認を扱います。

AveMujica API 2026年6月22日 2 分で読めます

多くのチームは、月次の LLM API コストを過小評価している。理由は、モデルを 1 つずつ個別に見積もり、リトライや出力比率の増大、前払いサブスクリプションを見落としているからだ。信頼できる予測は、使用量を推測ではなくワークシートとして扱う：リクエスト数 × 入力トークン数 × 入力単価 + リクエスト数 × 出力トークン数 × 出力単価を、モデル構成、リトライ率、失敗率、サブスクリプション料金、隠れた使用量のバッファで調整する。プラットフォームが Key 単位、モデル単位、日単位の数値を開示していれば、このワークシートは仮定ではなく実データに基づいて作成できる。

1 枚のワークシートで実用的な予測を作る

単純な月次の式から始め、実際のトラフィックの形に合うまで各変数を展開していく。

Monthly Spend = (Requests × Input Tokens × Input $/1M) + (Requests × Output Tokens × Output Ratio × Output $/1M) + Subscription Fees + Retry Buffer + Hidden Usage Buffer

例えば、サポートアシスタントが月に 10 万リクエストを処理し、平均 4,000 入力トークン、1,200 出力トークン、入力 100 万トークンあたり $2.50、出力 100 万トークンあたり $10.00 のモデルを使う場合、おおよそのコストは次のようになる：

入力：100,000 × 4,000 × $2.50 / 1,000,000 = $1,000
出力：100,000 × 1,200 × $10.00 / 1,000,000 = $1,200
小計：$2,200

その後、以下の調整を適用する。

要因 1：出力比率は固定ではない

出力トークンのほうが一般的に高くつく。なぜなら出力の単価が高く、タスクによって completion トークン数が大きく変わるからだ。一律の仮定ではなく、過去の出力/入力比率を使う。

タスク種別	典型的な出力比率	備考
分類 / 抽出	0.05–0.15	非常に短いラベルや JSON フィールド
要約	0.2–0.4	元の文章より短くなる
チャット / サポート	0.3–0.8	指示やコンテキストに依存
コード生成	0.5–1.5	入力長を超えることもある
推論 / Agent ループ	1.0–3.0	Chain-of-thought で出力が膨らむ

製品が分類タスクからエージェントワークフローへ移行している場合、請求が来る前に高い出力比率で予測を再実行しよう。

要因 2：モデル構成は、ボリュームよりも急速にコストを変える

統一された API サーフェスがあると、モデルの切り替えが容易になり、それはコスト層の切り替えも容易にする。多くのモデルに対応する単一ゲートウェイが価値あるのは、モデル選択がクライアントの書き換えではなくポリシー判断になるからだ。しかし、その利便性の分、予測には重み付きモデル構成を含める必要がある。

小さな表を作る：

モデル層	リクエスト割合	入力 $/1M	出力 $/1M	100 万トークンあたりの重み付きコスト
小型 / 高速	60%	$0.15	$0.60	~$0.31
中型 / 汎用	30%	$2.50	$10.00	~$3.25
大型 / 推論	10%	$15.00	$60.00	~$19.50

リクエスト数が変わらなくても、小型層から大型層へ 10 ポイントシフトするだけで、支出は 2 倍以上になる可能性がある。プロダクト実験中は毎週モデル構成を確認すること。トラフィックを振り分ける前にこれらの差分を発見するのに、公開カタログがどう役立つかはモデル価格の可視化を参照。

要因 3：リトライと失敗は実際のコストだ

リトライロジック、タイムアウト処理、アップストリームエラーはすべてトークンを消費する。観測された失敗率に基づいてリトライバッファを追加する：

低成熟度 / 初期統合： 15–25%
安定的な本番ワークロード： 5–10%
バッチまたは高レイテンシパイプライン： 10–20%

リトライをタダだと思わない。トークン生成前にアップストリームが失敗した場合を除き、リトライされたリクエストも課金対象になる。しかし、それが保証されるわけではない。

要因 4：サブスクリプションと最低料金

多くのプロバイダは、月額サブスクリプション、予約スループット、エンタープライズ最低料金などに容量を束ねている。使用量がコミットを下回っても予測が崩れないよう、トークン価格とは別に計上する。含めるべき項目：

プラットフォームのシート料金
予約容量またはプロビジョンドスループット
サポートティア
ログやキャッシュされたプロンプトの egress やストレージ

要因 5：隠れた使用量

初回の予測で最も見落とされがちなカテゴリ：

Embedding とリランキング： トークン単位だが、チャットとは異なるバッチ処理になる
画像、音声、動画： トークンではなくリクエストやピクセル単位のことが多い
ツール呼び出しのオーバーヘッド： システムプロンプト、関数定義、返却されたツール結果が入力トークンを増やす
キャッシングとコンテキストの増大： 長い会話は各ターンで課金されるコンテキストを蓄積する
評価と合成データ： 合成テスト実行が本番ボリュームに匹敵することもある
シャドウキー： 中央ワークフローの外で作られた統制外のキー

優れた API Key ガバナンスは、アプリごとにスコープ付きキーを発行し、定期的に有効な認証情報を確認することでシャドウキーを排除する。

実データを式に入れる

予測の質は入力データで決まる。仮定を置き換えるために、プラットフォームの機能を使う：

/wallet には、現在の残高、チャージ履歴、グループ別の価格影響が表示される。予測と実際の引き落とし率を突き合わせるのに使う。
/dashboard/overview には、モデル別・Key 別の使用トレンドが表示される。毎月モデル構成と出力比率を更新するのに使う。
/usage-logs/common には、トークン数、レイテンシ、結果ステータスを含むリクエスト単位の記録がある。リトライ率と失敗コストを正確に測定するのに使う。

複数のアップストリームプロバイダーを直接使っている場合、価格比較の前にトークン数を正規化する。プロバイダーによっては、トークン、文字、リクエストのいずれかでカウントする。集中型の使用ログを使えば、その正規化は自動化される。

判断表：予測をどのくらいの頻度で更新するか

状況	予測の頻度	更新内容
安定したワークロード、同じモデル構成	月次	実際の支出 vs 予測、出力比率
活発なプロダクト実験	週次	モデル構成、出力比率、リトライ率
新モデルまたはプロバイダーのロールアウト	ローンチ前とローンチ後 4 週間は週次	価格、失敗率、レイテンシ
予算引き締め	隔週	低層へのモデル構成シフト、隠れた使用量の監査
エンタープライズ交渉	四半期	サブスクリプション、最低料金、コミット使用量

実践的な月次チェックリスト

翌月の予算を確定させる前に：

/usage-logs/common から実際のリクエスト数、入力トークン数、出力トークン数を取得する。
主要モデルごとに出力比率を計算し、前月と比較する。
/dashboard/overview を使って重み付きモデル構成を更新する。
観測された失敗率とリトライ率からリトライバッファを追加する。
サブスクリプションと予約容量料金を固定項目として追加する。
3 か月間の安定したデータが蓄積するまでは、5–10% の隠れた使用量バッファを追加する。
合計を /wallet の引き落としとチャージタイミングで突き合わせる。

価格とプロバイダー契約は頻繁に変わる。最終確認日：2026-06-22。最新のレートについては、OpenAI API 価格、Anthropic Claude 価格、Google Gemini 価格などの公式情報源を参照してください。

予測を運用の一部にする

目標は完璧な予測ではない。目標は、毎月改善され、予想外の支出を防ぐ予測だ。ワークシートから始め、プラットフォームのデータで裏付け、変化の速度に合わせた頻度で見直し、モデル選択を予算を意識した判断として扱う。価格、使用量、ガバナンスが同一のサーフェスに集約されていれば、予測は月末の火消しではなく、日常の運用タスクになる。

AveMujica API が役立つ場面

AI ワークロードが実運用に入ると、課題は「呼び出せるか」から「誰が使い、いくらかかり、失敗時にどう扱うか」へ移ります。AveMujica API はモデルアクセス、価格文脈、ウォレット影響、利用履歴を同じコンソールにまとめます。

まず 1 つの実ワークフローで試します。
モデルアクセス、コスト、ログを同じ場所で確認します。
レイテンシ、支出、所有者が明確になってから対象を広げます。

ゲートウェイは手順を増やすためではなく、キー、請求、プロバイダー制限、障害対応を分散させないために使います。

よくある質問