最近、メインで使用している M2 MacBook Air（RAM 16GB）で、1日に何度もGUIがフリーズし、最終的に画面が一瞬紫色になって強制再起動するという致命的なトラブルに見舞われました。
ウィンドウの切り替えもできず、カーソルはレインボーになり、やがて操作不能になります。最初は特定のアプリのバグやメモリ不足を疑いましたが、DiagnosticReports を解析した結果、背後で信じられない規模のディスク I/O の暴走と、それに伴うファイルシステムの崩壊が起きていたことが判明しました。
本記事では、この異常事態の「真の原因」と、OS アップデートだけでは決して治らなかった理由、そして最終的な解決手順をエンジニア視点でまとめました。
1. 表面的な原因と初期調査の罠
症状の概要
最初は内部ディスプレイでの通常使用時に発生し、その後すぐに外部モニター（WQHD 240Hz）接続時のクラムシェルモードでも頻発するようになりました。画面が一瞬紫になり、勝手に再起動します（カーネルパニック）。
最初のアプローチ（外れ）
まず疑ったのは、macOS の検索インデックス機能である Spotlight と QuickLook のサムネイル生成でした。
/Library/Logs/DiagnosticReports のログ（.diag ファイル）を見ると、mds_stores が30分で約2GBもの書き込みを行っていたからです。
「Spotlight の書き込みが SSD を圧迫し、240Hz の画面描画（WindowServer）に遅延が生じてパニックになっている」と仮説を立て、以下の対策を実施しました。
-
sudo mdutil -a -i offによる Spotlight の一時停止 - QuickLook キャッシュのクリア
- RAM と APFS の整合性テスト（この時点では正常）
結果：全く改善せず、相変わらずフリーズと再起動を繰り返しました。
2. ズバリ、真の原因は何か？
さらに深くシステムログを解析したところ、真犯人が姿を現しました。
真の原因は、photolibraryd（写真ライブラリ管理プロセス）の同期異常による、SSD の I/O 帯域の枯渇でした。 macOS 26.3.1 上で発現しており、ユーザー側の使い方やサードパーティ製アプリの問題ではなく、OS レベルの不具合と考えられます。
実際のログが語る「証拠」
Mac がクラッシュしたり、バックグラウンドのプロセスが異常なリソース消費を行った場合、その証拠は以下のディレクトリに保存されます。
ログの保存場所：/Library/Logs/DiagnosticReports/
このディレクトリ内に生成されていた photolibraryd_2026-03-13-065350_Waykash-MacBook-Air.diag を開くと、信じがたい記録が残っていました。以下が実際のログの抜粋です。
Date/Time: 2026-03-12 18:08:57.361 +0900
End time: 2026-03-13 06:53:45.761 +0900
OS Version: macOS 26.3.1 (Build 25D2128)
Command: photolibraryd
Path: /System/Library/PrivateFrameworks/PhotoLibraryServices.framework/Versions/A/Support/photolibraryd
Resource Coalition: "com.apple.photolibraryd"(1022)
On Behalf Of: 365 samples corespotlightd [781] (365 samples originated by dasd [447])
Event: disk writes
Action taken: none
Writes: 34.36 GB of file backed memory dirtied over 45888 seconds (748.77 KB per second average), exceeding limit of 397.68 KB per second over 86400 seconds
恐怖の「34GB」無限ループ書き込み
Writes: 34.36 GB という記述の通り、photolibraryd が約12.7時間（45,888秒）の間に 34.36 GB ものデータをバックグラウンドで書き込み続けていました。
スタックトレースを追うと、メッセージアプリ等で送られてきたメディアを処理・統合する PLSyndicationSyncEngine が CoreData（SQLite）に対して異常な頻度でコミットを繰り返していることが確認できます。corespotlightd からの検索インデックス要求（dasd 経由）も巻き込み、事態は悪化の一途をたどっていたのです。
システムがフリーズするまでの流れ
-
photolibrarydの同期異常が発現し、裏で34GB以上の書き込みを強行。M2チップの Unified Memory と SSD の I/O を極限まで食いつぶします。 - その状態で240Hzの外部モニターへフレームを描画しようと WindowServer が処理要求を発行しますが、I/O が枯渇しているため応答不能に陥ります。
- 画面がフリーズし操作不能となったため、電源ボタン長押しによる強制終了（
btn_rst）を実施。これが紫画面を伴った再起動として記録されます。
3. なぜ OS アップデートで改善しなかったのか？（ログが示す崩壊の連鎖）
原因がわかったところで、滞留していた macOS の緊急セキュリティ対応（RSR）アップデートを適用しました。しかし、フリーズは数日後に再発してしまいました。
なぜ OS をアップデートしても治らなかったのでしょうか？そこには恐ろしい「負の連鎖」が待っていました。
証拠1：アップデートが引き金となった「同期の強制再開」
OS アップデートを適用すると、システムはセキュリティや整合性を確認するため、停止していたはずの様々なバックグラウンドタスクをリセット・再開させます。これにより、一時的に息を潜めていた photolibraryd の同期異常が再び最初からスタートしてしまいました。
実際のログ（photolibraryd_2026-03-22-031429_Waykash-MacBook-Air.diag）：
Command: photolibraryd
OS Version: macOS 26.3.1 (Build 25D771280a)
Event: disk writes
Writes: 34.36 GB of file backed memory dirtied over 29133 seconds (1179.43 KB per second average), exceeding limit of 397.68 KB per second over 86400 seconds
OS アップデート適用直後（ビルド番号が 25D2128 → 25D771280a に更新されたタイミング）の3月22日に、再び34.36GBもの異常な書き込みが再開されています。注目すべきは、1回目（748 KB/秒・約12.7時間）と比べ、2回目は1,179 KB/秒・約8.1時間と、書き込み速度が約1.6倍に悪化している点です。ファイルシステムの損傷が進むにつれ、I/O の暴走が加速していたと考えられます。
証拠2：限界を超えた強制終了の痕跡
フリーズのたびに電源ボタンの長押し（強制終了）を繰り返した結果、システムにはハードウェアリセットの痕跡が多数刻まれていました。
実際のリセットカウンタ（ResetCounter-2026-03-25-181246.diag）：
Boot faults: rst btn_rst,btn_seq_reset timeout,dblclick_timeout
btn_rst は物理ボタンによる強制リセットを示します。これが後述する致命的なファイルシステム破損を引き起こした決定的な証拠です。
証拠3：ファイルシステム（APFS）の破損と自己修復によるCPU異常消費
これが最も致命的でした。度重なる強制終了により、書き込み途中だったデータが SSD 上に放置され、APFS（Apple File System）のディレクトリ構造に不整合（Dirty な状態）が生じていたのです。
実際のログ（apfsd_2026-03-22-124012_Waykash-MacBook-Air_cpu_resource.diag）：
Command: apfsd
Path: /usr/libexec/apfsd
Event: cpu usage
Action taken: none
CPU: 90 seconds cpu time over 107 seconds (84% cpu average), exceeding limit of 50% cpu over 180 seconds
ファイルシステム管理デーモンである apfsd が、不整合の修復をバックグラウンドで試みて CPU 使用率84% を超過し続けていました。通常ではあり得ない負荷です。
証拠4：SSD への高頻度 I/O アクセスの継続
APFS が破損した状態でブラウザやエディタがアクセスを要求したことで、SSD への I/O が絶えず高負荷状態に置かれていました。signpost_reporter_2026-03-25-133728_Waykash-MacBook-Air_cpu_resource.diag のスタックトレースには、APFS 経由の書き込みと NVMe 完了割り込みが高頻度で発生していた記録が残っています。
vnode_dev_flush_buf → _vnode_dev_write → buf_bawrite
→ AppleAPFSContainerScheme::write
→ IOBlockStorageDriver::prepareRequest
IONVMeController::HandleInterruptRequest
→ IOBlockStorageDriver::prepareRequestCompletion
→ buf_biodone
APFS からの書き込みリクエストと NVMe の完了割り込みが断続的に積み重なっており、破損したファイルシステム上ではわずかな I/O 負荷でもシステム全体が応答不能に陥りやすい状況であったことを示しています。
まとめ：OS が新しくなっても治らなかった理由
OS 自体が新しくなっても、足元にある「ファイルシステム」が骨折したままだったため、ブラウザ（Orion や Brave）がキャッシュを読み書きした程度のわずかな負荷でさえ再びシステム全体がダウンする状態に陥っていたのです。
4. 最終的な解決策（負の連鎖を断ち切るステップ）
この問題を解決するには、単に原因プロセスを止めるだけでなく、傷ついたシステムを底辺から治療する必要がありました。
Step 1：リカバリモードからの「ディスクの修復」【最重要】
通常起動やセーフモードすらままならない状態だったため、OS の外側からファイルシステムを修復します。
- Mac の電源を完全に切ります。
- 電源ボタンを押し続け、「起動オプションを読み込み中」で離します。
- 「オプション」から macOS 復旧 に入り、「ディスクユーティリティ」を起動します。
- メインドライブ（Macintosh HD - Data）を選択し、「First Aid」 を実行して APFS のエラーを完全に修復します。
Step 2：「あなたと共有」の無効化と写真ライブラリの修復
macOS 側の I/O 暴走の根源を絶ちます。
- 「メッセージ」アプリの設定から「あなたと共有」機能をオフにします。
- システム設定の iCloud > 写真 の「このMacを同期」を一時的にオフにします。
-
Option + Commandを押しながら「写真」アプリを起動し、「ライブラリを修復」 を実行します。
5. 今後の展望：安定稼働に向けた追加の対策
上記の手順で致命的なパニックは防げましたが、今後も開発作業などでシステムに高負荷をかける場合、以下の設定を検討することで更なる安定化が図れるでしょう。
なお、以降の対策は AI（LLM）の提案をもとにした、今後の安定化のための展望です。
開発エディタ等の OS レベルでのファイル監視（Watcher）の除外
Windsurf（VS Code ベースの AI エディタ）などの強力な File Watcher が、巨大なデータセットや node_modules を常時スキャンすると、macOS のファイルシステム（FSEvents）に多大な I/O 負荷がかかりクラッシュの引き金となる可能性があります。
ここで注意すべきは、.windsurfignore や .gitignore を設定するだけでは不十分だということです。これらはあくまで「AI の文脈読み込み」や「Git トラッキング」から除外するだけであり、エディタの OS レベルでのファイル監視機能自体は止まらないからです。
真に I/O 負荷を下げるには、エディタの設定（settings.json）を開き、files.watcherExclude を指定して OS レベルでの監視を完全に遮断する必要があります。
{
"files.watcherExclude": {
"**/.git/objects/**": true,
"**/node_modules/**": true,
"**/巨大なデータセットのフォルダ名/**": true
}
}
まとめ
「Mac の画面がフリーズして紫になる」という症状は、一見するとGPUやメモリのハードウェア故障を疑いたくなるでしょう。
しかし今回のケースは、 「photolibraryd の同期異常が数十GBの書き込みを行い I/O を枯渇させた結果、画面がフリーズして強制終了を余儀なくされ、さらにその繰り返しがファイルシステムを破損させた」 というソフトウェア起因の複合的な障害でした。
OS のアップデートは魔法の杖ではありません。今回は「同期プロセスの停止」と「リカバリモードでの First Aid（ディスクの修復）」によって状況は概ね改善したと見ています。
本記事は ChatGPT, Gemini, Claude の支援のもと分析し記事にしたものです。