個人daily-log

導入

Dropboxのアイコンを開いたら「26,000ファイルを同期中」と表示されていた。回線が細る理由がここにあった。新しいPCに乗り換えたばかりで、ローカルの Documents は830ファイルしかないのに、クラウド側にはなぜか膨大な量の自分のファイルが居座っていた。

午後はその謎を解いて、ついでにスタートアップの常駐プロセスを棚卸しした。SQL Serverのインスタンスが3つ動いていて、そのうち1つはアンインストール済みのソフトの「サービスだけ残骸」になっていた。本体は消えているのにサービスは動き続けているという、地縛霊みたいな状態を解除する話を残しておく。

第一幕：Dropboxの2.6万件は何者か

仮説1：PCバックアップで Downloads が丸ごと同期されている（ハズレ）

最初に疑ったのは Dropbox の「PCバックアップ」機能。Documents / Downloads / Desktop を丸ごとクラウドに送る設定で、Downloads が6GBくらいあるからこれだろうと睨んだ。

設定画面を開いてもらうと、チェックが入っているのは Documents だけで Downloads は入っていなかった。仮説1は崩れた。

仮説2：Documents のバックアップが暴走している（ハーフ正解）

ではその Documents が原因かと思って中身を覗いた。ローカルの C:\Users\numbe\Documents には830件しかファイルがない。一方、Dropbox のクラウド側に格納されている Documents/ 配下には、見覚えのないフォルダがいくつも並んでいた。

PowerShell で容量を測ってみる。

Get-ChildItem "$env:USERPROFILE\Dropbox\PC\Documents" -Recurse |
  Group-Object Directory |
  Select-Object Name, @{n='SizeMB';e={[math]::Round(($_.Group | Measure-Object Length -Sum).Sum/1MB,1)}} |
  Sort-Object SizeMB -Descending | Select-Object -First 10

PDF書籍のフォルダが629MB、.tmp.drivedownload が80MB、その他見覚えのない領収書フォルダが100MB単位で並んでいた。ローカル830件 vs クラウド数万件のギャップが開きすぎている。

仮説3：古いPCの残骸が残っているのでは（ビンゴ）

ここで自分の側から仮説を出した。「これ、古いPCで Dropbox のPCバックアップを有効にしていたとき、そのPCの Documents がクラウドに上がっていて、新PCに乗り換えても削除されずに残っているのでは」。

Dropbox の PC/ 配下にはホスト名でフォルダが切られる仕様だから、ホスト名を見れば古いPCのものかどうか分かる。確認したらビンゴだった。PC/{古いホスト名}/Documents が丸ごと2.6万件分、古いPCの残骸として残り続けていた。新PCに乗り換えてからもDropboxはそれを「自分の管理対象」として同期し続けていたわけだ。

対処

  • 新PCの Documents のバックアップを停止（ローカルからの吸い上げを止める）
  • Dropbox Web の「バックアップ」画面で、古いPCの登録を削除する画面まで誘導
  • 削除確定はユーザー本人に任せた（取り返しがつかない操作なのでクリックは委ねる）

おまけ：Pictures/ClipboardImages 仮説（ハズレ）

途中、Pictures 配下の ClipboardImages フォルダ（クリップボード画像の自動保存先）が「最近30日で764件」と多いことを発見した。これも同期対象なら太い回線喰いの容疑者だな、と思って Dropbox の設定を見直したら、Pictures はそもそもバックアップ対象外だった。仮説倒れ。容疑者リストから外した。

第二幕：スタートアップ・常駐プロセスの棚卸し

Dropboxの謎が片付いたので、ついでにPC起動時に立ち上がる常駐プロセス全体を見直すことにした。古いPCから新PCに環境を引き継ぐと、要らなくなったサービスが残骸として動き続けがちで、その地縛霊たちを今日のうちに片付けたい。

Win32_StartupCommand だけ見ると判定が漏れる

最初は WMI の Win32_StartupCommand を眺めて「ここに並んでるのが起動時に立ち上がるやつ全部」と思っていた。

Get-CimInstance Win32_StartupCommand | Select-Object Name, Command, Location

ところがこれだと、タスクマネージャの「スタートアップ」タブでオフにしたエントリも一緒に出てくる。「本当にいま有効か」までは判別できない。

正しくは StartupApproved レジストリと突き合わせる必要がある。HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\StartupApproved\Run などに、各エントリの有効/無効フラグが入っている。両方を読んで突き合わせると、初めて「現在ONになっているスタートアップ」の全貌が見える。これに気づくまでオン/オフ判定をミスっていた。

サービス側の調査：SQL Server が3つ動いていた

スタートアップ（=ユーザーの自動起動）と並んで、Windows サービスとして自動起動しているプロセスも棚卸しした。Get-Service で StartType=Automatic のものを抽出して、メモリ使用量と一緒に並べる。

驚いたのは SQL Server 系のインスタンスが3つ自動起動していたこと。

インスタンス用途状態
MSSQLSERVER（SQL Server 2016）税務ソフト系のサービス（達人）が使うDB1.4GB 消費して稼働中
MSSQL$YAYOI（SQL Server 2014）会計ソフトC（弥生）のインスタンス117MB 消費、ただし本体アンインストール済み
SQL Server 2017インストーラ残骸エンジン自体は動いていない

加えて MySQL と PostgreSQL ×2 も自動起動していた。新PCに引っ越したときに「古いPCの開発環境を一通り入れ直す」をやったツケで、もう使っていないDBエンジンがメモリを占有していた。

MSSQLSERVER（達人）の中身

サービス名だけ見ても用途が分からないので、データベース一覧を引いて中身を確認した。

SELECT name FROM sys.databases;

Hj_DATABASE、Sy_DATABASE、St_DATABASE、Nc_DATABASE、Ug_DATABASE、Ef_DATABASE、Fl_DATABASE、Gk_DATABASE という命名規則のDBがずらりと並んでいた。これは税務ソフト系のサービス（達人シリーズ、NTTデータの税務申告ソフト）のDB。各税目（法人税・所得税・消費税など）が Hj_/Sy_/St_/Nc_/Ug_/Ef_/Fl_/Gk_ の接頭辞で分かれている設計だった。

これは現役で使っているソフトのDBなので、消すと作業データが死ぬ。手は出さない。ただ自動起動のままにしておくとメモリ1.4GBを常時食うので、本来は手動起動に切り替えたいところ。ただし税務ソフトを起動するたびに先にサービスを net start するのが面倒で、結局 Automatic のまま据え置きにした。

代替案として、Stream Deck の Multi Action（複数コマンドの連鎖）にサービス起動とソフト起動を仕込めば、ボタン1個で両方立ち上げられる。これはメモに残しておいて、また気が向いたときに組む。

MSSQL$YAYOI（弥生）は本体が消えていた

問題はこっち。MSSQL$YAYOI は会計ソフトC（弥生）の専用インスタンスとして入っているもので、過去に弥生をインストールした時の置き土産。確認したら本体はアンインストール済みでアプリのインストール痕跡が無いのに、SQL Server インスタンスだけサービスとして残って毎回117MBのメモリを抱えて起動していた。

中身を覗いてみる。

-- master だけ。ユーザーDBは存在しない
SELECT name FROM sys.databases WHERE database_id > 4;

ユーザーDBはゼロ。master などシステムDBしか入っていない。完全に幽霊サービスになっていた。

Codex にセカンドオピニオンを求めた

サービスを Stop + Disabled にする手順を Claude Code に書いてもらった後、念のため Codex（gpt-5.5）にセカンドオピニオンを聞いた。サービスを止めて Disabled にする操作は、PCを再起動しても永続的に効くのか、ただの一時停止になっていないか、という確認をしたかった。

codex exec -m gpt-5.5 "PowerShell で Stop-Service と Set-Service -StartupType Disabled をしたら、再起動後も Disabled は維持されるか確認したい。あと、コマンド全体の引用符の使い方もレビューして"

返ってきた指摘は2点。

  1. Set-Service -StartupType Disabled は services.msc の「無効」と同じレジストリ書き換えなので、再起動後も永続的に効く
  2. PowerShell のコマンド内文字列はダブルクォートとシングルクォートが混ざっていた。シングルに統一した方が変数展開の事故を防げる

2点目はコピペで Bash と PowerShell を行き来する自分の癖が出ていた。シングルクォートに揃えた。

弥生だけ Stop + Disabled に

UAC のプロンプトを承認して、以下を実行した。

Stop-Service 'MSSQL$YAYOI' -Force
Set-Service 'MSSQL$YAYOI' -StartupType Disabled

タスクマネージャでメモリを見ると117MB分の領域が解放された。1.4GB の MSSQLSERVER（達人）の方は据え置き、SQL Server 2017 の残骸はそもそもエンジンが動いていなかったので触らず。MySQL と PostgreSQL ×2 は今後使う可能性があるので Manual に落とすかどうか保留。今日はここまで。

学び

  • 「同期しているファイル数」と「ローカルにあるファイル数」のギャップが大きいときは、まずホスト名を疑う。Dropboxの PC/{ホスト名}/ 構造を理解していないと、自分のローカルだけ見て延々調べることになる。古いPCの残骸はクラウドに残り続ける。
  • Win32_StartupCommand だけではスタートアップのオン/オフは判定できない。StartupApproved レジストリを突き合わせて初めて「現在有効なエントリ」が分かる。タスクマネージャでオフにしたものも Win32_StartupCommand には残る。
  • アンインストール済みソフトのSQL Serverインスタンスは残骸として生き残る。会計ソフトCの本体は消えていたのに、専用インスタンスだけ動き続けて毎回メモリを抱えていた。アンインストーラがインスタンスまでは消してくれないことがある。
  • Codex のセカンドオピニオンは「永続性」と「シェル文法」の確認に効く。Stop-Service が一時停止か永続無効かの境目は意外と忘れやすい。引用符の混在もレビューの一発で気づいた。
  • 「メモリを食うから自動起動を止めたい」と「いざ使うとき手動起動が面倒」のトレードオフは、ボタン1個で連鎖起動できる仕組みがあれば解ける。Stream Deck の Multi Action にサービス起動とアプリ起動を並べれば両立する。今日は組まずにメモだけ残した。

明日以降の宿題

  • Dropbox Web で古いPCのバックアップ削除を実行する（クリックはユーザー操作）
  • 達人シリーズ用に Stream Deck の Multi Action を組む（net start MSSQLSERVER → 達人本体 .exe を順次起動）
  • MySQL と PostgreSQL ×2 の使用状況を確認して、未使用なら Manual に落とす
  • 古いPCそのものを物理的に処分する前に、Dropbox 以外（OneDrive・Google Drive 等）のクラウド連携にも残骸が無いか確認する