PCのメモリ逼迫を調査した記録：Irodori-TTSのモデルをGPUで組み立て、不要なMySQLを削除する

朝7時の時点で、メモリの使用率は82%ほどあった。この PC はメモリを使い切って落ちることがある。前日にも dev サーバーまわりの対策を計画書にまとめて手を入れたが、何が PC を落としているのかは、まだ突き止められていない。そこで Claude Code に「余計なやつ」の調査を頼み、前日の計画書と照らして現状を見てもらった。

07:00 の現状と、前日の対策の効き目

最初の報告では、物理メモリ 31.9GB のうち空きは 7.0GB だった。 82% の約4割を、Irodori-TTS のナレーション生成（python）1本が使っているという。前日の計画書にあった dev サーバー対策は全部済んでいて、eurekapu の dev サーバーは 1.5GB まで下がっていた。前日の対策は効いていた。この時点では、Irodori がいちばんの食い手ということになっていた。

SQL Server が2つ、MySQL が1つ

調べてもらうと、SQL Server は2つ入っていた。動いている方（MSSQLSERVER）は税務ソフトA用で、止まっている方は会計ソフトC用だった。会計ソフトC用のインスタンスは消せる。ただ、会計データ本体がこのインスタンスの中にあるので、消すなら先に退避が要る。

MySQL は税務ソフトAの部品ではなく、2023年12月に自分で入れた開発用のようだった。中身を見ると、自分で作った DB は1つもない。入っていたのは MySQL 自身が使うシステム用の DB と、sakila だけだった。

決裁フォームでは、最終的に次のように選んだ。

判断1（税務ソフトAの SQL Server）：C「いまのまま」
判断2（MySQL）：C「アンインストール」
判断3（Irodori）：A「測ってから選ぶ」

13個の MySQL 部品を管理者 PowerShell で消す

最初につまずいたのは、管理者で開いた PowerShell へのコピペだった。 Win+X から「ターミナル（管理者）」で開いた Windows Terminal なら、ドラッグで選んで Ctrl+C（または右クリック）でコピーできる、と教わった。

スクショを見ると、消す対象が13個あった。「13個あるみたいですけど、これ全部消すんですかね。めんどくさいな」と Claude Code に投げた。画面から1つずつ消す必要はなく、管理者の PowerShell でコマンドを実行すればまとめて消せる。ただし、画面で進んでいる「Preparing to remove...」が終わるまでは待つ。 Windows のインストーラーは同時に1つしか動かせず、並べて走らせるとエラー 1618（別のインストールが進行中）で失敗するからだ。

一覧を貼って見てもらうと、13個とも MySQL の部品で、Installer の2つは最後に並んでいた。ただ、13個とも一覧に残っていたので、「Preparing to remove...」は終わっていないか、途中で止まっていたらしい。その画面が消えたのを確かめてから、同じ PowerShell で実行した。

今度は PowerShell の表示がいつまでも先へ進まない。スクショを貼って相談すると、MySQL Server 8.2 の削除自体は 07:50:18 に成功で終わっていた（Windows のイベントログで確認）。見立ては「本体の mysqld.exe は消えたが、MySQL のサービスが動いたまま残っていて、Start-Process -Wait がその終了を待っている」というものだった。この見立ては外れた。最終的に13個とも終了コード 0 で終わり、単に時間がかかっていただけだった。

そのあと残っていた3つも片付け、サービス、プロセス、アンインストール一覧、ポート 3305、フォルダのどれにも MySQL は残らなかった。それでも物理メモリは 26.7GB 使用のままで、下がったのは MySQL の約0.6GB 分くらいだった。原因は MySQL の外にある。

メモリを1分ごとに記録する

MySQL の削除を待つあいだに、計画書の Step 1 として、メモリを1分ごとに記録する仕組みを Claude Code に作ってもらった。 1回あたり約1秒で動いた。 Chrome のように細かいプロセスが多いものは合計が見えないので、プロセス名ごとの合計の列も足した。スクリプトは ASCII のみで書き、ログオン時に自動で起動するよう登録した。 2つ目を起動してもすぐ終了し、常駐は1本だけのままだった。

記録は 07:50 から続き、08:07 までで18行、08:49 までで60行たまった。間隔は60〜61秒で、抜けはなかった。

途中で、chrome-devtools-mcp が20個、合わせて 3.2GB あるのも見つかった。 Claude のセッションは4つしかないのに多すぎるので、親のセッションが残っているかを調べてもらった。

Irodori は物理メモリをどれだけ使っているか

判断3のとおり、Irodori のメモリの内訳を測ってもらった。本番と同じ条件（参照音声あり）で2回動かした結果、物理メモリの使用は常時約4GB で、読み込み中の約5秒だけ 6.7GB まで上がる。朝に見た 12.9GB はコミット（予約した量）で、物理メモリをそれだけ使っていたわけではなかった。 Irodori 単体で PC が落ちるとは考えにくい。朝の「約4割」の見立ては、ここで崩れた。

モデルを GPU の上で組み立てる

続けて、Irodori の対策を進めてもらった。 Irodori のモデルを GPU の上で組み立てても音声が変わらないかを確かめてもらった。まず、合成のたびに seed がかけ直されているかをコードで確認した。 CPU で組み立てた場合は2回とも完全に一致したが、GPU で組み立てた場合とは波形が一致しなかった（長さは同じ）。どの程度違うのかを測ってもらい、本番スクリプトに GPU で組み立てる関数を足した。

本番スクリプトの出力先だけを scratchpad に変えて1区間まるごと流し、既存の本番音声とハッシュを比べ、あわせてメモリも測った。コミットは、コミット前に走る Codex レビューで止められ、そのうち1件は「手順1（確認）と手順2（コピー）の対象がずれている」という指摘だった。 Claude Code はこれを high と判断して直した。

結果として、音声は今までとビット単位で同じまま、1区間（absolute-ref-breaks、52文）を作るあいだのメモリの山が下がった。直した記録係を起動し直し、8コミット（前日の分6つを含む）を push した。

全スクリプトを GPU へ、スキルにはルールとして

報告を読むと、Irodori を使う他のスクリプトは CPU でモデルを組み立てたままだった。「全部 GPU にしたほうがいいんじゃないか」と伝えた。あわせて、Irodori-TTS を使うスキル側に、今回メモリが逼迫して落ちた経緯を書いたうえで、新しくスクリプトを作るときは GPU で組み立てる方にする、というルールを足してほしいと頼んだ。経緯まで要るかは、頼みながら迷っていた。

intro の合成は170文あり、10分ほどかかる。待つあいだに、スキルへのルール追加を先にコミットしてもらった。 GPU のメモリが 8GB 中 7.5GB まで埋まる点は、いまは問題ではないという。内訳は Irodori が約5.5GB、残りの約2GB は画面表示や Chrome など、普段から GPU を使っているものだ。 Irodori は with-lock で1本ずつしか動かないので、Irodori 同士で取り合うことはない。

本番用の generate-excel-intro-irodori.py で170文を作り直し、前回（09-24）の出力と比べた。 170文すべて、完成した mp3、時刻データ（excelIntroRender.json）が1バイトも違わず一致した。確認用のフォルダは消し、両方のリポジトリを push した。

11:05 dev サーバーの再起動が止められた

11時過ぎ、dev サーバー（http://localhost:3200）が止まっていた。バックグラウンドで動いていた「dev サーバーを起動し直す」コマンドを、メモリがひどく不足していたため Claude Code 自身が止めていた。コマンドやサーバーの不具合ではない。メモリがまだ足りない可能性があるので、起動し直さずに声がかかるのを待つ、という報告だった。

画面再現の確認作業から始めたかったので、Google タスクの今日の分に加えてもらった。「マイタスク」に、9/27 期限で「Excel関数の活用：画面再現の確認作業（残り18本）」が入った。題と期限が正しく入っていることは、登録結果で確かめてもらった。

学び

朝に見た Irodori の 12.9GB はコミット（予約した量）で、物理メモリの使用は常時約4GB だった。コミットを物理メモリの使用と読むと、食い手を見誤る。
MySQL を消しても、下がったのは約0.6GB だった。消して下がった量を見たことで、原因が MySQL の外にあると分かった。
GPU でモデルを組み立てると、最初の比較では波形が合わなかった。最終的な本番スクリプトでは、音声がバイト単位で一致することを170文すべてで確かめてから切り替えた。

PC を落としている犯人は、まだ分からない。 Irodori 単体では落ちないと分かり、MySQL も消したのに、11時過ぎにはメモリ不足で dev サーバーの再起動まで止まった。 1分ごとの記録は、今もログオンのたびに動き出す。

#メモリ#Windows#Irodori-TTS#GPU#PowerShell#Claude Code