ファンが止まらなかった。
Claude CodeにNotebookLM MCPを繋いで数日。最初は快適だった。「NotebookLMにソースを追加して」「要約して」がターミナルから一発でできる。ブラウザを開かなくていい。最高だと思った。
3日後、Macのファンが全力で回り始めた。Activity Monitorを開いたら、NotebookLM MCPのプロセスが120個に増殖していた。CPU使用率2800%。スワップ8.5GB。マシンは事実上フリーズしていた。
これは notebooklm-mcp（npm、v1.2.1） の話だ。npx notebooklm-mcpで起動するやつ。
NotebookLM関連のMCPパッケージはnpm・PyPI合わせて6つ以上あって名前が紛らわしい。代表的なものだけでも：
| パッケージ | 言語 | 備考 |
|---|---|---|
notebooklm-mcp |
npm | ← 今回の犯人 |
notebooklm-mcp-server |
npm | 別パッケージ。v3系。未検証 |
notebooklm-mcp |
PyPI | Python版。FastMCP v2ベース。未検証 |
notebooklm-py |
PyPI | MCPサーバーではなくCLI/APIツール。別物 |
この記事で書いているのはnpmのnotebooklm-mcpだけ。他のパッケージで同じ問題が起きるかは未検証なので、混同しないでほしい。
何が起きていたのか
Claude CodeのMCPサーバーは、セッション開始時に起動する。問題はセッション終了時に確実に終了しないケースがあること。
NotebookLM MCPの場合、内部でヘッドレスブラウザ（Puppeteer）を使っている。MCPプロセス自体が終了しても、子プロセスのブラウザが残る。さらに、Claude Codeのセッションを開くたびに新しいMCPプロセスが立ち上がる。
つまり：
セッション開始 → MCPプロセス起動 → ブラウザ起動
セッション終了 → MCPプロセス終了（不完全）→ ブラウザ残留
次のセッション → 新MCPプロセス起動 → 新ブラウザ起動
さらに次 → さらに新プロセス → さらにブラウザ……
これが数日繰り返されて、120プロセスになった。
発見の経緯
最初はzshの起動が遅いのかと思った。直前に.zshrcをいじっていたからだ。でもtime zsh -i -c exitは0.04秒。問題ない。
次にClaude Code自体を疑った。でも再起動しても重い。
Activity Monitorを開いてCPU順にソートした瞬間、画面が真っ赤だった。nodeプロセスが大量に並んでいる。全部NotebookLM MCP関連。
ps aux | grep -i notebooklm | grep -v grep | wc -l
127。
殺しても死なない
最初にやったのはkill。
ps aux | grep -i notebooklm | grep -v grep | awk '{print $2}' | xargs kill
一時的にプロセスは消える。CPUも下がる。よし、解決——と思ったら、Claude Codeで次のプロンプトを送った瞬間にまた増え始めた。
MCPの設定が残っている限り、セッション開始のたびに再スポーンする。killは対症療法にすぎない。
正しい対処法
1. MCPの設定を外す
claude mcp remove notebooklm
これが根本対策。設定から外せば、次のセッションでプロセスは起動しない。
「でも使いたいんだけど」——わかる。自分もそうだった。でもプロセスリークを起こすMCPは、修正されるまで外しておくのが正解だ。使いたいときだけclaude mcp addして、終わったらclaude mcp removeする運用もある。面倒だが、Macが死ぬよりマシだ。
2. 残留プロセスを全部殺す
設定を外した後、残っているプロセスを掃除する。
# NotebookLM関連のプロセスを確認
ps aux | grep -i notebooklm | grep -v grep
# 確認してから一括終了
ps aux | grep -i notebooklm | grep -v grep | awk '{print $2}' | xargs kill -9
# Puppeteer（ヘッドレスChrome）も残っている可能性がある
ps aux | grep -i "chromium\|chrome.*headless" | grep -v grep
3. 再発防止：MCPプロセスの定期チェック
自分はこのスクリプトを使っている。
#!/bin/bash
# mcp-check.sh — MCPプロセスの増殖チェック
MCP_COUNT=$(ps aux | grep -i mcp | grep -v grep | wc -l | tr -d ' ')
if [ "$MCP_COUNT" -gt 10 ]; then
echo "⚠️ MCPプロセスが${MCP_COUNT}個検出されました"
echo "以下のコマンドで確認してください："
echo " ps aux | grep -i mcp | grep -v grep"
echo ""
echo "不要なMCPを外すには："
echo " claude mcp remove [名前]"
fi
10個を超えたら警告。日常的に5個以上あるなら、使っていないMCPが設定に残っている可能性が高い。
NotebookLM MCP以外も危ない
この問題はNotebookLM MCPに限った話ではない。ヘッドレスブラウザを内部で使うMCPサーバーは、同じリスクを抱えている。
具体的に注意すべき特徴：
- Puppeteer / Playwright を依存に持っている
-
npx経由で起動するタイプ（キャッシュの問題もある） - 認証が必要なWebサービスに接続する（セッション維持のためにプロセスが残りやすい）
MCPを新しく繋ぐときは、数時間後にActivity Monitorでプロセス数を確認する癖をつけた方がいい。
「繋いですげー」の裏側
MCPは便利だ。自分もClaude Codeに10個以上繋いでいる。ChatworkもGmailもGoogle Calendarも、MCPで繋いでターミナルから操作できるのは本当に楽だ。
でも「MCPを10個繋いだらブラウザを開かなくなった」という話と「MCPのプロセスが120個に増殖してMacが死んだ」という話は、同じコインの裏表だ。
MCPサーバーは結局、裏でプロセスが動いている。それが正しくクリーンアップされるかは、各MCPサーバーの実装に依存する。公式のMCPサーバー（GitHubやファイルシステム系）は概ね安全だが、コミュニティ製のMCPサーバーは自分で確認するしかない。
導入の「すげー」は3分で味わえる。でもそのプロセスが裏で何をしているか、終了時にちゃんと死んでくれるかは、数日使ってみないとわからない。
確認コマンドまとめ
# 現在のMCPプロセス数
ps aux | grep -i mcp | grep -v grep | wc -l
# プロセス一覧（CPU順）
ps aux | grep -i mcp | grep -v grep | sort -k3 -rn
# Claude Codeに登録されているMCP一覧
claude mcp list
# 不要なMCPを外す
claude mcp remove [名前]
# nodeプロセスの確認（MCPはnodeで動くものが多い）
ps aux | grep node | grep -v grep | wc -l
まとめ
MCPは便利だが、繋ぎっぱなしにはリスクがある。
- 使っていないMCPは
claude mcp removeで外す - Activity Monitorを時々見る
- ファンが回り始めたら、まずMCPを疑う
-
killだけでは解決しない。設定を外すのが根本対策
120プロセスの地獄を経験して学んだ。MCPを「信用する」前に、プロセスを「監視する」方が先だ。
MCPのプロセス増殖、経験した人いますか？ どのMCPサーバーで起きたか、コメントで教えてもらえると助かる。