CPUもメモリもGPUも余っているのに、PCが重いのはなぜですか？

利用率のパーセンテージは、待ち時間を表示できないためです。実測でよくある原因は、実空きページの枯渇と、内蔵GPUの共有メモリ、そして描画に使われるメモリ帯域です。いずれもCPU使用率にもGPU使用率にも現れません。メモリ128GBのマシンで「利用可能 49GB」と表示されている状態で、実空きが 0.00GB だった例があります。この状態ではメモリを確保するたびにゼロ埋め待ちが入り、GPUがそれに当たると画面とマウスが止まります。株式会社IIWAYO.TECH では、まず実空きページを実測してから原因を絞り込んでいます。

タスクマネージャーの「利用可能」と、実空きメモリは何が違いますか？

「利用可能」は、実空き（ゼロ埋め済み）とスタンバイの合計です。スタンバイは他のプロセスが使っていた内容が残っているキャッシュなので、再利用の前にゼロ埋めの工程が入ります。つまり「利用可能 18GB」と表示されていても、即座に使えるページは 1GB しかない、ということが起こります。体感の引っかかりと相関するのは実空きのほうです。Windows は搭載量に関わらず空きをスタンバイへ回すので、実空きが小さいこと自体は正常な挙動です。

AIコーディングエージェントを使っているとPCが重くなるのはなぜですか？

セッションが異常終了したとき、MCPサーバーやフックの子プロセスが親を失って残るためです。実測では、停止したフックプロセスが55件、全件がCPU使用時間0秒で、最も古いもので6.5日間生き残り、合計約2.6GBを保持していました。CPUを使わないので使用率順に並べても見つかりません。OpenAI の Codex リポジトリにも Issue #26984 や Issue #12491 として同種の報告があり、ツール側の既知の課題です。

メモリを増設すれば、この症状は解決しますか？

増設の前に、同じ構成で問題が出ていない機体と数値を比べてください。実例として、メモリ1枚挿しのシングルチャネル構成が原因だと考えて約8万円の増設を検討したケースがありますが、同じ機種で快適に動いているPCも同一構成でした。その時点で、シングルチャネルは症状を説明できないと分かります。無料の実験を全部やってから有料の判断をしてください。無料の実験は、買い物が効くかどうかの判定を兼ねています。

社内に同じ機種が無い場合は、どう切り分ければいいですか？

「安い順」に候補を潰します。孤児プロセスの確認、実空きページの解放、画面の枚数と解像度を下げる、専用VRAMの割り当て変更、最後にメモリ増設という順番です。それぞれ1回に1つだけ変えて、数値と体感の両方を採ってください。数値は「効いた」ことしか言いません。効果があったかどうかは人にしか判断できません。そして必ず、重いと感じている最中に測ってください。アイドル時の測定は「異常が出ていない状態」を測っているだけです。

AgentReaper は何をするツールですか。無料で使えますか？

AIコーディングエージェントが残した孤児の子プロセスを回収し、あわせてメモリとグラフィックスの状態を測る Windows 常駐ツールです。MITライセンスで公開しており、無料で使えます。C#で約3,000行、Windowsに同梱のコンパイラでビルドするため .NET SDK も npm も不要です。汎用の高速化ツールではなく、1つの故障モードだけを対象にしています。ドライランを人が確認して承認するまで、設定を変えても何も終了しません。

PCが重いのにCPUもメモリも余っている理由と、同型機を使った切り分け手順

— 数値をしきい値と比べている限り、この症状は切り分けられません —

タスクマネージャーが全部「余裕あり」と言っているのに、マウスが一瞬止まる

CPU 数パーセント。メモリ使用率 40 パーセント。GPU も数パーセント。ディスクもほぼ動いていない。

それで、ウィンドウを切り替えるとワンテンポ遅れる。文字を打つと、たまに引っかかる。マウスカーソルが、コンマ数秒だけ固まる。

私はこの状態のPCを2台抱えていて、片方については 32GB のメモリを追加で買う直前まで行きました。金額にして約8万円です。

結局、買いませんでした。買わなくて正解でした。同じ機種をもう1台使って比べたら、疑っていた原因が3つとも消えたからです。

しかも、消え方が面白かった。快適に動いているほうの機体のほうが、数値は悪かったのです。

この記事は、その切り分けの記録です。使ったコマンドは全部そのまま載せます。私が最初にやった「数値をしきい値と比べる」というやり方が、なぜ確信を持って間違った結論に着地するのかも書きます。

まず「利用可能」という数字を疑うところから始まりました

Windows のタスクマネージャーには「利用可能」という数字が出ます。32GB のマシンで 18GB 利用可能、と表示されていれば、普通は「まだ余っている」と読みます。

ところが、この数字は空きメモリではありません。

Windows のメモリは、大きく分けて次の状態を持ちます。

状態	中身	すぐ使えるか
実空き（Free + Zeroed）	誰も使っておらず、ゼロ埋め済み	そのまま使える
スタンバイ（Standby）	他のプロセスが使っていた内容が残っているキャッシュ	使う前にゼロ埋めが要る
変更済み（Modified）	書き戻していない内容	ディスクへ書いてから
使用中	プロセスが握っている	使えない

タスクマネージャーの「利用可能」は実空きとスタンバイの合計であることを示す図。32GBのマシンで「利用可能18GB」と表示されていても実空きは1GBしかない例と、メモリ128GBのマシンで「利用可能49GB」表示のときに実空きが0.00GBだった実測値

タスクマネージャーの「利用可能」は、実空き + スタンバイです。つまり、実空きが 1GB しかなくてもスタンバイが 17GB あれば「18GB 利用可能」と表示されます。

なぜこれが体感に効くのか。スタンバイのページを再利用するには、中身を消す（ゼロ埋めする）工程が挟まります。実空きが枯渇していると、新しくメモリを確保するたびにこのゼロ埋め待ちが発生します。

そして、GPU が同期的にメモリを要求した瞬間にそれが起きると、画面とマウスが止まります。 アプリケーションが待たされるのではなく、描画そのものが待たされるので、体感としては「PC全体が固まった」と感じます。

私のメイン機（メモリ 128GB）で実測したときは、「利用可能 49GB」と表示されている状態で、実空きが 0.00GB でした。49GB 余っているように見えて、実際には 1 バイトも即座に使えるページが無い。この状態でマウスが止まっていました。

ここまでは、原因の候補としては筋が通っています。問題は次からです。

内蔵GPUは、その「実空き」と同じ池から水を汲んでいます

なぜ GPU の話が出てくるのか。ここが分かりにくいので、実測を交えて説明します。

内蔵GPU（CPU に同居しているグラフィックス）には、専用に確保された VRAM があります。ただし、この容量はファームウェアの設定で決まっていて、多くの機種では初期値が控えめです。

私のメイン機を測ったときの値です。メモリ 128GB を積んだマシンですが、

専用VRAM は 2,048MB（2GB）。UEFI の初期設定が「自動」のままでした
そのうち 1,726MB を使用中。使用率 84%
収まりきらなかった 2,239MB が、共有システムメモリへ退避していました

問題はこの「共有システムメモリ」です。これは実空きページと同じプールから取ります。 つまり、専用VRAM が足りない分だけ、GPU がシステムメモリの空きを食っている状態でした。

そして、GPU がメモリを要求するタイミングは選べません。画面を描くたびに必要になります。実空きが枯渇していれば、そこでゼロ埋め待ちが発生します。アプリが待つのではなく、描画が待つ。 だから体感が「PC全体の停止」になります。

このとき、デスクトップの描画を担当するプロセス（DWM）のコマ落ち率を測ると 11% ありました。10 フレームに 1 枚以上落としている計算です。数値としては地味ですが、マウスカーソルの動きとしては明確に分かります。

ファームウェアで専用VRAM を 32GB に引き上げたところ、

DWM のコマ落ち率 11% → 0%
共有メモリへの退避 1,483MB → 327MB

になりました。ただし、この変更は再起動を伴います。再起動そのものの効果と分離できていないので、「VRAM が原因だった」と断定はしていません。 負荷が元に戻った状態でもう一度測るまでは、確定として扱わないことにしています。

ちなみに、専用VRAM の割り当ては上げれば上げるほど良いわけではありません。この機種で最大値の 96GB を指定したところ、実使用 80GB に対して OS から見えるメモリが 31.7GB まで減って破綻しました。上限は 32GB が妥当でした。

「メモリが足りないのではなく、GPU に取られている」「GPU に取られているのではなく、割り当てが小さいせいであふれている」。この構造が分かっていないと、メモリを足しても解決しません。

AIエージェントは、子プロセスを置き去りにします

なぜ実空きが枯渇するのか。私の環境では、犯人のひとつがはっきりしていました。

Claude Code や Codex、Cursor を一日中動かしていると、MCP サーバーやフックスクリプトが絶えず起動されます。ほとんどは正常に終了します。しかし、セッションが異常終了したとき、その子プロセスは親を失って残ります。

自分の環境を数えたときの実測値です。

停止したフックプロセス 55 件。全件が孤児で、全件が CPU 使用時間 0 秒。 最も古いもので 6.5 日（9,318 分）生き残っていました。合計で約 2.6GB
1 つのエージェントクライアントの配下に、孤児になった MCP サーバーが 23 件。21 時間気づきませんでした

CPU を使っていないので、タスクマネージャーを CPU 順に並べても見つかりません。1 件あたり数十 MB なので、メモリ順に並べても上位に来ません。数だけがじわじわ増えて、実空きページだけが静かに減っていきます。

これは私の環境固有の話ではありません。開発元にも報告が積み上がっています。

OpenAI の Codex リポジトリには、MCP stdio サーバーがパイプのファイルディスクリプタと孤児の子プロセスを蓄積し、最終的に "Too many open files" で機能停止する不具合（Issue #26984）が報告されています。4〜5 個の MCP サーバーを設定したセッションで、本来 15 本程度で済むはずの匿名パイプが 186 本まで積み上がり、その超過分が孤児プロセスとほぼ 1 対 1 で対応していた、という内容です。

さらに極端な例として、GUI 版で MCP の子プロセスが回収されず、ゾンビが 1,300 件以上、メモリリークが 37GB に達した報告（Issue #12491）もあります。

つまり、これは「使い方が悪い」話ではなく、ツール側の既知の課題です。修正が入るまでの間、利用者側で回収するしかありません。

そこで、回収するツールを自分で書きました。

測るためのツールを先に作りました

AgentReaper という Windows のタスクトレイ常駐ツールです。C# で約 3,000 行。MIT ライセンスで公開しています。

やることは 2 つだけです。

「孤児・CPU 無活動・一定時間経過・複数個」という形だけを探して、プロセスツリー単位で終了させる
メモリリストの状態と、ハードウェアの状況を測って報告する

汎用の「PC 高速化ツール」ではありません。1 つの故障モードだけを対象にしています。

ここで大事なのは 2 番目です。回収より先に、測ることのほうが役に立ちました。

--diagnose は何も変更せず、1 回走査して JSON を出します。読む順に並べてあります。

項目	何が分かるか
`remoteAccess`	遠隔操作ツールが動いているか。動いていれば、体感の速さはこの機体だけでは決まらない
`memory`	`freeAndZeroGb` が体感と相関する数字。`availableGb` がタスクマネージャーの「利用可能」
`physicalMemory`	メモリスロットの実装状況とチャネル。1 枚挿しは帯域が半分
`graphics`	専用VRAM と、画面の枚数・解像度・リフレッシュ・合成に要る帯域の下限
`reapCandidates`	回収候補。空なら「回収するものが無い」が正解
`topGroups`	上位のプロセス群。状況を掴むためだけに使う
`warnings`	上を人が読める形にまとめたもの

実際に打ったコマンド

git が入っていれば、これだけで動きます。.NET SDK も npm も不要です。Windows に最初から入っている C# コンパイラ（.NET Framework 4.x）でビルドします。

1 行ずつ実行してください。以下は C:\dev\AgentReaper に置く例です。

1. 取得する

git clone https://github.com/shoutaitou3-creator/AgentReaper.git C:\dev\AgentReaper

2. ビルドする

powershell -ExecutionPolicy Bypass -File C:\dev\AgentReaper\build.ps1

3. 測る（何も変更しません）

C:\dev\AgentReaper\dist\AgentReaper.exe --diagnose --json

結果は画面に出るのと同時に C:\dev\AgentReaper\dist\diagnose.json に保存されます。

4. 実空きだけを取り出して見る

JSON 全体は長いので、最初に見るべき数字だけ抜きます。

(Get-Content C:\dev\AgentReaper\dist\diagnose.json -Raw | ConvertFrom-Json).memory

5. 何が回収対象になるかを見る（終了はしません）

C:\dev\AgentReaper\dist\AgentReaper.exe --dry-run

ここまで、PC の状態は 1 ミリも変わっていません。

6. ドライランの内容に納得したら、そこで初めて承認する

C:\dev\AgentReaper\dist\AgentReaper.exe --approve

7. 1 回だけ回収する

C:\dev\AgentReaper\dist\AgentReaper.exe --reap-once

6 を通していない状態では、設定で「実行する」に切り替えても 7 は何も終了させません。承認は設定ファイルのハッシュに紐づいているので、設定を 1 文字でも変えたら 6 からやり直しになります。

なお、Windows Defender 等に検知される可能性があります。全プロセスを列挙し、プロセスツリーを終了させ、NtSetSystemInformation を呼ぶ——これは行儀の悪いソフトの挙動そのものですし、自分でコンパイルした未署名バイナリには実績がありません。観測される挙動としては妥当な判定です。ソースが読める量であること、自分でコンパイルすること、ネットワーク通信のコードが一切入っていないことが、こちらから出せる材料の全部です。

しきい値で診断すると、確信を持って外します

ここからが本題です。

このツールには、実空きが一定量を下回ったら自動でメモリを解放する機能を付けていました。その閾値の初期値を、私は 6.0GB にしていました。

これは 128GB のメイン機で決めた値です。

32GB のマシンにこの設定を持っていくと、何が起きるか。

32GB 機の平常時の実空きは、実測で 1.47GB でした。Windows は搭載量に関わらず空きを遊ばせず、片っ端からスタンバイに回します。だから実空きは、128GB 機でも 32GB 機でも、平常時は小さいままです。これは異常ではなく正常な挙動です。

つまり 32GB 機では、何も問題が起きていない平常時から、常に閾値を割っていることになります。結果として、クールダウンが明ける数分おきに解放処理が走り続け、13GB あったファイルキャッシュを永久に捨て続けます。

軽くするつもりの設定で遅くなり、しかも利用者は原因に辿り着けません。 ログには「解放しました」としか出ないからです。

これを直すのに、設定ファイルの初期値を変えるだけでは足りませんでした。誰かが別のマシンから設定をコピーしてくれば、同じことが起きます。だから、

閾値を書かなければ搭載メモリ量から自動算出する（16GB 機なら 1.00GB、32GB 機なら 1.26GB、64GB 機なら 2.56GB、128GB 機なら 5.12GB）
搭載量の 25% を超える値が書かれていたら、コード側で切り詰めて、切り詰めた事実をログに残す

という形にしました。設定ファイルからは無効化できません。

この修正を入れたとき、私は「これで安全になった」と思っていました。実際には、問題の半分しか見ていませんでした。

同じ機種をもう1台、比較のために使いました

重いほうのPCを、仮に A拠点機 と呼びます。クライアント先に置かせてもらっている開発用のミニPCです。

このA拠点機を、上のツールで一通り測りました。

項目	A拠点機（重い）
CPU	16 コア
メモリ合計	31.557 GB
平常時の実空き	1.475 GB
スタンバイ	13.635 GB
メモリスロット	2 本中 1 本のみ実装（シングルチャネル）
回収候補（孤児プロセス）	0 件

孤児プロセスはゼロ。つまり AgentReaper の本来の出番はありませんでした。ここで普通なら手詰まりです。

残った候補は「実空きの枯渇」と「メモリ帯域がシングルチャネルで半分しかないこと」でした。

まず実空きを試しました。スタンバイを全部捨てる操作を実行します。これは管理者権限が要ります。「Windows ターミナル（管理者）」または「PowerShell（管理者）」を開いてから打ってください。

C:\dev\AgentReaper\dist\AgentReaper.exe --lighten

前後で数値を比べたいので、--lighten の直後にもう一度測り直します。diagnose.json は測ったときにしか更新されないので、読むだけでは古い値のままです。まず測り直して、

C:\dev\AgentReaper\dist\AgentReaper.exe --diagnose --json

そのうえで、さきほどと同じ抜き出しを打ちます。

(Get-Content C:\dev\AgentReaper\dist\diagnose.json -Raw | ConvertFrom-Json).memory

結果は劇的でした。実空きが 1.47GB から 15.88GB へ。スタンバイは 13.94GB から 0.02GB に落ちました。10 倍以上です。

体感を聞きました。返ってきた答えは、

ちょっとマシっていうかんじですね。

10 倍にして「ちょっと」なら、これは主因ではありません。

この時点で、私はシングルチャネルを疑い始めました。メモリを 1 枚足せばデュアルチャネルになり、帯域が倍になります。同じ型番のモジュールが 1 枚約8万円。発注ボタンの手前まで行きました。

そこで、もう1台のことを思い出しました。

まったく同じ機種のPCを、別の拠点にも置いています。そちらは重くありません。

3つの候補が一度に消えて、3つとも「逆方向」でした

こちらを B拠点機 と呼びます。同じメーカーの同じ型番、同じ CPU、同じ構成です。そして「普段どおり快適」に動いています。

B拠点機でも同じ測定を実行しました。結果を並べます。

項目	A拠点機（重い）	B拠点機（快適）	判定
CPU	16 コア	同一	差なし
メモリ構成	1 枚 32GB	同一（シングルチャネル）	候補から除外
実空き（Free + Zeroed）	11.344 GB	1.265 GB	除外（逆方向）
接続している画面	2 枚	4 枚	除外（逆方向）
画面合成に要る帯域の試算	2.57 GB/s	6.304 GB/s	除外（逆方向）

同じ機種のA拠点機（重い）とB拠点機（快適）の実測値比較表。CPUとメモリ構成は同一、実空きはA機11.344GBに対しB機1.265GB、画面はA機2枚に対しB機4枚、画面合成帯域はA機2.57GB/sに対しB機6.304GB/sで、3つの候補が逆方向の値で除外されたことを示す

3 つの候補が、一度に消えました。

そして 3 つとも、快適に動いているほうの機体のほうが、数値は悪かったのです。

シングルチャネルは、快適な B拠点機も同じ構成でした。メモリを足しても、この症状は説明できません
実空きは、快適な B拠点機のほうが 9 倍近く少ない（1.265GB 対 11.344GB）
画面の枚数と、内蔵GPU が合成に使う帯域は、快適な B拠点機のほうが 2.5 倍多い

もし A拠点機の数値だけを見て、しきい値と比べていたら、どうなっていたか。

「実空きが平常時 1.47GB しかない。これは少ない」「メモリが 1 枚挿しでシングルチャネルだ。帯域が半分だ」——どちらも事実で、どちらも症状の説明になりません。 そして私は確信を持って 8 万円を払い、何も改善しなかったはずです。

数値は、動いている機体の数値と並べて初めて意味を持ちます。

「変わらなかった」は、いちばん価値のある結果です

この切り分けで、実際に効いたのは「効かなかった」という結果のほうでした。

スタンバイを全部捨てて実空きを 10 倍にした → 体感はほぼ変わらなかった → 実空きは主因ではない
同型機と比べた → 同じ値だった → その項目は差を説明できない

どちらも「何も改善しなかった」報告です。しかしこの 2 つがあったから、8 万円を払わずに済みました。

ここには落とし穴があって、私は 1 回踏み抜きました。

アイドル状態で測ってしまったのです。

A拠点機で「重い」と言われている状態を調べるつもりが、実際に測ったのは、誰も操作していない静かな 1 分間でした。当然、どの数字もきれいに出ます。パケットロス 0、遅延も安定、送信量もほぼゼロ。

これは「異常が出ていない状態」を測っただけで、何も肯定も否定もしていません。 アイドルは測るのが楽なので、つい測ってしまいます。

だから手順に書き足しました。人間に「重いと感じる操作を再現してください」と頼んで、その最中に測る。 これをやらないと、綺麗な数字を見て安心して終わります。

順番は「疑わしい順」ではなく「安い順」

一連の作業を経て、切り分けの順番を手順として固定しました。ツールに同梱している AGENTS.md に書いてあります。

順	候補	実験	費用
1	孤児プロセスの堆積	`--dry-run`。候補が空なら 1 コマンドで除外できる	無料
2	実空きページの枯渇	`--lighten` を 1 回。前後の数値と体感を比べる	無料
3	画面の合成負荷	画面を一時的に減らす、解像度やリフレッシュを下げる	無料
4	専用VRAM の不足	ファームウェアまたは GPU ソフトで設定変更。再起動が要る	無料・作業の中断あり
5	メモリのシングルチャネル	2 枚目を挿す	有料

表だけだと 3 と 4 が曖昧なので、実際の操作を書いておきます。

3 の「画面を減らす」を試す前に、いま何枚繋がっているかを数字で確認します。

(Get-Content C:\dev\AgentReaper\dist\diagnose.json -Raw | ConvertFrom-Json).graphics.displays

ここに、物理的に繋いだ覚えのない画面が出ることがあります。仮想ディスプレイを作るソフト（会議ツールの仮想画面、リモート用の仮想モニタードライバー等）を入れていると増えます。画面の枚数は、繋いだケーブルの本数とは一致しません。

減らし方は Windows の設定からです。Windows キー + P を押して「PC 画面のみ」を選ぶと、外部出力を 1 回で止められます。個別に外すなら 設定 → システム → ディスプレイ で対象の画面を選び、「このディスプレイを削除する」を選びます。リフレッシュレートは 設定 → システム → ディスプレイ → ディスプレイの詳細設定 → リフレッシュレートの選択 で下げられます。仮想ディスプレイのソフトを入れているなら、それを終了させるのが一番早いです。

変更したら、もう一度 --diagnose --json を打って、displays の枚数と合成帯域の試算が実際に下がったことを確認してから体感を見ます。

4 の専用VRAM は、UEFI（BIOS）の設定項目です。 電源投入直後に Delete または F2 を連打して UEFI に入り、DVMT Pre-Allocated UMA Frame Buffer Size Share Memory といった名前の項目を探します（呼び名はメーカーによって違います）。Windows 側のレジストリを書き換えても変わりません。 これは実際に試して効きませんでした。

そして、大きくすればいいものでもありません。前述のとおり、128GB 機で最大値の 96GB を指定したら OS から見えるメモリが 31.7GB まで減って破綻しました。変更後は必ず、タスクマネージャーで OS が認識しているメモリ量を確認してください。

無料の実験を全部やってから、有料の判断をします。これは順序の問題であると同時に、無料の実験そのものが「買い物が効くかどうか」の判定を兼ねているからです。3 を試して体感が変わらないなら、5 に金を払っても同じ結果になる可能性が高い。

そしてこの表より上位に、費用ゼロで最も強い手があります。

同じ構成で問題が出ていない機体があるなら、それを使う。 両方で測って差分を取れば、同じ値の項目は「差を説明できないから」という理由だけで、実験なしに一括で候補から外せます。

この手が見落とされやすいのは、単純な理由です。健康なほうの機体は、誰も気にしていないからです。困っているのは重いほうなので、意識がそちらに固定されます。

ついでに見つかった、自分のバグの話

信頼性の話として、都合の悪いことも書いておきます。

画面の枚数を測る機能を追加したとき、「仮想ディスプレイかどうか」を判定するロジックを、**「専用VRAM を報告していないアダプターに繋がっている画面 = 仮想」**という形で書きました。

これがA拠点機で誤判定を出しました。内蔵GPU の実物の画面が「仮想ディスプレイ」として報告されたのです。原因は単純で、その機種の内蔵GPU はレジストリに VRAM 容量を書いていませんでした。

「無いこと」を根拠に「有ること」を主張していたわけです。判定を「既知の仮想ディスプレイドライバー名に一致するかどうか」だけに書き直しました。名前が一致しない仮想ドライバーは検出できませんが、実物の画面を仮想と呼ぶよりはるかにマシです。

診断ツールの誤検出は、ただのバグより性質が悪いと考えています。使う人は、そのツールを信じて判断するからです。 だから、拒否したものも切り詰めたものも、必ず理由つきで出力に残す設計にしています。設定が黙って無効になるほうが、エラーで落ちるより危険です。

このやり方が効かない場面

正直に、限界も書きます。

同型機が無い場合、この記事の一番強い手は使えません。 その場合は「安い順」の表を上から順に潰していくしかなく、時間がかかります。

対照実験で言えるのは「機体は原因ではない」までです。 「では何が原因か」は別の作業です。今回のケースでも、機体側の候補が全部消えた時点で、残りの調査は機体の外側に移りました。それは別の話なのでこの記事には書きません。

AgentReaper は汎用の高速化ツールではありません。 孤児プロセスが溜まっていない環境では、reapCandidates は空のまま何もしません。それが正しい動作です。空だったときに、無理やり設定を書いて何かを終了させようとしてはいけません。

そして プロセス数は体感と相関しません。 私の環境の実測では、726 プロセスで描画のコマ落ち 11%、522 プロセスで 0%、463 プロセスでも 0% でした。プロセス数を減らすことを目的にしないでください。

設定はAIエージェントに書かせる前提で作りました

このツールは、少し変わった形で配布しています。

リポジトリには仕組みだけが入っていて、設定が入っていません。 clone した時点で、回収対象を定義するファイルは空です。これは意図的です。何がリークしているかは、使っているエージェントと MCP サーバーによって違い、その環境を測らないと分からないからです。

想定している使い方は、普段使っている Claude Code や Codex に同梱の AGENTS.md を読ませ、診断を走らせて、その環境用の設定を書かせることです。提案された内容を人間が承認します。

ここで 1 つ、実際に指摘されて直した点があります。当初、READMEにはこう書いていました。

このリポジトリの AGENTS.md を読んで、このPC用に設定して

これに対して、こう言われました。「新しいセッションを立ち上げているのに、『このリポジトリ』と言って通じるのか」と。

通じません。 新しく起動したエージェントは、あなたがどのフォルダの話をしているかを知りません。絶対パスで渡す必要があります。

C:\dev\AgentReaper\AGENTS.md を全文読んでから
C:\dev\AgentReaper\dist\AgentReaper.exe --diagnose --json を実行して、
このPC用の設定を提案してください。
プロセスは終了させないでください。--approve も実行しないでください。

エージェントに作業を頼むときの指示文は、新しいセッションで、文脈ゼロの相手に渡しても成立するかで点検する価値があります。AI 駆動開発の現場では、この種の「自分の頭の中では自明な参照」が最もよく事故を起こします（AI駆動開発で、最初の画面が出るのは5日目 ── 何が出てきて、どちらが何をやるか）。

言語モデルが、他人のPCで、プロセスを終了させる設定を書く。この前提を置いたので、安全機構はドキュメントのお願いではなくコードで強制しています。

4 文字未満のパターン、node や python のような汎用語との完全一致は読み込み時に拒否
7 種類以上の実行ファイルに当たった、全プロセスの 15% を超えた、CPU を 60 秒以上使っているプロセスに当たった場合は走査時に無効化
ドライランを見て承認するまで、設定で「実行する」に変えても何も終了しない。承認は設定ファイルのハッシュに紐づくので、1 文字変えれば自動的に失効する

自動テストは 44 項目。実プロセスを 1 件も終了させずに、これらの拒否が実際に働くことを検査しています。

おわりに——あなたの手元に、比較できる2台目はありませんか

今回の切り分けで一番効いたのは、高度な解析でも、特別な計測ツールでもありませんでした。

同じ機種で、問題が起きていないほうを、同じやり方で測っただけです。

それだけで、疑っていた 3 つが一度に消えて、8 万円の買い物が止まりました。しかも 3 つとも、快適なほうの機体のほうが数値は悪かった。あのまま数値をしきい値と比べていたら、自信を持って外していたはずです。

社内に同じ型番のPCが複数あることは、珍しくないと思います。全社で一括導入していれば、むしろ普通です。困っている 1 台の中を掘る前に、困っていない 1 台を測ってみてください。

同じことは、システムのトラブルシューティング全般に言えます。「動いている環境との差分」は、どんな高度な推論よりも速く、確実です。私たちが BANSOU CTO™ として入る現場でも、最初にやるのはたいていこれです。新しい分析を足すのではなく、比較できる基準を 1 つ用意する。

そして、もし手元に比較対象が無いなら——まず何も変えずに測って、その数字を控えておいてください。 今日の平常値は、明日おかしくなったときの唯一の基準になります。今日しか採れません。

この記事のポイント

タスクマネージャーの「利用可能」は空きメモリではない。実空き（ゼロ埋め済み）とスタンバイの合計であり、体感と相関するのは前者。128GB のマシンで「利用可能 49GB」でも実空き 0.00GB という状態が実際に起きる
AI コーディングエージェントの MCP サーバーやフックは、セッション異常終了時に孤児として残る。実測で 55 件・全件 CPU 0 秒・最古 6.5 日・合計 2.6GB。開発元にも Issue #26984、Issue #12491 として報告済みの既知課題
別の機体で決めた閾値を持ち込むと、平常時から常に閾値割れになり、キャッシュを捨て続けて逆に遅くなる。しかもログには「解放しました」としか出ないので原因に辿り着けない
同じ構成で問題が出ていない機体があるなら、両方で測って差分を取る。 同じ値の項目は実験なしで候補から外せる。今回は 3 つが一度に消え、3 つとも快適なほうの数値が悪かった
切り分けの順番は「疑わしい順」ではなく「安い順」。 無料の実験は、有料の対策が効くかどうかの判定を兼ねている
「変わらなかった」は結果である。空振りをはっきり空振りと記録しないと、効かない対策を触り続けることになる

伊藤翔太 株式会社IIWAYO.TECH 代表取締役 / 株式会社リサスティー代表取締役

次に読むおすすめ

AI駆動開発で「できるはず」と「できた」の間にある距離をどう見積もるか
AIエージェントに記憶を持たせる設計——どこに何を置くと壊れないか
クラウドとローカルNASのハイブリッド構成を選ぶ判断基準