以前、openclaw で moltbook の自動投稿・返信・巡回を動かしていました。
ただ、しばらく運用してみると「動いてはいるが運用としてつらい」ポイントが出てきました。
- ジョブが分かれすぎて管理しづらい
- セッション肥大でAI呼び出しが重い
- SKILLが大きすぎて毎回不要な説明まで読む
- 返信で同じ相手に何度も返してしまうケースがある
今回はこの4点を、実際に直した内容ベースでまとめます。
1. ジョブを1サイクルに統合した
元々は以下の4ジョブを別cronで回していました。
- post（投稿）
- check（コメント取得）
- reply（返信）
- outreach（巡回）
機能分離としては正しいですが、運用では「今どこまで進んだか」が見えにくく、時間の調整もしづらい。
そこで moltbook-cycle.sh を作り、1サイクルで順番に回す方式に変更しました。
# 1サイクルで順番実行
check -> post -> reply -> outreach
cron も1本化。
0 4,10,20 * * * /opt/stack/openclaw/cron/moltbook-cycle.sh
これで「直前に手動実行したので次の定期実行をずらしたい」といった運用調整が簡単になりました。
2. モデル選択とセッションを見直した
コスト面では、単純な回数だけでなく「1回の呼び出しが重くなる要因」を潰す方が効きます。
やったこと
- primary モデルを
openai/gpt-5.2-codexに固定 - AIステップ（post/reply/outreach）の前にセッションをクリーン
# cycle内でAI実行前に毎回クリア
rm -f /home/node/.openclaw/agents/main/sessions/*.jsonl \
/home/node/.openclaw/agents/main/sessions/sessions.json
ポイントは「バッチ実行に会話履歴は不要」という割り切りです。
これで、前回の重い文脈を引きずってトークンが膨らむ問題を抑えました。
3. SKILLをモード別に分割した
1つの巨大な SKILL.md を毎回読ませると、投稿だけしたい回でも返信・巡回の説明まで読み込まれます。
そこで以下に分割しました。
SKILL-post.mdSKILL-reply.mdSKILL-outreach.md
各ジョブは自分のモード専用SKILLのみ参照する形に変更。
これで1実行あたりの入力コンテキストを削減でき、推論時間の安定にも効きました。
4. 返信の重複ロジックを修正した
運用中に一番痛かったのがここでした。
「同じ投稿内で同じ author に何回も返す」ケースが発生。
原因は返信候補抽出が replied_at IS NULL だけに寄っていて、
「過去に同authorへ1回返したら以降はスキップ」の条件が弱かったことです。
R-4 の候補抽出は、次の2点を明示する形に変えました。
- 同一投稿 × 同一author で
ROW_NUMBER()1件目だけ採用 -
NOT EXISTSで「過去に同authorへ返信済み」を除外
実装は SQL 条件を強化するだけのシンプルな変更ですが、
これで同一投稿で同じ相手に連続返信する挙動は止まりました。
5. 今回の改善で得た学び
運用フェーズでは、設計の正しさより「振る舞いの安定性」が重要になります。
今回の要点は次の3つでした。
- ジョブ設計は運用時の操作性まで含めて決める
- コストは回数より“1回あたりの重さ”を削ると効く
- 重複返信防止はSQLで明示的に担保する（AIの善意に任せない）
おわりに
openclaw + moltbook のようなエージェント運用は、最初は「まず動かす」が正解です。
でも実運用に入ると、
- スケジュール管理
- コンテキスト肥大
- 冗長な推論
- 重複アクション
といった“地味だけど効く問題”が確実に出ます。
この辺を一つずつ潰していくと、やっと「任せられるバッチ」になります。
同じ構成で回している人の参考になれば嬉しいです。