2026 DeepSeek Harnessスマホ遠隔操作はそのまま使える？

公式のDeepSeek Harnessは、dsh webでWeb UIを起動し、初期状態ではhttp://127.0.0.1:3080で待ち受けます。公式Web UIでは、ワークスペースの選択、モデル設定、セッション実行、ファイル操作、コマンド実行、承認要求を扱えます。(github.com)

一方、Android向けの「DSH Mobile — DeepSeek Harness Remote」は、コミュニティが作った非公式アプリです。作者のREADMEでは、チャット、目標、承認、質問、バックグラウンド処理、通知などをスマートフォンから操作できると説明されています。ただし、その機能と安全性はDeepSeek Harness本体の公式保証ではありません。(github.com)

DeepSeek Harness Mobileという検索語で見つかるアプリやリポジトリは、名称が似ていても同じ実装とは限りません。星の数や投稿の反応ではなく、README、Release、SECURITY、互換性表を個別に確認してください。遠隔Web UIを使う場合も、認証方式とネットワーク境界を先に整理する必要があります。

タスク一覧や通知を表示するだけなら、書き込み操作より安全です。しかし、画面に出る情報は単なる進捗率ではありません。リポジトリ名、ワークスペース名、プロンプト、ツール実行結果、エラー内容、ファイルパスが含まれる可能性があります。

コミュニティ製アプリの説明では、セッション履歴を再接続時に取得し、通知やツールカードを表示する構成が示されています。DSH Mobileのセキュリティ資料では、セッション本文をディスクに保存せず、接続時に再取得するとされていますが、これは同アプリの説明であり、すべてのモバイル実装に共通する仕様ではありません。(github.com)

次の条件を満たさないなら、まず読み取り専用の検証用ワークスペースに戻してください。

• [ ] 実際に表示される範囲を、ダミーリポジトリで確認した
• [ ] プロンプトとツール結果に秘密情報が含まれていない
• [ ] 通知本文にファイル名、パス、外部サービス情報が出ない
• [ ] アプリが保存するホスト情報、履歴、診断情報を確認した
• [ ] AndroidまたはiOS側の通知プレビューを無効化した

注意：画面が読み取り専用に見えても、バックエンドへの接続自体がAPI操作を許可している場合があります。表示範囲と操作権限は別々に確認してください。

2026年8月19日時点で、公式READMEと公式Web UIガイドは、Node.jsからWeb UIを起動する手順を案内しています。公式タグにはdsh-v0.1.0-rc.7があり、リリース日は2026年8月17日です。しかし、同じ公式資料内で原生のiOSアプリやAndroidアプリを公式実行入口として案内している記述は確認できません。(github.com)

したがって、現在の正確な表現は次のとおりです。

• 公式のDeepSeek Harnessにスマホ専用入口がある、とは断定できない
• コミュニティ製のモバイル伴侶アプリはすでに存在する
• そのアプリの対応状況、安全性、認証方式はプロジェクトごとに異なる
• rc.7向けの検証結果を、将来のバージョン保証として扱わない

追加プロンプト、目標変更、モデル切り替えは、単なる表示更新ではありません。実行中のAgentに新しい入力を送り、キュー、計画、利用モデル、ツール呼び出しの順番を変える可能性があります。

特に確認すべきなのは、スマホとデスクトップが本当に同じセッションを見ているかです。コミュニティ実装の互換性資料では、内部Webクライアントが使うJSON-RPCの形を基準にし、特定のHarness版をサポート基準にしています。ただし、その基準は通信プロトコルの完全な固定を意味しません。(github.com)

表示が同期しているからといって、タスクの因果関係まで正しく同期しているとは限りません。重複送信を避けるため、再接続直後はすぐに追加指示を出さず、最後のツール結果とキュー状態を先に確認してください。

公式Web UIガイドは、現在の権限ポリシーで承認が必要な操作を確認する設計を説明しています。承認対象には、ファイル編集、コマンド実行、外部通信などが含まれ得ます。スマホでは表示領域が狭いため、コマンド全文、対象パス、現在のワークスペース、実行理由が見えないまま押せる状態を避けてください。(github.com)

コミュニティ製Android実装は、承認や質問への回答をスマホから行えると説明しています。しかし、同実装のセキュリティ資料も、Harnessにはトークン、Cookie、TLSによる認証がないと明記しています。つまり、スマホ側の承認画面が丁寧でも、接続経路全体の認証が強化されるわけではありません。(github.com)

第二段階：低リスク操作へ進む条件

次の分岐で判断してください。

• 承認画面にコマンド、対象ファイル、作業目的が表示される
  → ダミーリポジトリのファイル作成やテスト実行だけ許可する
• 拒否、タイムアウト、再送信の挙動を確認できる
  → 1回だけ押し、通信再試行後に実行回数をログで確認する
• 同じ承認が重複表示される、または対象が変わる
  → スマホ操作を中止し、デスクトップでセッションを確認する
• 重要なファイル変更、資格情報、外部サービス操作が含まれる
  → 完全なログと差分を確認できる環境へ戻す
• 認証、TLS、監査、利用者の識別を証明できない
  → チーム共有と公衆回線接続を行わない

経験則：承認の失敗で怖いのは、拒否そのものより「タイムアウトしたので、もう一度押した結果、実行が2回走る」ケースです。再送信前にセッションログを確認してください。

接続範囲は、次の3層に分けて考えます。

DSH Mobileの資料では、LAN接続時に認証トークン、Cookie、TLSがなく、同一ネットワーク上の端末が信頼済みホストとしてAPIへ要求を送れると説明されています。さらに、アプリの自動探索は端末のIPv4 /24範囲を調べる仕様です。これは自動探索の説明であり、安全な認証機能ではありません。(github.com)

LAN接続を試す場合も、まず公式のループバック状態と比較してください。コミュニティ実装が必要とするLANパッチや待ち受け変更は、公式の初期設定ではありません。認証なしでインターネットへ公開する手順は、利便性よりも制御面の拡大が先に来るため、ここでは推奨しません。

自分のスマホだけで使う場合でも、Harnessが置かれたMacに接続できれば、セッション閲覧、質問への回答、承認、タスク中断などが可能になります。チームへ共有すると、誰が何を許可したか、誰の権限でコマンドが動いたかを別途管理しなければなりません。

次の項目を証明できない場合、重要なHarnessインスタンスを共有しないでください。

• 利用者ごとの認証と権限分離
• TLSによる通信保護
• 承認、拒否、変更、切断の監査ログ
• 端末紛失時のセッション無効化
• 退職者や外部協力者のアクセス撤回
• モバイルアプリとHarness本体の互換性管理

チームで使うなら、スマホアプリを直接公開するより、まず遠隔Web UIの認証方式、通信経路、監査方法を文書化してください。接続をチームへ広げる前に、安全なリモート作業環境の確認手順で、利用者の識別とアクセス撤回の条件も確認しておくと判断しやすくなります。Macを常時稼働させる構成では、物理端末を自前管理する場合と、管理されたリモート環境を使う場合の運用負担も比較対象になります。

現時点の判断は3段階です。

今後、次の信号が出たら再評価してください。

1. 公式リポジトリにモバイル対応や公式APIが明記される
2. Harness本体にペアリングトークンや利用者認証が追加される
3. TLS、監査、権限撤回の仕様が公式資料で確認できる
4. コミュニティ実装の互換性表がrc.7以降へ更新される
5. Android、iOS、デスクトップ間の再接続テストが公開される

DeepSeek Harnessの更新は速く、公式README自身が互換性を壊す変更の可能性を示しています。コミュニティアプリのrc.7対応は、対応確認が行われた基準であって、次のリリースにも自動的に適用される長期保証ではありません。(github.com)

デスクトップを直接公開する構成は、通信経路、認証、ログ、端末の常時稼働を自分で管理する必要があります。重要なタスクでは、スマホアプリを足すだけではこの問題は解消しません。まずは管理対象を限定した遠隔Web UIや、継続稼働用のMac環境で検証し、モバイル接続はその上に追加する順番が安全です。

まずはサイト内の遠隔Web UIとバックグラウンド作業の確認手順を読み、ダミーのHarnessで通知、再接続、承認拒否を順番に確認してください。実際に常時稼働するMac環境が必要になった場合は、リモートMac環境の選び方を、認証、接続範囲、運用責任の比較材料として確認できます。そこで認証と監査の境界を説明できないなら、スマホから本番タスクを操作する段階ではありません。