Macが突然の再起動を繰り返す原因を調べたら、真犯人はSpotlightだった

Posted at 2026-06-28

1. はじめに

M1/M2/M3などの Apple Silicon Mac を使っていて、「突然画面がブラックアウトし、Macが強制的に再起動（カーネルパニック）する」 という謎の怪現象に遭遇したことはないでしょうか。

私自身、開発中の Python 常駐スクリプト（論文推薦 Bot）がメモリを 1.45GB も消費しており、スレッドやソケット接続が 100本以上も開いたままリークしているのを目撃したため、「自作ツールのリソース枯渇（OOM）が Mac を落としているに違いない」と確信していました。

そこで、常駐プロセスから PyTorch (SentenceTransformer) を完全排除して Google Gemini API 移行を断行するなどの「大手術」を行い、メモリを 500MB 以下、スレッド・ポート数を一桁にまで削り落としました。

しかし、それでも Mac の突然の再起動は治まりません。

「自分のコードじゃないなら、一体何が原因なんだ？」
システムログを深く掘り下げた結果、そこに写っていた真犯人は、macOS 標準のファイル検索インデクサである Spotlight（のPDF文字認識エンジン） 。

この記事では、Mac の再起動ループに悩まされている方に向けて、システムログ（DiagnosticReports）から原因を特定する手順と、その技術的メカニズム、そして最もシンプルな回避策を共有します。

2. トラブルの初期症状と「濡れ衣」

開発中の論文推薦システム（RSS をフェッチし、論文 PDF をダウンロードして、ベクトル化して ChromaDB に格納する Bot）を動かし始めてから、Mac の強制再起動が頻発するようになりました。特に夜間のバッチ処理中や、特定の論文をセーブした直後に Mac が突然落ちます。

ターミナルでリソースを確認すると、以下の状況でした。

$ ps aux | grep telegram_bot
masa  979  15.7  12.0  436043632  1450000  ??  S  12:29AM  Python telegram_bot.py

メモリ使用量: 物理メモリで 1.45GB 占有
スレッド数: 28スレッド
オープンされたソケットポート数: 104個 (HTTPS 接続のリーク)

「これはひどい。」
PyTorch (SentenceTransformer) が CPU や GPU（MPS）をロードし、さらにクローラーなどのサブプロセスが次々に立ち上がるたびに 1.5GB 近くのメモリを消費していたため、OS がメモリ限界（OOM）に達してカーネルパニックを起こしたのだと考えました。

施したコード大手術

PyTorch の完全排除: ローカルのベクトル推論モデルを削除し、Gemini API の埋め込みモデル（gemini-embedding-001）へ完全移行。
キャッシュの導入: スコアリング対象（2500本以上）を毎回 API で呼ぶと破綻するため、SQLite の embedding カラムに 768次元ベクトルをキャッシュさせ、API 呼び出しを最小限に。
接続リークの修正: 常時接続を HTTPS 4ポートのみに固定。

この結果、Bot は常時 500MB 前後、スレッド数一桁で超高速に動作するようになり、起動も 0.1秒になりました。
しかし、大手術完了の安堵も束の間、Mac は再びブラックアウトし、再起動しました。

3. 真犯人の特定：システムログを覗く

自作コードがこれ以上ないほどクリーンになったにもかかわらず Mac が落ちるため、OS 側の挙動を疑い始めました。

① システム再起動履歴の確認

まずはターミナルで last reboot を実行し、システムが落ちた正確な時間帯をリストアップします。

$ last reboot | head -n 10
reboot time                                Mon Jun 29 05:31
reboot time                                Mon Jun 29 01:21
reboot time                                Mon Jun 29 01:19
shutdown time                              Mon Jun 29 01:14
reboot time                                Sun Jun 28 23:11

昨日から今日にかけて、数分おき、あるいは深夜帯に何度も再起動が起きている不吉な履歴が記録されていました。

② クラッシュレポートの調査

macOS がクラッシュした際のバックグラウンドサービスのログは、/Library/Logs/DiagnosticReports/ に .ips という拡張子で保存されます。
ここを時系列でソートして検索してみます。

$ ls -t /Library/Logs/DiagnosticReports/ | grep -E "panic|ips" | head -n 5
CGPDFService-2026-06-28-234313.ips
mdworker_shared-2026-06-28-234209.ips
CGPDFService-2026-06-28-234119.ips
CGPDFService-2026-06-28-234111.ips
mds_stores-2026-06-28-232926.ips

システムが落ちた時間帯（23:40前後）と完全に一致して、CGPDFService および mdworker_shared というサービスが大量のクラッシュログを吐き出していました。

mdworker_shared / mds_stores: Spotlight がファイルのインデックス（検索用の目次）を作成するためのバックグラウンドワーカー。
CGPDFService: macOS 標準の PDF テキスト解析やレイアウト抽出を行うバックグラウンドサービス。

③ `.ips` (クラッシュログ) のデバッグ解析

クラッシュした CGPDFService の IPS ログの冒頭を覗いてみます。

  "faultingThread" : 3,
  "threads" : [
    {
      "triggered": true,
      "id": 46998,
      "threadState": {
        "flavor": "ARM_THREAD_STATE64",
        "esr": {"value":2449473540,"description":"(Data Abort) byte read Translation fault"},
        "pc": {"value":7397977112,"matchesCrashFrame":1}
      },
      "queue": "NSOperationQueue 0x1047a81a0",
      "frames": [
        {"imageOffset":803144,"symbol":"CRTextRecognition::CRCTLD::CRConstrainedTextLineDetectionImpl::findWhitespaceRegions(...)","imageIndex":4},
        {"imageOffset":821268,"symbol":"CRTextRecognition::CRCTLD::CRConstrainedTextLineDetectionImpl::groupRegions(...)","imageIndex":4},
        {"imageOffset":5065948,"symbol":"PageLayout::getOrderedLayout(...)","imageIndex":5},
        {"imageOffset":1491524,"symbol":"CGPDFPageCopyPageLayoutWithCTLD","imageIndex":5},
        {"imageOffset":4847108,"symbol":"CGPDFPageCopyString","imageIndex":5},
        {"imageOffset":7076,"symbol":"__29-[CGPDFPageImpl getPageText:]_block_invoke","imageIndex":0}
      ]
    }
  ]

コールスタックをたどると、クラッシュの決定的な証拠が写っていました。

Spotlight の指示で CGPDFPageCopyString（PDFのテキスト抽出）が走る。
その内部で CRTextRecognition (macOS標準の文字認識・OCRエンジン。Live Text 機能の裏側) が呼び出される。
OCR エンジンがテキストの領域検出（findWhitespaceRegions / groupRegions）を行っている最中に、Data Abort（メモリの不正アクセス例外＝セグメンテーションフォールト）が発生してプロセスが急死している。

4. なぜ「PDFのOCR」でMac全体が再起動するのか？

通常、バックグラウンドの XPC サービス（CGPDFService など）がメモリバグで落ちるだけなら、そのサービスが再起動するだけで、Mac 本体が強制終了することはありません。

しかし、Apple Silicon (M1/M2/M3) Mac のユニファイドメモリ環境において、この挙動は牙を剥きます。

GPU/Neural Engine の巻き込み:
TextRecognition による OCR スキャンは、CPU ではなく Apple Neural Engine (ANE) や GPU (Metal) のハードウェア支援を用いて並列実行されます。
カーネル空間のフリーズ (Kernel Panic):
ハードウェアと密接に連携するドライバ空間（AGXMetal等）で、この文字認識スレッドがメモリ破壊やヌルポインタ参照などの致命的な例外を引き起こすと、デバイスドライバ全体がフリーズ（デッドロック）します。
強制再起動:
macOS はカーネルレベルのフリーズを検知すると、システム崩壊を防ぐために強制的に「カーネルパニック」を起こし、ブラックアウトしてシステムを再起動させます。

トリガーとなったファイル

自作ツールが新着論文の PDF をダウンロードした瞬間、Spotlight がその PDF を検知し、裏で自動的に OCR インデックス（Live Text のため）を作成しようとします。
その際、学術論文の PDF に大量に含まれる複雑な数式、ギリシャ文字、あるいは特殊な数式用フォントのレイアウトを macOS の文字認識エンジンが処理しきれず、メモリ破壊を起こして OS ごと Mac を巻き添えにして落ちていたのです。

5. 解決策：犯人を「出入り禁止」にする

原因さえ分かれば、対策は極めてシンプルです。
Spotlight がダウンロードされた論文 PDF を勝手にスキャンしにいくのを禁止すれば、クラッシュは 100% 発生しなくなります。

Spotlightのプライバシー除外設定手順

Mac の 「システム設定」 を開きます。
「SiriとSpotlight」 を選択します。
画面の最下部にある 「Spotlightのプライバシー...」 ボタンをクリックします。
左下の「＋」ボタンを押すか、Finder から PDF を保存しているフォルダ（例: 論文フォルダやダウンロードフォルダ） をドラッグ＆ドロップしてリストに追加します。
「完了」を押して保存します。

これだけで、Spotlight（mdworker）は該当フォルダ内の PDF のスキャンを完全にスキップするようになり、Mac はピタッと落ちなくなりました。

6. おわりに（まとめと教訓）

「Mac が落ちるのは自分のコードのせいだ」と思い込み、数日間コードの最適化や PyTorch のスレッド数制限に頭を抱えていましたが、蓋を開けてみれば macOS 標準の OCR エンジンが数式 PDF に敗北して自爆していた、というオチでした。

しかし、このトラブルシューティングのおかげで、

常駐 Bot が PyTorch 排除により 1.45GB ➡️ 500MB に軽量化された
ベクトルの SQLite キャッシュ化で処理が爆速になった
埋め込みモデルを Gemini API に移行したことで、RAG の検索精度が劇的に向上した

という大きな副産物（怪我の功名）を得ることができました。

自作の常駐ツールやバッチ処理によって Mac が突然落ちる現象に遭遇した際は、コードを疑う前に、まずは /Library/Logs/DiagnosticReports/ を覗いて、Spotlight が PDF 相手に自爆していないか確認してみるが強くお勧めです。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up