2026 年 MacLogin クラウド Mac における OpenClaw Webhook 重複排除とべき等キー: ベンダーが POST を再送してもエージェント二重実行を止める

HTTP Webhook は魅力的ですが、Stripe や GitHub、自前 ERP が TLS の瞬断や502、オペレーターの「配信リプレイ」ボタンで同じ経理イベントを黙って再送し、OpenClaw が高コストなエージェントターンを二回走らせることがあります。2026 年の正解は「ゲートウェイが賢いはず」という希望ではなく、安定したキー、TTL 付きストレージ、抑制件数を示すメトリクスという明示的なべき等契約です。本稿は香港・東京・ソウル・シンガポール・米国で MacLogin Apple Silicon 上に OpenClaw を置くオペレーター向けに、macOS ファイルシステムの現実と無視できない地域間時計ずれを一緒に扱います。

あわせて読む:TLS リバースプロキシ Webhook、cron と launchd のスケジューリング、監査証跡向け CLI フック。ハブはOpenClaw トピック索引、運用の入口はヘルプと価格設定です。

日本の金融系では「同一取引の二重計上」を内部統制で必ず潰す一方、Webhook は非同期で再試行が当たり前です。このギャップを埋めるには、HTTP 200 を返す前に「この配送 ID は既に処理済み」と判定する層をゲートウェイ直後に置き、会計システムと同じ言葉（配送 ID、伝票番号、イベント ID）でログを残すのが効きます。

常時オンゲートウェイ上のベンダーリプレイ脅威モデル

正当なインフラは TLS の瞬断、502、オペレーター起動の「配信リプレイ」で POST を再送します。攻撃者は捕捉した本文を再送してクレジットを焼いたり、プロンプトインジェクションに回したりします。したがって重複排除層は同一の正当リトライと改ざんリプレイを区別できなければなりません—署名検証はWebhook 署名の指針どおり必須で、べき等性は成功パス上の二重を扱います。

• バースト窓:地域障害のあと90秒以内に同一論理イベントが8回届くことがある。
• ペイロード漂移:ゲートウェイが再シリアライズでタイムスタンプを足す—JSON 文字列一致だけではキーにできない。
• 共有リース:1 台の Mac mini に二チームが乗るとログが倍増し、重複テーブルを回さないと APFS スナップショットが膨らむ。

東京で夜間バッチ、米国東海岸で昼の取引が重なると、同じ「論理イベント」が二つのオンフコールが見るダッシュボードに別々の「新規」として出ることがあります。配送 ID を正規化してからログに出すと、人間の混乱が減ります。

キー形状の判断マトリックス（✓ / ✗）

「複合キー」を採るときは、将来フィールドが増えたときに衝突が増えないよう、バージョン接尾辞をキーに含めるか、マイグレーション手順を先に書いておくと安全です。

ストレージ、TTL、macOS ファイルシステムの現実

多くのチームは launchd が既に握っている~/.openclaw以下に追記のみの JSON Lines から始めます。重複がO(log n)検索を要する段階で SQLite が勝ちます。どのエンジンでもディレクトリはchmod 700、ネットワークマウント上の DB は fsync 遅延を計測なしに置かないでください。混雑した VPN 越しの東京—米国 NFS は、誤って「新規イベント」挿入が二重化し経理支払いまで届いた事例があります。

SQLite を選ぶ場合は WAL モードと適切な同期設定をドキュメント化し、コンパクション用ヘルパーを別 launchd ジョブに分けると本番の Webhook レイテンシと競合しにくくなります。

CLI 実験から本番 launchd までの 9 手順展開

1. 取得:実ペイロードを 5 件（マスク済み）集め、正規キーの抽出パスを文書化する。
2. 実装:OpenClaw がキューに入れる前のミドルウェア—適切なら本文duplicate_suppressedで200を返す。
3. 単体テスト:250 ms 以内の三重配送でサンダリングハードを再現する。
4. 負荷試験:本番で許可する最小 MacLogin プラン上で時間1,200件の合成イベント。
5. 配線:受理、抑制、署名拒否のカウンタを用意する。
6. ペア:ループバック拘束と組み合わせ、ヘルスチェックが重複層をすり抜けないようにする。
7. 出荷:重複テーブルを圧縮するヘルパーは launchd のThrottleIntervalを5秒以上にする。
8. 実行:デプロイ後にopenclaw doctorを走らせ標準出力をアーカイブする。
9. 観測:香港と米国タイムゾーンで三営業日フル観測する。

9 番目の「三営業日」は、金曜デプロイで月曜朝のリトライ山を必ず含むように調整してください。日本の祝日と米国の祝日がずれる週は、実質観測が短く見えるのでカレンダーをチケットに貼っておくとよいです。

HMAC 検証、時計、ずれ予算

署名方式は Unix タイムスタンプに ±300 秒の許容を載せることが多く、Mac mini の時計がそれを超えると dedup の前にベンダーから拒否されます—ログを誤って重複排除の失敗と読むチームが後を絶ちません。メンテではsntp -sS time.apple.comを実行し、連続二回で漂移が2秒を超えたらアラートに繋ぎます。NTP 健全性は抑制件数と同じパネルに載せ、オンコールが相関を見られるようにしてください。

コンテナや VM ではホストとの時計共有設定も確認し、サマータイム切り替えの週は意図的に追加ヘルスチェックを入れると安心です。

レイテンシ SLO と誤った二重受理

プロセス内 LRU だけを見る高速ミドルウェアは再起動後に重複を取りこぼします。遠隔 Redis を不安定なトンネル越しに叩く遅いミドルウェアはベンダーの HTTP タイムアウトを超え、さらにリトライを誘発する悪循環になります。ループバック上では p95 が35 ms 未満で状態は永続化する、を同時に満たすのが目安です。両立が無理ならコミュニティ連携で文書化されているイベントゲートウェイ（Hookdeck 級）を Mac の手前に置き、オンマシン dedup を第二防衛線に縮小してください。

p95 が境界付近で推移しているときは、ディスクではなく同ホスト上の別テナが CPU を奪っていないかも見てください。共有 Mac では Xcode インデックスが Webhook と同時に走る典型パターンです。

日本と米国を跨ぐ相関のコツ

東京主・米国ウォームスタンバイ構成はよくあります。重複状態は自動では複製されない—同じ外部イベントバスを前段に置くか、フェイルオーバーで重複が戻ることを受け入れ、dedup DB を複製してください。各行にregion=jpとregion=usを付け、切り替え後のフォレンジックで時系列を混同しないようにします。状態ディレクトリのバックアップで~/.openclawをスナップショットするときは dedup ストアを含め、ロールバックの一貫性を保ってください。

スタンバイを「たまに起動して疎通だけ」にしていると、dedup が空のまま本番トラフィックを受ける瞬間が生じます。定期の状態同期か、フェイルオーバー演習で必ず埋めてください。

よくある質問

OpenClaw がベンダー署名検証の代わりになりますか。いいえ。重複排除は直交します。HMAC や mTLS を先に通してください。

安定 ID が無いベンダーは。不変フィールドから複合キーを組み立て衝突を文書化し、推測ではなくベンダーにエスカレーションしてください。

より隔離されたゲートウェイが欲しい。騒音の近所問題が出たら価格設定からソウルやシンガポールのノードを足してください。

Webhook 負荷の重い OpenClaw スタックに Mac mini M4 が効く理由

Webhook バーストは小さな CPU と I/O のバーストです。HMAC 検証、SQLite 挿入、エージェントワーカーへのファンアウトは M4 のシングルスレッド性能と高速 SSD に乗りやすいです。統合メモリは夜間の埋め込み再構築中に Node の GC と Ollama が同じリースを奪う—経理 Webhook が重なる典型—でも戦いにくくなります。MacLogin の多地域フットプリントにより、ベンダー多数が居るリージョン（しばしば米国東海岸）に dedup を近づけつつ、東京では低遅延 VNC で人間オペレーターを置け、税関を越えてベアメタルを送る必要が減ります。

1 台に詰め込むより追加の mini を借りた方がよいのは、無関係な Xcode ジョブが CPU を奪いミドルウェア応答が遅れる—まさにベンダーが最もリトライしやすい瞬間—に重複抑制メトリクスが腐るからです。