Linux は OpenClaw のコントロールプレーン、ゲートウェイ、または外向きプロキシとしてよく使われ、実際にビルドを走らせる Mac は MacCloud 上にあることが多いです。以下は systemd 搭載ディストリビューション（Ubuntu LTS、Debian、クラウドベンダーイメージなど）を想定し、権限が明確で、再起動とトラブルシュートがしやすい構成を目指します。

1. 専用ユーザーとディレクトリが重要な理由

業務プロセスを root で動かさないでください。OpenClaw 用のシステムユーザーと作業ディレクトリ（例：/var/lib/openclaw）を用意し、設定と秘密情報はそのユーザー配下に置き、機密ファイルは 600 などに絞ります。バックアップ、移行、引き継ぎの境界がはっきりします。

2. 安定した systemd ユニットの書き方

Type=simple または公式推奨タイプを使い、WorkingDirectory と EnvironmentFile を明示します。Restart=on-failure と適切な RestartSec を有効にし、異常ループで CPU を食いつぶさないようにします。複数インスタンスはテンプレートユニットや別サービス名で分け、同じ PID ファイルを共有しないでください。

要点： 起動・停止理由が journalctl -u で追えることは、シェルスクリプトの echo よりチケット運用に向きます。

3. ネットワークとファイアウォール

既定ではインバウンド拒否、必要なものだけ許可。外向きクライアントだけならインバウンドポートを開けないままでも構いません。MacCloud 上の Mac と通信するときは固定の出口 IP やプライベートネットを優先し、クラウド側でホワイトリストしやすくします。穴あけが必要ならポートと有効期限を変更記録に残してください。

4. ログとローテーション

標準出力は journald に渡すか、logrotate 管理のファイルへ。run_id や step などのフィールドを入れておくと Mac 側ビルドログと突き合わせやすくなります。ディスク満杯はオーケストレーション全体を落とします。上限ポリシーを忘れないでください。

5. Mac ビルドマシンとの連携のコツ

Linux はオーケストレーションとコールバック、Mac は Xcode／GUI 寄りの作業に寄せます。長時間ステップはリースと課金をコントロールしやすい側に置きましょう。Mac インスタンスが日次／週次課金の場合、更新境界で中断できない長ジョブを開始しないようにします。

6. セルフチェックリスト

  • サービスは非 root で動き、ディレクトリ権限は最小か？
  • 失敗時に systemctl status で直近のログが見えるか？
  • ファイアウォールとクラウドのセキュリティグループを両面で確認したか？
  • ログ増加にしきい値アラートがあるか？

デスクトップ側のデバッグが必要なら WSL2 ガイド へ。CI なら GitHub Actions 連携 を読んでください。