2026 常時稼働リモート Mac 上の OpenClaw：
launchd／systemd の再起動、ログとディスク、Gateway ハングの切り分け

無人 OpenClaw で陥りやすい 6 つの思い込み（「プロセスが動いている」≠ 健全）

1. launchd／systemd の「読み込み済み」を「準備完了」と同一視する：クラッシュループでも loaded のままです。連続稼働時間と直近の終了コードで判断し、一覧出力だけでは決めないでください。
2. コンテナ内だけいじってホストのバインド権限を忘れる：コンテナ内では書けるがホスト側ローテーションから見えないパスは、二重書き込みやローテーション破壊の原因になります。
3. リバースプロキシと Gateway のループバック差を無視する：コントロール UI の静的資産は読み込める一方、コールバックは公開ホスト名へ飛びます。127.0.0.1 だけを TLS 終端越しに curl するプローブは「メトリクスは緑、利用者は赤」になり得ます。TLS リバースプロキシの記事と併読してください。
4. 429／タイムアウトをすべてベンダー起因にする：無人のリトライ嵐は自己増幅します。プロバイダのルーティング指針に沿ってバックオフやサーキットブレーカを足してください。
5. デバッグログをマスキングなしのままにする：トークン、Webhook、個人情報が集中ログに流れると、ディスクが満杯になる前にコンプライアンスリスクが膨らみます。SIEM へ送る前は許可リスト型のフィールド設計を優先してください。
6. クラウド Mac がノート PC と同じ電源方針だと思う：スリープ、クラムシェル、メンテナンス窓が長寿命接続を落とします。「寝ないで」と頼むのではなく、電源とデーモン再起動を文書化してください。

次に「プロセスが見えること」と「メッセージの往復」を分離し、macOS と Linux のスーパーバイザに落とし込みます。

三層切り分け：ホストプロセス、コンテナネットワーク、エッジプロキシ

第 1 層（ホストプロセス）では、Gateway バイナリ／Node プロセスが正しいユーザー下で生き残り、意図したインタフェースにバインドし、現行のトークンとデータディレクトリを見えているかを問います。

第 2 層（コンテナ）では compose ネットワーク、公開ポート、ボリュームに絞ります。ホストの curl とコンテナ内の curl が食い違うときは、まず Docker ネットワーク切り分けチェックリストへ戻ります。

第 3 層（プロキシ）では TLS、WebSocket Upgrade、パス剥がし、タイムアウトを扱います。エッジの 502／握手問題は Nginx／Caddy チェックリストに従います。

リモート Mac では第 3 層が SSH トンネルやプライベート DNS の背後にあることが多く、「localhost の curl が通る」は「公開コールバックが通る」と同義ではありません。Slack／Telegram 型のチャネルでは、チャネル切り分けチェックリストで OAuth スコープも検証してください。

Gateway が CI ビルドや cron と同居するときは、ディスク I／O と CPU の奪い合いに注意します。ビルドのスパイクがログの fsync や TLS 握手を遅らせ、断続的タイムアウトとして表面化します。ビルドキャッシュと Gateway データパスを分けて監視し、双方の書き込み率でアラートを張れば、インフラの揺らぎをモデル品質の劣化と誤認しにくくなります。

macOS launchd と Linux systemd：再起動方針で固定すべき項目

launchd では UserName、WorkingDirectory、標準出力／標準エラー出力のパス、KeepAlive と組み合わせた ThrottleInterval を明示し、クラッシュ嵐でホストを占有させないようにします。

systemd では Restart=on-failure と RestartSec を対にし、EnvironmentFile と LimitNOFILE を文書化します。いずれも SSH セッション終了後もサービスを維持できることが、無人運用と対話デバッグの決定的な違いです。

Docker で Gateway を包む場合、launchd／systemd が直接 Node を見るのではなく、多くは docker compose up -d（またはラッパー）を監督します。健全性判定は compose か、Kubernetes ヘルスチェックの記事で述べる HTTP プローブへ寄せ、フリーズしたコンテナをホストが「健康」と誤認しないようにしてください。

ログ量、ローテーション、マスキング（シークレット方針と同じ境界）

ログ、設定、データのパスはマウントを分け、バックアップとクォータを独立させます。ローテーションはプレーンテキストのホストログと Docker の json-file ドライバの両方を対象にしてください。コンテナを消しても巨大なレイヤがディスクに残ることがあります。最低限、Bearer トークン、Webhook シークレット、メールアドレス、チャネル ID の末尾をマスキングし、SIEM へ送る前は脆弱なブラックリスト正規表現より許可リスト型のフィールドを優先します。

インストール後 doctor の記事と組み合わせ、doctor の要約だけをチケットに貼り、フル環境ダンプをチャットに流さないでください。

集中ログ基盤では OpenClaw 専用の保持期間とサンプリング方針を置き、インシデント中だけサンプリングを上げ、変更窓の後に自動で元へ戻し、「一時デバッグ」が常態化しないようにします。

六ステップの自己修復 Runbook（アラートからポストモーテムまで）

1. 変更面を凍結する：イメージタグ、compose ファイルのハッシュ、直近 3 件のプロキシ証明書／DNS 変更を記録します。
2. 三層を一度ずつプローブする：ホストのリスナ、コンテナ内の上流、公開ホスト名への curl／WebSocket（タイムスタンプ付き）です。
3. チャネル状態を確認する：文書化された status／probe コマンドを使い、HTTP 200 だけに頼りません。
4. ディスクとログ増加を見る：du を 24 時間前と比較し、ログバーストを検知します。
5. 境界のついた再起動：まず compose restart、必要ならホスト再起動。終了コードを取得します。
6. ポストモーテムの型：根本原因を設定／ネットワーク／ベンダー／リソースに分類し、アラートを再調整します。

オンコール向け指標（定量化できる 3 つ）

1. 連続稼働ウィンドウ：7 日間で人手なしに何時間連続で回せたか。契約 SLA を下回るならディスクや CPU を増やします。
2. 1 日あたりのログ増加 GB：絶対量と週次トレンドを報告し、14 日先まで容量を見通します。
3. 偽「ハング」率：Gateway を再起動しただけで消えるチケットの割合。高い場合は切り分け順が誤っており、モデル対チャネルの証拠を先に集めるべきです。

doctor、Docker、プロキシ、Kubernetes の各記事との役割分担

本稿は長期監督、ログ／ディスク衛生、リモート Mac 上のハング切り分け順を扱います。doctor の記事はインストール後検証、Docker ネットワークチェックリストはコンテナ経路、リバースプロキシの記事は TLS／WebSocket、ヘルスプローブの記事はオーケストレータの意味論です。Runbook の重複を避けるため、インストール → ネットワーク → エッジ → 定常運用の順で文書化してください。

ノート PC 単体ホストが長寿命 OpenClaw に向かない理由

スリープスケジュール、パッチ周期、ローミング回線は SLA を文書化しにくく、ディスクと帯域を日常作業と共有するとハングやログ嵐の切り分けが難しくなります。契約に基づく専用リモート Macなら、電源方針、ディスク階層、出口を個人の習慣から切り離せます。

CI テスターと同じリージョン、低いスリープ確率、予測可能なディスクと帯域が OpenClaw と自動化に必要なら、MACCOME のクラウド Mac は落ち着いた実行面になります。まず Mac mini レンタル料金を確認し、シンガポール、東京、ソウル、香港、米国東海岸、米国西海岸の地域ページから注文へ進めます。接続手順は ヘルプセンターを参照してください。