DeepSeek Harness 自動化：タスクの設定と検証
DeepSeek-V4 Team · 2026年10月8日 · 17 min read
時間通りに届くリマインダーは、自動化タスクの前半に過ぎません。後半は、モデルに依頼された作業そのものです。DeepSeek Harness は、保存された配信記録とリンクされた会話を通じてこの区別を可視化しますが、両方を確認する必要があります。
2026 年 10 月 3 日リリースの dsh-v0.2.1-alpha.1 では、自動化機能が Web モードに組み込まれています。このチュートリアルは 対象バージョンのスケジュールガイド に従います。これは独自のインストール向けの小さな動作確認の手順を提供するものであり、測定された信頼性の結果を報告したり、マシンオフ時の無人実行を保証するものではありません。
リマインダー作成前にモードを確認する
モデルプロバイダーを構成し、Standard、Creator、または PTC モードを使用してください。これらのプリセットはリマインダーツールを公開します。Minimal モードは公開せず、委任されたサブエージェントもそれらへのアクセスを拒否されます。スケジューリング機能の欠如は、言葉の問題ではなくモードの問題である可能性があります。
サイドバーから 自動化タスク を開きます。このページでは、各会話を最初にアクティブにせずに会話全体のタスクを検査できます。新規 アクションは、作成リクエストが既にメッセージ入力欄に入っている新しいセッションを開きます。あらゆるドラフトと同様に、送信前に検査してください。
最初の試行では、結果が明白な無害なリクエストを選択してください。モデルに複数のウェブサイトを検索させてレポートを作成させるよりも、短い固定チェックリストを依頼する方が、配信と実行の検査は容易です。基本メカニズムが機能した後で外部依存関係を追加できます。
識別可能な配信から始める
次のようなリクエストを送信します。
2 分後に、この会話でサンプルレポートを確認するようリマインダーを送ってください。リマインダー指示では、ソース日付、欠落行、合計の整合性という 3 つのチェックで返信するよう求めてください。ワンタイムリマインダーを作成し、保存されたタスク名と予定時刻を表示してください。
これは繰り返しタスクではなく、ワンタイム遅延を依頼しています。タスク詳細を開き、その区別を確認してください。待っている間は Host を稼働させてください。リマインダーが届いたら、依頼された 3 つのチェックについて会話を検査し、記録 を開いて配信証拠を検査します。
保存された記録は、リマインダーが会話インボックスに永続的に書き込まれたことを意味します。モデルが依頼されたレスポンスを完了したことを意味するわけではありません。記録が存在しても結果が欠落している場合は、スケジュールを再作成する前に会話とプロバイダー状態を調査してください。そうでなければ、同じリクエストに対して複数のタスクを作成するリスクがあります。
配信後、ワンタイムタスクは非アクティブになります。タスクリストの すべて または 非アクティブ で見つかります。アクティブなリマインダーをリストするビューから消失しても、タスクまたはその履歴が削除されたことを意味しません。
毎日のローカル時間には「毎日」ルールを使用する
毎日の壁時計リマインダーと固定経過間隔は、異なる意図を表します。「24 時間ごと」は間隔アンカーから開始します。「Asia/Shanghai の毎朝 09:00」はローカル時計時間とゾーンを指定します。実際の要件に一致するルールを選択してください。
例えば:
Asia/Shanghai の毎朝 09:00 に、この会話でサンプルレポートを検査するようリマインダーを送ってください。タスク名を Daily report check にしてください。毎日ローカル時間ルールを使用し、ワンタイムリマインダーまたは固定 24 時間間隔は作成しないでください。作成後、保存されたルールと次回予定時刻を表示してください。
ルール で、頻度、時間、保存された IANA ゾーンを確認してください。次のターゲットはデバイスのゾーンで表示されるため、デバイスが別のゾーンを使用している場合、保存されたルールとは異なって見える可能性があります。2 つの見える時計値が一致する必要があると仮定せず、基礎となる意図された時間を比較してください。
夏時間の変更があるゾーンの毎日スケジュールは追加の注意が必要です。対象バージョンのガイドによると、存在しないローカル時間はスキップされ、重複する時間は先に来る時刻に 1 回だけ実行します。固定間隔は経過時間スケジューリングであり、それらの壁時計ルールに従いません。
複製を作成せず既存タスクを編集する
アクティブなタスクを選択し、ルール を開きます。名前、指示、タイミングを編集できます。編集は 変更を保存 が選択されるまでローカルに残ります。受け入れられた編集は、タスク ID、元の会話、保存された配信記録を保持します。
間隔を変更すると、次の間隔は Host が保存を受け付けた時刻から測定されます。同等の正規化ルールはタイマーを再起動しません。この違いは短い間隔をテストする際に重要です。指示のみを変更することは、新しいスケジュールとして扱われるべきではありません。
保存後、タスクを再開または更新し、保存された値を検査してください。更新を確認できない場合は、再試行する前に現在のタスクを検査してください。古い画面と失敗した書き込みは異なる問題です。非アクティブなタスクは読み取り専用なので、完了したワンショットタスクの非アクティブカードを編集して繰り返しタスクに変えることは期待しないでください。
Host の再起動動作を意図的にテストする
スケジューラーは Host 内で実行されます。ブラウザタブを閉じることは、Host プロセスを停止することと同じではありません。再起動テストを実行する前に、インストールを実際に所有しているプロセスまたはデスクトップアプリケーションを特定してください。
使い捨てのワンタイムリマインダーを使用してください。期限到来前に Host を停止し、その時間後に再度起動します。文書化された動作は、保存されたタスクをチェックし、期限切れのワンショットを配信することです。繰り返しリマインダーの場合、再起動は Host が停止している間に経過したすべての間隔ではなく、直近で実行時刻を過ぎた回だけを処理します。
この実験に外部副作用のあるタスクを使用しないでください。ドキュメントは 厳密に 1 回だけの配信を保証しません。インボックス永続化後だがタスク記録更新前の失敗は、配信されたメッセージを記録されずに残し、繰り返しを許可する可能性があります。レポートドラフトは、支払い、メッセージ送信、または不可逆的なファイル操作よりも優れた試行です。
2 つの結果で動作確認の記録を保持する
各トライアルに短い表を使用してください。配信と作業完了の区別は、緑色のスケジューリング指標が不完全な結果を隠さないようにします。
| トライアル | 配信証拠 | 作業証拠 |
|---|---|---|
| ワンタイム遅延 | 予定発生時に保存された記録 | 会話内に依頼されたチェックリストが表示される |
| 毎日ルール | 正しい頻度、ゾーン、次回ターゲット | 次回配信リクエストが意図した指示を使用する |
| 編集 | 新しい保存値と同じタスク ID | 後続のレスポンスが編集された指示に従う |
| 再起動 | Host 起動後に予想される期限切れリマインダー | リンクされた会話が依頼された結果を生成する |
記録は設定された履歴制限内で保持されます。欠落した古い履歴は、現在の指示を見るだけでは再構築できません。記録をモデル実行の完全な監査ログではなく、実際に含まれるエントリの配信証拠として扱ってください。
終了したらトライアルを削除する
詳細から使い捨てタスクを削除し、削除を確認します。これにより将来の配信が停止し、タスクの保存された配信履歴が削除されます。元の会話ですでにキューに入れられたメッセージは取り消されないため、作業が既に期限を迎えている場合はその会話を確認してください。
対象バージョンはタスクの一時停止や実行ごとの新規セッション作成をサポートしません。元の会話と利用可能な編集コントロールを中心にワークフローを設計してください。永続的な実行トラッキングを持つ継続運用サービスが必要な場合は、リマインダーサポートから推測するのではなく、別途構築してください。
インストールと移行のコンテキストについては、Harness 0.2.1 アップデートレビュー を読んでください。観察可能なリマインダーから始め、タイミング、配信、完了がインストールでどのように表示されるかを理解してから、実際の作業を追加してください。