Local の Intel バイナリを1,285件から217件に減らした。残ったのは毎日使っている PHP だった

Apple Silicon の Mac に乗り換えたあと、自分の開発環境から Intel のバイナリはどれだけ消えたのか。数えてみたら、1,285件ありました。

そのうち1,068件は消せました。残る217件は、消せません。使っているものの中に入っているからです。bin/darwin/bin/php を file に通したら Mach-O 64-bit executable x86_64 と返ってきた瞬間が、この作業でいちばん手が止まったところでした。毎日書いている WordPress のコードは、Rosetta の上で動いていたことになります。

以下は、その前後の記録です。環境は MacBook Pro（M5 Pro）、macOS 26 Tahoe、移行アシスタントで前の Intel 機から引き継いだもの。対象は Local by Flywheel（LocalWP）です。

「もう消した」と思っていた

Homebrew は入れ替え済みでした。which -a brew が返すのは /opt/homebrew/bin/brew の1本だけで、PATH に Intel 版は残っていません。この作業は乗り換えた直後に済ませていて、それで環境の移行は終わったつもりでいました。

今月の頭にディスク全体を走査したとき、Intel バイナリが3,661件あって、そのうち2,544件が Local だと分かっています。そのときに古い PHP をいくつか消した記憶があったので、もう大半は片づいていると思っていました。

念のため ls を叩きました。

31個、全部残っていました。消した記憶のほうが間違っていたわけです。

数えてみる

Local が各サービスを置いているのは ~/Library/Application Support/Local/lightning-services です。この下を find で歩いて、実行可能なファイルを file に通し、x86_64 だけのものを拾いました。Universal（x86_64 と arm64 の両方を持つもの）は除いています。

1,285件でした。合計の容量は 6.2GB。系統ごとの内訳を出すと、こうなります。

PHP が20系統ありました。5.6.39 から 8.4.18 まで。8.3 系だけで 8.3.0、8.3.11、8.3.17、8.3.23 の4つ。php-7.4.30 に至っては +5 と +6 の枝番違いが両方あって、合わせて315MB です。同じ 7.4.30 なのに。

私が実際に使っているのは、PHP 8.3.23 の1系統だけです。全サイトをそこに統一してあります。MySQL は 8.0.35 と 8.4.0、Web サーバーは全部 nginx で Apache は使っていません。

つまり6.2GB のうち、大半は要らないものでした。Local はバージョンを上げるたびに新しいサービスを取ってきますが、古いほうを消しません。消さないこと自体は正しい判断だと思います。サイトごとに PHP を変えられるのが Local の売りなので、勝手に消されると困る人がいる。ただ、消していいかどうかを利用者が判断する材料は、UI のどこにも出てきません。

消したら壊れるのか

削除ではなく退避にしました。使っていない26個を、ホーム直下のバックアップ用フォルダへ mv で移します。残したのは php-8.3.23+0、mysql-8.0.35+4、mysql-8.4.0、nginx-1.26.1+3、mailpit-1.24.1+0 の5つだけ。Local は終了させてから作業しました。

起動して、全サイトを立ち上げて、管理画面まで開いて確認しました。壊れませんでした。エラーも出ず、サイトの起動も普段どおりです。使っていないサービスは、本当に使われていなかった、という当たり前の結果です。

数え直すと、こうなりました。

1,285件が217件に。6.2GB が1.8GB に。1,068件、約4.4GB が減った計算です。ディスクが4GB空くのは、それはそれで嬉しい。

余談ですが、退避したフォルダはしばらく置いておくつもりです。すぐ消せば4GB戻ってくるのですが、この記事を書いている最中に「あのバージョンの挙動を確かめたい」と思う場面が出てきそうな気がしていて、まだ踏み切れていません。バックアップを取る心理と、捨てられない心理は、たぶん地続きです。

残った217件は、どこにあったのか

ここからが本題でした。消えなかった217件の内訳は、php-8.3.23 に135件、mysql-8.0.35 に81件、nginx に1件。全部、いま使っているものの中です。

php-8.3.23 の135件が何なのかを見にいきました。

1行目です。php そのものが x86_64 でした。拡張だけが取り残されているのだろう、という予想は外れていて、本体からして Intel 向けのバイナリです。php-fpm も、Ghostscript の gs も、imagick も xdebug も opcache も、ImageMagick の coders 群も、ひとつ残らず x86_64。

Local でサイトを開くたび、PHP は Rosetta 経由で動いていたことになります。M5 Pro に乗り換えて、Homebrew を /opt/homebrew に入れ替えて、PATH を整えて。それでも、いちばん時間を使っている作業そのものは Intel のままでした。

気づかなかったのは、動いてしまうからです。Rosetta は速い。プラグインを書いて、ブラウザで確かめて、また書く。この往復で違和感を覚えたことは一度もありませんでした。壊れていれば分かる。動いていると、分からない。

Local も移行の途中だった

もうひとつ、見ていて気づいたことがあります。残った5つのうち、mysql-8.4.0 と mailpit-1.24.1+0 は x86_64 が0件でした。つまり arm64 ネイティブです。

一方で mysql-8.0.35 は81件が x86_64。同じ Local が配っている MySQL でも、8.4.0 は arm64 で、8.0.35 は Intel のまま。新しいバージョンから順に置き換わっていて、PHP にはまだ順番が回ってきていない、という状態のようです。Local 側の告知を追いきれていないので、そこは推測です。

そう考えると、私にできることは限られています。使っていないものを消すのは自分でできる。けれど php-8.3.23 の135件は、Local が arm64 版を配ってくれるまでどうにもならない。自分で PHP をビルドして差し替える手はありますが、Local の管理下にあるものを手で入れ替えると、次のアップデートで戻される可能性が高い。別の記事で書いた Dropbox の更新ヘルパーと、構造は同じです。配る側が置き直すものを、受け取る側が手で直しても続きません。

期限のほうは待ってくれない

Apple の説明によると、Rosetta は次のメジャーリリースである macOS 27 までは引き続き使えて、macOS 28 以降はメンテナンスされていない一部の古いゲームだけに残るそうです。macOS 27 が今年の9月、macOS 28 は2027年の秋の予定です。

1年あります。Local の中の人が PHP を arm64 で配り直すのに、1年は十分な時間だと思います。たぶん間に合う。ただ、間に合わなかったときに困るのは私のほうで、そのときになって慌てても打てる手は多くありません。

だからいま数えておいたのは、無駄ではなかったと思っています。前に一度、手元の Mac にどれだけ Intel バイナリが残っているかを棚卸ししたときは、アプリの数を数えて終わりにしていました。開発環境の中まで開けていなかった。数え方を変えると、見えるものが変わります。

ついでに、隣も開けました。/usr/local が3.2GB 残っていたのが、ずっと気になっていたからです。

Homebrew の残骸だと思っていた3.2GB

/usr/local/Homebrew も /usr/local/Cellar も、もう存在しません。Homebrew はきちんと消えています。それなのに3.2GB ある。Intel 時代のアンインストーラが消しきれなかったものだろう、と思っていました。

同じ要領で数えると、/usr/local/lib の下に x86_64 が586件。Local の217件より多い。ただし内訳を見ると、Homebrew 由来と言えるものは、リンク先が消えた壊れたシンボリックリンクが5本だけでした。brew.1 の man ページ、zsh と fish の補完ファイル、doc のリンク。容量はゼロに近い。

3.2GB の正体は、Homebrew ではありませんでした。

sfdx は Salesforce CLI の 7.150.0。同梱している Node が v16.13.1 で、とうに EOL です。案件はもう終わっています。python3.9 と 3.10 の中身は albumentations、cv2、Cython、easydict。/usr/local/insightface も残っていたので、当時の顔認識の実験環境がそのまま化石になっていたわけです。しかもこの2系統には、呼び出し口がありませんでした。/usr/local/bin に python 系のリンクが1本も無い。909MB あるのに、起動する手段が存在しない。

n は Node のバージョン管理ツールで、17.9.0、18.15.0、24.2.0 の3本が入っていて、全部 x86_64 でした。ただし which -a node が返すのは /opt/homebrew/bin/node だけ。Homebrew に乗り換えた時点で n は PATH から外れていて、誰も呼んでいません。

Trolltech は Qt 4 の残骸です。Trolltech という社名は2008年に消えています。

node_modules に、知らないパッケージが3つ

グローバルの node_modules を眺めていて、目が止まりました。to、update、upgrade。3つ並んでいます。

to は実在のパッケージでした。xml、json、yaml を相互変換するツールで、バージョン 0.2.9。2013年頃のものです。使った記憶はありません。

断定はできませんが、npm install -g npm to update のような案内文を、そのまま打ったのだと思います。npm が出す「To update, run: …」の途中の単語が、たまたま実在するパッケージ名だったので、エラーにならずに入る。update と upgrade も揃っているのは、偶然にしては出来すぎです。

10年以上前のタイプミスが、移行アシスタントで新しい Mac まで運ばれてきていました。

数えたあとの数字

使っていないものを別のディスクへ逃がしました。sfdx、Python の2系統、n、Trolltech、insightface、それに MySQL 公式インストーラのデータディレクトリ。壊れたリンクも消しました。

93%減。容量は3.2GB が682MB になりました。Local と合わせると、1,871件が259件、9.4GB が2.5GB です。

ここで、性質の違いがはっきりしました。Local に残った217件は、使っているから消せません。対して /usr/local から消えた544件は、ほぼ全部が使っていないものでした。終わった案件の CLI、当時の実験環境、乗り換えて不要になったバージョン管理ツール、消えた社名のフォルダ、そしてタイプミス。

片方は Local が arm64 版を配ってくれるまで待つしかない。もう片方は、いつでも消せたのに、開けてみるまで存在すら知りませんでした。移行アシスタントは、その両方を同じように運んできます。中身が要るかどうかは、判断しません。

残した42件には JPKI が含まれています。マイナンバーカードを読むためのもので、確定申告の時期に使う可能性がある。使うかどうか分からないものを残す判断は、これはこれで、また同じ層を作っているのかもしれません。

あなたの Mac の /usr/local には、何が入っていますか。

関連記事

• DropboxMacUpdate だけが Intel のまま残っていた ── バンドルの中の原本は Universal なのに、展開された実体だけが Intel だった話です。
• 手元の Mac に Intel バイナリがどれだけ残っているか棚卸しした ── アプリ単位で数えたときの記録です。
• Parallels の中身は Intel だらけだった ── 仮想環境の側で見つかった残骸の話です。