【悲報】Windows 11の標準機能がSSDを密かに食い尽くす 「見えないファイル」が最大500GB、クリーンアップでも検出不能
【悲報】Windows 11の標準機能がSSDを密かに食い尽くす 「見えないファイル」が最大500GB、クリーンアップでも検出不能
「誰にも見えない」――Windows 11の標準機能がストレージを最大500GBまで食いつぶしていた。原因はほとんどの人が存在すら知らないファイル「CapabilityAccessManager.ddb」。しかもWindowsのクリーンアップ機能では検出できない。128GBや256GBのSSDを搭載したノートPCでは、このファイル1つでストレージがほぼ埋まり、「ディスク容量が不足しています」の警告が出てシステム全体の動作が目に見えて遅くなる。120GBのSSDを搭載したSurface Pro 7で空き容量が100MBを切るまで原因が分からなかったという報告もある。
消えた70GB 正体は「アプリアクセス履歴」の書き込み先行ログ
あるユーザーがWindows 11の空き容量が急激に減っていることに気づいた。アプリを消しても一時ファイルを削除しても容量は戻らない。調べた結果、「CapabilityAccessManager.ddb」という名前のファイルが70GBにまで膨れ上がっていた。聞き慣れない名前だが、Windows 11に標準搭載されている「機能アクセスマネージャーサービス」が生成するファイルだ。アプリがカメラやマイク、位置情報にアクセスした履歴を記録するデータベースの一部で、正常な状態なら数MB程度に収まる。それが数十GB、ひどい例では500GBを超えるまで膨張していた。
厄介なのは、Windowsの設定にあるストレージ管理画面でもディスククリーンアップでも、このファイルが検出されないことだ。WindowsやWizTreeのようなサードパーティ製のディスク解析ツールを使って初めて全体が判明する。OSが生み出した問題をOS標準のツールでは見つけられない。ストレージ管理の画面には一時ファイル、アプリ、システムといったカテゴリーがあるが、このファイルはどのカテゴリーにも分類されず合計値にも反映されない。ユーザーが見ている数字と実際の使用量の間に数十GBの差が生まれていた。
原因はSQLiteの仕組み デルのソフトがトリガーに
CapabilityAccessManager.ddbはWAL（Write-Ahead Logging）と呼ばれる書き込み先行ログで、データベース本体への書き込みが追いつかない時の一時的なバッファとして機能する。通常は定期的に本体へ統合されてサイズが戻るところが、特定のアプリが高頻度で書き込み続けると統合処理が追いつかず、ログだけが膨張し続ける。デルのSmartByteやRainmeterといったサードパーティ製ソフトが位置情報やネットワーク状態を頻繁に参照することで、この状態を引き起こしていた。
サードパーティ製ソフトがトリガーだとしても、ログの肥大化を検知する仕組みも制御する仕組みもOS側には何も備わっていなかった。ログファイルが肥大化するまでの間に一度でも検知して警告を出す処理が入っていれば変わっていた。ストレージを食いつぶしたのはWindowsの標準サービスだ。
「見えない修正」 リリースノートに記載なし、1週間後に追記
Microsoftは6月にリリースしたプレビュー更新プログラムKB5095093でこの問題の修正を配信した。当初のリリースノートにはこの修正が記載されておらず、チェンジログに追記されたのはリリースから約1週間後のことだ。追記された内容は「CapabilityAccessManager.ddbのディスク使用量の改善」。対象はWindows 11バージョン24H2と25H2で、7月のセキュリティ更新で全ユーザーに自動配信される予定となっている。
ユーザーからの報告はフォーラムに数ヶ月前から上がっていた。Microsoftは4月にフィードバックハブで「調査中」と回答しているが、修正が公開されたのは6月。その間ストレージが逼迫したPCでは、動作の遅延やシステムの不安定が続いていたことになる。修正の適用後、既存の肥大化ファイルが自動で縮小されるかどうかは環境によって異なる可能性がある。
手動で対処する場合の手順と注意点
手動で対処する場合は、サービス管理画面から「機能アクセスマネージャーサービス」を停止し、以下の場所にあるCapabilityAccessManager.ddbを削除してPCを再起動する。
C:\ProgramData\Microsoft\Windows\CapabilityAccessManager\サービスは再起動時に新しいファイルを自動生成する。注意点が2つある。1つはこの操作の後にWi-Fiやネットワーク接続が一時的に途切れることが報告されていること。接続が回復しない場合はサービスが正常に再起動しているか確認が必要だ。もう1つはCapabilityAccessManager.ddbではなく本体のデータベースファイルを削除しないこと。設定が初期化され、予期しない動作を招く可能性がある。KB5095093の適用と合わせて、ログファイルの現在のサイズを一度確認しておきたい。ファイルの場所はProgramDataフォルダー内のため、エクスプローラーの表示から「隠しファイル」をオンにする必要がある。
OSが自ら作った問題を、OS標準ツールでは見つけられない
今回の問題が象徴的なのは、「OSが生み出した問題をOS標準のツールでは見つけられない」という構造だ。ストレージ管理画面のカテゴリー分類から漏れ、合計値にも反映されない。ユーザーが見ている数字と現実の間に数十GBのギャップが生まれ、そのギャップこそが「ディスク容量不足」という深刻な症状を引き起こしていた。Microsoftが4月に調査中と回答しながら修正まで2ヶ月を要し、しかもリリースノートへの記載が1週間遅れた事実は、フィードバックループの遅さと情報開示の不透明さを浮き彫りにする。サードパーティ製アプリがトリガーだとしても、OS標準サービスが無制限にログを肥大化させ、それを検知・制御する仕組みを持たなかったことは、設計上の欠陥と言わざるを得ない。ユーザーは「消えた容量」を取り戻すために、隠しフォルダの奥深くでサービスを止め、謎の.ddbファイルを手動で削除し、ネットワーク断絶のリスクを負わされる。これが2026年のWindows 11で起きている現実だ。
ネットの反応
新品の500GのSSDがあっと言う間に残り50GとかわけのわからんことがおきるOSなんだよ。くそOSすぎる
「空き容量が増えるぞ！神アプデ！」という記事があったが、消防士が放火してたニュースを思い出した
いつからだろう。Windowsの「サービス」が「余計なことばっかする常駐ソフト」に感じるようになったのは。てかいくらなんでも細かく分けすぎなんだよな。細かいサービスが何百もアプリ間通信して常時ポーリング監視してるからクソ重くなるし、依存関係で絡まってトラブりやすいし
消すにしてもそのフォルダって所有権取らないとサイズすら確認できないから敷居が高いよね
もはやガンレベルですな
256GBのssd食い潰すとかさぁ…でもwalだからhddでも繋いどきゃええんやろか
ほんと、Windows脱出したいLinux使い
なるほどコレのせいか…
他に多いところだと 1.\Windows\System32\DriverStore\FileRepository と 2.\Windows\WinSxS が容量を増やし無駄に積み重なるフォルダですな
この問題はなかったけど調べたらメモリダンプが23Gもあった。あまり遊んでないMSFSのローリングキャッシュも何気に邪魔くさかったのでいい掃除の機会にはなりました
MS「DELLさん。リリースするソフトはちゃんとテストしてくださいよ」DELL「そんな仕様聞いてねーし」MS「仕様じゃねーし。俺知らなかったし」DELL「バグだよね？」MS(コンシューマ向けアナウンス)「修正パッチリリースしまーす」こんなところか？
OSが管理しているDBでDBサイズの異常を検知出来無かったのか、OS管理だからユーザーに触らせない為に無条件で検出から除いていたのだろうな。今は毎月再起動させるのだからその時にDB統合プロセスを入れるだけで、遅いPCの動作がマシになるのでは
んな、素人以下のOS？は、やめて、Linuxにして、もっと違うことに悩んでほしい
えーっ、Windowsさん、今度は何ですか？
はぁ？
google play games のuserdata.imgもとんでもない事になってた
こそっと変更するからたちが悪い
AI搭載だから無駄書きか多いのかも
AIの所感
CapabilityAccessManager.ddbの肥大化問題は、Windowsのアーキテクチャが抱える「監視のための監視」という構造的矛盾を露見させた。アプリがカメラ・マイク・位置情報にアクセスするたびに履歴を記録するデータベース。その書き込み先行ログ（WAL）が、統合処理が追いつかないほど高頻度で書き込まれると無制限に膨張する。トリガーになったのはDellのSmartByteやRainmeterといったプリインストール・常駐ソフトだが、根本原因は「OS標準サービスに、自ら生成するログのサイズを監視・制御する機構が一切なかった」ことにある。
SQLiteのWALモードはデータベースの耐久性と性能を両立する優れた仕組みだが、チェックポイント（WALから本体への統合）が追いつかない状況を検知し、ログサイズに上限を設けたり、書き込み元のプロセスをスロットルしたりするセーフガードをOS側が実装していなかった。これが「設計上の欠陥」でなければ何と呼ぶべきか。
さらに深刻なのは、この肥大化したファイルがストレージ管理画面のどこにも現れず、ディスククリーンアップでも検出されず、ユーザーが見える「空き容量」と実態の間に数十GBのギャップを作り出していた点だ。OSがユーザーに提示する情報と現実が乖離している。これはテレメトリやGDIDの問題と同じ構造だ。「ユーザーに知らせる義務も誰も感じていなかった」帳簿の話が、ここでも繰り返されている。
修正パッチKB5095093がリリースノートに記載されず、1週間後にこっそり追記されたことも、Microsoftの情報開示姿勢の不透明さを象徴する。フィードバックハブで「調査中」から修正公開まで2ヶ月。その間、128GB/256GB SSD搭載機では実用不能に近い状態に追い込まれたユーザーが少なくなかったはずだ。手動対処でサービスを停止して.ddbを削除すれば一時的に容量は戻るが、ネットワーク接続が途切れるリスクをユーザーに負わせる仕様自体が、すでにユーザーフレンドリーとは言えない。
この一連の問題が示すのは、Windowsが「ユーザーのためのOS」から「Microsoftのためのデータ収集プラットフォーム」へとシフトしつつある中で、ユーザー側のリソース（ストレージ、CPU、ネットワーク、プライバシー）が一方的に消費され続けているという現実だ。Linuxへの移行を語る声が後を絶たないのは、技術的な優劣以前に、この「片方だけを破ることはできない」帳簿の構造から降りたいという切実な願いの表れだろう。