DeepSeek Harness データバックアップ移行検収

セッションは開けるのに、別のリポジトリへ書き込もうとしている。

最短の解決策は、DeepSeek Harness データバックアップを「再構築できる環境」「保持すべき会話状態」「作業領域」「認証情報」の4層に分け、最後に隔離環境で実タスクを完了させることです。

この手順は、アップグレード候補版を試す既存ユーザー、ローカル環境をクラウドMacへ移す開発者、継続的なAgent環境を引き継ぐ運用担当者と購買担当者向けです。単にフォルダーをコピーしたいだけで、会話の再開や交付後の検収が不要な場合は、ここまでの確認は必要ありません。

SECTION 01先にバックアップの合否条件を決める

DeepSeek Harnessは現在も開発者プレビューで、公式リポジトリ自身が互換性を壊す変更の可能性を明記しています。したがって、旧環境のフォルダーを新環境へ上書きし、「ファイルが存在するから成功」と判定する方法は危険です。(github.com)

合格条件は、次の4点を同時に満たすことです。

• 会話を一覧から開き、持続イベントを読み取れる。
• 元のリポジトリ、ブランチ、コミット状態と一致している。
• モデル呼び出し、ツール実行、承認処理が隔離環境で動く。
• 実際のAPI Keyを通常のバックアップへ含めず、復元後にも秘密情報が残っていない。

会話ログだけを戻すと作業領域が不明になり、コードだけを戻すと会話の判断履歴や承認状態が消えます。特に長時間のAgent作業では、チャット本文以外のツール呼び出し、承認、モデル選択などが再開判断に影響するため、会話状態を単なるテキスト書き出しとして扱わないでください。

SECTION 02まず何を捨て、何を再構築するか決める

第一段階：環境を記録してから停止する

バックアップを始める前に、次の情報をテキストで保存します。

• DeepSeek Harnessの導入元とコミットまたはリリース識別子
• 実行モード、起動コマンド、使用しているプロファイル
• Node.js、pnpm、Gitなどの依存関係
• モデル識別子、Providerの識別子、カスタムエンドポイントの有無
• DSH_HOMEを使用している場合の実際の値
• 現在開いているセッション数と作業領域の対応表

公式開発ガイドでは、Node.jsは22.19以上または24系、リポジトリのpnpmは11.7.0、Gitは2.26以上が前提として示されています。これは固定の復元保証ではなく、現行ソースを再構築する際の確認材料です。(github.com)

ソースキャッシュ、依存パッケージのキャッシュ、一時ビルド成果物、再インストール可能なソフトウェアは、永久保存する重要状態と分離します。保存するのは「後で同じ状態を作るための記録」であり、不要なキャッシュまで混ぜた巨大な丸ごとコピーではありません。

SECTION 03指標別に見るバックアップ対象と拒収条件

SECTION 04会話完全性は本文ではなくイベント列で判定する

公式の開発資料には、SessionEventをソースとドキュメントの対応対象として管理する記述があります。これは、会話の保存単位を単純な画面表示のテキストと決めつけず、現行バージョンのイベント定義と永続化方式を確認すべき理由になります。(github.com)

実際のバックアップでは、次の順序で検査します。

1. Agentの新規書き込みを停止する。
2. 停止時刻、対象セッション、実行中タスクの有無を記録する。
3. セッション一覧を保存し、件数と識別子を控える。
4. 各セッションから代表例を選び、最初の入力、ツール呼び出し、承認、直近イベントが読めるか確認する。
5. コピー先で一覧件数と抽出結果を比較する。
6. 隔離環境で、会話を開いて安全な読み取り専用タスクを実行する。

書き込み中のデータベースやイベントファイルをそのままコピーすると、最後のイベントだけ欠けたり、インデックスと本体の状態が一致しなかったりします。停止できない場合は、取得時刻をそろえたスナップショットなど、一貫性境界を作れる方法を選び、通常のファイルコピーを完全バックアップと呼ばないでください。

注意：開発者プレビューでは会話形式のバージョンや内部配置が変わる可能性があります。具体的なディレクトリ一覧を固定手順として配布する前に、使用中のコミットと実行モードで現物を確認してください。

SECTION 05作業領域を先に固定しないと復元を拒収する

DeepSeek HarnessのWeb UIガイドでは、起動したディレクトリを初期のファイルシステム位置として扱い、別途ワークスペースを選択する流れが説明されています。つまり、会話が開けても正しいリポジトリが自動的に選ばれるとは限りません。(github.com)

各セッションについて、次の対応表を作ります。

• 絶対パスまたは移行後の正規パス
• リモートURLと対象リポジトリ
• ブランチ名とHEADのcommit
• 未コミット変更、未追跡ファイル、stashの有無
• サブモジュール、ローカル設定、生成物などの外部依存
• Agentに書き込みを許可してよい範囲

Gitで復元できるソースと、ローカルにしか存在しない成果物を分けることも重要です。リポジトリに含まれるファイルはクローンとチェックアウトで戻せますが、未追跡ファイル、秘密ではないローカル設定、無視対象の生成物は別途確認しなければなりません。

復元後は、最初にパスとcommitを表示し、差分を保存してからAgentを読み取り専用で起動します。正しい作業領域であることを確認する前に書き込み権限を与えると、誤ったプロジェクトへ変更を加える事故を止めにくくなります。

SECTION 06設定とプラグインは互換性を仮定しない

設定は一つのファイル群として扱わず、次の境界で分けます。

• ユーザー単位の設定
• プロジェクト単位の設定
• 実行環境に依存する設定
• Providerとモデルの設定
• プラグイン、Skills、プロジェクト指示ファイル

公式ガイドでは、Web UIの設定画面からモデルとAPI Keyを登録し、ワークスペースを別に選択する手順が分かれています。これは、モデル設定と作業領域を同じバックアップ対象として無条件に上書きしないための判断材料です。(github.com)

プラグインは、旧バージョンの設定をそのまま読ませるのではなく、まず一覧化し、現行バージョンで読み込めるかを個別に確認します。Skillsや指示ファイルも、ユーザー領域へ置くもの、プロジェクトへ置くもの、実行環境へ再導入するものを記録してください。

公式リポジトリの開発者プレビュー表示は、旧設定、第三者プラグイン、新しいイベント形式の組み合わせを自動的に保証するものではありません。互換性が未確認なら、復元ではなく再設定として扱い、旧設定を退避したうえで最小構成から追加します。(github.com)

SECTION 07FAQ：よくある省略判断を先に潰す

DSH_HOMEだけで会話を戻せるとは限らない

DSH_HOMEは重要な確認対象ですが、その名前だけを根拠に完全な保存範囲と判断しないでください。起動方法、実行モード、イベントの保存先、設定の分離方法を現行環境で確認し、会話一覧と代表イベントを実際に読み出せることまで検収します。

会話ログと作業領域は別物だが、対応関係は一体で管理する

会話ログと作業領域は同じ場所へ保存する必要はありません。しかし、どの会話がどのリポジトリ、ブランチ、commitに対応するかは一つの台帳で管理します。対応表がなければ、別のプロジェクトへ会話を復元する事故を発見しにくくなります。

API Keyは通常のバックアップから除外する

バックアップファイルへAPI Keyを入れると、圧縮ファイル、転送先、バックアップ履歴、ログのどこか一箇所が漏れただけで利用可能な秘密情報になります。参照名だけを保存し、復元時に別経路で注入してから、不要になったキーを交換する運用が安全です。

SECTION 08実際の復元を5段階で検収する

第一段階：隔離コピーを作る

本番の作業領域へ直接戻さず、新しいユーザー領域または一時ディレクトリへ復元します。ネットワーク接続やAPI呼び出しを制限できるなら、最初は読み取り確認を優先します。

第二段階：環境を再構築する

記録した導入元、コミット、Node.js、pnpm、Gitの条件から新環境を作ります。公式のソース導入手順では、依存関係の導入後にビルドを実行し、Web UIを起動する流れが示されています。(github.com)

第三段階：会話と設定を別々に戻す

会話イベントを先に読み取り、設定とプラグインは最小限の構成で追加します。設定を一括上書きして起動不能になった場合でも、どの変更が原因か追跡できるように、投入単位ごとに差分を残します。

第四段階：作業領域を照合する

パス、リポジトリ、ブランチ、HEAD、未コミット差分を確認します。Web UIを利用する場合、ワークスペースを明示的に選択し、選択前にAgentへ書き込みを許可しないでください。公式ガイドでも、ワークスペース選択後にセッションを実行する流れになっています。(github.com)

第五段階：可逆タスクを最後まで実行する

新規ファイルを作らない読み取りタスク、または専用の一時ブランチ上で戻せる小さな変更を選びます。会話を開く、モデルを呼ぶ、ツールを実行する、承認を確認する、対象作業領域へ期待どおりの変更を加える、差分を戻す、という一連の記録を残します。

Web UIは標準でローカルの127.0.0.1:3080に提供されると公式ガイドに記載されています。遠隔環境へ移す場合は、ポート公開の有無だけでなく、認証、接続元制限、作業領域の分離も検収対象に含めてください。(github.com)

SECTION 09交付前に残す証跡と拒収条件

運用担当者が署名できる証拠パッケージには、少なくとも次を含めます。

• 移行前後のバージョン、コミット、実行モード
• 4層の資産台帳と除外理由
• セッション件数、抽出したイベント、復元後の比較結果
• 作業領域ごとのパス、ブランチ、commit、変更状態
• 設定とプラグインの差分、読み込み結果
• API Keyを含めていないことの確認と、復元後の再登録・交換記録
• 実タスクの入力、承認、ツール結果、最終差分

次のいずれかに該当する場合は、ファイルが揃っていても拒収します。

• 会話本文は見えるが、イベントやタスク状態を読み取れない。
• 作業領域のパスまたはcommitを証明できない。
• 旧プラグインが読み込めず、代替設定も記録されていない。
• バックアップやログに実際のAPI Keyが残っている。
• 実タスクを実行せず、一覧表示だけで復元成功としている。

DeepSeek HarnessのアップグレードやクラウドMacへのセッション移行では、受け渡し時点の環境記録と検収票を一緒に管理すると、後から「どの時点で壊れたか」を切り分けやすくなります。長期運用では、クラウドMacの交付条件にも、作業領域の分離、接続方法、認証情報の投入方法を明記しておくと安全です。

現在の端末だけで移行を試す場合、旧環境を止める時間が取れない、隔離コピーを作れない、復元後に同じタスクを試す空き環境がない、という3つの制約が起きやすくなります。そうした条件では、購入して常設環境を増やすより、まずMACNOXのMacレンタル構成で一時的な検証環境を用意し、四層の資産台帳と実タスクの証跡をそろえてから本番移行を判断するほうが、誤復元と秘密情報の混入を切り分けやすくなります。

SECTION 10よくある質問 FAQ

SECTION 11関連記事

• DeepSeek Harnessのコンテキスト圧縮でコストを削減する方法
• macOS移行時に確認したい互換性とソフトウェアの検証項目
• チームで共有するMacの権限管理と安全な運用方法