DeepSeek Harness リモート Web UIは、個人または固定された少人数ならループバック待受けを維持し、SSH トンネルで接続してください。チーム向けの公開入口は、独立した利用者認証、TLS、送信元制限、監査、権限撤回まで用意できる場合に限って選びます。trustedHostsだけではログイン認証になりません。

今週の判断

  • 個人利用：SSH トンネルを選びます。
  • 固定メンバーの少人数利用：まずSSH トンネル。接続管理が増えたら限定公開を検討します。
  • 正式なチーム運用：認証付きHTTPS入口を構築できる場合だけ、非ループバック待受けへ進みます。

この記事は、別の端末からWeb UIへ接続したい個人開発者、複数人の入口を設計するプラットフォームエンジニア、反復可能な安全確認を求めるセキュリティ担当者向けです。単に「画面が開くか」ではなく、到達性、Host信頼、利用者認証、Harness内部権限を分けて判断します。

01

入口を決める基準はアクセス人数と責任範囲です

公式READMEでは、npx @deepseek-ai/dsh webでWeb UIを起動でき、標準ではhttp://127.0.0.1:3080で提供されます。確認時点は2026年8月19日です。公式リポジトリは現在もDeveloper Previewで、互換性を壊す変更があり得ると説明しています。(github.com)

この初期状態は、同じMac上で使うための設定です。別端末からアクセスするには、次のどちらかへ変わります。

選択肢 待受け 向いている利用者 強み 主な弱点
SSH トンネル ループバックを維持 個人、固定された少人数 公開ポートを増やさず暗号化経路を作れる 利用者ごとの接続管理や監査が弱い
制限付き公開入口 非ループバックまたはプロキシ 小規模チーム URLを共有しやすく、入口側で認証を統合しやすい TLS、認証、ログ、撤回を継続管理する必要がある
チーム向けHTTPS入口 アプリの前段に認証付きプロキシ 正式なチーム、運用担当あり 利用者単位の制御と監査を設計しやすい プロキシ障害、証明書更新、ヘッダー処理が増える

判断を急ぐと、見えにくいコストが発生します。公開ポートを開けると、アクセス元の識別、認証失敗の確認、メンバー削除、証明書更新、バージョンアップ後の再検証が必要になります。個人が一時的に遠隔 Macへ入るだけなら、この管理負担は目的に対して大きすぎます。

注意：回線を127.0.0.1から非ループバックへ変えても、それは「到達できる範囲」が変わっただけです。利用者の本人確認や操作権限の設定が完了したことを意味しません。

02

ネットワーク到達性とHost信頼を分離して確認します

SSH トンネルでは、DeepSeek Harnessをループバックで待ち受けさせたまま、SSH接続を通して手元の端末へポートを転送します。リモート側のWeb UIを外部ネットワークへ直接公開しないため、ファイアウォールや公開DNSの設定を増やさずに済みます。

ただし、SSH トンネルはチームガバナンスの万能策ではありません。誰が接続したかを利用者単位で記録したい場合、SSHアカウントの共有は避ける必要があります。鍵の撤回、接続時刻、作業領域の権限を別々に管理してください。

非ループバック待受けを選ぶ場合は、少なくとも次を確認します。

  • 実際にどのアドレスとポートで待ち受けているか。
  • 外部端末から到達できる送信元がどこか。
  • ファイアウォールで許可する範囲を限定しているか。
  • 不要になったとき、公開入口を一手順で閉じられるか。
  • 想定外のHostヘッダーを拒否できるか。

trustedHostsは、このうち最後のHost authorityの受け入れ範囲に関係する設定です。許可したHost名からのリクエストに見えることと、利用者が正規メンバーであることは別問題です。公式Web UIガイドも、モデル設定、ワークスペース選択、操作承認といったアプリ内の流れを説明していますが、trustedHostsを利用者ログイン機構として説明していません。(github.com)

そのため、trustedHostsを設定した後も、利用者認証、セッション管理、権限撤回を別途用意します。Hostチェックに通過しただけで、Web UIの操作を許可する設計は不十分です。

03

SSHの暗号化経路とHTTPS入口では責任の置き場所が違います

SSH トンネルでは、SSHクライアントと接続先ホストの間の暗号化、公開鍵の検証、利用者アカウントの管理が中心になります。OpenSSHの公式マニュアルでも、ローカルポート転送はSSH接続を介して指定先へ接続する機能として定義されています。(github.com)

一方、HTTPS入口では、次の責任が入口側へ移ります。

  • TLS証明書の発行、更新、失効。
  • 利用者認証とセッション期限。
  • 送信元IPまたはネットワーク範囲の制限。
  • X-Forwarded-*などのプロキシヘッダーの扱い。
  • APIキーや環境変数をログ、画面、エラーに出さない設計。
  • 認証失敗、権限変更、管理操作を追跡できる記録。

DeepSeek HarnessのWeb UIガイドでは、APIキーはSettingsのModelsから入力して保存する流れが示されています。別の端末へキーをコピーすることや、URLへキーを含めることを前提にした説明ではありません。APIキーをシェル履歴、共有チャット、プロキシのアクセスログへ残さない運用にしてください。(github.com)

ここで、遠隔 Macを使う場合の設計を分けます。自分のMacBookからVpsMeshの管理する遠隔 Macへ一時接続するだけなら、SSH トンネルと個別アカウントの組み合わせが管理しやすいです。複数人が同じWeb UIで承認操作や作業領域の変更を行うなら、共有SSH鍵ではなく、利用者ごとの認証と撤回記録が必要になります。

04

監査と保守では公開入口の弱点が表面化します

公開入口の便利さは、ブラウザーでURLを開くだけで接続できる点です。しかし、運用開始後に確認すべき項目が増えます。

  • 失敗したログインを利用者別、送信元別に識別できるか。
  • メンバーを削除した直後に既存セッションを失効できるか。
  • プロキシ設定を変更した責任者と日時を追跡できるか。
  • DeepSeek Harnessの更新後に待受けとHost拒否を再確認したか。
  • TLS証明書の更新失敗を検知できるか。
  • Web UI停止後に外部からポートが見えなくなるか。

公式リポジトリの最新タグとして、2026年8月17日付のdsh-v0.1.0-rc.7が確認できます。Developer Previewの段階では、更新による設定名、起動動作、Web UIの挙動変化を前提に、固定版での検証と変更記録を残すべきです。(github.com)

反対に、個人の一時利用であれば、公開入口を常時保守する理由は薄くなります。SSH接続を停止すれば経路を閉じられ、Harness自体はループバックで動き続けます。作業終了後にトンネルを切断し、必要ならリモートプロセスも停止する運用なら、公開DNS、証明書、認証プロキシを持たずに済みます。

05

5段階の端末間受け入れ試験で最終判断します

構成を決める前に、次の順番で確認してください。コマンドや起動パラメーターは、2026年8月19日時点の公式READMEとリリース内容を再確認してから実行します。Developer Previewのため、古い記事の引数をそのまま使わないでください。

  1. 待受け状態を確認する
    リモートMac上で、プロセスが127.0.0.1:3080を待ち受けているか、または意図した非ループバックアドレスを使っているかを確認します。設定ファイルの記述だけでなく、OSのソケット一覧を確認します。

  2. SSH経路を単独で試す
    個人利用では、手元の端末からSSH トンネルを作り、ローカル側の転送先を開きます。トンネルを切った後、外部端末から同じポートへ接続できないことも確認します。

  3. Host拒否を確認する
    正規のHostと、想定外のHostを使い分けます。trustedHostsの設定が不適切なHostを拒否するかを確認します。ただし、この試験は利用者認証の試験ではありません。

  4. 認証と権限を確認する
    正規ユーザー、無効化したユーザー、期限切れセッションで動作を分けます。ワークスペースの選択、ファイル変更、コマンド実行、承認要求が、想定した権限範囲に収まるかを確認します。公式ガイドでも、Web UIはワークスペース追加後にセッションを開始し、権限ポリシーに応じて操作承認を求める流れです。(github.com)

  5. 断線と復旧を試す
    SSH接続、プロキシ、Web UIプロセスをそれぞれ止めます。再接続後に、作業状態、未完了タスク、認証状態、入口ログが期待どおりになるかを記録します。復旧後に古いセッションが無条件で残るなら、公開入口の採用を止めて設計を見直します。

判定は明確です。個人アクセスで外部端末からの接続と切断が確認できたら、SSH トンネルを継続します。固定チームで利用者認証、TLS、許可元制限、監査、撤回をすべて確認できたら、受控えた公開入口へ進みます。どれか一つでも未確認なら、ループバック待受けへ戻します。

経験則：0.0.0.0で待ち受けられたことは、公開運用の合格証ではありません。到達性、Host信頼、認証、内部権限の4層を個別に記録できない場合は、入口を広げない方が安全です。

06

結論表の後に決めるべき運用案

DeepSeek Harness リモート Web UIを自分だけが断続的に使うなら、SSH トンネルが適切です。接続経路を必要な時間だけ作れ、ループバック待受け、APIキーの保管、公開ポートの停止を分けて管理できます。

チーム向けの公開入口は、共有URLだけでは完成しません。認証基盤がない、TLS更新担当がいない、アクセスログを見ない、メンバー撤回を即時に行えないという状態なら、画面が開いても長期運用には向きません。

現在のローカルMacや簡易的な公開サーバーで運用すると、電源状態、スリープ、回線変動、公開ポートの保守を自分で抱えることになります。長時間稼働する遠隔 Macを安定した作業環境として使いたい場合は、まずDeepSeek HarnessのクラウドMac引き渡し確認やMacレンタルのプライバシーポリシーを確認し、臨時の算力環境や検証用入口だけをVpsMeshで借りる構成が現実的です。長期の固定負荷、物理インターフェース必須、社内認証基盤との密結合がある場合は、自前Macの方が適する場合もあります。

07

よくある判断を短く確認します

FAQでは、公開可否、trustedHostsの役割、SSH トンネルとリバースプロキシの使い分け、非ループバック待受け後の確認範囲を整理しています。どの回答でも、ページが表示できることと、認証・権限・監査が成立していることを混同しないでください。