Appleの公式資料では、Macの電源スケジュールをpmset -g schedで確認できます。(support.apple.com)
画面が切れたがログとプロセスが動いているなら、再送せずに監視を続けます。Mac休止後のDeepSeek Harness中断で状態を確認できないなら、作業領域とログを保全し、続行ではなく再構築または手動確認へ切り替えてください。
この手順が必要な人
Macを閉じたあと、タスクが消えたように見える個人開発者向けです。リモート接続で長いビルドやテストを走らせるAgentエンジニアにも適しています。
継続稼働するMac環境の管理、障害復旧、再起動後の検収を担当する運用担当者にも役立ちます。
まず知っておくべき4つの中断原因
DeepSeek Harnessの画面やセッション記録だけでは、実行状態を確定できません。確認対象は次の4つです。
画面や接続だけが切れた
- Macは起動中です。
- Harnessのプロセスも動いている可能性があります。
- Web画面の再読み込みや再接続だけで復帰できる場合があります。
macOS休止に入った
- Mac自体は電源が入っていますが、省電力状態になります。休止中はディスクや通信、プロセスの進行に影響が出ます。(support.apple.com)
- Wake for network accessが有効でも、個別のAgentタスクが最後まで進む保証にはなりません。(support.apple.com)
ユーザーのログアウトや認証状態が変わった
- LaunchAgentはログイン中のユーザー環境で動作します。
- Keychainの認証情報やグラフィック権限に依存する処理は、同じMacでも実行コンテキストが変わると失敗します。(developer.apple.com)
Harnessまたは子プロセスが終了した
- セッション履歴が残っていても、実際のコマンド、ビルド、テストが動いているとは限りません。
- 作業領域に差分があっても、処理が正常終了した証拠にはなりません。
ケース:画面は切れたが処理は続いていた
リモート接続が切れた直後に、同じタスクをもう一度送るとします。最初のプロセスがまだAPI呼び出しやビルドを実行していれば、二重実行、同じファイルへの競合、重複公開につながります。
このケースでは、最初に別の接続経路でMacへ入り、プロセス、ログ、作業領域、生成物の4点を確認します。ログの時刻が進み、生成物が想定された順序で更新されているなら、画面だけの障害と判断して待機できます。
Web UIが切れたとき、タスク停止をどう判定するか
最初にブラウザーを更新しないでください。更新しても元のプロセスが再接続されるとは限らず、逆に新しい指示を送る危険があります。
第一段階:Macの到達性を確認する
別のSSH接続、リモートデスクトップ、または管理用の接続から次を確認します。
- Macへログインできるか。
- CPUやメモリを消費するHarness関連プロセスがあるか。
- ログファイルの最終更新時刻が進んでいるか。
- 作業領域のファイル更新が意図した範囲に収まっているか。
- 子プロセスやテストランナーが残っているか。
DeepSeek Harnessの実装によっては、会話やセッションの保存と、現在動いている処理が別管理になっている場合があります。公開されているHarnessのREADMEでも、セッション保存、SQLite状態、バッチ実行などは実装ごとに異なる構成として説明されています。自分の導入版で同じ機能が有効か、READMEと実際の起動方法を照合してください。(github.com)
停止条件
次のどれかに該当するなら、待機を止めます。
- ログの更新が止まり、プロセスも存在しない。
- プロセスはあるが、子プロセスがゾンビ化または異常終了している。
- 生成物が途中状態で、完了マーカーがない。
- 外部サービスへの送信や公開が完了したか確認できない。
- ロックファイルだけが残り、所有プロセスがない。
状態を確認できないまま、同じプロンプトや同じ公開コマンドを再送してはいけません。
Mac休止後のDeepSeek Harness中断をどう切り分けるか
pmset -g schedでスリープや起動の予定を確認し、システムログとHarnessの最後のイベント時刻を並べます。休止開始の直前でログが止まったなら、電源状態が原因候補です。ただし、その時間関係だけで「唤醒後に自動継続する」とは判断できません。
Macの休止設定は、電源接続時とバッテリー使用時で異なる場合があります。画面オフとシステム休止を混同せず、電源設定、Wake for network access、予定された起動や休止を個別に確認してください。(support.apple.com)
復帰後は次の順番で確認します。
- 作業領域を別ディレクトリまたは別ブランチへ保全します。
- Harness本体と子プロセスの存在を確認します。
- 最後のログイベントと作業領域の差分を照合します。
- 生成物のハッシュ、サイズ、完了ファイルを確認します。
- 最小の読み取り専用テストを実行します。
- 次の段階を続けるか、途中から再構築するか決めます。
テストや公開処理の完了状態が不明な場合、Agentに「前の段階は終わった」と推測させないでください。未知の状態で自動継続すると、未完了処理のスキップや重複操作が起きます。
ユーザー退出後に何を確認すべきか
「ブラウザーを閉じる」「リモート接続を切る」「macOSからログアウトする」「システムを再起動する」は、同じ切断ではありません。
ブラウザーを閉じただけなら、Mac上のプロセスは残る可能性があります。リモート接続を切った場合も、接続方式と起動元によっては処理が継続します。一方、ログアウトではユーザーセッションに属するプロセスが終了する可能性があり、LaunchAgentもログインセッションとの関係を確認する必要があります。(developer.apple.com)
Keychainを利用する認証処理では、ログインユーザーのコンテキストが重要です。ユーザー環境で動く処理と、システムコンテキストで動くデーモンでは、参照できるKeychainや権限が異なります。(developer.apple.com)
復旧前の対照リスト
ブラウザー終了
- プロセス、ログ、成果物を確認すれば待機できる可能性があります。
- UIの再接続だけで復旧する場合があります。
リモート接続切断
- 接続元ではなく、Mac側でプロセスを確認します。
- 接続切断をタスク終了とみなしてはいけません。
macOSログアウト
- ユーザー単位のLaunchAgent、Keychain、GUI権限を再確認します。
- 認証を再利用できると決めつけないでください。
システム再起動
- 実行プロセスは一度失われます。
- セッション記録があっても、処理の途中状態は別途検証が必要です。
プロセスが消えたあと、続行か再構築かを決める方法
プロセスが終了している場合は、セッションが表示されるかではなく、作業の冪等性で判断します。
続行に向く条件
- 最後のイベントが明確です。
- 生成物が完全で、検証に通ります。
- 次の処理が重複しても外部副作用がありません。
- ロックファイルや一時ファイルを安全に整理できます。
- Harnessが再開位置を明示できます。
再構築に向く条件
- API送信、公開、データ更新の完了状態が不明です。
- 部分ファイルが最終成果物と区別できません。
- テスト結果の保存がありません。
- 子プロセスの終了理由が分かりません。
- 認証コンテキストが変わっています。
長い処理ほど、1回の大きなAgentタスクにまとめない設計が有効です。ビルド、テスト、成果物検証、公開を分け、各段階にログと完了マーカーを残してください。
5分で実行できる中断復旧チェックリスト
- [ ] 作業領域を別名で保全しました。
- [ ] Harness本体と子プロセスを確認しました。
- [ ] 最後のログ時刻を記録しました。
- [ ]
pmset -g schedで休止・起動スケジュールを確認しました。(support.apple.com) - [ ] macOSログアウト、単なる接続切断、再起動を区別しました。
- [ ] Keychainや環境変数の認証経路を確認しました。
- [ ] ロックファイルの所有プロセスを確認しました。
- [ ] 生成物のハッシュまたは検証テストを実行しました。
- [ ] 外部公開やデータ更新の完了状態を確認しました。
- [ ] 状態不明のまま同じタスクを再送していません。
- [ ] 続行、再構築、手動承認の判断理由を記録しました。
復旧テストを合格にする基準
長期のバックグラウンドタスクを運用するなら、通常動作だけでなく中断後の状態を検収します。最低限、次の4ケースを同じバージョンで試してください。
- リモート接続だけを切断する。
- Macを休止させてから復帰する。
- Harnessの親プロセスを終了する。
- Macを再起動する。
各ケースで、プロセスが戻るか、セッションが読めるか、作業領域が壊れていないか、生成物を検証できるかを記録します。1つでも完了状態を判定できないなら、その処理は無人継続ではなく手動承認へ分類します。
運用上の分類は3つで十分です。
中断後に再実行できる処理
- 一時ファイルを捨てても安全です。
- 外部副作用がなく、入力から再生成できます。
プロセスを保持すべき処理
- 大規模ビルド、長時間テスト、継続的なストリーム処理です。
- 休止やログアウトを前提にしない独立環境が向きます。
人の承認が必要な処理
- 公開、課金、データ削除、外部システム更新です。
- 状態不明からの自動再開を禁止します。
Macの常時稼働環境を比較する場合は、KVMNODEのMac環境案内で接続方式と利用形態を確認し、必要に応じてMac環境の導入候補と自分の復旧要件を照合してください。
FAQ
Macを閉じたあともDeepSeek Harnessは動き続けますか?
画面を閉じただけでも、Macが休止へ移行すると通信やプロセスの進行に影響が出る場合があります。Wake for network accessはMacを起こすための設定であり、個別のHarnessタスクの自動継続を保証するものではありません。復帰後にログ、プロセス、生成物を確認してください。
Web画面が切れたらAgentタスクも停止したと考えるべきですか?
停止とは限りません。別の接続からMacへ入り、プロセス一覧、ログの更新時刻、作業領域の差分、子プロセスを確認してください。ログが継続し、成果物が管理された順序で更新されている場合は待機できます。確認できない場合は再送せず、状態保全を優先します。
Macの復帰後に元のタスクを続けられるか判断する方法は?
作業領域を保全してから、最後のイベント、ロックファイル、生成物、テスト結果を照合します。次の段階が明確で、外部副作用の完了状態も確認できる場合だけ続行します。公開やデータ更新の結果が不明なら、最小テストと手動承認を挟んでください。
リモートMacを再起動するとDeepSeek Harnessの会話は自動復旧しますか?
セッション記録が残ることと、処理プロセスが再開することは別です。再起動後はHarnessの親子プロセス、ユーザー単位の起動設定、Keychain、作業領域、生成物を個別に確認してください。自動復旧を前提にすると、途中処理の重複や未完了段階の見落としが起こります。
長時間のAgent処理をmacOSの休止で止めない方法は?
電源接続時の休止設定、Wake for network access、予定された休止と起動を確認してください。ただし、休止対策だけではログアウト、プロセス終了、再起動を解決できません。4種類の中断テストで復旧境界を確認し、継続要件が厳しい処理は常時オンラインの独立Macへ移す方が安全です。
現在のMac運用から独立したMac環境へ切り替える判断
ローカルMacは、短いビルド、対話的な修正、物理デバイスを使う作業に向いています。一方で、合間に休止する、ユーザーがログアウトする、接続だけが切れる、再起動後の検収を行っていないという状態では、長時間のDeepSeek Harness処理を任せにくくなります。
現在の方法には、休止設定への依存、ユーザーセッションへの依存、プロセス終了後の復旧判定不足という欠点があります。4つの中断テストで合格基準を満たせないなら、独立したオンラインMac環境へ移し、プロセス責任、ログ保存、再起動後の検収を分離してください。KVMNODEのMacレンタルを候補にする場合も、契約前に「休止しないこと」だけでなく、再接続、再起動、認証、作業領域保全まで確認するのが現実的です。