DeepSeek V4のAPI料金：ピーク時間を日本時間で確認・費用計算

日本時間で先に結論を確認すると、DeepSeek公式APIのピークは月〜金の10:00–13:00と15:00–19:00です。それ以外と週末はオフピークで、各トークン単価はピークの半額になります。

ただし「安い時間に全部回す」は運用方針になりません。夜間評価や期限に余裕のあるバッチは移動できますが、ユーザーが待つチャット、障害対応、決済判断、対話型のコーディングエージェントは遅延コストのほうが大きくなり得ます。見積もりに使う前に、その処理が待てるかを決める必要があります。

本稿の価格は2026年9月7日にDeepSeek公式の料金表で確認しました。価格は変更されるため、大きな予算を確定する前に公式ページを再確認してください。

料金表は三種類のトークンを分けて読む

DeepSeekの公式APIは、入力をキャッシュヒットとキャッシュミスに分け、出力を別単価で計算します。単に「入力800万トークン」と記録するだけでは、請求を再現できません。

すべて100万トークン当たりのUSD価格です。外部のAPI提供サービス、クラウド経由、公開ウェイトを使った自前運用にはそのまま適用できません。上乗せ料金、独自の利用上限、税、通貨換算、失敗時の課金条件が異なる可能性があります。Web／アプリの利用条件とも別です。

モデル選択も時刻だけでは決まりません。自動検証できる大量処理はFlashから始め、Proは実タスクで成功率の向上、再試行の削減、レビュー時間の短縮が確認できる場合に限定するのが堅実です。

キャッシュヒットを含めた計算例

費用は次の三項を足します。

text
費用 = キャッシュヒット入力 ÷ 1,000,000 × ヒット単価
     + キャッシュミス入力 ÷ 1,000,000 × ミス単価
     + 出力 ÷ 1,000,000 × 出力単価

ある日次処理が入力800万トークン、出力100万トークンを使い、入力の75%に当たる600万トークンがキャッシュヒットしたとします。キャッシュミスは200万トークンです。

V4 Flashなら、オフピークは 6 × 0.007 + 2 × 0.22 + 1 × 0.66 = $1.142、ピークは $2.284。V4 Proなら、オフピークは 6 × 0.022 + 2 × 0.66 + 1 × 1.98 = $3.432、ピークは $6.864 です。

同じトークン構成を移動すればAPI料金は半分になります。一方、キャッシュ率を上げる施策は、高いキャッシュミス入力を安いヒット入力に置き換えます。この二つは併用できますが、目的は別です。

また、この算例には追加の再試行、外部サービスの手数料、税、品質低下、待ち時間、手作業の確認が含まれません。安い時間まで待った結果、納期を外して人が再実行したなら、トークン費用だけを半額にしても節約とは言えません。

日本時間の境界をUTCで判定する

公式の基準は月曜から金曜の 01:00–04:00 UTC と 06:00–10:00 UTC です。JSTはUTC+9で夏時間がないため、同じ日の10:00–13:00と15:00–19:00に安定して換算できます。

ここでいう月〜金は、公式料金表のUTC基準の曜日です。日本の祝日を除外する規定ではないため、祝日でも月〜金の該当時間帯はピークとして見積もります。土日は終日オフピークです。

次は処理予定時刻の料金区分を判定する例です。開始時刻を含み、終了時刻を含まない区間として扱います。サーバーのローカル時刻に依存しないよう、タイムゾーン付きの日時をUTCへ変換します。

python
from datetime import datetime, timezone

def estimate_price_band(at: datetime) -> str:
    if at.tzinfo is None or at.utcoffset() is None:
        raise ValueError("Timezone-aware datetime required")
    utc = at.astimezone(timezone.utc)
    minute = utc.hour * 60 + utc.minute
    peak = utc.weekday() < 5 and (
        60 <= minute < 240 or 360 <= minute < 600
    )
    return "peak" if peak else "off_peak"

planned = datetime.fromisoformat("2026-09-07T13:00:00+09:00")
print(estimate_price_band(planned))  # off_peak

これは予定時刻を分類するコードであり、送信した瞬間の単価を固定する仕組みではありません。 公式文書では、料金区分の境界をまたぐ長いリクエストを送信時・推論開始時・完了時のどこで課金判定するかは確認できませんでした。境界直前の実行で安い単価を確保できるとは考えず、余裕を持った予定と実際の利用明細で確認してください。

待てる処理には締切を付ける

オフピークへ移す候補は、入力を保存でき、再実行しても業務結果を重複させず、完了を確認できる処理です。夜間の回帰評価、分類、検索用データの更新、緊急ではないリポジトリ検査などが該当します。利用者が待つ応答や障害対応は、待機による損失も含めて判断します。

たとえば12時30分に受け付けた処理の締切が14時なら、13時からの安い時間へ移せるか、所要時間と再試行の余裕を確認します。締切が12時45分なら、料金だけを理由に13時まで待つことはできません。

実行可能になる時刻 not_before と最終完了期限 deadline_at を分けて持たせると、待てる間だけ待機列に置き、締切が近づいたら実行する判断ができます。再配信には業務上の一意なキーを使い、同じ書き込みや通知を二重に行わないようにします。

記録しておきたいのは、受付・送信・完了時刻、モデル名、ヒット入力・ミス入力・出力の各トークン数、再試行回数、最終状態と費用です。全リクエストを合計する場合、既に含まれた再試行費をもう一度加算しないようにしてください。

オフピークは空き容量の保証ではない

DeepSeekの同時実行上限の公式文書は現在、アカウント当たりFlash 2500、Pro 500の同時実行上限を示し、超過時は HTTP 429 を返すと説明しています。対象アカウントによって増枠の可能性はありますが、オフピークが必ず高速・安定という意味ではありません。

再試行の待ち時間を段階的に延ばし、回数に上限を設けます。長く待機した処理や最終的に失敗した処理を確認できるようにしてください。実際の用途を代表する少量の処理で、成功率、応答時間、再試行、出力長、確認作業の時間を比較します。観測期間を一律に固定せず、必要な処理の違いを確認してから拡大します。

V4 Pro正式版の発表によれば、この時間帯別料金は2026年8月16日16:00 UTCに始まりました。4月のプレビュー版の価格を載せた古い解説と現在の請求が合わない理由はここにあります。価格をコードに永久固定せず、設定と確認日を一緒に管理してください。

他社のAPIも含めて選ぶ段階では、同じ依頼内容、出力上限、再試行条件、合格基準でLLM API料金を比較します。半額になる時間は明確ですが、本当に安くなるのは、処理が期限内に正しく完了した場合だけです。