macOS 26.6 にしたら Mac が熱くバッテリーも激減？その理由を解説

macOS 26.6 をインストールして再起動したところ、1 時間もしないうちに Mac がここ数か月で一番熱くなっていた。メールを読んでいるだけなのにファンの音が聞こえる。バッテリーの残量は、新品だった頃以来見たことのない速さで減っていく。開いているアプリを見ても理由がわからず、何を終了させても直らない。

ほぼ間違いなく、あなたの Mac は Spotlight のインデックスを再構築しています。Apple 自身の macOS 26.6 リリースノートには、このアップデートが「macOS 27 のリリースに向けて Spotlight を最適化する」と書かれています。これは Apple 自身の表現であり、この記事全体の中で最も重要な一文です。Spotlight を最適化するということは、インデックスに手を入れるということです。インデックスに手を入れるということは、ファイルシステムを走査し、検索可能なテキストを抽出するために書類を開き直し、Photos ライブラリを再解析し、その結果をすべてディスクに書き戻すということです。この作業は CPU とディスクを占有し、あなたが頼んだかどうかに関係なくバックグラウンドで実行され、まさに今あなたが見ている症状、つまり発熱、ファンの騒音、そして実際の作業内容とはまったく釣り合わないバッテリーの減りを引き起こします。

厄介なのは、macOS がこの処理についてほとんど何も見せてくれないことです。進捗バーもなければ通知もなく、System Settings のどこにも「インデックス作成 43% 完了」といった表示はありません。そのため、まったく正常で自然に終わるバックグラウンド処理が、故障した Mac とまったく見分けがつかなくなります。このガイドはその差を埋めるものです。26.6 で何が変わったのか、そして何が Apple 公式で何が報道による解釈なのかを整理し、インデックス作成がなぜこれほどコストの高い処理なのかを分解し、あなたの Mac でそれが起きているかをプロセス名で確認する手順を案内し、どれくらい時間がかかるのか・何が長引かせるのかを示し、そして重要な点として、これが通常のインデックス作成ではないことを示す具体的で正直なサインのリスト、つまり待つのをやめてトラブルシューティングを始めるべきタイミングをお伝えします。さらに、正しい方法でクリーンな再構築を強制する手順と、それを早すぎるタイミングで行うと問題が改善するどころか悪化する理由についても解説します。

重要なポイント

• Apple は原因を間接的に認めています。 macOS 26.6 のリリースノートには、このアップデートが macOS 27 のリリースに向けて Spotlight を最適化すると記載されています。Spotlight を再最適化するということは再インデックスすることであり、再インデックスはコストの高い処理です。26.6 のインストール直後の数日間に起きる発熱とバッテリー消費は、不具合ではなく予測できる副作用です。
• 探すべきプロセスは mds、mds_stores、mdworker_shared です。 これらが Activity Monitor の CPU タブの上位に並んでいれば、答えは出ています。Apple Intelligence 対応の Mac では、コミュニティの報告により photoanalysisd、siriinferenced、intelligenceplatformd も挙げられていますが、これらの具体的な名前は Apple による公式文書ではなく報告レベルの情報として扱ってください。
• 介入する前に、実稼働時間で 24〜48 時間は様子を見てください。 コミュニティの報告では CPU 負荷の高い期間はこの範囲に収まり、数日以内に落ち着くとされています。この時計は Mac が起動して電源が入っている間しか進まないため、毎晩スリープするノートブックでは 2 日分の作業が 1 週間に引き延ばされます。
• まだインデックスを再構築しないでください。 sudo mdutil -E / と、Spotlight のプライバシー設定に追加してから削除する裏技は、どちらも同じことをします。完了済みの作業をすべて捨てて、ゼロからやり直すのです。どちらかを早期に実行すれば、熱は減るどころか増えることが確実です。
• 「遅い」と「止まっている」の違いを知ってください。 正常なインデックス作成は徐々に収まり、アイドル時間に反応します。本当に止まっているインデックスは、何日経っても同じ CPU 使用率に張り付いたまま下がらず、mdutil がエラーを返し、あるいは 1 週間経っても Spotlight がまったく何も返さない状態になります。これは実際に起こりうるケースであり、きちんとした対処が必要です。

macOS 26.6 が Spotlight に実際に加えた変更

Apple が書いた一文

macOS Tahoe 26.6（ビルド 25G72）は 2026 年 7 月 27 日に公開されました。通常のセキュリティ内容に加えて、Apple のアップデートノートには、このアップデートが macOS 27 のリリースに向けて Spotlight を最適化するという一行が含まれています。

短い一文ですが、非常に大きな意味を持ちます。Apple は通常、あるポイントリリースがデータベースの書き換えに 2 日分のバッテリーを費やすことを事前に教えてはくれません。しかし文字どおりに読めば、「macOS 27 のリリースに向けて Spotlight を最適化する」とは、次のバージョンの macOS が到着したときに準備が整っているよう、現行バージョンの macOS が今のうちに下準備をしている、という意味です。検索システムに対してできる意味のある下準備といえば、インデックスそのもの、つまりその形式か中身、あるいはその両方に対する作業しかありません。

これは Apple が過去にも使ってきたパターンです。アップグレード当日、つまり不満が最も高まりやすく、しかもマシンが設定の移行や iCloud コンテンツの再ダウンロードで既に忙しいタイミングで、全員に数日がかりの再インデックスを強いる代わりに、ポイントリリースがその作業の一部を静かに前倒しで済ませておくのです。コストは、あなたが注意深く見ている瞬間から、見ていない瞬間へと移されます。これはエンジニアリング上妥当なトレードオフですが、同時に今これほど多くの人が混乱している理由そのものでもあります。ありふれた .6 アップデートがノートブックを 2 日間温め続けるとは、誰も予想しないからです。

報道が上乗せした内容

9to5Mac や TechTimes をはじめとする各媒体の報道はさらに一歩踏み込み、このインデックス作業は macOS 27 の新しい Siri と Apple Intelligence 機能が利用するオンデバイスインデックスを構築しているものだと伝えています。この推論には説得力があります。macOS 27「Golden Gate」は Spotlight と Siri をはるかに密接に結び付けるものであり、自分のファイルについての質問に答えられる対話型アシスタントが即座に応答するには、それらのファイルに関する豊かで事前構築された理解が必要だからです。

ただし出典ははっきりさせておきましょう。この関連付けは報道による解釈であり、Apple の声明ではありません。 Apple が言ったのは「Spotlight を最適化する」です。Apple は「Siri のためのセマンティックインデックスを構築する」とは言っていません。Siri に絡めた見方は、macOS 27 に関する公開情報からのよく練られた推論であり、実際に正しい可能性も十分にありますが、リリースノートそのものよりは緩めに受け止めるべきです。本記事ではこの点が出てくるたびに注記しますし、そうしない情報源には懐疑的であるべきです。

macOS 27 自身のスケジュールについて補足すると、現在はパブリックベータ中で（パブリックベータ 1 が 7 月 13 日、パブリックベータ 2 が 7 月 22 日、開発者向けベータ 4 が 7 月 20 日に登場）、秋の提供開始が見込まれています。対応は Apple silicon のみ、M1 以降です。Intel Mac をお使いの場合、macOS 26.6 はあなたのマシンでも Spotlight の作業を行いますが、「macOS 27 の Siri に備えている」という位置付けは当てはまりません。macOS 27 はそもそもあなたの Mac では動作しないからです。

変わらなかったこと

切り分けのために、macOS 26.6 が行わなかったことをはっきり述べておく価値があります。ファイルを消去したり、設定をリセットしたり、アプリの動作を変えたりはしていません。データは無事です。インデックスの書き換え中は Spotlight の検索結果が不完全だったり、順序がおかしかったりすることがありますが、それは一時的なものです。Mac は熱いのに、それ以外はすべて正常に動作しているなら、それは壊れたインストールではなくインデックス作成処理の典型的な姿です。

macOS 26.6 で変わったすべての点、つまりセキュリティ修正や細かな挙動の変更まで含めた全体像を知りたい場合は、その関連記事がリリース内容を網羅しています。本記事は発熱とバッテリーの問題に絞って解説します。

インデックス作成のコストが高い理由

検索インデックスとは実際に何なのかを考えたことがなければ、この CPU コストは理不尽に感じられるかもしれません。何も検索していない。Mac はアイドル状態だ。なぜこんなに働いているのか、と。

それは、インデックスの構築が軽い記録作業ではないからです。これは 4 つの別々に重い処理が積み重なったものであり、macOS はそれらをほぼ同時に走らせます。

処理 1：ファイルシステムの走査

インデクサが最初にしなければならないのは、何が存在するかを調べることです。つまり、インデックス対象のすべてのボリューム上のすべてのファイルを列挙します。書類フォルダだけではありません。アプリケーションバンドル、キャッシュ、フレームワークのリソース、ダウンロード、開発者なら Xcode のシミュレータ、仮想マシンのディスクイメージ、node_modules ディレクトリ、そしてこれまで蓄積されてきたその他すべてが対象です。実際に使われている Mac には、数十万から数百万のファイルが当たり前に存在します。

そのひとつひとつについて、macOS はファイルの stat を取得しなければなりません。名前、サイズ、タイムスタンプ、種類、拡張属性を読み取ります。個々の操作はごく些細なものです。しかし 100 万ファイル分を掛け合わせると、小さなランダム読み込みが延々と続く嵐になり、これはストレージデバイスに頼める処理の中でも最も効率の悪いものの 1 つです。高速な内蔵 SSD ならまだ許容範囲です。外付けのハードディスクではきわめて過酷です。

処理 2：ファイルの中身からのメタデータ抽出

ファイルが存在することがわかるだけでは、Spotlight は役に立ちません。書類の中身を検索したいはずです。クライアント名が書かれた PDF を見つけたい、特定の語句が入った Pages ファイルを探したい、うろ覚えの添付ファイルが付いたメールを見つけたい、といった具合です。

そのためには macOS がファイルを開いて解析しなければなりません。これが Spotlight インポータの仕事です。PDF、Word 書類、Keynote のデッキ、ソースコードファイル、テキストが埋め込まれた画像などをフォーマットごとのプラグインが開き、検索可能な内容を取り出します。この解析は本当に CPU を消費する作業です。スキャンページを含む大きな PDF、200 MB の Keynote プレゼンテーション、10 年分のメールアーカイブは、いずれも読み取りとトークン化に実際のプロセッササイクルを要します。

ここで登場するのが mdworker と mdworker_shared です。macOS はキューを処理するために複数のワーカープロセスを並列に起動します。だからこそ Activity Monitor でそれらが同時にいくつも見えることがあり、また、単独では大したことがないように見えても合計の CPU 負荷が高くなるのです。

処理 3：Photos ライブラリの解析

Photos は photoanalysisd が担当する独自の解析パスを実行します。これはファイル単位のインデックス作成とは別物で、1 項目あたりのコストはかなり高くなります。テキストを読んでいるのではなく、顔認識、シーンや被写体の検出、そして「写真に写っているもので検索する」機能を支えるために、画像の内容に対してオンデバイスの機械学習を実行しているからです。

数万枚の画像を含む Photos ライブラリは、非常に大量の推論作業を意味します。大きなライブラリを持っていて、Mac の熱設計に余裕がない場合、photoanalysisd だけで感じている熱の大半を占めることもあります。また、この処理は数日にわたって長引く可能性が最も高いものでもあります。Photos が意図的に処理を抑制し、Mac がアイドル状態で電源に接続されているときに実行することを好むからです。

処理 4：対応 Mac におけるオンデバイスのセマンティック層

Apple Intelligence 対応の Mac では、コミュニティの報告や Activity Monitor での観察により、この期間に追加で 2 つのプロセスが現れると指摘されています。siriinferenced と intelligenceplatformd です。報告されている役割は、単なるキーワード一致ではなく、自分のコンテンツについての自然言語の質問にシステムが答えられるようにするための、オンデバイスのセマンティックな理解を構築することです。

これはこの全体像の中で最も文書化されていない部分なので、緩めに受け止めてください。 Apple は、これらのデーモンが 26.6 のアップデート後のパスで何をしているのかについての内訳を公開していません。観察できるのは、この期間にそれらが CPU を消費している様子が報告されていることと、その存在が macOS 27 の Siri に関する報道の解釈と一致していることだけです。もし見えたなら、その筋書きと矛盾しません。見えなかったとしても、何かがおかしいという意味ではありません。そのワークロード自体をまったく実行しない Mac も多数あるからです。

これら 4 つの処理を合わせると、複数のコアで長時間にわたり高い CPU 負荷が続くマシンができあがります。継続的な CPU 負荷は熱を意味します。熱はファンを意味します。そしてノートブックでは、そのすべてがバッテリーから支払われます。ここに故障はひとつもありません。ただ、あなたがスケジュールしたわけでもなく、目にも見えない重い処理が走っているだけです。

自分の Mac で本当にこれが起きているかを確認する方法

ここまでは一般論です。次は、それがあなたのマシンに当てはまるかを確かめましょう。「たぶんインデックス作成だろう」は診断ではありません。確認するまでは推測にすぎないのです。手間の少ない順に 4 つのチェックを行います。

チェック 1：Activity Monitor の CPU タブをプロセス名で見る

Activity Monitor を開きます（アプリケーション → ユーティリティ、または Command-Space を押して名前を入力。Spotlight が正常に動いていればの話ですが）。CPU タブをクリックし、% CPU の列見出しをクリックして降順に並べ替え、最も忙しいプロセスが上に来るようにします。

そして名前を読んでください。探すのは次のプロセスです。

• mds — メタデータサーバ。全体の調整役です。通常それ自体は CPU をあまり使わず、作業を管理して振り分けます。
• mds_stores — インデックスストアへの書き込みを行うプロセス。Spotlight 関連プロセスの中では通常最も重く、インデックス作成が実際に走っていることを示す最も明確な単独の指標です。
• mdworker / mdworker_shared — 上で説明したファイル単位の解析を行うインポータのワーカー。同時に複数動いているのは正常です。
• photoanalysisd — Photos ライブラリの解析。存在していれば Photos のパスが走っているということです。
• siriinferenced / intelligenceplatformd — Apple Intelligence 対応の Mac で、このワークロードの一部として報告されているもの。繰り返しますが、報告レベルであり公式文書ではありません。

これらのうち 2 つ以上が CPU リストの上位にいれば、診断は確定です。アップデート後のインデックス作成を内側から見ると、そう見えます。

一方、ブラウザ、チャットアプリ、バックアップツール、あるいは見覚えのある特定のアプリケーションが上位に来ているなら、発熱の原因はインデックス作成ではありません。その場合は他の原因についてのセクションまで読み飛ばしてください。これは Activity Monitor が教えてくれる最も価値のある情報であり、15 秒で済みます。

数値の読み方についてひとつ補足します。マルチコアの Mac では、1 つのプロセスの % CPU が 100% を超えることがあります。コア単位で計測されているためです。340% と表示されているプロセスは、おおよそ 3.5 コア分の処理能力を使っています。並列でのインデックス作業では正常なことであり、それ自体は心配する理由になりません。

チェック 2：エネルギータブ

エネルギータブに切り替えます。見るべき列はエネルギー影響で、これはプロセスがバッテリーの面でどれだけコストになっているかについての macOS 自身の総合的な推定値です。CPU に加えて、ウェイクアップ回数など電力に関わる他の挙動も加味されています。

「何がバッテリーを食い潰しているのか」という具体的な問いに対しては、エネルギータブのほうが CPU タブより役に立ちます。プロセスは、そこそこ忙しい程度でも極端に電力を食うことがありますし、CPU% の平均値では均されてしまう短いバーストで動くこともあるからです。インデックス関連デーモンがエネルギー影響で上位を占めているなら、それがあなたのバッテリー消費の正体を数値で示しています。

ついでに「スリープを妨げているプロセス」の列も見ておきましょう。インデックス作成中にスリープを妨げるプロセスがあるのは想定内です。macOS は処理の途中でマシンを眠らせるよりも、一部のインデックス作業を意図的に生かし続けるからです。

チェック 3：Terminal での mdutil -s -a

Activity Monitor は何が動いているかを教えてくれます。mdutil は、Spotlight 自身が自分の状態をどう認識しているかを教えてくれます。Terminal（アプリケーション → ユーティリティ）を開いて次を実行します。

mdutil -s -a

-s フラグは「状態を表示」、-a は「すべてのボリューム」を意味します。ボリュームごとに 1 ブロックずつ出力され、それぞれパスの後に状態の行が続きます。見たいのはこれです。

/System/Volumes/Data:
	Indexing enabled.

Indexing enabled. が健全な答えです。Spotlight がそのボリュームをインデックスするよう設定されているという意味で、これは一連の処理が動くための前提条件です。

マウントされているすべてのディスクではなく起動ボリュームだけを見たい場合は、次を使います。

mdutil -s /

注意すべき異常な状態が 2 つあります。あるボリュームが Indexing disabled. と報告していて、それを意図的に無効化した覚えがない場合、Spotlight は動いていないので永遠に完了しません。次のコマンドで再度有効にします。

sudo mdutil -a -i on

管理者パスワードの入力を求められます。入力しても文字は表示されませんが、これは正常な動作です。

一方、mdutil が有効／無効というきれいな状態ではなくエラーを返す場合は、その正確な文言をメモしてください。これは後述する本物の「正常ではない」サインのひとつです。

macOS の構成によっては、Terminal にフルディスクアクセス（System Settings → プライバシーとセキュリティ → フルディスクアクセス）が付与されていないと、mdutil が一部のボリュームについて限られた情報しか報告しないことがあります。出力が想定より乏しい場合は、何かが壊れていると結論づける前にこの点を確認する価値があります。

チェック 4：負荷はアイドル時間に連動しているか

これは多くの人が飛ばすチェックですが、4 つの中で最も診断価値の高いものです。

インデックス作成は行儀のよい処理として設計されています。あなたが Mac を積極的に使っているときは手を緩め、使っていないときにペースを上げます。したがって健全なインデックス作成のサインは、あなたの活動と逆の動きになります。電源につないだまま Mac を放っておくと数分後にファンの音が大きくなり、戻ってきて作業を始めると、システムが CPU を譲るのでわずかに静かになります。

発熱がそのように振る舞っているなら、それはバックグラウンドのメンテナンス作業であり、進行しています。逆に、何をしても負荷が完全に一定で、蓋を閉じた午前 3 時も、重い作業をしている午後 3 時も CPU がまったく同じなら、それはスケジューラを意識したバックグラウンド処理というより、ループにはまって止まっている状態に近いといえます。

Activity Monitor を開いたままにせずとも、Terminal でこれを観察できます。

top -o cpu

これは実行中のプロセスを CPU 使用率順に並べ、継続的に更新します。終了するには q を押します。Activity Monitor を出しっぱなしにするより軽量な監視方法です（Activity Monitor 自体も多少の CPU を消費します）。

見つからないものについての注意

進捗率はありません。完了予定時刻もありません。macOS はそれを公開しておらず、どんなコマンドの組み合わせでも作り出すことはできません。進捗の大まかな代用として、ディスク上のインデックスサイズが増えていく様子を観察する人もいますが、その解釈には注意が必要です。macOS は処理の途中で圧縮や再編成を行うため、インデックスサイズは単調に増加するわけではないからです。

進捗バーがないことは受け入れましょう。この状況で本当に苛立たしい部分であり、そうでないふりをしても役には立ちません。あなたにできるのは、正しいプロセスが動いていること、Spotlight がインデックス作成を有効と報告していること、そして負荷がアイドル状態に反応していることを確認し、あとは時間に任せることです。

実際にどれくらい時間がかかるのか

コミュニティの報告と報道は、おおまかな形で一致しています。アップデート後およそ 24〜48 時間は CPU 使用率が急上昇し、何も介入しなくても数日以内に落ち着くというものです。

これは正しく捉えてください。人々の報告から導かれた典型的な範囲であって、保証でもなければ Apple が公表した数値でもありません。あなたの Mac は 6 時間で終わるかもしれませんし、4 日目でもまだ処理中かもしれません。覚えておくべきは正確な時間数ではなく、その形です。最初は重く、徐々に収まり、数日以内に終わる、という形です。

さらに重要なのは、この時計は Mac が起動していて実際に作業をしている間しか進まないという点です。この状況全体の中で最も誤解されているのがここです。夕方に 3 時間だけ使って閉じる MacBook を使っているなら、インデクサに与えているのは 1 日 3 時間です。2 日分の作業は 1 週間近くかかることになり、毎朝蓋を開けるたびに熱いマシンを見て、何も改善していないと結論づけてしまいます。何も異常はありません。ただ、ごく少量ずつしか与えていないだけです。

時間が長引く要因

• ライブラリのサイズ。 最大の単独要因です。数十万のファイル、数万枚規模の Photos ライブラリ、何年分ものメールは、いずれもほぼ線形に作業量を押し上げます。
• 遅いストレージ。 Fusion Drive、古い SATA SSD、特に外付けのハードディスクは、インデックス作成が依存する小さなランダム読み込みが劇的に遅くなります。アーカイブが詰まった外付けドライブが処理全体を支配してしまうこともあります。
• ディスクがほぼ満杯。 インデックス作成には、インデックスを書き込み圧縮するための作業領域が必要です。空き容量が数パーセントしかないドライブはスラッシングを起こし、速度が落ち、最悪の場合は完了できません。ストレージが逼迫しているなら、空き容量を確保するのは正当な対処です。もし原因が肥大化した「システムデータ」カテゴリだという多くの Mac のひとつなら、システムデータの容量が膨らんで減らない理由についてのガイドで、その容量を取り戻す方法を解説しています。
• スリープ。 前述のとおりです。スリープのたびに進捗は止まり、復帰時に一部の作業がやり直しになります。
• 競合する負荷。 アップデート後の初回 Time Machine バックアップ、iCloud の再ダウンロード、Xcode のビルドを同時に走らせていれば、すべてがその分だけ長くかかります。
• サーマルスロットリング。 ファンレスや薄型のマシンでは、継続的な負荷がクロック速度の低下を招き、それが処理を長引かせ、さらに発熱を長引かせます。通気を改善することは、実際に全体の所要時間を短縮します。
• 外付けドライブ。 マウントされていてインデックス対象になっている外部ボリュームはすべて追加の作業になります。今使っていないドライブを取り外すことは、これを目に見えて速くできる数少ない手段のひとつです。

実行中にすべきこと

「何をすべきか」への正直な答えは、ほとんどの場合「終わるまで待つ」です。ただし、本当に効果のある選択肢がいくつかあり、本当に害になる選択肢もいくつかあります。

電源につなぐ。 これが最も価値の高い行動です。AC 電源に接続していると、macOS はバックグラウンドのメンテナンスをずっと積極的に実行するようになりますし、バッテリー残量が減っていくのを見つめずに済むので、不安の大部分がなくなります。バッテリー駆動でのインデックス作成は遅く、しかも目につきます。最悪の組み合わせです。

蓋を開けたまま Mac を起こしておく。 MacBook の蓋を閉じると作業の大部分が停止し、熱がディスプレイに閉じ込められます。硬く平らな面（ベッドの上でも、ソファのクッションの上でも、膝の上でもなく）に開いたまま置いておけば、筐体が放熱でき、処理を進められます。一晩動かし続けたい場合は、System Settings → ロック画面でディスプレイのスリープとロックまでの時間を延ばせますし、省エネルギー（ポータブルでは バッテリー → オプション）に、電源接続時にディスプレイがオフでもスリープさせない設定があります。

Wi-Fi に接続しておく。 この期間に走る処理の一部は純粋にローカルなものではありません。Photos や iCloud のコンテンツは、解析される前に同期や再ダウンロードが必要な場合があります。接続を保っておけば、停止してリトライを繰り返すことなく完了できます。

今は必要ない外付けドライブを取り外す。 接続されていてインデックス対象になっているボリュームはすべて作業を増やします。月に一度しか触らないアーカイブ用ドライブを取り出せば、キューから完全に除外できます。

デーモンを強制終了しない。 Activity Monitor から mds、mds_stores、mdworker_shared を強制終了しても、役に立つことは何もありません。macOS は数秒以内にそれらを再起動しますし、進行中の作業を捨ててしまった可能性があるため、同じ CPU サイクルをもう一度費やすことになります。主導権を握った気分にはなります。実際には逆です。

まだインデックスを再構築しない。 方法は後述しますし、実際に再構築すべきケースもありますが、それは今ではありません。詳細は次の次のセクションで扱います。

サードパーティのクリーナーや「最適化ツール」をインストールしない。 この状況はソフトウェアを追加しても何も解決しませんし、Mac がすでにファイルシステム全体をスキャンしている最中に、ファイルシステム全体をスキャンするツールを追加すれば、熱は減るどころか増えます。

一時的に Spotlight への期待値を下げる。 インデックスの書き換え中は、検索結果が不完全だったり、順位がおかしかったりすることがあります。これは自然に解消します。Spotlight の検索挙動が一番気になるという場合は、macOS Tahoe の Spotlight 完全ガイドで、検索システムの構造と各部分の役割を解説しています。

正常ではない場合

ここからは慎重にならなければなりません。この記事の安心させる側の主張、つまり「大丈夫、ただのインデックス作成です」は、それがあなたにとって真実である場合にしか役に立たないからです。これを読んでいる人の中には、本当にインデックスが止まっている人や、まったく別の問題を抱えている人もいます。そういう人に待てと言うのは、1 週間を無駄にしろと言っているのと同じです。

以下は被害妄想ではなく、本物のサインとして扱ってください。

負荷がまったく収まらない。 健全なインデックス作成は徐々に落ち着きます。mds_stores の CPU 使用率が 1 日目も 4 日目も 7 日目もまったく同じで、下降傾向がまるでないなら、それは短距離走ではなく高原状態です。高原状態は自然には解消しません。

mdutil が状態ではなくエラーを返す。 mdutil -s -a が、きれいな Indexing enabled. や Indexing disabled. ではなくエラーメッセージを返す場合、Spotlight は自分で説明できない状態に陥っており、これは正当な障害です。

インデックス作成が無効と表示され、有効のままにならない。 sudo mdutil -a -i on を実行して反映を確認したのに、後から再び無効になっているなら、何かが能動的にそれをオフにしています。これは待って解決する問題ではありません。

電源に接続して起動したままの状態で 1 週間経っても、Spotlight が文字どおり何も返さない。 インデックス作成中に結果が部分的になるのは想定内です。しかし、電源につないで起動し続けたマシンで、1 週間経ってもよくあるファイルに対して結果がゼロというのは異常です。

Mac は熱いのに、インデックス関連デーモンが CPU 上位にいない。 これは重要なポイントです。Activity Monitor でブラウザ、同期クライアント、あるいは見覚えのあるアプリが CPU を占有しているなら、アップデートの時期がどうであれ、インデックス作成はあなたの問題ではありません。物語よりも Activity Monitor を信じてください。

カーネルパニック、突然の再起動、負荷時のシャットダウン。 インデックス作成でこうしたことは起こりません。発熱に不安定さが加わっているなら、ハードウェアまたはファームウェアの問題が疑われ、忍耐ではなく Apple サポートに相談すべき状況です。

ファンが常に最大で回り、筐体が触れないほど熱い。 温かいのは想定内です。本当に危険を感じるほどの熱、特にまったく回転数が変動しないファンを伴う場合は、ファンや温度センサーの故障を示すことがあります。あるいは単に通気口がふさがっているだけということもあるので、まずそちらを確認する価値があります。

正しく実行した本格的な再構築の後でも何も改善しない。 後述の再構築をいずれ実施し、十分な時間を与えたうえで、まったく同じ状態に戻るなら、問題はインデックスではありません。

以上のいずれかに当てはまるなら、次のセクションはあなたのためのものです。当てはまらないなら、次のセクションは罠です。どうかそのまま待ってください。

クリーンな再構築を強制する方法と、その代償

まず代償を理解する

Spotlight にインデックスの再構築を強制する方法は 2 つあります。しかしそれは 2 種類の異なる対処法ではなく、インターフェースが違うだけの同じ操作です。片方を試してから、違う結果を期待してもう片方を試すのはやめてください。

どちらも行うのは、既存のインデックスを消去し、何もない状態からやり直すことです。

今のあなたの問題に照らして、もう一度読んでください。あなたがここにいるのは、Mac がインデックスを構築していて熱いからです。再構築は、それまでに進んだ分をすべて捨てて、丸ごと最初から作り直させます。短期的には、熱は減るどころか増えます。たとえば 70% まで進んでいた処理を 0% に戻すわけですから、その 70% 分の代償をもう一度支払うことになります。

だからこそ、この件に関する信頼できるアドバイスはどれも「まず待つ。本当に止まっている場合にだけ再構築する」なのです。Mac が温かいからといって初日に再構築するのは、最も逆効果な行動です。2 日で済む問題を 4 日の問題に変え、しかも「対処しても効果がなかった」と思い込ませることになります。

再構築するのは、本当の理由があるときです。高原状態、mdutil のエラー、あるいは 1 週間続く検索結果ゼロといった場合です。焦れたから、ではありません。

実行前の準備

• 電源につなぐ。 バッテリー駆動での再構築は、言うまでもなく悪手です。
• Mac を使わなくてよいタイミングで始める。 就寝前か、デスクを離れる一日の前に。電源につないだ状態で、邪魔されない起動時間を与えてください。
• ディスクの空き容量を確保する。 インデックスにも置き場所が必要です。
• 完了するまで検索は使い物にならないと割り切る。 検索対象のデータベースそのものを削除するのです。部分点はありません。

方法 A：Terminal

Terminal を開いて次を実行します。

sudo mdutil -E /

-E は、指定したボリュームのインデックスを消去して再構築するという意味です。末尾の / は起動ボリュームを指します。管理者パスワードの入力を求められます。

実行前にどのボリュームが存在し、現在の状態がどうなっているかを確認するには、まず mdutil -s -a を実行してください。現代の APFS 環境では通常、データボリュームが /System/Volumes/Data として表示され、/ が期待どおりに動かない場合はそちらを直接指定できます。

sudo mdutil -E /System/Volumes/Data

コマンドが完了したら、インデックス作成が有効で実行中であることを確認します。

mdutil -s -a

Indexing enabled. になっていてほしいところです。無効と表示された場合は、sudo mdutil -a -i on で再度有効にします。

あとは放っておきます。数分以内にファンが激しく回り始め、その状態が何時間も続くと考えてください。それがあなたが依頼した再構築であり、意図どおりに動いている姿です。

方法 B：System Settings の検索プライバシー

Terminal を使いたくない場合は、グラフィカルな同等機能が System Settings → Siri と Spotlight（構成によっては単に Spotlight と表示されます）→ 検索プライバシーにあります。

+ ボタンをクリックして、起動ディスク（または再構築したいボリューム）をプライバシー除外リストに追加します。少し待ちます。次にリストでそれを選択し、– をクリックして再び削除します。

ボリュームを追加すると、Spotlight にそれを忘れてインデックス作成を停止するよう指示することになります。削除すると、Spotlight にゼロからインデックス作成を開始するよう指示することになります。正味の効果は完全な再構築で、sudo mdutil -E / が行うのとまったく同じことです。

使いやすいほうのインターフェースを選んでください。両方を使ってはいけません。そして最初のほうが効かなかったように見えても、2 つめを実行しても助けにはなりません。同一の操作だからです。より可能性が高い説明は、単に再構築がまだ実行中だということです。

再構築プロセスのより詳しい手順、そして OS アップデートとは無関係に検索が壊れているケースについては、検索が動かないときに Spotlight インデックスを再構築するガイドをご覧ください。

実は原因かもしれない他の要素

タイミングは因果関係ではありません。アップデート後に Mac が熱くなったのは事実で、アップデートがインデックス作成を始動させたのも事実ですが、アップデート後の数日間には他にもいくつかのことが起きており、そのどれかが真犯人かもしれません。インデックス作成がすべてだと結論づける前に、特に Activity Monitor でインデックス関連デーモンが上位に来ていなかった場合は、以下を切り分けてください。

Photos と iCloud の初回同期。 アップデートによって、Photos がライブラリを再検証したり、オリジナルを再ダウンロードしたり、iCloud Drive がファイルの状態を突き合わせたりすることがあります。どちらもネットワークとディスクに負荷をかけ、長時間実行される可能性があります。Photos では、ライブラリ表示の一番下までスクロールすると同期状況が表示されます。System Settings → Apple アカウント → iCloud では、iCloud Drive が実際に同期中かどうかを確認できます。この作業はインデックス作成と重なることが多く、それがアップデート直後の数日間が不釣り合いに忙しく感じられる理由です。

復活したログイン項目やバックグラウンドエージェント。 アップデートによって、無効にしていたものが再び有効になることがありますし、再インストールされたアプリがヘルパーを登録し直すこともあります。System Settings → 一般 → ログイン項目と機能拡張で、見覚えのないものや許可した覚えのないものがないか確認してください。挙動のおかしいバックグラウンドエージェントは、Spotlight とはまったく無関係に無期限に CPU を食い続けることがあります。

暴走しているアプリ。 何百ものタブを開いたブラウザ、何週間も開きっぱなしの Electron アプリ、ビデオ通話、同期クライアントは、いずれも継続的な発熱を生みます。Activity Monitor の最上位がシステムデーモンではなくアプリケーションなら、それが答えです。終了させ、温度を観察して確認してください。

Time Machine のアップデート後初回バックアップ。 大型アップデートの後は大量のシステムファイルが変更されているため、次のバックアップは通常の増分バックアップよりはるかに大きくなります。ディスク全体を広く読み込むため、インデクサと直接競合します。メニューバーの Time Machine 項目を確認し、バックアップ中であれば発熱の一部はそのせいです。キャンセルせずに完了させてください。キャンセルしても、大きなバックアップが後回しになるだけです。

メモリ圧迫によるスワップ。 Mac の RAM が不足していると、重いバックグラウンド処理がディスクへのスワップを引き起こし、本来の処理に加えて負荷と熱が増えます。Activity Monitor のメモリタブにはメモリプレッシャーのグラフがあり、黄色や赤が続いていればこれが影響しています。メモリを多く使うアプリをいくつか終了させれば、RAM だけでなくディスクの負荷も下がります。

劣化したバッテリー。 これは新しい現象ではないので見落としやすいのですが、アップデートがそれを可視化しただけです。継続的な CPU 負荷はバッテリーに強い負担をかけ、長年で容量を失ったセルは、まさにこの種の負荷のもとで最も劇的にその老朽ぶりを露わにします。System Settings → バッテリー → バッテリーの状態を確認してください。修理サービス推奨と表示されていたり、最大容量が明らかに低下していたりする場合、「26.6 がバッテリー駆動時間を破壊した」と感じている現象の一部は、もともと限界に近かったバッテリーが、それを露呈させるワークロードに出会った結果です。

通気口の閉塞やほこりの蓄積。 地味ですが実際にあります。何年も問題なかったマシンが、吸気口がふさがっているというだけの理由で、継続的な負荷のもとで熱くなることがあります。ソフトウェア的な原因を想定する前に、通気口が塞がっていないこと、マシンが硬い面に置かれていることを確認してください。

macOS 27 に備える

報道の解釈が正しいとすれば、そして繰り返しますがそれは解釈です、今あなたの Mac で起きている作業は税金ではなく投資ということになります。構築されているインデックスは、自分のコンテンツについて自然言語で質問したときに macOS 27 の Siri と Apple Intelligence 機能が問い合わせる土台になるものです。

この見方は、ひとつの実務的な判断において重要です。アップグレードする前に、この作業を終わらせてください。 この作業の途中の Mac に macOS 27 をインストールすると、大型 OS アップグレード自身のインデックス作成と移行処理が、未完了の作業の上に積み重なります。macOS 27 のアップデート（今のベータであれ、秋の正式版であれ）を適用する前に、Mac が冷えて静かになるまで待つことが、問題を複合させないための最もシンプルな方法です。

計画を立てるうえで知っておくとよい点をいくつか挙げます。

• macOS 27 は Apple silicon 専用、M1 以降です。Intel Mac は Tahoe に留まります。Intel マシンをお使いの場合、macOS 27 への準備という位置付けは一切当てはまりませんが、26.6 の Spotlight 最適化自体は実行されています。
• macOS 27 は現在パブリックベータ中で、秋の提供開始が見込まれています。メインマシンにベータソフトウェアを入れるのは、お試しではなく本気のコミットメントです。
• すでに macOS 27 ベータを実行していて同様の発熱やバッテリー消費が見られる場合、それは別の状況であり、考慮すべき点も異なります。ベータはアップグレード時に独自の、より広範な再インデックスを行います。そのケースについては macOS 27 ベータでの Spotlight 再インデックスで個別に解説しており、こちらは 26.6 ではなくベータに特化した内容です。2 つのアドバイスを混ぜないでください。想定される時間軸も挙動も同じではありません。
• 新しい Siri と Spotlight の統合が提供開始後に何をもたらすはずなのかを理解したい場合は、macOS 27 の新しい Siri と Spotlight の会話機能の解説記事で、ベータ時点の機能セットを紹介しています。

よくある問題のトラブルシューティング

問題：Activity Monitor で mds_stores が 300% 以上の CPU を使っているので、終了させたい。 **解決策：**やめてください。強制終了しても作業は止まりません。launchd が数秒以内にデーモンを再起動しますし、進行中のインデックス作成の進捗は破棄されるため、その CPU 時間をもう一度費やすことになります。mds_stores の高い使用率は、インデックス作成が正常に進んでいることを示す、入手できる中で最も明確な証拠です。電源につなぎ、Mac を起こしたまま、走らせておいてください。正当な介入は意図的な再構築だけであり、それも「正常ではない場合」のセクションの条件を満たしたときに限られます。

問題：初日に sudo mdutil -E / を実行してしまい、今は以前より熱くなっている。 **解決策：**残念ながら、それは想定どおりの結果です。再構築は、アップデート後のインデックス作成パスが進めていた分をすべて破棄してゼロから再開したため、その作業の代償を二度払っていることになります。取り消す方法も、近道もありません。電源につなぎ、蓋を開けたままにし、マシンをスリープさせないようにして、起動状態で 24〜48 時間をしっかり確保してください。再構築を再度実行しないでください。二度目を実行すれば、二度目のリセットになるだけです。

問題：mdutil -s -a が起動ボリュームについて Indexing disabled. と表示する。 **解決策：**Spotlight が動作していないため、永遠に完了せず、検索も無期限に壊れたままになります。sudo mdutil -a -i on で再度有効にし、求められたら管理者パスワードを入力してください。その後もう一度 mdutil -s -a を実行し、Indexing enabled. と報告されることを確認します。もし勝手に無効に戻るなら、何かが能動的にそれをオフにしています。System Settings の検索プライバシーにそのボリュームが登録されていないか確認し、登録されていれば削除してください。

問題：MacBook が毎朝熱く、1 週間経っても改善しない。 **解決策：**カレンダー上の日数ではなく、実際に起動して電源が入っていた時間を数えてください。毎晩数時間だけ使って閉じているのであれば、24〜48 時間という目安が前提とする稼働時間のごく一部しかインデクサに与えていません。電源につなぎ、蓋を開けて硬い面に置き、電源接続時にスリープしない設定にしたうえで、一晩まるごと中断なしで稼働させてください。それでも CPU が目に見えて下がらなければ、正当に再構築を検討してよい領域に入っています。

問題：Spotlight がまったく結果を返さず、検索でアプリを起動することもできない。 **解決策：**再構築が実行中であればこれは想定内です。検索対象のデータベースが作り直されている最中だからです。その間はアプリケーションフォルダか Dock からアプリを起動してください。実際に電源が入って稼働した時間で 1 週間を超えても続く場合は、mdutil -s -a でエラーや無効状態を確認し、それから意図的な再構築を 1 回だけ実行して一晩走らせてください。それでも検索が空のままなら、問題はインデックスではないので、Apple サポートにエスカレーションすべきです。

問題：発熱は本物だが、インデックス関連デーモンは Activity Monitor の上位にまったくいない。 **解決策：**それならタイミングがどうであれ、インデックス作成は原因ではありません。CPU タブを % CPU で並べ替えて実際の最上位消費者を特定し、次にエネルギータブでエネルギー影響の最上位項目を確認してください。よくある犯人は、タブを大量に開いたブラウザ、同期クライアント、アップデート後の Time Machine の初回大規模バックアップ、そして再び有効になったログイン項目です。最上位の犯人を終了させ、数分以内に温度が下がるかを観察してください。

FAQ

macOS 26.6 がバッテリーの問題を起こしているのですか、それともバッテリーが劣化しているのですか？

どちらもあり得ますし、混同しやすい問題です。アップデート後のインデックス作成は実際にバッテリーの消費を速めますが、一時的なもので、徐々に収まります。劣化したバッテリーは回復しません。System Settings → バッテリー → バッテリーの状態を確認してください。修理サービス推奨と表示されていたり、最大容量が明らかに低下していたりする場合は、アップデートが問題を作り出したのではなく、もともとあった問題を明らかにしただけです。

アップデート後のインデックス作成は実際どれくらいかかりますか？

コミュニティの報告では、CPU 負荷の高い状態がおよそ 24〜48 時間続き、数日以内に落ち着くとされています。これは典型的な範囲であって、Apple による保証ではありません。決定的に重要なのは、この時計は Mac が起動して稼働している間しか進まないという点です。毎晩数時間だけ使うノートブックでは、2 日分の作業が 1 週間近くに引き延ばされます。

処理を速めるために sudo mdutil -E / を実行すべきですか？

いいえ。このコマンドはインデックスを消去してゼロから作り直すため、完了済みの作業がすべて破棄されます。短期的には熱を悪化させるだけで、改善はしません。本当にインデックスが止まっている場合、つまり電源につないで何日も稼働させても CPU が下がらない、mdutil がエラーを返す、あるいはまる 1 週間経っても検索結果が空、といったケースのために取っておいてください。

Spotlight のプライバシー設定を使う裏技は、Terminal での再構築と違うものですか？

いいえ。System Settings → Siri と Spotlight → 検索プライバシー にボリュームを追加してから削除する操作は、sudo mdutil -E / が行うのとまったく同じ完全再インデックスを強制します。ひとつの操作に対する 2 つのインターフェースです。好きなほうを選び、1 回だけ実行し、違う結果を期待してもう一方を試さないでください。

Apple は本当に macOS 27 の Siri のために私の Mac を準備しているのですか？

Apple のリリースノートには、このアップデートが macOS 27 のリリースに向けて Spotlight を最適化すると書かれています。その部分は確定情報です。しかし、これが macOS 27 の Siri と Apple Intelligence 機能を支えるインデックスを構築しているという具体的な主張は、Apple ではなく報道によるものです。macOS 27 について知られていることを踏まえれば妥当な推論ですが、あくまで解釈として扱ってください。

Spotlight をまったく使わないなら、インデックス作成を完全に止められますか？

sudo mdutil -a -i off でインデックス作成を無効にできますが、割に合わない取引です。Spotlight はアプリの起動、Mail や Photos の検索、Siri の提案、そして多くのアプリでのファイル参照を支えています。無効化すれば、数日間の発熱を避ける代わりに、それらすべてを恒久的に劣化させることになります。待ってやり過ごすほうが、ほとんど常に良い選択です。

まとめ

macOS 26.6 をインストールした直後に Mac が熱くなり、バッテリーを一気に消費し始めたのなら、圧倒的に可能性が高い説明は Spotlight インデックスの再構築です。そして Apple はその理由を一行で伝えていました。このアップデートは macOS 27 のリリースに向けて Spotlight を最適化する、と。報道で広まっている Siri に絡めた見方はその一行のもっともらしい読み方ではありますが、Apple の声明ではなく解釈です。この 2 つは頭の中で分けておく価値があります。

決めつけず、確認してください。Activity Monitor を開いて % CPU で並べ替え、mds、mds_stores、mdworker_shared を探し、大きな Photos ライブラリがあるなら photoanalysisd も探します。エネルギータブで、実際にバッテリーを消費しているものを確認します。mdutil -s -a を実行して、インデックス作成が有効であることを確かめます。そして、席を離れると負荷が上がり、作業を始めると和らぐかどうかに注目してください。この逆相関こそ、健全なバックグラウンド処理のサインです。

そのうえで、地味だが効果的なことをしましょう。電源につなぎ、硬い面の上で蓋を開けたままにし、電源接続時にスリープしないようにし、必要のない外付けドライブを取り外し、処理を終わらせることです。カレンダー上の日数ではなく、実際に起動していた時間で 24〜48 時間をしっかり与えてください。デーモンを強制終了したり、インデックスを再構築したりしたくなる衝動は抑えてください。どちらも進捗を捨て、終わらせたいはずの問題そのものを長引かせます。

そして、本当に正常ではない領域に入ってしまった場合、つまり電源につないで何日経っても負荷が収まらない、mdutil がエラーを返す、インデックス作成が有効のままにならない、あるいは 1 週間まったく検索結果が空、といった場合は、意図的に、一度だけ、一晩かけて、電源につないだ状態で再構築し、必要な時間を与えてください。それでも何も変わらなければ、問題は最初からインデックスではなかったということです。上に挙げた他の原因を調べるか、Apple サポートに連絡すべき段階です。

この記事を読んでいるほとんどの人は、電源につないで待つ以外に何もする必要がありません。満足のいく答えではないでしょうが、それが正解です。あなたの Mac は壊れていません。忙しいだけです。