DeepSeek APIの料金：日本時間のピークと費用計算

DeepSeek公式APIのピークは、日本時間で月〜金の10:00〜13:00と15:00〜19:00です。この時間帯の単価はオフピークのちょうど2倍で、土日と中国の祝日は終日オフピークになります。日本の業務時間とほぼ重なるため、日中に回している処理ほど影響を受けます。

単価も2026年9月10日に変わりました。現行モデルは deepseek-flash（DeepSeek-V4.1-Flash）と deepseek-v4-pro の2つで、Flashはオフピークで100万トークンあたり入力（キャッシュミス）$0.15、出力$0.60です。旧名の deepseek-v4-flash を指定したままでも動きますが、処理するのはV4.1-Flashで、請求もFlashの新単価です。Proの単価は据え置きです。

以下の単価は2026年9月26日時点のDeepSeek公式の料金表に基づきます。価格は予告なく変わることがあるため、予算を確定する前に公式ページを見直してください。

現行の単価表

DeepSeekの請求は、キャッシュヒット入力、キャッシュミス入力、出力の3種類を別々の単価で計算します。「入力800万トークン」とまとめて記録しても請求額は再現できないので、見積もりの段階から3つに分けて数えます。

いずれも100万トークンあたりのUSD価格で、2026年9月26日時点の公式料金表の値です。人民元建ての料金表も同じ比率で、Flashのオフピークはキャッシュミス入力1元、出力4元です。

2つのモデルは料金以外にも違いがあります。どちらもコンテキスト長は1M、最大出力は384Kで、思考モードと非思考モードを切り替えられます。画像入力に対応するのはFlashだけで、Proは非対応です。アカウントあたりの同時実行上限はFlashが2,500、Proが500です。

この表はDeepSeek公式APIの料金です。同じモデルを扱う外部のAPI中継サービスやクラウド経由の利用は別契約で、上乗せ料金、通貨、利用上限、時間帯の扱いが公式と同じとは限りません。購入先による違いはLLM APIの最安プロバイダー：同じモデルを購入先別に比較で整理しています。

8月から9月にかけて変わったこと

8月以前の単価表や試算がいまの請求と合わない場合、原因はたいてい次の3つの変更のどれかです。

9月10日の値下げで、Flashの単価は旧V4 Flashの表と比べて、キャッシュヒット入力が57%、キャッシュミス入力が32%、出力が9%下がりました。旧表のオフピーク単価はキャッシュヒット$0.007、キャッシュミス$0.22、出力$0.66です。Flashの入力を$0.22や$0.44としている解説は、9月10日より前の単価のままです。

モデル名も整理されました。deepseek-v4-flash と deepseek-v4-flash-vision-exp は旧モデルが終了したあと、互換のために一時的にV4.1-Flashへ振り向けられています。公式は新しいモデル名として deepseek-flash を案内しており、この転送がいつまで続くかは明記されていません。設定ファイルやSDKの呼び出しは、早めに deepseek-flash へ書き換えておくのが安全です。

Proは9月14日以降も提供が続き、公式の更新履歴は課金方法を変えないと説明しています。Proの単価は8月の正式版以降と同じです。

日本時間では業務時間の大半がピーク

公式の基準はUTCで、月曜から金曜の 01:00〜04:00 と 06:00〜10:00 がピークです。日本時間はUTC+9で夏時間がないため、年間を通じて次のように換算できます。

9時から18時の勤務で考えると、9時台と13時〜15時の昼の2時間を除く6時間がピークに入ります。日中に社員が使うチャットボットや社内ツールは、ほとんどの呼び出しがピーク単価になると見込んでおくのが現実的です。

祝日の扱いには注意が必要です。オフピークになるのは中国の祝日で、日本の祝日ではありません。日本の祝日でも平日なら、上の時間帯はピーク単価です。反対に、国慶節の連休のような中国の祝日は、日本では平日でも終日オフピークになります。具体的な日付は中国政府が公表する休日カレンダーで確認してください。中国で土日を振替出勤日にする場合の扱いは料金表に書かれていないため、見積もりは文言どおり土日＝オフピークとし、実際の利用明細で確かめます。

処理を予約するシステムでは、予定時刻の区分をコードで判定できます。サーバーのローカル時刻に左右されないよう、タイムゾーン付きの日時をUTCに変換して判定します。ピークの時間帯（UTC 1:00〜10:00）は北京時間でも同じ日付に収まるので、中国の祝日は北京時間の日付で照合します。

from datetime import date, datetime, timedelta, timezone

BEIJING = timezone(timedelta(hours=8))

def price_band(at: datetime, cn_holidays: set[date]) -> str:
    if at.tzinfo is None or at.utcoffset() is None:
        raise ValueError("タイムゾーン付きの datetime が必要です")
    utc = at.astimezone(timezone.utc)
    if utc.weekday() >= 5 or at.astimezone(BEIJING).date() in cn_holidays:
        return "off_peak"
    minute = utc.hour * 60 + utc.minute
    peak = 60 <= minute < 240 or 360 <= minute < 600
    return "peak" if peak else "off_peak"

# 中国の祝日は公式の休日カレンダーから入力する
cn_holidays: set[date] = set()

print(price_band(datetime.fromisoformat("2026-09-28T10:30:00+09:00"), cn_holidays))  # peak
print(price_band(datetime.fromisoformat("2026-09-28T13:30:00+09:00"), cn_holidays))  # off_peak

開始時刻を含み終了時刻を含まない区間として判定しています。これは予定時刻の分類であり、送信した瞬間の単価を保証するものではありません。境界をまたぐ長いリクエストを、送信時・推論開始時・完了時のどの時点で判定するかは公開文書に記載がありません。12:55に投げた長い処理が安い単価で済むとは考えず、境界の前後には余裕を持たせてください。

キャッシュを含めて費用を計算する

1回の処理の費用は、3種類のトークンを単価ごとに足して求めます。

費用 = キャッシュヒット入力(100万単位) × ヒット単価
     + キャッシュミス入力(100万単位) × ミス単価
     + 出力(100万単位) × 出力単価

例として、入力800万トークン、出力100万トークンの日次バッチを考えます。入力の75%にあたる600万トークンがキャッシュヒット、残り200万トークンがキャッシュミスです。

再試行、ツール呼び出しの追加入力、税、為替は含めていません。この試算から、判断に効く点が3つ読み取れます。

1つ目に、Flashの費用の約65%は出力です。キャッシュミス入力の単価はヒットの50倍ありますが、キャッシュ率をさらに上げても削れるのは入力部分だけです。出力の長さを抑えるほうが、Flashでは効果が大きくなります。

2つ目に、モデルの選択は時間帯より費用への影響が大きくなりました。値下げ前、この構成でのProとFlashの差は3.0倍でしたが、いまは3.74倍です。Proのオフピーク$3.432は、Flashのピーク$1.836より高くなります。Proは、実際のタスクで成功率の向上や再試行・確認作業の削減が確かめられた処理に絞るのが堅実です。

3つ目に、時間をずらして得られる金額は規模しだいです。Flashのこのバッチを平日22日分ピークからオフピークへ移すと、差額は1日$0.918、月に約$20です。Proなら同じ条件で1日$3.432、月に約$76になります。この金額と、待つことで生じる遅れや運用の手間を比べて決めます。

移す価値があるのは待てる処理だけ

オフピークへ移す候補は、入力を保存しておけて、再実行しても結果が重複せず、完了を確認できる処理です。夜間の回帰評価、大量の分類、検索用データの更新、急がないコードレビューなどが当てはまります。一方、利用者が応答を待つチャット、障害対応、対話しながら進めるコーディングエージェントは、待たせることによる損失のほうが大きくなりがちです。

日本時間で考えると、移し先は3つあります。昼の13:00〜15:00、平日19:00以降の夜間、そして土日です。たとえば12:30に受け付けた処理の締切が14:00なら、13:00からの枠へ移して所要時間と再試行の余裕が収まるかを確認します。締切が12:45なら、単価だけを理由に13:00まで待つことはできません。

仕組みとしては、実行してよい最早時刻 not_before と、完了期限 deadline_at を別々に持たせます。待てる間だけ待機列に置き、期限が近づいたらピークでも実行します。再送には業務上の一意なキーを使い、同じ書き込みや通知を二重に行わないようにします。

費用を後から検証できるよう、受付・送信・完了の時刻、モデル名、キャッシュヒット入力・キャッシュミス入力・出力のトークン数、再試行回数、最終状態を記録しておきます。全リクエストを合計するときは、すでに含まれている再試行分を二重に数えないようにしてください。

オフピークでも同時実行上限は同じ

オフピークは単価が半額になる時間帯であり、処理能力の余裕を約束するものではありません。同時実行上限の公式文書では、アカウントあたりの上限は deepseek-flash が2,500、deepseek-v4-pro が500で、超えると HTTP 429 が返ります。増枠は申請でき、追加料金はかからないと説明されています。

夜間や土日に処理をまとめると、同時実行数が上限に近づきやすくなります。再試行の間隔を段階的に延ばし、回数に上限を設け、最後まで失敗した処理を人が確認できるようにしてください。本番の規模に広げる前に、実際の用途を代表する少量の処理で、成功率、応答時間、再試行回数、出力の長さを比べておくと、見積もりと請求のずれを早めに見つけられます。

他社のモデルも含めて単価を比べる場合は、AI API 料金比較：主要5社の単価と最安モデルの選び方が参考になります。DeepSeekでは半額になる時間帯がはっきりしていますが、実際に安く済むのは、処理が期限内に正しく完了したときだけです。