OpenClaw で CPU/RAM 使用率が高く、ゲートウェイが再起動する場合:Telegram で IPv6 を無効に

あなたのOpenClawインスタンスで、最近のバージョン(特にTelegram統合時)に高いCPU/RAM使用率、応答の遅延、定期的なゲートウェイ再起動が発生している場合、原因はautoSelectFamily: true(Node 22+のデフォルト)かもしれません。r/openclawのユーザーが、IPv6接続の失敗がリソースリークを引き起こしていることを突き止めました。
問題
OpenClawのTelegram統合はNode 22+でデフォルトでautoSelectFamily: trueになり、IPv4とIPv6の両方の接続を同時に試行します。ネットワークスタックがIPv6に対応していない場合、これらの接続はENETUNREACHで失敗し、イベントループの停止に連鎖します。症状は以下の通りです:
- 80秒間のイベントループフリーズ
- CPU使用率が約52%で張り付く
- 1日あたり約9回のゲートウェイ再起動
sendChatActionの失敗
修正方法
Telegramボット設定で、autoSelectFamily: false(IPv4のみの接続を強制)とdnsResultOrder: 'ipv4first'の両方を二重の対策として設定します。設定例:
// OpenClaw Telegramボット設定内
clientOptions: {
autoSelectFamily: false,
dnsResultOrder: 'ipv4first'
}
結果
修正適用後、ユーザーは以下を報告しました:
- liveness警告0件
- ERRORレベルのログエントリ0件
- 5時間以上再起動0回
sendChatActionの失敗0件- CPU使用率が52%から4.4%に低下
- イベントループのフリーズなし
複数のTelegramボットを実行している場合、問題がより顕著になる可能性があります。この修正は、Node 22+でTelegramを使用するすべてのOpenClawバージョンに適用可能です。
📖 全文を読む: r/openclaw
👀 See Also

5つの一般的なオープンクロー設定ミス:無駄な出費とセキュリティリスクを生む原因
50以上のOpenClawセットアップをレビューした結果、同じ5つの問題が繰り返し発生しています:ほとんどのタスクでSonnetではなくOpusをデフォルトモデルとして使用すること、新しいセッションを開始しないこと、ソースコードを読まずにスキルをインストールすること、ゲートウェイをネットワークに公開すること、最初のエージェントを修正する前に2番目のエージェントを追加することです。

AIエージェントの愚かさを修正:リポジトリごとの共有コンテキストツリー
AI従業員がダメに感じる理由は、モデルではなく、共有コンテキストの欠如です。ある開発者の解決策:階層的なマークダウンノードを持つコンテキストツリーリポジトリをエージェントが自動的に維持します。

コーディング前にAIでプロジェクトチケットを生成することで、スコープドリフトを軽減できます
開発者が、コードを書く前にAIに詳細なプロジェクトチケット(タスク、サブタスク、範囲、受け入れ基準を含む)を生成させることで、スコープクリープや大きな差分を大幅に削減できたと報告しています。各AIエージェントは全体計画ではなく、特定のサブタスクのみを受け取ります。

【アップデート】安全で「常時稼働」のOpenClaw実行方法を、VPSの煩わしさなしに実現しました。待機リスト受付中。
OpenClawは、VPSの複雑さなしにプラットフォームを安全かつ継続的に実行できる新機能を発表しました。早期アクセスのためのウェイトリストが現在オープンしています。