DeepSeek Harness デスクトップアプリ：インストーラーが実際にマシンに導入するもの

DeepSeek Harness デスクトップアプリは、以下で得られるのと同じWebインターフェースを包んだElectronシェルです：npx @deepseek-ai/dsh web。また、現在バージョン0.2.1-rc.2のハーネス向けに、プラットフォーム別の3つのインストーラーとして提供されます。その説明は軽視しているように聞こえますが、そういう意図ではありません。動作するインターフェースをデスクトップコンテナで包むだけなら週末で済む作業です。しかし、独自のランタイムディレクトリを管理し、ウィンドウを閉じてもタスクを存続させ、安定版リリースのないチャネルで自己更新し、それらすべての操作をまたいでセッションを保持するコンテナで包むことは、数か月かかる部分であり、まさに読む価値のある部分です。DeepSeek-V4.1-Flash を、ターミナルではなくウィンドウ内で動くハーネス経由で実行したいなら、これがそのビルドです。そして、興味深い問いはすべて、ウィンドウの周囲で何が起きるかに関するものです。

詳細に入る前に、2つ言っておく必要がある。第一に、この記事は「デスクトップアプリは存在しない」という以前の案内を置き換えるものだ。その案内は2026年8月に書かれた時点では正しかったが、今は誤っている。第二に、これはパブリックプレビューであり、DeepSeek自身のサイトでもそう表示されている。そして、その呼び名が示すとおり、パッケージングには粗削りな部分がある。インストーラーは動作する。だがその周辺の配布は、想像するより薄い。

デスクトップビルドが実際に何なのか

デスクトップアプリケーションは薄いElectronレイヤーであり、その役割はHostプロセスを起動し、ウィンドウをそのプロセスに向けることです。ウィンドウは独自のチャットインターフェースをレイアウトするわけではありません。アプリ内にバンドルされたパッケージ済みのWebエントリをdsh-app://app/から読み込み、表示される更新ダイアログは2つ目のバンドル済みオリジンであるdsh-app://shell/から提供されます。子NodeプロセスはElectronのRunAsNodeモードで起動されて共有プロファイルランナーを開始し、シェルはHTTPを認証済みWeb Hostへ転送する際にtransfer-encoding、connection、keep-aliveヘッダーを削除します。プラグインバンドルのレスポンスにはno-storeが付与されます。これは小さな詳細ですが、目に見える結果を伴います。プラグインを変更すれば、次回のリロードでその変更が反映されます。

URLがdsh-app://であり、localhostではないため、覚えておくべき固定ポートも、回避すべきポート衝突もありません。デスクトップ版HostはデフォルトでOSが割り当てたポートで待ち受けます。特定のポートが必要な場合はwebserver.config.portのオーバーライドで設定できますが、デフォルトは意図的に定数にはされておらず、Hostは127.0.0.1にバインドします。これは、古い手順に従ってきた場合に重要です。8月のインストールガイドで出回っていた19387という番号はデスクトップ版のポートではなく、それをポートとして扱うと、存在しないサービスを探し回ることになります。

バージョン固定は、一見したよりも厳格です。Electron と @deepseek-ai/dsh は常にまったく同じバージョンを伴います — 範囲でも、互換性のあるメジャーバージョンでもありません — そのためハーネスのアップグレードはデスクトップリリースであり、新しい dsh と古いウィンドウの組み合わせはサポートされていません。Electron プロセスはプロセス存続期間中の単一インスタンスロックを取得し、次を排他的に所有します: $DSH_HOME/profiles/desktop。この排他性は実際のもので、CLI はそのプロファイルを起動できず、また npm でインストールされた dsh はそれを変更できません。2 つのインストールが共有するのは、あなたにとって重要な状態 — セッション、設定、認証情報、ワークスペース、ストレージで、すべて $DSH_HOME の下にあります。共有しないのは、実行可能パッケージ、プラグインの有効化、ロックファイル、あるいは node_modules であり、そのためデスクトッププロファイルにプラグインをインストールすることは、CLI プロファイルにインストールすることと同じ操作ではありません。

3つのインストーラー、1つの更新チャネル、安定版リリースなし

インストーラーは3つ存在し、そのすべてが応答します。Windows 64ビット実行ファイルは289,385,456バイトで、HTTP 200で配信されています。Appleシリコン用ディスクイメージは264,990,950バイトで、こちらも200です。Intel Mac用ディスクイメージは289,480,824バイトで、こちらも200です。3つとも最終更新日は2026年10月17日です。ダウンロードページからリンクされているのはそのうち2つだけです。Intelビルドは公開されており、到達可能ですが、リンクがどこにも貼られていないのはdeepseek.com/en/harness/ です — Intel Macを使っていてページに従ったなら、自分向けのビルドはないと妥当に結論づけるでしょう。

Intel版も1バージョン遅れている。その更新フィードには0.2.1-rc.1が記載されており、WindowsとApple-siliconのフィードはいずれも0.2.1-rc.2を記載している。リリース候補1つ分は機能面での大きな差ではないが、どのターゲットが最初にビルドされ、どれが最後に検証されるかを示す確かなシグナルであり、作業セッションを特定のプラットフォームに移す前にまさに知っておきたいことだ。

アップデートチャネルは、配布の話が薄弱になる箇所だ。フィードはターゲットごとに、同じホスト上の/dsh-desk/feeds/<target>/ の下にある。Windows x64 はnightly.yml を解決し、macOS の両ターゲットはnightly-mac.yml を解決する。この3つのいずれかにlatest.yml またはlatest-mac.yml を要求すると 404 が返る——安定版チャネルもベータチャネルも存在せず、存在する唯一のチャネルから抜ける方法もない。DeepSeek 自身の公開ノートは、この状況を否定するどころか裏付けている。すべてのリリースが nightly フィードを公開し、同じ成果物を指すlatest フィードを公開するのは安定版リリースのみだ。この文脈における「Nightly」はビルドの頻度ではなくチャネル名であり、Windows と Apple シリコンのフィードはどちらも同じ 0.2.1-rc.2 ビルド（10月17日付）を配信している。Windows パッケージのタイムスタンプは 09:22 UTC、Apple シリコンパッケージは 09:57 UTC だ。つまり、自動アップデータの仕組み、ジッター付きポーリング、1時間を上限とするバックオフは手に入るが、プレビューチャネルが現在保持しているもの以外を要求する方法はない。

GitHubは別の角度から同じ点を指摘している。deepseek-ai/deepseek-harnessリポジトリは——2026年10月21日に確認した時点で256,559個のスターと30,921個のフォークを集めていた——同じ日付に31件のリリースがあり、そのすべてがプレリリースとしてフラグ付けされ、そのすべてにバイナリ資産が一切添付されていなかった。Releasesページにダウンロードできるものは何もない。ビルドが必要なら、download.deepseek.comまたはnpmから取得する。そこでは@deepseek-ai/dshのlatestが現在0.2.1-rc.2に解決される。このリポジトリは変更履歴の信頼できる情報源であり、成果物にとっては行き止まりである。これははっきり述べる価値があるほど異例だ。なぜなら、31件のリリースを見たときの直感では、そのうちのどれかにインストーラーがあると期待してしまうからだ。

インストーラーが書き込むものと、触れることを拒むもの

Windows インストーラーは MSI のラッパーではなくネイティブな NSIS パッケージで、そのとおりに動作します。ライト、ダーク、自動のパレットを用意しており、インストール時に選択できます: /THEME=light、/THEME=dark、/THEME=auto のいずれか。保存先ディレクトリは編集可能で、インストールスコープは現在のユーザーに限定されます。ドライブのルートは保存先として拒否され、空でない保存先は既に登録済みのインストールである場合にのみ受け入れられます。これは、無関係なフォルダーを上書きしないというインストーラーの挙動です。更新時、サイレント実行の経路では実行中のアプリケーションが終了するまで最大 10 秒待機し、それでも実行中であれば終了コード 2 で停止します。これはインストールの破損ではなく正直な失敗であり、アプリを先に終了しないスクリプトによる展開では必ず表面化します。

このアンインストーラーは、ほとんどのアンインストーラーが間違える線引きを正しく行います。削除するのは Electron の userData ディレクトリ、%APPDATA% 配下の製品ディレクトリ、そして %LOCALAPPDATA% 配下のアップデーターキャッシュです。ハーネスホーム —— ~/.dsh、あるいは DSH_HOME が指す場所 —— には一切触れません。ここにはセッション、設定、認証情報、プラグインが保存されています。--updated または /KEEP_APP_DATA を渡した場合も、Electron のデータは保持されます。つまり、アンインストールして再インストールすることは、作業内容を失わずに壊れたウィンドウを修正するためのサポート対象の方法であり、これは偶然ではなく意図的な設計判断です。

同梱ランタイムは、サイズが大きくアプリのディレクトリ外に存在するため、知っておく価値があります。numpy、pandas、python-docx、python-pptx、openpyxl、Pillow、lxml、XlsxWriterを含むPythonに、Nodeとpnpmを加えたものは、次の場所にインストールされます：$DSH_HOME/dsh-runtimes/dsh-primary-runtime（通常は~/.dsh/...、両方のプラットフォームで）— ワークスペースが初めて必要だと宣言したときに。そのため、1週間使用した後のディスク使用量はインストール直後のディスク使用量とは異なり、また、アンインストールで$DSH_HOMEを保持した場合も、数百メガバイトのランタイムが保持されます。

設定は起動時に一度だけdesktop/settings.jsonから読み込まれます。これはElectronのuserDataディレクトリ内にあり、Windowsでは%APPDATA%\@deepseek-ai\dsh-desktop\desktop\settings.json、macOSでは~/Library/Application Support/@deepseek-ai/dsh-desktop/desktop/settings.jsonを指します。DSH_HOMEはこのファイルの場所を変更しません — これは特筆に値する点です。なぜなら、これは他のすべてが従う変数に従わない唯一の設定項目だからです。このファイル内の更新設定はミリ秒単位です：intervalMsのデフォルトは600,000で、maxBackoffMsのデフォルトは3,600,000であり、少なくともintervalMs以上である必要があります。ジッターはデフォルト0.2で、0から1の範囲にクランプされ、1秒を下限としつつ、バックオフの上限を超えることはありません。接続ごとの非アクティビティ期限である60,000ミリ秒が更新のHTTP通信に適用されますが、アクティブなダウンロードには総所要時間の期限はありません — 遅い回線でもダウンロードの途中で打ち切られることはありません。

ウィンドウを閉じてもアプリケーションは終了しません

どちらのプラットフォームでも、ウィンドウを閉じると非表示になります。macOS ではCommand-Wです。Windows では閉じるボタン、Alt-F4、またはタスクバーの「閉じる」です。Windows は初回の非表示前に確認を求め、Electron の userData ディレクトリにbackground-close-confirmedフラグを書き込むため、毎回ではなく 1 回だけ確認します。Windows は実行中ずっとトレイアイコンも保持します。macOS にはメニューバーアイコンが一切ないため、非表示状態はそこで本当に見えなくなります。アプリは実行中で、タスクも実行中なのに、画面には何も表示されず、dsh://openまたはプラットフォームに応じてトレイで再度開くまで、その状態が続きます。

非表示にしても残るものが、役に立つ部分です。実行中のタスクは動き続け、次にウィンドウが表示されたときには、同じセッション、同じ下書き、同じスクロール位置で同じドキュメントが表示されます。これは、閉じてから開き直すブラウザタブとは異なる動作であり、長時間実行されるエージェントタスクを扱う作業ならデスクトップビルドをわざわざ使う価値がある理由でもあります。ウィンドウを閉じて、タスクを完了させておけるのですから。

終了は、独自のロジックを持つ別個の操作です。終了する前に、シェルはHostを検査し、サブエージェントや承認待ちのエージェントを含む実行中のエージェント、キューに入ったメッセージ、実行中または停止中のジョブ、そして待機状態にあるスケジュール済みリマインダーがあるかどうかを確認します。それらが一つも存在しなければ、確認なしで静かに終了します。いずれかが存在する場合は、DeepSeek Harnessを終了しますか？というタイトルのネイティブ確認ダイアログが表示され、検出された内容に応じて三つの説明のいずれかが示されます。タスクが中断される、スケジュールされたタスクが実行されない、またはその両方です。一度もreadyに到達しなかったHostはタスクを開始できていないため、その状態での終了は確認なしで進みます。「閉じる」と「終了」の区別がこの設計の要点であり、一方のプラットフォームだけが常駐アイコンを表示するにもかかわらず、両方のプラットフォームで維持されています。

dshコマンドと、そこで重要になる順序

インストーラーは dsh をお使いの PATH に追加できます。これにより、デスクトップアプリが使用するのと同じハーネスホームに対して CLI を実行できるようになります。この設定項目は dsh コマンドを管理… で、メニューの アップデートを確認… のすぐ下にあり、インストール、修復、削除の 3 つのアクションがあります。macOS では /usr/local/bin/dsh にランチャーを書き込み、必要に応じて管理者の承認を求めます。Windows では、現在のユーザーの PATH。

順序に関する2つのルールは見落としやすく、後から気づくと厄介です。1つ目：デスクトップアプリケーションをアンインストールする前に Remove を実行してください。アンインストーラーは dsh の登録を削除しないためです。先にアンインストールすると、存在しないバイナリを指す PATH エントリが残ってしまいます。2つ目：アプリケーションを別の場所に移動した場合は、登録がアプリに付いてくると想定せず、macOS では Repair を、Windows では新しい場所から Install を使用してください。

デスクトッププロファイルのプラグイン管理には、独自の注意点があります。Electron が実行中は$DSH_HOME/profiles/desktopを排他的に所有しているため、そのプロファイルへのインストールはアプリを開いたままでは行えません。サポートされている手順は、デスクトップアプリを一度起動して終了し、その後コマンドラインからdsh plugin --profile desktop add <package>を実行することです。パッケージはデスクトッププロファイルに配置され、次にウィンドウを開いたときに有効になります。

パッケージがすでに伝えていることは、まだ完成していない。

READMEの「既知の制限」セクションは異例なほど率直で、その中でも2つの項目は真っ先にあなたに影響を与えるものです。

• アカウントのサインインは接続されていません。 サインインボタンは無効になっています。代わりに、初回実行時には API キー入力フォーム付きの 600×700 のウェルカムウィンドウが開きます。[保存して続行] を選ぶとキーが開発用資格情報ストアに書き込まれ、[後で設定] を選ぶとキーを保存せずに実際のワークスペースが開きます。表示される箇所で [サインイン] を押すと、設定済みのプラットフォームページがシステムブラウザで開き、ホストが PKCE 交換と一時的なループバックコールバックを担います。基盤は存在しますが、アカウントの紐付けはありません。実際には、キーを用意しておくことを想定してください。

• リリース署名と公証は、本番リリース環境を必要とするものとして記載されています。 これはREADMEが慎重に書かれているということであり、また、文章よりも計測の方が有用な箇所でもあります。公開されているWindows実行ファイルには、拡張検証チェーンを備えた有効なAuthenticode署名が付与されています。そのチェーンはGlobalSign Root CA–R3から、GlobalSign Code Signing Root R45、GlobalSign GCC R45 EV CodeSigning CA 2020を経て、Hangzhou DeepSeek Artificial Intelligence Co., Ltd.に発行されたリーフ証明書に至るもので、管轄はCN / Zhejiang / Hangzhouと記載され、事業者区分は民間組織となっています。その署名のRFC-3161タイムスタンプは2026-10-17T09:22:04Zを示しており、これはWindows更新フィードのリリース日時と1分以内で一致します。また、ダウンロードしたファイルのSHA-512ダイジェストは、そのフィードで公開されているハッシュとバイト単位で一致します。したがってWindowsでは、プロセスが完全に本番化されていないというREADMEの記述にかかわらず、現時点でバイナリは署名され、タイムスタンプが付与され、ハッシュも一致しています。macOS側は別問題であり、そこでの公証は検証していません。Windowsの結果をそのまま当てはめて解釈しないでください。

クラッシュレポートと、知っておく価値のある1つの詳細

クラッシュレポートはcrash-<UTC time>-<source>.log というファイル名で、~/Library/Logs/DeepSeek Harness（macOS の場合）または Windows の Electron userData パス配下の logs ディレクトリに書き出され、直近 10 件のみが保持されます。この保持件数は少なすぎて無視できません。問題が繰り返し発生しているのに数日間確認しないでいると、最初の失敗を説明するはずだったログは消えてしまいます。断続的に発生する問題をデバッグしている場合は、ディレクトリごとコピーしておいてください。

破損した設定の復旧手順も同じくらい具体的です。シェルはcordis.patch.ymlをcordis.patch.yml.bak-<timestamp>に、解析せずに名前変更します。そのためファイルは修復されるのではなく保持され、アプリはデフォルト設定で起動します。このファイルを手動で編集していた場合、編集内容は .bak に残っており、引き続き読み取ることができます。

これによって、以前の「デスクトップアプリはない」という助言がどういう位置づけになるか

2026年8月に、harnessにはデスクトップアプリケーションがなく、Windowsユーザーはターミナルビルドを実行すべきだというガイダンスを公開しました。これは当時は正確でしたが、今では古くなっています。ターミナルビルドは今も動作しており、サーバー、コンテナ、スクリプト化された用途には今も適切な選択です。変わったのは、デスクトップビルドがおもちゃのようなラッパーではないということです。独自のプロファイルを持ち、ウィンドウを閉じてもタスクを維持し、自己更新し、CLIと役立つ形で状態を共有します。以前の記事で存在しないと書かれていたためにデスクトップビルドを先延ばしにしていたなら、その理由はもうありません。

インストール手順そのものは、当社のインストールウォークスルーで扱っており、意図的にここでは繰り返しません。そのウォークスルーでは伝えられないのは、3つのインストーラーのうちどれがダウンロードページにリンクされていないか、どのターゲットが1リリース遅れているか、オプトインできる安定版更新チャネルが存在しないこと、そしてREADMEでは署名は将来のリリースに属するとされているのにWindowsバイナリが署名されていることです。これらの事実が、デスクトップビルドがインストールすべき適切なものかどうかを決め、このページが別に存在する理由です。

何もインストールしたくない場合は

1つのモデルにたどり着くためにハーネスをインストールするのは、わずかな作業のわりに表面積が大きすぎます。しかもデスクトップアプリはプレビュー版で、更新チャネルは1つだけ、誰もリンクしていないIntelビルドもあります。本当に必要なのがDeepSeek-V4.1-Flash — ハーネスがデフォルトで使うモデルであり、0.2.1-rc.2のノートでサポートが追加されたのと同じモデル — なら、APIエンドポイントを使えばそれが実現できます。インストーラーも、プロファイルディレクトリも、起動中だと覚えておかなければならないトレイアイコンも不要です。

行うべき比較は、抽象論としてのデスクトップアプリ対APIではない。問題は、その作業が、ウィンドウを閉じてもワークスペースを開いたままにし、あなたのマシン上でスクリプトを実行し、セッションを何時間も維持できるエージェントを必要としているのか——その場合、前述のパッケージング上の問題は我慢する価値があり、その動作を得る唯一の方法はデスクトップ版だ——それとも、その作業が、すでにどこか別の場所で提供されているモデルへの一連のリクエストなのか、ということだ。後者の場合、モデルディレクトリがより短い道であり、この記事の中にそれを変えるものは何もない。