Chrome DevTools MCPが33個のNodeを起動していた：メモリ2.12GBの内訳

開発claude-code-tools

Chrome DevTools MCPが33個のNodeを起動していた：メモリ2.12GBの内訳

タスクマネージャーで node.exe を数えると、47プロセスが並んでいた。Nuxtの開発サーバーだけでは説明がつかない。親子関係と起動引数をたどると、そのうち33プロセスが chrome-devtools-mcp に集まった。

さらに1セットを分解すると、ブラウザを操作するMCP本体だけでなく、npxのパッケージ起動係とGoogle利用統計用watchdogが1個ずつ常駐していた。本記事では、Windows 11上で計測したメモリの内訳と、利用統計を止める方法を記録する。

結論

  • Chrome DevTools MCPは、今回の構成では1接続につき3個のNodeプロセスを起動した
  • 内訳はMCP本体、npx package runner、利用統計watchdog
  • 11接続で合計33プロセス、固有RAMは約2.12GBだった
  • --no-usage-statistics を付けるとwatchdogを起動せず、今回の構成では約409MBを削減できる
  • 最大の削減策は、ブラウザ操作を使わないセッションでMCP自体を起動しないこと

対策後のメモリを再計測した

利用統計watchdogとCodex側のChrome DevTools MCPを止めたあと、Windows全体をもう一度計測した。最新のスナップショットでは、搭載31.93GBのうち25.34GBを使用し、空きは6.59GB、使用率は79.4%だった。再計測の間は79〜81%で動き、調査中に最大88%まで上がっていた使用率は一段下がった。

アプリ別のPrivate Working Setは次のとおりだった。共有メモリを含むWorking Setはプロセス間で同じ領域を数えるため、ここでは実際に解放を期待しやすい固有RAMを並べている。

アプリプロセス数固有RAM合計
Chrome315,617.6MB（約5.49GB）
Node.js253,978.0MB（約3.88GB）
Claude Code61,627.5MB（約1.59GB）
ChatGPT11922.7MB（約0.90GB）
Windows Defender1520.0MB（約0.51GB）
Aqua Voice8407.1MB（約0.40GB）
SQL Server1387.8MB（約0.38GB）
Dropbox7241.1MB（約0.24GB）

対策前後でNode.jsは47プロセスから25プロセスへ減った。Chrome DevTools MCPに関係するNodeは33個から10個へ減り、内訳はClaude Codeの5セッションが持つ「MCP本体＋npx runner」の5セットだった。利用統計watchdogは11個から0個、Codex配下のMCPも0個になった。VS Codeは終了済みで、Code.exeは残っていなかった。

約25GBを全体で分ける

ChromeとNode.jsだけを足すと約9.4GBになる。それでも使用中の25.34GBには約16GB残るため、全プロセスのPrivate Working SetとWindows側の領域まで分けた。

区分実RAM使用中メモリに占める割合
Chrome約5.49GB21.7%
Node.js約3.88GB15.3%
Claude Code約1.59GB6.3%
ChatGPT約0.90GB3.6%
その他すべてのプロセス約4.21GB16.6%
Windows・共有メモリ・カーネル約9.28GB36.6%
合計約25.34GB100%

小さいアプリは確かに積み上がっていたが、Chrome、Node.js、Claude Code、ChatGPT以外のプロセスを全部足しても約4.2GBだった。残る約9.3GBは、カーネル、ドライバー、共有DLL、メモリマップ、ページテーブルなど、タスクマネージャーのアプリ欄へそのまま現れない領域だった。

確認できた範囲では、カーネルのページプールと非ページプールが合計約2.4GB、システムキャッシュが約0.8GBを使っていた。一方、スタンバイキャッシュ約4.4GBは空き6.59GBの側に含まれ、アプリが要求すればWindowsが自動で明け渡す。手動で空にしても持続的な削減にはならない。計測時はページファイルへの継続的な読み書きも発生しておらず、使用率79%でもメモリ不足に陥った状態ではなかった。

Node.jsの約97%はNuxtとDevTools MCPだった

25個のNode.jsを用途別に分けると、細かなツールがRAMを食い尽くしていたわけではなかった。

用途プロセス数固有RAM合計
Nuxt／Vite開発サーバー4約2.24GB
Chrome DevTools MCP本体5約1.55GB
Chrome DevTools npx runner5約15MB
学習クイズサーバー10約34MB
Codex内部Node1約50MB

Nuxt／ViteとDevTools MCP本体の2種類だけでNode.jsの固有RAMの約97%を占めた。特にNuxtのメインプロセス1個が約2.20GBを保持していたため、ローカル確認を終えて開発サーバーを止めれば約2.2GBを戻せる。

5つのClaude CodeセッションがすべてChrome DevToolsを使うなら、5個のMCP本体が使う約1.55GBは並列作業の必要経費になる。現在のMCP本体は1セッションあたり約313〜328MBだった。5セッションを維持したまま3セッションでMCPを読み込まない構成にできれば、MCP分だけで約0.9GBを減らせる。

Chromeは11タブから24レンダラーへ分かれていた

Chromeにはトップレベルのタブが11枚あり、その下で24個のレンダラープロセスが約5.19GBを保持していた。11枚の内訳はlocalhostの開発ページ7枚、ローカルHTML 2枚、XとClaudeが各1枚だった。同じ図解ページを開いたタブも2枚あった。

Chromeはタブだけでなく、iframe、拡張機能、Service Worker、サイト分離でもレンダラーを増やす。そのため「11タブなのに24プロセス」は異常とは限らない。ただし、確認を終えたローカルページや重複タブを閉じれば、現在の環境では最も大きい約5.5GBへ直接手を入れられる。タブごとの正確な使用量はChromeのタスクマネージャー（Shift + Esc）で確認できる。

5セッション運用で現実的に削れる範囲

5セッションを同時に動かす前提では、正体不明の大きな無駄は残っていなかった。削減候補は次の順になる。

  1. ローカル確認後にNuxt開発サーバーを止め、約2.2GBを戻す
  2. Chrome DevToolsを使うClaude Codeセッションを限定し、1セッションあたり約0.3GBを減らす
  3. Chromeの古いローカルプレビューと重複タブを閉じる
  4. DB開発をしない時間はSQL Serverを止め、約0.4GBを戻す
  5. Aqua Voice、Dropbox、LINEなどを使わない時間だけ終了する

Windows Defender、svchost、メモリ圧縮、Windowsのカーネル領域は停止対象にしない。利用統計watchdogとCodex側の不要なMCPはすでに取り除いたため、残るメモリ消費の中心は「5セッションを並列に動かす」「Nuxtを起動する」「Chromeでプレビューを並べる」という作業そのものだった。

計測環境

項目値
OSWindows 11 Pro 25H2
搭載メモリ32GB
Node.js22.22.2
chrome-devtools-mcp1.7.0
起動方法npx chrome-devtools-mcp@latest --autoConnect
同時利用Claude Code 5セッション、Codexデスクトップ1タスク

数値は一時点のスナップショットであり、接続中のページ、MCPの稼働時間、Windowsのメモリ圧縮によって変動する。共有ライブラリを二重計上しないよう、削減効果の判断にはPrivate Working Setを使った。

1接続が3個のNodeへ分かれる

実際のプロセスツリーは次の形だった。

Claude Code / Codex
└─ npx.exe
   └─ node.exe  npx-cli.js
      └─ cmd.exe  chrome-devtools-mcp --autoConnect
         └─ node.exe  chrome-devtools-mcp.js
            └─ node.exe  telemetry/watchdog/main.js

3個の役割は異なる。

  1. npx-cli.jsはnpmキャッシュから対象パッケージを解決し、MCP本体を起動して終了を待つ
  2. chrome-devtools-mcp.jsがMCPリクエストを受け、Chrome DevTools Protocol経由でブラウザを操作する
  3. telemetry/watchdog/main.jsが利用統計を別プロセスで送信する

--autoConnect は既存のChromeへ接続する指定であり、3プロセス化の原因ではない。

11接続・33プロセスのメモリ内訳

役割プロセス数固有RAM合計共有込みRAM合計1個あたり固有RAM
MCP本体111,505.2MB1,946.2MB136.8MB
npx package runner11205.4MB647.3MB18.7MB
利用統計watchdog11409.1MB849.9MB37.2MB
合計332,119.7MB3,443.4MB—

利用統計watchdogだけで固有RAMを409.1MB保持していた。1個なら37MBでも、会話やセッションごとにMCPサーバーが立ち上がると同じプロセスが横へ並ぶ。

接続元を追うと、Claude Codeの5セッションが1セットずつ、Codexデスクトップ配下が6セットを起動していた。Claude Code側は設定の二重登録ではなく、各セッションが専用のstdio MCPサーバーを持つ構成だった。公式READMEにも、多くのMCPクライアントは会話ごとにサーバーを1つ起動すると記載されている。

→ Chrome DevTools MCP公式：Concurrent sessions

利用統計watchdogは何をしているか

インストール済みパッケージのコードを確認すると、usageStatistics が有効な場合だけ ClearcutLogger を初期化し、そのコンストラクターから WatchdogClient が別のNodeプロセスをspawnしていた。watchdogはMCP本体から標準入力でイベントを受け取り、ツール呼び出しの成否、レイテンシ、環境情報などを送信する。

利用統計はデフォルトで有効だが、ブラウザ操作そのものには必要ない。Chrome本体の利用統計設定とも独立している。

→ Chrome DevTools MCP公式：Usage statistics

利用統計を無効化する

MCPサーバーの引数へ --no-usage-statistics を追加する。

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "chrome-devtools-mcp@latest",
        "--autoConnect",
        "--no-usage-statistics"
      ]
    }
  }
}

環境変数でも無効化できる。

CHROME_DEVTOOLS_MCP_NO_USAGE_STATISTICS=1

設定は次回起動するMCPサーバーから反映される。すでに動いているwatchdogは自動では消えないため、親のClaude CodeやCodexセッションを閉じるか、コマンドラインでwatchdogと確認できたPIDだけを終了する。node.exeを名前で一括終了すると、Nuxt、Claude Code、MCP、エディタ拡張まで巻き込むので避ける。

今回の環境では、11個のwatchdogをPID指定で停止し、残数が0になったことを確認した。MCP本体は停止せず、Chrome操作機能を維持した。

さらに減らすならMCPを必要時だけ起動する

利用統計を止めても、MCP本体とnpx runnerは残る。今回の固有RAM2.12GBのうち、MCP本体が1.51GBを占めた。メモリを大きく戻すには、ブラウザを操作しないClaude CodeセッションでChrome DevTools MCPを読み込まない運用へ切り替える必要がある。

npx runnerはパッケージの自動取得と最新版追従を担う。chrome-devtools-mcpを固定インストールして実体を直接起動すれば約205MBとWindows上のシェルラッパーを減らせるが、更新を自分で管理することになる。最初に外すべきなのは、機能に影響しない利用統計watchdogと、使っていないセッションのMCP本体だ。

計測してわかったこと

プロセス一覧で node.exe を一括りにすると、Nuxtのメモリ増加とMCPの多重起動が混ざる。起動引数、親PID、Private Working Setを同時に見ると、47個のNodeが「Nuxt 4個」「Chrome DevTools MCP 33個」「その他10個」へ分かれた。

「Nodeが多い」で止めず、どの親が何を何個起動したかまで数える。そうすると、アプリ本体を壊さずに409MBだけ切り離せた。

#Claude Code #Codex #Chrome DevTools #MCP #Node.js #メモリ