AIツールが重い時に何が起きているか。指示では直せない層がある話

先日、Macにこんな警告が出ました。

アプリケーションメモリが不足しています。

一覧を見ると、ChatGPTアプリが 34.48 GB と表示されていました。
私のMacの搭載メモリは16GBです。
16GBしかない機械で、34GB。
数字がおかしいことは分かりました。
でも、何が起きているのかは分かりませんでした。

この記事は、その原因を実際に調べて分かったことの記録です。

そして最後に、AI活用で意外と見落とされている視点の話をします。

「重い」は感覚ではなく、数字で見られる

まず前提として、「なんか重い」は感覚の話ではありません。

数字で見られます。

調べたら、こうなっていました。

順番に説明します。

専門用語が並んでいますが、たとえ話にすると単純な話です。

メモリとスワップは、机と書庫

パソコンには2種類の置き場所があります。
メモリは、作業机です。

今まさに使っている書類を広げておく場所で、広いほどサクサク動きます。
私のMacは16GB分の机がありました。

ストレージは、書庫です。

しまっておく場所で、取りに行くのに時間がかかります。
ここで スワップ という仕組みが出てきます。
机がいっぱいになると、パソコンは「今すぐ使わない書類」を一時的に書庫へ避難させます。
これがスワップです。

問題は、避難させた書類を使うたびに書庫まで取りに行く必要があること。
机の上なら一瞬なのに、書庫だと何十倍も時間がかかります。
私のMacは、17.5GB分を書庫に避難させていました。

机（16GB）より多い量が、床にあふれていた状態です。
だから、何をやっても重かった。

アプリは1つのプロセスで動いていない

もう1つ、知らなかったことがあります。
「ChatGPTアプリ」と言っても、動いているのは1つではありません。
画面を描く係、通信する係、コードを実行する係。

複数のプロセス、つまり作業員がチームで動いています。

1人1人が机のスペースを取ります。
私のMacでは、ChatGPTアプリだけで 162個 のプロセスが動いていました。

そして、そのうち 122個 が node_repl という同じ名前のプロセスでした。

使い捨てのはずのものが、帰らなかった

node_repl は、コードを実行するために立ち上がるプロセスです。
本来は、仕事が終わったら終了するはずのものです。
ところが、終了せずに残り続けていました。

起動時刻を調べたら、2日以上前のものが生き残ったまま積み上がっていました。
私はChatGPTアプリを 12日間つけっぱなし にしていました。
その間、少しずつ増え続けて、気づいたら122個。

つまり、こういう状態です。

仕事をしていないのに、机を占領している作業員が122人いる。

机（16GB）はとっくに満杯。
あふれた分が床（スワップ17.5GB）に積まれ、最終的にパソコンが「もう置く場所がありません」と警告を出した。
これが、あの34.48GBの正体でした。

机の上と床に積まれた分の合計だったんです。

再起動したら、数字はこう変わった

アプリを完全終了して、起動し直しました。

ウィンドウを閉じるだけではダメです。
プロセスが残ります。
アプリ自体を終了させる必要があります。

結果です。

スワップが17.5GBから4.3GBに落ちました。

床に積まれていた書類が片付いて、机に余裕が戻った。

体感の重さも消えました。

ここからが本題。AGENTS.mdでは直せなかった

さて、原因が分かったので、次に考えたのはこれです。
「再発防止を、AIへの指示で書けないか」
私はAGENTS.mdやSKILL.mdでAIの動きを設計しています。

だから最初に思ったのは、「使い終わったらプロセスを終了する、とルールに書けばいいのでは」ということでした。
結論から言うと、書けません。
設定ファイルを調べたら、node_repl はこう登録されていました。

[mcp_servers.node_repl]
command = "..../node_repl"
startup_timeout_sec = 120

mcp_servers として登録されている。

これは、AIが判断して起動するものではなく、アプリ側が勝手に立ち上げる常駐プロセスだということです。

ここに、層の違いがあります。

AGENTS.mdに「プロセスを終了して」と書いても、AIにはそれを止める手段自体がありません。

アプリが管理している領域だからです。

指示は、届く場所にしか届きません。

「書けば効く」と「書いても届かない」の境界線

これは以前、AGENTS.md、SKILL.md、README、memoryの違い で整理した話と地続きです。

あの記事ではこう書きました。

絶対に破ってほしくない制約は、validator、test、hook、権限まで落とす。

今回はその一段先の話でした。
validatorやhookですら届かない層がある。
AIに何かを守らせたいとき、私たちはつい「どう書けば伝わるか」を考えます。

でも、その前に確認すべきことがあります。

そもそも、AIにその操作ができるのか。

できないことは、どんなに上手く書いても実行されません。

プロンプトの問題ではなく、権限と管轄の問題です。

ここを混同すると、「ちゃんと指示したのにやってくれない」という無駄な試行錯誤が延々と続きます。

では、何が対策になったのか

指示で直せないなら、別の手を考えます。
私が実際に取ったのは、この2つです。
1つめは、定期的なアプリの再起動です。

3〜4日に1回。
単純ですが、確実で副作用がありません。
2つめは、使っていないプラグインを切ることです。
設定を見たら、プラグインが13個も有効になっていました。

そのうちいくつかが node_repl を必要とするものでした。
使っていないものを切れば、そもそもプロセスが生まれる回数が減ります。
こちらは対症療法ではなく、発生源を減らす手です。

なお、「余ったプロセスを自動で終了するスクリプトを組む」という案も検討しましたが、やめました。
調べたら、生きているプロセスの中に正常に使用中のものが混ざっていたからです。
見分ける条件を作れない状態で自動削除を組むと、作業中のものまで巻き添えにします。

自動化は、判別条件が確実に作れるときだけやる。
これも今回の学びでした。

知らないと、原因にたどり着けない

今回いちばん実感したのは、これです。
知らないことは、疑うことすらできない。
私は「なんか重いな」とは思っていました。

でも、12日間つけっぱなしにしていることが問題だとは、まったく思っていませんでした。
そもそも「アプリが複数のプロセスで動いている」ことを知らなかったからです。
知らなければ、その線を疑えません。

疑えなければ、調べません。
調べなければ、いつまでも「Macが古いのかな」で終わります。
実際には、Macは何も悪くありませんでした。

AI活用は、指示の質だけで決まらない

AI活用の話をすると、たいていプロンプトの話になります。
どう書けば伝わるか。
どう設計すればうまく動くか。
大事です。
私もそこに時間をかけています。

でも今回、それだけでは足りないと分かりました。
AIツールは、パソコンの上で動いています。
メモリを使い、プロセスを立ち上げ、リソースを消費します。

動いている環境が壊れていたら、どんなに良い指示を書いても遅い。

これは指示の質ではなく、環境の状態の話です。
そして環境の状態は、感覚ではなく数字で見られます。

見方さえ知っていれば、原因は特定できます。

まとめ

今回分かったことを整理します。

• 「重い」は感覚ではなく、メモリとスワップの数字で確認できる
• アプリは1つではなく、複数のプロセスで動いている
• つけっぱなしにすると、終了し損ねたプロセスが溜まることがある
• 溜まるとスワップがあふれ、パソコン全体が遅くなる
• AGENTS.mdやSKILL.mdは指示層であり、プロセス管理の層には届かない
• 届かない層の問題は、指示ではなく運用（再起動・設定変更）で解く
• 自動化は、判別条件が確実に作れるときだけやる

AI活用でつまずいたとき、原因は指示の中にあるとは限りません。
指示が届かない場所で起きていることもあります。
その切り分けができると、無駄な試行錯誤がかなり減ります。

まずは、自分が使っているツールを何日つけっぱなしにしているか。
そこから確認してみてください。

参考

• OpenAI: Custom instructions with AGENTS.md
• OpenAI: Agent Skills
• Anthropic: Claude Code memory