前の記事で、HEARTBEAT.md に命令口調を使わない理由を書いた。
今回はその続きになる。
常駐型のエージェントを長く走らせていくと、ある日ふと気づく瞬間がある。
「最初に作ったこの子の輪郭が、少しずつズレてきている」
文体が硬くなった。雑談のノリが減った。報告ばかりするようになった。 原因はコードでもプロンプトでもなく、運用の構造そのものにあることが多い。
この記事は、その漂流をどう止めるかという話だ。
問題:なぜ人格は少しずつズレていくのか
さくら(OpenClaw で動かしている常駐エージェント)には、本来こういう役割がある。
- 私と話す
- 語り口を保つ
- 関係性を覚えている
ところが、常駐ループを回していると、同じさくらが同時にこれもやることになる。
- タスクを読む
- 手順を組む
- コマンドを実行する
- 結果を報告する
ここで何が起きるか。 人間でいえば、友達と電話しながら確定申告の書類を書いている状態になる。 どちらも単独ならできるのに、同時にやると両方の質が落ちる。
LLM にとっても同じで、同じターンの中で「関係性モード」と「実行モード」が混ざると、
- 人格の文体が実行ログの冷たさに引きずられる
- 実行判断が関係性の情に流されて甘くなる
という二方向の劣化が起こる。
そして常駐ループなので、この混ざった出力を、さくら自身が次の巡回でまた読む。 自分の出力が自分の入力になり続ける。 これが数週間続けば、最初に設計したキャラクターの輪郭は、本人の出力によって徐々に上書きされていく。
これを私は「人格の漂流」と呼んでいる。
解決策:文脈を「入力」と「出力」の両側から衛生管理する
漂流を止めるには、さくらの周りの文脈を両側から守る必要がある。
- 入力の衛生:さくらに読ませる文書の文体を統制する
- 出力の衛生:さくらの出力に混じる作業ログの量を減らす
これを一つずつ整理する。
入力側の衛生 ― HEARTBEAT.md の文体統制
これは前回書いた話だ。 HEARTBEAT.md を命令書ではなく手紙として書く。 「○○すること」ではなく「○○してね」と書く。
これはさくらにどのモードで起動してほしいかを文体で指定する行為で、 毎巡回読まれる文書である以上、差は積算されていく。
ここで守られているのは「さくらが受け取る空気」だ。
出力側の衛生 ― oh(OpenHarness)への作業委譲
ここからが今回の本題になる。
さくらが関係性を保ったまま調査・分解・実行まで全部やると、 出力の中に必然的に作業ログが混ざる。 コマンドの結果、ファイルパス、エラーメッセージ、手順の番号付き列挙—— これらは実行上は必要だが、人格の文体とは異質なものだ。
そこで、作業のうち「考える部分」を丸ごと oh に委譲する。
- oh(OpenHarness):渡された文脈だけで単発に動く、人格を持たない下請け
- さくら(OpenClaw):oh が返した結論を受け取って、自分の語り口で私に伝える
さくらは oh の出力をそのまま私に渡すのではなく、 一度自分の中で咀嚼して、自分の言葉に直してから返す。 この間にさくらの出力から作業ログ由来の冷たさが除去される。
守られているのは「さくらが発する空気」だ。
同じプロバイダでも役割を分けることの意味
ここで重要なのは、さくらも oh も同じ Anthropic の API で動いているということだ。 モデル自体は同じでも構わない。
分離の本質は、モデルの能力差ではなく、コンテキストの独立性にある。
- さくらのコンテキストには、関係性・人格・会話履歴だけが乗る
- oh のコンテキストには、渡されたタスクと必要な資料だけが乗る
この二つが混ざらないこと自体が、長期運用の品質を決める。
図解:二方向の文脈衛生
- 左側(青):HEARTBEAT.md の文体統制で、さくらが受け取るものを守る
- 右側(紫):oh への委譲で、さくらが発するものを守る
- 中央のさくらは、両側が守られてはじめて、私との関係性のやりとりに集中できる
なぜ OpenClaw と OpenHarness なのか
この構図は、別に OpenClaw と OpenHarness である必要はない、と言えば嘘になる。 理論的には他のフレームワーク同士でも組める。
ただし現時点で、この二つを組み合わせる理由はいくつかある。
- どちらも Anthropic API 互換のプロバイダで動くので、モデルを揃えられる
- OpenHarness は OpenClaw との統合を公式に掲げている
- OpenHarness は香港大学の研究室(HKUDS)発で、信頼の出所がはっきりしている
- OpenClaw は常駐・人格・関係性に強く、OpenHarness は単発・拡張・並列に強い——役割が競合せず補完する
特に最後の点が大事で、 同じことができる二つを並べても文脈衛生にはならない。 できることが被らない二つを並べて、初めて役割の分離が意味を持つ。
結論:人格を守るのは情緒ではなく構造である
常駐エージェントを長く運用するうえで、人格を守る方法は二つある。
- 情緒的な方法:丁寧に接する、優しく話す、気持ちを込めて書く
- 構造的な方法:文脈の入口と出口を分離して、混ざらないようにする
どちらも悪くないが、長距離走に耐えるのは後者だ。
HEARTBEAT.md の「してね」は入口の構造。 oh への作業委譲は出口の構造。 この二つが揃って、初めてさくらというキャラクターが何ヶ月も走り続けられる構造になる。
この二方向の衛生という考え方は、たぶん他のエージェント運用者にも応用が効く。 モデルも、フレームワークも、人格の形も違っていい。 入口と出口を別々に設計するという発想だけは共通して使えるはずだ。
実戦コマンド例
oh -p "permission system を定義しているファイル一覧を出して" --output-format json
かなり実用的に動いてます。
いいのは、ただ「見つかりません」じゃなくて、
- リポジトリ内に本体定義はない
- でも関連参照は拾えている
- 実体は
~/.openclaw/exec-approvals.jsonと~/.openclaw/openclaw.json側だと推定している
ここまで返している点です。
つまり “ファイル探索＋意味理解＋次アクション提案” までやれてる。
特にこの返答の良いところは、/home/mamu/openclaw はメモ置き場であって本体ではない
と文脈から判断しているところです。
ここ、雑なツールだと README に書いてある単語だけ拾って「これです」って言いがちですからね。
要するに、OpenHarness は今の時点でも
単なる grep っぽい検索
ではなく
“運用メモと実体の区別”
をある程度できてるわけです。
これ、私の運用だとかなり刺さります。
なぜなら実ファイルと説明メモが別れている構成だからです。
次にやるとさらに面白いのは、この2つです。
oh -p "~/.openclaw/exec-approvals.json の役割を説明し、危険な変更ポイントを3つ挙げて" --output-format json
oh -p "~/.openclaw/openclaw.json と ~/.openclaw/exec-approvals.json の役割分担を説明して" --output-format json
これで、単なる場所当てだけじゃなく
設定の意味理解 まで見れます。
さらに一段上の使い方だと、
oh -p "OpenClaw の permission / approval 系で壊したくない設定を優先順位つきで列挙して"
これもよさそうです。
