著者注：DeepSeek API にピーク・オフピーク価格とツール課金が導入されて以降、従来の「単価 × Token」による見積もりは通用しなくなりました。本記事では 5 つのステップで、時間帯、Token の種類、キャッシュ、ツール呼び出しという 4 つの観点から、アプリの実際の呼び出しコストを再計算します。
多くの開発者のコスト表は、まだ「入力単価 × 入力 Token + 出力単価 × 出力 Token」というレベルにとどまっています。DeepSeek API に ピーク・オフピーク価格とツール呼び出し課金 が導入されてから、この式には 2 つの変数が欠けるようになりました。リクエストがどの時間帯に発生したか、そしてツールを何回呼び出したかです。同じアプリ、同じ Token 使用量でも、時間帯を変えて実行すると、請求額に差が出ることがあります。
これは価格の転載記事ではありません。本文では、検証されていない単価は一切提示しません。すべての価格、時間帯割引、キャッシュの基準については、APIYI 価格ページ docs.apiyi.com/models のリアルタイムデータおよび DeepSeek 公式発表を基準にしてください。本記事が解決するのは方法論の問題です。価格表を入手した後、それをいかにして自分の業務ログに正しく当てはめるか、ということです。
コアバリュー：本記事を読み終えると、再利用可能な DeepSeek API コスト試算フレームワークを手に入れ、どのリクエストをオフピーク時間帯に移す価値があるか、どのツール呼び出しを削減する価値があるかを判断でき、さらに正確な価格データをどこから取得すべきかが分かります。
DeepSeek API のピーク・オフピーク価格設定後のコストの要点
最近、DeepSeek の商業化の動向に関するメディアの議論が明らかに増えています（たとえば 36Kr の記事「梁文锋下山，DeepSeek在找什么？」など）。価格体系の変化も開発者が注目するポイントです。背景にある商業ロジックが何であれ、呼び出し側にとって最も直接的な影響は、コストモデルが「一次元」から「多次元」に変わったことです。まずは新しいコスト構成を下表で整理します。
| コスト軸 | 説明 | 試算への影響 |
|---|---|---|
| 時間帯係数 | ピーク時とオフピーク時で異なる課金基準が適用される | リクエスト時刻ごとにバケット分けして集計する必要があり、全時間帯の平均値は使えない |
| 入力 Token（キャッシュヒット） | コンテキストキャッシュにヒットした入力部分 | 単価がミス部分と異なるため、別途集計が必要 |
| 入力 Token（キャッシュミス） | 初回出現またはキャッシュ失効した入力 | 長い System Prompt を使うアプリでは比率が最大になる |
| 出力 Token | 推論モデルの思考プロセス Token を含む | 推論系モデルは出力量が過小評価されがち |
| ツール呼び出し費 | 呼び出し回数などの基準で課金されるツール利用 | 新たに加わった独立のコスト項目で、Token も連動して増える |
価格の具体的な数字を表に入れていないのは、意図的なものです。DeepSeek の価格は過去に何度も調整されており、以前には夜間のオフピーク割引を導入した後に方針を変更したこともあります。ある日に見た数字をコストモデルにハードコードすると、数か月後には誤ったデータになってしまいます。正しい方法は、単価をモデルの「入力パラメータ」にして、価格ページからリアルタイムに読み込むことです。
DeepSeek API の時間帯課金の要点を詳しく解説
ピーク・オフピーク価格設定の本質は、算力のアイドル時間帯を、実行を遅らせてもよいタスクに還元することです。試算においては、3 つの細かい点が最も間違えやすいところです。第一はタイムゾーンです。公式の時間帯は通常、北京時間（UTC+8）で定義されていますが、多くのサーバーログはデフォルトで UTC 時間を記録しています。変換しないと、リクエストの集団ごと誤ったバケットに振り分けてしまいます。第二は時間帯をまたぐリクエストです。長時間のストリーミング出力を伴うリクエストは、ピーク時に始まりオフピーク時に終わることがあります。リクエストの開始時刻と終了時刻のどちらで課金するかは、公式ルールに従う必要があります。第三はリトライです。失敗してリトライしたリクエストは別の時間帯にずれ込むことがあり、実際に成功したリクエストの時刻で計算すべきです。
DeepSeek API のツール課金の要点を詳しく解説
ツール課金の落とし穴は「二重課金」にあります。Web 検索のようなツールを例にすると、1 回の呼び出しで回数ベースのツール費が発生する可能性があるうえ、ツールが返した結果はコンテキストに注入され、次のラウンドの入力 Token としてもう一度課金されます。モデルが 1 回の会話の中でツールを 3〜4 回連続で呼び出すと、コンテキストの蓄積に伴って Token コストはどんどん膨らんでいきます。そのためツールコストを試算するときは、「呼び出し回数」と「ツール結果によって増える追加の入力 Token」の両方を集計する必要があり、どちらも欠かせません。
DeepSeek API 呼び出しコストのクイックスタート：5ステップで再計算
以下の手順では、コードを一切書く必要はありません。ログのエクスポートと表計算ソフトだけで完了します。すでにデータ基盤をお持ちの場合は、これらのステップを SQL やレポートに置き換えてください。
ステップ 1：価格パラメータ表を準備する
まず「価格パラメータ表」を作成します。各行が1つの課金変数で、単価はすべて価格ページから取得し、取得日も記録します。このステップが、以降のすべての計算の正確性を左右します。
| 変数名 | 意味 | データソース |
|---|---|---|
| ピーク時キャッシュヒット入力単価 | ピーク時間帯にキャッシュがヒットした入力価格 | APIYI 価格ページ docs.apiyi.com/models |
| ピーク時キャッシュミス入力単価 | ピーク時間帯にキャッシュがミスした入力価格 | APIYI 価格ページ docs.apiyi.com/models |
| ピーク時出力単価 | ピーク時間帯の出力トークン価格 | APIYI 価格ページ docs.apiyi.com/models |
| オフピーク時対応3項目単価 | オフピーク時間帯の入力・キャッシュ・出力価格 | APIYI 価格ページおよび公式告知 |
| ツール呼び出し単価 | 各ツールの課金基準と単価 | APIYI 価格ページおよび公式告知 |
| 時間帯の境界 | ピーク・オフピークの開始終了時刻とタイムゾーン | DeepSeek 公式告知 |
💡 データソースの推奨事項：価格パラメータ表は APIYI 価格ページ docs.apiyi.com/models と定期的に照らし合わせて更新し、表に「取得日」を明記してください。公式が価格改定を行った場合でも、この表を修正するだけで、コストモデル全体に自動的に反映されます。
ステップ2：タイムスタンプ付きの使用量ログをエクスポートする
各リクエストのログには、少なくとも次のフィールドを含める必要があります。リクエスト開始時刻、モデル名、入力Token数、そのうちキャッシュヒットしたToken数、出力Token数、ツール呼び出し回数とツール種別です。DeepSeekのレスポンスでは、usageフィールドにキャッシュヒット／ミスのToken統計が返され、推論モデルの思考Tokenも出力に計上されます。ログが総Token数しか記録していない場合は、まず計測ポイント（インストルメンテーション）を補うことをおすすめします。そうしないと、後続の試算はあくまで概算になってしまいます。
ステップ3：時間帯ごとにバケット分けする
タイムスタンプをすべて北京時間に統一し、ピーク／オフピークの境界に基づいて各リクエストに「ピーク」または「オフピーク」のラベルを付けます。さらに1時間単位で細分化しておくと、業務トラフィックの波形が見えるようになり、その後のスケジューリングの根拠になります。多くのチームはこのステップを終えて初めて、かなりの割合のリクエストが実は定期実行タスクに由来しており、オフピーク時間帯に移せることに気づきます。
ステップ4：項目ごとにTokenコストとツールコストを計算する
時間帯バケットごとに、それぞれ次のように計算します。Tokenコスト = キャッシュヒット入力 × 該当単価 + キャッシュミス入力 × 該当単価 + 出力 × 該当単価、ツールコスト = 各種ツールの呼び出し回数 × 該当ツール単価です。最後にピークとオフピークの2つのバケットを合算すれば、それが新しい基準での総コストになります。
ここでは単価を使わず、利用量だけで示すイメージを見てみましょう。あるカスタマーサポートアプリが1日あたり10,000リクエストを処理し、1回あたりの平均入力が3,000 Token（うち約6割がキャッシュヒット）、出力が500 Token、平均で5回に1回の割合で検索ツールが呼び出されるとします。この場合、1日あたり約1,200万のキャッシュヒット入力Token、約1,800万のキャッシュミス入力Token、約500万の出力Token、約2,000回のツール呼び出しが発生し、さらにツール結果の書き戻しによって追加の入力Tokenも生じます。これらの数量をピークとオフピークの比率で分解し、価格パラメータ表の単価を掛け合わせれば、実際の日次コストが算出できます。
ステップ5：旧基準と比較し、最適化の余地を見つける
新しい基準での結果と、従来の「単一平均単価」による見積もりを並べて比較すると、差額が最も大きい部分が最適化の重点になります。よくある結論は3つです。ピーク時間帯の比率が高すぎる、ツール呼び出しが頻繁すぎる、キャッシュヒット率が低すぎる、というものです。次のセクションでは、この3つそれぞれに対する具体的な方法を紹介します。
🚀 クイックスタート：同一のインターフェース上でDeepSeekと他のモデルのコスト差を試したい場合は、APIYI apiyi.com から呼び出せます。APIYIは本記事で扱うDeepSeekモデルのAPIを提供しており、OpenAIとAnthropicの両方のインターフェース形式に対応しています。既存のコードは通常、base_urlとAPI Keyを変更するだけで接続でき、具体的なアドレスとパラメータはドキュメントセンター docs.apiyi.com をご覧ください。
DeepSeek API のピーク・オフピーク料金におけるユースケースとコスト戦略
アプリケーションの種類によって、ピーク・オフピーク料金やツール課金への感度は大きく異なります。まず自分がどのタイプに属するかを見極め、そのうえで最適化の方向性を決めるほうが、一律に「全部を夜間に回す」より効果的です。
| アプリケーション種別 | 時間帯の柔軟性 | ツール依存度 | 推奨戦略 | 利用可能プラットフォーム |
|---|---|---|---|---|
| オンラインカスタマーサポート / 対話ボット | 低。リアルタイム応答が必須 | 中 | キャッシュヒット率を高め、ツール呼び出しを簡素化 | APIYI apiyi.com、DeepSeek 公式 |
| ドキュメントのバッチ処理 / データアノテーション | 高。遅延実行が可能 | 低 | すべてオフピーク時間帯にスケジューリング | APIYI apiyi.com、DeepSeek 公式 |
| AI 検索 / リサーチアシスタント | 中 | 高 | ツール呼び出しのラウンド数を制御し、コンテキストに戻す内容を圧縮 | APIYI apiyi.com、DeepSeek 公式 |
| コード Agent | 中 | 高 | ツール呼び出しを統合し、コンテキストを短縮 | APIYI apiyi.com、DeepSeek 公式 |
| コンテンツ生成の定期タスク | 高 | 中 | オフピーク時にバッチ生成し、ピーク時はレビューのみ行う | APIYI apiyi.com、DeepSeek 公式 |
リアルタイム系アプリケーションの DeepSeek API コスト最適化
リアルタイムアプリケーションはピーク時間帯を避けられないため、キャッシュとツールに重点を置くべきです。固定不変のシステムプロンプト、ナレッジベースの要約、Few-shot 例をメッセージの先頭に置き、バイト単位で同一に保つと、キャッシュヒット率を大幅に高められます。ツールについては、まず一度の軽量な判断で「本当に検索が必要か」を決め、モデルが不要な場面で繰り返し呼び出さないようにします。
オフライン系アプリケーションの DeepSeek API オフピーク・スケジューリング
オフラインタスクはピーク・オフピーク料金の最大の受益者です。考え方は、業務システムとモデル呼び出しの間にタスクキューを1層追加し、ピーク時はキューへの投入だけを行い、オフピーク時に処理ワーカーがまとめて実行するというものです。注意点は2つあります。1つはオフピーク時は同時実行が集中するため、事前にレート制限を見積もり、必要に応じてバッチ単位で制限をかけること。もう1つは、タスクにタイムアウト時のフォールバックを設け、オフピーク時に処理しきれなかったタスクが次のピーク時間帯にずれ込み、かえって高額で精算されるのを防ぐことです。
DeepSeek API ツール課金の最適化案の比較
ツール課金は比較的新しく追加された項目であり、同時に最も制御しにくい項目でもあります。その消費量はモデル自身の判断に委ねられているからです。以下では、よく使われる制御手法をいくつか比較します。
| 最適化案 | コスト削減の源 | 適用シーン | 注意点 |
|---|---|---|---|
| 事前インテント判定 | 不要なツール呼び出し回数を削減 | 検索アシスタント、カスタマーサポート | 判定自体もTokenを消費するため、軽量なプロンプトを使う |
| 最大呼び出しラウンド数の制限 | 1リクエストあたりのツール費用に上限を設定 | Agent系アプリ | ラウンド数が少なすぎると回答品質に影響する可能性がある |
| ツール戻り値の圧縮 | コンテキストへの再投入で発生する入力Tokenを削減 | 検索・リトリーバル系ツール | 要約と主要フィールドのみを残す |
| 結果キャッシュの再利用 | 同一クエリの重複呼び出しを回避 | ホットな質問が集中するシーン | 適切な有効期限を設定し、情報の陳腐化を防ぐ |
| 自前検索による代替 | 有料ツールを自社ナレッジベースで代替 | 領域知識が安定している業務 | 自社構築・保守のコストを見積もる必要がある |
比較の読み解き
事前インテント判定は呼び出し頻度に対して最も直接的な効果があり、多くの対話シーンに適しています。ただし、リクエストごとに短い判定処理のオーバーヘッドが加わるため、短い対話ではかえって割に合わないことがあります。これに対し、ツール戻り値の圧縮はほぼ副作用がなく、ツールを伴うすべてのアプリでデフォルトで有効にすべき手法です。最大呼び出しラウンド数の制限はどちらかというとヒューズのような役割で、特定のリクエストがモデルによるツールの繰り返し呼び出しで異常な請求を生むのを防ぐために使います。
💡 選択のヒント：ツールコストの最適化効果は業務によって大きく異なるため、まず小規模なトラフィックでA/B比較を行うことをおすすめします。APIYI apiyi.com を使えば、同一のインターフェース形式のまま異なるモデルを切り替えて対照テストができます。価格ページ docs.apiyi.com/models のリアルタイム単価と組み合わせれば、各案の実際の効果をより早く把握できるでしょう。
よくある質問（FAQ）
Q1: DeepSeek API のピーク・オフピーク料金とは何ですか？
ピーク・オフピーク料金とは、同じモデルでも時間帯によって異なる課金基準が適用される仕組みです。通常、アイドル時間（オフピーク）は価格が低く設定され、遅延可能なタスクを時間帯をずらして実行させることで計算資源の利用を平準化する狙いがあります。具体的な時間帯の境界や割引幅は、DeepSeek の公式発表および APIYI の料金ページをご確認ください。
Q2: ピーク・オフピーク料金は従来の一律料金と比べて、試算方法にどのような違いがありますか？
一律料金では「総トークン数 × 単価」を計算するだけで済みます。一方、ピーク・オフピーク料金では、まずリクエスト時刻ごとにバケット分けし、各バケットに個別の価格を適用したうえで、ツール呼び出し料金を加算する必要があります。全日平均単価で見積もると、ピーク時間帯の比率による誤差が隠れてしまいます。特にトラフィックが日中に集中する業務では注意が必要です。
Q3: リクエストがピークとオフピークの時間帯にまたがる場合、どの時刻で課金されますか？
公式の課金ルールによります。一般的にはリクエスト開始時刻で計算されることが多いですが、決めつけは禁物です。試算モデルでは「課金基準時刻」を設定可能なパラメータにしておき、公式のルールを確認してから値を入れることをおすすめします。長時間のストリーミングリクエストは別途フラグを立て、サンプリングして突き合わせ確認するとよいでしょう。
Q4: ツール課金によってコストがなぜ「倍増」するのですか？
ツール呼び出しでは通常、2つの費用が発生するためです。1つはツール自体の呼び出し料金、もう1つはツールの結果をコンテキストに戻した際に、入力トークンとして再び課金される分です。複数ラウンドのツール呼び出しではコンテキストがどんどん長くなり、後のラウンドでは前の結果分も支払うことになります。そのため、呼び出し回数と戻す内容の長さを同時に制御する必要があります。
Q5: API 経由で DeepSeek をすばやく呼び出し、コストを照合するにはどうすればよいですか？
次の手順で操作できます。
1. APIYI apiyi.com にアクセスしてアカウントを登録し、APIキーを取得します
2. ドキュメントセンター docs.apiyi.com で接続先を確認し、OpenAI または Anthropic 互換形式を選択します
3. 料金ページ docs.apiyi.com/models で DeepSeek 関連モデルの入力・出力・キャッシュ単価を確認します
4. 少量のトラフィックで本記事の5ステップ試算を実行し、管理用の請求明細と照合してキャリブレーションします
APIYI は本記事で扱う DeepSeek モデルの呼び出しを提供しており、インターフェース形式は主要な SDK と互換性があるため、既存プロジェクトで直接差し替えて検証できます。
Q6: サードパーティプラットフォーム経由で呼び出す場合、ピーク・オフピークとツール課金の算定基準は同じですか？
プラットフォームによっては、時間帯を区別するかどうか、ツール料金をどのように換算するかなど、課金ルールが公式と異なる場合があります。APIYI 経由で呼び出す場合は、APIYI の料金ページ docs.apiyi.com/models に記載された実際のデータを基準にしてください。公式の価格表をそのまま適用せず、試算前にこの点を確認すれば、照合時の誤差の大半を防げます。
Q7: DeepSeek API のコスト試算にはどのような既知の限界がありますか？
主に3つあります。1つ目は、価格が改定されるため、モデルがパラメータ更新に対応している必要があることです。2つ目は、推論モデルの思考トークン長は変動が大きく、平均値での見積もりは誤差が大きくなりやすいため、分位点を使うことをおすすめします。3つ目は、ツール呼び出し回数はモデルが自律的に決めるため、同じプロンプトでも入力によって差が大きく出ることです。一度きりの試算ではなく、継続的なモニタリングが必要です。
DeepSeek API のピーク・オフピーク料金におけるコスト試算の主要ポイント Key Takeaways
- コストは多次元化する：時間帯、キャッシュ、出力、ツールの4項目の組み合わせで請求額が決まる
- 単価は必ずパラメータ化する：価格は APIYI 価格ページのリアルタイムデータを基準にし、ハードコードしない
- タイムゾーンを先に揃える：ログはすべて北京時間に変換してからピーク/オフピークに振り分ける。そうしないとバッチ全体が誤分類される
- ツールは二重に課金される：呼び出し料金に加えて Token の埋め戻しがあり、両方を集計する必要がある
- オフラインタスクはオフピークへ移す：タスクキューでピークを削るのが最も直接的で効果的な最適化
- リアルタイムタスクはキャッシュ活用：固定プレフィックスを変えずに保ち、キャッシュヒット率を高める
- 試算はすぐに検証できる：APIYI の互換インターフェースで少量のトラフィックを試し、請求書と照合してモデルを調整する
まとめ
DeepSeek API がピーク・オフピーク料金とツール課金を導入したことで、コスト試算における核心的な変化は次の3点に集約できます。
- 総量からバケットへ：リクエストを時間帯で分割し、ピークとオフピークを別々に計算してこそ、真のコスト構造が見えてくる
- Token から Token＋ツールへ：ツール料金は独立したコスト項であり、さらに入力 Token も連動して押し上げる
- 静的見積もりから継続モニタリングへ：価格も使用量も変わるため、試算モデルはパラメータ化して定期的にキャリブレーションする必要がある
まずは本記事の5ステップの流れで直近1週間のログを一通り処理し、ピーク時間帯の割合、ツール呼び出し頻度、キャッシュヒット率という3つの主要指標を見つけてから、的を絞った最適化を行ってください。統一インターフェースで DeepSeek やその他のモデルをテストしたい場合は、APIYI apiyi.com から接続できます。接続方法はドキュメントセンター docs.apiyi.com を参照してください。単価はすべて価格ページ docs.apiyi.com/models の実際のデータを基準にしてください。
📚 参考資料
- 36氪の報道：「梁文锋、山を下りる——DeepSeekは何を探しているのか？」
- リンク：
36kr.com/p/4055279154779015 -
説明：DeepSeekの最近の商用化動向に関する業界報道で、価格調整の背景を理解するための参考になります。
-
APIYI 価格ページ：DeepSeekなどのモデルの入力・出力・キャッシュ単価
- リンク：
docs.apiyi.com/models -
説明：本文の価格関連パラメータはすべてここから取得しています。試算前に確認することをおすすめします。
-
APIYI ドキュメントセンター：接続方法とインターフェース形式の説明
- リンク：
docs.apiyi.com -
説明：OpenAIおよびAnthropic互換形式での接続方法を掲載しています。
-
DeepSeek 公式 API ドキュメント：課金ルールと usage フィールドの説明
- リンク：
api-docs.deepseek.com - 説明：ピーク・オフピーク時間帯の境界、キャッシュの仕組み、ツール課金の基準は公式説明に準じます。
作者：APIYI 技術チーム
技術交流：コスト試算や接続の過程で問題が発生した場合は、APIYI 公式サイト apiyi.com からお気軽にお問い合わせください。接続に関する資料は docs.apiyi.com のドキュメントセンターもご覧いただけます。
