2026 OpenClaw デーモンと起動自動化：VNC リモート Mac での launchd 安定運用チェックリスト

2026年3月25日 · 約12分

手動起動から一歩進み、再接続・再起動後も OpenClaw を戻すには macOS の launchd が定石です。本稿は VNC リモート Mac 上での運用を想定し、痛み・方式比較・plist の型・launchctl bootstrap・ログ確認・権限は VNC で、という順で整理します。バイナリは which openclaw、サブコマンドはインストール済みバージョンの公式情報に合わせてください。

レンタル環境では「自分専用に見えるが実は同居している」ケースもあるため、plist のパーミッションと ProgramArguments の改ざん耐性を意識してください。秘密情報を plist に直書きすると、他アカウントやバックアップ経由で漏れやすくなります。運用手順を 5〜10 行の runbook にしておくと、深夜インシデントでパニックが減ります。

デーモンがないと起きること

SSH セッション終了でプロセスが落ちる（tmux でも再起動方針は別途）。
スリープや電源方針でゲートウェイポートが消える。
キーチェーン等の初回確認が GUI 待ちで止まる。
標準出力/エラーをファイルに分けないと障害分析が遅い。
二重起動やポート競合で不安定になる。

方式の比較

方法	向く場面	自動起動	クラッシュ後	監査性
前臺	デバッグ	×	×	低
tmux	中期的に繋ぐ	要工夫	手動	中
cron	定期	△	常駐ゲート向きではない	中
LaunchAgent	ログイン後の常駐	○	KeepAlive は慎重に	高

KeepAlive は設定ミス時に再起動嵐になり得ます。先にログで安定を確認してから慎重に。

実装の流れ（6 ステップ）

1) 実パスと引数を確定（例: /opt/homebrew/bin/openclaw + gateway 等）。

2) ~/Library/LaunchAgents/com.example.openclaw.plist を作成。

3) Label / ProgramArguments / RunAtLoad / StandardOutPath / StandardErrorPath を記述。

4) plutil -lint で XML 検証。

5) launchctl bootstrap gui/$(id -u) ~/Library/LaunchAgents/com.example.openclaw.plist（環境に合わせる）。

6) ポート待受・err ログ・再起動テスト。更新時は bootout 後に再登録。

<?xml version="1.0" encoding="UTF-8"?>
<plist version="1.0"><dict>
<key>Label</key><string>com.example.openclaw</string>
<key>ProgramArguments</key><array>
<string>/opt/homebrew/bin/openclaw</string><string>gateway</string>
</array>
<key>RunAtLoad</key><true/>
<key>StandardOutPath</key><string>/tmp/openclaw.out.log</string>
<key>StandardErrorPath</key><string>/tmp/openclaw.err.log</string>
</dict></plist>

秘密情報は plist に直書きせず、キーチェーンや権限付き設定へ。EnvironmentVariables で PATH だけ足すのは一般的。

WorkingDirectory とログパスの現実的な置き場所

OpenClaw が相対パスで設定ファイルを探すなら WorkingDirectory を明示し、手元で試したときと同じカレントに揃えます。ログを /tmp に置くと再起動で消えることがあるので、長期運用なら ~/Logs/openclaw/ のようにユーザー配下のディレクトリを作り、ローテーション方針（サイズ上限や週次削除）を決めておくと安全です。

KeepAlive と再起動嵐の避け方

トークン欠落などで即終了する状態に KeepAlive を付けると、短時間に何度も再起動し stderr が埋め尽くされます。まずは KeepAlive なしで stderr を読み、安定したら必要に応じて Apple ドキュメントにある間隔制御を検討してください。

launchctl は成功でもサービスが死んでいるとき

アクセシビリティ、フルディスクアクセス、ネットワークの初回ダイアログが隠れているだけ、というケースはリモート Mac で頻発します。SSH の出力だけ見ていても気づけないので、VNC で設定アプリを開いて確認するのが最短です。

ロールバック手順（メモ用）

stderr 末尾 200 行と plist をチケットに貼る。
launchctl bootout gui/$(id -u) ~/Library/LaunchAgents/com.example.openclaw.plist（ドメインは環境に合わせる）。
VNC で手動起動し、動作 argv と plist を diff。
plutil -lint とレビュー後に再 bootstrap。

アップグレード当日の追加チェック

メジャー/マイナー更新では、バイナリパスやデフォルトの設定ディレクトリが変わることがあります。リリースノートを読んだら、① VNC で一度だけ対話実行して新しいウィザードや同意画面を消す、② 動いている argv をメモする、③ plist を更新して bootout→bootstrap、④ 更新直前後で 1 分間の stderr 行数を比較して異常な増加がないか見る、の四段に分けると戻しやすいです。複数人で同じレンタル Mac を触る場合は、誰が plist を「正」とするかを決めないと上書き合戦になります。

監視の最低ライン（高価な APM がなくても）

フルスタックの可観測性がなくても、launchctl print の exit status、err ログの最終更新時刻、コンソール URL の HTTP ステータスを 5 分おきに cron で叩くだけで「完全沈黙」を早期に掴めます。ディスク使用率も忘れがちですが、ログローテーション無しの KeepAlive 失敗は一晩でボリュームを圧迫し、別の意味でサービスを落とします。

ポート競合と「二重 bootstrap」

同じ Label を変えずに二重登録したり、手動起動したプロセスと launchd 管理プロセスが同じポートを奪い合うと、ログには bind error が断続的に出るだけで原因が分かりにくくなります。運用ルールを「常に launchd 一本」か「デバッグ時は必ず bootout」かに揃え、lsof で LISTEN を確認してから次の試行に進むと混乱が減ります。チーム内でポート番号とプロセスの対応表を共有ドキュメントに 1 ページだけでもあると、引き継ぎが楽です。

セキュリティの最低限メモ

ゲートウェイを 0.0.0.0 に開くか、SSH トンネル必須にするかは脅威モデル次第です。レンタル Mac は「自分だけが触る」前提でも、パスワード再利用や弱い VNC パスワードが混ざると簡単に踏み台になります。plist に書けるのはパスとフラグまでに留め、トークン類は OS の秘密ストレージに寄せる——この二行を runbook の先頭に書いておくと後悔が減ります。

目安： ドキュメントのコンソール用ポート（例 18789）を lsof で確認。

VNC を閉じても正しく載った LaunchAgent は止まりません——再起動ポリシーを設計してください。

トラブルシュート 10 解、2026.3.x 移行、VNC 設定ガイド。

まとめ

launchd はライフサイクルの契約、VNC は人間が必要な瞬間を短くします。実機 Mac を増やさずに近い運用をしたい場合、VNCMac のような VNC 付きリモート Mac と本チェックリストの組み合わせが実用的です。