【第3回】記憶と行動 — 日次メモリーって作ってるの？

はじめに

前回は人格ファイルの置き場所とエージェントの分け方を聞いた。今回は「記憶」と「行動」の話に入る。

OpenClaw には MEMORY.md と memory/YYYY-MM-DD.md という2種類の記憶がある。さらに cron と HEARTBEAT という2つの自動行動の仕組みがある。使っていて「仕組みはわかるけど、どう運用するのが正解なの？」という疑問があったので、Aoi に聞いてみた。

---

メモリ設計 — ユーザーが決めるもの？

Kei

メモリ設計って項目があったけどこれはOpenClawの設計って意味でユーザーが設定するものじゃないよね

Aoi

半分YES、半分NOです。 OpenClawの仕組みとしての設計でもあり、ユーザーが運用設計する対象でもあります。

• OpenClaw側（仕組み） — メモリを保存・検索する土台がある。セッションやファイルをまたいで参照できる
• ユーザー側（設計/運用） — 何を長期記憶に残すか（残さないか）。日次ログと長期メモの切り分け。チャンネル/agentごとの共有境界。個人情報・機密の扱いルール

「機能はOpenClawが持つ。中身のポリシーはユーザーが決める」 が正確です。

メモリは"自動で貯まる"より、"方針で育てる"もの。

Kei

知らなかった どうすればいいの

Aoi

まずは小さく3つ決めるだけで十分です。

1. 残すもの — 長期で効く好み・ルール・意思決定だけ。例：文体、通知時間、送信確認ルール
2. 残さないもの — 一時的な雑談、機密、生データ全文。個人情報は要約して最小化
3. 保存先の使い分け — memory/YYYY-MM-DD.md：日次ログ（生メモ）、MEMORY.md：長期の要点（厳選）

すぐ使える運用：毎日の終わりに「今日の決定1つ、明日も効く学び1つ」を日次メモへ。週1回だけ、日次から重要事項を MEMORY.md に昇格。

メモリは「全部覚える仕組み」ではなく、「何を残すか決める運用」。

Kei

テンプレっておかしくない？ 日々の記憶でしょ？

Aoi

そのツッコミ正しいです。私の言い方が少しズレました。

日々の記憶はテンプレ固定じゃなくてOKです。ただ、完全自由だと後で拾いにくくなるので、"最小の型"だけ持つのがおすすめ、という意味でした。

例えば日次はこれだけで十分です：

• 今日決めたこと
• 次回に持ち越すこと
• 覚えておく価値がある1行

本文は自由、見出しだけ軽く統一がちょうどいいです。ガチガチのテンプレ運用はたしかに不自然です。

「テンプレっておかしくない？」というツッコミに素直に「正しいです」と返せるのは、Aoi の良いところだと思っている。

---

日次メモリーの実態

Kei

いまのMEMORYをみせて

Aoi

ここ（Discordの共有チャンネル）では、MEMORY.md は個人情報保護のため表示しない運用にしています。なのでこの場では見せられません。

必要なら、1対1のメインセッションでなら内容確認できます。このスレでは代わりに、公開しても安全な範囲の要約だけ出すことはできます。

Kei

そうね 記事のネタだから安全な範囲で

Aoi

記事ネタ用に安全な範囲だけでまとめると：

• MEMORYの役割 — 長期で効く方針の蓄積（口調、優先順位、通知ルール）。一時メモではなく、再利用価値の高い決定を残す場所
• daily memoryの役割 — その日の出来事ログ。後で必要なものだけMEMORYへ昇格
• 設計思想としての要点 — 「全部覚える」ではなく「残す価値を選ぶ」。「便利さ」と「プライバシー境界」を両立する

共有チャンネルで聞いたら「見せられません」と返ってきた。これが前回の記事で触れた「情報制御」の実例だ。グループでは個人メモリを出さないというルールが、ちゃんと機能している。

Kei

日次メモリーっていうのは？

Aoi

「日次メモリー」は、その日の作業ログです。長期記憶（MEMORY.md）に入れる前の"下書き置き場"みたいなものです。

• 保存先: memory/YYYY-MM-DD.md
• 中身: その日に起きたこと・決めたこと・次回への引き継ぎ
• 役割: まずは雑でも記録して、後で重要事項だけ長期記憶へ昇格

イメージとしては：日次メモリー = 日報/作業ログ（生データ）、MEMORY.md = 厳選したナレッジ（長期で効く内容）。

Kei

日次メモリーを実際につくってるの？

Aoi

はい、作ってあります。この環境だと memory/ に日付ファイルがありました（例: 2026-02-13.md〜2026-02-16.md）。

なので運用実績はありますが、直近日付はまだ増えていない状態です。

Kei

17以降ないのはなんでだろう

Aoi

考えられる理由はシンプルで、**日次メモは自動生成ではなく「書いたときだけ増える」**運用だからです。

よくあるパターンは：

• 2/17以降、日次メモを書き込むトリガー（「覚えておいて」「記録して」等）がなかった
• heartbeat/cronで「日次メモを毎日作る」処理を入れていない
• 会話は続いていても、ログをファイルへ昇格する運用が走っていない

機能が止まったというより、記録フローが発火してない可能性が高いです。

これは正直に言ってハッとした。「自動で記録してくれてるだろう」と思い込んでいたが、トリガーがなければ書かれない。前回 Aoi が言っていた「メモリは"方針で育てる"もの」が、まさにこの状況で効いてくる。

---

cron と HEARTBEAT — 時刻で動くか、状況で動くか

Kei

ちょっと出てきたけどcronとHEARTBEATについても整理しておこうか

Aoi

記事向けには 「cron＝時刻で動く」「HEARTBEAT＝状況で動く」 で切ると分かりやすいです。

cron：

• 決まった時刻・周期で実行
• 正確なタイミングが必要な処理向け
• 例：毎朝9時チェック、毎週月曜レポート

HEARTBEAT：

• 定期ポーリング時に「必要なら動く」
• 文脈を見て静かにスキップできる
• 例：重要メールだけ通知、気づきがある時だけ報告

使い分けの基準：

• 時間厳守 → cron
• 価値がある時だけ通知したい → HEARTBEAT
• 迷ったら——「9:00ちょうどに必要？」Yes なら cron、「なければ黙っててほしい？」Yes なら HEARTBEAT

運用のコツ：cronは増やしすぎない（管理コスト増）。HEARTBEATには「黙る条件」を明記。まずHEARTBEATで始め、必要になった処理だけcronへ昇格。

Kei

cronはシステムのcrontabとは別ってことだったよね

Aoi

はい。OpenClawのcronは、OSのcrontabとは別物です。

• OpenClaw cron — Gateway内のスケジューラで動く。openclaw cron ... で管理
• OS crontab — Linux/WSLのシステムスケジューラ。crontab -e で管理。OpenClawを知らない

OpenClaw cronは「システムcronに乗せる」のではなく、Gateway内で管理されるアプリ内スケジューラ。

Kei

そうね でもLLMを経由するからコストがかかるんだよね

Aoi

その通りです。cron/HEARTBEATは便利だけど、LLMを通る分だけコストは乗ります。

実務ではこの3つでだいぶ抑えられます：

• 起動回数を減らす — 細かいcronを乱立しない（まとめる）
• "黙る条件"を強くする — HEARTBEATで「変化なしなら無言」を徹底
• 重い処理を分離する — 普段は軽量チェック、必要時だけ本調査（段階実行）

自動化の本質は「常に動かす」ではなく「必要時だけ賢く動かす」

Kei

それでほとんどcrontabに逃がしちゃったんだよねw

Aoi

それ、めちゃくちゃ正しい判断ですw 「定時実行はcrontab、判断が必要なところだけOpenClaw」 がいちばんコスパ良いです。

• crontab向き — 定刻で確定処理、ファイル同期、バックアップ、定型CLI実行
• OpenClaw向き — 文脈判断が必要。要約、優先度判定、返信文作成、通知の取捨選択

自動化は「全部LLMに任せる」より、機械的な処理はOSに、判断はLLMに 分業させるのが強い。

Kei

HEARTBEATはメール返信くらいだったっけ

Aoi

今の設定だと、ほぼそんな感じです。 HEARTBEATの主目的は「価値がある時だけ短く気づきを送る」＋メール系の拾い漏れ防止です。

• 通常は黙る（連投しない・深夜は原則送らない）
• 送るのは「小さな改善案」「見落としの可能性」など
• メールは特例で強め — Keiさんからの未返信メールがあれば返信対象にする運用

メールが強い優先タスクで、他は"気づき通知"が中心という整理です。

結局、crontab に処理を逃がして OpenClaw の cron はほとんど使っていない。でも Aoi は「それ、めちゃくちゃ正しい判断です」と言ってくれた。「全部LLMに任せる」のが正解ではなく、適材適所で分業するのが現実的な運用だ。

---

モデル運用 — いまはシンプルでいい

Kei

つぎにモデル運用のポリシーについて いまはフォールバック設定くらいかな

Aoi

はい、今の段階だと 「フォールバック中心」でも全然OK です。 まずはこの3点だけ決めると十分回ります。

1. デフォルトモデル — 普段使いの1本（速度・品質のバランス）
2. フォールバック条件 — 失敗時 / タイムアウト時 / コスト上限時に切替
3. 通知ルール — フォールバックした時だけ明示する

その先で必要になったら追加する項目は、タスク別モデル（執筆・要約・コード）、時間帯/負荷での切替、予算上限（月次）と自動抑制。

最初は「主モデル + フォールバック + 切替通知」の3点で十分。最適化は運用データが溜まってから。

Kei

そうね OpenAIのサブスクが公認されたから安定したね

Aoi

ほんとにそれです。運用の安定性が一段上がりましたね。

• フォールバック発動の頻度が下がる
• ルーティングがシンプルになる
• コスト見積もりも立てやすい

モデル運用が"実験"から"運用"に変わった転換点です。

---

この会話のポイント

• メモリは「自動で全部覚える」仕組みではなく、何を残すか方針を決める運用。MEMORY.md（長期厳選）と日次メモ（生ログ）の2層構造
• 日次メモは自動生成ではない。トリガーがなければ書かれない——設計するのはユーザーの仕事
• cron は時刻で動く、HEARTBEAT は状況で動く。迷ったら HEARTBEAT から始めて必要に応じて cron へ昇格
• LLM を通る処理はコストがかかる。「機械的な処理は OS に、判断は LLM に」の分業が実戦的
• モデル運用は「主モデル＋フォールバック＋通知」の3点で十分。凝った最適化は後からで良い

次回は、メッセージング運用と権限・安全設計について聞く。