レンタル Mac mini 上の OpenClaw MCP 子プロセス残留：終了衛生と launchd リカバリ（2026-05-19）

ProxyMac の香港・日本・韓国・シンガポール・米国リージョンで借りた Mac mini M4 に OpenClaw と Model Context Protocol（MCP）stdio サーバーを載せているチームは、プロンプトが止まっているのに RSS だけが伸びる、node 行が増え続ける、ゲートウェイ更新後にツールだけ不安定、といった症状に直面することがあります。2026 年 5 月 19 日付けの本稿は、孤児プロセスの積み上げと JSON 行バッファリングの停滞を切り分け、5 列のオペレーター対応表と 9 ステップの launchd 安全手順を提示します。並列エージェント、stdio バッファ、ゲートウェイ復旧 へ相互にリンクし、オンコール手順書へ貼り込めるようにしました。

兆候：スワップ前に見える「プロセス表のドリフト」

上流の議論では、親が終わっても Node 子が数十 MB 規模の RSS を握ったまま残る例が報告されています。単テナのベアメタルでは隣人がいないぶん、問題がそのまま top と launchd の統計に出ます。

• 行数ドリフト：夜間に誰も SSH していないのに pgrep -lf mcp の結果が冷起動直後より多い。
• 段階的レイテンシ：最初のツール呼び出しは成功し、後から詰まる。古い読み手がパイプを閉じない典型です。
• バージョン skew：CLI だけ新しく、LaunchAgent 下のゲートウェイが旧 semver の子を抱えたまま。
• 「モデル障害」偽陽性：プロバイダ遅延は健康でもローカル fork が飽和。必ずホスト側を先に疑ってください。

根：stdio MCP が「粘着プロセス木」を生みやすい理由

stdio はランダム TCP を開けない反面、POSIX のパイプ規則をそのまま受けます。書き込み端が一つでも開いていると EOF は来ません。npx が孫プロセスだけ残すパターンも珍しくありません。LaunchAgent 環境では対話シェルより PATH や HOME が貧しく、短い再起動ループが「CPU 攻撃」に見えることがあります。

ulimit とメモリ上限 もセットで読んでください。多くの macOS ワークロードで プロセスあたりソフト上限 2560 のファイル記述子は一見ゆとりがありますが、ツール呼び出しが「各呼び出し × 3 本のパイプ」を積み上げると途中で半開き状態になり、孤児化の土壌になります。

オペレーター対応マトリクス（信号 → 行動）

一次信号	最初の手（順序厳守）	保存すべきデータ	誤検知時の戻し	エスカ先
20 分で RSS が約 200 MB 無断増	まず ps -o pid,ppid,rss,command を CSV 化	PPID 鎖と JSONL タイムスタンプ	親 PID を特定する前に kickstart しない	プラットフォーム SRE
管理ポート二重 LISTEN	ゲートウェイ復旧 の単一リスナ手順	lsof -nP -iTCP:18999 -sTCP:LISTEN	競合 plist を bootout	自動化リード
429 ばかりで CPU は低い	並列ガイドで同時実行を下げる	5 分バケットごとの 429 件数	旧 maxConcurrentTasks に戻す	FinOps
RSS 平坦だがツールだけ固まる	バッファ/PTY を調査、即 SIGKILL は避ける	dtruss など短時間サンプル（方針許可時）	無バッファ実験フラグを元に戻す	クライアント開発

9 ステップのクリーンラン（SSH セッション）

1. メンテ告知：90 秒でも CI 影響があるならチャットに書く。
2. 証跡エクスポート：ゲートウェイログ末尾 500 行と launchctl print gui/$UID の OpenClaw ラベル抜粋。
3. 新規ジョブ停止：Webhook やスケジューラを一時停止し、殺しながら生まれるレースを避ける。
4. 親子マッピング：PPID を書き写し、launchd 管理ゲートウェイへ先に kill -9 しない。
5. SIGTERM ウェーブ：対象 MCP 葉に送り、15 秒待って再カウント。
6. SIGKILL は argv 確認済みのみ。
7. ゲートウェイ再起動：ベンダ推奨の launchctl kickstart -k または bootout/bootstrap。
8. スモーク：読み取り専用ツールを 2 回叩き、10 分以内に RSS が基線へ戻るか見る。
9. ポストモーテム：週次再発なら PPID CSV を添付し本稿 URL を貼る。

launchd 特有の再サイクル規律

ThrottleInterval・KeepAlive・SuccessfulExit の組み合わせが、異常終了後にどれだけ激しく再起動するかを決めます。Node だけ入れ替えて古い stdio が死んだ PTY にぶら下がったままだと、launchd から見たゲートウェイは「健康」でもツールはランダムに失敗します。launchctl print で EffectiveUserID と plist 所有者を突き合わせてください。

TCC やキーチェーンの初回承認が必要なら VNC で一度 GUI を開き、その後は ヘルプ に沿ってヘッドレス SSH に戻すのが安全です。GUI と無人 launchd を同じホストで混在させると、MCP サーバが二重起動しやすくなります。

予防：同時実行・タイムアウト・爆発半径

孤児を産まない方が安いです。

• キューの深さと年齢をログに出し、並列 OpenClaw のパターンに合わせてバックプレッシャーを設計する。
• サーバごとにハードタイムアウトを設定する（キー名はリリースで変わる）：ネットワーク系は 120 秒、軽い stat 系は 15 秒から試す。
• 自動化ペルソナごとに作業ディレクトリを分け、git やパッケージマネージャのロック競合を避ける。
• 実験用 MCP と本番オーケストレーションを別 mini に分ける。HK/JP/KR/SG/US の選択は 料金ページ だけで完結します。

FAQ

ゲートウェイを止めたのに MCP stdio サーバーが残るのはなぜですか？ 強制終了でシグナル連鎖が途切れたり、npx が起動した中間シェルより孫プロセスだけが残ったりすると、MCP の Node 子が孤児化します。KeepAlive 付き LaunchAgent が新ゲートウェイを即再起動すると、古いパイプが開いたままになり、モデル遅延は正常でもツールだけ不安定に見えることがあります。

本番 ProxyMac mini で孤児 MCP を kill してよいですか？ まず SIGTERM を送り、ps と lsof の証跡を残し、argv が MCP 由来と確認できてから SIGKILL を検討してください。共有ホストでは他人のセッションを誤終了しないようファイル記述子を確認し、再起動後は lsof で管理ポートの LISTEN が一つだけか検証します。

stdio 行バッファリングのハングとの違いは？ バッファ問題は JSON 行が欠けたまま CPU が平坦なことが多いです。孤児蓄積はアイドル時でも RSS と node プロセス数が増え続けます。前者は PTY や無バッファ実行を、後者は同時実行上限・タイムアウト・ゲートウェイ再サイクル規律を見直します。

なぜ MCP の副作用 containment に ProxyMac Mac mini が向くか

MCP はツール呼び出しのたびに fork と fd を増やします。Apple Silicon M4 はその余裕を単スレッド性能と電力効率で支え、macOS はデスクトップ自動化と同じ前提を保ちます。HK / JP / KR / SG / US のどこに置くかで SaaS やレジストリへの往復が短くなります。ProxyMac のレンタルなら、汚れたプロセス木ごと捨てられるラボ用 miniを同じ 料金 ページから追加し、CAPEX なしで衛生サイクルを回せます。運用手順は ヘルプ の SSH/VNC 節と整合させてください。