2026 カナダ cloud Mac M4 無頭 OpenClaw CI：install-cli.sh・--no-onboard・Mac mini hosting launchd 探針

プラットフォームチームが OpenClaw をカナダのリモート Mac M4 に移す際、よくある失敗はデスクトップ手順のコピーです。Screen Sharing を開き、完全な openclaw onboard を実行し、SSH 切断後も Gateway が生き残ることを期待する——CI とバッチワークロードには別の契約が必要です。公式 install-cli.sh と --no-onboard によるヘッドレス（headless）インストールパス、事前注入された設定、ウィザードの代わりに launchd ヘルスプローブ。本稿は一つの問いだけに答えます：クラウド Mac / Mac mini クラウド ビルド席で再現可能なヘッドレス OpenClaw CI をどう着地させるか。SSH トンネル vs 直結 Gateway の再議論はしません（OpenClaw カナダ M4：SSH ゲートウェイ、18789 token と launchd）。対話型 onboard のログ playbook も扱いません（リモート Mac インストール、onboard と LaunchDaemon 24/7）。同じ Mac mini ホスティング 席で GitHub Actions runner も動かすなら、クラウド Mac 上のセルフホスト macOS runner に従い Unix ユーザーと launchd ラベルを分け、Node バージョンとポート 18789 の競合を避けてください。

1. 対話 onboard ではなくヘッドレス --no-onboard が必須なとき

対話型 openclaw onboard は、実 GUI セッションのある Mac でオペレータが TCC（アクセシビリティ、自動化、画面収録）を承認する初回体験に向いています。ターゲットが SSH またはセルフホスト runner 経由のみの クラウド Mac CI レーンで、設定が内部テンプレートから既に生成されている場合、ウィザードを続けるとパイプラインをブロックし、Git から再構築できないスノーフレークホストを作ります。

ヘッドレス契約は次のとおりです：

• install-cli.sh で Node LTS とグローバル openclaw CLI semver を固定。
• --no-onboard を渡し、設定ディレクトリ（上流ドキュメントに従い、多くは ~/.openclaw）を Secrets 管理から同期。
• エージェントがブラウザ自動化で TCC をまだ必要とする場合のみ、一度限りの Screen Sharing ウィンドウをスケジュール。その後は launchd のみで運用。

「リモート Mac 安定化」ノートとの違い：本稿はバージョン管理された CI Runbook とプローブスクリプトを提供し、デスクトップオペレータマニュアルではありません。新席ごとに onboard へ手入力しているチームは、まだヘッドレス成熟度に達していません。

2. ヘッドレス install-cli.sh vs 完全 onboard：選び方

プロバイダから新しい Mac mini クラウド 席をプロビジョニングするとき、最初にヘッドレス smoke パイプラインを実行してください。「一度手で onboard」したチームは、数週間後に 1 時間以内に Gateway を DR できないことに気づくことが多いです。

比較表の「典型障害」列は、Runbook 更新のトリガーとして使えます。PATH ドリフトが週次で再発するなら、plist の EnvironmentVariables と CI 側の Node pin を同じ変更で扱うべきです。クラウド Mac ビルド席では、設定 semver と CLI semver を別チケットで上げない運用が、sharp や 401 の連鎖障害を減らします。

3. ヘッドレスプロビジョニング Runbook：install-cli.sh と設定注入

以下の例は、VNC 管理者から分離した専用システムユーザー openclaw-ci を想定します。カナダ M4 クラウド Mac では Node を LTS（2026 年基準 22.x が妥当）に pin し、runner ユーザーの nvm shim から分離——launchd ジョブは対話 shell プロファイルを読み込みません。

# クラウド Mac 上で openclaw-ci として SSH
export OPENCLAW_CONFIG_DIR="$HOME/.openclaw"
curl -fsSL https://example.openclaw.dev/install-cli.sh | bash -s -- --no-onboard

# CI secrets から config を復元 — token を Git にコミットしない
install -d -m 700 "$OPENCLAW_CONFIG_DIR"
echo "$OPENCLAW_CONFIG_JSON" > "$OPENCLAW_CONFIG_DIR/config.json"

# サポートされていれば Gateway launchd サービスをインストール
openclaw gateway install-daemon
openclaw doctor --non-interactive

ホビーインストールと本番 クラウド Mac レーンを分ける運用メモ：

1. 冪等性：workflow は再実行に耐えること。良いスクリプトは既インストール時 no-op またはバージョン収束。
2. Semver ロック：Runbook に openclaw --version と config schema バージョンを記録。アップグレードは変更ウィンドウとロールバック手順付き。
3. ディスクレイアウト：npm/pnpm キャッシュは独立 wipe 可能なパスに。同ホストで iOS もビルドするなら Derived Data と分離。
4. Checksum：本番では install スクリプト digest を pin。検証なしの curl | bash はサプライチェーン事故の待ち。

4. launchd ヘルスチェック：プロセス、ポート、ログの三角

ヘッドレスでは「Gateway が上がっている」は、フル PATH の SSH セッションで一度 curl しただけ、という意味になりがちです。本番プローブは launchd 状態、リッスンアドレス、ログキーワードを同時に検証。5 分ごとに cron またはスケジュール GHA workflow で実行：

#!/bin/bash
set -euo pipefail
LABEL="ai.openclaw.gateway"
launchctl print "gui/$(id -u)/$LABEL" | grep -q 'state = running'
lsof -nP -iTCP:18789 -sTCP:LISTEN | grep -q openclaw
curl -sf -H "Authorization: Bearer $OPENCLAW_GATEWAY_TOKEN" \
  http://127.0.0.1:18789/health | grep -q '"ok":true'
tail -n 50 ~/Library/Logs/openclaw/gateway.log | grep -Ei 'sharp|EADDRINUSE|401' && exit 1 || true

plist は絶対パスで openclaw を呼び、EnvironmentVariables に PATH=/opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin を明示。launchd は対話 ~/.zprofile を読みません。この不一致が、レンタル クラウド Mac で「SSH では動くが daemon は即終了」の最大原因です。

プローブに duration メトリクスを追加：/health p95 レイテンシを追跡し、コールドスタートが workflow タイムアウト予算を超えたらアラート。対話で 4 秒、launchd で 30 秒の Gateway は、厳しいリトライの CI job を失敗させ得ます。

ヘッドレス運用では、プローブ結果を時系列 DB に書き込み、週次レポートで EADDRINUSE や 401 のトレンドを可視化することを推奨します。単発の手動 curl 成功は SLA 証拠になりません。Mac mini クラウド 席では、再起動後 90 秒以内に緑へ戻ることを SLO として Runbook に明記し、超過時は自動で launchctl kickstart を試行するようにしてください。

5. プローブ結果マトリクス：緑、黄、赤の対応

黄色が 24 時間超続く場合はリリースブロッカー扱い。ヘッドレス CI は予測可能な Gateway を前提とし、断続的な認証・レイテンシ障害は agent 側で高コストな一括タイムアウトに増幅します。

オペレータは黄状態で agent 同時実行数を下げ、Token 同期と openclaw doctor を先に実行してください。赤へ移行する前に、Mac mini ホスティング 席のディスク I/O やメモリ圧力が Gateway 再起動を遅延していないかも確認します。

6. Apple Silicon クラウド Mac 上の sharp ネイティブモジュール

OpenClaw の依存に sharp（libvips バインディング）が含まれます。M4 arm64 ホストで Node メジャー不一致やインストールユーザー混在があると、Cannot find module '../build/Release/sharp.node' や実行時アーキテクチャ不一致が出ます。ヘッドレス CI は初失敗 job で初めて気づくべきではありません——golden image または post-install hook に sharp 検証を焼き込んでください。

6.1 よくある失敗と修正

• ユーザー不一致：root がグローバル CLI を入れ、openclaw-ci が daemon 実行——サービスユーザーで sharp または CLI を再インストール。
• Node アップグレード後未 rebuild：Node bump 後 npm rebuild sharp または openclaw CLI パッケージ再インストール。
• Rosetta 混在：plist と CLI は両方 arm64；file $(which node) は arm64 を示すこと。
• オフラインキャッシュ：帯域制限の Mac mini クラウド ホストでは sharp バイナリを prefetch し、CI 毎 job の GitHub releases 取得を避ける。
• 複数 Node マネージャ：daemon に Homebrew Node、対話 shell に nvm を混在させない——1 つのストーリーを plist にエンコード。

node -p "process.arch + ' ' + process.version"
npm ls sharp --global 2>/dev/null || true
npm rebuild sharp --foreground-scripts
openclaw doctor 2>&1 | tee /tmp/openclaw-doctor.log
grep -i sharp /tmp/openclaw-doctor.log && exit 1 || echo "sharp OK"

doctor がまだ sharp を報告するなら、同一 install-cli.sh アーティファクトから Node と CLI チャンネルを揃えてからアプリ層を追う。Homebrew Node + npm グローバル CLI で plist PATH 未修正は、Mac mini ホスティング チケットで最頻の sharp エッジです。

ゴールデンイメージを使うチームは、イメージ更新のたびに npm rebuild sharp と openclaw doctor --non-interactive を post-install hook に含めてください。帯域制限のある Mac mini クラウド では、sharp の prebuilt バイナリをローカル mirror に置くと、CI ジョブごとの GitHub 依存が減り、ヘッドレス lane の可用性が上がります。

7. CI における Gateway 18789 境界と token ローテーション

ヘッドレス pipeline は bearer token 付きでローカル Gateway 127.0.0.1:18789 を呼ぶべき——ポートを公開インターフェースに晒さない。token は CI secrets（例 OPENCLAW_GATEWAY_TOKEN）に保存。ローテーション：新 token を config に書き、daemon reload、プローブ緑、旧 secret 失効。ループバックは runner と Gateway が 1 台の クラウド Mac を共有するときレイテンシ最小。クロスホストは上記 SSH ゲートウェイ記事へ。

workflow は明示タイムアウトと限定リトライ。再起動後コールドスタート 10–30 秒あり得る。プローブ失敗時は破壊的 reinstall の前に一度 launchctl kickstart。macOS パッチ後の boot storm で動作 config を消さないよう on-call に文書化。

Token ローテーションは CI パイプラインと Gateway の両方で同じ変更チケットに紐づけ、片方だけ更新される split-brain を防ぎます。本番 クラウド Mac では、staging 席で新 token を検証してから production config を切り替える二段階デプロイが安全です。ロールバック手順には旧 token の有効期限と gateway.log に残る 401 スパイクの見方を含めてください。

8. ホスト型 Mac 席でのヘッドレス OpenClaw セキュリティ基線

• 専用ユーザー：openclaw-ci は admin 権限・VNC ログインなし。
• Secrets：config と token は vault のみ。ボリューム FileVault 有効。
• ネットワーク：インバウンドは SSH または Tailscale のみ。18789 を LAN にブロードキャストしない。
• サプライチェーン：install スクリプト checksum 検証。本番で未監査 pipe-to-bash を禁止。
• 監査：gateway.log 14 日保持。401 と sharp キーワードをログスタックへ。
• ブラスト半径：agent tools profile は最小権限。不可信 fork PR は本番 Gateway ホストに触れない。

ヘッドレス自動化は速度を上げ、疑わしい install URL に人が気づく一瞬も削ります。install スクリプト URL と checksum を本番 TLS 証明書と同じ厳格さで扱ってください。

監査ログは SIEM へ転送し、401 と sharp キーワードでアラートルールを設定します。fork PR から本番 Gateway ホストへ到達できる workflow パスは、branch protection と environment 承認の両方で遮断してください。

定期的な DR 演習では、新規 クラウド Mac 席を Runbook どおり 30 分以内に再構築できるかを計測します。ヘッドレス CI の価値は、対話 onboard に戻らずに fleet を再生成できる点にあります。Mac mini ホスティング 契約では、スナップショットと FileVault 回復キーの保管場所も Runbook に含めてください。

9. ヘッドレス OpenClaw を GHA または内部 CI に接続

Gateway プローブが緑になってから、ガード付きステップで pipeline に OpenClaw を公開：

1. GitHub Environments から OPENCLAW_GATEWAY_TOKEN を export。本番はレビュア必須。
2. agent job は runs-on: [self-hosted, macos-m4-canada, openclaw] ラベル。署名/archive job と分離。
3. 高コスト LLM やブラウザステップの前に、cron と同じ shell プローブで fast fail。
4. 失敗時 openclaw doctor 出力を workflow artifact に保存し非同期レビュー。

メモリ計画：24GB Mac mini クラウド 席で同夜 xcodebuild archive も走るなら、ユニファイドメモリ圧力 80% 超で OpenClaw agent バッチを一時停止。キュー深度アラートで「GitHub が遅い」誤認を防ぎ、ホスト過負荷を見抜く。

GHA workflow では、OpenClaw ステップの前に memory_pressure または vm_stat ベースの preflight を入れると、夜間 archive と agent の衝突を減らせます。ラベル openclaw を archive 専用 runner と混在させないことも、Mac mini ホスティング 運用の基本です。失敗 artifact には doctor 出力に加え、直近 200 行の gateway.log を添付すると、VNC なしのトリアージが現実的になります。

10. カナダ M4 専用席の初週チェックリスト

1. Mac mini ホスティング プラン選択（CI + Gateway は 24GB RAM、512GB SSD 以上）。
2. openclaw-ci 作成。install-cli.sh --no-onboard smoke 合格。
3. config と token 注入。openclaw doctor --non-interactive クリーン。
4. launchd インストール。緑/黄/赤プローブとページング。
5. sharp 事前検証。Node と CLI バージョンを Runbook にロック。
6. GHA runner 共有時、ユーザー分離とポート競合なしを確認。
7. 再構築手順：新 クラウド Mac 席は 30 分以内に同一 Gateway 動作へ。

初週の終わりに、staging と production で同じ Runbook を実行し、差分が plist パスと token 注入だけであることを確認してください。これが Mac mini クラウド ヘッドレス運用の合格ラインです。

11. FAQ

--no-onboard 後も VNC は必要？

エージェントがブラウザ自動化や TCC を要するなら一度限りのグラフィカルセッション。純 CLI または API Gateway は launchd 安定後 VNC なしで長期運用可。

install-cli.sh vs 完全 install.sh？

CI が CLI + Gateway のみなら install-cli.sh。メニューバーアプリ付き完全インストーラは反復ヘッドレス runner 展開に不向き。

プロセスは動くのにプローブ 401？

多くは token ローテーションドリフトか workflow が旧 secret 送信。ディスク config と Authorization ヘッダを揃え、古い token を注入するプロキシを確認。

SSH では sharp OK、launchd では NG？

ほぼ常に PATH またはユーザー環境差。launchctl print の environment と対話 env を並べて比較。

macOS で Docker 内 OpenClaw Gateway は？

Mac 上 Docker はネイティブ TCC と GUI 自動化を置き換えられない。Gateway はネイティブ launchd。コンテナは周辺ツールのみ。

1 ホストで OpenClaw と GitHub Actions をどうスケジュール？

agent バッチは archive ピークを避ける。メモリ 80% 超で agent 一時停止。ラベルと並行性は セルフホスト runner 記事参照。

Hashvps カナダノードはヘッドレス OpenClaw に向く？

専用 IPv4、ベアメタル M4、常時 SSH が必要なら向く。npm キャッシュとローテーション gateway ログにディスク tier が足りるか確認してから契約。

標準 CLI アップグレード手順は？

メンテナンス窓：launchctl bootout、install-cli でバージョン収束、npm rebuild sharp、doctor、プローブ緑、トラフィック復帰。