LLM機能の運用コストは、トークン単価から出した数字の倍になる

LLMを使った機能を本番に載せる前に、必ず聞かれることがある。 月いくらかかるのか。

トークン単価は公開されているので、計算はできる。 ただ、そこで出した数字は、実際の請求額とだいたい合わない。

倍近くずれることもある。 何が抜けているのかを書いておく。

■ まず、素の計算をしてみる

社内向けの問い合わせチャットを例にする。

1日1,000リクエスト。 1リクエストあたり、入力8,000トークン、出力500トークン。

入力が多いのは、RAGで検索した社内ドキュメントをコンテキストに詰めるからだ。 LLMを使った機能では、入力が支配的になることが多い。

Claude Sonnet 5 の単価は、100万トークンあたり入力3ドル・出力15ドル。

入力：8,000 × 1,000 = 800万トークン → 24ドル／日 出力：500 × 1,000 = 50万トークン → 7.5ドル／日

合計で約32ドル／日。 月に約950ドル、日本円で14万円ほど。

ここまでは誰でも出せる。 問題はこの先だ。

■ プロンプトキャッシュで、入力側は下がる

入力8,000トークンのうち、6,000トークンは毎回同じだとする。 システムプロンプトと、固定の参照情報だ。

この部分はキャッシュできる。 キャッシュから読む場合の単価は、通常の約0.1倍になる。

つまり600万トークン分が、24ドルではなく数ドルで済む。 入力側は半分以下に落ちる。

ただし書き込み時は1.25倍（5分保持）または2倍（1時間保持）かかる。 5分保持なら2回目のリクエストで元が取れるが、1時間保持は3回必要になる。

リクエストが散発的にしか来ない機能では、キャッシュが切れ続けて書き込み料だけ払うことになる。 ここは実測しないと分からない。

■ ここから、単価表に載っていない費用が積み上がる

素の計算に抜けているものが3つある。

ひとつ目はリトライだ。 タイムアウト、レート制限、そして出力のJSONパース失敗。 どれも再実行になる。数パーセントは見込む必要がある。

ふたつ目は検証のための二重呼び出しだ。 回答をそのまま返せる用途は少ない。 コンテキストに無いことを喋っていないか、別のLLM呼び出しで検証することになる。

この検証を入れると、単純に呼び出し回数が倍になる。

三つ目は評価だ。 プロンプトを変えるたびに、テストケースを全件流し直す。 これは開発中ずっと発生し続ける。

評価はレスポンスを待つ必要がないので、バッチAPIを使える。 バッチなら単価が半額になるので、ここは必ず使う。

■ 積み上げた結果

先ほどの例に戻る。

キャッシュ適用後で、1日約15ドル。 検証の二重呼び出しで、約1.7倍。 リトライで数パーセント。

月に約800ドル、12万円前後。

素の計算と近い数字に戻ったように見えるが、中身が違う。 キャッシュで下げた分を、検証と再実行で食い潰している。

キャッシュを実装していなければ、月20万円を超える。

■ 一番大きい費目は、推論費用ではない

ここが本題だ。

月12万円の推論費用に対して、この機能を維持するために何時間使うか。

回答品質のレビュー。 プロンプトの調整。 モデル更新への追従。

月20時間使えば、エンジニア単価から逆算して、推論費用より人件費のほうが大きくなる。

LLM機能のコストは、実質的には人件費だ。 トークン単価の議論に時間をかけても、桁が変わることはない。

削るべきは、運用に人手がかかる設計のほうだ。

■ 見積もりの立て方

だから、着手前にこう出す。

まず1リクエストあたりのトークン数を実測する。 推定しない。代表的な入力を10件ほど流して測る。

次にリクエスト数を想定する。 ピーク時と平常時を分ける。

そこに係数を掛ける。 検証の呼び出し回数、リトライ率、評価の実行頻度。

最後に、運用に何時間かかるかを見積もる。 ここを出さない見積もりは、意味のある数字にならない。

■ 単価は動く

最後にひとつ。

モデルの単価は変わる。 新しいモデルが出れば旧モデルは値下がりし、導入価格が設定されることもある。

だから見積もりを固定値で持たない。 単価を設定値として外に出し、トークン数のほうを資産として持つ。

トークン数の実測値さえあれば、単価が変わっても再計算は一瞬で終わる。