macOS TahoeでpeopledがMacのCPUを占有？原因はたいてい連絡先ウィジェット

何もしていないのにMacが温かい。バッテリーの残り時間予測は半分になっている。アクティビティモニタを開いてCPU順に並べ替えると、一番上に見たこともないプロセス——peopled——がいて、70〜80%に張り付いたまま動かない。あるいはcontactsdのこともある。最も深刻なケースでは、accountsdが180%に達し、その後ろにcontactsdとitunesclouddが続く。終了しようとしても意味がない。そもそも終了できないからだ。再起動すれば1時間ほどは改善する。

この現象は3月のmacOS Tahoe 26.4以降、Macユーザーの間でずっと起きており、26.5や26.6でも依然として発生している。Appleはこれを認めておらず、検索上位に出てくる「Macを再起動する／NVRAMをリセットする」といった記事のどれにも、最も確実な修正方法は書かれていない。それはウィジェットを削除することだ。

このガイドでは、peopledとは何か（実際に中身を調べた）、なぜウィジェットがこれをループに陥れるのか、なぜ存在すら知らなかったフォルダに付いた検疫（quarantine）フラグがもう一つの引き金になるのか、そして各修正方法を試すべき正しい順序について説明する。

要点まとめ

• peopledは連絡先ウィジェットを支えるデーモンだ。 そのバイナリ自体にWidgetSuggester、WidgetConfigurationReader、CallHistoryFetcherという名前のクラスが含まれており、サンドボックスプロファイルは通話履歴データベースへのアクセスを許可している。この組み合わせがループの正体だ。
• 修正1：すべての連絡先ウィジェットを削除する——デスクトップ、通知センター、コントロールセンターのすべてから——そして再起動する。Appleのコミュニティフォーラムで確認された54件以上の報告のうち、大多数がこれで解決している。
• 修正2：~/Library/Application Support/CallHistoryDBの検疫フラグを解除し、peopledを強制終了する。削除すべきウィジェットが存在しない場合の修正法で、ターミナルにフルディスクアクセスが必要になる。
• 修正3：iCloud連絡先を無効化してから再度有効化する。 一部のユーザーには効くが全員には効かず、無効にしている間は同期が失われる。
• ExchangeやGoogleアカウントに起因するcontactsdのスパイクは、症状は同じでも別系統の古いバグであり、修正方法も異なる——アカウントを削除するか、サードパーティ製クライアントを使う。
• Appleは修正について公式に文書化していない。 26.4.1、26.5、26.6、26.6.xのいずれのリリースノートにも言及はなく、26.5以降でも報告は続いている。

正確にはどのプロセスか

これらの報告には3つのデーモンが登場するが、互いに置き換え可能なものではない。アクティビティモニタを%CPU順に並べ替えて、自分の場合はどれに当てはまるか確認しよう。

プロセス	所属	典型的な報告内容	最も可能性の高い原因
peopled	Peopleフレームワーク——ウィジェット提案、ファミリー、スクリーンタイム、ステータス	26.4以降、70〜80%が持続	連絡先ウィジェット＋読み取れないCallHistoryDB
contactsd	Contactsフレームワーク——アドレス帳データベースと同期	60〜90秒おきに80%までスパイク、または持続的に高負荷	iCloud／Exchange／Google連絡先の同期ループ
accountsd	Accountsフレームワーク——サインイン中の全アカウント	contactsdやitunesclouddと並んで180%	アカウント認証ループ。サインアウトによる修正は効かないことが多い

peopledであれば、まずウィジェットの章から読んでほしい。contactsd単体であれば、同期アカウントの章に直接進んでほしい。accountsdを筆頭に3つすべてが該当する場合は、最も解明が進んでいないパターンに当てはまっており、該当の章ではわかっていないことをそのまま正直に記している。

peopledが実際にしていること

名前からは連絡先を連想するし、これに言及しているガイドもたいてい「連絡先データを管理する」と説明している。それはおおむね正しいが、具体的には間違っている。そしてその違いこそが、修正すべきなのがアドレス帳の修復ではなくウィジェットである理由だ。

26.5.2で動作しているMacでこのデーモンを実際に調べた。実体は/System/Library/PrivateFrameworks/People.framework/peopledにあり、そのlaunchdジョブ（/System/Library/LaunchAgents/com.apple.peopled.plist）を見ると、何がこれを起動させているかがわかる。ログイン時にロードされるわけではない——RunAtLoadはfalseだ。起動のきっかけはイベントである。

• missedCall、unreadMessage、readMessage、location、dndAvailability、screenTimeRequest、askToBuyRequest、childStateに対応するBiomeストリーム
• 2つのシステム通知：__ABDataBaseChangedByOtherProcessNotification（アドレス帳が変更された）と_CalDatabaseChangedNotification（カレンダーが変更された）

つまり、不在着信のたびに、メッセージのたびに、連絡先の編集のたびに、カレンダーの変更のたびにpeopledは起動する。では起動したpeopledは何をするのか。バイナリ内の文字列がそれに直接答えている。Swiftのクラス名の中には次のものがある。

_TtC7peopled15WidgetSuggester
_TtC7peopled18CallHistoryFetcher
_TtC7peopled25WidgetConfigurationReader

そしてログメッセージのテンプレートの中には次のものがある。

Event triggered widget refresh: %{private}s, %s
Last widget suggestion date is older 24 hours, suggest widgets
Last widget suggestion date is within 24 hours, do not suggest widgets
error reading widgets configurations: %s
Failed to suggest widgets with error: %s

Contactsフレームワーク、CallHistoryフレームワーク、そして2つのBiomeフレームワークとリンクしている。そのコード自体が語っている限りでの目的は、直近の通話やメッセージをシグナルとして使い、連絡先ウィジェットや人物関連の提案にどの人物を表示するかを決めることだ。

これで障害モードの筋道が通る。あらゆる通話やメッセージで起動され、仕事はウィジェットの更新であり、そのためには通話履歴を読み取る必要があるデーモンなのだ。

なぜループするのか

コミュニティスレッドの断片を、バイナリが語っている内容と並べてみよう。

peopledはサンドボックス内で実行される。そのプロファイルは/System/Library/Sandbox/Profiles/com.apple.peopled.sbにあり、(deny default)から始まって、特定の扉だけを開けていく。そのうちの2つが次のものだ。

(home-subpath "/Library/CallHistoryDB/")
(home-subpath "/Library/Logs/CallHistory")

つまり、~/Library/Application Support/CallHistoryDB/の読み取りが許可されている。ここにはmacOSが、Continuity経由でiPhoneとの間に発着信した通話のデータベースを保存している。このフォルダはTCCによっても保護されており——手元のMacでは、ターミナルにフルディスクアクセスを与えるまで、そこに対するlsはOperation not permittedを返す——だからこそ以下の修正方法にはその権限が必要になる。

では実際の報告を見ていこう。4月21日、Appleのコミュニティスレッドであるユーザーが、peopledが暴走している間にコンソールで見つけたカーネルメッセージを引用していた。

Sandbox: peopled … deny(1) file-read-data ~/Library/Application Support/CallHistoryDB

そして5月20日には別のユーザーが次を引用している。

failed to open /Users/[user]/Library/Application Support/CallHistoryDB: 1 (Operation not permitted)

これらすべてに整合する解釈はこうだ。連絡先ウィジェットがインストールされているためpeopledに更新が依頼される。更新するということは通話履歴を取得することを意味する。その取得が拒否される——フォルダにcom.apple.quarantine属性が付いてしまったか、あるいは報告からは特定できていない何らかの権限上の理由による——ため更新は失敗し、次のイベント（あるいはリトライ）が再びそれを引き起こす。本来、不在着信の後にミリ秒単位で走るはずのデーモンが、代わりに動き続けることになる。

ここで何が確定していて何が確定していないのかは正確に述べておきたい。クラス名、サンドボックスのルール、ログメッセージは直接観察できるものであり、実際に我々が読んだものだ。このループが「ウィジェット更新→読み取り拒否→リトライ」であるというのは、これまでに見たすべての報告と、効果のある2つの修正方法の両方に整合する推論にすぎない。Appleはこのメカニズムを確認しておらず、第二の引き金が存在する可能性もある——あるユーザーは、連絡先ウィジェットがまったく存在しない状態でコントロールセンターを整理し直した後にループが始まったと報告している。

何かを変える前に確認する

2分観察するだけで1時間の当てずっぽうが省ける。そしてCPU使用のパターンを見れば、どの修正方法を選ぶべきかがわかる。

まず波形を見る。 アクティビティモニタでそのプロセスを選択し、ウィンドウ下部のCPU履歴を確認する。あるいはターミナルから次を実行する。

top -stats pid,command,cpu,time -o cpu -n 5

70〜80%で平坦に張り付いているpeopledはウィジェットループだ。スパイクしてゼロまで落ち、1分後に再びスパイクするcontactsdは同期ループだ。3つのデーモンすべてで持続的にCPUを消費している場合はアカウント系のパターンだ。

どれくらいの時間動き続けているかを確認する。 peopledは通常、数秒だけ存在する。手元の（正常な）Macでは41日間常駐した状態でCPU使用率0.0%になっている——常駐していてもアイドル状態であれば問題ない。確認すべきは、常駐していてなおかつビジーになっているケースだ。

ps -axo pid,etime,pcpu,comm | grep -E "peopled|contactsd|accountsd"

拒否ログを探す。 これが決め手となるテストだ。ターミナルをもう1枚開き、デーモンが暴走している間のログをストリーム表示する。

log stream --predicate 'process == "peopled"' --info

そして最初のウィンドウで、直近数分間のログから、コミュニティの報告が引用しているサンドボックスの行を検索する。

log show --last 10m --predicate 'eventMessage CONTAINS "Sandbox: peopled"'

CallHistoryDBに対するdeny(1) file-read-dataが見つかれば、CallHistoryDBパターンに該当しており、修正2が効くはずだ。拒否なしにEvent triggered widget refreshが繰り返されているなら、修正1から試す。ログが静かなのにCPUが高い場合、そのループはデフォルトのログレベルでは記録されないコード内にある。それでも順番通りに修正を試してみるとよい。

確実性が欲しいなら、ファイルシステムを監視する。 fs_usageは、失敗したものも含めて、プロセスが試みたすべてのファイル操作を表示する。

sudo fs_usage -w -f filesys peopled

CallHistoryDBに対するエラー付きの試行で画面が埋め尽くされていれば、それがまさにこのループがリアルタイムで見えている状態だ。

修正1：連絡先ウィジェットを削除する

これが最も多く効果が確認されている修正方法であり、可逆的でターミナルも不要なため、最初に試すべきものだ。

ただし注意点がある。Tahoe搭載のMacにはウィジェットが存在しうる場所が3つあり、そのすべてから取り除く必要がある。

デスクトップ

壁紙をControlキーを押しながらクリックし、ウィジェットを編集を選ぶ。編集中はデスクトップ上の連絡先ウィジェットに削除ボタン（隅にあるマイナス記号）が表示されるので、それをクリックする。あるいはウィジェット自体をControlキーを押しながらクリックし、ウィジェットを削除を選んでもよい。完了をクリックする。

通知センター

メニューバーの日付と時刻をクリックして通知センターを開き、一番下までスクロールしてウィジェットを編集をクリックする。ここにある連絡先ウィジェットも同じ方法で削除する——Controlキーを押しながらクリックしてウィジェットを削除を選ぶか、削除ボタンをOptionキーを押しながらクリックする。

コントロールセンター

ここは見落とされがちな場所だ。Tahoeではウィジェットがコントロールセンターに移動しており、そのカスタマイズはシステム設定の中にはないためだ。メニューバーのコントロールセンターアイコンをクリックし、コントロールを編集を選んで、連絡先関連の項目をコントロールセンターの外にドラッグする。完了をクリックする。

そのあと再起動する——ログアウトだけでは不十分だ。スレッド上で確認された複数の修正報告が、完全な再起動をして初めてCPUが下がったと述べている。

同じスレッドからもう一つ注意点がある。7月31日の報告によると、一部のユーザーでは連絡先ウィジェットを追加していなくても、ウィジェットギャラリーを再び開いただけでループが再発したという。この問題を経験したことがあるなら、Appleがこのデーモンを修正するまでは、ウィジェットエディタ自体を避けるべきものとして扱ってほしい。

修正2：CallHistoryDBの検疫フラグを解除する

連絡先ウィジェットがどこにも存在しないMac、あるいは削除しても効果がなかった場合には、こちらの修正方法が該当する。これはスレッド中で最も技術的に詳細な報告が5月20日にたどり着いたもので、少なくとも他に2人のユーザーが効果を確認している（6月26日には「peopledプロセスのCPU消費が今は0%になった」と書いたユーザーもいた）。

ステップ1：ターミナルにフルディスクアクセスを与える

システム設定 > プライバシーとセキュリティ > フルディスクアクセスで、ターミナルを追加してオンに切り替える。これをしないと、以下のコマンドはすべて「Operation not permitted」で失敗する——ちょうどpeopled自身がぶつかっているのと同じエラーだ。権限を付与したらターミナルを再起動する。

ステップ2：フォルダを確認する

ls -lan@ "$HOME/Library/Application Support/CallHistoryDB"

@フラグは拡張属性を表示する。探すべきものは、フォルダ自体、あるいはその中のCallHistory.storedataファイルに付いているcom.apple.quarantineだ。検疫（quarantine）はmacOSがダウンロードしたファイルに付けるフラグであり、システムのデータベースに付くいわれはない。どうやってそこに付くのかはわかっていないが、バックアップからの復元と、別のMacからの移行が考えられる2つの経路だ。

ステップ3：削除する

xattr -dr com.apple.quarantine "$HOME/Library/Application Support/CallHistoryDB"

-dは属性を削除し、-rはフォルダ内を再帰的に処理する。

ステップ4：デーモンを再起動する

sudo killall -9 peopled CallHistorySyncHelper

どちらも必要になれば再び起動される。数分間アクティビティモニタを見守ってほしい。

フラグが再発する場合

スレッド上のあるユーザーは7月17日、この修正は効いたものの、一晩で検疫フラグが「再出現した」と報告している。もし同じことが起きたら、何かがそのフォルダを再び検疫扱いにしていることになる。有力な候補は、フォルダを新規データとして扱うバックアップツールや同期ツールだ。夜間に何が動いているか確認してほしい。もっと単刀直入な方法として、別のユーザーはデータベースを削除してmacOSに再作成させるというアプローチを取った。

rm -rf ~/Library/Application\ Support/CallHistoryDB

これによりMac側の通話履歴のコピーは失われるが、Continuity経由でiPhoneから再び埋まっていく。これは属性を削除するよりも強引な手段であり、我々ならまず属性の方から試す。

修正3：iCloud連絡先を切り替える

システム設定 > [あなたの名前] > iCloud > iCloudに保存 > 連絡先、をオフにする。1分ほど待ってCPUを確認する。下がったら再びオンに戻し、そのまま下がった状態を保つかどうかを確認する。

これは一部のユーザーには効き、何年も前から続く同種のスレッドでも定番のアドバイスとなっている。一方で、あるユーザーが5月11日に遭遇した失敗パターンもある——トグルがまったくオフにならないというものだ。そうなった場合は、iCloudから完全にサインアウトし（データのコピーを残すか尋ねられたら残す）、再起動してから再びサインインする。なお、accountsdパターンを報告したV2EXの投稿者はまさにこれを試したが、サインインし直した直後にCPUが元通りになったという。

contactsdでExchangeやGoogleアカウントを使っている場合

これはTahoe以前から存在する問題で、メカニズムもより明確だ。

contactsdはContactsフレームワークのデーモンで、アドレス帳データベースを保有し、連絡先を同期するすべてのアカウントとの間で整合を取る。スケジュールに沿った定期処理も行っており、そのlaunchdジョブは、電源接続時かつ操作していない時にのみ実行されるvalidate-cacheという日次タスクと、繰り返し実行されるaccounts.cleanupアクティビティを登録している。contactsdが時々短くCPUを使うのは正常な動作だ。

正常でないのは、1分おきくらいにスパイクが起きることだ。あるデベロッパーは2025年12月、Apple Developer Forumsでまさにこれを記録している。Tahoe 26.1のM1 Maxで、連絡先を有効にしたOffice 365アカウントを使うと、AddressBookManagerが81%に、contactsdが22〜59%に達するパターンが60〜90秒おきに繰り返された——サーバー側でExchangeの連絡先フォルダを空にしても発生し、クリーンインストールでも再現した。同じアカウントと同じデータでも、M4搭載のMacやiOSでは起きなかった。Appleからの返信は誰にもなかった。

効果があったのは、この開発者が取った回避策だ。システム設定 > インターネットアカウントからExchangeアカウントを削除し、必要であればContactsフレームワークを経由しないOutlookを使う。2024年モデルのMacBook Proの26.3でcontactsdが問題になった2月のコミュニティフォーラムの報告でも、同様のアドバイス——ExchangeとGoogleからの連絡先同期を止めてテストする——がなされている。iCloudとGoogleアカウントの両方が連絡先を同期しているなら、まずGoogleの方を外してみるとよい。

accountsdパターン

最も深刻な報告——26.5.2のM5搭載MacBook Airでaccountsdが180%に達し、contactsdとitunesclouddを伴っていたケースで、7月にV2EXで報告されたもの——には、確認済みの修正方法がない。報告者は毎朝同じ時刻に発生し始めると述べており、これはウィジェットのイベントというよりスケジュールされたタスクを示唆している。サインアウトしてサインインし直しても効果はなかった。

我々から付け加えられることとしては、accountsdはAccountsフレームワークのデーモンで、サインイン中のアカウントの認証情報が必要になるたびに呼び出される。itunesclouddはiTunes Cloud（Apple Music／ストア）のライブラリデーモンだ。この3つが同時に発生しているということは、何かが繰り返しアカウントの認証情報を要求しては失敗していることを意味する。このパターンに該当する場合でも、上記の修正方法を順番に試す価値はある。それでも解決しない場合は、システム設定 > インターネットアカウントの中で、単一のアカウント——古いGoogleやExchangeのログイン、期限切れのアプリ用パスワードなど——が認証に失敗していないか確認する価値がある。警告バッジが表示されているものはすべて削除しよう。

なぜTahoeで、なぜウィジェットなのか

ウィジェット自体はMacに何年も前から存在しているので、なぜ26.4から始まったのかと問うのは当然だ。2つのことが同時に変わっている。

1つ目は、ウィジェットが存在する場所だ。Tahoeはデスクトップや通知センターに加えて、コントロールセンターにもウィジェットを置けるようにした。そしてコントロールセンター内の連絡先ウィジェットは、デスクトップに置かれたものとは異なる頻度で更新される——デーモン自身のログテンプレートも、日次の「ウィジェットを提案する」処理（「Last widget suggestion date is older 24 hours」）と、イベント駆動の更新（「Event triggered widget refresh」）を区別している。表示面が増えれば更新リクエストも増え、失敗したものがリトライされる機会も増える。

2つ目は、このデーモンのエラー処理が、後退（バックオフ）するのではなくリトライしているように見えることだ。これは挙動から我々が推測したものであり、バイナリから直接読み取れるものではないが、これこそが実際のバグだと考えられる。拒否された読み取りは一度だけログに記録し、次の本物のイベントが来るまで更新をあきらめるべきだ。ところが実際には再試行され、しかもイベントは絶えず送られてくる。

このどちらもユーザー側で変えられるものではない。変えられるのは、ウィジェットが存在するかどうかと、読み取りが拒否されるかどうかであり、3つの修正方法はまさにそこに働きかけている。

修正した後にすべきこと

直った状態を保つために、いくつかやっておくべきことがある。

修正2を使った場合はターミナルのフルディスクアクセスをそのまま残しておくか、意図的に取り消す——どちらでも構わないが、フルディスクアクセスを持つターミナルは広範な権限であることを踏まえ、自分がどちらを選んだかは把握しておこう。

しばらくウィジェットギャラリーを避ける。 スレッドの7月31日の報告は、何かを追加することではなく、ギャラリーを開くこと自体がループを再発させたと具体的に述べている。他のウィジェットを追加したい場合は追加したうえで、後でアクティビティモニタを確認しよう。

次のmacOSアップデートの後、もう一度確認する。 マイナーアップデートによって一部のユーザーではコントロールセンターのデフォルト項目が再追加されており、連絡先ウィジェットが静かに戻ってくることが、問題が再発する最も可能性の高い理由だ。

報告を提出する。 Feedback Assistantで、カテゴリはmacOS、CPUが高いときに取得したsysdiagnose（ターミナルからsudo sysdiagnose、またはShift-Control-Option-Command-Period）を添付し、サンドボックスの拒否ログの行を貼り付ける。5か月分のフォーラムスレッドではこの問題は動かなかったが、同じログ行を伴う数百件のFeedback報告なら動くかもしれない。

もう直ったのか

わかっている限りでは、直っていない。AppleのTahoeのアップデートノートを確認したが、26.4.1は「バグ修正を提供」、26.5は「機能強化、バグ修正、セキュリティアップデートを含む」、26.6はSpotlightのインデックスを最適化するとあり、26.6.1と26.6.2はセキュリティリリースだ。いずれにも連絡先、ウィジェット、CPUへの言及はない。コミュニティスレッドでは26.5でも報告が続いており（5月15日には「Tahoe 26.5でもこの問題はまだ存在する。Appleは早急にこれを修正する必要がある」との投稿）、7月に入っても続いている。8月17日にリリースされた26.6.2については、良い方にも悪い方にもまだ報告を見ていない。

macOS 27ベータを使っていて、この問題を見た・見ていないいずれの場合も、ベータ版の既知の問題まとめで追跡している。

試すだけ無駄なこと

NVRAMやSMCのリセット。 どちらもユーザー空間のデーモンのファイル権限とは何の関係もない。飛ばしてよい。

tccutil reset All。 あるユーザーが試したが効果はなく、しかもMac上のすべてのアプリからあらゆるプライバシー権限が剥がされてしまい、それを付与し直すのに午後いっぱいかかることになる。TCCが原因の層だと考える理由はない——ログに出ている拒否はサンドボックスによるものであり、TCCではない。

セーフモード。 セーフモードで起動して戻すと一部のキャッシュがクリアされ、少数のユーザーには一時的な改善が見られた。手順が増えただけの再起動であり、根本原因には対処していない。

launchctlでpeopledを無効化する。 launchctl disableでこのエージェントを無効化することはでき、動かなくなる分CPUの消費は止まる。しかし連絡先ウィジェット、人物の提案、スクリーンタイムの「購入をリクエスト」の仕組み、その他これに依存するものすべても止まってしまう。しかもSystem Integrity Protectionが有効なMacでは、この変更がアップデートを越えて残らない可能性もある。最終手段の診断以外では推奨しない。

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

アクティビティモニタにcontactsdが20個も表示される

これは我々自身、本記事を書いている最中に目撃した。連番のPIDを持つcontactsdプロセスが20個一気に現れ、すべてlaunchdの子プロセスで、すべてCPU使用率0%、1分以内に消えていった。これはlaunchdがクライアントごとにオンデマンドでインスタンスを生成しているだけで、バグではない。バグとは、高いCPU使用率のまま居座り続ける単一のプロセスのことだ。

連絡先ウィジェットは削除したのにpeopledがまだ80%のまま

デスクトップ、通知センター、コントロールセンターの3か所すべてを確認し、そのうえで修正2に進む。そもそも連絡先ウィジェットを持ったことがない場合は、直接修正2に進んでよい。

xattrが「No such xattr: com.apple.quarantine」と表示される

そのフォルダは検疫されていないので、それがあなたの原因ではない。修正3を試し、ExchangeやGoogleアカウントが連絡先を同期していないかも確認してほしい。

CallHistoryDBに対するlsが、sudo付きでも「Operation not permitted」になる

sudoはTCCを迂回できない。ターミナル自体にフルディスクアクセスが必要で、システム設定で付与したうえで、ターミナルを再起動する必要がある。

macOSアップデート後に問題が再発した

アップデートによって、コントロールセンターのデフォルトレイアウトにウィジェットが再追加されることがある。3か所をもう一度確認してほしい。

FAQ

peopledはマルウェアか

いいえ。これは署名されたApple製のデーモンで、封印されたシステムボリューム上の/System/Library/PrivateFrameworks/People.framework/peopledにある。同じ名前のプロセスが他の場所から実行されていたら調べる価値があるが、これはApple自身のものだ。

単に強制終了してもいいか

sudo killall peopledは、次のイベントに起動させられるまでは止められる。忙しいMacであれば、それは数秒後だ。強制終了後にCPUが低いままなら引き金がなくなったということなので、診断としては有用だが、修正方法としては不十分だ。

ウィジェットを削除すると何か失われるか

失われるのはウィジェットだけだ。連絡先、通話履歴、Spotlightやメッセージでの提案も、すべて引き続き機能する。peopledも必要なときには変わらず動く。単に、更新できないものの更新を頼まれなくなるだけだ。

なぜCallHistoryDBフォルダの読み取りにフルディスクアクセスが必要なのか

そこには通話ログが含まれており、macOSはこれをメッセージやメールと同様、機微な個人データとしてTCCで保護している。この保護があるからこそターミナルには権限の付与が必要になるし、予期しない検疫フラグがこれほど破壊的な影響を及ぼすのも同じ理由だ。デーモンはそのデータへ、サンドボックス化された狭い一本の経路しか持っておらず、その経路を塞ぐものは何であれ完全にデーモンを止めてしまう。

macOS 27でこれは直るか

わからない。Appleはこの問題を認めておらず、ベータ版のリリースノートにも一切記載がない。もしメカニズムが証拠から示唆される通りだとすれば、修正自体は小さなもの——一度失敗したらリトライをやめるだけ——であり、言及されないままどのマイナーアップデートで届いてもおかしくない。

まとめ

何もしていないのに熱くなるMacは、ほぼ必ずどこかのプロセスがループに陥っており、そのループの原因はほぼ必ず地味なものだ。今回の場合は、ウィジェットを最新の状態に保つのが仕事で、あらゆる通話やメッセージで起動され、必要な唯一のデータベースを読み取れないデーモンだった。ウィジェットを削除すればリクエストは止まり、フォルダの権限を直せば読み取りは成功する。どちらの方法でもループは断ち切れる。

アクティビティモニタの一番上にpeopledがいるなら、3つの修正方法を順番に試し、その都度再起動しよう。ExchangeやGoogleアカウントに起因するcontactsdであれば、そのアカウントを削除しよう。そしてaccountsdを筆頭に3つすべてが該当するなら、上記のすべてを試し、警告が出ているアカウントを削除したうえで——Appleはこの問題について5か月間沈黙を保っているので——サンドボックスのログ行を添えたFeedback報告を提出しよう。それが最終的にこの問題を直すきっかけになるかもしれない。

関連記事：macOS 26.6後にMacが熱くなりバッテリーが減る問題、Liquid Glassを伴う26.5でのWindowServerのCPU問題、Tahoeで連絡先アプリが動作しない問題、アクティビティモニタの基礎から学ぶガイド、Tahoeでのウィジェットカスタマイズガイド。