【macOS】DropboxMacUpdate だけが Intel のまま残っていた

朝、コーヒーを机に置いて、Local を立ち上げようとしたところで手が止まりました。灰色のパネルが出ています。プラグインの続きに入る前に、これを片づけないといけない。

そのあとの30分を、私は新しい DropboxMacUpdate を探すことに使いました。存在しないものを、です。Dropbox のダウンロードページを開き、ヘルプセンターを検索し、それらしいリンクがないかを見て回りました。出てこないのが正しかったと分かるのは、もう少しあとになってからです。

警告の中身はこうです。Dropbox 本体は arm64 で動いているのに、更新ヘルパーだけが x86_64 のまま ~/Library/Dropbox/ に居座っている。そして新しい DropboxMacUpdate をどこかから落としてくることはできません。あれは単体では配られていないので、消してから入れ直すしかない。

探しても出てこないのが正しかった

DropboxMacUpdate は、Dropbox デスクトップアプリに同梱された裏方のプロセスです。Dropbox のヘルプにも、サポート対象の macOS にデスクトップアプリを入れると一緒に入る、と書いてあります。単体のダウンロードリンクを探すのは、libsystem_kernel.dylib の最新版をどこかからダウンロードしようとするのと同じで、そもそも配布の単位が違う。分かってしまえば当たり前の話なのですが、警告に「このバージョンの DropboxMacUpdate」と書かれていると、つい「では新しいバージョンはどこに」と考えてしまいます。警告文の主語が、利用者が手を出せる単位と一致していない。

ここからが厄介でした。Dropbox 本体を最新版に入れ替えても警告は消えない、という報告が Dropbox フォーラムに何件も上がっています。しかも消えない理由が、素直に想像するものと違いました。

原本は Universal で、展開された実体だけが Intel だった

XRom さんという方が投稿していた file の出力が、いちばん分かりやすい。

アプリバンドルの中に入っている原本は Universal です。両方のアーキテクチャを持っている。ところが、そこから ~/Library/Dropbox/ へ展開された実体だけが x86_64 で固まっている。つまりバンドルをいくら調べても正解は出ず、展開先を見ないと分からない。XRom さんは Dropbox を捨てて ~/Library/Dropbox の中身も消してから 250.4.3245 を入れ直したそうですが、それでも展開されたのは x86_64 のほうだったと書いています。ここを読んだときに、これは自分の手順が悪いのではないのだと少し安心して、同時に、では何をすれば直るのかが分からなくなりました。

私は AppCleaner を使って、Dropbox 本体と関連ファイルをまとめて捨ててから入れ直しました。手で場所を探して消すのではなく、関連ファイルの検出を任せた形です。結果はこうなりました。

直っています。惜しいことに、直す前の出力を取っていませんでした。警告を消すことを先に考えてしまって、記録を残す発想が後から来た。この記事でいちばん欲しかった一行を、私は自分で捨てています。

削除の順番

解決を報告していたのは、Dropbox のサポートではなく jmsdkjd さんという一般の利用者でした。手順そのものは拍子抜けするほど単純です。Dropbox を終了して /Applications/Dropbox.app を捨てる。次にアップルメニューからシステムレポートを開いて、ソフトウェアのアプリケーション一覧で種類が Intel になっている Dropbox 関連を全部探す。一覧で項目を選ぶと下のペインに実際のパスが出るので、そこへ行って .app を消す。それから入れ直す。

順番を守らないと直らない、というのがこの手順の勘所です。jmsdkjd さんは、インストーラが既存の更新ヘルパーを見つけると置き換えず、消えていれば入れる、という挙動をしているのではないかと推測しています。私も同じ読みです。断言はしませんが、XRom さんの再現手順と噛み合いますし、AppCleaner でまとめて消してから入れ直した私の環境で直ったことも、同じ向きを指しています。消してから入れる、という順番が効くということは、インストーラ側に「既にあるなら触らない」という分岐が入っている可能性が高い。

出てくる場所は、報告を見るかぎり2つでした。

Intel 版を返すダウンロードリンク

もうひとつ、途中で踏み抜きやすい穴があります。kentbrew さんの報告によると、dropbox.com/downloading?full=1&os=mac から取れる dmg は Intel 版だったそうです。せっかく残骸を消しても、入れるものが Intel 版なら振り出しに戻る。Dropbox のモデレーターは、コミュニティの Dropbox Desktop Client Builds に全ビルドが並んでいると案内していました。arm64 のオフラインインストーラはそこから取るのが確実です。

余談として、サポートとのやりとり

この kentbrew さんのやりとりが、読み物としてなかなかきつい。サポートとメールを往復した末に、返ってきたのは新しいユーザープロファイルを作ってそちらを使ってください、という案内で、そのままチケットを閉じられています。移行アシスタントで環境を運んできた意味が消える回答です。そのあとに一般ユーザーの投稿で直った、という順番になっている。同じスレッドで、iTerm2 でも同じ警告が出たとも書いていました。iTerm2 は長いこと Universal のはずなので、移行アシスタントの側にも何かありそうです。

私の Mac も移行アシスタントで引き継いだ個体です。M5 Pro の MacBook Pro で、本体は新しい。それでも ~/Library/ の中身は前の環境から運ばれてきていて、そこに古い実体が残っていた。新しいインストーラが「既にある」と判定し続けるのだとしたら、機種を買い替えても症状は付いてきます。断定はできませんが、条件は揃っています。

数え方を変えると、残っている量が変わる

警告が消えたので、ついでに手元の Mac にどれだけ Intel バイナリが残っているのかを数えました。ディスク全体を走査して Mach-O を拾った結果が、3,661件です。

内訳を見て、しばらく画面を眺めることになりました。

7割が Local でした。PHP 5.6.39 から 8.3.23 まで20系統ぶんが入っていて、各系統に ImageMagick の coders が127件から130件、Apache の modules が88件、dylibs が58件から70件。PHP のバージョンを増やすたびに、x86_64 の ImageMagick が1セットずつ積まれていたことになります。Dropbox の更新ヘルパー1つを追いかけていた私の足元に、2,544件が黙って積んであった。

それから Rosetta Check を入れました。バージョンは 2.3.5 (129) で、無料で配られています。アプリと、アプリの中に埋まっているコンポーネントの両方を検査して、ひとつのスコアにまとめてくれます。

主な妨げとして挙がったのは、SurFlex Screen Recorder（440.1MB）、NXPowerLite Desktop（268.7MB）、Uni Detector、それに Auburn Sounds Graillon 2 と Element のオーディオプラグインでした。SurFlex は私の走査でも107件で上位に出ていたので、こちらは一致しています。

ただ、コンポーネントの検出数は36件です。私が数えたのは3,661件でした。Local の2,544件は、Rosetta Check のコンポーネント一覧には出てきません。どちらかが間違っているのではなく、数えているものが違います。Rosetta Check が見ているのはアプリと、オーディオプラグインやシステム拡張のように「アプリに差し込まれる部品」で、開発環境がアプリケーションサポート配下に展開した PHP のバイナリ群は、その枠に入らない。90%という数字は、その枠の中では正しい。

Neil Johnson さんは、Pro Tools や Logic、Photoshop の利用者は長年ためこんだ Intel プラグインが macOS 28 で一晩にして使えなくなる可能性がある、と書いていたそうです。実際、私の Photoshop 2026 の中にも42件ありました。Universal アプリのバンドルを歩いて中の Intel バイナリを探す Deep inspection という機能もあります。ただ、今回の Dropbox のケースは原本が Universal で展開先が Intel という形で、バンドルの中を歩く機能が、バンドルの外に展開された実体まで見に行くとは限りません。私の環境ではすでに直してしまったので、そこは確かめられませんでした。

数え方が3通りあって、3通りとも違う数字を出す。警告を出したのは macOS で、90%と言ったのは Rosetta Check で、3,661件と言ったのは自分で回した走査です。どれを信じるかというより、それぞれが見ている範囲を知っておかないと、片づいたつもりで片づいていない。

配る側の目で読み直す

ここまでは Mac の利用者としての話です。ただ、私は WordPress プラグインを4本配っている側でもあって、そちらの目で読むと、これはかなり肝が冷える事故に見えました。

Dropbox がやってしまったのは、更新のときに既存のファイルを見つけて手を引いた、ということです。バンドルの中の原本はちゃんと Universal に差し替わっている。差し替えの意思はあった。それでも、展開済みの実体には届いていない。配布物の中身を新しくすることと、利用者の環境に置かれた実体が新しくなることは、別の話なんだと思い知らされます。

怖くなったので、自作の4本を全部読み直しました。「既にあれば作らない」という分岐が、どこに何本あるのかを数えたわけです。

いちばん近い形をしていたのは、PDF Image Creator だった

Rapls PDF Image Creator は、PDF の表紙から Imagick でサムネイルを作るプラグインです。Generator.php の205行目あたりに、もう作ってあるかを判定する処理があります。

この hasThumbnail() が見ているのは、post meta の _rapls_pic_thumbnail_id と、添付投稿が存在するかどうかだけです。生成された画像ファイルそのものには file_exists() をかけていません。添付投稿の行さえ残っていれば、画像ファイルがディスクから消えていても「ある」と判定して、再生成しない。$force を渡さないかぎり復活しません。

Dropbox はバンドルの中を見て、展開先を見ていませんでした。私は DB の行を見て、ディスクを見ていなかった。判定のよりどころを実体からひとつズラすと、「あるはず」と「ある」が離れていきます。同じ形です。

同じプラグインでも、ディレクトリ作成は is_dir と wp_mkdir_p で毎回走るので消えても直りますし、設定は読み取り時にデフォルトとマージするので古い設置でも新しいキーが効きます。1箇所だけ、判定の見る先を間違えていた。

一度やられた記録が、コメントに残っていた

Rapls AI Chatbot の Pro 側に、フォントを扱う処理があります。installed-fonts.json を書くところで、「既にあれば作らない」を意図的にやめて、パスが違えば必ず書き直すようになっていました。理由がコメントに書いてあります。同梱している JSON には、ビルドしたマシンの絶対パスが焼き込まれている。そのまま残すと、利用者の環境で日本語が文字化けする。

これは過去に一度噛まれたということです。推測ではなく記録として残っている。すぐ隣にある .ufm の生成は、逆に存在するかどうかだけを条件にしていて、壊れていても作り直しません。同じファイルの中に、痛い目を見て直した箇所と、まだ直していない箇所が並んでいる。

やらかさない側の書き方も、手元にあった

Prime Cache は逆でした。wp-content/advanced-cache.php を書く前に、既存ファイルの中身を読んで所有者を確かめます。自分の署名があれば再生成し、読めなければ触らず、他のキャッシュプラグインが現役で置いたものなら上書きしない。無効化されたプラグインの置き土産だと判定できたときだけ、置き換える。file_exists の真偽だけで決めていません。

そのうえ、管理画面を開くたびに設置物が揃っているかを確認して、無ければ作り直す処理が入っています。有効化のときだけ生成して、消えたら二度と戻らない、という穴を先に埋めてある。Dropbox のインストーラがやらなかったことを、こちらではやっていました。

Thanks Mail for Stripe は、そもそもファイルを一切書きません。ただ、設定は読み取り時に自己修復するのに、テーブルへの列追加だけは有効化のときにしか走らない。同じコードの中で、直る場所と直らない場所が分かれています。

3本の温度差

判定のよりどころを間違えたもの、間違えて直したもの、最初から間違えないように書いたもの。4本を並べて読むと、この3つが揃っていました。書いたのは全部私です。書き方の良し悪しというより、そのとき何を怖いと思っていたかが、そのまま分岐の形になっている。

Apple の説明では、Rosetta は次のメジャーリリースである macOS 27 までは引き続き使えて、macOS 28 以降はメンテナンスされていない一部の古いゲームだけに残るとのことです。macOS 27 が今年の9月、macOS 28 は2027年の秋の予定なので、今すぐ Dropbox が動かなくなるわけではありません。時間はあります。手元の Mac にどれだけ Intel バイナリが残っているかは前に一度棚卸ししていて、そのときは見えていなかった層が、今回で2つ増えたことになります。展開先の実体と、開発環境の中身です。

その時間を、どちらに使うか。自分の Mac から Intel バイナリを狩り出すほうは、数えれば終わりが見えます。3,661件を1件ずつ減らしていけばいい。配っている側としての作業には、終わりが見えません。自分の更新処理が既存があるので何もしないと判断している場所は、数え上げたつもりでも、まだあるかもしれない。今回は4本を読み直して1件見つけました。次に読み直したら、また見つかるでしょうか。