OpenClawユーザー、ツールのアーキテクチャと安全性のギャップを批判

r/openclawのユーザーは、OpenClawを「この種のエージェント自動化をこれほど手軽に実現する唯一のツール」と評しながらも、試用後に幻滅を表明し、その体験を不十分に保守されたSAPシステムに例えています。

アーキテクチャ上の批判

ユーザーは、OpenClawが不十分であると指摘する主な4つの領域を特定しています：

• ファイルおよび設定変更のための制御層： ユーザーは、ファイル操作や設定変更をLLMが直接実行すべきではないと主張しています。彼らは、「その日のモデルの気分」に依存するのではなく、ユーザーに事前に確認したり事後に通知したりするようなルールに基づいて決定する、決定論的な中間層を提唱しています。
• 保護されたカーネル： ユーザーは、LLMが変更できないコア部分が必要だと提案しています。これには、保護対象として定義された設定ファイルや重要なシステムファイルが含まれます。
• コンテキスト管理と委任： この批判は、リクエストタイプに基づいた真のコンテキスト管理が欠如していることを指摘しています。現在は、「実際に必要なものに関係なく、すべてのリクエストが同じコンテキストで溢れかえり、膨大な量のトークンを浪費しています。」ユーザーは、コンテキストはケースバイケースで構築されるべきだと提案しています。また、コーディングタスクは同じエージェント内で処理されるのではなく、専用のコーディングLLMにCLI経由で委任されるべきだと示唆しています。
• バージョン管理、テスト、設定可能性： ユーザーは、組み込みのgit統合の欠如、品質ゲートの不在、およびシステムの深部にまで到達するツールとしては設定項目が少なすぎることを指摘しています。これらはすべて後から追加できるが、デフォルトでは存在しないと述べています。

コミュニティと開発パターン

ユーザーはERPシステムとの類似性を指摘し、現在の選択肢は「ドキュメントのないずさんなコミュニティプラグイン」を通じて機能を拡張するか、自分自身で「仕様書もドキュメントもテストもなしに」機能を構築するかのどちらかだと述べています。どちらのアプローチも、「そのまま本番環境にリリースされる」と指摘しています。

これらの批判にもかかわらず、ユーザーは「現時点では、同じ機能を同じくらい簡単に、しかもより良い方法で提供する代替案は見当たらない」と結論付けています。