macOS 27 で夜間に dasd と appstoreagent の CPU 使用率が高くなる問題の対処法

macOS 27 で朝になると Mac が熱く、ファンが回り、バッテリーが減っていませんか。dasd と appstoreagent のループを確認し、コミュニティの回避策を適用して、ほかの原因も切り分けます。

バッテリーが十分な状態でMacのフタを閉じたのに、朝になると本体が温かく、ファンが明らかに回った形跡があり、一晩のスリープで減るはずの量を超えてバッテリーが減っている。これが macOS 27 Golden Gate へのアップグレード直後から始まった場合、はっきりと報告されている原因の候補があります。dasd と appstoreagent という2つのバックグラウンドプロセスが、毎晩午前0時から密なループに入っているというものです。このガイドでは、この2つのプロセスが何者か、Apple のバックグラウンドスケジューラがそれらをいつ実行するかをどう決めているか、あなたが見ているのが本当にこのバグなのか(Mac が夜間に熱くなる十数個の別の原因ではないのか)をどう証明するか、コミュニティの回避策の具体的な手順と元に戻す方法、そして macOS 27.0.1 で修正されたかどうかについて何が言えて何が言えないかを説明します。ここに書かれている内容はすべて公開されている報告とドキュメントに基づいており、未確認の事項はその旨を明記しています。

重要ポイント

このバグは報告されており、複数の人が再現していますが、Apple はまだ認めていません。 9月27日に立てられた MacRumors のスレッドでは、2台の MacBook で午前0時に appstoreagent と dasd が急上昇すると報告されており、Mac Studio と MacBook Pro のユーザーからも同様の報告があります。Apple はこの件に関する既知の問題を公開していません。
報告されている原因は、自身の期限を先へ進めない Apple Arcade のタスクです。 独立した複数の解説によると、com.apple.appstored 内の ArcadePayoutResetDate という設定値が過去の日時のまま固定され、スケジューラがそのタスクを繰り返し実行し続けます。頻度は毎秒70〜100回と報告されています。
何も変更せずに2分で確認できます。 プロセスを CPU 使用率で並べ替え、設定値を読み取り、述語を指定して統合ログを確認します。日付が過去で、ログが大量に出力されていれば、それがこのバグです。
コミュニティの回避策は defaults write を1回と killall appstoreagent です。 日付を未来に押し出します。あくまで回避策であり、元に戻せます。選んだ日付(たとえば7日後)まで効果が持続すると報告されています。
27.0.1 で修正されたかどうかは確認できませんでした。 Apple の 27.0.1 アップデート(ビルド 26A434)は、詳細不明の不具合を修正するものと説明されています。この問題について確認済みの結果を投稿した人はまだいないため、修正済みと決めつけず、ご自身の Mac で確かめてください。
まず、ありふれた原因を除外してください。 アップグレード後の Spotlight や写真の解析、Time Machine、iCloud の同期、ネットワークアクセスによるスリープ解除の設定はいずれも夜間の発熱を引き起こします。どのプロセス名がどの原因を示すかは、後述の判断表で確認できます。

症状:午前9時に Mac が温かく、バッテリーが減っている

MacRumors のスレッドの投稿者は、この症状をもっとも的確に説明しています。macOS 27 をインストールしてから、MacBook Pro と MacBook Air の両方で、「ちょうど午前0時に」CPU 使用率が急上昇し、原因は appstoreagent と dasd だったとのことです。2回目には、iStat Menus を開いたまま両方のマシンを一晩稼働させたところ、負荷は午前9時に再び下がりました。Mac Studio と MacBook Pro を使っている別のメンバーも同じ挙動を確認しており、3人目は有用な指摘を加えています。システムモニタを使っていなければ CPU 負荷には気づかないかもしれませんが、「バッテリーの減りが速くなっていることには間違いなく気づく」というものです。

押さえておきたい詳細を挙げます。いずれもユーザーの観察であり、Apple の公式ドキュメントではありません。

発生時刻はローカル時間の午前0時と報告されています。 スレッド内のある投稿者は、負荷が午前9時に終わったと述べています。別の解説では、固まったタイムスタンプを、その投稿者のタイムゾーンでの「today at 00:00:00」と説明しています。どちらも Apple のドキュメントではなく、ユーザーの観察です。
正式版で初めて現れたものではありません。 スレッドの投稿者は、初期のベータ版ですでに見かけた人がいたと述べています。また、6月24日付の中国語の解説では、macOS 27 のデベロッパベータで appstoreagent が100パーセントを超える CPU を使用していたと記されています。つまり、リリース版で新たに生じた退行ではなく、以前から存在していたバグが出荷されたものです。

ご自身の Mac に当てはまるなら、このまま読み進めてください。日中に熱くなる場合や、夜間だけでなくアップグレード後の数日間ずっと熱い場合は、「ほかの原因」の節へ進んでください。その場合、同じ対処法は効きません。

dasd と appstoreagent の正体

ネット上の見知らぬ人が書いたコマンドを実行する前に、何に手を加えるのかを知っておくと役立ちます。

appstoreagent:App Store のバックグラウンドヘルパー

appstoreagent は、App Store の仕組みに属するユーザー単位のバックグラウンドエージェントです。アプリのアップデート確認、自動ダウンロードの処理、ライセンスの検証、App Store の状態の同期を行います。通常は目に見えず、CPU 使用率もほぼ0パーセントです。加えて、ここで問題になる役割として Apple Arcade の管理処理も担っており、そのため Arcade 関連の設定値がこのドメイン(com.apple.appstored)に現れます。

dasd:Duet Activity Scheduler

dasd は Duet Activity Scheduler デーモン(略して DAS)で、Mac でもっとも重要なバックグラウンドプロセスの1つです。この仕組みについて公開されている最良の資料である The Eclectic Light Company の Howard Oakley 氏の記事によると、次のように説明されています。DAS は予定されたアクティビティの一覧を保持し、次に実行すべきものを判断するために頻繁に評価しています。あるアクティビティの総合スコアがしきい値を超えると、DAS はそれを実行すると決定し、Apple の軽量なプロセス間通信である XPC を通じて Centralized Task Scheduling(CTS)に起動を指示します。

Time Machine のバックアップ、ソフトウェアアップデートの後片付け、セキュリティスキャン、同期処理、数十種類の定期メンテナンスは、すべてこのパイプラインを通ります。2026年7月の分析で Oakley 氏は、macOS 26.5.2 の起動後およそ1分間に DAS へ送信された、互いに異なるアクティビティが少なくとも701件あったと数えています。また、Apple シリコン搭載 Mac の効率コアで行われる作業の大部分は、現在 DAS と CTS が担っていると指摘しています。言い換えると、dasd は交換台のようなものです。これが CPU を消費しているなら、通常は何かが仕事を送り込んでいるか、同じ仕事を延々と送り込んでいることを意味します。

スケジューラの判断方法:スコア、条件、しきい値

Oakley 氏の解説には、DAS がスコアに組み込む要素が挙げられています。バッテリー残量、充電器の接続有無、エネルギー予算、CPU 使用率、メモリ負荷、熱状態、ネットワーク品質、Mac が Power Nap 状態かどうか、ユーザーがアプリを操作中かどうかなどです。アクティビティごとに固有の条件もあり、たとえば初回の Time Machine バックアップには「起動後300秒間は実行しない」という条件があります。DAS は自身の判断をログに記録しており、氏はスコアとしきい値スコアに並んで、「Decision: Can Proceed」や「Decision: Must Not Proceed」という形式のエントリを示しています。

今回のバグに関係する、この設計の特性が2つあります。

DAS は条件だけでなく、期限にも基づいて仕事を実行します。 アクティビティには特定の時刻までに実行するという印を付けられます。期限を過ぎていて、条件が満たされていれば、実行されます。
アクティビティは所有者を通じて自分自身を再登録します。 アクティビティの実行後、それを所有するプロセス(ここでは appstoreagent)が、次回いつ実行したいかをスケジューラに伝えます。ここで誤った日付が害を及ぼします。

ログ中のアクティビティ識別子は 0:com.apple.softwareupdated.logs-cleanup:A2BBC8 のような形式です。ユーザー ID、アクティビティ名、そして DAS が割り当てる短い16進数のサフィックスで構成されます。覚えておくべきサブシステム名は、DAS の com.apple.duetactivityscheduler と CTS の com.apple.xpc.activity です。前者はこのあとすぐに使います。

報告されている原因:先に進まない期限

複数の人が、それぞれ独立に同じ場所に原因をたどり着いています。もっとも詳細な公開解説は nix-config リポジトリの issue 82 で、MacRumors の返信がリンクしていたブログ記事の中国人開発者の功績としています。その内容を要約すると次のとおりです。

関係するタスクは com.apple.appstored.ArcadeResetPO で、この解説では Apple Arcade の開発者向け支払いリセットタスクだと説明されています。
実行後は、com.apple.appstored ドメインの設定値 ArcadePayoutResetDate が次のサイクルへ進むはずです。ところが実際には、過去のタイムスタンプに固定されたままになります。
そのため dasd はタスクが期限切れだと判断して即座に実行します。appstoreagent は同じ期限切れの時刻で再登録します。このサイクルが毎秒およそ70〜100回繰り返されます。
結果として、1コアが張り付き、統合ログが大量に出力され、発熱とバッテリー消費が起きます。

phobox360 のスクリプトリポジトリは、独自にバグを見つけたという MacRumors のメンバーが書いたもので、同じ仕組みを説明しています。ArcadeResetPO という名前の Apple Arcade のバックグラウンドタスクが、自身を過去の時刻で繰り返し再スケジュールするというものです。独立した2人が同じ結論に達しているため、単なる個人の体験談以上ではありますが、Apple の見解ではありません。

これより前の6月の報告は、ベータ版時代の別の形を説明しています。Arcade のコード内のデータベースエラー(SQLite テーブルの列の欠落や、すでに実行中のタスクを更新しようとするログ行)と、ネットワークインターフェース参照の密なループが原因だとしています。主な価値は、この問題がリリース前から存在していた証拠になる点です。対処法として紹介されている kill -STOP でのプロセス凍結は、凍結中は App Store のアップデートが無効になるため、現在推奨されている方法ではありません。

自分の問題かどうかを確認する方法

順番に実施してください。この節の手順では、設定は一切変更しません。理想的には、最初の2つを Mac が不調な最中、つまり午前0時の直後か、朝いちばんに何かを操作する前に実行してください。

ステップ1:アクティビティモニタを確認する

「アプリケーション」>「ユーティリティ」からアクティビティモニタを開き、CPU タブをクリックして「% CPU」列で並べ替えます。dasd と appstoreagent の両方が上位に並び、CPU 使用率が持続していて、できれば累積の CPU 時間が大きくなっていることを確認します。このバグが起きている Mac では、1コア分を使い切ると報告されているため、マルチコアのマシンで単一プロセスが100パーセント近い値を示すのが典型的なパターンです。dasd は root として動作するため、自分のプロセスしか表示されない場合は、「表示」>「すべてのプロセス」に設定してください。

Mac が一晩中アイドルだった場合でも、appstoreagent の隣に非常に大きな CPU 時間が表示されていれば、急上昇が過ぎたあとでも強い手がかりになります。この列は累積されるためです。6月の解説には、appstoreagent が126.7パーセントで、実行時間が284分を超えている top の1行が示されています。

早朝のキッチンテーブルで、湯気の立つコーヒーカップの横に置いた薄い銀色のノートパソコンを見て顔をしかめる30代の女性。ぼかされた画面にはプロセスの一覧が表示されている

ステップ2:ターミナルで top を使って確認する

アクティビティモニタでも構いませんが、ターミナルなら、フォーラムのスレッドにそのまま貼り付けられるテキストが得られます。top が最初に出力するサンプルは起動時からの平均値なので、2回サンプリングして2つ目を読みます。

top -l 2 -n 10 -o cpu -stats pid,command,cpu,time

-o cpu は CPU で並べ替え、-n 10 は一覧を10プロセスに制限し、-l 2 は2回サンプリングし、-stats は列を選択します。2つ目のブロックを読んでください。Mac がほかにはアイドルなのに、dasd と appstoreagent の両方が上位数件に入っていて、どちらもゼロに近くなければ、このバグと矛盾しません。より簡単な代替手段として、ps -axo pid,pcpu,time,comm -r | head を使うと、現在の使用率で CPU を多く消費しているプロセスを一覧できます。

ステップ3:Arcade の日付を読み取る

症状ではなく報告されている原因のほうを確認するため、これが決定的なテストです。phobox360 プロジェクトのディスカッションに、ロケールに依存せずに値を読む方法が示されています。キーは com.apple.appstored ドメインにあり、plutil で読み取ると値は ISO 8601 形式で返ってきます。

plutil -extract ArcadePayoutResetDate raw ~/Library/Preferences/com.apple.appstored.plist
defaults read com.apple.appstored ArcadePayoutResetDate
date -u +"%Y-%m-%dT%H:%M:%SZ"

1つ目のコマンドは、保存されている日付を 2026-09-26T22:00:00Z の形式で出力します。2つ目は同じ値をロケール設定を通して出力するため読みやすい反面、スクリプトの作者たちが見つけたとおり、12時間制のロケールでは表示形式が異なることがあります。プログラムで比較するつもりなら1つ目を使ってください。3つ目は同じ形式で現在時刻を出力するので、目で見比べられます。

結果の読み方は次のとおりです。

保存されている日付が過去(現在の UTC 時刻より前)で、かつ dasd と appstoreagent が忙しい場合:報告されているバグに一致します。
保存されている日付が未来で、プロセスが静かな場合:あなたに起きているのはこのバグではありません。
保存されている日付が未来なのに、プロセスがまだ忙しい場合:ほかの何かが起きているか、公開されていない原因でループしています。後述のプロセス表を使ってください。
**キーが存在しない場合:**アプリがまだ作成していないだけで、どちらとも判断できません。App Store や Apple Arcade を一度も起動したことのない Mac には、キーがないことがあります。

何かを変更する前に、この出力を保存してください。元の値の記録になります。

ステップ4:正確な述語で統合ログを確認する

「毎秒70〜100回」という主張は、ログで確かめられます。macOS の log コマンドは NSPredicate のフィルタを受け付け、process == "name" という短縮形は log の man ページに記載されています。dasd の直近数分間を1行のコンパクトな形式で表示するには、次のようにします。

log show --predicate 'process == "dasd"' --last 5m --style compact | head -50

1分間に何行書き込まれたかを数えると、おおよその頻度がわかります。

log show --predicate 'process == "dasd"' --last 1m --style compact | wc -l

正常な Mac では、この数値は控えめです。このバグが発生していれば、大量のログが出ます。報告では、ループによって統合ログが大量に出力されるとされています。スケジューラのサブシステムで絞り込むことも、タスク名を直接検索することもできます。

log show --predicate 'subsystem == "com.apple.duetactivityscheduler"' --last 2m --style compact | head -50
log show --predicate 'eventMessage CONTAINS "ArcadeResetPO"' --last 2m --style compact | head -50

タスク名によるフィルタがもっとも的を絞れます。ArcadeResetPO が1分間に数十回現れるなら、報告されているバグが確認できたことになります。事後ではなくリアルタイムで見たい場合は、同じ述語で log stream を使います。

log stream --predicate 'eventMessage CONTAINS "ArcadeResetPO"' --style compact

停止するには Control-C を押します。注意点が2つあります。1つ目は、このバグのある Mac で、緩い述語のまま数時間分の log show を実行しないことです。ログが膨大になり、コマンドが極端に遅くなります。期間は短くしてください。2つ目は、ここで示しているのはドキュメントに基づく構文であって、あなたのログに実際に何が出力されるかの記録ではないということです。メッセージの文言はビルドによって異なる場合があるため、最初のフィルタで何も出ない場合は、バグがないと判断する前にプロセスによるフィルタを試してください。

ステップ5:何が Mac を起こしていたかを確認する

ループが動作しているなら、Mac がそのあいだずっと起きていたのか、それとも起こされたのかも知りたいところです。pmset の2つの読み取りが役立ちます。

pmset -g assertions
pmset -g log | grep -E "DarkWake|Wake "

1つ目は現在の電源アサーション、つまりバックグラウンドタスクやディスプレイを起こしておくプロセスなど、いまスリープを妨げているものを表示します。2つ目は電源ログからスリープ解除の履歴を出力します。各スリープ解除の行には「due to」という理由が付いており、DarkWake は Mac が暗いままバックグラウンド作業を行う部分的なスリープ解除です。マニュアルページは -g log を、管理者やデバッグ用途のための、スリープ、スリープ解除、その他の電源管理イベントの履歴と説明しています。夜間にネットワークやメンテナンスを理由とする DarkWake が続いていれば、スケジューリングの経路が疑われます。完全なスリープ解除が途切れず続いているなら、Mac を起こし続けている何かがあります。これらの行の読み方については、Mac のスリープ問題の総合ガイドで詳しく解説しています。

判断表:どのプロセスがどの原因を示すか

このバグが紛らわしいのは、無関係な十数個のジョブも夜間のバックグラウンド CPU として現れるからです。この表は、アクティビティモニタで見えるものを、もっとも可能性の高い説明に対応付けたものです。Apple のドキュメントと本記事で引用した情報源から作成した診断の補助であり、保証ではありません。

CPU 上位に見えるもの	もっとも可能性の高い原因	正常か問題か	最初の確認
`dasd` と `appstoreagent` の両方が忙しい、多くは午前0時から	報告されている Arcade の日付ループ	問題(報告されているバグ)	ステップ3:`ArcadePayoutResetDate` は過去か
`mds`、`mds_stores`、`mdworker_shared`	Spotlight のインデックス作成	アップグレード後の数時間から数日は正常。いつまでも収まらなければ問題	Spotlight の再インデックスガイド
`photoanalysisd`、`mediaanalysisd`	写真がライブラリをスキャンしている(顔、シーン、物体)	アップグレードや大量の読み込みの後は正常。特に電源接続中	写真を開き、ライブラリの解析状況を確認
`backupd`、`backupd-helper`、`diskarbitrationd`	Time Machine のバックアップ	1時間ごとなら正常。完了しないなら問題	システム設定 > 一般 > Time Machine と、Time Machine のトラブルシューティングガイド
`bird`、`cloudd`、`fileproviderd`	iCloud Drive などのファイルプロバイダが同期中	大規模な同期中は正常。ループしているなら問題	iCloud Drive の状態と、最近の変更のサイズを確認
アイドル中に `powerd`、`kernel_task` が高い	熱管理または電源アサーション	状況による。原因ではなく症状であることが多い	ステップ5とアサーション一覧
`dasd` 単独で、メモリが数GBまで増加	別の `dasd` のメモリ問題。ユーザーの報告を引用するサードパーティのブログが macOS 27 ベータで報告している	問題だが別の問題であり、日付の修正は当てはまらない	アクティビティモニタのメモリタブ
`contactsd`、`peopled`	連絡先ウィジェットと通話履歴データベース	Tahoe 世代の既知の問題	peopled と contactsd のガイド
サードパーティ製アプリまたはそのヘルパー	アプリ自体	そのアプリの問題	終了し、アップデートを確認

この表から、経験則が2つ導けます。1つ目は、組み合わせが重要だということです。dasd 単独は、多くの仕事を振り分けているスケジューラであり、CPU を消費しているのは振り分けられた先のプロセスであることが多いです。決まった時刻に dasd と appstoreagent が揃うのが、報告されているパターンです。2つ目は、時刻が重要だということです。インデックス作成や写真の解析はアップグレード直後にもっとも重く、やがて収まりますが、午前0時に結び付いたループは毎晩繰り返されるはずです。

コミュニティの回避策を1行ずつ解説

MacRumors のメンバーと各解説が行き着いた修正は、設定値を1つ変更するものです。スレッドに投稿された形のものを、スレッドにはない説明を添えて示します。

何かを変更する前に:元の値を保存する

元に戻せるよう、現在の値のコピーを取ります。どちらのコマンドも何も変更しません。

defaults read com.apple.appstored ArcadePayoutResetDate > ~/Desktop/arcade-date-before.txt
defaults export com.apple.appstored ~/Desktop/appstored-before.plist

1つ目は現在の日付をテキストファイルに書き出します。2つ目は com.apple.appstored の設定ドメイン全体を、デスクトップ上のプロパティリストに書き出します。1つ目のコマンドが「does not exist」と表示した場合、キーは存在しないので、1行目は省略できます。

コマンド

MacRumors に投稿され、nix-config の issue でも繰り返されている、7日間版は次のとおりです。

defaults write com.apple.appstored ArcadePayoutResetDate -date "$(date -v+7d -u +"%Y-%m-%dT%H:%M:%SZ")" && killall appstoreagent

分解して見ていきます。

defaults write com.apple.appstored ArcadePayoutResetDate -date "..." は、App Store エージェントの設定の ArcadePayoutResetDate キーに日付の値を書き込みます。-date フラグは、値が文字列ではなく日付であることを defaults に伝えます。
$(date -v+7d -u +"%Y-%m-%dT%H:%M:%SZ") は、その日付をシェルが計算する部分です。date -v+7d は BSD 版の date(macOS のもの)で現在時刻を7日進め、-u は UTC を使い、フォーマット文字列が Z で終わる ISO 8601 のタイムスタンプを生成します。Homebrew の coreutils にある GNU 版の date はフラグが異なるため、パス内のシステムの date を置き換えている場合は、/bin/date として実行してください。
&& は、書き込みが成功した場合にのみ次の部分を実行します。
killall appstoreagent は、実行中の appstoreagent を終了させ、再起動して新しい設定値を読み込ませます。システムが必要に応じてふたたび起動するので、恒久的な停止ではありません。App Store がダウンロードやアップデートの最中であれば中断されるため、何もアップデートしていないときに実行してください。

これは通常のユーザーとして実行し、sudo は使わないでください。この設定はあなたのアカウントに属しており、phobox360 プロジェクトも、利用者に sudo なしで実行するよう明示的に指示しています。root で設定を書き込むと、エージェントが読み取れないファイルが作られる可能性があります。

期待される結果:再起動から数秒以内に、アクティビティモニタで dasd と appstoreagent がほぼゼロまで下がるはずです。このコマンドを最初に記録した解説は、修正が即座に効くと述べています。ただしこれは1人のユーザーが報告した結果であり、あなたの Mac で同じになるとは約束できません。

何が変わり、何が変わらないか

変わるのは日付1つだけです。 何も削除されず、システムファイルにも触れず、保護機能も無効化されません。com.apple.appstored はごく普通のユーザー単位の設定ドメインです。
日付が古いままになるバグそのものは直りません。 スケジューラがタスクを期限切れと見なさなくなるよう、期限を手の届かない先へ動かすだけです。報告者たちは、Apple が本当の修正を出すまでの回避策と説明しています。
Apple Arcade のサブスクリプションやゲームに影響するとは知られていません。 関係するタスクは、開発者向け支払いのリセットと説明されています。ただし、日付を大きく先へ動かしたときに Arcade の管理処理がどうなるかを検証した人は、まだ公表していません。スクリプトの作者も、より積極的な2035年のオプションについて同じことを述べています。Arcade をよく使うなら、短い7日間の設定を選んでください。

明るい自宅の仕事部屋で、薄い銀色のノートパソコンにコマンドを入力し、ほっとした表情を浮かべる若い男性。ぼかされた画面にはシンプルなターミナルのウインドウが映っている

日付の選び方:7日か、数年か

nix-config の解説は 2099-01-01T00:00:00Z を使っており、これはタスクを事実上永久に棚上げします。

defaults write com.apple.appstored ArcadePayoutResetDate -date "2099-01-01T00:00:00Z"
killall appstoreagent

こうすれば毎週修正を繰り返す必要がなく、「App Store の機能を損なうことなく」タスクを長期的に棚上げできると報告されていますが、この説明は報告者のものであり、Apple が確認したものではありません。phobox360 のスクリプトの任意の恒久モードは2035年を使い、Arcade の管理処理への影響は独立に確認されていないという明示的な警告が付いています。当サイトの推奨は、事実ではなく判断ですが、まず7日間から始めることです。うまくいけば、診断が正しかったことを低リスクで確かめられ、さらに進むかどうかは後で決められます。

元に戻す方法

戻す方法は2つあります。必要になる前に両方を知っておくと安心です。

**保存した値を復元する。**元の日付を保存してあり、それが有効な過去の日付だった場合、書き戻すと以前の状態、つまりループのある状態に戻ります。実際にこれを行うのは、テストのため、または Apple へのバグ報告用にきれいな状態を渡すためだけでしょう。テキストファイルにある ISO 形式の文字列を使ってください。

defaults write com.apple.appstored ArcadePayoutResetDate -date "2026-09-26T22:00:00Z"
killall appstoreagent

例の日付は、ご自身が保存した値に置き換えてください。

**キーを削除する。**上書きを取り除き、保存された値がない状態でエージェントを起動させます。

defaults delete com.apple.appstored ArcadePayoutResetDate
killall appstoreagent

キーの削除は、設定を初期値に戻すための defaults の標準的な方法です。macOS 27 でキーがないとき App Store エージェントがどう動作するかは文書化されておらず、有効な新しい日付を作り直すかもしれませんし、バグのある日付を作るかもしれません。キーを削除してもループが戻る場合は、回避策をもう一度適用してください。

スクリプトという選択肢と、その信頼度

dasd-arcade-loop-fix リポジトリは、同じ変更を、ドライラン、確認プロンプト、元の値の自動バックアップ、ロールバックコマンド付きのスクリプトにまとめています。執筆時点ではスターもフォークもほとんどない小さなプロジェクトで、広くレビューされてはいません。妥当な考え方は、実行前にスクリプトを読むか、あるいは同じことを全体が見える形で行う上記の1行コマンドを使うことです。スクリプトを使う場合、文書化されているフラグは、ドライラン、既定の1週間の延期、そして --rollback です。プルリクエストでは、defaults read の日付の出力形式が原因で12時間制のロケールで異常終了する問題が修正されており、設定の出力を解析するシェルスクリプトが壊れやすいことをよく示しています。

やってはいけないこと

**dasd を kill しないでください。**root が所有しており、launchd が即座に再起動します。スケジューラを kill しても直りません。タスクが期限切れになっている理由も解決しません。
**appstoreagent を恒久的な措置として kill -STOP したりアンロードしたりしないでください。**6月の解説は、ベータ版では他に効く手がなかったため kill -STOP を使いました。これはプロセスを一時停止するので、kill -CONT で再開するまで App Store のアップデート、ダウンロード、ライセンス確認が止まります。
**システム整合性保護を無効にしたり、/System のファイルを編集したりしないでください。**どの報告でも、そのようなことは必要ありません。
**自動アップデートを切るだけで直ったことにしないでください。**MacRumors の返信の1つがこれを提案しており、エージェントが起動する頻度は減るかもしれませんが、報告されている原因には対処できません。タスクは Arcade の支払いリセットであって、アップデートの確認ではないからです。また、App Store アプリのセキュリティアップデートが自動で届かなくなります。テストのために切った場合は、元に戻してください。

なぜ再発するのか、どう対処するか

7日間のコマンドを使った場合、書き込んだ日付は本物の有効な日付になり、その日が過ぎるまでスケジューラは満足します。その日が過ぎると、古い日付の状態がふたたび起こり得ます。報告によれば、約1週間後にループが再発することがあります。仕組みは、バグの説明から予想できるとおりです。修正は期限を動かしているだけで、期限を正しく進められないバグはまだ残っています。

選択肢は2つあります。

**毎週コマンドを繰り返す。**カレンダーにリマインダーを設定します。手間が少なく、Arcade の状態を正常に近く保てます。
**ずっと先の日付を使う。**2099年の形式なら手間が省けます。トレードオフは前述のとおり、Arcade の管理処理に対する検証の少ない領域に入ることです。

macOS 27.0.1 で修正されたのか

わかりません。推測で答えるより、そう伝えるほうがよいと考えます。

確認できること:Apple は9月28日に macOS 27.0.1 をリリースしました。The Eclectic Light Company の記事によると、新しいビルド番号は 26A434 で、アップデートは「詳細不明の不具合と、Platform SingleSignOn に影響する不具合の1件を修正しているようだ」とされ、公開されているセキュリティリリースノートはありません。この記事は、CPU、バッテリー、App Store、Apple Arcade については何も述べていません。

スレッドが示していること:27.0.1 が出た後、最初の投稿者は「これは macOS 27.0.1 で修正されたのだろうか」と書きました。続く返信は別のバグ、つまりファイル拡張機能のローカルネットワーク権限の問題についてで、そちらは修正されていないと確認しています。スレッドの中に、Arcade のループについて修正の前後の結果を報告している人はいません。

したがって、正直な立場は、どちらの方向でも未確認だということです。また、リリースノートが曖昧なことはよくあるため、記載がなくても修正が含まれている可能性はあります。

自分の Mac で有益な証拠となる形で確かめる方法は次のとおりです。

27.0.1 にアップデートします(システム設定 > 一般 > ソフトウェアアップデート)。
回避策を適用する前に、ステップ3を実行して ArcadePayoutResetDate を読み取ります。
すでに回避策を適用している場合は、設定した日付が過ぎるまで待つか、前述のとおりキーを削除して再起動し、午前0時をまたいで様子を見ます。
翌朝、top またはアクティビティモニタを確認し、タスク名の述語でログを読みます。
結果を MacRumors のスレッドに投稿します。それを読んでいるのは、答えを必要としているのと同じ人たちです。

夜間の発熱とバッテリー消費で除外すべきほかの原因

dasd が犯人だったとしても、単独犯とは限りません。アップグレードは一連の追い込み処理を引き起こすため、複数の問題が同時に起きているのはよくあることです。Arcade のループがすべてだと結論づける前に、次の項目を確認してください。

アップグレード後の Spotlight と Siri のインデックス作成

大型アップグレードの後、macOS は検索インデックスの一部を再構築し、それが mds、mds_stores、mdworker_shared として現れます。予期しないスリープ解除に関する Apple 自身のガイダンスには、Spotlight がディスクのインデックスを作成していると Mac はスリープしない、と記されており、スリープできない Mac は熱を持ち、夜間にバッテリーを消耗します。インデックス作成には終わりがあります。数時間、大容量のドライブでは1〜2日ほど激しく動作し、その後落ち着きます。Arcade のループは落ち着きません。macOS 27 後の Spotlight 再インデックスのガイドでは、「まだ作業中」と「止まっている」の見分け方を扱っており、macOS 26.6 に関する以前の報告では、Siri のインデックスで同じパターンが見られたことを示しています。

写真の解析

photoanalysisd と mediaanalysisd は、写真ライブラリを走査して人物、シーン、物体を認識します。アップグレードや読み込みの直後にもっとも重くなり、終われば止まります。開始する決まった時刻はありません。Mac を一晩電源につないだままにして、負荷が数晩のうちに落ち着くかどうかを見てください。

Time Machine

Time Machine のバックアップは、同じスケジューラを通して実行されます。Oakley 氏の解説には、5分間の待機が必要なため起動直後の数秒間に DAS がバックアップを見送る例が示されており、条件が働いている一例です。アップグレード後の最初のバックアップや、低速なネットワーク上の保存先へのバックアップは、数時間かかって Mac を熱くすることがあります。backupd が忙しいプロセスなら、Time Machine のトラブルシューティングガイドが参考になります。また、Oakley 氏のバックアップのスケジューリングとディスパッチに関する記事では、バックアップが妙な時刻に始まる理由が説明されています。

Power Nap と「ネットワークアクセスによるスリープ解除」

Apple のスリープとスリープ解除の設定に関するページには、Power Nap を使うと Mac がスリープ中に自身を更新でき、「ネットワークアクセスによるスリープ解除」を使うと、ほかのユーザーが共有サービスにアクセスできるよう Mac が短時間スリープを解除する、と書かれています。ノートブックでは、どちらもシステム設定 > バッテリー > オプションにあります。Apple の予期しないスリープ解除のページは、対処案として、ネットワークアクセスによるスリープ解除の無効化と共有サービスの停止を挙げています。pmset のマニュアルページによると、womp は「ネットワークアクセスによるスリープ解除」に相当するターミナルの設定で、powernap は対応機種で有効です。Power Nap の利用可否は機種によって異なるため、表示されなくても驚かないでください。

現在の値を変更せずに確認するには、次のようにします。

pmset -g | grep -E "powernap|womp"

pmset -g log で夜間に定期的な DarkWake が見られるなら、両方をオフにしてみるのは妥当な実験です。Mac が起きているあいだ、またはメンテナンスのためのスリープ解除中に発生する Arcade のループは直りませんが、診断のノイズは取り除けます。何が効いたかを判別できるよう、変更は一度に1つだけにしてください。

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

コマンドの後もプロセスが忙しいまま

症状:defaults write と killall を実行したのに、dasd と appstoreagent がまだアクティビティモニタの上位にいる。

原因:いくつかの可能性があります。killall が一致せず、古い日付をキャッシュした古いプロセスがまだ動いているのかもしれません。ドメインの入力ミスなどで、書き込みが黙って失敗した可能性もあります。あるいは、まったく別の原因を見ているのかもしれません。

解決策:

plutil -extract ArcadePayoutResetDate raw ~/Library/Preferences/com.apple.appstored.plist で値を読み戻し、未来であることを確認します。
killall appstoreagent をもう一度実行し、アクティビティモニタでプロセスが新しい PID で再起動したかを確認します。
タスク名の述語でログを1分間確認し直します。ArcadeResetPO が現れなくなったのに CPU がまだ高いなら、原因はほかにあります。上のプロセス表が次の確認先です。

plutil -extract ArcadePayoutResetDate raw ~/Library/Preferences/com.apple.appstored.plist
pgrep -l appstoreagent

それでも解決しない場合:Mac を一度再起動してください。再起動により、キャッシュされた設定や、スケジューラの固まった状態が消去されます。再起動後も日付が有効で負荷が残るなら、別のバグとして扱い、助けを求める前にステップ2とステップ4の出力を集めてください。

1週間後にループが戻ってくる

症状:1週間は静かだったのに、午前0時の急上昇が戻ってくる。

原因:設定した7日間の日付が過ぎ、根本のバグがまだ残っています。

解決策:コマンドをもう一度実行するか、前述のようにもっと先の日付を選んでください。繰り返したくないなら、Arcade の管理処理への影響が文書化されていないことを踏まえたうえで、長い期間を選ぶと判断してください。

プロセスは静かなのに夜間のバッテリー消費が続く

症状:dasd と appstoreagent はゼロなのに、バッテリーが減り続ける。

原因:スリープ中の発熱や消耗は、CPU ではなく、スリープ解除やアサーションが原因であることがよくあります。

解決策:夜間の時間帯について pmset -g log を読み、Mac が何回、なぜスリープ解除されたかを確認します。pmset -g assertions で、スリープを妨げているものがないかを確認します。よくある原因は、Mac のスリープ問題の総合ガイドと macOS Tahoe のバッテリー消耗ガイドで解説しており、バッテリーデータの読み方をさらに深く扱うのが高度なバッテリー診断ガイドです。

FAQ

macOS 27 で dasd と appstoreagent が大量の CPU を使うのはなぜですか?

MacRumors のメンバーや独立した解説の報告によると、Apple Arcade のタスク ArcadeResetPO が保存された日付を過去のままにしているため、スケジューラがそれを絶えず再実行しており、頻度は毎秒70〜100回に達する可能性があります。Apple は確認していません。パターンは、多くは午前0時から始まる1コアの張り付きで、発熱とバッテリー消費の増加を伴います。

ArcadePayoutResetDate に対して defaults write コマンドを実行しても安全ですか?

変更するのはユーザー単位の設定1つだけで、システムファイルには触れず、キーの削除や保存した値の復元で元に戻せます。これはコミュニティの回避策であり、Apple のガイダンスではなく、長期間にわたる Arcade の管理処理への影響は文書化されていません。先に元の値を保存し、短い期間を選んでください。

macOS 27.0.1 で dasd と appstoreagent のループは修正されましたか?

確認できませんでした。Apple の 27.0.1 アップデート(ビルド 26A434)は、詳細不明の不具合と Platform SSO の問題1件を修正すると報じられており、この件への言及はありません。これについて尋ねた MacRumors の唯一の投稿には、別のバグに関する返信が付きました。午前0時をまたいで日付を読み取り、ご自身の Mac で確かめてください。

Spotlight や写真ではなく、このバグだとどうすればわかりますか?

保存されている日付を plutil で読み取り、現在の UTC 時刻と比較します。dasd と appstoreagent が忙しいのに日付が過去で、ログに ArcadeResetPO タスクの繰り返しが見えるなら、このバグです。Spotlight は mds プロセスとして、写真は photoanalysisd として現れ、午前0時という決まった開始時刻はありません。

1週間後に問題が戻ってくるのはなぜですか?

回避策はリセット日を1週間先に動かします。その日が過ぎると、日付を進められない根本のバグが再び発生し、ループが戻ります。報告者は約1週間後に再発すると述べています。毎週コマンドを繰り返すか、先の日付を選ぶこともできますが、長い日付は検証が少ない点を受け入れる必要があります。

App Store の自動アップデートを無効にすれば止まりますか?

MacRumors の返信の1つは、プロセスが静かになると述べていますが、報告されている原因は、アップデートの確認ではなく Arcade の支払いタスクなので、対処にはなりません。また、App Store アプリの自動アップデートが届かなくなります。修正ではなく、試してみるトレードオフとして扱い、効果がなければアップデートを再度オンにしてください。

dasd や appstoreagent を kill してもよいですか?

appstoreagent を kill すると急上昇は一時的に止まりますが、システムが必要に応じて再起動し、古い日付は残っているため、ループが再開します。dasd は root が所有するスケジューラで、launchd が即座に再起動します。appstoreagent を kill -STOP で凍結すると動作しますが、再開するまで App Store のアップデートとライセンス確認が止まります。

修正は Apple Arcade のゲームやサブスクリプションに影響しますか?

公開されている報告にそのような記述はありません。タスクは開発者向け支払いのリセットと説明されており、回避策が変更するのは日付1つだけです。ただし、日付を何年も先へ動かした場合のテスト結果は公表されておらず、スクリプトの作者も、Arcade の管理処理への影響は確認されていないと明言しています。Arcade を遊ぶなら、短い期間を使ってください。

まとめ

macOS 27 で Mac が夜間に熱くなりバッテリーが尽きる背景には、増えつつある報告によれば、スケジューラのループがあります。dasd が振り分け、appstoreagent が再登録を続ける、日付が先へ進まない Apple Arcade のタスクです。何も変更せずに確認するのは簡単で、保存されている日付を読み、UTC と比較し、ログでタスク名を探します。日付が過去なら、1行のコミュニティの回避策でループがすぐに止まると報告されており、元に戻すのも容易です。

期待は現実的に保ってください。これは、長い日付を許容しないかぎり繰り返しが必要な回避策であり、Apple は認めておらず、27.0.1 やその後のアップデートで修正されるとも言えません。日付の確認で問題が見つからなかった場合は、診断を無理に当てはめず、上の判断表を使って、Spotlight、写真、Time Machine、iCloud、スリープ解除の設定を1つずつ確認してください。

さらに詳しく知りたい方へ。アップグレード後に Mac が熱くなる原因としてもっとも多い正当なものは、Spotlight 再インデックスのガイドで扱っており、スリープ解除やアサーションの問題は Mac のスリープ問題の総合ガイドで扱っています。別のプロセスが原因なら、peopled と contactsd のガイドが当てはまるかもしれません。そして、27.0.1 でお使いの Mac に何か変化があったかどうかがわかったら、MacRumors のスレッドの人たちに教えてあげてください。

ご質問やお役に立つヒントがありましたら、ぜひ下のコメント欄でお聞かせください。

関連ツール: Mac 互換性チェッカー - お使いの Mac が特定の macOS バージョンに対応しているか確認できます。