OpenClaw が「永遠に起きている」ことを要求する理由
OpenClaw のコアは長時間稼働する Node.js プロセスである Gateway です。Channel Adapters（Telegram・WhatsApp・Discord などのチャンネルからのメッセージを受信）・Session コンテキスト・Agent Runtime・heartbeat スケジューラーを同時に管理します。Gateway プロセスが終了すると、進行中のすべての Agent タスクが中断し、heartbeat タスクもトリガーされなくなります。
ローカル Mac で実行する場合、以下の 5 種類のイベントが直接 Gateway を中断させます：
蓋を閉じてのスリープ：macOS はデフォルトで蓋を閉じるとスリープに入り、Node.js プロセスが一時停止されます。再度開いたときに heartbeat タスクが積み上がっており、正常なスケジューリングを回復するには再起動が必要です。
システム更新による再起動：macOS の自動更新が夜間に完了すると再起動を促します。無人の場合、次回起動まで Gateway はオフラインのままです。
Keychain と権限ポップアップ：シェルコマンドを実行する際に macOS が認証ウィンドウを表示することがあります。無人の場合、ポップアップが対話フロー全体を中断させます。
マルチユーザーコンテキストの汚染：Mac を共用する場合、異なるユーザーのパス・環境変数・API キーが上書きされるリスクがあり、スキルの実行が失敗します。
SLA 保証なし：開発機はローカルデバッグも担当するため、CPU/メモリの競合が予測不能です。チームの納品基準に組み込もうとしても、ローカル Mac は契約上の根拠にはなりません。
上記 5 点は同じ根本原因を指しています：ローカル Mac はインタラクティブな使用のために設計されており、長時間無人稼働プロセスのために最適化されていません。
ローカル Mac vs KVMNODE クラウドノード：安定性比較
OpenClaw をクラウドノードに移行しても、ローカルコントロール感を失うわけではありません——データ・設定・スキルスクリプトは引き続きお客様のリポジトリに保存されます。クラウドノードは永遠に起きている実行環境を提供するだけです。
| 比較項目 | ローカル Mac | KVMNODE クラウドノード |
|---|---|---|
| プロセス可用性 | スリープ・更新・停電の影響を受ける | 7×24 オンライン、pm2 自動再起動 |
| ポップアップ干渉 | Keychain ポップアップには手動確認が必要 | 初回設定後は権限が固定され、GUI ポップアップなし |
| マルチユーザー隔離 | パスとキーの汚染リスク | 独立ノード、単一ユーザー環境、監査が明確 |
| パフォーマンスの安定性 | ローカルタスクとリソースを競合 | CPU/メモリを専有、プリエンプションリスクなし |
| リージョンの柔軟性 | 物理的な位置が固定 | アジア・欧州・アメリカのマルチリージョンノードを選択可能 |
| コスト形態 | 資本支出 + 電気代 + 運用コスト | 日/月単位の柔軟な課金、廃棄コストなし |
OpenClaw をクラウドノードに移行することで、「今日 Gateway が動いているか」を日々のチェックリストから永久に削除できます。
KVMNODE コンソールでメインユーザークラスターに合わせてリージョンを選択することで、エントリーと実行端を同じ地理的フェンスに収束させ、SLO を書く際に明確な RTT ベースラインが得られます。
ユースケース × デプロイモード：クラウドへの移行が必要な場面
すべてのユーザーが即座にクラウドへ移行する必要はありません——たまにスクリプトを実行する程度であれば、ローカル Mac で十分です。以下のマトリックスで使用強度に基づいて判断してください：
| ユースケース | 推奨モード | クラウド移行の判断基準 |
|---|---|---|
| 個人 PoC / 週末の実験 | ローカル Mac | 中断は許容可能、SLA 要件なし |
| 個人本番（朝のレポート/監視/自動返信） | クラウドノード · 月単位 | heartbeat は 7×24 のトリガーが必要 |
| 小チーム共有 Agent（2〜10 人） | クラウドノード · 月単位 | 複数人の共用でパス汚染リスクが高い |
| 企業自動化 / 外部への可用性保証 | クラウドノード · 長期 | SLA は契約に明記が必要、コンプライアンス監査が必須 |
| クロスタイムゾーンチーム | マルチノード · メインリンクと同リージョン | Agent のレイテンシがユーザー体験に直接影響 |
heartbeat_頻度 = 1時間あたりのトリガー回数（1日 4 回以上はクラウド移行を推奨） 中断_許容度 = low | medium | high（low = クラウド移行必須） チーム規模 = 1 | 2-10 | 10+（2人以上での共用ノードは専有を推奨） 結論 = 上記のいずれかが該当 → KVMNODE クラウドノードを優先検討
クラウド移行前の準備：すでに 100 以上の AgentSkills を実行中、または複数の Channel Adapter が接続されている場合、移行前に現在のスキルディレクトリの絶対パスと .env 設定を記録しておき、新しいノードに移行する際にそのまま再利用してください。
KVMNODE ノードに OpenClaw Gateway をデプロイする 6 ステップ
以下の手順は運用担当者に直接渡せます。チームに Ansible や Terraform がある場合は、ステップ 2・4・5 をべき等タスクに置き換えることができますが、受け入れ基準は「pm2 永続化の有効化 + heartbeat クローズドループログ」とします。
ノードリージョンを選択して SSH 接続を確立：KVMNODE コンソールで主要ユーザーまたは Webhook ソースに最も近いノードを選択し、ローカル ~/.ssh/config を設定してワンクリックのパスワードなしログインを実現します。
実行環境の確認：ログイン後に node -v（≥ 18.x が必要）と npm -v を実行し、ノードが LLM API エンドポイント（OpenAI / Anthropic / Google）にアクセスできることを確認します。
リポジトリをクローンして依存関係をインストール：実行：git clone https://github.com/OpenClawHQ/openclaw.git && cd openclaw && npm ciを明確に説明します。
設定ファイル（.env と YAML）を移行：scp で .env（LLM API キー・リスニングポート）と config/*.yaml を転送します。コードリポジトリへの平文書き込みは絶対に禁止。
プロセスデーモン（pm2）の設定：実行：npm install -g pm2 && pm2 start npm --name "openclaw-gw" -- start && pm2 save && pm2 startupを明確に説明します。
受け入れ基準を書き込み heartbeat を検証：手動 heartbeat タスクを 1 回トリガーし、ログに「実行→観察→メモリ書き込み」の完全なループが現れることを確認し、重要なパラメーターを Runbook に記録します。
本番環境に必ず記録する 3 つの設定基準
プロセスデーモンの再起動ポリシー：max_restarts: 10 と min_uptime: 5000 を設定し、上限に達したら停止して pm2 webhook でアラートを送信します。クラッシュループが本当の問題を隠すのを防ぎます。
ポート隔離とアクセス制御：ダッシュボードはデフォルトでポート 3000 をリッスンし、パブリックネットワークに公開してはいけません。SSH トンネル経由でアクセスし（ssh -L 3000:localhost:3000 your-node）、ファイアウォールでポート 3000 のインバウンドを禁止します。
AgentSkills のパス権限：サードパーティのスキルは独立したディレクトリに配置し、低権限ユーザーで実行して、OpenClaw プロセスがアクセスできるディレクトリの範囲を正確に制限します。
セキュリティ警告：OpenClaw はシステムレベルのアクセス権限（ファイルシステム + シェルコマンド）を持っています。本番ノードでは絶対に root ユーザーで Gateway を実行せず、出所不明のサードパーティ AgentSkills もインストールしないでください。
ローカル Mac でスリープ戦略を何度もデバッグするより、KVMNODE の専有クラウドノード 1 台で「今日 Gateway が動いているか」を日々のチェックリストから永久に削除できます。KVMNODE 高性能 VPS はより安定したスタート地点です：専有リソース・7×24 オンライン・日/月単位の柔軟な課金。