2026年 OpenClaw Webhooks の受信と GitHub／GitLab CI：共有シークレット、ゲートウェイルーティングとレート制限、専用リモート Mac の SSH における再現可能なデプロイ、401／413／タイムアウト FAQ
CI は HTTP で話します。GitHub Actions や GitLab CI から、ヘッドレス Mac 上の OpenClaw 互換ゲートウェイへ「軽く叩く」には、共有シークレット、リバースプロキシのパスルーティング、ゲートウェイ側のスロットリング、そしてペイロードサイズが静かな本番とページャ祭りを分けます。本稿は受信 Webhook を専用メタル上の SSH 再現デプロイに結びつけ、401／413／タイムアウトの切り分け表で締めます。
TL;DR — 要点
結論： Webhook URL は能力 URL として扱い、すべてのリクエストを認証し、ペイロードは小さく保ち、ワーカーがモデルやディスクに触れる前にゲートウェイでバックプレッシャーをかけます。
- GitHub： 生ボディに対する
X-Hub-Signature-256（HMAC-SHA256）を検証。シークレットは CI と検証側だけに置く。 - GitLab：
X-Gitlab-Token（またはパイプライントークン）を送り、欠落は拒否——URL の難読化だけに頼らない。 - ゲートウェイ： 外向きホスト名は一つ、環境ごとにパス接頭辞（
/hooks/prod/...など）、明示的なレート制限で暴走パイプラインからローカル推論を守る。 - Mac ワーカー：
openclaw・Node・brew をピン留めし、設定は git 管理、launchdで再起動、CI と同じ HTTPS 経路を SSH からスモークする。
CI とセルフホスト Runner の境界の話は 2026年 Jenkins SSH ビルドエージェント vs GitHub Actions セルフホスト macOS Runner：専有リモート Mac 上の並行性、SSH セッション安定性、TCO 意思決定マトリクス＋FAQ と併読すると、Webhook をどの階に置くかの判断がぶれにくいです。
1. 参照アーキテクチャ：CI → HTTPS → ゲートウェイ → ワーカー
2026 年の典型は次の通りです。GitHub Actions または GitLab CI が共有インフラ上で動き、あなたの HTTPS エンドポイントへ POST します。TLS はリバースプロキシまたはエッジ（Cloudflare、Tailscale Serve、クラウド LB 等）で終端し、Mac 上の 127.0.0.1 リスナへ転送します。OpenClaw 風ゲートウェイは Webhook を検証し JSON を正規化し、モデル・ツール・シェル自動化へ渡します。
公開面をプロキシに置くと、証明書ローテーション、WAF、パス単位のレート制限を、CI のたびにデーモンを再デプロイせずに足せます。
2. 共有シークレット：GitHub の HMAC と GitLab のトークンヘッダ
2.1 GitHub（X-Hub-Signature-256）
GitHub は Webhook シークレットで生の POST ボディに署名します。検証側も同じバイト列をハッシュし（JSON の整形差で壊さない）、定時間比較で突き合わせます。シークレットはリポジトリ／Organization のシークレットに置き、Mac 側はサービスユーザだけが読める環境ファイルから——ワールド読み可能なホームは避けます。
2.2 GitLab（X-Gitlab-Token）
GitLab はプロジェクト／パイプライン Webhook で静的トークンヘッダを送れます。パスワード同様に扱い、ローテーションと最小スコープ、検証失敗は値をログに出さず記録します。.gitlab-ci.yml から curl する場合はマスク済み変数から注入し、ジョブログに URL 全文が出ないよう注意します。
3. ゲートウェイルーティング、パス接頭辞、マルチ環境の安全
パス名前空間を明示します：/hooks/ci/prod、/hooks/ci/staging など。それぞれ別ポートまたは Unix ドメインソケットにマップし、ステージングのバグが本番キューに入らないようにします。エッジでは WAF／レートプロファイルを環境別に——本番はバースト厳しめ、ステージングはデバッグ用にリプレイをやや許容、が無難です。
TLS を Mac 上で終端する構成（必須ではありません）でも、環境ファイルごとにリスナ設定を分け、クエリ文字列一つで意味が変わる「一枚岩設定」は避けます。
4. レート制限：CI ストームからゲートウェイを守る
CI は誤って扇状に広がります：マトリックス、リトライ、手動再実行で 1 分あたり数十 POST も珍しくありません。リバースプロキシまたはゲートウェイで RPS・同時接続の上限を張り、滞留がローカルキューの固着ではなく HTTP 429 と Retry-After として見えるようにします。429 比率のアラートを併用し、ワークフロー設定ミスにユーザー報告が先に来ないようにします。
5. 専用リモート Mac 上の再現可能デプロイ（SSH）
再現性は「自分のマシンでは動いた」と「毎週火曜 3 時にも動く」の差です。独占 Mac では次を固定します。
- バージョン：
openclawCLI、ゲートウェイパッケージ、Node をピン留めし、インフラ用リポジトリ横にversions.lockのような小さな記録を置く。 - 設定： リスナアドレス、Webhook ルート、環境変数を git 管理し、
rsyncや Makefile の SSH ターゲットで配る。 - プロセスモデル：
launchdの plist でStandardOutPath／StandardErrorPathを分け、CI 起因の失敗に監査の跡を残す。 - スモーク： CI ジョブまたは手動ゲートから、本番 Webhook と同じ公開 URL へダミーペイロードを署名付き POST——TLS・パス・ヘッダのドリフトをマージ前に検知する。
物理 Mac 上で CI のパフォーマンス一貫性を詰める観点は 2026年における物理MacのCI環境パフォーマンス一貫性最適化ガイド も参照ください。
6. FAQ マトリクス：401、413、タイムアウト
| 症状 | 想定原因 | まず確認すること |
|---|---|---|
401 Unauthorized |
HMAC／トークンの欠落・不一致。HMAC では時刻ずれは稀だが JWT エッジでは起きやすい。 | X-Hub-Signature-256／X-Gitlab-Token の有無をログ（値は出さない）。生ボディで HMAC を再計算。CI 変数と Mac 側シークレットの一致。 |
413 Payload Too Large |
誤って巨大 JSON（成果物を埋め込んだ等）またはプロキシのボディ上限が GitLab／GitHub 既定より小さい。 | Webhook からバイナリを除き URL で渡す。nginx の client_max_body_size 等は必要最小限、アプリ側にもハード上限。 |
クライアントタイムアウト／504 アップストリーム |
ワーカーがモデル I／O でブロック、CI の HTTP ステップがゲートウェイ処理より短い、プロキシのアイドルタイムアウト。 | ハンドラは速く 202 Accepted を返し非同期処理。GitHub の --max-time と GitLab の curl タイムアウトをプロキシのキープアライブと揃える。ゲートウェイ側の待ち時間はアップグレード runbook で下限を記録し、Ollama やツール呼び出しと一緒に見直す。 |
Webhook ワーカーに Mac mini が向く理由
ゲートウェイは長寿命プロセスです。数週間手動再起動なしで生き、CI からのバーストに耐え、机の上では静かであるべきです。Apple Silicon の Mac mini はアイドル電力が極めて低く（数ワット程度）、ファンも静かで、無人の launchd ジョブと相性のよい macOS の安定性があります。SSH 自動化向けのネイティブ Unix ユーザランド、プロキシ補助の Homebrew、Gatekeeper・SIP・FileVault による多層防御で、無人時の攻撃面を多くの汎用 PC より小さく保ちやすいです。
機密フックを共有 Runner に預けず CI 主導の自動化を置きたい場合、Mac mini M4 は並列検証に十分な性能と読みやすい熱挙動、長期オンラインほど有利に見える TCO を兼ね備えた実用的なアンカーになります。
ゲートウェイを自分の管理下のハードに載せる準備ができたら、下の SSHMac トップから想定 Webhook 量に合うプランを選んでください。
SSHMac のトップページでプランを確認できます。