macOS「Application Not Responding — Force Quit?」（虹色ビーチボール）の修正方法

TL;DR

回転するビーチボール（SPOD）が表示され、macOSが**「アプリケーションが応答しません — 強制終了しますか？」**とポップアップを出している。今すぐアプリを復旧させたい場合は、アクティビティモニタを開いてCPUまたはメモリでソートし、問題のあるプロセスを終了してから再起動する。以下のセクションでは、発生原因と再発を防ぐ方法を詳しく説明する。

# ターミナルから強制終了（Dock自体がフリーズしている場合に最速）
kill -9 $(pgrep -x "AppName")

# または killall を使用
killall -9 "Slack"

ビーチボールが表示される本当の原因

回転するビーチボール（SPOD — Spinning Pinwheel of Death）は、アプリのメインスレッドが約4〜5秒間応答しなくなったときに表示される。macOSがその無応答を検知し、**「アプリケーションが応答しません — 強制終了しますか？」**ダイアログを表示する。

主な原因：

• プロセスがCPUを100%占有している — バックグラウンドのヘルパー、プラグイン、またはアプリ自体が無限ループに陥っている
• メモリ不足 — RAMが枯渇し、macOSが激しくスワップしており、メインスレッドがページフォルトの解決を待ってブロックされている
• ディスクI/Oのボトルネック — 低速なHDD、故障しかけたSSD、またはアプリがまだアクセスしようとしている切断済みのSMB/NFSマウント
• アプリ内のデッドロック — 2つのスレッドが互いを待ち続け、処理が一切進まない状態
• 設定ファイルまたはキャッシュの破損 — 起動時に壊れたplistを解析しようとして、アプリが停止する

手順1 — まず本当の原因を特定する

単に強制終了して済ませてはいけない。なぜ起きたかを突き止めないと、また同じことが繰り返される。

# 現時点でCPUを最も消費しているプロセスを確認
top -o cpu -n 20 -l 1 | head -30

# メモリプレッシャーを確認
vm_stat | grep -E "Pages (free|active|inactive|speculative|wired|occupied)"

# ディスクI/Oを確認（sudoが必要）
sudo fs_usage -w -f filesys 2>&1 | grep -i "your_app_name"

アクティビティモニタ（アプリケーション → ユーティリティ → アクティビティモニタ）は、素早く視覚的に確認したい場合に便利：

• 「CPU」タブ → %CPU降順でソート — 90%を超えているものがあれば要注意
• 「メモリ」タブ → 下部の「メモリプレッシャー」グラフを確認（赤色は危険な状態）
• 「ディスク」タブ → 「読み込まれたバイト数」が数百MB単位で急増しているものがないか確認

手順2 — 正しく強制終了する

方法A：強制終了ダイアログ（CMD+OPT+ESC）

⌘ + ⌥ + Escを押し、*（応答なし）*と表示されているアプリを選択して「強制終了」をクリックする。ほとんどの状況で有効だが、未保存の作業は失われることに注意。

方法B：ターミナルでkill（UIが完全にフリーズしている場合）

# PIDを取得
pgrep -lx "Slack"

# まずSIGTERMで穏やかに終了を試みる
kill $(pgrep -x "Slack")

# 5秒後もまだ生きていれば強制終了
sleep 5 && kill -9 $(pgrep -x "Slack") 2>/dev/null

方法C：アクティビティモニタからkill

プロセスを選択 → ツールバーのXボタンをクリック → 「強制終了」。方法Aと同じ結果だが、操作経路が異なる。

手順3 — 根本原因を修正する

ケース：メモリプレッシャーが高い / スワップが発生している

# スワップの使用量を確認
sysctl vm.swapusage

# 実行中のアプリに影響を与えずに非アクティブページを解放
sudo purge

スワップ使用量が常時2GBを超えている場合は危険信号。バックグラウンドのアプリを閉じるか、RAMの増設を検討する。特定のアプリのメモリリークを確認するには：

leaks --atExit -- /Applications/AppName.app/Contents/MacOS/AppName

ケース：設定ファイルの破損

壊れた.plistファイルがあると、起動後数秒でアプリが毎回フリーズする。バックアップを取ってから削除し、アプリに設定ファイルを再生成させる。

# アプリの設定ファイルをバックアップして削除
cd ~/Library/Preferences
mv com.company.AppName.plist com.company.AppName.plist.bak

# macOSが古いバージョンをキャッシュから提供しないよう設定キャッシュをクリア
killall cfprefsd

アプリを再起動する。正常に動作すれば、古いplistが原因だったということなので、.bakファイルを削除する。

ケース：アプリキャッシュの破損

# アプリ固有のキャッシュを削除
rm -rf ~/Library/Caches/com.company.AppName

# Electronアプリ（VSCode、Slack、Notion）はこちらにもキャッシュがある：
rm -rf ~/Library/Application\ Support/AppName/Cache
rm -rf ~/Library/Application\ Support/AppName/Code\ Cache

ケース：ネットワークマウントの切断によるディスクI/Oブロック

SMB共有やNFSマウントからファイルを読み込むアプリは、そのマウントが到達不能になった瞬間に無限に待ち続けてハングする。メインスレッドは、返ってこないファイルシステムの応答をひたすら待ち続ける。

# マウントされているネットワークボリュームを一覧表示
mount | grep -E "smb|nfs|afp"

# 切断されたマウントを強制アンマウント
diskutil unmount force /Volumes/MyShare
# または
sudo umount -f /Volumes/MyShare

ケース：ヘルパープロセスの暴走（Electronアプリで非常に多い）

# アプリから起動されたすべての子プロセスを確認
pstree -p $(pgrep -x "Slack") 2>/dev/null || pgrep -P $(pgrep -x "Slack")

# メインアプリではなくヘルパープロセスをkill
kill -9 

ケース：SpotlightがアプリのデータフォルダをインデックスしているCase

Spotlightのmds/mdworkerプロセスは、アプリのデータディレクトリを再インデックスしようとしたとき（多くはアップデート直後）に、大量のディスクI/Oを引き起こすことがある。

# mds がCPUを食い潰していないか確認
top -o cpu | grep mds

# 一時的にインデックスを停止
sudo mdutil -a -i off
# 数分後に再度有効化
sudo mdutil -a -i on

永続的に除外するには：システム設定 → SiriとSpotlight → Spotlightのプライバシー → フォルダをドラッグして追加する。

手順4 — 強制終了前に診断情報を取得する

繰り返しフリーズが発生する場合は、きちんと調査する価値がある。強制終了前にspindumpを取得しておくこと。フリーズした瞬間のすべてのスレッドの完全なスタックトレースが記録され、有用なバグレポートを作成するのに役立つ。

# フリーズしたアプリのspindumpを取得（/tmp/ に保存）
sudo spindump AppName -o /tmp/AppName_spindump.txt

# またはプロセスを10秒間サンプリング
sample $(pgrep -x "AppName") 10 -file /tmp/AppName_sample.txt

ファイルを開いて、繰り返し現れるスタックフレームを探す。その繰り返しがデッドロックまたはホットループの証拠だ。

確認

修正を適用したら、問題が解決したと判断する前に60秒間アプリを観察する：

# CPUとメモリをリアルタイムで追跡
top -o cpu -s 2 -l 30 | grep -i "appname"

# メモリプレッシャーを監視（5秒ごとに更新）
vm_stat 5

アクティビティモニタのメモリプレッシャーグラフは緑色を維持しているべきだ。黄色は警告サイン。赤色はアプリを閉じるかRAMを増設しない限りフリーズが続くことを意味し、その状態ではどんな修正も効果を発揮しない。

何も効果がない場合 — 最終手段

macOS全体のUIがフリーズしている？マウスは動くのに何も反応しない？別のマシンからSSHでアクセスしてセッションを再起動する：

# ウィンドウサーバーをkill — 即座にセッションが終了する
ssh user@your-mac
sudo killall -KILL loginwindow

ログアウトされ、セッションがクリーンに再起動する。未保存の作業は失われるが、強制電源断よりはるかに速く、ファイルシステムの破損も防げる。

再発を防ぐために

• ディスク空き容量を少なくとも10〜15%確保する — macOSはSSDを仮想メモリのスワップ領域として使用するため、ディスクがほぼ満杯だとスワップが遅くなり、ビーチボールの原因になる
• 時々sudo periodic daily weekly monthlyを実行して、蓄積したシステムキャッシュをクリアする
• アプリを最新の状態に保つ — 多くのANRバグは最新バージョンで修正済みだが、アップデートしないユーザーのほとんどはそれに気づかない
• Electronアプリ（VSCode、Slack、Notion）については、現在使用しているバージョンのリリースノートを確認する。Electronのメモリリークは一般的で、通常1〜2リリース以内にパッチが適用される
• バッテリー駆動時だけビーチボールが出る場合は、システム設定 → バッテリー → 省電力モードがCPUを大幅に制限している可能性がある。重い作業中はオフにすること。