loopify

/loopify — エージェントループを設定する

「このタスクを定期的に実行したい」という状態から、適切な実行間隔、冪等性、終了条件を備えたループを設定するウィザードです。参考（Claude Code）：ScheduleWakeup（動的な実行間隔）、CronCreate（固定スケジュール）、組み込みの/loop（動的な自己ペースでの再実行）です。その他のホストについては、ステップ 4 の「Claude Code 以外のホストについて」を参照してください。

ステップ 0 — ループする内容を確認する

コンテキストから明らかでない場合は、「このループで各反復時にどのタスクを実行しますか？」と尋ねます。

次に、必要事項を確認します。

質問	重要な理由
どのくらいの頻度で実行しますか？	cron、動的実行、単発実行のいずれにするかを決めます
いつ停止しますか？	終了条件です。ループには必ず必要です
ループ本体では何をしますか？	必要な冪等性の要件を決めます
出力先はどこですか？	ファイル／通知／コミット／出力なし
2 回実行された場合、どのような障害が起きますか？	冪等性を検証します

ステップ 1 — パターンを選ぶ

主なパターンは 3 つあります。「どのくらいの頻度で実行するか」の回答に応じて選択します。

パターン A — Cron（固定スケジュール）

次の場合に使用：毎朝 8 時、毎週金曜日、毎時 0 分など、予測可能な間隔でタスクを実行する場合。

ツール：CronCreate — cron 式で定期タスクをスケジュールします。

CronCreate({
  schedule: "0 8 * * *",           // daily at 8am local
  prompt: "<loop body prompt>",
  timezone: "America/Los_Angeles"
})

よく使われる cron パターン：

• 0 8 * * * — 毎日 8 時
• 0 9 * * 1 — 毎週月曜日 9 時
• 0 9 * * 5 — 毎週金曜日 9 時
• 0 */2 * * * — 2 時間ごと
• */15 * * * * — 15 分ごと

トレードオフ：

• ✅ 予測しやすく、人にも読みやすいため、把握が簡単です
• ✅ 時刻に依存するタスク（朝の概要、1 日の終わりの要約）に最適です
• ❌ 前回の実行が終わっていなくても、スケジュールされた時刻に実行されるため、ループ本体を冪等にする必要があります
• ❌ 自己調整機能はありません。タスクの所要時間が大きく変動する場合、スケジュールしすぎになります

パターン B — 動的な実行間隔（自己スケジュール）

次の場合に使用：時計ではなく状態に応じてタスクを実行する場合。条件が満たされるまで監視するパターンや、外部イベントを待つ場合。

ツール：ScheduleWakeup — 現在の実行が次回の起動を自らスケジュールします。

ScheduleWakeup({
  delaySeconds: 270,               // stay in cache window (< 5min)
  reason: "checking build status; sleeping under 5min to stay cache-warm",
  prompt: "<same task, re-entered>"
})

重要な遅延時間のルール（ScheduleWakeup のドキュメントに基づき、ウィザードに組み込まれています）：

遅延時間	用途	キャッシュへの影響
60s–270s	アクティブな処理 — ビルドのポーリング、まもなく変化する状態の待機	5 分間のプロンプトキャッシュを維持するため、高速かつ低コストです
300s ❌	使用しないでください	どちらの利点も得られません。キャッシュミスが発生する一方で、待機時間を延ばす効果がありません
300s–3600s	状態が変わるまで数分かかるものを待つ場合	キャッシュミスは発生しますが、それに見合う効果があります
1200s–1800s（20～30 分）	特定のシグナルがないアイドル時の実行間隔	自律ループのデフォルトです

300s をそのまま選ばないでください。270 に短縮してキャッシュを維持するか、1200 以上にしてキャッシュミスを受け入れ、待機時間を延ばしてください。

トレードオフ：

• ✅ 状況に応じて調整されます。アイドル時は長く、アクティブ時は短く待機します
• ✅ 適切に調整すれば、キャッシュ効率が最適になります
• ❌ 次回の実行をいつスケジュールするか、ループ本体で判断する必要があります（追加のロジックが必要です）
• ❌ 次にいつ実行されるかを予測しにくくなります

パターン C — 単発ループ（条件成立まで実行）

次の場合に使用：条件が満たされるまでタスクを実行し、その後停止する場合。その後の繰り返し実行はありません。

ツール：プロンプト自体に終了条件を含めて、組み込みの/loopを使用します。

/loop
Check if the deploy is healthy. If yes → stop. If no → wait 5 min and check again.
Max 10 iterations. If still failing after 10, alert and stop.

トレードオフ：

• ✅ 条件を確認し続ける用途では、最も簡単です
• ✅ 有界で、必ず最終的に終了します
• ❌ 無期限に繰り返す用途には向きません。その場合はパターン A または B を使用します

ステップ 2 — ループ本体を冪等に設計する

冪等とは、ループを 2 回実行したときに、1 回実行した場合と同じ結果になることです。cron と動的パターンでは必須です。前の反復がまだ実行中、または一部しか完了していない間に、次の実行が開始されるためです。

冪等性のパターン：

• 「すでに完了」のマーカーを使う：例として、最終成功実行時のタイムスタンプを記録した状態ファイル <vault>/.loopify/<name>-last-run.txt をコミットします。ループ本体では、作業を行う前にタイムスタンプを確認します。
• 重複排除キーを使う：ループから DB やファイルに書き込む場合は、コンテンツハッシュまたはタイムスタンプをキーにして、再実行しても何も行われないようにします。
• トランザクションを使う：ループ本体の DB 書き込みはアトミックにします。すべてコミットされるか、すべてロールバックされるかのどちらかにします。
• 変更前に状態を確認する：変更を適用する前に現在の状態を確認します。すでに適用済みならスキップします。

冪等性チェックを強調しながら、ループ本体のドラフトをユーザーに提示します。まだない場合は追加します。

ステップ 3 — 停止条件

すべてのループに必要です。選択肢：

停止条件	使用する場面
最大反復回数（例：100 回の実行後に停止）	cron ループ — 暴走を防ぎます
状態ベース（例：メトリクス X が Y を下回ったら停止）	監視ループ
時間ベース（例：24 時間後に停止）	期間を限定した監視
エラーベース（例：連続 3 回失敗したら停止）	すべてのループ — 劣化を検知します

ループが本当に無期限の場合（例：終了予定のない週次 cron など）でも、CronDelete を使った手動停止手段を追加します。ユーザーが停止方法を把握できるよう、SKILL／ループのメモに記載します。

ステップ 4 — スケジュールを設定する

ステップ 1 のパターンに基づいて設定します。

cron（パターン A）：

CronCreate({
  schedule: "<expression>",
  timezone: "<tz>",
  prompt: "<loop body>",
})

返された cron_id を報告し、ユーザーが後で CronDelete を実行できるようにします。

動的（パターン B）： ループ本体のプロンプトの末尾で ScheduleWakeup を呼び出すようにします。

<do the work>
Then: ScheduleWakeup({delaySeconds: <tuned per Step 1>, prompt: "<same body>", reason: "<why this cadence>"})

ワンショット（パターン C）： /loop <prompt with exit condition> を実行するだけです。

Claude Code 以外のホストの場合

CronCreate、ScheduleWakeup、/loop は Claude Code の機能です。このスキルのその他の内容（パターンの選択、冪等性、停止条件、検証）は、どのエージェントにも適用されます。他のホストでは、スケジューラーはエージェントの外部にあり、非対話型のエージェント実行を呼び出します。

スケジューラー	使用する場面
ホスト独自のスケジュールタスク（利用可能な場合）	第一候補です。ホストのドキュメントを確認してください
システムの cron／launchd／systemd タイマー	マシンが常時稼働しており、ループでローカルファイルが必要な場合
GitHub Actions schedule:	リポジトリ上でループが動作し（vault のコンパイル、上流の確認など）、ノート PC を閉じても実行を継続する場合

ジョブは、ループ本体をプロンプトとしてヘッドレスエージェントコマンドを実行します。例：claude -p "<body>"、codex exec "<body>"、または cursor-agent -p "<body>"。エージェントの CLI が提供する非対話モードを使用してください。

• 動的な実行間隔調整（パターン B）に直接相当するものはありません。固定スケジュールを使い、処理がなければループ本体を早期終了させます。
• ワンショット（パターン C）は、停止条件をループ条件に含めたシェルの while ループでヘッドレスコマンドを実行する形になります。
• ヘッドレス実行では承認を求められないため、動作する範囲で最小限の権限をジョブに付与し、プロンプトへの入力待ちにならないよう、出力をファイルまたは通知に書き込ませます。

ステップ 5 — 初回実行を検証する

最初の反復を待つか、同じプロンプトを使って /loop から手動で実行し、ドライランを行います。次の点を確認してください。

• 出力が想定どおりの場所に書き込まれた
• 冪等性チェックが機能する（2 回実行し、2 回目は何も行われない）
• 停止条件が、条件に該当した場合に正しく動作する
• 設定している場合、ログ／通知が表示される

ステップ 6 — 報告と次の対応

次の内容を報告します。

• 選択したパターン（A／B／C）とその理由
• 登録した Cron ID またはウェイクアップパターン
• 設定した停止条件
• 導入した冪等性の仕組み
• ループの停止方法（CronDelete <cron_id>、または動的パターンの場合は「ウェイクアップを呼び出さない」）

次のことを提案します。

• 「このループ設定を skillify from-chat でスキルとして保存しますか？」
• 「この機会に weekly-review または daily-startup のループも登録しますか？」
• 「ループの実行時に second-brain の出力先へ書き込みますか？」

よく使うループのレシピ

よく使うループの種類向けのテンプレートです（使用時に内容を埋めてください）。

• references/daily-brief.md — 朝のルーチンループ（カレンダー＋優先事項＋夜間の状況）
• references/weekly-review.md — 金曜日のポートフォリオ状況確認
• references/upstream-check.md — 適応したスキルの上流に変更がないか定期的に確認
• references/vault-compile.md — raw/ → wiki/ の定期的なコンパイル
• references/metric-monitor.md — 指標をしきい値に達するまでポーリングし、達したらアラートを送信

組み合わせて使うもの

• skillify — -ify 三部作の仲間です。新しい SKILL.md を作成するには skillify を使います。目的がスキルではなくスケジュールされたタスクの場合は、loopify を使います。
• toolify — 仲間です。インテグレーションを追加するには toolify を使います。すでに統合されているツールの上で何かをスケジュール実行するのが目的の場合は、loopify を使います。
• second-brain — 多くのループは vault（raw/ または outputs/）に書き込みます。vault の自動コミットパターンが適用されます。
• pm — daily-brief と weekly-review のループは、出力を生成する前に pm から情報を読み取ることがよくあります。

品質に関する注意事項

• delaySeconds に 300s を指定しないでください。 どちらの利点も得られません。270 に下げるか、1200 以上にしてください。
• すべてのループに停止手段が必要です。 無期限のループでも、手動で停止する方法を記載してください。
• cron＋dynamic では、冪等性が必須です。 前の反復が実行中に、ループが二度起動することを想定してください。
• 頻度の高すぎる cron より、動的な間隔調整を優先してください。 15 分ごとの cron は、作業の準備ができていなければトークンを浪費します。動的な間隔調整なら、アイドル時に頻度を下げられます。
• cron_id を記録してください。 そうしないとループが孤立し、停止しにくくなります。
• 各反復を簡潔に記録してください。 1 行（「2026-06-30 08:00 daily-brief: 実行、3 件」）だけでも、動作のずれを簡単にデバッグできます。
• 外部 API にアクセスするループでは、レート制限を守ってください。 ベンダーの上限が 1 日 100 回なら、1 日 500 回の実行をスケジュールしないでください。
• 不確かな場合は、無期限より期間を限定してください。 1 週間実行するか 1 か月実行するか迷ったら、まず 1 週間から始め、問題なく動くことを確認してから延長してください。