「画面は実行中のまま、結果が返らない」なら、まずLLM retryの開始証拠を確認してください。新しい再試行イベントがなく、待機時間も制御できない場合は、無限に待たず現場を保存して停止します。モデル、通信、設定、ツール、リモートプロセスのどこで止まったかを分ければ、再実行すべきか判断できます。
この手順は、ローカルで待機状態を見ているユーザー、無人のバックグラウンドタスクを運用する担当者、再試行ログと上流APIの状態をまとめて監視したいプラットフォーム担当者向けです。
最初に、画面ではなく進行証拠を確認する
ある実行で、画面には読み込み表示が残っていました。しかし、セッションイベントに新しいモデル要求がなく、ツール完了記録も増えていませんでした。ここで画面更新を繰り返しても、停止した処理は復旧しません。
最初に次の3点を同じ時刻軸で確認します。
| 確認対象 | 見るべき信号 | 判断 |
|---|---|---|
| タスク状態 | 実行中、待機中、失敗、取消済みの状態変化 | 状態だけでは実行継続の証明になりません |
| セッションイベント | 要求送信、応答受信、再試行予定、再試行開始、ツール開始・完了 | 新しいイベントがあるかを確認します |
| プロセス | 対象プロセスの存在、CPU・I/O、作業ディレクトリ | プロセスがあっても処理が進むとは限りません |
DeepSeek Harnessの待機表示は、再試行中と判断してよいですか。
いいえ。表示だけでは不十分です。再試行予定の記録と、次の要求が実際に開始した記録が対になっているかを確認してください。モデル応答後に承認待ち、Hook、Bash、外部ツールで止まっている場合は、LLM retryの問題ではありません。
DeepSeek APIには、応答まで接続を維持する仕組みがあります。公式説明では、推論開始まで10分を超えた場合にサーバーが接続を閉じるとされています。接続が維持されていることと、Harness内部の処理が進んでいることは別です。(公式の接続維持と制限の説明) (api-docs.deepseek.com)
第一段階：再試行の予定と開始を分けて調べる
「再試行が予定された」という記録だけで、次の要求が送信されたとは限りません。保存されたイベントから、次の組み合わせを探します。
- 直前の要求が失敗または切断された時刻を確認します。
- 再試行を予定した記録を確認します。
- 再試行開始、要求送信、応答受信の順で記録を探します。
- 予定後に取消、プロセス終了、セッション切断がないか確認します。
- 新しい記録が増えていなければ、現場保存のうえ停止を検討します。
| 観察結果 | 可能性 | 次の行動 |
|---|---|---|
| 再試行予定あり、開始記録あり | 待機または上流応答中 | 通信と応答時刻を監視します |
| 再試行予定あり、開始記録なし | 待機取消、内部停止、プロセス中断 | ログを保存して停止します |
| 要求送信あり、応答なし | 通信、上流処理、接続処理 | 接続とサーバー状態を照合します |
| 応答受信あり、結果なし | ツール、承認、後処理 | ツール実行経路へ移ります |
モデル要求が失敗した後、何回まで自動再試行されますか。
固定回数を前提にしないでください。利用中のHarnessのバージョン、設定、エラー分類、実装中の待機条件によって挙動が変わる可能性があります。現在のログに記録された再試行予定と開始イベントを優先し、公式文書やソースで確認できない回数や待機時間を運用基準にしないことが安全です。
第二段階：同じモデルエラーなら設定を直す
毎回ほぼ同じエラーが返る場合、再試行回数を増やしても解決しません。DeepSeek APIの公式エラー一覧では、400は形式不正、401は認証失敗、402は残高不足、422はパラメータ不正、429はレート制限、500と503はサーバー側の障害または過負荷として整理されています。(公式エラーコード一覧) (api-docs.deepseek.com)
| 確認項目 | 検証方法 | 修正後の復旧基準 |
|---|---|---|
| モデル名 | 現在の設定ファイルと要求本文を照合 | 最小入力で応答が返る |
| APIキー | 使用プロセスの環境変数とキーの有効性を確認 | 認証エラーが消える |
| Base URL | OpenAI互換形式など、実際の接続先を確認 | 送信先が意図したAPIになる |
| Provider設定 | モデル、エンドポイント、認証方式の組み合わせを確認 | 同一エラーが再現しない |
| パラメータ | 必須項目、ツール定義、JSON形式を縮小して確認 | 最小要求が正常終了する |
公式ドキュメントでは、OpenAI互換形式のBase URLとして https://api.deepseek.com が案内されています。モデル名やAPI形式は更新されるため、設定を手入力で推測せず、利用時点の公式モデル一覧と要求仕様を照合してください。(公式モデル・料金一覧) (チャット完了要求の仕様) (api-docs.deepseek.com)
修正後は、長いプロンプトやツール定義をそのまま戻さないでください。短いテキスト、単一モデル、最小権限の設定でモデルチェーンだけを検証し、成功してから元のタスクへ段階的に戻します。
第三段階：モデル成功後のツール停止を切り分ける
LLMから200相当の正常応答やツール呼び出しが返っても、Agent全体が完了したとは限りません。モデル要求の完了と、ツール結果の返却、次のセッションイベント、最終回答の生成は別工程です。
次の順番で確認します。
- モデル応答を保存し、ツール呼び出しが含まれているか確認します。
- 承認が必要な操作で止まっていないか確認します。
- HookやBashが終了コードを返したか確認します。
- 外部ツールの接続、標準出力、タイムアウトを確認します。
- 最小の安全なツール呼び出しで完了まで再現します。
ツール問題の調査で、すべての権限を一括で開放するのは避けてください。原因が権限なのか、作業ディレクトリなのか、外部接続なのか分からなくなり、破壊的な操作のリスクも増えます。
復旧と判断できるのは、最小ツール呼び出しが開始し、結果を返し、その結果をHarnessが次のイベントとして保存できた状態です。モデルだけが返答しても、ツール完了記録がなければ復旧扱いにしません。
第四段階：リモート環境の変化を確認する
遠隔実行では、接続が切れたことだけでタスク停止とは断定できません。一方、接続が切れたまま処理継続とも証明できません。プロセス、ネットワーク出口、スリープや再起動、作業ディレクトリを別々に確認します。
| 環境確認 | 瞬間的な障害の例 | 継続的な環境問題の例 |
|---|---|---|
| プロセス | 一時的な接続断後もプロセスが存続 | プロセスが終了、親プロセスも消失 |
| ネットワーク | 一時的な名前解決や経路障害 | 同じ出口からAPI接続が継続失敗 |
| OS状態 | 短時間の復帰後に実行が進む | スリープ、再起動、強制終了が発生 |
| 作業場所 | 同じ作業ディレクトリを保持 | マウント解除やパス変更が発生 |
再試行後の遠隔タスクは、どうすれば現場を復元できますか。
まずセッションイベント、標準出力、プロセス一覧、作業ディレクトリ、環境変数の状態を保存します。環境の識別情報が変わっている場合は、旧タスクを無理に継続せず、新しい検証タスクを作成してください。古いセッションを再開することが、同じ失敗を繰り返す原因になる場合があります。
クラウドMacを使っている場合は、実行前に接続断後のプロセス保持、スリープ抑止、再起動後の作業領域、ログ回収方法を決めておく必要があります。環境選びから見直すなら、MACCOMEのMacレンタル案内と、Mac miniの利用方法を確認し、DeepSeek Harnessを長時間動かす条件と照合してください。
停止・再実行・環境移行を決めるチェック項目
次を順番に確認してください。
- [ ] 最新イベントの時刻と、最後に進行したイベントの種類を保存しました。
- [ ] 再試行予定と再試行開始の両方を確認しました。
- [ ] モデル名、Provider、Base URL、APIキーを照合しました。
- [ ] 400、401、402、422、429、500、503などの公式分類と実際の応答を照合しました。
- [ ] 最小テキスト要求でモデル経路を単独検証しました。
- [ ] ツール、承認、Hook、Bash、外部接続の停止箇所を確認しました。
- [ ] リモートプロセス、ネットワーク出口、OS再起動、作業ディレクトリを確認しました。
- [ ] バージョン、セッション識別子、エラー本文、再現手順を保存しました。
判断は次の3つに分けます。
| 条件 | 結論 | 実施内容 |
|---|---|---|
| 新しいイベントが継続し、原因が一時的 | 継続待機 | 監視期限を決めて待ちます |
| 進行証拠がなく、現場を保存できる | 取消して再実行 | 最小構成から再検証します |
| 環境の識別情報や作業領域が変化 | 新環境へ移行 | 新しい検証タスクとして開始します |
結局、DeepSeek Harnessの反復リトライを止める基準は「画面が動いているか」ではなく、「次の要求と結果が記録されているか」です。長時間タスクだけで断線や作業環境の変化が再発するなら、DeepSeek Harnessを再インストールする前に、バックグラウンドタスクの受入条件とクラウドMacの復旧条件を見直してください。
手元のMacだけで運用すると、スリープ、ネットワーク切断、作業場所の消失、再接続後のログ回収を個別に管理する必要があります。長時間の検証や一時的なAgent環境では、MACCOMEのMacレンタルを使って実行場所を分離したほうが、停止後の再現と現場保存を組み立てやすい場合があります。ただし、物理インターフェースが必要な処理や、長期にわたる安定した高負荷運用では、自前環境との費用と管理範囲を比較して選んでください。