2026 DeepSeek Harness プラグインの段階リリースは、唯一の実行環境へ一括適用せず、現行セットを固定して独立環境で「読み込み、最小タスク、権限、永続化、再起動」の順に確認してから分割切り替えするのが安全です。今週は、まず自動更新を止め、旧プラグイン一式と基準タスクの証跡を保存してください。

01

この手順が必要な運用担当者

共有Agentや共通ワークスペースを管理するプラットフォーム担当者は、承認済みのバージョンセットと回退手順を作る必要があります。dsh-pluginを開発する作者は、Host、Client、Cordisの依存契約が新バージョンでも成立するかを確認します。

長時間Agentを遠隔Macで動かす運用担当者は、更新作業そのものよりも「更新中に旧セッションを失うこと」と「再起動後に同じタスクを続けられないこと」を警戒しなければなりません。

DeepSeek Harnessは、2026年8月19日時点で開発者プレビューとして扱われ、破壊的な互換性変更が起こり得ます。v0.1.0-rc.7ではプラグイン設定カードが追加されていますが、これだけで第三者プラグインの安定互換性が保証されたとは判断できません。変更内容は、公式README、rc.7のリリース情報、対象プラグインのソースで照合してください。

02

0日目に現行プラグイン組み合わせを凍結する

最初に保存するのはプラグイン名の一覧ではありません。回退に必要なのは、次の組み合わせが同じ状態で再現できる証拠です。

  • Harness本体のバージョンと取得元
  • 各プラグインのバージョン、取得元、コミットまたは配布物
  • npmなどの依存関係を解決したロックファイル
  • 設定ファイルの場所、環境変数名、起動コマンド
  • HostとClientの接続方法
  • 現在完了できる読み取り専用の基準タスク
  • 実行ログ、ツール一覧、権限一覧、セッション保存先

作業前に、取得元が同じであることも確認します。例えば公式のNode系パッケージと、別経路で配布された同名のdsh-pluginを混在させると、名前だけでは依存関係を判別できません。公式のパッケージ構成ディレクトリも参照し、実際の構成と保存したロックファイルを照合します。

node --version
npm --version
npm ls --depth=0 > before-packages.txt
cp package-lock.json package-lock.before.json
cp -R .dsh-config .dsh-config.before

出力例は、あくまで保存対象の形式を示すものです。

@deepseek-ai/dsh@0.1.0-rc.7
@deepseek-ai/dsh-session@0.1.0-rc.7
@target/dsh-plugin@0.4.2

実際のパッケージ名、設定キー、依存バージョンは、公式の設定関連ディレクトリと対象プラグインの現在のソースから確認してください。存在を推測して設定キーを追加する方法は避けます。

注意：ロックファイルだけでは永続的な安定性は保証されません。Host、Client、Node実行環境、OS権限、保存先が変われば、同じロック状態でも動作が変わる可能性があります。

03

1日目は正式環境と別の検証面を作る

次に、独立したワークスペースまたは別の遠隔Macへ、必要な設定だけを複製します。実際の顧客認証情報、外部サービスの本番キー、削除や送信を伴う不可逆タスクは複製しません。

検証面で重要なのは、正式環境と同じ「インストール経路」と「起動方法」を使うことです。正式環境がローカルビルドなら検証面だけをパッケージ実行へ変えず、正式環境が固定済みの配布物なら、検証面だけソースの最新ブランチを使わないようにします。

最低限、次を分離します。

  • ワークスペースと作業ブランチ
  • セッション保存先
  • 認証情報と環境変数
  • 外部接続先
  • プラグインのインストール先
  • ログと回退用バックアップ

唯一のMacしかなく、旧環境を並行して保持できない場合は、そこで更新を実行しない判断が優先です。先にNodeMiniのMac運用環境のような別実行面を用意し、検証が終わるまで本番面を触らない構成にします。

04

2日目は読み込みと設定契約だけを確認する

第一段階では、外部へ書き込むツールや長時間Agentを動かしません。確認対象は、プラグインが発見されるか、設定が読めるか、HostとClientが起動するかです。

npm ci
npm run build
npm run start -- --config ./config.validation.json

ログでは、次の項目を個別に記録します。

  • プラグインの発見結果
  • 依存サービスの初期化順序
  • 設定値の読み込み結果
  • HostとClient間の接続状態
  • 警告、非推奨通知、未解決依存
  • 起動後に登録されたツールとイベント

成功条件は「画面が開いた」では不十分です。旧環境と新環境で、期待するプラグインが同じ名前で登録され、必須設定が同じ意味で解釈され、起動時エラーがないことをログで確認します。

Cordisを利用する構成では、サービス登録やコンテキスト変更の境界が変わっていないかを見ます。プラグイン名が同じでも、登録タイミング、依存サービス、イベント購読先が変われば、起動後の挙動は別物になります。API接続やツール呼び出しを含む構成では、公式のTool Calls仕様と対象プラグインの実装を突き合わせます。

05

3日目は最小タスクと権限境界を回帰する

第二段階では、読み取り専用タスクを1つ、回復可能な書き込みタスクを1つ選びます。読み取りタスクはファイル一覧や設定の表示など、外部送信を伴わないものにします。書き込みタスクは専用の一時ディレクトリへファイルを作成し、削除またはGit差分の破棄で戻せるものに限定します。

確認項目は次の順番です。

  1. 旧環境と新環境のツール登録一覧を保存する。
  2. 追加、削除、名称変更されたツールを比較する。
  3. 承認が必要な操作と自動実行される操作を分ける。
  4. サンドボックスの対象パスと外部接続範囲を確認する。
  5. 書き込み結果を回復し、ログ上の結果返却を確認する。
  6. 権限が広がった場合は、更新を止めて別途承認する。
diff -u tools.before.txt tools.after.txt
diff -u permissions.before.json permissions.after.json

出力に新しいファイル操作、ネットワーク接続、シェル実行などが現れた場合、便利になったかどうかではなく、承認済みの設計かどうかで判断します。権限拡大を「プラグイン更新に含まれる通常変更」と扱うと、共有Agent全体の安全境界を見失います。

06

4日目はセッション、永続化、再起動を別々に検証する

第三段階では、会話状態と長時間タスクを確認します。ここでは「サービスが再起動できたこと」と「実行中だったタスクを続行できたこと」を混同しないことが重要です。

思考モードやツール呼び出しを利用する場合は、公式のThinking Mode仕様にある会話状態の扱いも確認します。ツール呼び出し後の応答情報を保存しない実装では、Harnessが起動しても既存タスクの継続に失敗する可能性があります。

次の順に試します。

  • 新規セッションで基準タスクを実行する。
  • 既存セッションを読み込み、履歴と設定を確認する。
  • プラグインを停止して再起動する。
  • Harness本体を再起動する。
  • Macのログインセッションまたはプロセスが再生成された後に状態を確認する。
  • 長時間タスクを、前段階がすべて成功した場合だけ実行する。

成功の証拠は、単にプロセスが起動したという表示ではありません。セッション識別子、作業位置、未完了タスク、プラグイン状態、設定値が想定どおり復元され、再開後の結果が旧環境と比較できることです。

DeepSeek Harnessのバージョン更新検証に関する運用記事も参照し、再起動試験を「起動確認」と「タスク継続確認」に分けて記録してください。

07

分割切り替えは低リスクの実行面から進める

検証を通過したら、遠隔Macを一度に更新せず、リスクの低い順に切り替えます。例えば、内部検証用、失敗しても再実行できる短いジョブ、共有ワークスペース、長時間Agentの順です。

各グループを切り替えるたびに、次の観察を行います。

  • プラグインが期待どおり読み込まれたか
  • 旧セッションに影響がないか
  • 承認待ち操作が自動化されていないか
  • 再起動後に状態が残るか
  • ログに新しい警告や未解決依存がないか
  • 次のグループへ進める責任者が明確か

Harness本体、dsh-plugin、Cordis関連依存を同時に変更した場合、異常時に単一パッケージだけを戻してはいけません。更新前の完全な既知セットへ戻します。混合バージョンは、見かけ上起動できても、後からセッション復元やツール登録で不整合を起こすためです。

切り替え前の可否判定

  • [ ] 現行プラグイン、依存、ロックファイルを保存した
  • [ ] 旧環境で基準タスクを再実行できた
  • [ ] 独立した検証面を用意した
  • [ ] 顧客認証情報と不可逆タスクを検証面から除外した
  • [ ] 新プラグインの読み込みログを保存した
  • [ ] ツール登録一覧を更新前後で比較した
  • [ ] 権限変更を確認し、追加権限を承認した
  • [ ] 新規セッションと既存セッションを確認した
  • [ ] Harness再起動とタスク継続を別々に確認した
  • [ ] 失敗時に組み合わせ全体を戻す手順を試した
  • [ ] 切り替え責任者と次回再確認の条件を記録した

経験則：観察時間を短くするために複数グループを同時に切り替えると、障害範囲と原因候補が増えます。切り替え単位を小さくできない場合は、更新を延期して第二の実行面を先に作る方が合理的です。

08

更新を見送るべき条件

次のいずれかに該当する場合、段階リリースではなく延期または別環境での検証を選びます。

  • 旧バージョンの実行面を残せない
  • ロックファイルを再現できない
  • 対象プラグインのソースやリリース情報を確認できない
  • 新しい権限の用途を説明できない
  • セッションの保存先が不明である
  • 再起動後に同じタスクを続けられる証拠がない
  • Harness本体とプラグインを別々に回退できない
  • 本番認証情報を使わなければ検証できない

現在の構成を1台のMacへ集約したまま更新すると、停止、再検証、回退を同じ実行面で行うことになります。特に、共有Agent、長時間タスク、顧客データ、外部書き込みが重なる場合、ローカルMacの一括更新は短期的には簡単でも、障害時の復旧経路が狭くなります。NodeMiniのMacを使った一時的な検証環境なら、旧セットを保持したまま別の遠隔Macで確認する運用を組みやすくなります。

09

よくある判断

dsh-pluginの更新に失敗した場合

更新前に保存したロックファイル、依存関係、設定、起動方式を一式で戻します。単一パッケージだけを降格せず、旧環境で基準タスク、既存セッション、権限一覧を確認してから共有環境へ復帰させます。

チームのプラグインバージョンを統一する場合

本番の共有環境は承認済みの組み合わせを固定します。一方、開発者の検証環境まで同じ変更を即時反映させず、安定版セットと試験版セットを分離し、検証結果を記録してから昇格させます。

遠隔Macを分けて更新する場合

低リスクのジョブを担当するMacから切り替え、セッション、権限、再起動を確認した後に共有環境へ広げます。旧セットを別のMacまたは別ディレクトリに残せない場合、更新開始条件を満たしていません。

現行の単一Mac運用や一括更新は、手順が短い反面、共有Agentの停止、依存関係の混在、再起動後の状態消失という3つの弱点を抱えます。長期の高負荷処理や物理インターフェースが必要な用途では自前のMacが適しますが、短期の検証や段階切り替えで第二の実行面が必要なら、NodeMiniのMacレンタルを使って旧環境を残しながら検証する方が、回退経路まで含めて設計しやすくなります。