本番ワークフローにおけるLLMコストの管理
LLMコストで最もよくある驚きは、高額なパイロットではありません。安価なパイロットが高額な本番システムに変わること—あるいは、怖い見積もりのせいで有望なプロジェクトが中止されること—です。両者は異なる経済性で動いているからです。
コストはワークフローの設計特性であって、月末に発見する価格ではありません。コストを制御できるチームは、ワークフロー実行1回あたりのコストを、精度と同じように、設計し、測定し、合否判定する数値として扱います。
パイロットのコストが誤解を招く理由
チャットのパイロットは「席数あたり」の経済性で動きます。20人が1日に数回質問する量は人間の根気で上限が決まり、モデル選択にかかわらず月額は小さくとどまります。本番ワークフローは「イベントあたり」の経済性です。受信メール、文書、Webhookのたびに発火し、量は根気ではなく事業が決め、事業が成長すれば増えます。
パイロットは設計上、最適化されていません。全ステップに大型モデル、コンテキストには文書全文、削る理由がないので検索結果はそのままプロンプトへ。品質検証の方法としては正しく、予算のベースラインとしては誤りです。
失敗は両方向に起きます。あるチームはパイロットを線形に外挿し、5桁ドルの月額を見て、下のレバーで安くできたはずのプロジェクトを中止します。別のチームは「パイロットでは$200だった」と思い込み、2枚目の請求書で本番の経済性を知ります。
コストレバー、効果の大きい順
ステップごとにモデルサイズを合わせる。 ワークフローは1回のモデル呼び出しではなく、難易度の異なる複数のステップです。本当に難しいステップにはフロンティアモデル、分類・ルーティング・抽出には小型モデル。単独で10倍になることも多い、最大のレバーです。
プロンプトとコンテキストの規律。 答えを変えるチャンクだけに検索結果を絞り、静的なシステムプロンプトはキャッシュする。プロンプトキャッシュは、対応環境では繰り返しコンテキストのコストを最大90%程度削減します。
バッチ化と非同期化。 ほとんどのワークフローステップに対話的な応答は不要です。バッチAPIは通常、対話料金の半分程度で、非同期キューはスパイクを平準化します。
繰り返しの回答をキャッシュする。 同じ質問が毎日来るなら、承認済みの回答をキャッシュから返し、外れたときだけモデルを呼ぶ。
出力長を制御する。 出力トークンの単価は通常、入力の5倍程度です。スキーマ制約付きJSONに固定し、ステップごとに最大長を設定し、分類ステップに作文をさせない。
実行1回あたりのコストを受け入れ基準にする。 初日からステップ別・実行別にトークンとコストを記録し、毎回のデモで品質指標の隣にその数値を置く。測らないものは管理できません。
順序が重要です。多くのチームはまずキャッシュの小技に手を伸ばしますが、モデルサイズの適正化とコンテキストの規律だけで、他のすべてを合わせた以上の効果が出るのが普通です。
試算例:月3,000通のサポートメールのトリアージ
標準的なサポートメールのトリアージワークフローを考えます。受信メールを分類し、構造化フィールドを抽出し、返信が必要な約40%に下書きを作る。未最適化なら、1通ごとにスレッド全文と検索したナレッジベースのコンテキストが付き、入力約6,000トークン・出力約800トークンになります。
| 設計 | 1通あたりコスト | 月3,000通 |
| --- | --- | --- |
| 全ステップにフロンティアモデル、フルコンテキスト | 約$0.15 | 約$450 |
| 全ステップに中位モデル、同じプロンプト | 約$0.03 | 約$90 |
| 階層化:小型モデルが分類・抽出、中位モデルが40%の下書きのみ、コンテキスト削減+システムプロンプトのキャッシュ | 約$0.006 | 約$18 |
数値は2026年時点の公開トークン単価レンジから計算した例示です。絶対値ではなく比率を読んでください。25倍の差は値引き交渉ではなく、設計判断から生まれます。
月3,000通ならどの行も支払える金額です。それこそが罠のでき方で、量が強制するまで規律は生まれません。同じワークフローが月30万イベントになると、およそ$45,000と$1,800の差になります。また、下位モデルへの切り替えは一括格下げではなく、評価セットに対してステップごとに検証すべきです—ステップごとの適切なClaudeモデル選定は、それ自体が1つの判断です。
ステップをLLMから外すべきとき
一定の量を超えると、最も安いモデル呼び出しは「やめた呼び出し」です。シグナルは次のとおりです。
ラベルが安定した大量の分類ステップ—ファインチューニングした小型モデル、あるいは埋め込み+古典的な分類器が、ごく一部の価格で同じ仕事をします。
決定的な変換—日付パース、通貨換算、参照、スキーママッピング—は普通のコードの仕事であり、モデル呼び出しにすべきではありません。
同じ回答の繰り返し提供—レビュー済みの出力をキャッシュやルール表に昇格させ、本当に新しいケースだけにモデルを使う。
大量実行時に1つのステップが請求を支配する—ファインチューニングはプロンプト自体を縮められます。調整済みモデルは1回あたりの指示と例が少なくて済むからです。
学習が安くても、ファインチューニングは無料ではありません。データセットの整備、評価、タスクが変わるたびの再学習という維持コストを伴います。月々の削減見込みと維持コストの算術で正当化してください。同じ算術が逆方向にも守ってくれます。月$70の節約のためにファインチューニングすべき人はいません。
当社のスプリントでは、実行1回あたりのコストを受け入れ基準に明記し、週次デモで品質指標の隣にコストダッシュボードを示します—スプリントの構成はパッケージを参照してください。引き渡し時点で、本番の1か月にいくらかかるかを、コミットする前に把握できます。実務的なルール:自分のワークフローの1実行のコストを今日言えないなら、最初に直すべきはモデル選定ではなくそこです。