セッションのファイルは生成されているのに、再起動後に続きから開けない。 最短解決は、単一マシンで逐セッションのバックアップを優先するなら JSONL を先に検証し、構造化検索が必要で信頼できるローカルディスクを使える場合だけ SQLite を選ぶことです。

この判断は、DeepSeek Harness の公式設定を確認したうえで行ってください。現在は開発者プレビューで、互換性を壊す変更が予定されているため、拡張子や設定例だけを見て「安全」と決めるのは危険です。公式リポジトリも、開発者プレビュー中で互換性のない変更があり得ると明記しています。(公式リポジトリのプレビュー説明)

このページは、会話を長期間保存したい個人開発者、クラウドMacで複数セッションを運用するチーム、監査・復旧基準を作るプラットフォーム担当者向けです。短い試用だけで後端を決めず、停止、再起動、再開、バックアップの復元まで確認したい人に向いています。

最初に保存方式を決める判断軸

DeepSeek Harness のセッション保存は、単なるログ出力ではありません。公式アーキテクチャでは、セッションイベントを追記型のログとして扱い、再開、フォーク、表示、テレメトリ、永続化が同じイベントストリームから派生します。つまり、バックアップ対象は「検索結果」や「画面表示」ではなく、再構成に必要な永続イベントです。(公式アーキテクチャ資料)

まず、次の条件で仮決定してください。

  • 個人利用、単一マシン、会話単位のコピーを重視するなら、JSONL 会話保存を先に検証します。
  • 大量セッションから条件検索、イベント追跡、系譜確認を行うなら、SQLite と派生検索インデックスを評価します。
  • SQLite のデータベースをローカルの APFS ボリュームに置けないなら、ネットワーク接続ストレージへの配置を急がないでください。
  • 保存場所がクラウドMacであっても、バックアップ先をネットワーク共有にしただけで SQLite の運用条件を満たすわけではありません。
  • 旧方式を削除してから新方式へ移行せず、旧データを読み取り専用で残して小規模なセッションから検証します。
公式のパッケージ一覧でも、session は JSONL と SQLite のバックエンド、投影処理、セッションレポートを持つ領域として分けられています。また、検索機能を担う session-query は別パッケージです。保存本体と検索用の派生データを同一視しないことが重要です。([公式パッケージ一覧](https://raw.githubusercontent.com/deepseek-ai/deepseek-harness/master/packages/README.md))

単一マシンの試用と逐セッション保存

短期試用では、SQLite の検索性能よりも「壊れたときに中身を確認できるか」が優先されます。JSONL はイベントを行単位で扱えるため、バックアップ対象をセッションごとに分けやすく、差分確認や部分的な退避もしやすい構成です。ただし、JSONL だから自動的に耐障害性が高い、という意味ではありません。

DeepSeek Harness の標準保存先はどこですか。

環境やプロファイル、設定パッチによって保存先が変わる可能性があるため、固定パスを記事だけで断定しないでください。起動時に実際の設定をダンプし、セッションルート、バックエンド、ログ形式、検索用インデックスの場所を記録します。公式アーキテクチャ資料では、dsh --profile web --dump-config によって実際に起動する設定ツリーを確認できると説明されています。(設定ツリー確認の公式資料)

確認する順番は次のとおりです。

  1. 起動するプロファイルと Harness のバージョンを記録します。
  2. --dump-config 相当の方法でセッションルートと保存バックエンドを確認します。
  3. 物理エンコーディングを確認し、エディターや file コマンドで読めることを確かめます。
  4. セッションを正常終了させ、プロセス終了後にも最新イベントが読めるか確認します。
  5. セッションディレクトリを別の場所へコピーし、コピー先で一覧と再開を試します。
  6. 復元したセッションで短い追加入力を行い、新しいイベントが正しい場所へ追加されるか確認します。
JSONL 会話保存が長期運用に向くかは、拡張子ではなくこの停止・再開試験で決まります。追記中にプロセスを強制終了し、再起動後に最後の確定イベントまで戻れるかを確認してください。最後の行が不完全な場合に無視できるのか、起動時にエラーになるのかも記録しておく必要があります。

注意：ファイルが存在すること、サイズが増えていること、バックアップツールがコピーできることは、復旧成功の証拠ではありません。最小の復元セッションで再開と追記まで完了して、初めて保存テストを合格にします。

長期エージェントと継続書き込み

長時間動くエージェントでは、保存方式よりも書き込みの境界が問題になります。モデル応答、ツール呼び出し、ツール結果、再試行、停止状態などがどのタイミングで永続化されるかを確認しないと、再開時に「画面に見えていた内容」と「保存された履歴」がずれることがあります。

JSONL を選ぶ場合は、次の証拠を取得します。

  • 数回の追加入力後に、ファイル末尾へイベントが追記されている。
  • 実行中のプロセスを終了しても、再起動後に最後の確定ターンを認識できる。
  • ツール実行の途中で停止した場合、未完了イベントを再実行するのか、失敗として閉じるのかが一貫している。
  • 同じセッションを再開してから、重複したユーザー入力やツール結果が生成されない。
  • 冷却期間を置いたセッションでも、一覧、再開、エクスポートが成立する。
SQLite を選ぶ場合も、同じ試験を実施します。データベースファイルが一つにまとまっているから復旧しやすい、という判断はできません。データベース本体、-wal、-shm などの関連ファイル、チェックポイント状態を含めたバックアップ単位を確認する必要があります。

SQLite の WAL モードは、読み取りと書き込みを並行しやすくする一方、共有メモリを使うため、同じホスト上での利用を前提にしています。SQLite 公式資料も、WAL はネットワークファイルシステムでは動作しないと明記しています。(SQLite の WAL 公式資料)

チーム検索と監査用インデックス

セッション数が増えると、「特定のツール名を使った会話」「失敗したイベント」「あるプロジェクトの再試行履歴」を絞り込みたくなります。この段階では SQLite の構造化クエリや全文検索インデックスに価値があります。

ただし、検索を有効にするために、必ずしも保存本体を置き換える必要はありません。次のように役割を分けてください。

  • セッション永続化バックエンド：再開に必要なイベントを保存します。
  • 派生クエリインデックス：検索、集計、監査画面の表示を高速化します。
  • 通常ファイルバックアップ：保存されたセッションと設定を別媒体へ退避します。
この3つを一つの SQLite ファイルに集約すると管理しやすく見えますが、検索用インデックスを失っても元ログから再生成できる設計かどうかで復旧責任が変わります。検索インデックスを唯一の原本にしないでください。

クラウドMacで、どの保存方式がバックアップしやすいですか。

単一セッションを個別に渡したいなら、一般には JSONL のほうが対象を説明しやすく、ファイル単位の退避も行いやすいです。一方、チーム全体の履歴を条件検索したい場合は SQLite が便利ですが、データベース関連ファイルと整合性のあるバックアップ方法を運用に組み込む必要があります。

クラウドMacでは、セッションルートだけでなく、設定ファイル、バージョン情報、認証情報の参照方法、検索インデックスの再生成手順も納品対象に含めます。クラウドMacの利用環境を整える場合は、MACGPUのMac利用案内と、用途別のMacレンタル構成の確認ページも併せて確認してください。

ローカルディスクとネットワーク接続ストレージ

ローカルディスクでは、SQLite のロック、同期、チェックポイントを同一ホスト内で完結させやすくなります。ネットワーク接続ストレージでは、ファイルロックの見え方、キャッシュ、切断時の書き込み結果、共有メモリファイルの扱いが環境ごとに変わります。

SQLite の WAL をネットワーク接続ストレージに置けますか。

WAL を有効にした SQLite データベースを、そのままネットワーク共有へ置く前提では設計しないでください。SQLite 公式資料では、ネットワーク越しのファイルロックや遅延、複数ホストからのアクセスが問題になり得ると説明され、WAL は同一ホストの共有メモリを必要とします。(SQLite のネットワーク利用に関する注意)

ネットワーク共有を使う必要がある場合は、少なくとも次を実施します。

  1. 同じセッションへ同時に2プロセスが書き込まないことを確認します。
  2. -wal と -shm の生成場所、権限、コピー対象を確認します。
  3. 書き込み中に共有を切断し、再接続後の整合性を確認します。
  4. 強制終了、Macの再起動、共有側の一時停止をそれぞれ試します。
  5. ロック取得失敗時に無限待機しないことを確認します。
  6. 復旧後にセッション一覧、イベント検索、再開、追加入力を順に実行します。
検証できない共有データベースは、本番の原本にしないでください。ネットワーク共有はバックアップ先として使い、実行中の SQLite は信頼できるローカルディスクに置く構成のほうが、責任範囲を明確にしやすい場合があります。

経験則：ネットワーク共有へコピーした SQLite が開けたことと、ネットワーク共有上で安全に書き続けられることは別の試験です。読み取り確認だけで運用可と判定しないでください。

後端移行と切り戻し手順

JSONL から SQLite、または SQLite から JSONL へ変更する場合は、データ変換の成功だけでなく、元セッションの意味が保たれているかを確認します。開発者プレビューでは互換性を壊す変更があり得るため、異なるバージョン間でそのまま再利用できるとは約束できません。(DeepSeek Harness 公式リポジトリ)

移行は次の手順に固定します。

  1. 移行前に Harness のバージョン、プロファイル、設定パッチ、保存先、バックアップ日時を記録します。
  2. 旧バックエンドを読み取り専用の保管物として残します。
  3. 代表セッションを少数だけ選び、新バックエンドへ複製します。
  4. セッション名、最終イベント、ツール結果、再開位置、検索結果を比較します。
  5. 強制終了と再起動を行い、移行後セッションへ追加入力します。
  6. 失敗した場合は設定を旧バックエンドへ戻し、旧データから作業を再開します。
  7. 問題がないことを確認してから、移行対象を段階的に増やします。
移行完了の判定は「ファイル変換が終わった」ではなく、「旧記録と新記録の双方で再開と監査ができる」にします。特に検索インデックスを新規生成する場合、ヒット件数だけでなく、元イベントとの対応関係も確認してください。

選択結果と運用上の出口

判断を迷ったら、次のスコアで候補を絞ります。各項目を満たす方式に1点を加え、同点ならバックアップと復旧テストが簡単な方式を優先します。

<
判断項目JSONLSQLite
個別セッションを簡単にコピーしたい21
人手でイベントを点検したい21
大量履歴を条件検索したい12
信頼できるローカルディスクを使える12
ネットワーク共有へ直接配置したい10
検索インデックスを別管理できる12
移行時に旧データを残せる22
個人の試用、短期の検証、逐セッションのバックアップを優先するなら JSONL を選びます。長期エージェントをチームで管理し、構造化検索と監査を必要とするなら SQLite を検討します。ただし、SQLite の実行場所がネットワーク共有になる時点で、WAL、ロック、異常終了、再開のテストに合格するまで採用を保留してください。

現在のローカル環境は、保存場所を自分で管理できる反面、再起動後の復元確認、バックアップの世代管理、ディスク障害時の交換作業を自分で負担します。一般的な共有ストレージは複数端末から扱いやすい一方、ロックと同期の境界が不透明になり、SQLite の関連ファイルを含む整合バックアップにも注意が必要です。長期運用で作業環境そのものを遠隔化したい場合は、こうした復旧責任を含めてクラウドMacへ移すかを判断してください。

まずは保存期間、検索の必要性、実行ディスクの種類を選択表に当てはめ、1つの代表セッションで停止・再起動・復元・追記を実施します。遠隔環境への移行を予定しているなら、次にクラウドMacでのセッション復旧と受け渡し条件を確認し、検証可能な環境だけを本番運用へ進めるのが安全です。