13週間OpenClawを日常使いして：良かった点、壊れた点、今も悩む点

Raspberry Pi上でOpenClawをプライマリな個人エージェントシステムとして13週間運用し、Telegramチャット、長期記憶、cronジョブ、サブエージェント、リサーチワークフロー、外部APIを処理してきたr/openclawユーザーが、詳細な総括を投稿しました。結論：OpenClawはインフラとして扱えるほど強力だが、忍耐、ログ、バックアップ、そして奇妙なエッジケースのデバッグを厭わない覚悟が必要なほどに、まだ荒削りである。

うまくいった点

• ワークフローの階層化。 エージェントはメッセージング、ファイル、cron、API、メモリ、ツールの間に位置する。cronシステムは真に有用で、定期的なジョブが収集、処理、要約、通知、フォローアップワークフローのトリガーを行う。一度調整すれば、良い意味で退屈になる。
• メモリ——キュレーションされていれば。 OpenClawは決定、プロジェクト状態、好み、ミス、以前の修正を記憶できる。しかし、生の断片をすべて長期記憶に入れると、スラッジと化す。クリーンアップとプロジェクト固有のメモリファイルにより、真の運用レイヤーとなる。
• 境界のあるタスクのためのサブエージェント。 最も有用なパターン：人間が方向性を決め、メインエージェントが調整し、サブエージェントが範囲限定の分析や実装を行い、メインエージェントが検証する。コンテキストが曖昧だったり、モデル/設定のルーティングが明示的でない場合は、有用性が低下する。
• 継続性。 最大の成功は単一の機能ではなく、システムが運用上のメモリ、スケジュールされたチェック、定期的な分析、技術的デバッグ、設定レビュー、小さなコード変更、構造化されたフォローアップを日常的に処理できるようになったことだ。

壊れた、または煩わしかった点

• モデル/設定の問題。 初期のローカル/小モデル（例：4kコンテキスト）では、OpenClawのシステムプロンプトとツールを処理できなかった。「アシスタントターン失敗」エラーは、RAMではなくAPIキー/設定の問題に起因することが多かった。
• cronとサブエージェントの相互作用のギャップ。 スケジュールされたワークフローがサブエージェントを起動し、正しく作業を行ったが、エージェント間の履歴が無効だったため、親が子の出力を読み取れなかった。修正：子が結果を直接書き込むように再設計（write --file）、親の読み取りに依存しない。
• シェルの引用。 JSONをシェルコマンドに渡すと、アポストロフィやネストされた引用で壊れた。修正：JSONを一時ファイルに書き込み、--fileで渡す。
• 更新のドリフト。 OpenClawの更新により、Piの起動パフォーマンスとメモリ負荷が改善されたが、更新日には注意が必要だった——設定のドリフト、ACPコマンドのドリフト、ドキュメントのドリフト。すべてが問題ないと信じるのではなく、実際に何が変わったかを確認する必要があった。
• サブエージェントのモデルオーバーライド。 デフォルトが常に尊重されるわけではなかった。現在はモデル/エージェントIDを明示的に渡している。
• ACPの信頼性の低さ。 OpenClaw経由のClaude ACPが内部ランタイムエラーで失敗。直接のACP/CLIパスは機能した。
• シークレット/設定の衛生。 OpenClawは構造化されたSecretRefをサポートするが、古いconfig/auth-profileファイルに平文のシークレットが残っている可能性がある。安全に移行するには、バックアップ、スキーマチェック、ロールバック計画が必要。
• Piのリソース圧力。 長時間実行されるClaude/Codexプロセス、cron、メモリアーティファクトが蓄積される。クリーンアップルーチンを追加。再生可能な約1.6GBのブロートに成長した死んだプロジェクトをアーカイブした。

こんな人におすすめ

OpenClawを個人エージェントシステムとして運用している開発者、特に制約のあるハードウェア上で、現実世界の痛点と実用的な回避策を正確に知りたい方。