MacのReportCrashとは何ですか?
macOSにおいて、ReportCrashは「launchd」親プロセスの下で動作する組み込みのクラッシュハンドラ(crash handler)です。アプリやバックグラウンドプロセスが予期せず終了すると必ずこのコンポーネントが起動し、何が起こったかを検査し、開発者(そして時にはあなた)が問題の原因を確認できるように診断レポートをディスクに書き込みます。

技術的には、ReportCrashは2つの形態で動作します:
- ユーザーレベルのプロセスのための LaunchAgent として、レポートをあなたの
~/Library/Logs/DiagnosticReports/フォルダに書き込みます。 - システムおよびroot所有のプロセスのための LaunchDaemon として、システム全体の診断ログディレクトリにレポートを保存します。
最近のmacOSバージョンでは、おなじみの「アプリが予期せず終了しました。Appleに送信しますか?」というダイアログは、Problem Reporterを目に見えるフロントエンドとし、ReportCrashが舞台裏で重労働の多くを行う、より広範なレポートスタックの一部です。
通常の状況下では、この活動に気付くことはほとんどありません。アプリがクラッシュし、ReportCrashが短時間介入してログを書き、終了します。CPU使用率が一瞬急上昇し、その後ゼロに戻ります。これが本来の動作です。
なぜReportCrashがCPUを独占するのか
ReportCrashが50-300%のCPUを消費(マルチコアシステム上で)し、アクティビティモニタ(Activity Monitor)に絶えず再表示されるのを目にする場合、それが真の犯人であることはほぼありません。それは使者(メッセンジャー)です。本当の問題は、短いループの中でクラッシュし続けている他の何かです。
一般的なパターンは次のとおりです:
- プロセスが起動します。
- ほぼ即座にクラッシュします。
- launchdがそれを再起動します。
- ReportCrashが別の障害を処理するために起動します。
- これがノンストップで繰り返されます。

クラッシュレポートの生成と圧縮は些細な作業ではないため、このループに陥ったプロセスはReportCrashを24時間体制で忙しくさせる可能性があります。フォーラムやQ&Aサイトでの多数のユーザーレポートは同じ物語を示しています:ReportCrashの高い持続的なCPU使用率は、ほぼ常に、クラッシュと再起動を止めないバックグラウンドエージェント、拡張機能、またはフレームワークと相関しています。
典型的な根本的な原因は次のとおりです:
- 破損したデータで詰まった同期およびインデックス作成デーモン(例:連絡先、提案、または検索関連サービス)。
- macOSアップデート後に壊れたサードパーティのメニューバーアプリやヘルパー。
- LaunchAgentsやLaunchDaemonsがもはや存在しないバイナリを起動し続けているアンインストールされたアプリの残骸。
- テスト中にコンポーネントが繰り返しクラッシュする開発者ツールやシミュレータ(Xcode、iOSシミュレータなど)。
要するに、ReportCrashがうるさいのは、他の何かが病気だからです。目標は、その「何か」を見つけ、修正または削除し、その後に初めてReportCrash自体に触れることを検討することです。
ちなみに、このパターンは私が取り上げた他の高いCPUの話、例えば chronod、contactsd、syspolicyd、および wdavdaemon に関わるものと非常によく似ています – 小さなバックグラウンドワーカーが脱線し、システムパフォーマンスを道連れにします。
MacでReportCrashの高いCPU使用率を修正する方法
ステップ1. ループでクラッシュしているものを特定する
一つだけ行うなら、これを実行してください。ReportCrashを過剰動作モードに引きずり込んでいるプロセスが何であるかを知る必要があります。
- **コンソール(Console)**を開く
- Command–Spaceを押し、
Consoleと入力してReturnを押します。
- Command–Spaceを押し、
- サイドバーで**クラッシュレポート(Crash Reports)**を探します(または「レポート」の下の「Crash Reports」セクションを使用)。
- **日付(Date)**順に並べ替え、最新のエントリを確認します:
- 短期間に同じプロセス名が何度も繰り返されているのが見えるでしょう。
- クラッシュレポートが空に見える場合は、以下に切り替えます:
- system.log または すべてのメッセージ(All Messages)、その後
crash、Service onlyなどの用語を検索します。
- system.log または すべてのメッセージ(All Messages)、その後

以下を書き留めてください:
- 問題のあるプロセス名(例:
suggestd、メニューバーアプリ、何らかのヘルパー)、 - 表示されている場合はそのパス、および
- おおよそどのくらいの頻度でクラッシュするか。
これがあなたの主な容疑者です。
ステップ2. 問題のあるアプリまたはコンポーネントを削除または修復する
何がクラッシュしているかがわかったら、最善の修正方法は通常、その特定のアイテムを更新、リセット、またはアンインストールすることです。
- 知っていて使用している通常のアプリの場合:
- 実行中の場合は終了します。
- メニュー(多くの場合 アプリ名 ▸ アップデートを確認)またはApp Store経由でアップデートを確認します。
- クラッシュが続く場合は、クリーン再インストールを試します:
- アプリケーションからアプリをゴミ箱にドラッグします。
- 再起動します。
- 公式ソースから新しいコピーをダウンロードして再インストールします。
- もう気にしないアプリの場合:
- アプリケーションで、明らかなヘルパーツール(アンインストーラー、アップデーター)と一緒にそれを削除します。
- その後、以下の場所で残りのコンポーネントを確認します:
~/Library/Application Support/~/Library/LaunchAgents//Library/LaunchDaemons/
- そのアプリに明確に関連するアイテム(名前やベンダーが一致するもの)のみを削除します。

- システムサービスの場合(例:
suggestd、連絡先関連、またはiCloud同期):- 関連する機能を一時的に無効にします:
- システム設定 ▸ インターネットアカウントで問題のあるアカウントをオフにします。
- iCloud連絡先、SiriとSpotlightの提案、または同様のアイテムをオフに切り替え、しばらく待ってからオンに戻します。
- 特定のアカウントや機能を無効にした後にCPUの嵐が収まる場合、不正なデータはそこに存在する可能性が高いです。
- 関連する機能を一時的に無効にします:

考え方は単純です:クラッシュし続けるものが消えるか、正しく振る舞い始めれば、ReportCrashはもはやノンストップで実行する理由がなくなります。
ステップ3. 特大のクラッシュログと診断をクリアする
クラッシュループを手なずけた後でも、システムには何千もの古いクラッシュレポートが散乱している可能性があります。それら自体が通常CPUスパイクを引き起こすことはありませんが、ディスク容量を浪費し、分析をノイズだらけにする可能性があります。
以下のように安全に削除できます:
- Finderで、Shift–Command–Gを押して**フォルダへ移動…**を開きます。
- これらの場所を一つずつ訪れます:
~/Library/Logs/DiagnosticReports//Library/Logs/DiagnosticReports/(管理者権限が必要な場合があります)
- 古い
.crashおよび.panicファイルをゴミ箱に移動します(バックアップが必要な場合はアーカイブフォルダへ)。 - すべてが安定していると確信したら、ゴミ箱を空にします。

根本的な原因が続く場合、これはReportCrashのCPU使用を直接止めるものではありませんが、Macを整理整頓し、バックグラウンドI/Oをわずかに減らすことができます。
ステップ4. 問題のあるログイン項目とバックグラウンドヘルパーを無効にする
非常に一般的なシナリオは、とうの昔に忘れたアプリのログイン項目またはLaunchAgentが、もはや存在しない何かを起動しようとしている場合です。そのバイナリは正しく起動できず、即座にクラッシュし、ReportCrashがスパムされます。
以下のクリーンアップを実行してください:
- ログイン項目を確認
- システム設定 ▸ 一般 ▸ ログイン項目に移動します。
- ログイン時に開く と バックグラウンドでの実行を許可 の下で、認識できないか、もはや使用していない項目を無効にします。
- LaunchAgentsとLaunchDaemonsを検査
Finderで、移動 ▸ フォルダへ移動… を使用し、以下を見ます:~/Library/LaunchAgents//Library/LaunchAgents//Library/LaunchDaemons/
- 各フォルダについて:
- 名前で並べ替え、アンインストールされたアプリに明らかに属しているアイテムを探します。
- 疑わしい
.plistファイルを即座に削除するのではなく、デスクトップの一時フォルダに移動します。 - 再起動し、アクティビティモニタを見てReportCrashが落ち着くかどうかを確認します。

数日間すべてが正常に動作する場合、それらの隔離された .plist ファイルを安全に削除できます。重要な何かが壊れた場合は、元に戻してください。
ステップ5. セーフモードでテストする
セーフモードは、サードパーティのコンポーネントが関与しているかどうかを知るための素早い方法です。この診断モードでは、macOSは不可欠な拡張機能のみをロードし、ほとんどのログイン項目とLaunchAgentsを無効にします。
- Macをシャットダウンします。
- 電源を入れ、CPUタイプに適したキーを押し続けます:
- Intel Mac: 起動音の直後にShiftを押し続け、ログインウィンドウが表示されるまで待ちます。
- AppleシリコンMac:
- 「起動オプションを読み込み中」と表示されるまで電源ボタンを押し続けます。
- 起動ディスクを選択し、Shiftを押し続け、セーフモードで続けるをクリックします。
- ログインして**アクティビティモニタ(Activity Monitor)**を開きます。
セーフモードではReportCrashが静かでも、通常の再起動後に再び暴走する場合、ほぼ間違いなくサードパーティのソフトウェア(ログイン項目、カーネル拡張、ヘルパーツール)を扱っています。その手がかりを使って、ステップ2と4をより積極的に再確認してください。
ステップ6. SMCとNVRAMをリセットする(頑固なケースの場合)
ReportCrashに直接結びついてはいませんが、電源管理やハードウェア状態の低レベルの不具合は、時としてランダムな繰り返しのクラッシュやシステムの不安定さとして現れます。SMC(Intel Mac)とNVRAMをリセットすることで、それらのクモの巣を取り払うのに役立つ場合があります。
手順はMacのモデルによって異なりますが、大まかには次のとおりです:
- NVRAMリセット(Intel Mac):
- Macをシャットダウンします。
- 電源を入れ、すぐにOption–Command–P–Rを押し続けます。
- 約20秒間キーを押し続けてから放します。
- SMCリセット(Intel Mac):
取り外し可能なバッテリーの有無、iMac、Mac miniによって手順が異なります。正確なモデルとmacOSバージョンのAppleの指示を参照してください。
AppleシリコンMacでは、個別のSMCまたはNVRAMリセットはありません – きれいなシャットダウンと電源投入のシーケンスが実質的に同じことを行います。
アプリレベルの原因を除外し、これらのリセットを実行した後でもReportCrashの高いCPUが続く場合は、「高度な調整」の領域にいます。
ステップ7. (高度)ReportCrashを一時的に無効にする
このステップはオプションであり、経験豊富なユーザーを対象としています。既知の回避不可能なクラッシュループが存在する環境(例:ファジング、特定のテスト設定)では、一部の管理者は終わりのないログを生成してリソースを浪費しないようにReportCrashを無効にすることを選択します。
一般の家庭用またはオフィス用Macの場合、これを恒久的な修正ではなく、真の犯人を追跡する間の短期的な回避策としてのみ推奨します。自動クラッシュ診断を失い、より深い問題の兆候を隠す可能性があります。
それでも続行したい場合は、ターミナルからReportCrashのLaunchAgentとLaunchDaemonをアンロードできます:
- アプリケーション ▸ ユーティリティからターミナルを開きます。
- これらのコマンドを慎重に実行します(2つ目のコマンドでは管理者パスワードの入力が求められます):
launchctl unload -w /System/Library/LaunchAgents/com.apple.ReportCrash.plist
sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.ReportCrash.Root.plist

これにより、ReportCrashがユーザーおよびシステムプロセスに対して自動的に起動するのを防ぎます。
後でクラッシュレポートを再度有効にするには、以下を実行します:
launchctl load -w /System/Library/LaunchAgents/com.apple.ReportCrash.plist
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.ReportCrash.Root.plist
もう一度言いますが、これを最初の手段ではなく、最後の手段として扱ってください。ReportCrashを無効にすることで問題が「解決」したように見える場合、実際には体温計を取り外しただけで、熱を治したわけではありません。
今後のReportCrash問題を防ぐ方法
すべてのクラッシュを防ぐことはできませんが、いくつかの習慣を守ることで、制御不能なReportCrashインシデントの確率を減らすことができます:
- macOSとコアアプリを最新の状態に保つ:安定性の修正は、システムとアプリのリリースノートの常連です。
- スタートアップ項目を厳選する:定期的にログイン項目を確認し、起動ごとのロードが不要なものはすべて無効にします。
- アプリをきれいにアンインストールする: アプリの使用を停止するときは、アプリケーション内のメインバンドルだけでなく、サポートファイルや起動ヘルパーも削除します。
- 怪しいインストーラーやバンドルを避ける: アドウェアや質の悪いバックグラウンドエージェントは、ブラウザハイジャッカーだけでなく、奇妙なクラッシュの一般的な原因です。
- アクティビティモニタに目を光らせる: ファンが突然回り始めた場合、CPUとエネルギーのタブをちらっと見るだけで、慢性的な問題になる前に誤動作しているプロセスを見つけることができます。
まとめ
CPUへの影響が出始めたとき、ReportCrash自体を責めるのは誤解です。プロセスが何時間もCPUを独占する場合、それは何らかのアプリ、サービス、または残骸コンポーネントが、容赦ないクラッシュと再起動のループに陥っていることを示す強い指標です。
修正は通常、劇的というよりは方法論的です:何がクラッシュしているかを特定し、それを修復または削除し、ログイン項目とLaunchAgentsをクリーンアップし、その後に初めてReportCrashを一時的に無効にするなどの高度な手段を検討します。根本的な不安定性がなくなれば、Macはいつもの静かで、涼しく、目立たない動作に戻るはずです。
FAQ
1. ReportCrashはMacのウイルスやマルウェアですか?
いいえ。ReportCrashは、クラッシュを分析し診断レポートを保存する責任を持つ、正当なAppleシステムコンポーネントです。もしCPUを大量に使用しているなら、それはほぼ常に別のプロセスが誤動作している症状であり、それ自体の感染ではありません。
#
2. アクティビティモニタでReportCrashプロセスを強制終了しても安全ですか?
macOSを壊すことなくアクティビティモニタ(Activity Monitor)からReportCrashを強制終了できますが、それは一時的な措置に過ぎません。根本的なアプリやサービスがクラッシュし続ける場合、launchdは最終的にReportCrashを再起動し、CPUスパイクが戻ってきます。
#
3. どのアプリがReportCrashにCPUを大量に使用させているかを知るにはどうすればよいですか?
コンソール(Console)で最近のクラッシュレポート(Crash Reports)や system.log 内の繰り返されるエントリを確認してください。短期間に何度も表示される同じプロセス名が通常犯人です。そこから、そのアプリやコンポーネントを更新、リセット、またはアンインストールしてください。
#
4. Macでのクラッシュレポートを永久に無効にできますか?
はい、launchctl を介してReportCrash起動サービスをアンロードできますが、それは自動クラッシュ診断を失い、より深い問題の初期兆候を隠す可能性があることを意味します。ほとんどのユーザーにとっては、クラッシュレポートを有効にしたまま、クラッシュしているものを修正する方が良いでしょう。
#
5. ReportCrashの問題を修正するためにmacOSの再インストールを検討すべきなのはいつですか?
クリーンなmacOSの再インストールは最後の手段です。次の場合にのみ検討してください:
- 容疑者を削除し、ログイン項目をクリーンアップし、セーフモードでテストし、SMC/NVRAMをリセットした後でも、ReportCrashが依然として高いCPUを消費している場合;そして
- 複数のシステムプロセスが明確な共通の原因なしにクラッシュしている場合。
そのシナリオでは、データをバックアップして新規インストールを行うことで、深く破損したシステムコンポーネントやフレームワークを除外できます。
