DeepSeek Harness のコンテキスト圧縮を13フレームで分解
ソース解説動画をコマごとに追い、dsh の圧縮がいつ発火し、何を切り詰め、何を要約し、追記専用ログがどうセッションを再構築するかを整理します。
最終更新: 2026-09-23
本ページは、ソースコードレベルで DeepSeek Harness のコンテキスト圧縮を解説する動画を、コマごとに読み解くものです。最初に、動画の性質を確認しておきます：原動画はナレーション付きの仕組み解説アニメーションで、スライドに圧縮パイプラインを一枚ずつ描くスタイルであり、製品 UI の実機録画ではありません。だからこそ各機構が1枚にきれいに分離されており、アーキテクチャの教科書として読めます。
文中の数値——デフォルト発火しきい値 80%、8192 コードポイントのトリム（先頭 4096 + 末尾 1024 を保持）、直近 16% の原文保持——は 2026-09-23 時点で deepseek-harness 公式リポジトリのドキュメントと突き合わせ、一致を確認しています（thresholdRatio 0.8、thresholdChars 8192、retainRatio 0.16）。公式ドキュが詳細を定義しない部分（チェックポイントの8分類など）は、動画作者・小木頭によるソース読解の図示であり、本文中でその旨を明示しています。
まずは要約から
- ▸圧縮は dsh に組み込みではなくプラグイン能力：ctx.compaction が能力インターフェース、compaction-basic がデフォルト実装。コンテキストがウィンドウの約 80% に達するか、サーバー側の超過報告、あるいはアイドル時の /compact 入力で発火します。
- ▸要約の前にトリム：8192 コードポイントを超えるツール結果は先頭 4096 と末尾 1024 だけを残し、トリム後に収まれば要約のモデル呼び出し自体を省略します。
- ▸圧縮された履歴は構造化チェックポイントに変わり、直近約 16% は原文のまま保持。永続ログが全イベントを残すため、モデルのビューはいつでもリプレイで再構築できます。
圧縮パイプライン、12ステップ
アーキテクチャの中の圧縮
- 1
まず位置：DeepSeek のリクエストには圧縮ステージがある
動画はリクエスト構造の比較から始まります。Codex 方式のリクエストは入力 + コンテキスト + モデル呼び出し。DeepSeek Harness はこの間に専用の圧縮ステージを挿入します。この1枚が動画全体の地図——圧縮は事後対処ではなく、リクエストパイプラインの正規の一段だという話です。
パイプラインのコンテキストとモデル呼び出しの間に、圧縮の一段が増える。0:32 の場面を見る - 2
登場人物：1つの能力を複数プラグインで分担
圧縮はケイパビリティシームとして分割されています。/compact コマンドが手動入口、ctx.compaction が能力インターフェース、その背後のデフォルト実装が compaction-basic。周囲に任意の相棒が2つ——圧力を測る token meter と、ツール結果を切り詰める tool result pruner です。compaction-basic を差し替えても他はそのまま動きます。
$ctx.compaction$dsh-compaction$compaction-basic$command-compact
能力の継ぎ目1本に、5つの役割：コマンド、インターフェース、デフォルト実装、そして2つの任意パートナー。2:18 の場面を見る - 3
3つのトリガーを覚える
圧縮の起点は3つ。毎リクエスト前の pre-step チェックは推定圧力をデフォルト 80% のしきい値（モデル別に設定可）と比較。サーバーがすでにコンテキスト超過を報告している場合は回復フローに入り、通常しきい値をスキップして先に現場を修復。エージェントのアイドル中に /compact を打てば、80% を待たずに随時整理します。
$agent/pre-step$context-overflow$/compact · agent idle
発火の道は3本。80% を本当に待つのは1本だけ。3:50 の場面を見る - 4
メーターの読み方：プロバイダー値 + 変化の推定
token meter は推定であることを隠しません。直近の成功呼び出しでプロバイダーが報告した使用量をアンカーにし、以降の可視コンテンツの変化を積算します——新規メッセージは増加、置換は減少にもなり得る。スライドのバーは定性イメージで、実測比率ではありません。
メーターは推定：最後の公式読み取りに、その後のドリフトを足したもの。4:20 の場面を見る
トリム・選択・要約
- 5
測る前に、まずログを切る
最初のレバーは要約ではなく削除。巨大なツール結果1本でコンテキストの半分以上を占めることは珍しくなく、中間部分を切り落とすだけで圧力がしきい値を下回ることがあります。以降の章の機構はすべて、この最も安い工程が済んだ前提で動きます。
まず切る。巨大なツール結果1本が問題の全部かもしれない。1:15 の場面を見る - 6
プリナー分解：8192 コードポイント、4096 + 1024 を保持
テキストが 8192 Unicode コードポイントを超えたツール結果（3つの Web プリセットの現在設定）は書き換えられます：先頭 4096 コードポイント、トリムマーカー、末尾 1024。単位はトークンではなくコードポイントで、この工程はモデルを一切呼びません。数値は公式 compaction-tool-result-pruner のデフォルト（thresholdChars 8192、headChars 4096、tailChars 1024）と一致しています。
$threshold: 8192 code points$keep head 4096 + tail 1024
しきい値は 8192 コードポイント。先頭 4096、マーカー、末尾 1024。5:40 の場面を見る - 7
レンジ選択：直近 16% を原文保持、切断線はペアを避ける
トリム後も圧力が超過なら compaction-basic がレンジを選びます。最新メッセージから遡り、ウィンドウ予算の約 16%（公式 retainRatio のデフォルト）に達するまで原文を保持。切断線は必ずツール呼び出しとその結果の外側に引かれ、ペアが分断されません。メッセージノード単位の累計なので実際の保持量は 16% を少し超え得ます。この時点では範囲が選ばれただけで、要約はまだ生成されていません。
最新から遡る。切断線が呼び出しと結果の間を通ることはない。6:00 の場面を見る - 8
チェックポイント生成：compaction/start と8分類
要約は追記指示として実行されます。リクエストは元の system・tools・選ばれた旧メッセージを保持したまま、末尾に user メッセージを追加し、会話を構造化チェックポイントへ整理するよう指示。動画はこれを8分類で図示します——ユーザーの目標と意図、重要な技術概念、ファイルとコード、エラーと修正、未完了タスク、現在の作業、次のアクション、重要な背景と制約。公式ドキュもチェックポイント前文の存在を確認できますが、8分類の内訳は作者の模式的読解です。
$compaction/start
要約指示は構造化チェックポイントを求める——8分類は作者による模式図。7:05 の場面を見る - 9
合格した要約だけが置換を許される
要約が履歴を置き換えるには3つの関門があります。モデルが最後まで完了し空でないテキストを返したこと（エラー・中断・出力上限での打ち切りは失敗）。text コンテンツのみを保持すること——reasoning と tool calls はチェックポイントに入らず、画像出力は即拒否。ラッパー込みの要約推定量が置換対象区間より小さいこと。
どれか1つでも落ちれば、要約はモデルの前に出られない。7:56 の場面を見る
置換・リプレイと限界
- 10
ログは追記、モデルのビューが置き換わる
成功すると、永続ログに start・summary・checkpoint・end の一連のイベントが追記され、モデルの可視履歴はサーフェス置換で一新されます。スライドでは surfaceOp: undefined。チェックポイントが先、保持された直近原文が後。上流では何も削除されず、ログが完全な記録であり続けます。
$surfaceOp: { op: 'replace' }$compaction/start · summary · end
ログは増える一方。差し替えられるのはモデルのビューの側。8:48 の場面を見る - 11
回復はログのリプレイで
ログが追記専用かつ完全である限り、回復に元のコンテキストは不要です。イベントを順に読み返し、surfaceOp の append / replace を1件ずつ適用すれば、旧コンテンツ→チェックポイント→直近原文の順でモデルビューが再構築されます。圧縮済みセッションが再起動に耐えるのはこの仕組みのおかげです。
$surfaceOp: append / replace
回復は追記専用ログの決定論的リプレイ。9:05 の場面を見る - 12
まとめ：安定したインターフェース、交換可能な実装
最終スライドはパイプラインを4つの動詞に圧縮します——圧力を測る、ツール結果をトリムする、必要なら要約する、モデルビューを置き換える。そして役割分担：ctx.compaction が安定したインターフェース、compaction-basic が現行のデフォルト実装、agent loop・token meter・/compact 入口がその周囲。どの部品も他を壊さずに進化できます。
動詞4つ、安定したインターフェース1本、交換可能な実装1つ。10:00 の場面を見る
公式 0.1.7 との接点
このページが分解するのはプラグインパイプラインですが、公式 0.1.7 系は同じ継ぎ目を製品側から磨いています——アルファのリリースノートは、プロアクティブ圧縮のための出力容量とコンテキストヘッドルームの確保、待機タイムアウト後の長時間コマンドのバックグラウンド継続を明記。長時間タスクの実際のコストを知るには、 トークン使用量とコスト追跡ガイドを読む.
よくある質問
コスト、消失の範囲、限界——フレームだけでは分からない部分。
圧縮でトークンは余計に消えますか？
はい、要約1回につきモデル呼び出し1回分です。チェックポイント指示がモデルへ送られ、テキストの回答だけが保持されます。対照的に、巨大ツール結果のトリムはノーコスト——プリナーはモデルを呼ばず、トリムだけで圧力がしきい値以下に収まれば要約呼び出し自体がスキップされます。
手動の /compact と何が違いますか？
パイプラインは同じ、トリガーが違うだけです。自動圧縮は約 80% の圧力しきい値（またはサーバー超過）を待ち、/compact はアイドル中にしきい値に関係なく即実行。コマンドは圧縮した項目数と推定トークン削減を報告し、実行中に送ったメッセージは完了後に処理されます。
圧縮後、コンテキストは失われますか？
古いターンの原文はモデルの視界から外れますが、無にはなりません。目標・ファイル・エラー・未完了タスクをカバーする構造化チェックポイントに整理され、直近のスライス（デフォルトでウィンドウの 16%）は原文のまま、永続ログも全イベントを保持します。失われるのはモデルによる旧原文の直接参照であって、記録自体ではありません。
これらの数値は固定ですか？
いいえ。80% は thresholdRatio、16% は retainRatio のデフォルトで、プロバイダー・モデルごとに設定可能です。プリナーの 8192/4096/1024 コードポイント予算も設定できます。本ページの数値は 2026-09-23 時点の公式パッケージドキュとの照合値です。定数ではなく現行デフォルトとして扱ってください。
圧縮でも救えない場合は？
システムプロンプト、ツール定義、セッション接頭辞は縮められず、1本の巨大ツール呼び出しのような分割不能な単位も分割されません——動画が硬い境界として挙げる点です。単一の成果物が予算を超えるなら、タスクを分割するか、サブエージェントやバックグラウンドジョブに作業を移し、メインセッションには結論だけ受け取らせましょう。
関連ガイド
DSH 学習パスの隣接トラック。
DeepSeek Harness のトークン使用量とコスト追跡
圧縮でどれだけ節約できたかは、測ってこそ。セッション内・ログ・プロバイダーの利用ページで突き合わせましょう。
ガイドを読むDeepSeek Harness の4モード比較
standard・code（PTC）・cordis の各 Web プリセットは同じ圧縮グループを共有。それ以外の違いはこちら。
ガイドを読むDeepSeek Harness トラブルシューティング
コンテキスト超過エラーや圧縮リトライなど、長時間セッションの落とし穴と確実な直し方。
ガイドを読むDeepSeek Harness サブエージェント実践ガイド
1つのコンテキストでは足りないとき：長いタスクをサブエージェントとバックグラウンドジョブに分担させましょう。
ガイドを読むdsh TUI ターミナルガイド
ask_user_question とバックグラウンドジョブが同一画面に並ぶ、長時間タスクに最適なターミナル
ガイドを読む出典とクレジット
13枚のフレームはすべて同一動画の静止画です——ナレーション付きの仕組み解説アニメーションであり、公式製品 UI や実機録画ではありません。各画像は元動画の該当秒へ深リンクします。同一解説は YouTube では 01Coder、Bilibili では 五里墩茶社 が公開しています（同一作者：小木頭）。