DeepSeek API の請求は「呼び出し回数 × 単価」という単純なものではなく、入力 Token、出力 Token、キャッシュのヒット状況によって決まります。多くのチームは表示価格で予算を組み、公開後に実際のコストが想定より高くなることに気づきます。原因は通常、単価が変わったことではなく、入力の構造、キャッシュヒット率、リトライ回数が見積もり時と違うことです。

本記事では DeepSeek API の課金を計算可能な部分に分解します。どの Token が課金されるか、キャッシュが効くときと効かないときの違い、レスポンスの usage を使った見積もり方法、そしてコスト削減をどの順序で進めるべきかを説明します。具体的な単価はサイト内のモデル価格および DeepSeek 公式ドキュメントを基準にしてください。

注記：DeepSeek は各権利者の商標です。本記事は 2026 年 10 月時点で一般的なインターフェース形態を例にしています。価格、モデル名、課金ルールは変更される可能性があるため、購入前に公式ページを再確認してください。

一、まず請求を 4 つの課金項目に分ける

課金項目 発生するとき 主な影響要因 最適化の方向
入力（キャッシュミス） 新しい内容が初めてコンテキストに入るとき ドキュメント長、履歴メッセージ、ツール定義 検索、要約、切り詰め
入力（キャッシュヒット） 以前キャッシュされたプレフィックスを再利用するとき プレフィックスの安定性、ヒット率 固定プレフィックス、ランダム内容の削減
出力 モデルが本文や構造化結果を生成するとき 出力長、形式の制約 max_tokens、JSON 制約
推論内容 推論モデルが思考過程を生成するとき 問題の難易度、推論レベル 単純なタスクでは推論モデルを使わない

DeepSeek のコンテキストキャッシュは通常、入力側に現れます。ヒットしたプレフィックスはより低い入力価格で課金され、ミスした部分は標準の入力価格で課金されます。キャッシュ保存料が発生するか、キャッシュがどれだけ保持されるかは、公式ドキュメントの現在の説明を基準にしてください。古い記事のルールを流用しないでください。

1 回のリクエストのコストは次の式で表せます。

1 回のコスト =
  キャッシュヒット入力 Tokens × ヒット単価
+ キャッシュミス入力 Tokens × 入力単価
+ 出力 Tokens × 出力単価

この式をログに落とし込んでこそ、「この機能は月にいくらかかるか」に答えられます。コンソールの総請求だけを見ても、どのプロジェクト、どの種類のリクエストがコストを膨らませているかを特定するのは困難です。

二、キャッシュがコストを下げる理由と、効かないことが多い理由

コンテキストキャッシュの基本は、2 つのリクエストの冒頭部分が完全に一致していれば、サーバー側が以前の計算結果を再利用し、追加部分だけを再計算できるというものです。そのため、キャッシュは次のような内容に最も効果があります。

  1. 固定の system prompt と役割設定。
  2. 安定したツール定義、関数スキーマ。
  3. 繰り返し使うナレッジベースの断片、製品マニュアル、契約テンプレート。
  4. マルチターン会話で変化しない前半部分。

逆に、次の書き方はキャッシュを頻繁に無効化します。

  • system prompt の冒頭に現在時刻、ランダム ID、ユーザー名を挿入する。
  • リクエストごとにツールやドキュメントの順序を並べ替える。
  • ドキュメント全体を先頭に置き、その後にユーザーの質問を置く。
  • 同じ業務を異なるモデルや入口の間で切り替える。
  • プレフィックスが短すぎて、再利用できる粒度に達していない。

変化する内容をリクエストの末尾に置き、安定した内容を先頭に置くのが、最も簡単で効果的な方法です。キャッシュは通常ベストエフォートであり、ヒットを確約するものではありません。そのため予算は「一部ヒット」を前提に見積もり、全件ヒットを仮定しないでください。

三、usage フィールドで実際に見積もる

文字数から Token を推測しないでください。呼び出しのたびにレスポンスの usage を記録し、1 週間観察すれば、自社業務の実際の構造が見えてきます。

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["DEEPSEEK_API_KEY"],
    base_url="https://api.deepseek.com",
)

resp = client.chat.completions.create(
    model="deepseek-chat",  # モデル名はサイト内の料金ページを基準にする
    messages=[
        {"role": "system", "content": "あなたはカスタマーサポート助手です。回答は三文以内にしてください。"},
        {"role": "user", "content": "注文の発送後に住所は変更できますか？"},
    ],
    max_tokens=256,
)

usage = resp.usage
hit = getattr(usage, "prompt_cache_hit_tokens", 0) or 0
miss = getattr(usage, "prompt_cache_miss_tokens", 0) or 0

print("入力", usage.prompt_tokens)
print("キャッシュヒット", hit, "ミス", miss)
print("出力", usage.completion_tokens)

レスポンスにキャッシュの内訳フィールドがない場合は、総入力と総出力を記録し、請求書や使用量ページから逆算します。重要なのはフィールドの定義を統一し、日付や入口の異なるデータを混ぜて比較しないことです。

見積もり時には少なくとも、時刻、プロジェクト、モデル、入力 Token、出力 Token、キャッシュヒット、リトライ回数、ストリーミングの有無を記録します。金額は月末に単価を掛けて計算しますが、過程の指標は毎日確認してください。

四、同じ呼び出し量でも請求が数倍違う理由

シナリオ 典型的な Token 構造 コストが膨らむ点 最適化の重点
カスタマーサポート Bot 入力が多く出力が短い 履歴メッセージを毎回送る 要約、キャッシュ、直近数ターンだけに限定
ドキュメント抽出 入力が中程度、出力が構造化 同じドキュメントを繰り返し読む プレフィックスのキャッシュ、バッチ処理
コードアシスタント 入力も出力も大きい ツール結果と長いファイル 検索、分割、出力制限
長文生成 入力が短く出力が長い 出力 Token の累積 分割生成、max_tokens
推論タスク 入力が中程度、出力に思考を含む 思考過程が出力に計上される 単純なタスクは非推論モデルに切り替え

差は通常 5 つの点から生まれます。

  1. 入力と出力の比率が違う：カスタマーサポートと長文執筆ではコスト構造が正反対であり、同じ平均値で見積もれません。
  2. キャッシュヒット率が違う：固定プレフィックスは再利用できますが、動的な内容はキャッシュを無効にします。
  3. コンテキスト長が違う：毎ターン文書全体を入れると、入力コストがターン数に応じて累積します。
  4. リトライ回数が違う：429 やタイムアウト後の再送はリクエスト量を増やします。失敗したリクエストが課金されるかは請求書を基準にしてください。
  5. モデル階層が違う：推論モデルと非推論モデルでは単価も出力長も異なり、ミスマッチは予算を膨らませます。

五、コスト削減の順序を逆にしない

  1. まず定量化：usage とログで各機能の実際の Token 構造を計算します。感覚に頼らないでください。
  2. 次にキャッシュヒットを上げる：system prompt、ツール定義、ナレッジのプレフィックスを固定し、冒頭の動的な内容を減らします。
  3. 次に入力を減らす：RAG では関連する断片だけを取得し、履歴メッセージは要約し、ツール出力は必要なフィールドだけ残します。
  4. 出力を制限する：適切な max_tokens を設定し、JSON や固定フィールドを要求して、繰り返しの説明を減らします。
  5. モデルを振り分ける：分類、抽出、書き換えは軽量モデル、複雑な推論は上位モデルに回します。
  6. 非同期とバッチ処理：リアルタイム性が不要なラベリング、要約、オフライン分析はキューで実行します。
  7. 監視とアラート：プロジェクト、モデル、シナリオの 3 軸で使用量を見て、予算上限を設定します。

順序を逆にすると、よくある結末はこうです。より安いモデルに替えたのに、入力が整理されておらずキャッシュもヒットせず、請求は下がらず品質だけが落ちる。

六、予算と請求の管理方法

  • 1 プロジェクトに 1 Key とし、テストと本番を分けて割当を奪い合わないようにする。
  • Key に消費上限とアラートを設定し、異常な呼び出し時に自動で損失を止められるようにする。
  • 毎週「プロジェクト、モデル、シナリオ」で照合し、最も伸びている呼び出しを見つける。
  • キャッシュやモデル振り分けによる節約分は個別に記録する。そうしないと最適化の効果を証明できない。
  • 人民元での支払いと請求書が必要なチームは、国内 AI ゲートウェイで請求を統一できます。具体的な価格、為替、請求書のルールはモデル価格を基準にしてください。

よくある質問

DeepSeek のキャッシュは手動で有効にする必要がありますか？

通常、キャッシュ対象を明示的に指定する必要はなく、サーバー側がプレフィックスに基づいて再利用を自動判断します。具体的な仕組みと保持期間は公式ドキュメントを基準にしてください。必要なのは設定を増やすことではなく、プレフィックスを安定させることです。

キャッシュヒット率が上下するのはなぜですか？

よくある原因は、プレフィックスにタイムスタンプ、ランダム ID、ユーザー情報が混ざっていること、またはリクエストが異なるモデルや入口の間で切り替わっていることです。まず変化する内容を末尾に移し、1 週間観察してください。

推論モデルの思考内容は課金されますか？

推論モデルが生成する思考 Token は通常、出力に計上されます。具体的な定義は公式ドキュメントと請求書を基準にしてください。単純な分類や抽出タスクでは、既定で推論モデルを使うことは推奨しません。

入力と出力はどちらが高いですか？

多くのモデルでは出力単価が入力単価より高いですが、キャッシュヒット後の入力価格は通常さらに低くなります。2 つの単価だけを比較せず、自社の入力・出力比率で 1 回のリクエストコストを計算してください。

見積もりと請求が合わないのはなぜですか？

よくある見落としには、履歴メッセージ、ツール定義、リトライ、キャッシュミス、長い出力があります。リクエスト ID と使用量ログを照合してこそ、差異を特定できます。

次のステップ

まずZSQH AI Gateway でテスト用 Key を作成し、実際のタスクを 1 週間実行して入力、出力、キャッシュヒットを記録します。その後、モデル価格で予算に換算してください。モデルの可用性と価格は料金ページを基準にしてください。

関連記事：