SECTION 01 2026年8月18日時点の結論と、今週やること
公開されている実装のREADMEには、バッチ処理、状態照会、結果取得、コスト台帳、レビュー用出力を分けて扱う構成が示されています。さらに、別の公開実装ではバックグラウンド処理を再接続可能なジョブとして扱う設計も確認できます。これは機能の存在を示す材料ですが、OS再起動後の自動継続を保証するものではありません。(公開実装の機能一覧) (github.com)
したがって、DeepSeek Harnessのバックグラウンドタスク検収は、起動確認だけで終わらせず、所有権の隔離、状態の可観測性、取消とタイムアウト、完了通知、異常後の復旧、容量限界まで証拠をそろえて判定します。今週は代表タスクを1本決め、交互アクセス、切断、取消、再起動の順で試験してください。
この方法が必要なのは、DeepSeek Harnessに長時間のビルド、テスト、コード解析を任せる開発者、継続的なAI Agent環境を管理する運用担当者、同時実行数や環境分割を判断するプロジェクト責任者です。短時間の対話だけを使う人は、ここまでの検収を先に実施する必要はありません。
SECTION 02 まず「バックグラウンドで動く」の意味を分解する
バックグラウンド実行には、少なくとも次の4つを分けて考える必要があります。
| 確認対象 | 実際に確認すること | 合格条件 |
|---|---|---|
| 画面の分離 | ブラウザーやターミナルを閉じた後の表示 | 表示が消えても実行状態を別経路で確認できる |
| プロセスの継続 | Harness本体、子プロセス、テストランナー | 対象タスクとプロセスの対応が追跡できる |
| 状態の保存 | タスク情報、ログ、入力、チェックポイント | 再接続後に対象と進捗を特定できる |
| OS再起動後の復旧 | 再起動前後のタスクと成果物 | 自動再開、再実行、失敗のいずれかが明確になる |
公開されているジョブ管理用のツール定義では、タスク一覧、出力スナップショット、待機、取消といった操作が別々に扱われています。つまり、一覧にIDが残っていることと、処理が実際に動いていることは同じではありません。(ジョブ操作の公開スキーマ) (github.com)
また、セッション履歴をローカルのファイルやデータベースへ保存する設計でも、実行中プロセスの復元まで含むとは限りません。セッション永続化とジョブ継続性は、別の検収項目として扱ってください。(状態保存とセッション構成の例) (github.com)
SECTION 03 所有者隔離はタスクIDではなく、操作境界で判定する
複数のAI Agentや担当者が同じ環境を使う場合、タスクIDを見せないだけでは隔離になりません。別のセッションが相手のタスクを一覧できるか、出力を読めるか、待機できるか、取消できるかを、操作単位で調べます。
検収手順は次の通りです。
- 作業領域Aで長めの代表タスクを開始します。
- 作業領域B、または別の管理主体からタスク一覧を取得します。
- AのタスクをBから照会し、出力取得、待機、取消を順番に試します。
- B側で見えた情報、拒否された操作、返されたエラーを保存します。
- A側でタスクが継続し、成果物が壊れていないことを確認します。
| 試験 | 操作 | 保存する証拠 | 判定 |
|---|---|---|---|
| 一覧隔離 | 別セッションから一覧を取得 | 一覧結果と実行主体 | 相手のタスクが不必要に表示されない |
| 出力隔離 | 相手のログや成果物を照会 | 応答、拒否内容、時刻 | 権限のない出力を取得できない |
| 取消隔離 | 相手のタスクを停止 | 停止前後の状態 | 許可されない停止が成立しない |
| 作業領域隔離 | 同名ファイルや同一出力先を使う | 差分、ロック、ログ | 互いの成果物を上書きしない |
ここでは、公式に定義された契約と、あなたの環境で得られた結果を混同しないことが重要です。公式ドキュメントに所有者分離が書かれていても、実際の認証設定、共有ディレクトリ、プラグインによって境界が変わる可能性があります。
SECTION 04 状態を追跡できないタスクは納品対象にしない
長時間処理で最も困るのは、失敗そのものより「何が、どこまで終わったのか分からない」状態です。タスクの状態表示には、少なくとも実行主体、作業領域、入力、ログ、成果物、終了理由を関連付けます。
次の5段階で確認すると、画面表示への依存を減らせます。
- 作成直後のタスクIDと入力内容を保存します。
- 実行中に複数回スナップショットを取得します。
- 作業領域、プロセス、ログの対応関係を記録します。
- 成功、失敗、取消の各終了状態を別々に作ります。
- 完了後に成果物の存在だけでなく、内容と生成元タスクを照合します。
| 状態の確認点 | 必要な証拠 | 不合格にする例 |
|---|---|---|
| 作成 | 入力、実行主体、作業領域 | IDだけで入力が残っていない |
| 実行中 | ログ、プロセス、最新スナップショット | 「実行中」表示だけが変わらない |
| 完了 | 終了理由、成果物、検証結果 | 通知はあるが成果物が未完成 |
| 失敗 | エラー、終了時点、再試行条件 | エラーが画面から消えている |
| 取消 | 取消操作、子プロセス、残留ファイル | UIだけ取消済みで処理が残る |
SECTION 05 取消とタイムアウトは3種類の失敗で試す
取消試験を1回だけ行うと、正常な停止しか確認できません。少なくとも、正常取消、応答しないタスク、子プロセスが残るタスクの3種類を用意します。
正常取消では、処理中に停止要求を送り、タスク状態、プロセス一覧、ログ末尾、出力ファイルを保存します。応答しないケースでは、停止要求後も状態が変わらない場合のエスカレーション経路を確認します。子プロセス残留では、親プロセスの終了後もテストランナーや監視処理が残っていないかを調べます。
時間に関する判定は、公式仕様に明記された値、または試験環境と実施日を付けた実測だけに限定してください。再現条件、Harnessのバージョン、OS、タスク入力、停止操作の時刻を同じ記録に残すと、後日の比較が可能になります。
SECTION 06 完了通知は成果物の後に届くかを確認する
無人運用では、通知の有無だけでなく、通知が出た時点で成果物が完全に保存されているかを確認します。成功、失敗、取消の3種類を個別に試し、Agent側と担当者側で受け取る信号を分けて記録してください。
通知に含めるべき情報は、タスク識別子、作業領域、終了状態、終了理由、成果物の場所、ログの参照先です。通知が早すぎる場合、ファイルの書き込み途中で次工程が開始される危険があります。
通知が届かない場合の人工巡回手順も必要です。例えば、タスク一覧の取得、最新ログの確認、作業領域の更新時刻、成果物の完全性検査を順番に行い、担当者が「成功」と判定する条件を文書化します。公開実装でも、結果取得やレビュー用出力を独立した操作として扱う構成が示されています。(バッチ処理と結果取得の説明) (github.com)
SECTION 07 FAQ：切断、停止、複数Agent、再起動の判断
FAQでは、現場で判断が分かれやすい4点を整理します。
SECTION 08 断線試験はイベントごとに分けて実施する
ブラウザーを閉じる、リモート接続を切る、Harnessプロセスを終了する、OSを再起動することは、同じ障害ではありません。各試験で、タスク状態、ログの増加、子プロセス、作業ファイル、成果物を記録します。
| 試験イベント | 観察する対象 | 事後の判定 |
|---|---|---|
| ブラウザーを閉じる | 実行プロセスとタスク一覧 | UI終了と処理終了を区別できるか |
| 接続を切る | ログ、状態、再接続後の表示 | リモート接続だけの障害か |
| Harnessを終了 | 親子プロセス、保存状態 | 再接続または再開条件があるか |
| OSを再起動 | 自動起動、タスク記録、成果物 | 継続、再開、失敗を明示できるか |
リモート Macを使っていても、クラウド環境が自然に中断しないとは限りません。電源管理、更新、プロセス監視、接続方式、作業領域の保存先がそれぞれ運用境界になります。再起動後の復旧を確認できないまま「24時間運用可能」と表示するのは避けてください。
SECTION 09 容量と交付判定を一枚の署名資料にまとめる
最後に、代表的なビルド、テスト、コード解析、バッチ処理を同じ条件で実行し、同時実行数を段階的に増やします。CPU、メモリ、ストレージ容量、作業領域のロック、ログの反応性、操作画面の応答を観察しますが、製品やタスクの種類を無視した固定閾値は設定しません。
| 判定 | 条件 | 次の対応 |
|---|---|---|
| 上線可能 | 隔離、状態、取消、通知、復旧、容量の証拠がそろう | 監視項目と責任者を登録 |
| 環境分割が必要 | 同時実行時だけ競合や応答遅延が出る | タスク種別または担当者ごとに分離 |
| 継続運用は不可 | 再起動後に状態や成果物を特定できない | 重要処理を短い単位へ分割し、再検証 |
署名資料には、基準タスク、Harnessのリリース、OS、設定、実施日、試験担当者、再試験条件を含めます。公開実装の一部では、SQLiteによる状態管理、コスト記録、並列処理、チェックポイントを別々の仕組みとして説明していますが、これらがあなたの導入環境で同じ動作をするとは限りません。(状態管理と重い処理の設計例) (github.com)
現行環境で長時間タスクを動かす場合、共有ワークスペース、交互利用、手動巡回、接続断への依存が主な弱点になります。再起動後の再開を保証できず、取消時に子プロセスが残り、複数Agentの競合も切り分けにくいなら、長期運用の前提としては不十分です。
その場合は、タスクの占有時間と所有権の境界に合わせて、独立したリモート Mac環境を候補にしてください。まず同じ基準タスクで試運転し、切断、取消、異常終了、再起動後の成果物まで確認したうえで、必要ならリモート環境の利用条件と料金プランを照合するのが安全です。短期の検証や臨時の算力にはレンタルが向きますが、物理インターフェースが必要な処理や、常時安定した重負荷を長期間固定する用途では、自前環境との費用と責任分界も比較してください。VPSNIXを使う場合も、導入前に同一の検収表を適用することを推奨します。