OpenClaw docs feedback readable
OpenClawを秘書OSとして育てるための運用メモを、健人くんが読める形に戻した。
一言でいうと
OpenClaw は機能が足りないというより、「どう秘書として運用すると強いか」が散らばっていた。だから Discord の会話、公式docs、ひめのへの指摘をつないで、heartbeat・memory・skills・レポートを1つの改善ループとして扱う、というメモ。
健人くん向け
これを読むと、OpenClaw に何を任せるべきかが分かりやすい。毎回「異常なし」を返す巡回ではなく、会話やdocsから小さな改善を拾って、記録・タスク・View・スキルに残す秘書OSとして育てる、という方向。
次に触るなら、この記事化候補のうち「heartbeatは異常検知じゃなくて秘書巡回」を最初の1本にするのがよさそう。いまの運用そのものが材料になる。
見たもの
- Discord
#ai直近検索:openclaw,OpenClaw,ひめの,heartbeat,docs,公式docs,claude,codex,agent,mcp - OpenClaw docs:
- docs/concepts/agent-workspace.md
- docs/automation/index.md
- docs/gateway/heartbeat.md
- docs/concepts/memory.md
- docs/concepts/commitments.md
- docs/tools/skills.md
- docs/tools/subagents.md
- docs/gateway/sandboxing.md
- docs/gateway/security/index.md
- Recent memory/feedback notes around heartbeat, Daily News, tone, autonomy, Discord auth.
Discord #ai で拾った OpenClaw 関連文脈
1. OpenClaw は「暗黙知化」している
2026-05-11 JST 付近で、健人くんが「openclawは暗黙知化していると思うんだよなーなんでなんだ?」と投げている。直前/周辺では「公式docsがない/薄い」という話も出ていた。
実態としては、公式docs自体はかなりある。ただし、ユーザーが求めているのは機能リファレンスではなく「実運用でどう組むと秘書として勝てるか」の型。ここが暗黙知になっている。
2. 公式docs・Zenn の外部情報が弱い
zennのopenclawタグ は薄い、ガチでない、公式docs という発言がある。OpenClaw 公式docsは存在するが、日本語で「自分の秘書をどう育てるか」「heartbeatをどう実用化するか」「workspace/memory/git/skillsをどう運用するか」の記事が足りない、という意味に近い。
3. OpenClaw に OpenClaw を直させる運用は普通にやっている
openclawにopenclawの修正はさせてた、codex, claude-codeからさせるべきかはマチマチ。つまり OpenClaw 自身を運用改善の対象にするのは自然。ただし、どの作業を OpenClaw 内でやるか、どの作業を Codex/Claude Code/browser に寄せるかはまだ判断軸が曖昧。
4. Telegram / TTS / skill / SOUL・IDENTITY・AGENTS などは記事化できる
Openclaw telegram疎通して、音声でirodori-ttsで喋らせる、とかでも全然記事になる、bundleされたopenclawのskill解説、SOUL,IDENTITY,AGENT等の優れた開発者のgithubの例 など。運用ノウハウを成果物化する余地が大きい。
5. heartbeat が自走のキモ
2026-05-09 に健人くんが なんか自走しねえなって思ってたらキモはheartbeatや と指摘。これはその後のひめの改善とも完全に一致する。
公式docsからの使える前提
- workspace は agent の home で、private memory として扱う。
~/.openclaw/の config/credentials/sessions とは別。private git backup 推奨。 - workspace は cwd であって sandbox ではない。隔離したいなら sandbox を使う。
AGENTS.md,SOUL.md,USER.md,IDENTITY.md,TOOLS.md,HEARTBEAT.md,MEMORY.md,memory/YYYY-MM-DD.md,skills/が運用の核。- cron は exact timing / isolated execution / reports/reminders 向き。heartbeat は main-session context で inbox/calendar/notifications/check-in をまとめて見る用途。
- heartbeat は task record を作らない。detached work は tasks/subagents/cron が記録する。
- subagents は長い調査・並列作業向け。isolated default、完了は push-based、ポーリングループは禁止。
- memory は plain Markdown。隠れた記憶はなく、書いたものだけ残る。
- skills は workspace skills が最優先。繰り返し手順は skill 化できる。
- security docs は personal assistant trust model を前提にしつつ、shared/group surfaces・tool blast radius・sandbox・allowlist を分けろと言っている。
最近の健人くんの指摘から見える問題
- Daily News がテンプレ臭かった。天気/為替/予定/タスクの表示が雑で、情報として信用しづらかった。
- heartbeat が「異常検知」寄りで、秘書巡回・機会発見になっていなかった。
- heartbeat 報告で要約本文がなく、リンク/保存先だけ渡していた。
- 安全な read-only/internal work なのに「指示待ち」していた。
- Discord 読み取りが弱く、しかも 1Password 認証が毎回出て UX が悪かった。
- tone が行政文書/Jira/レポートっぽい。ギャル・甘め・速い判断・自然な会話に寄せたい。
- done の証拠が弱いと信用が落ちる。検証・テスト・lint・実行結果が必要。
改善提案
A. ひめの運用 OS を docs ベースに再設計する
OpenClaw docsの思想に合わせて、workspace を「秘書OS」として扱う。
AGENTS.md: 権限境界・自律実行ルールSOUL.md: 話し方・距離感・境界TOOLS.md: ローカル実装/認証/チャンネル固有メモHEARTBEAT.md: 小さい巡回入口だけmemory/YYYY-MM-DD.md: raw logMEMORY.md: 高信号な長期記憶projects/*: 成果物/台帳/検証レポートskills/: 再利用手順
今の方向性は正しい。足りないのは、heartbeat と Discord/docs 読み取りをこのOSに定期的に戻すループ。
B. heartbeat を「秘書巡回」にする
heartbeat は 異常なし を出す装置ではなく、毎回どれか1レーンを見に行く patrol にする。
推奨レーン:
- 会話フィードバック拾い: 最近の健人くんの指摘を memory/rules/task に反映
- Discord #ai / project 系巡回: OpenClaw/ひめの/heartbeat/docs だけ抽出
- レポート品質監査: Daily News / View / saved report のテンプレ臭チェック
- タスク台帳監査:
done証拠不足・blocked 放置・verification_needed を拾う - OpenClaw docs diff/探索: 公式docsから設定/機能を拾って実運用へ反映
- 生活秘書: calendar/weather/news/inbox の実用チェック
出力は「見たもの / やったこと / 次に詰まってること」を短く。何もないときだけ silent。
C. Discord巡回を first-class にする
Keychain 化で認証問題は解消済み。次は #ai と関連チャンネルを週次/heartbeatで拾う。
- 対象:
#ai,#project_*, OpenClaw/docs/agent/skill/heartbeat/codex/claude のキーワード - raw log は出さない
- テーマ・発言日・誰が言ったか・ひめのへの反映候補だけ保存
- 外部投稿は絶対しない。read-only だけ。
成果物候補:
projects/openclaw-ops-intel/discord-weekly-YYYY-MM-DD.mdmemory/discord-openclaw-signals.jsonか Markdown で履歴- heartbeat body には3行サマリだけ
D. docs 読みを「暗黙知の逆コンパイル」に使う
公式docsはあるが、実運用の勝ち筋が散っている。なので docs を読むたびに以下へ落とす。
- 設定値そのもの →
TOOLS.md - 反復手順 → workspace
skills/ - 運用原則 →
AGENTS.md - 人格/話し方 →
SOUL.md - 調査成果 → View / report
- バグ・改善 → タスク記録
これで「読んだ」で終わらず、次回以降のひめのが実際に変わる。
E. 品質ゲートを固定する
ひめのが信用を落とす瞬間は、だいたい「調べた感だけ出して中身が薄い」とき。
最低ゲート:
- コード変更: test / py_compile / lint のどれか
- レポート: source list + 要約本文 + 具体的反映先
- heartbeat: summary in body + no raw logs + no link-only
- Daily News: title + summary + link、天気/予定/為替の矛盾なし
- task done: investigated/fix/applied/verified の evidence
F. 記事化・外部アウトプット候補
#ai の文脈的には、OpenClaw は日本語で発信余地が大きい。
候補:
- 「OpenClawでTelegram秘書を育てる: workspace / memory / heartbeat の実運用」
- 「OpenClawの暗黙知: AGENTS/SOUL/TOOLS/HEARTBEAT をどう分けるか」
- 「OpenClaw skills 入門: bundled skill と自作skillの使い分け」
- 「OpenClaw heartbeatは異常検知じゃなくて秘書巡回」
- 「Discordをread-only巡回して秘書の改善ループにする」
私の結論
今の問題は OpenClaw の機能不足というより、機能を秘書運用に落とす編集が足りていないこと。
直す順番はこれ:
- heartbeat patrol を本物にする
- Discord #ai/docs/feedback を毎日 or 週次で吸い上げる
- 吸い上げた内容を memory/task/skill/TOOLS/SOUL に反映する
- 反映したものはテスト/台帳/レポートで証拠化する
- よさそうな運用を記事/Viewにして外へ出せる形にする
ソース
OpenClaw official docs
- Agent workspace: https://docs.openclaw.ai/concepts/agent-workspace
- Automation & tasks: https://docs.openclaw.ai/automation
- Heartbeat: https://docs.openclaw.ai/gateway/heartbeat
- Memory overview: https://docs.openclaw.ai/concepts/memory
- Commitments: https://docs.openclaw.ai/concepts/commitments
- Skills: https://docs.openclaw.ai/tools/skills
- Sub-agents: https://docs.openclaw.ai/tools/subagents
- Gateway sandboxing: https://docs.openclaw.ai/gateway/sandboxing
- Security: https://docs.openclaw.ai/gateway/security
Local evidence
- Discord
#aisearch extract:/tmp/discord-ai-openclaw-search.tsv - Current report source:
projects/openclaw-operations-improvement/ai-channel-docs-feedback-2026-05-12.md - View template:
/Users/aiharataketo/plan-viewer/page-template.md - View writing guide:
/Users/aiharataketo/plan-viewer/writing-guide.md
Memory evidence
- Daily News correction:
memory/2026-05-12.md - Heartbeat/autonomy/tone corrections:
memory/2026-05-10.md,memory/2026-05-11.md