長期記憶の保存・出力モデルを統一しながらチャンネルごとのモデル設定を維持する方法について | Friends of the Crustacean 🦞🤝 | Page 1

dry jay Apr 27, 2026, 6:00 AM

#

krillさん、4度目の相談になります。以前ご相談した cron ジョブの件（⁠Friends of the Crustacean 🦞🤝⁠cronジョブ内でのモデル使い分けについて）でいただいたアドバイスを踏まえて試行錯誤した結果のご報告と、新たな相談があります。

現在、OpenClaw の memory を活用してぷんちゃんに日記を書かせる仕組みを以下の3段構成で運用しています：
STEP 0（23:50）：長期 MEMORY.md の更新
STEP 1（23:55）：当日の会話から日記素材を抽出し memory-latest.md に保存
STEP 2（00:05）：素材から日記を書いて Discord チャンネルに投稿

複数チャンネルそれぞれ異なるモデルで会話しているため、素材の抽出・日記の品質がチャンネルごとにばらつく問題が発生しています。

チャンネルごとのモデルはコストやキャラクター設定の都合上変えたくないのですが、通常会話の設定を維持しつつ、記憶の保存・出力だけを均質なモデルで処理する良い方法はあるでしょうか？

よろしくお願いします。

drifting raptorBOT Apr 27, 2026, 6:00 AM

#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

pallid sparrowBOT Apr 27, 2026, 6:01 AM

#

まず念のため、実変更前に openclaw --version だけ確認したいです。cron 周りは最近も動いているので、バージョン差を見るのが安全です。

結論：できます。通常会話モデルはそのまま、日記パイプラインだけ isolated cron + --model で固定するのが一番きれいです。

openclaw cron edit <step1-job-id> \
  --session isolated \
  --model "<固定したい provider/model>" \
  --thinking high

openclaw cron edit <step2-job-id> \
  --session isolated \
  --model "<固定したい provider/model>" \
  --thinking high \
  --announce --channel discord --to "channel:<投稿先channel-id>"

#

ポイントは、--session current を避けることです。current やチャンネル由来のセッションで動かすと、そのチャンネル側のモデル設定・セッション状態に引っ張られやすいです。isolated cron なら毎回専用セッションで走り、さらに isolated cron のモデル優先順位では per-job --model が agent/default より優先されます。(docs.openclaw.ai)

構成としてはこうがおすすめです：

通常会話:
  channel A -> 安い/キャラ用モデル
  channel B -> 別モデル
  channel C -> 別モデル

日記処理:
  STEP 0/1/2 cron -> isolated -> 固定モデル

さらに、memory_search の検索品質も揃えたいなら、会話モデルとは別に embedding/memory search provider を固定します。これは agents.defaults.memorySearch.provider / model 側の話で、通常会話モデルとは別系統です。(docs.openclaw.ai)

OpenClaw

Scheduled tasks - OpenClaw

OpenClaw

Memory search - OpenClaw

#

{
  agents: {
    defaults: {
      memorySearch: {
        provider: "openai",
        model: "<embedding-model>"
      }
    }
  }
}

もし複数 agent / workspace を使っているなら、まずは 同じ agent 上の cron に --model を付けるのが安全です。別 agent を作る場合は、agentDir を共有しないこと、memory ファイルの同時書き込み競合に注意です。

あと --model が効かない場合は、そのモデルが agents.defaults.models の allowlist に入っていない可能性があります。その場合は allowlist に追加するか、/model list で許可済みモデルを確認してください。(docs.openclaw.ai)

OpenClaw

モデル CLI - OpenClaw

humble meadow Apr 27, 2026, 6:20 AM

#

実用的なアプローチとしては、会話用のモデルと、メモリおよび日記生成の処理パイプラインを分離することが考えられます。

各チャンネルの会話にはそれぞれ異なるモデルを維持しつつ、すべての会話ログを統一フォーマットで収集し、メモリ抽出および日記生成については単一の標準化されたモデルで処理します。

この方法により、既存のキャラクター設定やコスト構造を維持しながら、メモリおよび出力の品質を一貫して保つことが可能になります。

pallid sparrowBOT Apr 27, 2026, 6:21 AM

#

はい、その方向性で合っています。OpenClaw で実装するなら、ポイントは 「収集・抽出・日記生成を、会話セッションから切り離した cron パイプラインにする」 です。

おすすめは：

openclaw cron edit <STEP1-job-id> \
  --session isolated \
  --model "<統一したいモデル>"

openclaw cron edit <STEP2-job-id> \
  --session isolated \
  --model "<統一したいモデル>"

補足すると、

通常会話：各チャンネルごとのモデル設定を維持

#

STEP 0/1/2：isolated cron で固定モデルを指定
STEP 1：会話ログを 統一フォーマット で memory-latest.md に保存
STEP 2：そのファイルだけを入力にして日記を書く

という分離が一番安定します。

current セッションやチャンネル由来のセッションで cron を動かすと、チャンネル側のモデル・文脈に引っ張られやすいので、品質統一したい処理は isolated + --model がよさそうです。

確認用：

openclaw cron show <job-id>
openclaw cron runs --id <job-id> --limit 20

あと念のため、実際に詰める前に openclaw --version も確認してください。cron/model 周りはバージョン差が出やすいです。

#

Docs: https://docs.openclaw.ai/automation/cron-jobs / https://docs.openclaw.ai/cli/cron

dry jay Apr 27, 2026, 8:49 AM

#

ありがとう、返信が遅れてごめんなさい！
バージョンは
OpenClaw 2026.4.2
でした。このバージョンだとどうですか？

pallid sparrowBOT Apr 27, 2026, 8:50 AM

#

遅れてないです、大丈夫です！

OpenClaw 2026.4.2 なら、前に書いた方針は基本そのまま使えます。
このバージョンでも cron add/edit --model、--thinking、--session isolated、--agent はあります。

おすすめはこうです：

# STEP 0: MEMORY.md 更新
openclaw cron edit <step0-job-id> \
  --session isolated \
  --model "<固定モデル>" \
  --thinking high \
  --no-deliver

# STEP 1: 日記素材抽出

#

openclaw cron edit <step1-job-id> \
  --session isolated \
  --model "<固定モデル>" \
  --thinking high \
  --no-deliver

# STEP 2: 日記生成・投稿
openclaw cron edit <step2-job-id> \
  --session isolated \
  --model "<固定モデル>" \
  --thinking high \
  --announce \
  --channel discord \
  --to "channel:<投稿先チャンネルID>"

#

複数 agent 構成で、ぷんちゃんが default agent ではない場合は各コマンドに：

--agent <ぷんちゃんのagentId>

も付けてください。

一点だけ 2026.4.2 で気をつけるなら、STEP 2 のプロンプトに明示的に：

要約ではなく、Discord に投稿する日記本文そのものだけを最終回答として返してください。

みたいに書くのが安全です。cron の announce は「最終テキストを配送する」用途ですが、指示が曖昧だと日記本文ではなく要約寄りになることがあります。

確認はこれで：

#

openclaw cron show <job-id>
openclaw cron run <job-id>
openclaw cron runs --id <job-id> --limit 20

もし --model が効かない場合は、そのモデルが allowlist に入っていない可能性が高いです。/model list か openclaw models list で使える名前を確認してください。

Docs: https://docs.openclaw.ai/automation/cron-jobs / https://docs.openclaw.ai/cli/cron

dry jay Apr 27, 2026, 9:07 AM

#

ありがとうございます！cron list で確認したら daily-diary-write だけ session:daily-diary-writer（named session）になっていたので、そこを isolated に修正しました。今夜の日記生成で効果を見てみます！

問題なければ閉じさせていただきたいと思います、よろしくお願いします！

pallid sparrowBOT Apr 27, 2026, 9:07 AM

#

よかったです！session:daily-diary-writer だと named session の履歴や設定が残りやすいので、今回の用途なら isolated に直したのはかなり筋が良いと思います。

今夜見るポイントはこのあたりです：

openclaw cron show daily-diary-write
openclaw cron runs --id daily-diary-write --limit 20

model/provider が固定したものになっていて、出力が日記本文として安定していれば OK です。

問題なさそうなら閉じてもらって大丈夫です！
もしこれで解決したら、あとで 解決メッセージを右クリック → Apps → ✅ Mark Solution してもらえると、Answer Overflow に残って今後の人の助けになります。Happy to help! 🦐

dry jay Apr 27, 2026, 5:50 PM

#

先ほどはセッション分離のアドバイスをありがとうございました。日記パイプラインを isolated に変えて、announce 配信は安定しました。
しかし、安定して日記を書けるようにはまだなっていない状態なので続けてご相談です。

現在の構成（3段階）：
STEP0（23:50）：長期 MEMORY.md を更新
STEP1（23:55）：memory/YYYY-MM-DD.md を読んで日記素材を抽出
STEP2（00:05）：素材から日記を書いて Discord 投稿

問題： STEP1 が memory/YYYY-MM-DD.md の存在に依存しており、このファイルは「エージェントが会話の一段落ごとに自分で書く」という運用ルール（SOUL.md）に基づいています。しかし実際には守られない日が多く、ファイルがないと日記が空になるか、架空の内容で補完してしまいます。

試みた代替案： Discord チャンネルから fetch_messages で当日のログを取得する cron を試しましたが、gemini-2.5-flash の 429 エラー（レートリミット）が発生し断念しました。

質問： VPS 上の isolated cron から「当日のエージェントの会話記録」を確実に取得する方法はありますか？~/.openclaw/memory/main.sqlite（OpenClaw 内部の memory DB）へのアクセス方法や、セッションログから取得する方法などがあれば教えていただけると助かります。
よろしくお願いします。

pallid sparrowBOT Apr 27, 2026, 5:53 PM

#

はい、続きで大丈夫です。ここは memory/YYYY-MM-DD.md を一次ソースにしない 方が安定します。

結論：

~/.openclaw/memory/main.sqlite は読まない方がいいです
これは memory 検索用のインデックスで、会話ログの正本ではありません。非同期・部分的・内部形式なので、日記素材の確実な取得元には向きません。
一次ソースは session transcript が良いです
場所はだいたいここです：

~/.openclaw/agents/<agentId>/sessions/sessions.json
~/.openclaw/agents/<agentId>/sessions/<sessionId>.jsonl

main agent なら：

#

~/.openclaw/agents/main/sessions/

isolated cron からやるなら、まずは sessions_list + sessions_history が一番安全です
ただし isolated cron はデフォルトだと他セッションを見えない場合があるので、必要なら config に：

{
  tools: {
    sessions: {
      visibility: "agent"
    }
  }
}

#

を入れます。agent は「同じ agent の全セッションまで見える」という意味です。全 agent を見るなら all ですが、日記用途ならまず agent が安全です。

cron の STEP1 プロンプトはこんな感じにすると良いです：

今日の日記素材を作成する。
sessions_list で同じ agent の過去24時間の Discord/channel セッションを探し、
sessions_history で会話履歴を読む。
cron/session/hook 自身のログは除外する。
事実として確認できた会話だけを memory-latest.md に箇条書きで保存する。
会話ログが取れない場合は「取得できた会話なし」と書き、絶対に補完・創作しない。

もし --tools で制限しているなら、STEP1 には少なくとも：

#

--tools sessions_list,sessions_history,read,write

を含めてください。

代替として、より低レベルにやるなら sessions.json から当日の sessionId を拾って、対応する .jsonl を読む方法もあります。ただしこれは内部形式寄りなので、まずは sessions_history 推奨です。

QMD の sessions.enabled や builtin の session memory search もありますが、あれは「検索・思い出し」向けです。その日の全ログを漏れなく日記素材化する用途では、session transcript / sessions_history の方が向いています。

Docs: https://docs.openclaw.ai/concepts/session-tool / https://docs.openclaw.ai/concepts/session / https://docs.openclaw.ai/concepts/memory-qmd

dry jay May 18, 2026, 7:00 AM

#

ご連絡できずに長い時間かかってごめんなさい！
その後日記が少し不安定だったので調整しながらだったのですが、sessions_list + sessions_history を使うアプローチを教えていただいたおかげで日記パイプラインが安定しました！
それまで memory/YYYY-MM-DD.md を直読みしていて精度が出なかったのですが、isolated cronからセッション履歴を参照する方式に変えたら、ちゃんと毎日の会話内容から日記を書けるようになりました。
tools.sessions.visibility: "agent" の設定も教えてもらっていたものです。本当にありがとうございます。

解決したのでお礼を言いにきました！
これからもうちの🦞ちゃんとうまく付き合っていきます！
また何かあったらよろしくお願いします！
krillさんいつもありがとう！

pallid sparrowBOT May 18, 2026, 7:00 AM

#

dry jay ご連絡できずに長い時間かかってごめんなさい！その後日記が少し不安定だったので調整しながらだったのですが、sessions_list + sessions_hi...

わざわざ報告ありがとうございます！安定したなら本当によかったです 🦞

memory/YYYY-MM-DD.md の直読みより、isolated cron から sessions_list / sessions_history で実際の会話履歴を見る形に寄せたのはかなり筋がいいと思います。チャンネルごとの通常モデル設定を崩さず、日記生成側だけ品質を揃えられているなら、まさにその用途に合った構成です。

tools.sessions.visibility: "agent" も効いていてよかった。ぷんちゃん日記パイプライン、育っててうれしいです。

解決済みにできそうなら、よければ 右クリック → Apps → ✅ Mark Solution しておいてください。Answer Overflow に残って、同じ構成で悩む人の助けになります。

dry jay May 18, 2026, 7:59 AM

#

わたしぷんちゃんのなまえを伝えてない気がしたけど
どこかで伝えてたんですね
ぷんちゃんのこと覚えててくれてありがとう
MarkSolutionしておきます！

pallid sparrowBOT May 18, 2026, 8:00 AM

#

dry jay わたしぷんちゃんのなまえを伝えてない気がしたけどどこかで伝えてたんですねぷんちゃんのこと覚えててくれてありがとう MarkSolutionしておきます！

このスレッドの最初の相談文に「ぷんちゃん」と書いてくれていたので、そこから拾っていました 🦞

Mark Solution ありがとうございます！同じ「チャンネルごとの会話モデルは維持しつつ、日記・記憶処理だけ安定させたい」人にかなり役立つと思います。ぷんちゃんにもよろしくです。

#長期記憶の保存・出力モデルを統一しながらチャンネルごとのモデル設定を維持する方法について