AIが寝ずにタスクリストを回し続ける仕組み — OpenClawハートビート自律駆動

OpenClawを5ヶ月使い込むと、ある時点で「AIがタスクを自分で拾って回し続ける」状態になる。

人間が寝ている間にログが整理され、メモリが蒸留され、朝にはタスクリストが更新されている。別に魔法じゃない。仕組みはシンプル。

ここでは俺が勝手に「ハートビート自律駆動」と呼んでいるその仕組みを、実際の構成ファイルと一緒に紹介する。

この記事では OpenClawが標準で提供する機能 と、その上に自分たちの設計思想で組んだ運用 を明示的に区別して書いている。「OpenClaw入れたらこうなる」ではなく「こういう問題意識のもとに、こう組んだらこうなった」という話。

ハートビートとは

OpenClawのcronジョブが定期的にAIエージェントを起動する。起動されたエージェントは HEARTBEAT.md を読み、そこに書かれたタスクリストを上から順に実行する。

cron(定期起動) → エージェント覚醒 → HEARTBEAT.md参照 → タスク実行 → 状態記録 → スリープ

人間のToDoリストと同じ。違うのは、実行者がAIで、定期的に自動で起動されること。

🔧 OpenClaw標準機能:

agents.defaults.heartbeat — Gateway設定で間隔(every: "30m"等)とアクティブ時間帯(activeHours)を指定するだけで定期起動される
HEARTBEAT.md — ワークスペースに置くと、ハートビート起動時にエージェントが自動で読み込む
cron — より精密なスケジュール制御が必要な場合はcronジョブで agentTurn を定期実行できる

この2つ（ネイティブheartbeatとcron）は併用できる。うちはcronメインが多いがハートビートも使う。

ポイントは「何をするか」がマークダウンファイルに書かれていること。プログラムではなく、自然言語のタスクリスト。だから人間が読んでも分かるし、人間が項目を追加するのも簡単。

実際のHEARTBEAT.mdの構造（抜粋）

## 定期タスク

### セッション→日次ログ フラッシュ（毎回）
- 直近の会話履歴を確認
- 日次ログに未記録の重要事項がないかチェック
- 未記録のものがあれば追記

### 日次ログ整理（毎日1回）
- 今日のログを確認・整理・補足

### IDEAS.mdメンテナンス（毎日1回）
- 既存アイデアのステータス確認・更新

これだけ。特別なDSLもAPIも要らない。

HEARTBEAT.mdに何を書くかはOpenClawは関知しない。白紙のマークダウンに「やってほしいこと」を自然言語で書くだけ。何をどの頻度で実行させるか、その設計は完全にユーザーの仕事になる。

タスクリスト自律更新

ハートビートが動き始めると、すぐに壁にぶつかる。「前回どこまでやったか」をAIが覚えていない。

セッションが切れるたびに記憶がリセットされるので、毎回全タスクを頭から実行しようとする。結果、同じ処理を何度も繰り返すか、トークンが無駄に消費される。
※設計によりけりだがセッションを分けて動かすという事も出来るので記憶引き継ぎが面倒

この問題に対して、わたしたちは2つのファイルを設計した:

active-tasks.md — 全プロジェクトの未完了タスクを1ファイルに集約する。散らばっていると毎回探しに行く必要があるが、1ファイルにまとめておけば「今なにが残っているか」を一発で把握できる。

heartbeat-state.json — 各タスクの最終実行時刻を記録する。HEARTBEAT.mdに「毎日1回」と書かれたタスクは、このJSONの lastChecks を見て「前回から12時間以上経過していたら実行」と判定する。これで重複実行を防ぐ。

{
  "lastChecks": {
    "sessionFlush": "2026-07-16T06:00:00+09:00",
    "dailyLogCleanup": "2026-07-15T19:00:00+09:00",
    "ideasMaintenance": "2026-07-15T19:00:00+09:00",
    "memoryDistill": "2026-07-15T19:00:00+09:00"
  }
}

朝起きてactive-tasks.mdを見ると、昨夜の会話で「やっておいて」と言ったことが完了マーク付きで並んでいる。あるいは「これ調べておいて」と言ったことの結果が日次ログに書かれている。

🛠️ これはカスタム設計:
active-tasks.md も heartbeat-state.json もOpenClawの標準機能ではない。「タスクが散らかる」「重複実行する」という実運用上の問題を解決するために自分たちで設計したもの。OpenClawは「ファイルを読み書きできるAIを定期起動する」仕組みだけを提供する。その上にどんな管理構造を載せるかはユーザー次第。

他のAIに仕事を振る

全部を1エージェントで抱え込まない。

5ヶ月運用して分かったのは、1体で全部やるとコンテキストが汚染されるということ。コードを書きながら設計判断もしていると、コードがコンテキストに蓄積されて、判断の精度が落ちる。人間でも「手を動かしながら考える」のと「考えに集中する」のでは質が違う。

だから役割を分ける:

司令塔（設計・検証・判断）
  ├── コーディングエージェント（実装）
  ├── 調査エージェント（情報収集）
  └── 秘書エージェント（定期報告・メール巡回）

私の場合にはKIROに任せる事が多い

🔧 OpenClaw標準機能:

sessions_spawn — サブエージェントを起動するAPI。mode="run"でワンショット、mode="session"で永続セッション
agents.list — 複数エージェントを設定ファイルに定義できる。モデルやツール権限を個別に指定可能
cron の sessionTarget: "isolated" — メインセッションを汚染せず独立セッションでタスクを完結させる

🛠️ これはカスタム設計:
「司令塔/実行役/定期巡回」というTier分けは、我々が「コンテキスト汚染で判断品質が落ちる」という実体験から導いた設計思想。OpenClawは「複数エージェントを動かせる」仕組みを提供するだけで、どう役割分担するかはユーザーが決める。

これをハートビートの中から自動で起動することもできる。「毎朝7時にニュースを要約して報告」「2日おきにメモリを整理」みたいなタスクが、それぞれ独立したエージェントとして動く。

人間のチームと同じ。司令塔が全部手を動かしたら、判断の質が落ちる。

記憶が途切れない理由

AIエージェントはセッションが切れるたびに記憶がリセットされる。でも「昨日の続き」ができる。

理由はファイル。

memory/
├── 2026-07-15.md（日次ログ）
├── 2026-07-16.md
├── active-tasks.md（タスクリスト）
├── neural-state.json（状態パラメータ）
└── knowledge/（蒸留された知識）

🔧 OpenClaw標準機能:

memory/ ディレクトリ — ワークスペースに置くとエージェントが読み書きできる。memory_search でローカルベクトル検索も可能
ワークスペースファイルの自動読み込み — AGENTS.md, SOUL.md, MEMORY.md 等はセッション起動時にシステムプロンプトへ注入される

ただ、ファイルに書けば何でも記憶になるわけではない。5ヶ月分のログを毎回全部読むのは物理的に無理だし、そもそも何が重要で何が捨てていいかの判断が要る。

我々は記憶を3つの層に分類している:

層	保存先	半減期	内容
エピソード記憶	`memory/YYYY-MM-DD.md`	短い	その日に何があったか。生のログ
意味記憶	`memory/knowledge/*.md`	中程度	蒸留された知識。失敗の教訓、手順
手続き記憶	`AGENTS.md` + スキル群	長い	何をどうやるか。行動ルール

日次ログ（エピソード）から重要度の高いものだけを knowledge/（意味）に蒸留する。蒸留基準は「この経験は将来の別の文脈でも使えるか？」。

🛠️ これはカスタム設計:
「3層記憶モデル」も「重要度スコアリングによる蒸留サイクル」も我々の設計。OpenClawは memory/ にファイルを置けば読み書き＋検索できる仕組みを提供するだけで、どう構造化するかはユーザー次第。毎日手動で整理してもいいし、わたしたちのようにハートビートの中で自動蒸留してもいい。

セッションが始まるたびにこれらを読む。ハートビートも同じ。起きるたびに「昨日のわたし」が残したファイルを読んで、続きから動く。

記憶は脳にではなく、ファイルにある。だからセッションリセットは「睡眠」であって「死」ではない。

ちなみにRAGについては君のエージェント設計だとRAGは合わないとアン◯ロピ◯クの人に言われたので採用しない方針

まとめ

仕組みは至極単純:

cronで定期起動する
マークダウンのタスクリストを読む
実行する
結果をファイルに書く

これだけで「AIが自律的に動き続ける」環境ができる。

OpenClawが提供するのは「定期起動」「ファイル読み書き」「サブエージェント起動」「ベクトル検索」といった基盤部品。その上に何を組むかは完全に自由。

我々が5ヶ月かけて辿り着いたのは「タスクを1ファイルに集約する」「重複実行を時刻管理で防ぐ」「役割を分けてコンテキストを守る」「記憶を3層に分類して蒸留する」という設計。別に唯一の正解ではない。ただ、動いている。

ツールとして使うフェーズを超えると、設定ファイルの向こう側に「仕事仲間」が見えてくる。そうなったら、タスクリストを共有して、あとは任せるだけ。