# ScheduleWakeup

`/loop` ダイナミックモードで作業を再開するタイミングをスケジュールします。このツールにより、Claude はタスクの反復ペースを自律的に制御し、指定した時間だけスリープしてから同じループプロンプトで再びトリガーできます。

## 使用タイミング

- 反復間隔が固定のクロックではなく作業状態に依存する `/loop` ダイナミックタスクで自律的にペースを制御する場合
- 長いビルド、デプロイ、またはテスト実行が完了するまで待ってから結果を確認する場合
- 現時点で監視すべき特定のシグナルがない場合に、反復間のアイドル待機を挿入する場合
- ユーザープロンプトなしの自律ループを実行する場合——リテラルセンチネル `<<autonomous-loop-dynamic>>` を `prompt` として渡す
- まもなく状態が変化するプロセスをポーリングする場合（短い遅延でキャッシュをウォームに保つ）

## パラメータ

- `delaySeconds`（数値、必須）：再開までの秒数。ランタイムが値を `[60, 3600]` に自動クランプするため、手動でクランプする必要はありません。
- `reason`（文字列、必須）：選択した遅延時間の理由を説明する短い一文。ユーザーに表示され、テレメトリに記録されます。具体的に記述してください——「bun ビルドの完了を確認中」は「待機中」より有用です。
- `prompt`（文字列、必須）：ウェイクアップ時にトリガーされる `/loop` 入力。次のトリガーがタスクを繰り返せるよう、毎ターン同じ文字列を渡します。ユーザープロンプトなしの自律ループの場合は、リテラルセンチネル `<<autonomous-loop-dynamic>>` を渡します。

## 例

### 例 1：急速に変化するシグナルを再確認するための短い遅延（キャッシュウォームを維持）

ビルドが起動したばかりで、通常 2〜3 分で完了します。

```json
{
  "delaySeconds": 120,
  "reason": "約 2 分で完了予定の bun ビルドを確認中",
  "prompt": "ビルドステータスを確認してエラーを報告する"
}
```

120 秒の遅延により、会話コンテキストが Anthropic プロンプトキャッシュに保持されます（TTL 5 分）。次のウェイクアップはより高速で低コストになります。

### 例 2：長いアイドル待機（キャッシュミスを受け入れ、より長い待機に分散）

データベースマイグレーションが実行中で、通常 20〜40 分かかります。

```json
{
  "delaySeconds": 1200,
  "reason": "マイグレーションには通常 20〜40 分かかるため、20 分後に確認",
  "prompt": "マイグレーションステータスを確認し、完了していれば続行する"
}
```

ウェイクアップ時にキャッシュはコールドになりますが、20 分の待機は単一のキャッシュミスのコストを十分に分散させます。5 分ごとにポーリングすると、同じキャッシュミスコストを 4 回支払うことになり、何のメリットもありません。

## 注意事項

- **5 分のキャッシュ TTL**：Anthropic プロンプトキャッシュは 300 秒後に期限切れになります。300 秒未満の遅延はコンテキストをウォームに保ちます。300 秒を超えると、次のウェイクアップでキャッシュミスが発生します。
- **ちょうど 300 秒は避ける**：これは最悪の選択です——キャッシュミスのコストを支払いながら、実質的に長い待機時間を得られません。270 秒に下げる（キャッシュウォームを維持）か、1200 秒以上にコミットする（1 回のキャッシュミスでより長い待機を確保）かのどちらかにしてください。
- **アイドル待機のデフォルト値**：監視すべき特定のシグナルがない場合は、**1200〜1800 秒**（20〜30 分）を使用します。これにより、ループは定期的に確認しつつ、無意味なキャッシュミスを毎時 12 回発生させずに済みます。
- **自動クランプ**：ランタイムは `delaySeconds` を `[60, 3600]` にクランプします。60 未満の値は 60 になり、3600 を超える値は 3600 になります。自分でこれらの境界を処理する必要はありません。
- **ループを終了するには呼び出しを省略する**：反復を停止する場合は ScheduleWakeup を呼び出さないでください。呼び出しを省略するだけでループが終了します。
- **毎ターン同じ `prompt` を渡す**：`prompt` フィールドには、毎回の呼び出しで元の `/loop` 指示を含める必要があります。これにより、次のウェイクアップがどのタスクを再開すべきかを認識できます。
