SECTION 01症状 → 最短の対処
DeepSeek APIの公式仕様では、レスポンスのusageに入力Token、出力Token、キャッシュヒットToken、キャッシュミスTokenが示されます。公式のToken使用量ドキュメントでこの内訳を確認し、キャッシュヒット率が高くても入力履歴の総量が増えているなら、Compaction、ツール結果の整理、会話分割の順に原因を切り分けてください。
症状：長い会話ほどToken消費が増え、応答も遅くなる。
最短の対処：まず履歴・ツール結果・出力を分離して記録し、同じ目的を続ける場合だけCompactionを実行します。目的や作業範囲が変わった場合は、新しい会話へ分けてください。
この記事は、長い会話でToken消費が増え続ける個人開発者、継続Agentの費用と応答時間を管理するエンジニアリングチーム、モデル料金と実行環境の総コストを評価する技術責任者向けです。単発の質問が中心なら、Compactionより固定指示や入力テンプレートの整理を先に行う方が適しています。
最終更新：2026年8月18日。DeepSeek Harnessの現行リポジトリ、Compaction関連の実装説明、DeepSeek APIのusage・キャッシュ・料金資料を確認しています。開発者プレビューのため、具体的な発火条件、イベント名、既定の組み合わせは更新される可能性があります。
SECTION 02まずTokenの増分を分解する
長いセッションの1回のリクエストは、少なくとも次の要素に分けて記録します。
- 今回追加したユーザー入力
- それまでの会話履歴
- システム指示とAgent用の固定コンテキスト
- ツール呼び出しとツールの返却結果
- モデル出力、再試行、エラー処理に伴う追加入力
会話が進むと、過去の履歴が次のリクエストにも含まれます。今回の指示が短くても、累積履歴、ツール結果、再掲されたエラーログが増えれば、入力側のToken消費は上昇します。
DeepSeekの公式資料では、Tokenはモデルの処理単位であり、実際の処理量はモデルが返すusageで確認するよう説明されています。文字数からTokenを推定する方法はモデルや言語によって差が出るため、請求管理では推定値ではなくAPIレスポンスを原記録にしてください。公式のToken計算資料には、オフラインで確認するためのTokenizerに関する案内もあります。
次のようなログを、リクエスト単位で保存すると原因を追いやすくなります。
request_id
prompt_tokens
completion_tokens
prompt_cache_hit_tokens
prompt_cache_miss_tokens
response_time
tool_result_bytes
compaction_event
ここで重要なのは、単一リクエストの料金ではなく、タスク完了までの累積値です。会話が長くなるほど、短い追加入力の背後で古い履歴が何度も送られている可能性があります。
SECTION 03ツール結果の膨張を止める
ログ、検索結果、ビルド出力、大きなファイルの読み込みは、会話を急激に膨らませる代表的な要因です。特に失敗したコマンドの全文を何度も貼り直す運用では、実際に必要な数行よりも、重複した周辺情報の方が大きくなります。
会話へ残す情報は、次の3層に分けてください。
- 即時判断情報：Agentが次の操作を決めるために必要な結論、失敗箇所、終了状態です。
- 検証情報：テスト名、該当行、スタックトレース、変更差分、再現コマンドです。
- 完全記録：全文ログ、検索結果の全件、大きなファイル、CI成果物です。
即時判断情報は短くまとめ、検証情報には保存先や識別子を添えます。完全記録は会話へ毎回再投入せず、ファイルや成果物として別に保存します。後で再取得できない証拠だけは、要約だけに置き換えないでください。
DeepSeek Harnessの現行開発者向け実装では、Compaction関連のサービス、基本的な要約バックエンド、ツール結果の裁剪機能、手動圧縮コマンドが確認されています。ただし、どのサイズや条件で自動処理されるか、既定設定がどう組み合わされるかは、バージョンによって変わる可能性があります。DeepSeek Harnessの公式リポジトリを使って、導入中のバージョンとREADMEの記述を照合してください。
削ってよい結果は、重複した成功ログ、同じ警告の繰り返し、未使用の検索候補、対象外の行です。残すべき結果は、終了コード、失敗したテスト名、再現条件、変更ファイル、失敗の前後にある重要なスタックトレースです。
SECTION 04キャッシュヒット率だけでコストを判断できない理由
DeepSeek APIのキャッシュは、入力履歴全体を消す機能ではありません。公式のキャッシュ説明では、以前の入力と重なるプレフィックスが再利用され、入力のうち一致した部分と一致しなかった部分が別々に扱われます。公式のコンテキストキャッシュ説明を確認すると、固定されたシステム指示や古い履歴がヒット側に入りやすい一方、新しく追加されたツール結果やユーザー入力はミス側に残り得ることが分かります。
したがって、次の状態は同時に成立します。
- キャッシュヒット率は高い
- 毎回送信する入力履歴は増えている
- 新しいログや指示はキャッシュミスになっている
- 出力Tokenと再試行回数も増えている
- セッション全体の費用は下がらない
キャッシュは入力の再利用による料金・処理効率の改善に役立ちますが、会話の設計を置き換えるものではありません。公式のキャッシュ導入説明でも、prompt_cache_hit_tokensとprompt_cache_miss_tokensを使ってキャッシュ性能を確認する仕組みが示されています。キャッシュ機能の公式発表を参照し、画面上の比率だけでなくAPIレスポンスの実数を保存してください。
料金計算は、次の変数式にしておくと価格改定へ対応しやすくなります。
入力ミスToken × ミス単価
+ 入力ヒットToken × ヒット単価
+ 出力Token × 出力単価
+ 再試行・Compaction・ツール実行の追加分
現行単価は固定値として記事やスクリプトへ埋め込まず、作業開始時にDeepSeek API公式の料金ページを確認してください。米ドル表示が必要な環境では、公式の米ドル料金資料を使います。公式ページには入力キャッシュヒット、入力キャッシュミス、出力を分けた料金が掲載されていますが、料金は変更される可能性があります。
SECTION 05Compaction前後で状態を検証する
Compactionは、長くなった会話を短い状態へまとめるための手段です。タスク管理システムや完全な監査ログではないため、圧縮前に重要な状態を外部へ保存しておく必要があります。
最低限、次の情報を引き継ぎ文書や作業ファイルへ記録してください。
- 最終目的と、変更してはいけないユーザー制約
- 変更済みファイルと未変更ファイル
- 完了済み、未完了、次に実行する操作
- テストの成功・失敗、失敗したコマンド、未解決の原因
- ブランチ、コミット、成果物の保存先
- 使用した権限、作業ディレクトリ、外部サービスの境界
圧縮後は、圧縮前と同じ確認指示を使います。例えば、現在の目的、変更済みファイル、最後に失敗したテスト、次の操作を列挙させ、元の記録と照合します。その後、差分確認や読み取り専用のテストを実行し、Agentが状態を正しく復元できるか確認してください。
Compaction後に未完了の作業や失敗テストが消えている場合は、会話をそのまま継続しないでください。元のセッションへ戻るか、外部保存した引き継ぎ情報から新しい制御済みセッションを作成します。重要なコード作業では、請求額の低下より状態復元の正確さを優先します。
SECTION 06圧縮・会話分割・停止の判断基準
Compactionを選ぶ条件
- 同じ成果物、同じ作業ディレクトリ、同じ目標を継続している
- 変更ファイル、テスト状態、次の作業を外部にも保存できる
- 圧縮前後の確認手順を実行できる
- Token増加の主因が履歴の重複である
新しい会話を選ぶ条件
- 要求が別機能や別案件へ移った
- 作業ディレクトリ、リポジトリ、権限境界が変わった
- 誤った仮説や無関係なツール結果が大量に蓄積した
- 監査対象として旧会話を完全保存したい
- 圧縮後の確認で重要な制約やテスト状態を復元できなかった
いったん停止する条件
- 入力Tokenは下がったが、再試行や手作業の復旧時間が増えた
- 応答時間、プロセスメモリ、ログ保存量が上昇している
- 同じ失敗を繰り返し、会話を続けるほど証拠が埋もれている
- モデル料金より、占有中の実行環境や担当者の待ち時間が大きい
SECTION 07実行前に確認するチェックリスト
- [ ] 各リクエストの
prompt_tokensとcompletion_tokensを保存する - [ ]
prompt_cache_hit_tokensとprompt_cache_miss_tokensを分けて保存する - [ ] ツール結果を即時判断、検証情報、完全記録に分類する
- [ ] 圧縮前に目的、制約、変更ファイル、テスト状態を外部保存する
- [ ] 圧縮後に同じ確認指示と差分確認を実行する
- [ ] 復元できない状態があれば、元の会話へ戻すか新しい会話を作る
- [ ] 同じ基準タスクでToken、応答時間、メモリ、ログ容量を比較する
- [ ] DeepSeek APIの料金とusageフィールドを作業開始前に再確認する
SECTION 08FAQ：長い会話で迷いやすい判断
キャッシュヒット率が高いのにToken消費が減らないのはなぜですか？
キャッシュは入力の再計算や一部の入力料金を軽くする仕組みであり、リクエストに含める履歴そのものを消す機能ではありません。固定された履歴がヒットしていても、新しいツール結果や追加指示は増え続けます。prompt_tokens、キャッシュヒット、キャッシュミス、出力Tokenを分離して確認してください。
Compactionでコード作業に必要な状態が失われることはありますか？
失われる可能性があります。未完了の修正、テストの失敗内容、ユーザー固有の制約、変更済みファイルの一覧が要約から抜けると、Agentが同じ調査を繰り返したり、既存の修正を上書きしたりします。圧縮前後で同じ確認指示を実行し、復元できなければ元の会話へ戻してください。
どの時点で会話を圧縮せず、新しいセッションへ移すべきですか？
目的、作業ディレクトリ、対象リポジトリ、成果物の境界が変わったときは、新しいセッションを優先します。同じ機能の実装を続け、必要な状態を外部保存できる場合だけCompactionを使います。誤った仮説が大量に混ざった会話も、圧縮より分割の方が復旧しやすくなります。
長いツール結果をどのように整理すればよいですか？
会話には失敗箇所、終了状態、該当行、再現コマンドだけを残し、全文ログは外部成果物として保存します。後で再取得できない証拠は削除せず、保存先と識別子を要約へ含めます。大きなファイルも全量を渡さず、対象の関数、行範囲、依存関係を限定して読み込ませてください。
長い会話の費用は何を基準に見積もるべきですか？
各リクエストの入力・出力Token、キャッシュヒット・ミスToken、再試行回数を使ってモデル費用を見積もります。そこへCompactionの追加呼び出し、ツール実行、応答待ち時間、プロセスメモリ、ログ保存量、状態復旧に要する人手を加えてください。単発の低料金ではなく、同一基準タスクの累積値で判断します。
SECTION 09環境コストまで含めた最終判断
Compactionで入力Tokenを削減できても、ローカル環境を長時間占有し続ければ、別の開発作業との競合、ログやワークスペースの混在、再起動時の復旧、メモリ不足による待ち時間が残ります。複数のAgentを同時に動かす場合は、会話を分割しても同じ実行環境内でプロセスやストレージが競合することがあります。
物理デバイスやローカル専用データが必要な長期処理なら、自前のMacを固定運用する方が適しています。一方、期間限定の検証、構成比較、長時間Agentの隔離実行では、日本向けMacレンタルの選択肢を確認し、必要な占有期間だけ環境を分ける方法が現実的です。
現在の環境でTokenだけを下げようとすると、会話の再利用効率は上がっても、タスク間の干渉、ログ管理、復旧作業、ローカル資源の占有が残る場合があります。MACNOXの料金情報を参照し、DeepSeek APIの料金と実行環境の費用を同じ基準タスクで比較してください。必要な期間だけMac環境をレンタルすれば、Compactionの効果を検証しながら、長時間Agentを他の作業から切り離して運用できます。
SECTION 10よくある質問 FAQ
キャッシュヒット率が高いのにDeepSeek HarnessのToken消費が減らないのはなぜですか？
キャッシュは入力の再計算や一部の入力料金を軽くする仕組みであり、リクエストに含める履歴そのものを消す機能ではありません。各リクエストのprompt_tokens、prompt_cache_hit_tokens、prompt_cache_miss_tokensを分けて記録し、累積入力Tokenと出力Tokenを別々に確認してください。
Compactionでコード作業に必要なコンテキストが失われることはありますか？
失われる可能性はあります。特に未完了の修正、テストの失敗内容、ユーザー固有の制約、変更済みファイルの一覧が要約から抜けると、Agentは同じ調査を繰り返したり、既存の修正を上書きしたりします。圧縮前後で同じ確認指示を実行し、復元できない場合は元の会話へ戻してください。
会話を圧縮するより新しいセッションを作るべきタイミングはいつですか？
目的、作業ディレクトリ、成果物の境界が変わったときは新しいセッションを優先します。同じ機能の実装を続けており、目標と作業場所が変わらない場合だけ、必要な状態を保存したうえでCompactionを使うのが安全です。監査が必要な案件では、完全ログを別保存してから分割してください。
ツールの返却結果が長すぎる場合、コンテキスト占有量をどう減らせますか？
ログや検索結果は、失敗箇所、該当行、終了コード、再現条件だけを会話へ残し、完全な出力はファイルやアーティファクトとして保存します。ソースコードの全量読み込みも避け、対象ファイル、関数、行範囲を限定してください。証拠を後から再取得できない場合は、要約だけでなく保存先と識別子も残します。
長い会話のコストはどのデータで見積もればよいですか？
最低限、各リクエストのprompt_tokens、completion_tokens、prompt_cache_hit_tokens、prompt_cache_miss_tokens、応答時間を保存します。見積もりは入力Tokenをキャッシュヒットとミスに分け、それぞれの単価を掛け、出力Tokenの料金を加える式で作ります。さらにCompaction待ち時間、メモリ使用量、復旧作業時間も別のコストとして記録してください。