Macのディスクが空なのに満杯？rootのログフォルダを確認しよう

macOSTahoe ·
Macのディスクが空なのに満杯？rootのログフォルダを確認しよう

ストレージツールは /private/var/root に隠れた数十ギガバイトを見逃します。暴走するRTCReportingログの見つけ方と、その原因となる同期バグについて解説します。

たいていの人が頼るストレージツールをことごとく打ち負かすストレージ問題を紹介します。

Macが「ディスクの空き容量がほとんどない」と言っています。ストレージ分析ツールを開いて見つかったものを合計してみると、合計はmacOSが報告する使用量よりも数十ギガバイト少なくなります。ディスクユーティリティはスナップショットなしと報告します。アプリを削除し、写真をオフロードし、ゴミ箱を空にしても、数字はほとんど動きません。再起動すると1時間ほどは改善しますが、また空き容量が消えていきます。

そのファイルは実在します。ツールがそれを見られないのは、それが**/private/var/root**——root アカウントのホームディレクトリ——に存在していて、そうしたツールはすべてあなたのユーザー権限で実行されているからです。

この問題が最もひどく影響するMacでは、その大部分は一つの原因に集約されます。rtcreportingdというシステムデーモンが書き込むログファイルが、数十ギガバイトにも達する量になっているのです。Michael Tsaiは2026年8月21日に、M4 MacBook Airで/private/var/root/Library/Logsだけで74GBを消費していたケースを記録しており、そのフォルダは一度クリアしても1日で27GBまで戻ってきました。

ログそのものは病気ではありません。それは、誰も温度計を見ていないときに詰まったデーモンがどう見えるかを示しているにすぎません。この記事では、その容量を見つける方法、この作業全体を無駄にしてしまう定番のミスを避けながら容量を取り戻す方法、そして実際にそれを生成しているプロセスを見つける方法を扱います。

要点まとめ

  • /private/var/rootは、あなたのユーザーで動くものすべてから見えません。 macOS 26.5.2でls /private/var/rootがPermission deniedを返すことを確認済みです。ストレージ分析ツール、Finder、ディスクユーティリティの使用量表示はすべて、この中にあるものを見逃します。
  • rtcreportingdはrootとして動作する実在のApple純正システムデーモンです。 そのlaunchdジョブがUserName => rootと宣言していることを確認済みで、これこそがそのログがあなたのではなくrootのホームディレクトリに置かれる理由です。
  • 報告される容量は数十ギガバイトに達し、しかも急速に再増加します。 記録されたケースでは74GB、削除後1日で27GBまで戻りました。根本原因がまだ動き続けていたためです。
  • この定番のミスが作業全体を無駄にします。 sudoで動くGUIツールでファイルを削除すると、それはroot自身の見えないゴミ箱に移動します。空き容量は解放されません。即座に削除するか、rootのゴミ箱を空にする必要があります。
  • 停止した同期クライアントを疑ってください。 記録されたケースではrtcreportingdとfileproviderdがそれぞれCPU使用率100%近くに張り付いており、Dropboxを終了させると両方が止まりました。fileproviderdは、クラウドストレージのFile Provider拡張機能をホストするmacOSのプロセスです。
  • /private/var/rootの中で無闇にファイルを削除しないでください。 ログとキャッシュは削除しても安全です。それ以外のものはそうではなく、この記事はどちらがどちらかを具体的に区別しています。

なぜストレージツールがそれを見られないのか

修正方法の前に、その仕組みを理解しておきましょう——なぜなら、それを理解しておくことが、次回また見当違いのものを追いかけずに済む方法だからです。

rootにもホームディレクトリがあり、デーモンがそれを使っている

macOSでは、rootアカウントのホームディレクトリは/private/var/rootです。ほとんどの人は、これは基本的に空で、macOS復旧環境からTerminalを実行したときだけ触れるものだと思い込んでいます。しかし、それはもう何年も前から真実ではありません。rootとして動作し、状態やキャッシュ、ログを保存したいシステムデーモンは、あなた自身のホームディレクトリと同じLibraryのレイアウトを使って、そこに書き込みます。

/private/var/root/Library/Logs
/private/var/root/Library/Caches

このディレクトリが自分の手の届かない場所であることは、コマンド一つで確認できます。Terminalが昇格権限を持っていないMacで実行してください。

ls /private/var/root

macOS 26.5.2（ビルド25F84）でまさにこれを実行したところ、次のように返ってきました。

ls: /private/var/root: Permission denied

これはごく普通のUnixパーミッション拒否です——rootのホームはrootのみに制限されたモードになっています。これはTCCのプライバシー保護ではありませんし、フルディスクアクセスで解決できるものでもありません。Dockから起動したストレージ分析ツールはあなたのユーザーとして動いているため、ファイルシステムもあなたのユーザーとして走査します。そして、そのディレクトリ配下のすべてが、そのマップに開いた穴になるのです。

数字が食い違う理由はこれ

「ストレージツールの合計値が合わない」という症状を訴える人がいますが、その理由がこれです。記録されたケースでは、OmniDiskSweeperのフォルダ合計は、macOSが使用中と報告した値よりもおよそ90GB少なくなっていました。

これを、Macの空き容量の数字が食い違う他の理由から切り分けておく価値はあります。理由はいくつもあり、そのうちこのバグに該当するのは一つだけだからです。

Howard Oakleyは2026年8月21日にこの計算の全体像を示しており、彼自身のMac miniの数字がその要点を物語っています。

ソース同じボリューム上で使用中と報告された値
diskutil apfs listのコンテナ差分837.101 GB
ボリューム単位のCapacity Consumedの合計837.027 GB
Finderのボリューム情報826.67 GB
ディスクユーティリティ814.03 GB

4つのツール、4つの数字、約23GBのばらつき、そして何一つ間違いはありません。この違いは、コンテナとボリュームの会計の違い、パージ可能領域、APFS特有のファイルの振る舞いから来ています。

  • コンテナ対ボリューム。 APFSコンテナは複数のボリュームを内包し、それらは空き容量を共有します。「Macintosh HDの空き容量」と「コンテナ内の空き容量」は、答えの異なる別の質問です。
  • パージ可能領域。 macOSは一部のコンテンツを、必要に応じて削除可能なもの——キャッシュ、一部のスナップショット、ダウンロード済みコンテンツの一部——としてマークします。ディスクユーティリティ自身のヘルプブックには「パージ可能に指定されたファイルを手動で削除することはできませんが、容量が必要になるとmacOSがそれらを削除します」とあります。Oakleyは自身のDataボリュームで47.04GBのパージ可能領域を計測しました。
  • 特殊なファイル。 APFSのクローンファイルは分岐するまでストレージを共有します。スパースファイルはnullでないデータのみを保存します。一部のシステムファイルは圧縮されています。データレスファイルはデータをクラウド側に保持し、必要に応じて実体化します。空き容量の会計は現時点でディスク上にあるものを基準にします。

これらのどれも、恒久的に成長し続ける説明のつかない90GBを生み出すことはありません。差が小さく安定しているなら、それは正常な会計処理です。差が大きく、Macがアイドル状態のときにも増え続けるなら、何かがあなたに見えないファイルを書き込んでいるということです。

もっとよくあるストレージの混乱——縮まないシステムデータや解放されないスナップショット——については、Macのシステムデータが巨大な問題とmacOSストレージ管理ガイドで別途扱っています。まずはそちらを確認してください。この記事は、それらの説明が当てはまらないケースについてのものです。

rtcreportingdの正体

ここは正直に、限界を明かしておきましょう。というのも、これからインターネット上には、Appleが一度も文書化していないデーモンについての自信満々な説明が溢れることになるからです。

私たちが直接確認したこと（macOS 26.5.2、ビルド25F84にて）。

実行ファイルは/usr/libexec/rtcreportingdに存在し、サイズは約1.45MBです。そのlaunchdジョブは/System/Library/LaunchDaemons/com.apple.rtcreportingd.plistにあり、次のように読めます。

{
  "EnablePressuredExit" => true
  "EnableTransactions" => true
  "Label" => "com.apple.rtcreportingd"
  "MachServices" => {
    "com.apple.rtcreportingd" => true
  }
  "ProgramArguments" => [
    0 => "/usr/libexec/rtcreportingd"
  ]
  "UserName" => "root"
}

自分のMacでも確認できます——このplistは誰でも読み取り可能です。

plutil -p /System/Library/LaunchDaemons/com.apple.rtcreportingd.plist

UserName => rootが、ログの行き先すべてを説明しています。 rootとして動作するデーモンが~/Library/Logsに書き込めば、それは/private/var/root/Library/Logsに書き込むことになります。そこに何ら特殊な事情はありません。

このバイナリはSwiftで書かれており、内部のクラス名はstringsで確認できます。そこにはBackendHTTP、TransparencyLog、StorebagCache、StorebagCoordinator、SessionCoordinator、XPCActivity、そして——ここに注目——CacheCleanupActivityが含まれています。Machサービス名にはcom.apple.rtcreporting、com.apple.rtcreporting.pathmonitor、com.apple.rtcreportingd.storebagが含まれます。

私たちがお伝えしないことは、「RTC」が何の略なのか、あるいはこのデーモンが正確に何を報告しているのかです。Appleはそれを文書化しておらず、私たちも略語の展開を勝手に作り出して事実であるかのように提示するつもりはありません。クラス名から支持できるのは、控えめな説明です。すなわち、HTTP経由でApple側のバックエンドと通信し、ローカルに状態をキャッシュし、ネットワーク経路の可用性を監視し、自身のキャッシュを掃除するためのスケジュール済みアクティビティを持つ、レポーティングまたはテレメトリのサービスだということです。

その最後の点が興味深いところです。このデーモンには掃除ロジックがあります。 そのログが数十ギガバイトにまで肥大化するとき、妥当な読み方は「Appleがログのローテーションを忘れた」ではなく、「デーモンが処理して後始末できる速度を上回るペースで何かがイベントを生成している」というものです。それは、イベントを生成しているものが何なのかを指し示しています。

境界線をはっきりさせておくと、これはクラス名からの推論であって、Appleの実装についての断定ではありません。観測された挙動にたまたま合致する仮説として扱ってください。

Terminal showing disk usage analysis on macOS

容量を見つける

以下の作業にはすべてsudoが必要です。実行する前に、各コマンドを読んでください。

1. 差分が存在することを確認する

まず、macOSが使用中だと考えている容量を確認します。

df -h / /System/Volumes/Data

最近のMacでは2行が表示されます。というのも、システムボリュームは封印された読み取り専用のスナップショットであり、あなたのデータは同じコンテナ内の別のボリュームに存在するからです。私たちのテストMacでは次のようになりました。

Filesystem        Size    Used   Avail Capacity  Mounted on
/dev/disk3s1s1   926Gi    12Gi   331Gi     4%    /
/dev/disk3s5     926Gi   568Gi   331Gi    64%    /System/Volumes/Data

両方とも同じSizeとAvailを報告している点に注目してください——これはボリューム単位の割り当てではなく、共有されるコンテナの空き容量です。これは、先ほど説明したコンテナ対ボリュームの区別を具体的に示したものです。

次に、スナップショットを確認して、それが原因ではないことを確かめます。

diskutil apfs listSnapshots /System/Volumes/Data

そしてコンテナ全体のビューも。

diskutil apfs list

スナップショットがわずかで、コンテナのCapacity In Useがストレージ分析ツールで見つかった値をはるかに上回っている場合、あなたは見えないファイルの問題を抱えています。

2. rootのホームディレクトリを計測する

これが、問題を見つけ出すコマンドです。

sudo du -h -d 2 /private/var/root/

-d 2は深さを2階層に制限します。これは、完全な走査を待たずともLibrary/LogsかLibrary/Cachesが犯人かどうかを見極めるのに十分です。大きな問題を抱えたマシンでは、1〜2分かかることを見込んでおいてください。

もう一階層深く、最も問題の大きいものを並べ替えて見るには次のようにします。

sudo du -h -d 3 /private/var/root/Library | sort -h | tail -20

健全なMacでは、これらの合計は小さい値です——ギガバイトではなくメガバイト単位です。もし/private/var/root/Library/Logsが「G」の付いた、しかも先頭が1桁より大きい数字を返してきたら、それがあなたの失われた容量です。

3. 中身を見る

何かを削除する前に、まず見てください。

sudo ls -la /private/var/root/Library/Logs
sudo du -h -d 1 /private/var/root/Library/Logs | sort -h | tail

記録されたケースでは、中身は「ほぼ全てがRTCReportingによるもの」でした。もしあなたのケースで他の何かが支配的なら、それは対応方針を変えるべきだということを意味します——この記事の診断アプローチ自体は引き続き有効ですが、犯人は別のサブシステムになります。

4. GUIでの代替手段

ウィンドウでこれを見たいなら、OmniDiskSweeperは無料で、元の報告でこの問題を明るみに出したツールでもあります。重要なのは、rootのホームディレクトリを見るためには必ず昇格権限で再起動して起動する必要がある点です。通常起動すると、他のあらゆるツールと同じ不完全な結果しか見えません。

私たちのストレージ分析ツール総まとめで選択肢を扱っていますが、どのツールにも同じ制約が当てはまることに注意してください。ツールがrootとして動いていない限り、この容量はそのツールには見えません。

容量を取り戻す——そして作業全体を無駄にするミス

ここに罠があります。しかも上出来な罠です。

sudoで動いているGUIツールでこれらのファイルを削除すると、そのツールはいつも通りの動作をします。つまり、ゴミ箱に移動させるのです。しかしそのプロセスはrootとして動作しているため、それはrootのゴミ箱、すなわち/private/var/root/.Trashであり、あなたのDockには表示されず、あなたが空にしようと思いつくこともないでしょう。ファイルはまだディスク上に残っています。空き容量は変わりません。削除がうまくいかなかったのだと結論づけてしまうことになります。

OmniDiskSweeperの場合、具体的にはOptionキーを押しながらだと、DeleteがDelete Immediatelyに変わります。

Terminalからは、ログの中身を直接削除します。

sudo rm -rf /private/var/root/Library/Logs/*

実行する前に、このコマンドを読んでください。これはrootのLogsディレクトリの中身だけを削除し、それ以外の何も削除しません。パスを短縮しないでください。スラッシュの前にスペースを入れないでください。

続いて、以前の試行でrootのゴミ箱に何か入っていないか確認します。

sudo du -sh /private/var/root/.Trash

もし何かあれば、次のようにします。

sudo rm -rf /private/var/root/.Trash/*

rootのホーム内のキャッシュも、一般的には安全に消去できます——定義上、それらは再生成可能なものだからです。

sudo du -h -d 1 /private/var/root/Library/Caches | sort -h | tail

触ってはいけないもの。 /private/var/root自体を削除しないでください。/private/var/root/Libraryをまるごと削除しないでください。キーチェーンや環境設定、見覚えのないものを削除して回らないでください。ログとキャッシュは安全なカテゴリですが、そこにある他のものは、何らかの理由があってそれを置いたシステムコンポーネントに属するものです。

その後、再起動してください。そしてdf -hで再確認し、容量が実際に戻ってきたことを確かめてください。

次に、原因を突き止める

削除だけで止めてしまうと、容量は一度戻ってきてもまた消えていきます。記録されたケースでは、再起動から数分で5GBに、1日で27GBに戻っていました。

CPUを監視する

アクティビティモニタを開き、%CPUでソートして、2つのプロセスを探してください。

  • rtcreportingd ——ログを書き込んでいるデーモン
  • fileproviderd ——クラウドストレージのFile Provider拡張機能をホストするmacOSのプロセス

記録されたケースでは、アイドル状態のMac上で、両方とも継続的にCPU使用率100%近くに張り付いていました。

Terminalからは次のようにします。

ps -Ao pid,pcpu,comm | grep -E 'rtcreportingd|fileproviderd'

これら2つのプロセスは、どちらも健全なMacで普通に存在し動作しています——ストレージ問題が一切ない私たちのテストマシンでも、両方が動作していることを確認しました。それらが存在すること自体は正常です。持続的なCPU使用は正常ではありません。 同期の最中に数パーセント使うのは想定内です。Macを何も操作していないのに90〜100%に張り付いているのが、その兆候です。

ログが増えていくのを観察する

最も直接的な確認方法は、二度計測することです。

sudo du -sh /private/var/root/Library/Logs

Macをアイドルのまま10分待って、もう一度実行します。健全なMacでは、この数字は意味のある変化をしません。何もしていないのに目に見えて増えていくなら、何かがループしています。

まずクラウド同期を疑う

fileproviderdが決め手です。これは、File Provider拡張機能をホストするシステムプロセスで、Dropbox、OneDrive、Google Drive、Box、iCloud Driveがすべて使っている、Finderにクラウドファイルを表示させる現代的な仕組みです。これが継続的にCPUを消費しているなら、いずれかの拡張機能が詰まっています。

記録されたケースでは、そのクライアントはDropboxで、約1年間にわたって不調だったMacでした——設定通りにファイルをオフラインで保持しておらず、何も変わっていないのに常に同期しているように見えていました。Dropboxを終了させると、CPU使用もログの増加も即座に止まりました。

自分のMacでこれを試すには、同期クライアントを一つずつ終了させて様子を見てください。同期を一時停止するのではなく、メニューバーアイコンからQuitで完全に終了させてください。一時停止された拡張機能は、それでもロードされたままになっている可能性があるためです。

# after quitting a sync client, check whether the load dropped
ps -Ao pid,pcpu,comm | grep -E 'rtcreportingd|fileproviderd'

一つのクライアントを終了させることで両方のプロセスがアイドルに落ち着いたら、それが原因です。

同期クライアントへの対処法

手間の少ない順に、選択肢を挙げます。

  1. アップデートする。 File Provider拡張機能のバグはよくあることで、頻繁に修正されています。他の何よりも先に、アップデートがないか確認してください。
  2. サインアウトして、再度サインインする。 これは拡張機能のローカル状態を再構築し、驚くほど多くの同期詰まりのケースを解決します。
  3. クライアントを削除して、再インストールする。 より破壊的ですが、より徹底的です。
  4. データを他の場所に移す。 記録されたケースでの結末は、iCloud Driveへの移行でした。Dropboxが移行のためにファイルを確実にダウンロードできないことが判明し、著者は代わりにDropboxのWebインターフェースからフォルダをダウンロードすることになりました。その後iCloud Driveは「すべてを素早くアップロードし、その後CPU使用ゼロの状態に落ち着いた」とのことです。

最後の点は、正直に書き添えておく価値があります。ソース側のクライアントが壊れている状態でクラウドプロバイダー間を移行するのは、実際に骨が折れる作業であり、Webインターフェースが最も信頼できるエクスポート経路になるかもしれません。私たちのiCloud Driveガイドでは移行先の側を扱っており、もしiCloud Drive自体が不調なら、iCloud Driveの自動ダウンロードバグという既知の別問題があります。

Dropboxだけが特に悪いと言っているわけではありません。記録されたケースにおけるクライアントがたまたまそれだったというだけです。どのFile Provider拡張機能でも詰まる可能性はあり、どれを使っていても診断方法は同じです。

Activity Monitor showing high CPU processes

それ以外にストレージが隠れている場所

rootのホームディレクトリは、ほとんど誰も確認しない場所ですが、ユーザーレベルのツールが手も足も出ない唯一の場所というわけでもありません。もし差分が/private/var/rootにないなら、数字が嘘をついていると結論づける前に、以下を確認してください。

他のデーモンが所有するrootのデータ。 /private/var/rootはrootのホームが存在する場所ですが、システムコンポーネントは/private/var/db、/private/var/folders、/Library/Logsにも書き込みます。同じ方法で計測してください。

sudo du -h -d 1 /private/var/db | sort -h | tail
sudo du -h -d 1 /Library/Logs | sort -h | tail
sudo du -sh /private/var/folders

/private/var/foldersは、ユーザーごとの一時ファイルやキャッシュコンテナを保持しており、正当に数ギガバイトに達することがあります。これはmacOSによって管理されており、一般的には放っておくべきです。再起動すれば、揮発性の部分はクリアされます。

ローカルのTime Machineスナップショット。 これは、最も疑われやすく、実際にはほとんど原因ではない存在です。決めつけずに、確認してください。

tmutil listlocalsnapshots /
diskutil apfs listSnapshots /System/Volumes/Data

もし本当にスナップショットが問題であれば、macOSは容量が逼迫すると自動的にそれを間引きます。より深いケースについては、私たちのTime Machineトラブルシューティングガイドで扱っています。

他ユーザーのホームディレクトリ。 言われれば当たり前ですが、実際には見えません——そのMac上の別のアカウントに200GBの動画があっても、あなたのユーザーとして動いているストレージツールにはそれが表示されません。sudo du -h -d 1 /Usersが、それを一行で答えてくれます。

実行中のプロセスに開かれたままのファイル。 削除はされたものの解放されていない容量です。これは、プロセスがまだそのファイルディスクリプタを保持しているために起こります。再起動すると消える差分として現れます。

sudo lsof / 2>/dev/null | grep -i deleted | head

Mailのローカルストア、iOSデバイスのバックアップ、Xcode。 開発者やMailのヘビーユーザーのMacで、典型的に巨大で忘れられがちな3つのディレクトリです。

du -sh ~/Library/Mail
du -sh ~/Library/Application\ Support/MobileSync/Backup
du -sh ~/Library/Developer/Xcode/{DerivedData,iOS\ DeviceSupport,Archives} 2>/dev/null

これらはすべて、あなた自身のユーザーとして読み取り可能なので、ストレージ分析ツールは確かにそれらを見つけます——ただ長いリストに紛れて見落とされがちなだけです。sudoにエスカレートする前に、確認しておく価値があります。

実体化してしまったクラウドプレースホルダーファイル。 どの同期クライアントでも「オンラインのみで保持」する設定を使っている場合、バグやフルテキスト検索が静かにすべてをダウンロードしてしまうことがあります。それはこの記事で扱っているのと同じ種類の障害であり、通常は同期フォルダ自体の着実な増加として現れます。

これはどれくらいよくあることなのか

正直な答えは、私たちにもわからないし、これについて発信している他の誰にもわかっていない、というものです。

公に記録されているものとしては、具体的な数字と具体的な修正方法を伴う一次情報の報告、RTCReportingのストレージについてのApple Support Communityのスレッド、そして自分のストレージが何に使われているのか尋ねているユーザーたちのRedditスレッドがあります。これは、この問題が実在し再現可能であることを立証するには十分ですが、どれだけの割合のMacが影響を受けているかを言うには不十分です。

私たちが自分たちの確認から言えることは、rtcreportingdは、ストレージに何の問題もない普通のMacでも動作しており、そこでのログは特筆すべきものではなく、このデーモンには大半の場合うまく機能している掃除ロジックがある、ということです。これは既定の動作ではなく、一つの故障モードです。あなたのMacのストレージの数字が正しく合っているなら、修正すべきものは何もありません。

Appleはこれについてサポート文書を一切公開しておらず、認知したとも表明しておらず、文書化された修正を出荷したこともありません。もしこの問題に遭遇したら、Appleにフィードバックを送るのは5分の価値があります——誰も報告しなければ、認知されないままだからです。

よくある問題のトラブルシューティング

sudo duがいつまでも終わらない

大きい、あるいは激しく断片化したディレクトリツリーでは、それが正常です。まず-d 1を使ってどのトップレベルフォルダが大きいかを特定し、そのフォルダだけを掘り下げてください。すでに気になっているディレクトリがわかっているなら、ディスク全体に対してduを実行するのは避けましょう。

ログを削除したのに空き容量が変わらない

ゴミ箱の問題です。sudo du -sh /private/var/root/.Trashを確認し、sudo rm -rf /private/var/root/.Trash/*で空にしてください。これは、GUIツールを使ったほぼ全員がハマる罠です。

もう一つの可能性は、削除されたファイルをまだプロセスが開いたままにしていることで、その場合そのプロセスが終了するまで容量は解放されません。Macを再起動してから、もう一度確認してください。

容量が1日で戻ってきた

原因を見つけていないなら、想定通りです。ログを削除するのは症状への対処に過ぎません。アクティビティモニタのステップに進み、何がループしているかを見つけてください。

rtcreportingdがCPUを使っているのに、クラウド同期クライアントが一つもない

それなら、トリガーは別の何かです。アクティビティモニタをCPUでソートし、他に何がビジーになっているか見てください。統合ログでこのデーモン自体のアクティビティを確認します。

log show --predicate 'process == "rtcreportingd"' --last 1h --info | head -50

統合ログのクエリは実際に書き込まれたものしか返さないこと、そしてログデータには保持期限があることに注意してください——長い期間にわたるクエリが、正当に何も返さないこともあります。

ディスクユーティリティのFirst Aidが「ディスクは正常」と言う

それはそうなります。これはファイルシステムの破損ではありません。First Aidはメタデータの整合性をチェックするものであり、大きくても有効なファイルで満たされたディレクトリは、完全に整合性が取れています。

rtcreportingdを無効化すればいいだけでは？

私たちならそうしません。これはSystem Integrity Protectionが有効なMac上のAppleのシステムデーモンであり、症状を回避するためにシステムのlaunchデーモンを無効化すると、後になってもっと厄介な第二の問題を引き起こしがちです。それを駆動しているプロセスを修正することの方に取り組んでください。もしこのデーモンが、識別できるトリガーもなく不調になっているなら、それは回避すべき対象ではなく、報告する価値のあるAppleのバグです。

Macの容量が足りず、今すぐ空きが必要

診断を進めている間の、即座に安全な対処法です。自分のゴミ箱を空にし、上記の通りrootのゴミ箱を空にし、rootのLogsの中身を削除し、sudo du -h -d 1 /private/var/root/Library/Cachesを確認してください。これらを合わせれば、原因を見つけるまでの間、Macを再び使える状態にするのに十分な容量が解放されることがよくあります。特にこれがmacOSアップデートを妨げている場合の対処法は、私たちの容量不足によるアップデート失敗のガイドで扱っています。

FAQ

/private/var/rootとは何ですか？

macOSにおけるrootアカウントのホームディレクトリです。root以外は読み取れないため、あなたのユーザーとして動くツールはその中を見ることができません。rootとして動作するシステムデーモンは、あなた自身のホームフォルダと同じLibrary構造を使って、そこにログやキャッシュ、状態を保存します。

なぜFinderやストレージアプリはこれらのファイルを見られないのですか？

それらはあなたのユーザーとして動作しており、そのディレクトリのUnixパーミッションがあなたのユーザーを除外しているためです。これはフルディスクアクセスで解除できるプライバシー保護ではなく、通常のファイルパーミッションです。GUIツールがそのディレクトリを走査するには、昇格権限で再起動する必要があります。

rtcreportingdとは何ですか？

/usr/libexec/rtcreportingdにある、com.apple.rtcreportingdによって起動され、rootとして動作するAppleのシステムデーモンです。Appleはこれを文書化していません。その内部構造は、HTTP経由でAppleのバックエンドと通信し、ローカルキャッシュを維持するレポーティングサービスであることを示しています。健全なMacにも存在しており、それ自体は問題ではありません。

これはマルウェアですか？

いいえ。これは/usr/libexecにあるApple製のバイナリで、封印されたシステムボリューム内のlaunchデーモンによって起動されています。その署名は次のコマンドで確認できます。

codesign -dv --verbose=2 /usr/libexec/rtcreportingd

rootのLogsフォルダは、どれくらいの容量が正常ですか？

健全なMacでは小さいものです——本来、気づくことすらないはずのフォルダです。もしsudo du -sh /private/var/root/Library/Logsが2桁ギガバイトの何かを返すなら、それが問題です。Apple公式のしきい値はなく、実用的なテストは、Macがアイドルのときにそれが増えるかどうかです。

Macクリーニングアプリでこれは直りますか？

ほぼ間違いなく直りません。あなたのストレージ分析ツールがこれを見逃した理由と同じです。クリーナーが権限をエスカレートし、rootのホームディレクトリを具体的に走査しない限り、そのファイルは見えません。そして、たとえクリーナーがそれらを削除したとしても、原因がたまった不要ファイルではなくループしているプロセスである以上、また戻ってくるのを止めることはできません。

これは特定のMacやmacOSバージョンだけの問題ですか？

そう言えるだけの公開データはありません。記録されたケースはM4 MacBook Airでした。私たちはmacOS 26.5.2で、このデーモンとパーミッションの挙動を確認しました。この仕組みについては、特定のチップやmacOSバージョンに固有のものは何もありません——rootは、macOSが存在する限りずっとホームディレクトリを持っていました。

これはAppleに報告すべきですか？

はい、遭遇したなら報告してください。sudo du -h -d 2 /private/var/root/の出力、rtcreportingdとfileproviderdのCPU数値、そしてどの同期クライアントを止めたら解決したかを含めてください。Appleはこれについて何も公開していません。そして具体的な報告こそが、それを変える方法です。

まとめ

この問題がこれほどまでに苛立たしいのは、Macのストレージについてのあなたの直感がことごとく外れるからです。そのファイルは、見つけられるフォルダの中にはありません。スナップショットでもありません。ストレージペインが言う意味でのシステムデータでもありません。アプリを削除しても役に立たず、数字は合わず、それを見せてくれるはずの唯一のツールは、まさにあなたがsudoで実行しようと思いつかなかったツールなのです。

どこを見ればいいかさえわかれば、これは10分の作業です。duで/private/var/rootを計測し、ログを削除し、rootのゴミ箱を空にし、そして——実際に重要な部分ですが——アクティビティモニタを見張り続けて、それを再び満たしているプロセスを見つけ出してください。10回のうち9回、CPUリストでfileproviderdがrtcreportingdの隣に座っているなら、それは何か月も静かに壊れたままだったクラウド同期クライアントです。

そして、もしあなたのMacのストレージの数字が90GBではなく数ギガバイト程度の食い違いなら、安心してください。それは単にAPFSがAPFSらしく振る舞っているだけであり、Howard Oakleyの計算がそのすべてを説明してくれます。

関連記事：Macのシステムデータが巨大で縮まない · macOSストレージ管理と最適化 · Macストレージ分析ツール比較 · iCloud Drive完全ガイド · macOSアップデートが止まる：容量不足

出典： Michael Tsai, "Huge RTCReporting Logs and Dropbox", 2026年8月21日 · The Eclectic Light Company, "The arithmetic of free space", 2026年8月21日 · Apple Support Communityスレッド254838127（RTCReporting） · Apple, Disk Utility Help（パージ可能領域について） · macOS 26.5.2（ビルド25F84）でのローカル検証、2026年8月22日、ls、plutil、strings、df、psを使用。