2026：1 台のレンタル Mac mini で OpenClaw の開発・ステージング・本番を隔離する（LaunchAgent、ポート、シークレット）
チームが 香港・日本・韓国・シンガポール・米国 にある Mac mini M4 で OpenClaw の自動化を出荷するのは、macOS がノートと一致するからです。しかしステージングのプロンプトが本番の MCP スキルを書き換えるほど信頼を壊すものはありません。本稿では （1） なぜ 1 台の mini にも 3 つの硬い壁が要るのか、（2） 各環境が触れてよい範囲を数値化する ブラスト半径マトリクス、（3） grep で追える フォルダとポートの命名契約、（4） launchd 上で繰り返し使える LaunchAgent の型、（5） GPU を複製せずにシークレットと JSONL ログを分ける方法、（6） 自動化の変更をマージする前のプレフライト、を順にまとめます。あわせて 並列エージェントの同時実行、シークレットとキーチェーン、JSONL 診断とローテーションのひな形 を参照してください。
Apple Silicon の mini 1 台でも「1 フォルダで突っ走る」より三環境が勝つ理由
財務は環境を請求行として想像しますが、プラットフォームエンジニアには 障害ドメイン として見えます。Slack の Webhook と本番 Terraform ステートの両方に書き込める単一の LaunchAgent は、マージコンフリクト一つで災害になり得ます。dev / staging / prod を 1 台の物理ボックスに分けるコストは低く、M4 の CPU に余裕があるからです。高くつくのは雑なファイル共有です。隔離は三つの具体的な勝ちをもたらします：独立したロールバック、顧客向け Webhook に触れない現実的なソークテスト、「Sarah が新スキルを試した」ログと「課金ボットが誤発火した」ログを分ける監査証跡です。
ProxyMac を使う場合は、セキュリティチームへ「同一請求書の下で複数環境がある」ことを明示し、出口帯域・ディスク割当・バックアップ方針を環境単位で分けるか確認しましょう。変更履歴にすべてを載せれば、事後の説明責任が一段楽になります。新人向けオンボーディングでは、3 つの plist・3 つのポート・3 セットのキーを 1 枚の図に描くと、口頭の「本番フォルダを触るな」より十倍伝わります。
- 数値ガードレール：各環境ルートに少なくとも 20 GB の空き APFS を残し、負荷試験中の JSONL スパイクが他エージェントを止めないようにします。ディスクが一桁 GB に迫ったら別のトリアージ記事へ。
- 人間のガードレール：ステージングのアラートと本番インシデント用チャンネルを絶対に共有しないでください。ノイズが混ざるとオンコールが両方を無視するよう訓練されます。
- 自動化のガードレール：API クォータが 1 週間安定するまで、ステージングの
maxConcurrentTasksを本番の 半分 に抑えます。
ブラスト半径マトリクス：各環境が触れてよい副作用
| 環境 | 許容される副作用 | チケットなしでは禁止 | 典型的な API キーの範囲 |
|---|---|---|---|
| Dev | ローカル git ブランチ、サンドボックス SaaS プロジェクト | 顧客 PII のエクスポート | 読み取り専用ミラーか短命 PAT |
| Staging | クローン済みデータに対するフルスキルグラフ | 本番 DNS の変更 | 別 Stripe testmode + 非本番 AWS ロール |
| Prod | 顧客ワークフロー、課金 Webhook | 実験的コンパイラ | 最小権限ロールと四半期ごとのローテーション |
この表をアーキテクチャ図の横に掲示し、フォルダ名だけで権限を推測させないようにします。行が破られたらデプロイを凍結し、コードを追う前に バージョンアップとロールバックの手順 で戻してください。
筋肉記憶で打てるフォルダとポートの契約
例として ~/openclaw-dev、~/openclaw-staging、~/openclaw-prod のような兄弟ディレクトリを作り、ステージングを本番の内側にネストしないでください。それぞれの中で config、skills、logs、tmp など同じサブフォルダをミラーし、サポート用スクリプトを同一に保ちます。ゲートウェイは 127.0.0.1 にバインドし、ポートは隙間を空けて割り当てます：例として開発 18789、ステージング 18799、本番 18809。空いた番号はペアプロ中のポートフォワード用に取っておきます。
社内 wiki に五列の表を書きます：環境名、絶対パス、TCP ポート、LaunchAgent のラベル、所有 Unix ユーザー。「どの plist が固まった？」という質問には、1 回の grep で答えられるべきで、~/Library/LaunchAgents を発掘する時間は無駄です。
LaunchAgent の型：環境ごとに plist を分け、巨大な一枚岩は作らない
com.yourorg.openclaw.dev.plist のように 3 枚の plist を用意します。それぞれに WorkingDirectory、非デフォルト PATH 用の EnvironmentVariables、その環境の logs ツリーへの StandardOutPath / StandardErrorPath を設定します。初期ロールアウトでは ThrottleInterval を 10 秒にして、クラッシュループがプロバイダを殴らないようにします。
インストール先に合わせて削る骨格の例です：
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0"><dict>
<key>Label</key><string>com.example.openclaw.staging</string>
<key>WorkingDirectory</key><string>/Users/automation/openclaw-staging</string>
<key>ProgramArguments</key><array>
<string>/opt/homebrew/bin/openclaw</string>
<string>gateway</string>
<string>--port</string><string>18799</string>
</array>
<key>RunAtLoad</key><true/>
<key>KeepAlive</key><true/>
</dict></plist>
127.0.0.1 にバインドし、リモートは SSH のポートフォワードかレビュー済みのエッジプロキシの前に置く—生のゲートウェイポートをインターネットに晒さないでください。
シークレット・ログ・ローテーション：交差汚染を防ぐ
API キーは環境ごとに別のキーチェーン項目か、権限 0400 の .env に入れます。本番キーをローテーションするときにステージングが「一時的に」同じパスを読むのは禁物で、そのショートカットはほぼ必ず恒久的になります。ログでは各 JSONL 行に env=staging のような接頭辞を付け、ファイル名も分けて ローテーションジョブ が開発ノイズを追いながら本番履歴を切らないようにします。
各環境から http://127.0.0.1:<port>/healthz（またはゲートウェイ相当）へヘルスチェックを飛ばし、ヘルスプローブの型 に沿ってください。閾値は変えます：開発は実験中に 5% ほどフラップしてもよいが、本番は連続 2 回の失敗でページを鳴らします。
スキルを本番へ昇格させる前のプレフライト
- 設定の diff：ステージングの
openclaw.json（または同等物）が、明示的に列挙したキー以外は本番と一致しているか確認する。 - ドライランの再生：直近 50 件の本番に似たイベントを匿名化ペイロードでステージングに流す。
- ポートの確認：
lsof -nP -iTCP -sTCP:LISTENでループバック上に意図したリスナーだけがいるか見る。 - ディスク：
df -hで本番ログを載せる APFS ボリュームに少なくとも 20 GB の空きがあることを確認する。 - MCP サーバ：各環境のツールマニフェストが別々のワーキングディレクトリを指しているか検証する。
- ロールバック練習：メンテナンス枠で本番 plist に対する
launchctl unload/ load を演習する。 - サインオフ：変更チケットにレビュアーのイニシャルを残す—自動化もアプリのデプロイと同じ厳しさで扱う。
よくある質問
本番は root で動かすべき？いいえ—ファイル ACL を伴う専用サービスアカウントのほうが常に勝ちます。root は TCC のプロンプトと監査を難しくします。
1 つの Node ランタイムを共有できる？バージョンは揃えてもよいですが、NODE_OPTIONS とグローバル npm のプレフィックスは環境別にしてください。Homebrew PATH の記事で触れた問題を踏み抜きます。
GitOps は？ブランチ（main、staging、dev）をミラーし、可能なら読み取り専用クローンでディレクトリにマップします—設定のバージョン管理 を参照してください。
隔離ができたあとも ProxyMac の Mac mini がマルチ環境 OpenClaw に合う理由
境界がはっきりすれば、単一の Mac mini M4 でも並列ゲートウェイ向けの ユニファイドメモリ の余裕、開発ノートと同じネイティブ macOS の挙動、香港/日本/韓国/シンガポール/米国 で予測可能な課金（CapEx のスパイクなし）を同時に得られます。ステージングが Swift パッケージをコンパイルしているあいだに本番エージェントが Webhook に応答する、という負荷パターンでも効きます。料金 を比較し、ヘルプセンター でリモートアクセスの型を確認し、テキストログだけでは説明がつかない launchctl の謎には VNC の手順 を控えておくと安心です。
