2026年DeepSeek Harness会話ログ容量は先に実測

容量計算の前提

必要容量は、次の式で管理します。

必要容量
= セッション永続化
+ ツール出力
+ 画像添付
+ ワークスペース成果物
+ 実行キャッシュ
+ バックアップ副本
+ 復旧余白

ここで注意したいのは、モデルが消費するTokenと、Macストレージに書き込まれるバイト数は別の指標だという点です。入力が長くてもログに保存される形式が圧縮されていればディスク増分は小さくなる場合がありますが、ストリーミング断片、ツール結果、画像の実体が保存されれば、Token表示だけでは容量を説明できません。

DeepSeek Harnessの公式仕様では、Sessionは型付きSessionEventを追記するイベントログとして扱われ、LLM向けの履歴はこのログから再構成されます。したがって、見えている会話本文だけでなく、ターン境界、モデル出力断片、ツール呼び出し、ツール結果、リクエスト情報なども測定対象に含めます。詳しくは公式のセッション仕様と公式アーキテクチャ資料を確認してください。 (github.com)

SessionEventの増加要因

SessionEventは、単純なユーザーメッセージの件数ではありません。公式ドキュメント上、turn/start、turn/end、step/start、step/end、user/message、assistant/chunk、assistant/message、tool/call、tool/resultなどが永続化対象になります。特にassistant/chunkは再生や画面表示の忠実度を保つため、正規ログから除外できない仕様です。 (github.com)

このため、同じ10往復の会話でも、ファイル検索だけを行うタスクと、ビルド、テスト、サブエージェント呼び出しを連続させるタスクでは増分が変わります。長いコード検索結果や標準出力をそのままツール結果として記録すれば、可視の回答文よりログが大きくなることもあります。

会話ログの保存場所

保存場所はバックエンドによって異なります。公式の永続化仕様では、JSONLバックエンドはセッションごとのログファイルを持ち、SQLiteバックエンドは1つのデータベース内にイベント単位の行を保存します。JSONLではセッションの物理パスを取得できますが、SQLiteではセッション専用ファイルが返らないため、特定ディレクトリを前提にした清掃スクリプトは避けるべきです。 (github.com)

稼働中の環境では、まず実際の設定と保存先を確認します。

dsh --profile web --dump-config > dsh-config.txt
find "$HOME" -type f \( -name "*.jsonl" -o -name "*.db" -o -name "*.sqlite" \) -print

出力例は次のように記録します。これは固定の標準パスを示すものではなく、測定対象を特定するための記録形式です。

backend=jsonl
artifact=/実行環境で確認したセッション保存先
before=取得した使用量
after=取得した使用量
delta=after-before

ツール結果と長時間タスク

長時間タスクでは、モデル出力よりもツール結果が上限を決める場合があります。ビルドログ、テスト失敗時のスタックトレース、大量のgrep結果、生成コードの差分は、会話ログに残るデータとワークスペースにだけ残るデータを分けて扱う必要があります。

同じ基準タスクを使い、次の条件を個別に測定します。

• コマンド出力を全量保存する。
• 標準出力を要約してから会話へ渡す。
• 大きな成果物を会話へ貼らず、ワークスペースのファイルとして残す。
• エラー時だけ詳細ログを保存する。

ここで、削減率を推測してはいけません。現在のバージョン、ツールプラグイン、圧縮方式、出力内容によって差が変わるため、各条件の実行前後でduまたはファイルサイズを取得します。

du -sh "$WORKSPACE"
find "$WORKSPACE" -type f -print0 | xargs -0 stat -f '%z %N' | sort -nr | head

ワークスペース成果物を削除しても、すでにtool/resultとして会話ログへ書かれた内容は減りません。逆に、ワークスペース上の生成物だけを別ボリュームへ移しても、再開に必要な参照関係や作業ディレクトリを失えば復元性が下がります。

画像添付の実測

画像添付は、枚数から容量を推定しないことが重要です。元画像、変換後のデータ、セッションに記録された参照情報、再開時に作られる一時的なコピーが同じ場所に存在するとは限りません。

現行の公式資料では、画像を含む永続化能力が案内されていますが、具体的な保存形式や互換性はリリースごとに確認が必要です。開発者プレビューは互換性を壊す変更があり得るため、画像添付を使う場合は、リリースノートと現在のソースを確認してから基準測定をやり直します。開発者プレビューの注意事項も運用記録に残してください。 (github.com)

測定では、画像の元ファイルとセッション再開後の容量を別々に取得します。

IMAGE="/path/to/sample-image"
du -h "$IMAGE"
find "$HOME" -type f -newermt "2026-08-18 00:00:00" -print

画像添付を含む代表タスクについて、次の3時点を記録します。

1. 添付前のセッション保存先。
2. 添付して応答を完了した直後。
3. プロセスを終了し、同じセッションを再開した直後。

機密性のある設計図、顧客画面、認証情報を含む画像は、単なるキャッシュではなく監査対象になり得ます。容量を減らす目的で削除する前に、保管義務、アクセス権、復元要件を確認します。

バックアップと復元

バックアップ容量は、作業用の空き容量として数えてはいけません。オンラインのセッションとワークスペースに加えて、スナップショット、移行用コピー、障害時の回退版が存在するなら、それぞれを別の副本として計上します。

公式の永続化仕様では、JSONLはチェックサム付きのZstandardフレームまたは未圧縮の行形式を扱い、SQLiteはイベントを行単位で保存します。また、読み込み時には中断されたターンを復旧処理できますが、保存形式のバージョンが一致しなければ読み込みを拒否する場合があります。つまり、バックアップが読めることと、現在のバージョンでそのまま作業を再開できることは同じではありません。 (github.com)

復元検証は、次の手順で実施します。

基準セッションを停止
→ 保存データを別ディレクトリへ復元
→ 現行バージョンで読み込み
→ 中断ターン、画像、ツール結果、ワークスペース参照を確認
→ 1回以上の追加操作を実行
→ 使用量とエラーを記録

セッション形式、画像添付方式、圧縮方式、コンパクションの挙動が変わった場合は、以前の測定値を新バージョンへそのまま適用しません。

測定手順

次の順で測れば、固定容量を推測せずに必要量を算出できます。

基準タスクの選定

通常の短い質問ではなく、実際の運用に近いタスクを選びます。ファイル検索、編集、テスト、ビルド、失敗からの再実行、画像添付を使うチームなら、それぞれを代表タスクへ含めます。

実行条件の固定

DeepSeek Harnessのバージョン、プロファイル、永続化バックエンド、プラグイン構成、ワークスペース、画像の種類、観察開始時刻を記録します。条件を変えた測定値は、同じ表へ混ぜません。

前後の差分取得

セッション保存先、ワークスペース、キャッシュ、バックアップ先を別々に取得します。可能であればプロセス開始前と終了後だけでなく、ツール結果が増えた直後、画像を添付した直後、復元直後にも取得します。

単位タスク増分の算出

単位タスク増分
= 実行後の対象容量
- 実行前の対象容量

複数回の測定を行う場合は、タスク種別ごとに中央値または保守的な上側の値を採用し、測定回数や採用理由を記録します。出所のない平均値を一般的なDeepSeek Harnessの性能として公開してはいけません。

保留期間と副本数の反映

運用容量
= 単位タスク増分
× 期間内タスク数
× 同時保持セッション数
+ ワークスペース増分
+ キャッシュ
+ バックアップ副本
+ 復旧余白

保留期間を短くすればオンライン容量は抑えられますが、監査記録を失う可能性があります。反対に、すべてを長期保存すれば、ログだけでなく画像、生成物、移行コピーの管理責任も増えます。

清掃と拡張の判断

安全に削除できるデータは、再開に不要で、監査要件を満たし、バックアップまたは再生成手段が確認できるものに限ります。会話ログの一部だけを手動編集したり、イベント行を飛ばしたりすると、再生順序やツール結果との対応関係を壊す可能性があります。

判断は次の条件分岐にします。

• セッションログが保留期間を超え、監査・再開要件も満たす場合は、公式の管理機構またはバックエンド単位の手順で削除します。
• ワークスペース成果物が再生成可能で、成果物の正本が別にある場合は、作業用コピーを整理します。
• 画像の元ファイルが別管理され、セッション内の参照だけを残す必要がない場合は、復元検証後に添付データの扱いを決めます。
• ログを削除できない、形式が不明、復元検証が未実施の場合は、清掃ではなくストレージ拡張へ回します。
• 長期重負荷で容量増分が安定している場合は、レンタルより専用の自前環境や別ストレージが適する可能性があります。

容量計画の記入表

現行環境とクラウドMacの比較

ローカルMacだけで長期運用すると、空き容量の監視、バックアップ先の確保、障害時の復元作業をチーム側で持つ必要があります。自前のWindowsやLinux、一般的なクラウドサーバーへ移す方法もありますが、macOS前提の開発ツール、権限設定、画面経由の確認、ストレージ増設を別々に設計しなければならず、短期検証や期間限定の監査環境では管理項目が増えます。

単位タスクの増分を測定した後であれば、Macレンタルの選び方や、NodeMiniの案内ページで、ログ保留分、同時実行分、バックアップ副本を含めた利用期間を相談できます。長期の固定負荷や物理インターフェースが必要な場合は自前Macが適しますが、検証、監査、移行、短期プロジェクトなら、容量を先に実測してからNodeMiniのクラウドMacへ割り当てる方が、過小なMacストレージを選ぶリスクを抑えやすくなります。

今週は、バージョンとバックエンドを記録し、代表タスクを実行して、SessionEvent、ツール結果、画像添付、ワークスペース、バックアップの5項目を別々に測定してください。測定表が埋まれば、清掃で対応するのか、クラウドMacの容量を拡張するのかを、推測ではなく保留期間と復元要件に基づいて決められます。