接続してWeb UIは開くのに、実際のタスク実行や再起動後の復元を確認していない。

最短の解決策は、環境、権限、ワークスペース、モデル、ツール、永続化、交接資料の7指標を固定タスクで検証し、1項目でも再現できなければ保留にすることです。DeepSeek Harness クラウドMac受入検査では、ページが表示されたかどうかを合否の根拠にしません。

技術購買担当者は、抽象的な要望を署名できる納品項目に変換できます。
開発者は、デモ起動ではなく実タスクが完了するか確認できます。
運用チームは、再起動、ログ、権限、障害時の切り戻し責任を明確にできます。

最終更新：2026年8月18日。DeepSeek Harnessの公式リポジトリ、Web UIガイド、アーキテクチャ資料を基準に確認しています。開発者プレビュー版であり、互換性を壊す変更があり得るため、納品時点の実環境で再検証してください。(公式リポジトリのREADME、公式Web UIガイド)

まず受入検査の基準線を作る

最初に、次の情報を1枚の検査票へ記録します。構成名や商品名から推測してはいけません。ターミナルで実行した結果、DeepSeek Harnessの設定画面、引き渡し担当者から受け取った資料のいずれかを証拠にします。

指標 検査する情報 合格の証拠
環境身份 macOS、CPUアーキテクチャ、Node.js、導入元、起動方法 コマンド出力と起動履歴
Harness構成 バージョン、プロファイル、プラグイン、パッチ 設定ダンプと構成ファイル
接続 SSH、画面共有、Web UIの接続経路 接続手順と利用アカウント
モデル モデル名、API接続先、認証方法 最小応答の成功記録
状態 セッション、ワークスペース、モデル設定 再起動前後の比較表

公式READMEでは、npm経由の起動に npx @deepseek-ai/dsh web を使い、Web UIは標準で 127.0.0.1:3080 に提供されると説明されています。ソースから起動する場合は、リポジトリ取得、依存関係の導入、ビルドを経由します。したがって、ポート番号や導入方式は「クラウドMacだからそうなっている」と考えず、実際の起動ログで確認します。(公式READMEの起動手順)

DeepSeek Harnessは開発者プレビューです。公式資料にも互換性を壊す変更があり得ると明記されています。納品時に取得したバージョン、コミット、ロックファイルを保存しないと、数週間後に同じ環境を再現できなくなります。

接続経路と管理権限を分離する

次に、誰がMacへ入り、誰がAgentを操作できるかを確認します。ここでは、Macのログイン権限とDeepSeek Harness内部の承認ポリシーを別々に扱います。

検査手順は次の通りです。

  1. 引き渡された一般ユーザーでSSHまたは画面共有に接続します。
  2. 管理者権限が必要な操作を1つ実行し、承認されるか拒否されるか記録します。
  3. Web UIへ接続できるネットワーク範囲を確認します。
  4. 管理者用アカウントと作業用アカウントを分けます。
  5. 引き渡し後にAPIキー、SSH鍵、管理者パスワードを交換します。
  6. 未許可のアカウントでWeb UI、作業ディレクトリ、ログへ到達できないことを確認します。

DeepSeek Harnessでは、モデル、ツール、セッションログ、サンドボックス、承認ポリシーなどが構成要素として組み合わされます。Mac側でログインできても、Agentのコマンド承認が適切とは限りません。逆に、Web UIの承認画面があっても、Macの管理者権限が広すぎれば別の経路から制御されます。(公式アーキテクチャ資料)

注意：APIキーを画面共有、チャット、引き継ぎ用のMarkdownへ貼り付けたままにしないでください。受入検査では接続成功だけを確認し、署名後に受領者が新しい資格情報へ交換する手順まで残します。

ワークスペースの境界を実ファイルで確かめる

DeepSeek HarnessのWeb UIガイドでは、起動ディレクトリが初期ファイルシステム位置になり、新しいWeb UIではワークスペースを選択するまでセッション作成ができないと説明されています。ここで「作業ディレクトリが設定済み」と表示されても、ファイル境界まで確認できたことにはなりません。(公式Web UIガイドのワークスペース説明)

検証用リポジトリには、次の3種類のファイルを置きます。

  • Agentが読んでよい説明ファイル。
  • Agentが変更してよいテストファイル。
  • 読み取りも変更も許可しない境界確認用ファイル。

そのうえで、固定した指示を送ります。読み取り、1ファイルの編集、禁止パスの参照、作業ディレクトリ外のコマンドを順番に実行します。各操作について、成功、拒否、承認要求、エラーのどれだったかを保存します。

テスト 確認動作 合格条件 証拠産物
読み取り 許可ファイルを要約 内容が取得できる 入力と回答
変更 テストファイルを1か所編集 差分が想定通り git diff
只読 変更禁止ファイルを編集 拒否または承認要求 UI記録、ログ
越境 作業範囲外を参照 設定した方針通りに拒否 エラー記録
書き戻し 結果ファイルを生成 指定場所だけに保存 ファイル一覧

最も危険なのは、デモ用リポジトリだけで「動いた」と判断することです。実際のプロジェクトには、環境変数、秘密情報、親ディレクトリ、Gitの別作業ツリーなどがあります。Agentが見える範囲をコマンド結果で記録し、必要なら受入専用の隔離リポジトリを使います。

モデルとツールを固定タスクで通す

モデル設定画面にモデル名が表示されても、呼び出しが成立するとは限りません。公式ガイドでは、SettingsのModelsからAPIキーを登録し、保存後に再起動せずモデル経路を利用できるとされています。受入時は画面表示ではなく、最小応答を実行してください。(モデル設定ガイドへの案内)

固定ベンチマークは、次の順番にすると切り分けやすくなります。

  1. 短い質問を送り、モデルの最小応答を確認します。
  2. 検証リポジトリのファイル要約を依頼します。
  3. テストファイルの1行変更を依頼します。
  4. シェルまたはファイル操作ツールを呼び出します。
  5. コマンド承認が必要な操作を試します。
  6. 結果ファイルとセッションログを確認します。
  7. APIエラー、タイムアウト、権限拒否、空応答を失敗信号として保存します。

DeepSeek Harnessの公式アーキテクチャでは、モデルアダプター、ツールレジストリ、セッションログ、Agentループなどもプラグインとして扱われます。つまり、同じ「Web UIが表示される環境」でも、プロファイルやパッチが違えば利用できるツールと承認動作が変わります。実際に起動した構成は、設定ダンプで固定してください。

再起動後の状態を比較する

継続稼働を前提にするなら、再起動検査を省略しないでください。まず非機密のテスト会話、選択中のワークスペース、モデル設定、プラグイン構成を記録します。その後、運用担当者の立ち会いで受動的な再起動を行い、同じ項目を再確認します。

比較項目は次の通りです。

  • 既存セッションが一覧に残っているか。
  • 過去の入力、回答、ツール結果を再表示できるか。
  • ワークスペース選択が維持されているか。
  • モデル名と接続先が保持されているか。
  • プラグインと承認ポリシーが同じか。
  • 再起動後に必要な手動操作は何か。

公式資料では、セッションログは追記型のイベント記録として扱われ、再開、分岐、検索、再生が同じイベントストリームから派生すると説明されています。ただし、クラウドMac側のディスク保持、起動方式、バックアップ範囲まで公式資料から推測することはできません。ここは提供環境で実測します。(セッションログの説明)

受入検査に関するFAQ

クラウドMacで画面が開けば、納品完了でしょうか。
画面表示は接続確認にすぎません。モデル応答、ファイル編集、コマンド承認、ログ保存、再起動後の復元が同じ検証条件で再現できることが必要です。どれか1つでも未確認なら、正式運用ではなく条件付き受入にします。

交付時のバージョン確認では何を保存しますか。
macOS、Node.js、DeepSeek Harnessの導入元とバージョン、起動コマンド、プロファイル、プラグイン、モデル名を保存します。特に開発者プレビューでは構成が変わりやすいため、画面写真だけでなくコマンド出力と設定ファイルを残してください。

再起動後に会話や設定が残るか、どう判断しますか。
再起動前にテスト会話と設定を記録し、同じアカウントで再起動後の一覧、履歴、ワークスペース、モデル設定を比較します。復元できた項目と再入力した項目を分離すれば、実際の運用手順になります。

リモートMacのワークスペースとコマンド権限はどう確認しますか。
隔離した検証リポジトリを用意し、読み取り、許可された編集、禁止ファイルの変更、作業範囲外の参照、承認が必要なコマンドを順番に試します。設定画面の表示ではなく、Agentが実際に到達できたパスと拒否された操作を記録してください。

継続稼働向けの障害復旧資料には何を含めますか。
ログの取得先、健康確認方法、更新担当、バックアップ対象、再構築できる範囲、切り戻し手順を含めます。復旧時間を実測していない場合は、数字を保証として書きません。資格情報は平文で保存せず、引き渡し後に交換します。

ログと切り戻しの責任を決める

受入の最後は、故障後に誰が何をするかです。次の5点が文書化されているか確認します。

  • セッションログを取得する方法。
  • Web UI、SSH、プロセスの健康確認方法。
  • DeepSeek Harnessや依存パッケージの更新担当。
  • バックアップされる設定、ワークスペース、ログの範囲。
  • 現行構成へ戻すためのパッチ、イメージ、再構築手順。

「バックアップあり」という表現だけでは不十分です。どのファイルが対象か、秘密情報を除外するか、復元後に何を再入力するかを明記します。環境の再構築境界を説明できない提供元は、長期稼働の責任分界も曖昧になりやすいです。

条件分岐で署名の判断を固定する

担当者ごとに判断が変わらないよう、次の分岐をそのまま社内基準にします。

  • 7指標すべてに実行記録があり、固定タスクを再現できる場合：通常受入に進みます。
  • モデル、ツール、再起動、ログのいずれかが未確認の場合：条件付き受入にし、期限と担当者を記載します。
  • 権限境界を確認できない場合：本番コードや秘密情報を投入せず、受入を保留します。
  • セッションや設定の復元範囲が不明な場合：継続稼働を前提にせず、再注入手順を整備します。
  • 交接資料に平文の鍵が残っている場合：鍵を交換してから署名します。
  • 固定タスクの成功信号を保存できない場合：ページが利用できても受入不合格とします。

交接パッケージには、環境一覧、アクセス責任、検査日時、入力、成功結果、失敗記録、バックアップ範囲、切り戻し手順を含めます。結論は「合格」「期限付き整改」「受入拒否」の3種類に限定すると、後から責任がぼやけません。

現在の手元Macや一般的なクラウド環境で始める方法は、短期の概念実証には向いています。しかし、スリープやOS更新で長時間処理が止まる、共有アカウントで権限の境界が曖昧になる、ディスク保持とログ取得の責任が不明確になる、といった欠点があります。専用のMac環境へ移す場合も、クラウドだから安全・安定と決めつけず、今回の検査票で実際の提供条件を確認してください。

固定した検査項目で、並列タスク数、隔離要件、希望するレンタル期間を整理できたら、MACCOMEのクラウドMac案内やMac miniのレンタル条件と照らし合わせると、必要な実行環境を比較しやすくなります。日本向けの配置を検討する場合は、東京向けMac環境の案内も候補になります。

自前のMacを購入するほうが、物理インターフェースや長期固定負荷を必要とする案件には適しています。一方、検証期間が限定され、チームで同じ環境を共有し、再現可能な引き渡しを優先するなら、MACCOMEのMacレンタルを同じ受入表で確認するほうが、未検証の構成を先に約束するより安全です。