ブログに戻る
macOS tutorial system tools

Macでmds_storesのCPU使用率が高い：待つべきときと対処すべきとき

mds_storesがCPUとディスクを食い続けている？これはSpotlightのボリュームごとのインデクサーです。多くの急上昇は自然に終わる正当な処理 — 正常なインデックス作成と、固まったプロセスの見分け方、そして本当に効く対処法を解説します。

Macがもたつくと感じてActivity Monitorを開くと — ファンがうるさく、ディスクのアクセスランプが点きっぱなしで — CPUカラムの先頭にいるプロセスがmds_storesで、100%、200%、あるいはそれ以上を示していることがあります。終了させるのは気が引けるし、放っておくのも時間の無駄に感じます。挙動のおかしいアプリとは違って、これは正当な処理かもしれませんし、固まってしまっているのかもしれません。本ガイドでは、その見分け方をはっきりと示し、実際に効く対処法を順に解説します。

結論から言うと

mds_storesは、macOSの検索インデックスであるSpotlightの「ボリュームごとに動くワーカー」プロセスです。CPU使用率が高くなるのは、たいていの場合「実際に作業が進行中」という意味です。インストールやアップグレード後の初回インデックス、新しく接続した外付けドライブ、クラウド同期によるファイルの動き、何千もの小さなファイルを生み出す開発ワークフローなどです。次の3つの兆候は、それが「働いている」のではなく「固まっている」サインです。

  1. 同じボリュームで24時間以上動き続けていて、進捗が見えない。
  2. 最近のトリガー — クラウド同期、大規模なファイルコピー、新しく接続したドライブ — が何もないのに、CPUとディスクが何時間も高止まりしている。
  3. 同じファイルを繰り返しスキャンしている。

ProcXrayのOpen Files（開いているファイル）パネルは、mds_storesが今まさに読んでいるファイルパスをそのまま見せてくれます — トリガーを特定する最速の手段です。Activity Monitorのプロセス・インスペクタにも開いているファイルの一覧はありますが、検索も履歴もない静的なダイアログにとどまり、何千ものインデックスパスをリアルタイムにふるい分けるには向きません。ProcXrayのパネルなら数秒で診断が片付くことも珍しくありません。

mds_storesとは？

mds_storesは、macOSのSpotlightを構成する3つのプロセスのうちの1つです。

Activity Monitorにmds_storesプロセスが複数表示されていても、それは正常な状態です — 単に複数のボリュームがインデックス対象になっているということです。インデックスが完成して落ち着いた状態のアイドルなMacでは、mds_storesのCPU使用率は概ね0〜5%です。ボリュームごとに分かれているおかげで、外付けドライブのmds_storesが起動ボリュームのワーカーに影響を与えずに単独で急上昇することもあります。

パーセンテージについての注意：Activity Monitorで100%は1つの完全なCPUコア相当を意味します。マルチコアのMacでは、1つのプロセスが100%を大きく超えて報告されることがあります。したがってmds_storesが250%というのは、約2.5コア分を占めているという意味です。

視点の切り替え：作業中 vs 固まっている

ここが本ガイドで最も重要な視点の切り替えです。WindowServerは常に上流のアプリに引っ張られている下流のプロセスですが、mds_storesがCPUを使っているときは、インデクサーが実際に正しく作業していることが大半です。そして正しい作業には終わりがあります。だから診断時に問うべきは「mds_storesが壊れているのか？」ではなく、

これは終わる一時的なインデックス処理なのか、それとも固まっているのか？

簡単な判別基準：

このルーブリックがこの記事の残りの構成を支えています：トリガーを特定 → 終わる兆しがあるかを確認 → 適切な対処を適用、です。

mds_storesを急上昇させる原因

頻度順に6つ挙げます。

1. 新規インストールまたはmacOSのアップグレード

ボリュームを初めてインデックスするとき、Spotlightはすべてのファイルからメタデータを抽出する必要があります。セットアップしたばかりのMacでは、ホームディレクトリのサイズや写真・ドキュメントの数によって、30分から数時間かかります。メジャーアップグレードでも、部分的な再インデックスがトリガーされることがあります。

2. 新しい外付けドライブ、または大規模なファイルコピー

新しいファイルそれぞれからメタデータを抽出する必要があります。雑多な内容で満たされた1 TBの外付けドライブをマウントすると、mds_storesが1時間から数時間忙しくなります。起動ボリュームへの大規模コピー — たとえばバックアップからフォルダを復元する — も同じ効果です。

3. クラウド同期によるファイルの動き

「mds_storesが止まらない」の最も多い単一の原因です。iCloud Drive、Dropbox、OneDrive、Google Drive、Boxはいずれもバックグラウンドでファイルを作成・変更・削除します。それらの変更すべてがSpotlightにとっての追跡対象イベントになります。特に悪名高い2パターン：iCloudのMacストレージを最適化（ファイルを退避して再ダウンロードする）と、OneDriveのファイル オンデマンド（同じ発想）。退避と再ダウンロードのサイクルごとに、対象ファイルが再インデックスされます。

4. 何千もの小さなファイルを生む開発ワークフロー

npm install / yarn install（あの悪名高いnode_modules）、Xcodeのビルドが~/Library/Developer/Xcode/DerivedDataに書き込む処理、大きなブランチのgit checkout、Dockerイメージの展開、Homebrewのアップデートなど、いずれも大量のファイルシステムイベントを一気に発生させます。Spotlightはそれらすべてをインデックスしようとします。

5. Time Machineの初回バックアップ、または大規模スナップショット

Time MachineはSpotlightが監視しているのと同じファイルシステムイベントストリームを使います。初回バックアップや大規模スナップショット操作では、mds_storesと相互作用して両方が同時に高くなることがあります。

6. インデックスの破損による再構築

強制シャットダウン、カーネルパニック、APFSボリュームの問題、ディスク修復の失敗の後、Spotlightインデックスが不整合な状態に陥ることがあります。するとmds_storesはゼロから再構築します — 見た目は初回インデックスとそっくりですが、何の前触れもなく始まります。

特定の犯人として名指ししておく価値があるアプリ：Adobe Creative Cloudの同期、Backblaze、Carbon Copy Cloner、そしてオンアクセススキャンを行うウイルス対策ソフト。これらが動いているなら、まずそれを疑ってください。

自然に収まるかどうかをどう判断するか

Activity Monitorは自然な出発点ですが、開いているファイルの一覧は検索も履歴もない静的なダイアログで提供されます — そして、この問題で最も解決の決め手になるのは、まさに**mds_storesが今読んでいるファイルパスと、その変化**を追えることです。

ステップ1：インデックスが有効になっているか確認する

ターミナルで次を実行：

mdutil -s /

出力は次のいずれかです：

各ボリュームについて繰り返してください（mdutil -s /Volumes/External）。

重要：mdutil -sが示すのはあくまで「そのボリュームでSpotlightインデックスが有効かどうか」だけで、進捗は報告しません。「まだ前に進んでいるか？」を判断するには、ステップ2のディスク読み込み傾向、ステップ3のOpen Filesに表示されるファイルパスが時間とともに変わっているか、そしてSpotlightの検索ウィンドウを開いたときに「インデックス作成中…」のステータスバーがまだ表示されるかどうかを合わせて見る必要があります。

ステップ2：Activity Monitorでの当たり

CPUタブ → CPUで並べ替えてmds_storesがトップにいることを確認。ディスクタブに切り替えて読み込んだバイトで並べ替えます。mds_storesがディスク読み込みを独占しているなら、能動的にファイルをスキャンしている（つまりインデックスを作っている）状態です。5分ほど見守りましょう — CPUは下降、横ばい、それとも上昇？

ステップ3：ProcXrayで「何をインデックスしているか」を特定

ProcXrayはこの種のクロスリソース診断のために作られています：

この種のデバッグでActivity Monitorに欠けている部分の全体像については、ProcXray vs Activity Monitorを参照してください。

ステップ4：疑わしいトリガーを取り除くA/Bテスト

仮説が立ったら、外付けドライブを一つずつ取り外し、クラウド同期アプリを一つずつ一時停止し、ビルドツールを終了させます。1つ変えるごとにmds_storesを1分ほど観察します。明らかな下降があれば、再起動もセッションの中断もなしに原因が確定します。

段階的な対処

順番に試してください — 安価で副作用の少ないものから。

1. 初回観察時は30分〜2時間待つ

最も見落とされがちな対処法。たいていのインデックスはこの時間内に終わります。Macを電源につないで放っておきましょう。戻ってきたらインデックスが完了している、というのが正解であることがほとんどです。

2. 元凶のフォルダをSpotlightのプライバシーに追加

システム設定 → Spotlight → プライバシー → 該当のフォルダをドラッグします。Spotlightはそのフォルダのインデックスを止めます。除外する価値が高いフォルダ：

代償：それらのファイルはSpotlight検索に出てこなくなります。ビルド成果物やnode_modulesに関しては、ほぼ確実に正しい選択です。

3. 一時的にクラウド同期を停止

Open FilesパネルでiCloud、Dropbox、OneDrive、Google Driveのフォルダをmds_storesが読んでいたら、そのアプリを一時停止します。mds_storesが数分で落ち着けば原因の確定です。長期対策としては、そのインデックスコストを受け入れるか、プライバシー設定でクラウドフォルダをSpotlightから除外するかです。iCloudの「Macストレージを最適化」が有効でディスク容量に余裕があるなら、これを無効にすることを検討してください — 退避と再ダウンロードのサイクルがループの最大の原因であることが多いです。

4. 特定のボリュームでインデックスを無効化

Spotlightで検索しない外付けドライブ（作業用ドライブ、メディアアーカイブなど）について。Time Machineのバックアップディスクではインデックスを無効化しないでください — Time MachineはそのボリュームのSpotlightインデックスに依存して動作します。

sudo mdutil -i off /Volumes/External

後で再有効化するにはsudo mdutil -i on /Volumes/External。

5. インデックスが壊れているときは強制的にクリーンな再構築

mdutil -sが「unknown indexing state」を報告した場合、あるいはすべてのトリガーを除外してもmds_storesが回り続ける場合、インデックスを消去して再構築します：

sudo mdutil -E /

再構築の間、30分〜数時間の高CPUとディスク活動が予想されます — それは再構築そのものであり、問題ではありません。破損を確認した後で使い、最初の反射として使わないでください。

6. 最後の手段：mds_storesを直接終了させる

macOSが数秒以内にきれいに再起動します。これでトリガーが直るわけではありませんが、暴走ループを中断して調査の時間を確保することはできます。Activity Monitorの「強制終了」、または：

sudo killall mds_stores

推奨しない：sudo mdutil -a -i offでSpotlightを永久に無効化すること。Spotlight検索、メール検索、そして基盤となるメタデータAPIに依存するすべてのアプリを失います。これが正しい修正であることはほぼありません — プライバシー設定でうるさいフォルダを除外する方を選んでください。

mds_storesだけが容疑者ではないより広範な性能トリアージについては、適切なプロセスを終了させてMacの動作の重さを直す方法を参照してください。

よくある質問

mds_storesを終了させても安全ですか？

はい。macOSが数秒以内に自動的に再起動します。終了させればその時点での処理は中断されますが、インデックスやデータが壊れることはありません。注意点：終了させた後に同じワークロードがすぐに再度高CPUへ引き戻すなら、何も直していません — 原因が継続的なものであり、上のリストから本物の修正が必要だと確認したに過ぎません。

通常のインデックスはどれくらい時間がかかりますか？

セットアップしたばかりのMacでの初回インデックス：通常30分〜2時間、非常に大きなホームディレクトリでは4〜6時間。新しくマウントした1 TBの外付けドライブ：おおむねファイル数に比例して1〜4時間。クラウド同期のバースト後のインデックス：数分。安定したファイル状態で24時間以上続くのは異常で、固まっているか暴走する変化源があるかのどちらかです。

なぜ同じファイルを何度もインデックスし続けるのですか？

ほとんどの場合、クラウド同期アプリかバックアップツールが同じファイルを繰り返し触っているからです。iCloud DriveのMacストレージを最適化はよくある犯人です — ファイルを退避して再ダウンロードし、そのサイクルごとに対象ファイルが再インデックスされます。「システム設定 → [あなたの名前] → iCloud → iCloud Drive → Macストレージを最適化」を確認してください。ディスク容量に余裕があれば、これを無効にすることで多くの場合ループが解消されます。

Spotlightを永久に無効化するべきですか？

いいえ — 非常に具体的な理由があり、Spotlight、メール、システム検索を一切使わない場合を除いて。多くのアプリが基盤のメタデータAPIに依存しているため、Spotlightを無効化すると虫眼鏡のアイコン以上のものが壊れます。プライバシー設定でうるさいフォルダを除外することで、ほとんどコストゼロに近いまま大半のメリットが得られます。

mds_storesがディスクを使っているのにCPUはほとんど使っていないのはなぜですか？

インデックスは大半がI/Oバウンドです。mds_storesの時間の大半は、ディスクからファイル内容を読み込むことに費やされ、メタデータを解析するための短いCPUバーストが挟まる形になります。高ディスク + 低CPUは通常のインデックスの特徴です。CPUも高いなら、インデクサーが大量の小さなファイルを処理している — node_modules、メールボックス、gitオブジェクトでよく見られるパターン — ということです。

参考資料

ProcXrayを無料でダウンロード → — mds_storesが今どのファイルをインデックスしているのかを直接確認できます。macOS Sonoma+、Apple Silicon・Intel対応。