01

2026年8月18日時点の結論

DeepSeekの公式料金表では、入力・出力・キャッシュヒットを別々に課金します。たとえば、DeepSeek V4 Flashは入力キャッシュヒット、入力キャッシュミス、出力で単価が異なり、DeepSeek V4 Proも同じ構造です。公式料金表で確認できるため、「1日=24時間」の単純計算は避けるべきです。

今週の推奨アクションは、まず1回の実タスクを完了条件と中止条件つきで記録し、その後に1日単位へ拡張することです。 短期検証はタスク単位、定型バッチは日次、継続Agentは予算上限と自動停止条件を設定します。

この内容は、長いコーディング作業の消費量を知りたい個人開発者、チーム導入の予算を申請するAI Agent担当者、短期レンタル・長期保有・手元のMacを比較する技術管理者向けです。

最終的な金額は、次の式で管理します。

1日の総費用 = API費用 + Mac環境費用 + ストレージ・バックアップ費用 + 人工保守費用

02

料金を測る単位

「DeepSeek Harnessは1日でどれくらい使うのか」を調べる前に、タスクの終点を固定します。開始時刻だけを記録すると、途中で待機していた時間、失敗して再実行した時間、手動確認の時間が混ざります。

運用形態 先に決める条件 適した測定単位
単発タスク 成功条件と中止条件 1タスク
固定バッチ 1日の処理件数 1日
対話型開発 コミット、テスト、レビューの完了 1セッション
継続Agent 停止条件、最大反復回数、予算上限 1時間・1日

完了条件は「コードを生成する」では不十分です。「テストが通る」「差分を保存する」「人間の承認待ちに入る」など、成果物で定義します。中止条件には、同じエラーの反復、API残高の下限、一定時間の無進展を含めます。

DeepSeek Harnessは1日で何トークン使うのか。 固定値はありません。入力トークン、出力トークン、推論トークン、ツール呼び出しの回数を、APIレスポンスのusageから取得します。公式仕様では、入力トークンはキャッシュヒットとミスに分けて返されます。トークン使用量の説明も参照し、推測ではなく実ログで集計します。

03

API費用の分解

公式料金表にある単価を、次のように変数へ置き換えます。ここでは将来の価格変更に備え、記事内で固定の総額を約束しません。

費用項目 記録する値 計算方法
入力・キャッシュヒット Hトークン H ÷ 1,000,000 × ヒット単価
入力・キャッシュミス Mトークン M ÷ 1,000,000 × ミス単価
出力 Oトークン O ÷ 1,000,000 × 出力単価
再試行 再実行分のH・M・O 成功分と分けて加算
1タスク費用 上記の合計 API請求額として保存

2026年8月18日に確認した公式表では、DeepSeek V4 Flashは入力キャッシュヒットが100万トークンあたり$0.0028、キャッシュミスが$0.14、出力が$0.28です。V4 Proはそれぞれ$0.003625、$0.435、$0.87です。最新の公式料金では単価変更の可能性も明記されているため、見積もり表には確認日を残します。

V4 ProとV4 Flashのどちらが安いのか。 単価だけならV4 Flashが有利です。ただし、難しい修正で失敗が増えたり、出力が長くなったりすると、1回の単価差より再試行分が大きくなる場合があります。単純な整形、定型テスト、短い分類はV4 Flashから始め、設計判断や複雑なデバッグはV4 Proを候補にします。

思考モードでは、ツール呼び出しを含む複数ターンが発生します。公式ドキュメントでも、ツールを使ったターンでは推論内容を後続リクエストへ正しく渡す必要があると説明されています。思考モードの仕様を確認し、1回のユーザー入力だけで費用を見積もらないことが重要です。

04

キャッシュと並列実行

キャッシュは常に100%ヒットする仕組みではありません。共通のシステム指示やリポジトリ概要を毎回同じ接頭辞で送れば再利用の可能性は上がりますが、プロンプトの先頭が変わる、履歴を途中で差し替える、ユーザー識別子を分けると、期待したヒット率にならないことがあります。コンテキストキャッシュの仕様では、キャッシュはベストエフォートであるとされています。

変動要因 請求量への影響 記録する指標
共通接頭辞が長い キャッシュヒットが増える可能性 ヒット率
毎回異なる履歴 キャッシュミスが増える可能性 ミス率
子タスクの分割 リクエスト数が増える 子タスク数
ツール失敗 再推論が発生 失敗回数
手動再発行 同じ入力を再請求 人工再実行数

同一アカウントの同時接続上限は、公式のレート制限ページでV4 Proが500、V4 Flashが2500と案内されています。上限を超えるとHTTP 429が返り、1接続は送信から応答完了まで数えられます。同時実行数と分離を基準に、並列数を設定します。

高並列にすれば、同じ時間内に有効な成果物が増えるとは限りません。429、ツールの競合、同じファイルへの同時書き込み、テスト環境のロックが増えると、再試行と人間の確認が増えるためです。

05

Mac環境の占用方法

Macの計算資源を費用へ入れるときは、所有形態ではなく占用時間で比べます。すでに保有しているMacでも、別の開発作業に使えない時間には機会費用があります。一方、短期レンタルは初期セットアップの手間を抑えやすい反面、利用しない時間まで確保すると効率が下がります。

環境 費用として計上するもの 向いている運用
手元のMac 占用時間、電力、保守、他作業の機会費用 小規模な検証
短期のリモートMac 利用時間、起動、転送、保存 期間限定の試用
長期保留ノード 保持期間、監視、バックアップ 毎日動く定型処理
共有環境 利用時間、待ち時間、権限調整 複数人の断続利用

MESHLAUNCHのMac環境の利用候補を比較するときも、掲載価格だけでなく、実際の稼働時間、停止時間、データ転送、ログ保管を同じ表に入れます。地域別に検討する場合は、米国東部向けMac環境のように、利用場所と作業時間帯も記録対象にします。

環境費用は、次の空欄テンプレートで始めます。

項目 試用 1日バッチ 継続Agent
Mac占用時間 ___時間 ___時間 ___時間
起動・停止作業 ___分 ___分 ___分
ログ保存 ___ ___ ___
バックアップ ___ ___ ___
無人復旧 ___回 ___回 ___回
環境費用合計 ___ ___ ___

DeepSeek Harness自体のMac上のCPU、メモリ、ストレージ使用量には、統一された公式数値がありません。導入先の実装、リポジトリの規模、ログ量、ツール構成で変わるため、30分の試行だけで長時間運用を断定しないでください。

06

人工保守の計上

開発者プレビューや更新頻度の高い構成では、ソフトウェアが無償でも保守費用は発生します。インストール、アップグレード、権限承認、APIキーの更新、互換性修正、異常終了後の再開、成果物のレビューを別項目にします。

継続稼働のAI Agentには何の費用を入れるべきか。 API料金だけでは足りません。少なくとも、次の5項目を日次で記録します。

  • APIの入力、出力、キャッシュヒット、キャッシュミス
  • 子タスク数、並列数、429や500などのエラー数
  • Macの占用時間、ログ容量、バックアップ容量
  • 人間が接管した回数と、1回あたりの対応時間
  • 完了したタスク数と、やり直しになったタスク数

APIエラーの扱いも費用に直結します。HTTP 429は送信速度が速すぎる場合、500や503はサーバー側の問題として説明されています。公式エラーコード一覧に従って、無制限の即時再試行は避けます。指数バックオフ、最大試行回数、手動確認への切り替えを実装します。

07

条件分岐による予算判断

次の条件で、試用継続、モデル変更、環境変更、停止を決めます。

  • 1タスクのAPI費用と再実行回数を取得できない場合は、日次運用へ進まず、ログ収集を先に直します。
  • V4 Proで成果物の品質が必要だが、定型処理の割合が高い場合は、定型部分だけV4 Flashへ分離します。
  • キャッシュヒットが低く、同じ長い指示を毎回送っている場合は、接頭辞と履歴の構造を見直します。
  • 429が発生する場合は、並列数を下げ、キュー方式へ戻します。上限申請だけで解決すると判断しません。
  • Macの占用率が低い場合は、短期環境へ切り替えます。毎日同じ時間に使う場合だけ長期保留を比較します。
  • 人工接管が増え、完了タスクあたりの対応時間が伸びる場合は、予算を増やす前に停止条件とツール権限を見直します。
  • 1日の予算上限に近づいた場合は、新規タスクを止め、保存済み成果物の確認だけを許可します。

判断指標は「1日いくら」だけにしません。1タスク費用、成功タスク費用、日次消費額、再試行率、人工接管率、完了率を並べます。時間単価の低いモデルでも、失敗が多ければ有効完了費用は上がります。

08

実行前チェックリスト

  • [ ] 完了条件を成果物で定義した
  • [ ] 中止条件と1日の予算上限を設定した
  • [ ] V4 ProとV4 Flashの選択理由をタスク別に記録した
  • [ ] 入力、出力、キャッシュヒット、キャッシュミスを保存する
  • [ ] 子タスク数と最大並列数を決めた
  • [ ] 429、500、503の再試行回数を制限した
  • [ ] Macの起動、停止、ログ、バックアップを費用化した
  • [ ] APIキーとツール権限の管理担当を決めた
  • [ ] 異常終了後の再開手順を確認した
  • [ ] 1回の実タスクで見積もり式を校正した

手元のMacだけで続ける場合、別作業との競合、電源断、OS更新、ログ容量不足が弱点になります。反対に、短期のクラウドMacやリモートMacは、利用しない時間の確保費用、転送待ち、権限設定、接続障害を見落としやすい構成です。

まず小規模な実タスクで式を校正し、利用時間が短く不定期ならMESHLAUNCHのMac利用方法を短期環境として比較します。毎日長時間の重い処理を固定して回し、物理インターフェースや専用周辺機器が必要なら、自有設備のほうが合う場合もあります。レンタルは、試用、チームの一時的な検証、利用時間が読めるAgent運用で特に比較しやすい選択肢です。