brewをM1のMacで使う｜Intelの頃と入る場所が違う

M1やM2のMacに移ってきた人がbrew m1で検索する理由は、だいたい3つに分かれます。手順書の通りに入れたのに brew: command not found と返る。入ったはずのコマンドが古いほうを指している。あるいは、どこかの記事で「Intel用が入っていると面倒になる」と読んで不安になった。どれも根っこは同じで、Apple Siliconになったときに導入先のディレクトリが変わった一点から派生しています。場所の違いを押さえれば、3つとも自分で切り分けられます。

Apple Siliconでは、入る場所が/opt/homebrewに変わった

Homebrewは、パッケージの実体をprefixと呼ぶ1つのディレクトリの下にまとめます。公式サイトは、このprefixがApple Siliconでは /opt/homebrew、Intel Macでは /usr/local になると明記しています。Linuxとその上のWSLでは /home/linuxbrew/.linuxbrew です。公式の文書も同じ記述で、インストールのスクリプトは既定のprefixへ導入すると書いています。

環境	prefix
Apple Silicon搭載のMac	/opt/homebrew
Intel搭載のMac	/usr/local
LinuxとWSL	/home/linuxbrew/.linuxbrew

この変更が入ったのは、Apple Siliconの登場に合わせてです。/usr/local はIntel時代からmacOSの標準的な共有場所として使われてきましたが、Rosetta 2を通してIntel向けのバイナリも動く環境では、同じディレクトリに2つの系統が混ざる恐れがありました。分けたことで、片方を消しても片方が残る形になりました。

Intel用とApple Silicon用の入れ替えを記録した文章は、この移行が実際に起きていることを示しています。

この記事では、Homebrew（Intel Mac用）を削除する方法とHomebrew（Apple Silicon用）をインストールする方法について記述しています。 出典: zenn.dev

意図せずIntel用を入れてしまい、後から気付いて入れ替える。この順番でつまずく人が一定数いるということです。

なぜApple SiliconではPATHに1行足すことになるのか

Intel時代のMacでは、Homebrewを入れた直後からコマンドが通りました。設定ファイルに何も書かなくても動いたのは、/usr/local/bin がmacOSの標準のPATHに最初から含まれていたからです。macOSはログイン時に /etc/paths を読んでPATHの土台を組み立てており、そこに /usr/local/bin が並んでいます。

/opt/homebrew/bin は、この一覧に入っていません。だから、入れただけではコマンド名だけで呼べません。ここを埋めるための仕組みが brew shellenv です。公式の説明書は、このコマンドがexport文を出力し、実行するとこのHomebrewの導入先が $PATH と $MANPATH と $INFOPATH に追加されると説明しています。$HOMEBREW_PREFIX、$HOMEBREW_CELLAR、$HOMEBREW_REPOSITORY も一緒に設定されます。

説明書は、この出力の評価を設定ファイルに書き足すことを勧めています。macOSなら ~/.zprofile、Linuxなら ~/.zshrc や ~/.bashrc に eval "$(brew shellenv zsh)" の形で書く例が挙げられています。シェルの名前は明示するよう案内されており、省略すると自動判定になりますが、それが正しいとは限らないと注意書きがあります。

この仕組みには便利な性質があります。説明書は、Homebrewのbinとsbinがすでに $PATH の1番目と2番目にあるときは何も出力しないと書いています。重ねて読み込んでも二重にならないため、設定ファイルに書いたまま放置しても副作用が出ません。入れた直後に command not found が出る場合は、この1行が書かれていないか、書いた先のファイルが読まれていないかのどちらかです。

いま動いているbrewがどちらのものかを確かめる

原因を探すときは、推測ではなく事実を1つずつ集めます。確かめる順番は3段です。

1段目は、機械そのものの種類です。arch は引数なしで実行すると機械のアーキテクチャの種類を表示すると説明書に書かれています。指定できる名前の一覧には x86_64 が64ビットのIntel、arm64 が64ビットのarm、arm64e がApple Siliconとして並んでいます。uname -m も同じ用途に使えて、説明書では現在のハードウェアプラットフォームの種類を出力すると定義されています。

2段目は、シェルが選んでいる brew の位置です。command -v brew や type -a brew を使うと、いまどのファイルが呼ばれるのかが分かります。/opt/homebrew/bin/brew ならApple Silicon用、/usr/local/bin/brew ならIntel用です。type -a は同じ名前が複数ある場合に全部を並べるので、両方が入っている状態もここで判明します。

3段目は、Homebrew自身に聞く方法です。brew --prefix は導入先を表示し、brew --cellar はCellarの場所を表示します。公式の文書は、Cellarの既定値が $(brew --prefix)/Cellar であると説明しています。ここで出た文字列が /usr/local 系なら、Apple Siliconの機械でIntel用を動かしていることになります。brew config は、Homebrewとシステムの設定をまとめて出すコマンドとして用意されていて、問題を報告するときに求められる情報だと説明書に書かれています。

Rosetta越しに入ってしまう経路と、その見分け方

Apple Siliconの機械なのにIntel用が入る経路は、いくつかあります。1つは、ターミナル自身をRosettaで開いた状態でインストールした場合です。アプリの情報から「Rosettaを使用して開く」を有効にしたままだと、その中で動くコマンドはIntelとして振る舞います。もう1つは、arch -x86_64 を頭に付けたコマンド列をどこかからコピーした場合です。arch は本来、ユニバーサルバイナリの中から実行するアーキテクチャを選ぶためのコマンドで、説明書にもその用途が書かれています。意図して使う分には正しい道具ですが、意味を知らずに貼ると系統が切り替わります。

3つ目は、移行アシスタントで古いMacから引き継いだ場合です。/usr/local の下がそのまま運ばれてくるため、Intel用のHomebrewが最初から存在する状態でセットアップが始まります。この場合、新しくApple Silicon用を入れると2つが同居します。

見分けは、上の3段の確認で足ります。機械が arm64 で、brew --prefix が /usr/local を返すなら、Rosetta越しの系統を使っています。両方あるなら type -a brew に2行出ます。どちらが先に来ているかで、普段どちらが動いているかが決まります。

2つのHomebrewが同居している状態をどう畳むか

同居していても、すぐに壊れるわけではありません。prefixが分かれているので、実体が混ざることはありません。問題になるのは、どちらでパッケージを入れたか分からなくなる点と、PATHの順番次第で呼ばれる側が変わる点です。

畳む手順は、消す前に記録を取る形にします。まず、残す側と消す側を決めます。特別な理由がなければ、Apple Silicon用を残します。次に、消す側で何が入っているかを書き出します。brew bundle dump --file で対象のBrewfileへ書き出せば、後から同じ構成を残す側で作り直せます。書き出したファイルを別の場所へコピーしてから、削除に進みます。

削除そのものは公式の案内に従います。自己流で /usr/local の下を消すと、Homebrew以外のものまで巻き込む恐れがあります。/usr/local はHomebrew専用のディレクトリではないため、中身を一括で削除するのは避けてください。公式のアンインストール手順を使えば、Homebrewが作ったものだけが対象になります。

畳んだ後は、PATHの記述も1本に整えます。設定ファイルに eval "$(brew shellenv zsh)" が2行書かれていると、消したほうを指す行が残ります。~/.zprofile と ~/.zshrc の両方に書いていないかを確かめて、1か所にまとめます。

公式が示す要件は、すでにApple Siliconを前提にしている

もう1つ知っておくとよいのは、公式の立ち位置が変わっていることです。公式の導入手順の文書には、macOSの要件としてApple SiliconのCPUが挙げられ、64ビットのIntel CPUを使う構成はTier 3として位置付けられています。macOSのバージョンについても、公式の導入手順はmacOS 15のSequoia以降を要件として挙げています。

インストーラーの対応範囲にも差があります。公式の文書は、macOS向けの .pkg インストーラーがApple Siliconのみに対応し、既定のprefixである /opt/homebrew へ導入すると書いています。Intel機ではこの形式が使えないため、スクリプトによる導入だけが選択肢になります。無人での配布を考えている環境では、この違いが構成の決め手になります。

ソースからビルドする場合の前提も明記されています。公式は、formulaをソースからビルドするときにXcode用のコマンドラインツールかXcodeが必要だと書いています。入れていない状態でビルドが必要なパッケージに当たると、途中で止まります。先に入れておけば、原因の分からない失敗を1つ減らせます。

環境を1つにまとめたあと、確かめる場所も1つにする

ここまでの作業は、どれも「いまの状態を見る」ことが中心です。type -a brew の結果を見て、/opt/homebrew/bin の中を目で追い、~/.zprofile を開いて記述を直す。ターミナルとテキストエディタとFinderを行き来しながら1件を追う形になります。手順の難しさよりも、この往復のほうが時間を食います。

フォルダの一覧とターミナルとAIとのやり取りが同じ画面にあれば、この往復が消えます。左のサイドバーで /opt/homebrew/bin を開いたまま、同じ窓の下で brew --prefix を打ち、出た結果をその場でAIに読ませて次の1手を決められます。フォルダとターミナルとAIが同じ窓にある形は、切り分けの途中で視線が飛ばなくなるという意味で効きます。何ができるのかはできることにまとまっています。

/opt のような普段開かない場所を扱うときは、サイドバーの作りも効いてきます。実体を動かさずに、案件のフォルダと並べて手元へ出せる形になっていれば、毎回パスを打ち直す必要がなくなります。ObsidianやCursorを2枚並べている状態との違いは他のファイル管理との比較に整理してあります。出先から作業の続きを確かめる使い方はiPhone・iPadから続きを、費用は料金、残った疑問はよくある質問に並んでいます。

決めることは1つです。Apple Silicon用のHomebrewを /opt/homebrew に1つだけ持ち、PATHの記述を1か所にまとめる。これだけで、手順書のパスが合わないという迷いも、古いほうが呼ばれるという現象も起きなくなります。