OpenClaw Gateway と stdio MCP は動いているのに、本番で子プロセス数の緩やかな増加、RSS の上昇、偶発的な OOM が出て、設定を直すべきかアーキテクチャを変えるべきか迷う場合があります。本稿は MCP stdio/HTTP ハンドシェイクと固着の切り分け、Gateway 本番の観測 と役割分担し、まず 7 項目のチェックで境界を引き、stdio と HTTP の運用対照表でトレードオフを整理し、6 ステップの回収とレート制限 Runbook と systemd/Docker における環境変数・再起動方針を述べます。末尾では OpenClaw 一覧 とコンピュート利用シーンへ誘導します。
stdio MCP の接続ハンドシェイク、固着、権限拒否 は ハンドシェイク編 を、許可リストとツール方針 は MCP ツールチェーン許可リスト編 を、ヘルスチェック、ログ、アップグレード／ロールバック は 観測編 を優先します。本稿が答えるのは、Gateway がセッションを安定して受け入れているのに子プロセスとメモリ曲線が許容できないときに、どう層別に運用するかです。
初回ハンドシェイク失敗： MCP トランスポートと下流の実行パスを見る領域であり、本稿では展開しません。
トークン／スコープと gateway closed (1000)： 専用の closed(1000) 記事を参照し、回収スクリプトの変更ではありません。
純粋なセキュリティ方針： dmPolicy / networkPolicy の変更はハードニング編へ。
Gateway が起動しない／not ready： ポート、メモリ、compose 順の not ready 切り分け記事を先に。
アプリ層のモデルバックエンドタイムアウト： MCP 子プロセス運用と並行して調べられますが、根本原因はモデルルーティング側かもしれません。
サードパーティ MCP 実装の一回限りのリーク： 上流修正かバージョン固定が必要で、回収は緩和にとどまります。
「掃除」を万能薬にすること： 水位とバージョン台帳のない強制終了は、真のリーク箇所を隠します。
OSS の議論では、stdio MCP が Gateway の子プロセスとして長時間セッションを張ると、セッションに応じてプールが膨らむことがあります。挙動はリリースごとに変わるため、運用では「許容プロセス上限＋回収方針」を当番手順に書き、デフォルト任せにしない方がよいです。まず セッション分離から想定される蓄積 のモデルを置き、対照表に進みます。
ハンドシェイク編との接点は、失敗時はログに接続／ハンドシェイクエラーが出ることです。本稿の典型シグナルはプロセス数の単調増加、段階的なメモリ上昇、一定周期での OOM killer です。切り分けでは Gateway 親と MCP 子の親子関係を（ps やコンテナ内 pstree で）確認し、モデルバックエンドやチャネルプロセスを MCP に数えないようにします。
複数のツールチェーン（ローカルスクリプトとリモート Mac 上の常駐エージェントなど）を動かす場合、どのホストに Gateway を置き、どこに重い MCP を置くかをトポロジに描くとよいです。Gateway ノードのメモリ余裕が、並行 stdio セッションの上限を決めます。キャパシティと接続の説明は 料金ページ とヘルプセンターのネットワーク要件と併せてください。
観測では少なくとも 3 系列を取ることを推奨します：プロセス数、Gateway と MCP の RSS、ツール呼び出し QPS とセッション数。セッション次元がないと、「蓄積」がピークか回収漏れか判断できません。観測編 のログ項目と揃えたうえでダッシュボードで週次比較しないと、当番は感覚で再起動するだけになります。
「子プロセスが多い＝HTTP に切り替え」と短絡するのも典型誤りです。ツールが極めて軽く並行も低いなら、セッションが閉じていない か 下流バイナリがブロック している可能性が高く、まずクライアント側のセッション寿命を締めてからトランスポート移行コストを見積ります。
stdio トランスポートは MCP サーバーを Gateway のライフサイクルに子プロセスとして強く結合します。HTTP トランスポートは独立したエンドポイントに近く、スケールとヘルスチェックの経路が異なります。下表は「stdio をさらに最適化するか」「HTTP に上げるか」のレビューに使います。
| 次元 | stdio MCP | HTTP MCP |
|---|---|---|
| プロセス結合 | 子プロセスは Gateway／セッションモデルに従い、蓄積を感じやすい | 多くの場合独立プロセスで Gateway はクライアント |
| 水平スケール | Gateway の同時拡張かセッション制限が必要になりがち | MCP サービスだけレプリカを増やせる |
| ヘルスチェック | Gateway ログとプロセス表に依存 | HTTP プローブと独立 SLO |
| 障害の爆発半径 | 子の問題が同ホストの Gateway を遅らせやすい | 隔離は良いがネットワークが 1 ホップ増える |
| 向く場面 | 軽いツール、低並行、同一ホストで信頼できる | 重いツール、高並行、独立リリースが必要 |
「ガバナンス」とは機械を無限に積むことではなく、プロセスとメモリ曲線 に契約を置くことです。契約を超えたらレート制限、回収、またはトランスポート変更です。
stdio/HTTP ハンドシェイク編 で設定は正しいと確認済みでも、メモリの赤線付近が続くなら、ホストを際限なく上げるのではなく「HTTP 化」をアーキテクチャレビューに載せます。
手順は「まず証拠、次にレート制限、最後にアーキテクチャ」です。観測編 のログ項目と揃え、ログなしの強制終了を避けます。
ベースライン： 安定負荷時のプロセス数、RSS、Gateway バージョン、MCP パッケージバージョンを変更台帳に記録します。
スパイクとリークの分離： スパイクは多くの場合並行セッションに連動します。単調増は回収漏れや下流ハングの可能性があり、スタックを取ります。
並行とタイムアウトの締め： 設定の範囲で並列ツール呼び出しを下げ、アイドルタイムアウトを短くし、曲線がセッション数とともに下がるか観察します。
計画回収： メンテナンス窓で Gateway をローリング再起動するかノードを切り離し、先にセッションをドレインします。
コンテナと systemd： 環境変数が実際の実行環境に届いているか確認します（デーモンと対話シェルの不一致はよくある落とし穴です）。
HTTP 移行の評価： 重い MCP や独立スケールが必要なサービスは別デプロイとヘルスチェックを置き、Gateway 側を HTTP トランスポートに切り替えます。
ps -axo pid,ppid,rss,comm | grep -E 'openclaw|mcp|node' | head -n 50 # コンテナ内では pstree -p 1 と併用して親子を確認
ヒント： openclaw.json を編集したら、サイト文書の推奨どおり検証コマンド（例 config:validate / doctor）を実行してからローリング再起動し、「設定は反映したつもりだがプロセスは古い値」の状態を避けます。
GitHub Issue では「stdio MCP の子がセッション交代時に回収されない」という報告もあり、運用では定期回収とバージョン追跡を暫定策としつつ上流修正を追います。文書化されていない手動 kill に長期依存しないでください。
systemd のタイマーや k8s CronJob などでサイドカー回収を使う場合は、Gateway の起動ユーザー、環境変数、cgroup のメモリ上限を揃えます。そうしないとスクリプトが見るプロセス木と本番が食い違い、切り分けで対立します。小さな単一ノードでは、まず設定で並行とタイムアウトを契約内に収め、サイドカーの複雑さは後回しにするのが無難です。
最後に、回収やレート制限の変更は必ずリリース版と紐づけます。stdio の挙動は Gateway のマイナーで変わり得て、版を揃えない曲線比較は意味がありません。
systemd ユニットは対話式 ~/.zshrc を継承しません。Docker Compose では MCP の実行ファイルパスや読み取り専用マウントが原因で子がループ再起動することもあります。Docker 本番記事 を踏まえ、Environment=、WorkingDirectory=、名前付きボリューム、イメージ digest を確認します。
注意： 前回の終了コードを見ずに docker compose restart を繰り返すと、設定ミス を メモリリーク と誤認しやすくなります。
not ready 切り分け編 とセットで：メモリ不足では Gateway が安定した MCP セッションに入る前に止まることがあり、先にリソースと起動順を直します。
以下の数値はよく使う出発点であり、実負荷に合わせて調整してください。
エージェントと Gateway を不安定な小メモリノードに詰め込むと「ツールチェーンとモデルの二重ジッター」が起きます。マシンを足すだけでセッションモデルを変えなければコストは線形に膨らみます。macOS 上のビルドや自動化を長期オンラインで予測可能な算力で回し、OpenClaw 周辺にも余裕を残したいチームには、固定 SSH と明確なスペックを持つ NodeMini の Mac Mini クラウドレンタル が、ノートや過剰共有ホストを寄せ集めるより有利なことが多いです。まず 料金 を確認し、ヘルプセンター でネットワークと接続要件を照合してください。
運用では「stdio セッション上限＋回収方針＋ HTTP 移行のトリガー」を同一の運用契約ページに書き、開発と SRE が同じ指標でレビューします。
外部向けの事後分析にはプロセススナップショットとログ抜粋を添え、設定ミスと上流欠陥を切り分けやすくします。
必ずしもそうではありません。セッション分離による想定内の増加とリーク様の蓄積を切り分け、RSS と Gateway バージョンで既知の問題を照合します。必要なら修正版へ上げ、cron だけ足すのではありません。
子プロセスの寿命がセッションモデルと長期整合しにくい、またはノードのメモリ余裕が続けて不足し水平拡張も難しいとき、HTTP MCP の方が独立スケールとヘルスチェックをしやすいことが多いです。背景は OpenClaw 一覧 も参照してください。