DeepSeek Harnessはどう使う？dshのインストールとデプロイ、Agent Harnessプラグインアーキテクチャ、AI CodingワークフローとClaude Code/Codex比較実践

2026年9月21日時点で、DeepSeek Harnessは公式に「developer preview」として案内されています。公式リポジトリにはnpx起動とソースコードからの構築経路が示されています。この2点から判断すると、DeepSeek Harnessはすぐに既存のAI Coding環境を置き換える製品ではなく、プラグイン化されたAgent Runtimeを研究し、自分のツールチェーンを組み立てたい人が小さく試す段階です。公式情報はDeepSeek Harnessのリポジトリで確認できます。

この記事を読むべき人

個人でオープンソースのAgent Harnessを研究したい開発者は、拡張構造と起動経路を重点的に確認してください。
クラウド開発環境を計画している技術責任者は、遠隔アクセス、権限、セッション保存、プラグインの管理方法に注目してください。

一方、チームが求めているものが「毎日の修正作業を安定して終わらせること」だけなら、直ちに移行する必要はありません。既存のAgentを残し、限定したリポジトリで双方向に試す判断が安全です。

最初に決める：研究用か、納品業務用か

DeepSeek Harnessをすぐ試してよいのは、次の条件に当てはまる場合です。

• プラグインを差し替えながらAgentの実行モデルを検証したい
• 独自ツール、社内スキル、サンドボックスを組み合わせたい
• ローカルまたはクラウド上に自分で実行環境を管理したい
• 互換性の変化や設定調整に対応できる担当者がいる

反対に、次の条件が強いチームは、まず現行環境を維持してください。

• 既存の権限、監査ログ、開発ルールを変更できない
• 全員が同じ操作で安定して利用する必要がある
• Agentの出力差より、納期と再現性を優先する
• プレビュー段階の破壊的な変更を吸収できない

判断は「移行するか、しないか」の二択ではありません。個人研究者ならすぐに試用し、AI Codingを多用する開発者なら既存環境との双方向運用にし、安定納品を担うチームなら検証完了まで移行を保留する、という3段階が現実的です。

注意：developer previewであることは、性能が低いという意味ではありません。ただし、互換性、設定方法、ログやUIの構成を正式版と同じ前提で固定してはいけません。

第一歩：dshのインストールとWeb UI起動を分けて確認する

dshの導入では、コマンドを実行できることと、遠隔から安全に操作できることを分けて考えます。公式の案内に沿った基本手順は次のとおりです。

1. Node.js公式ダウンロードページからNode.jsを用意し、nodeとnpmがシェルから呼び出せることを確認します。
2. 公式リポジトリのREADMEとドキュメントを読み、npxで起動する経路と、ソースコードを取得して構築する経路を比較します。npxの実行仕様はnpm公式のnpxドキュメントで確認できます。
3. 初回起動前に、作業ディレクトリ、待ち受けポート、利用するモデル提供元、認証情報の保管場所を決めます。
4. ローカル環境ではWeb UIが自分の端末から開けるかを確認し、まずコード閲覧だけの操作で接続を試します。
5. 別の端末から使う場合は、Web UIのポートを無条件に公開せず、SSHトンネルまたはアクセス制御された経路を選びます。SSHの転送と認証の仕様はOpenSSHの公式マニュアルを基準にしてください。
6. ソース構築を選ぶ場合は、起動後に同じプラグインが読み込まれるかを確認し、npx経路と挙動が異なる場合はコミット、依存関係、設定ファイルを記録します。

ローカル起動は端末のファイルシステムと権限を直接共有します。クラウド上の開発環境では、接続経路が増えるだけでなく、セッションの保存、再起動、ログ収集、利用者ごとの権限分離まで設計対象になります。短い検証であっても、ポート、ディレクトリ、認証情報を未確認のまま進めないでください。

第二歩：everything-is-a-pluginの構造を実行単位で読む

公式の設計では、モデルだけを交換するのではなく、Agentの周辺機能もプラグインとして組み合わせます。公式のコアサブシステムの説明では、セッションや実行ループなどの中核を確認でき、ツールサブシステムの説明では、ツールを実行部品として捉える考え方を確認できます。

実務では、次のように役割を分けて読むと混乱しにくくなります。

• モデル：推論と応答を担当します。
• ツール：ファイル参照、編集、Shell、検索などの操作を担当します。
• スキル：定型作業や専門的な手順をまとめます。
• セッション：会話、作業状態、実行履歴を保持します。
• サンドボックス：ファイルとコマンドの実行範囲を制限します。
• ストレージ：設定、成果物、ログ、再開に必要な状態を保存します。
• ループ：モデルの判断とツール実行を繰り返します。
• UI：人が状態を確認し、介入する入口になります。

最小の流れは、「モデルが修正方針を作る」→「読み取りツールが対象ファイルを取得する」→「編集ツールが差分を作る」→「サンドボックス内でテストを実行する」→「セッションとログに結果を残す」という構成です。ここで重要なのは、モデルを交換するだけでは権限設計にならない点です。ツール、保存先、実行ループをどの単位で許可するかを決める必要があります。

第三歩：モードと権限を実際の作業に合わせる

Standard、Code、Minimal、Creatorのようなモードは、優劣を競うものではなく、利用する部品の範囲を分けるための入口として扱うべきです。

• Standard：一般的なAgent作業をまとめて試すときに向きます。
• Code：ファイル編集、Shell、テスト実行を含むAI Codingの検証に向きます。
• Minimal：どの部品が必要かを切り分ける初期調査に向きます。
• Creator：独自のプラグインやスキルを作る側の検証に向きます。

名称だけで選ばず、作業単位で権限を決めてください。たとえばバグ修正では、最初に読み取りと検索だけを許可し、次に対象ディレクトリの編集、最後にテストコマンドを追加します。デプロイ、秘密情報の読み取り、ネットワーク接続は、別の承認段階に分けるべきです。

モデル提供元の設定は、公式のProvider設定ガイドを参照します。APIキーをプロジェクトのコミット対象に置かず、ログ、シェル履歴、共有ストレージに残らないことも確認してください。

第四歩：AI Codingワークフローを一つの修正で検証する

AI Codingワークフローの検証では、機能をたくさん並べるより、1件の再現可能なバグを最後まで通す方が判断しやすくなります。次の順番で記録してください。

1. 再現手順と期待結果をセッションの最初に書きます。
2. Agentには最初、関連ファイルの検索と読み取りだけを許可します。
3. 修正案と変更対象を説明させ、想定外のファイルが含まれていないか確認します。
4. 差分を作成し、テスト実行をサンドボックス内に限定します。
5. テスト結果、未解決の警告、変更理由を生成させます。
6. 人が差分とログを確認し、採用した変更だけを通常のレビューへ送ります。

この流れでは、コード読み取り、編集、Shell、検索、計画、子Agent、ワークフロー編成を別々に評価できます。修正案の作成はHarnessに任せやすい一方、秘密情報を含む設定変更、破壊的なコマンド、デプロイ判断は人の承認を残すべきです。

コミュニティで「速い」「便利」と報告されていても、それを公式性能の結論として扱ってはいけません。ここで測るべきなのは、あなたのリポジトリで同じ手順を再現できるか、ログから失敗原因を追えるか、別の担当者が同じ権限で再実行できるかです。

第五歩：Claude CodeとCodexを残した双方向検証にする

Claude CodeやCodexとの比較は、一般的な性能ランキングではなく、あなたの運用で確認できる項目に限定します。次の対照リストを使うと、移行判断が感覚論になりにくくなります。

• エコシステム：既存Agentで利用中のスキルや設定を、そのまま移せるか。
• プロジェクト互換性：リポジトリ、言語、テストコマンド、モノレポ構成を同じ手順で扱えるか。
• 権限モデル：読み取り、編集、Shell、ネットワーク、秘密情報を個別に制限できるか。
• ログ：誰が、どのセッションで、どのツールを実行したかを後から確認できるか。
• 失敗時の復旧：セッションを再開できるか、途中の変更を安全に破棄できるか。
• チーム教育：新しい利用者が権限とプラグインの構成を理解できるか。
• 維持費用：更新確認、依存関係の固定、プラグインの互換性確認を誰が担当するか。

次のチェックをすべて終えるまでは、全面移行しないでください。

• [ ] 同じバグ修正を既存AgentとDeepSeek Harnessで実行した
• [ ] 変更ファイルとテスト結果を人が比較した
• [ ] APIキーや秘密情報がログと作業ディレクトリに残らないことを確認した
• [ ] 読み取り、編集、Shell、ネットワークの権限を分けた
• [ ] セッションを終了・再開し、状態が期待どおり保持されるか確認した
• [ ] プラグイン更新時に互換性を確認する担当者を決めた
• [ ] 失敗した実行を再現できるログの保存場所を決めた
• [ ] 既存Agentへ戻す手順を文書化した

この検証で、DeepSeek Harnessの拡張性がチームの管理能力を上回るなら、研究用途に限定してください。逆に、独自ツールやサンドボックスを組み合わせる価値があり、管理者が更新と監査を担えるなら、対象ワークフローから段階的に広げられます。

遠隔のクラウド開発環境へ置くときの確認点

遠隔環境では、dshを起動できるかよりも、接続が切れた後に何が残るかが重要です。最低限、次の項目を分けて設計してください。

• Web UIをインターネットへ直接公開せず、SSHや認証付きの入口を使う
• ソースコード、セッション、生成物、ログの保存先を分ける
• 再起動しても必要なセッションだけ復元できるようにする
• 利用者ごとに作業ディレクトリと権限を分ける
• プラグインと依存関係の更新履歴を残す
• 使い終わった検証環境を停止・削除できるようにする

クラウド開発環境の選び方を整理するときは、ZavCloudのヘルプセンターで接続や運用に関する案内も確認してください。Macを使った遠隔開発を比較する場合は、Mac miniレンタルの選択肢も、物理環境を自前で維持する場合との違いを考える材料になります。

ただし、ここで紹介しているのはDeepSeek Harnessの公式機能と、遠隔運用で確認すべき設計項目です。ZavCloudの特定ノード、実測速度、料金、保存期間については、今回確認できる実測データがないため断定しません。

よくある導入判断

dshを素早く試す場合

個人の検証用ディレクトリでnpx経路を使い、コード閲覧、単一ファイル編集、テスト実行の順に許可します。まずは失敗しても捨てられるリポジトリを使い、既存プロジェクトの秘密情報や本番認証情報を持ち込まないでください。

ソースから構築する場合

プラグインを開発する人は、公式ソースの構築経路を選び、依存関係とコミットを固定します。起動できたかだけでなく、同じ設定でWeb UI、ツール、セッション、ログが再現できるかを確認します。

チームへ広げる場合

チーム導入では、個人の成功例よりも、権限と復旧手順を先に文書化します。利用者が増える前に、プラグインの承認、更新、ロールバック、ログ確認の責任者を決めてください。

FAQ

上の判断を踏まえると、DeepSeek Harnessは自分で拡張できるAgent基盤として試す価値があります。ただし、既存のClaude CodeやCodexをすぐに外す理由にはなりません。遠隔環境での運用を考えているなら、まず小さな検証環境を用意し、権限、セッション、ログ、復旧を確認してから継続利用を決めるのが適切です。

現在の一般的なクラウド開発環境は、短時間で始められる反面、実行環境の固定、GUIを含む操作、セッションの継続、細かな権限分離で追加設計が必要になることがあります。ローカル端末だけに寄せる方法も、端末の占有、チーム共有、環境差分が問題になりやすいです。複数のMac環境を一時的に比較しながらDeepSeek Harnessを検証したい場合は、ZavCloudのMacレンタルを候補に入れると、購入前に実際の運用経路を確認できます。ただし、長期の固定負荷や物理ポートが必須なら、自社保有のMacや専用環境の方が適しています。

まずは遠隔開発環境の案内と権限設計を確認し、双方向検証で再現性と保守負担が見えた時点で、長期運用へ進めてください。