2026年版 リモート Mac でセルフホスト GitHub Actions Runner を OpenClaw CI に接続：読み取り専用 Webhook、macOS ラベルプールと M4 並列（Lobster ワークフロー + トラブルシュート FAQ）

OpenClaw フォークやプラグインを維持するチームは、2026 年に次の二重課題に直面します。上流の OpenClaw CI では macos-node、macos-swift、checks-node-compat-node22 が本物の macOS を要求する一方、GitHub ホスト型 macOS の分課金とキューがコストを押し上げます。本記事はリモート専用 Mac 上の GitHub Actions セルフホスト Runner に限定し、macOS ラベルプールで OpenClaw の lane を受け、読み取り専用 Webhook + Lobster 多段ワークフローで失敗 triage する手順をまとめます。Gateway 18789 の導入や 6 地域ノード横評は書きません（ノードと TCO は macOS Runner ノード・TCO 記事 を参照）。プランは 料金ページ、米国東部・西部の公開チェックアウトは 米国東部・米国西部、Runner 運用は ヘルプセンター をご覧ください。

1) ホスト型 macOS Runner vs リモート Mac セルフホスト：OpenClaw CI 向け決定表

OpenClaw CI ドキュメントによれば、macos-node は macOS 関連ソース変更時に TypeScript テストを実行し、macos-swift は Swift の lint/ビルド/テストを担当します。手動 workflow_dispatch はスマート scope をバイパスし、Node 22 互換 lane を含むフルグラフを起動します。公式リポジトリは Blacksmith の macos-latest 系を使いますが、フォーク保守者が上流と同じキューを安定利用できない場合は、自前の macOS ラベルプールが必要です。

GitHub ホスト型 macOS は分課金向きで PR が少ないときに有効です。セルフホストはリモート M4 で「固定席 + 永続 node_modules / DerivedData」を買う形で、main の日次更新やプラグイン契約のシャード、上流 pnpm check 相当のローカル検証に向きます。6 地域ノードと日額—月額の試算は Runner TCO 記事 に任せ、ここでは OpenClaw lane の接続だけを扱います。常駐 Agent/Gateway の役割分担は OpenClaw リモート Mac 実践ガイド に一文だけ触れます（Gateway は対話とツール面、CI Runner はビルドとテスト）。

2) 環境チェックリスト：Xcode CLT、Node 22、CI ユーザー分離

上流は Linux で大半の Node シャードを回しますが、macos-node と checks-node-compat-node22 は Node 22 を要求します（CI ドキュメントの compat lane とローカル pnpm check 相当）。セルフホスト Runner では次を推奨します。

• Xcode Command Line Tools と、チームが固定した Xcode マイナー版を一致させる。Swift lane には CLT だけでなくフル Xcode。
• Node 22.x を fnm / mise で固定し、CI ユーザーの ~/.zprofile に反映。workflow 内は actions/setup-node も併用。
• pnpm を上流 packageManager に合わせ、キャッシュは CI ユーザーのホームに置き、日常開発と混在させない。
• 専用 Unix ユーザー（例：runner）で actions-runner をインストール。日常 Apple ID やチャット/ブラウザ鍵を持つユーザーで job を走らせない。
• リソース上限：ulimit、Activity Monitor、memory_pressure で監視。24GB 機種で初めて第 2 job の並列を検討。

Apple プラットフォーム API と署名は Apple Developer Documentation、Node のバージョン方針は nodejs.org を参照してください。

3) Runner 登録と macOS ラベルプール（HowTo）

GitHub 公式ドキュメントに従い、リモート Mac に Runner を登録します。OpenClaw フォークでは、上流 job の runs-on を曖昧な self-hosted ではなく、専用 label にマップしてください。

# ~/actions-runner ディレクトリで
./config.sh --url https://github.com/YOUR_ORG/YOUR_FORK \
  --token YOUR_REGISTRATION_TOKEN \
  --labels self-hosted,macOS,ARM64,openclaw-macos-node,openclaw-m4-16 \
  --name nuv-openclaw-macos-node-01

sudo ./svc.sh install
sudo ./svc.sh start

ラベルプールの推奨（lane 別）：

• openclaw-macos-node — 上流 macos-node（TypeScript/Vitest の macOS パス）。
• openclaw-macos-swift — macos-swift。CPU/メモリ負荷が高く、16GB 機では node lane とデフォルト並列しない。
• openclaw-node22 — 任意。手動 dispatch の Node 22 compat やローカル pnpm check スモーク用。
• openclaw-m4-16 / openclaw-m4-24 — ハードウェア段。workflow のマトリクスや容量計画に使う。

jobs:
  macos-node:
    runs-on: [self-hosted, macOS, openclaw-macos-node]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '22'
          cache: 'pnpm'
      - run: pnpm install --frozen-lockfile
      - run: pnpm test --filter macos-relevant

署名・notarization など副作用のあるステップには concurrency: { group: codesign-macos, cancel-in-progress: false } を付け、キーチェーンの同時解除を避けてください。SSH/Runner の常駐設定は ヘルプセンター を参照。

4) OpenClaw CI / dispatch と読み取り専用 Webhook

上流 CI は push/PR で preflight が lane を決めます。フォークではそのロジックを保ち、macOS job の runs-on だけ自プールに差し替えます。フル検証には公式の手動 dispatch（ドキュメント例）を使います。

gh workflow run ci.yml --ref main
gh workflow run ci.yml --ref main -f target_ref=your-branch -f include_android=true

読み取り専用 Webhook 推論層（段階導入推奨）：CI 失敗の triage では、まず読み取り専用イベント（workflow_run.completed、check_run.completed、workflow_job.completed）だけを購読し、payload のメタデータ（リポジトリ、ブランチ、結論、URL）をゲートウェイまたは軽量受信端へ渡します。第 1 段階で Contents 書き込みや自動 merge は申請しない。検証後、Agent が公開ログ URLまたは Actions API の読み取り範囲で要約し、安定してからコメント・label などに拡張します。

5) M4 16GB / 24GB 並列の簡易表（単機ラベルプール）

以下はOpenClaw macOS lane向けの実務的な並列目安です（SLA ではありません。リポジトリ規模とプラグイン数に強く依存）。多地域や並列席の拡張は TCO 記事のノード戦略を参照し、本記事では 6 地域横評はしません。

Nuvcloud は複数ノードの M4 ベアメタル、メモリ・SSD 拡張、並列席で上記ラベルプールを固定 CI 席にしやすい構成を提供しています。利用可能ゾーンと価格は 料金ページ と各チェックアウトページを正とし、本記事は可用性やキューの SLA を約束しません。

6) Lobster ワークフロー：CI 失敗ログ triage の再現可能な断片

Lobster は多段ツールチェーンを決定的な 1 回の呼び出しにまとめ、承認点と resumeToken を持ちます。「CI が赤 → ログ取得 → 分類 → 人間確認 → 要約配信」に向き、LLM がツールを段階的に乱呼びするより安全です。Agent 設定で alsoAllow: ["lobster"] を付けてから pipeline を渡します。

{
  "action": "run",
  "pipeline": "exec --json --shell 'gh run list --workflow ci.yml --limit 5 --json databaseId,conclusion,headBranch' | exec --stdin json --shell 'gh run view $ID --log-failed' | exec --stdin json --shell 'node scripts/ci-triage-summarize.mjs' | approve --preview-from-stdin --limit 3 --prompt '要約をオンコールチャンネルへ送る？'",
  "timeoutMs": 120000,
  "maxStdoutBytes": 512000
}

対応する .lobster ワークフローでは collect → classify → approval → notify と分割できます（Lobster ドキュメントの workflow files 節）。status が needs_approval のときは resume で続行します。

{
  "action": "resume",
  "token": "<resumeToken>",
  "approve": true
}

再現可能な triage の習慣：各失敗の run_id、発火した label（例：openclaw-macos-node）、stderr 先頭のハッシュをチーム wiki に残す。Lobster の JSON を issue コメントに載せる前に Secrets 断片がないか人間が確認。pipeline がタイムアウトする場合は timeoutMs を上げるか「ログ取得」と「LLM 要約」を分割。失敗 run は 7 日間の読み取り専用アーカイブを推奨し、flaky と真の回帰を比較しやすくします。

7) よくある質問（FAQ）

Q1：Runner が Offline と表示される
launchd の稼働、登録トークンの期限、ディスク満杯を確認。GitHub → Settings → Actions → Runners で削除後、config.sh で再登録。セルフホスト Runner ドキュメントを参照。

Q2：macos-node で Node バージョンエラー
Node 22 に揃える：Runner の node -v、workflow の setup-node、checks-node-compat-node22 の三者一致。古い ~/.npm グローバルキャッシュを整理。

Q3：Swift / SDK が見つからない
フル Xcode が入り sudo xcodebuild -license accept 済みか確認。macos-swift job を CLT のみの機械で走らせない。

Q4：読み取り専用 Webhook が 403 のまま
secret、HTTPS 証明書、リバースプロキシパスを確認。GitHub App に該当イベント権限があるか。ゲートウェイが PR 本文をシェル命令として実行していないか（メタデータのみ解析すべき）。

Q5：openclaw doctor との違いは？
doctor はインストール/ゲートウェイの健全性。CI の赤は Actions job ログ。Lobster + gh run view で CI を排障し、onboard ドキュメントで workflow を代替しない。

Q6：Linux だけで macOS をスキップできる？
純 Node 変更のマージには使えるが、Swift/macOS 関連 PR の前に少なくとも一度 workflow_dispatch でフル実行が必要。上流 preflight の意図と矛盾する。

Q7：上流とフォークで Runner を共有してよい？
非推奨。PR ソースと Secrets を分離し、サプライチェーン script がフォーク外の署名材料を読まないようにする。

Q8：Lobster が invalid JSON を返す
各ステップの stdout が JSON のみか確認。maxStdoutBytes を増やす。人間可読ログを --json なしで次段に pipe していないか。

Q9：ホスト型とセルフホストの併用は？
可能。例：PR はホスト型、main の macos-swift はセルフホスト。if: や workflow ファイル分割で切り分ける。

ほかの記事は 技術ブログ 索引からどうぞ。