要約：stdio はプロセス艦隊として扱う
MCP を増やせば便利になるとは限らない。各 stdio サーバは独立した子プロセスであり、メモリ・ファイル記述子・終了フックを個別に持つ。ツール一覧の再取得やモデル側のリトライが重なると、スポーン速度が回収速度を上回り、ps の行数が会話ラウンドと一緒に伸びるパターンが出る。RSS と子プロセス数が連動して増えるときは stdio ツリーの残留を疑い、RSS だけが尖って子数が平坦ならコンテキストやメディア一時領域を先に見る。
HTTP／SSE の url エントリは別クライアントパスに乗る。ビルドが stdio しか実装していない場合、設定に残したままだと明示的にスキップログが出る。コンプライアンスが許すなら薄いラッパで遠隔能力を stdio に折り返すか、検証済み stdio サーバへ一覧を絞る。
推奨順は openclaw status → openclaw gateway status → openclaw logs → openclaw doctor → openclaw channels status --probe。ゲートウェイ運用記事と整合させてから MCP に潜り、リバプロと MCP の間で空振りしない。
痛みの分解：リーク、ホットリロード、HTTP 境界
ホットリロードは子の完全終了を保証しない。mcp.servers を空にしても親プロセスが生きていると npx subtree が残る。openclaw gateway restart だけでは足りないときは systemd や launchd、コンテナの stop→start で冷やす。
多チャネル・大コンテキストはスポーンを増幅する。並列セッションごとにツール探索が走ると、モデル層の再試行と相まって負荷が跳ねる。まず有効サーバを減らし、次にモデルとチャネル、最後にメモリ増設を検討する。
アップグレード直後は plugins と mcp の競合に注意。スナップショットとロールバック手順に沿い、doctor とリリースノートの破壊的変更を突き合わせる。
リバプロのタイムアウトは再接続ストームを招く。再接続のたびに探索が再走しスポーンが増える。WebSocket とアイドル設定を先に整える。
CLI と常駐サービスの版ズレ。グローバル npm とコンテナ内バイナリが混在すると、doctor は緑でも挙動が食い違う。インストール比較で入口を一本化する。
意思決定表：信号 → 仮説 → 行動
| 信号 | 仮説 | 行動 | ガイド |
|---|---|---|---|
| RSS と子数が連動上昇 | stdio リーク | サーバ一覧を収束、コールド再起動、パッチ適用 | MCP アップグレード記事 |
| skipped / http のログ | 輸送ギャップ | stdio ラッパへ寄せるか url 項目を外す | インストール比較 |
| doctor 良好だがユーザー断 | プロキシのアイドル | 読み取り／送信タイムアウトと Upgrade ヘッダ | リバプロ記事 |
| 未知の設定キー | スキーマ変更 | リリースノートで JSON を移行 | MCP アップグレード記事 |
| 小メモリのリモート Mac | 容量不足 | MCP 数削減、並列抑制、プラン見直し | プラン／ノード |
原則は動く部品を減らしてから微調整。メモリを増やす前にプロセス曲線を読むほうが根本原因に近い。
手順スケルトン（How-to）
openclaw status
openclaw gateway status
openclaw logs --follow
openclaw doctor
openclaw channels status --probe
ps aux | rg -i 'openclaw|mcp|npx' || true
openclaw gateway restart
# 不十分なら: sudo systemctl restart openclaw-gateway
# もしくは compose 再起動（インストール手順に従う）
本番ではシェル履歴に秘密を残さない。sudo 境界とログマスキングを Runbook に明記する。
監視項目：感覚を時系列に落とす
ゲートウェイホストに RSS、子プロセス数、開いているファイル記述子、負荷平均、空きディスクを載せる。会話トラフィックと相関させ、子プロセス数のベースライン逸脱でアラートを張ると誤報が減る。
7×24 ゲートウェイと複数 MCP には数 GB 級の余裕と SSD 空きを確保する。ディスク満杯はログローテーション失敗を招き、二次障害になりやすい。
FAQ とホスト型リモート Mac
メモリ増設だけで十分？
一時しのぎにはなるが、リークがあれば再び単調増加する。再起動後に子がゼロに戻るかを必ず確認する。
url だけの MCP はいつ使える？
リリースノートに HTTP クライアントが明記されるまで stdio 前提で設計する。
sessions_spawn 記事との違いは？
そちらはサブエージェント権限。こちらは OS プロセスと輸送境界。順に読むと理解が速い。
まとめ：MCP は監督付きのプロセス艦隊として扱い、輸送の事実をリリースノートに合わせ、リロード不足なら冷たく再起動する。
限界：自前 VPS は OS パッチ、ディスク、リバプロ、常駐プロセスの積み上げが重い。SFTPMAC のホスト型リモート Macは Apple 互換環境と安定オンライン、SFTP 入口を束ね、バイナリ配送とゲートウェイを同じ現場に置きやすい。
プランとノードを確認し、リモート Mac 上のゲートウェイとファイル入口を揃える。