生成AIの請求が読めない会社へ トークン課金を“原価”に落とす方法
- 開発部
- 2 日前
- 読了時間: 5分
こんにちは！株式会社雲海設計の技術部です。
生成AIを業務に入れた会社が次にぶつかる壁。それは「請求が読めない」問題です。
月末の請求が「想定の2〜5倍」になる
使えば使うほど価値は出るのに原価が読めずに止まる
予算を守ろうとして利用制限 → 現場が回らない
この状況、システム開発でいうと「見積もりが崩壊する事件」と構造が同じです。
犯人は“技術力不足”ではなく設計と運用（＝原価管理）の不在。
今回はトークン課金を「経費」ではなく原価として扱える形に落とす、現実的な方法を解説します。
事件現場：なぜ請求が“読めない”のか
1) トークンは「従量課金」だが、従量の中身が増殖する
トークンはテキスト処理の最小単位で入力（prompt）と出力（completion）で別々にカウントされます。
つまり料金はざっくりこうです。
料金 ≒（入力トークン×入力単価）＋（出力トークン×出力単価）＋（付帯コスト）
しかし現場では入力トークンが静かに肥大化します。
典型が「会話履歴の積み上がり」と「長大なシステムプロンプト」です。
FinOps Foundationはこの“長いコンテキストの税金”を Context Window Tax として明示し、「安いモデルが最安とは限らない」と警鐘を鳴らしています。
2) “見えるコスト”だけ見て、損失が日常に溶ける
これは「テストのコストは見えるが、テスト不在の損失は日常に溶ける」という話と同型です。
生成AIも単価（$/1M tokens）は見える一方で、以下が溶けます。
無駄に長い指示文（毎回送っている）
過剰な出力（必要以上の文章量）
リトライ・再生成（“もう一回”が高い）
ツール実行（検索・コード実行など）の付帯コスト
まず“原価”の定義を決める：AI原価の内訳テンプレ
生成AIを原価として扱うには、内訳を分解して再現性のある式にする必要があります。
AI原価（1リクエスト）の基本式
AI原価
=（入力トークン − キャッシュヒット分）× 入力単価 +（キャッシュ入力トークン）× キャッシュ単価
+（出力トークン）× 出力単価
ツール / 周辺コスト（検索、ストレージ、監視、ネットワーク等）
オーバーヘッド（運用・ガバナンス工数）
OpenAIの料金表でも通常入力に加えて cached input tokens（キャッシュ入力）の単価が別建てで提示されています。
“読める請求”に変える 7ステップ（実務の順番）
Step 1：ユースケース単位で「成果物」を定義する
原価計算はまず「何を1単位の成果とするか」からです。
（一例）
問い合わせ一次回答：1件
議事録要約：1会議
見積レビュー：1案件
社内規程ドラフト：1本
ここが曖昧だと原価を落としても意思決定に使えません（＝“要件が曖昧”と同じ死に方）。
Step 2：ログで「トークン×ユースケース」を紐づける
最低限ほしいログはこれだけです。
use_case_id（例：support_reply / minutes_summary）
model（モデル名）
input_tokens / output_tokens / cached_input_tokens
latency / retry_count
生成物の品質メタ（採用率、修正回数、再生成回数）
Step 3：単価テーブルを作る（プロバイダ混在前提）
トークン単価はベンダーにより異なり、同一ベンダーでも入力 / 出力・キャッシュで差があります。
例として、OpenAIは入力 / キャッシュ入力 / 出力の単価を提示しています。
GoogleのGemini APIもトークン課金（画像出力はトークン換算）を明記しています。
Amazon Bedrockもモデルごとに input / output 単価で提示しています。
ポイント：「最安単価モデル」ではなく「ユースケース原価が最安」のモデルを選ぶ
これはFinOps Foundationが指摘する通りです。
Step 4：原価を「1成果」へ集約する（これが経営に効く）
例：問い合わせ一次回答（1件）のAI原価
1件あたり平均：input 2,000 / output 600
単価はモデルで変わるが、式は固定
ここで初めて、
人件費（オペレータ 1件あたり工数）
外注費（BPO単価）
既存FAQ整備費と比較できるようになります。
Step 5：原価を下げる “三種の神器”
① 出力を絞る（最速で効く）
出力トークンは入力より単価が高いことが多く、出力が増えるほど原価が読みにくくなります（勝手に長文を出す）。「結論 → 理由3点 → 次アクション」などフォーマット固定が効きます。
② キャッシュを使う（同じ前提文を毎回払わない）
OpenAIのPrompt Cachingは「繰り返しの多いプロンプトを安く・速くできる」設計で入力コスト最大90%削減をうたっています。
Amazon Bedrockもプロンプトキャッシュの割引（例：90%）を案内しています。
③ バッチ化する（非同期・まとめ処理）
Amazon Bedrockはバッチ推論を「オンデマンドより50%低い価格」と説明しています。
議事録要約やレポート生成、バックオフィスの定型文生成などはバッチが刺さります。
Step 6：ガードレール（予算上限と停止スイッチ）を設計する
1ユースケースあたり トークン上限
1人 / 1日あたり コスト上限
高額ルート（長文入力・高性能モデル）への 昇格条件
これがないとプロジェクトは“仕様変更の無制限投入”で崩壊するのと同じ経路を辿ります。
Step 7：ショーバック（見える化）→チャージバック（按分）
最初から「課金」すると反発が出ます。
まずは部署別・ユースケース別に見える化して「どこが伸びているか」「どこが無駄か」を潰す。次に按分へ移行が現実的です。
“Context Window Tax”を潰す：現場で起きる増殖パターン3つ
FinOps Foundationが問題視するのはまさにここです。
会話履歴の積み上げ（気づくと入力が10倍）
巨大な前提文（規約・マニュアル全文）を毎回投げる
検索結果や添付を丸ごと突っ込む
対策はシンプルで、設計の話です。
履歴は「要約して保持」「必要部分だけ再注入」
前提文はキャッシュ前提で固定化（または参照ID化）
検索結果は「根拠段落だけ」投入
まとめ：原価に落ちれば、生成AIは“止めどき”が消える
生成AIの請求が読めないのはツールが悪いのではなく、原価の定義と運用が無いからです。
これは「テスト」や「要件定義」と同じで技術課題ではなく経営課題として処理すると一気に前に進みます。
成果（1単位）を決める
トークンをログで紐づける
単価テーブルで原価化する
キャッシュ / 出力制御/バッチで最適化
上限と停止スイッチで暴走を止める
これで生成AIは「怖い従量課金」から「改善できる原価」になります。
【参考文献（最終アクセス：2026-02-03）】
1. OpenAI Help Center「What are tokens and how to count them?」
2. OpenAI「API Pricing」
3. OpenAI Docs「Prompt caching」
4. OpenAI Developers（Cookbook）「Prompt Caching 101」
5. FinOps Foundation「GenAI FinOps: How Token Pricing Really Works」
6. Google（Gemini API）「Pricing」
7. Amazon Web Services「Amazon Bedrock Pricing」
8. AWS Documentation「Amazon Bedrock pricing（User Guide）」
9. AWS Blog「Reduce costs and latency with Amazon Bedrock intelligent prompt routing and prompt caching (preview)」
コメント