brew installの使い方｜入れた物の居場所を把握する

brew installは1行で終わる操作なので、何がどこに置かれたのかを見ないまま次の作業へ進みがちになる。その結果、入れたはずのコマンドが呼ばれない、同じ名前の古い物が応答する、消したいのに置き場所が分からない、という詰まり方をする。ここでは brew install が実際に触っているディレクトリと、どのコマンドが応答するかを決めている1行を順に確かめていく。

brew installが置いている場所は3つに分かれている

Homebrew の説明で最初に押さえるべきなのは、パッケージの実体と、コマンドとして呼ばれる名前が別の場所にあるという構造である。公式サイトはこの点をはっきり書いている。

Homebrewは prefix の外部にファイルをインストールしません。各パッケージを Cellar 内の専用の keg にインストールし、そのファイルをHomebrewがインストールされている場所であるprefixへシンボリックリンクします。 出典: brew.sh

prefix は機械によって違う。Apple Silicon の Mac では /opt/homebrew、Intel Mac では /usr/local、Linux と WSL では /home/linuxbrew/.linuxbrew になる。この違いが、他の人の手順書をそのまま写して動かないときの原因のかなりの部分を占めている。パスを直書きした記事は、書いた人の機械の prefix を前提にしている。

実体は prefix の下の Cellar に入る。たとえば ffmpeg を入れると、バージョン番号を含んだディレクトリの中に本体が置かれ、prefix の bin にはそこへ向かうシンボリックリンクだけが作られる。つまり bin に並んでいるのは中身ではなく矢印である。

$ ls -l $(brew --prefix)/bin
/opt/homebrew/bin/ffmpeg -> ../Cellar/ffmpeg/8.1.1/bin/ffmpeg

この構造には実務上の利点がある。バージョンごとに別のディレクトリに入るため、入れ替えても前のバージョンが同じ場所で上書きされて消えることがない。そして prefix の外に出ないので、何が追加されたのかを調べるときに探す範囲が限定される。アプリケーション形式のパッケージは Caskroom に入り、こちらは /Applications へリンクされる。

置き場所を自分の機械で確かめる道具は最初から用意されている。brew --prefix が prefix、brew --cellar が Cellar、brew --caskroom が Caskroom を返す。手順書のパスを疑ったときは、記事の文字列ではなくこの3つの出力を信じるほうが早い。

入れただけでは呼ばれない。順番を決める1行がある

brew install が成功しているのに、そのコマンドが応答しない状態は珍しくない。原因はインストールではなく、シェルの設定にある。Homebrew の導入説明は、この設定を書かない場合どうなるかを言い切っている。設定ファイルに書くのは次の1行である。

eval "$(/opt/homebrew/bin/brew shellenv)"

書き込む先はシェルによって変わり、zsh なら ~/.zshrc、bash なら ~/.bashrc になる。<Homebrew prefix path> の部分は自分の機械の prefix に置き換える。この1行が prefix の bin を PATH の前に差し込む役目を持っている。

なぜ順番が問題になるのかというと、macOS には同じ名前のコマンドが既に入っていることがあるからである。git はその代表で、/usr/bin/git は Xcode の開発ディレクトリへ転送する仕掛けになっている。PATH の先頭に prefix の bin が来ていなければ、Homebrew で入れた新しい方はディスク上に置かれたまま呼ばれない。バージョン番号が変わらないという症状は、失敗ではなくこの順番の話である。

確認は which -a を使う。-a を付けると PATH の順に全部の候補が並ぶので、どれが先に見つかるのかがそのまま読める。1つしか出ないときは設定漏れ、2つ出て Homebrew 側が上に来ていれば意図した状態である。シェルを開き直していない場合も同じ症状になるため、書いた直後は新しいタブで確かめる。

formulaとcaskは審査の通り方から違う

Homebrew のパッケージは2種類ある。formulae はソースコードからコマンドラインツールやライブラリ、サービスを組み立てる定義で、casks はアプリケーションやフォント、プラグインなど、既にビルドされたバイナリを置く定義である。

見落としやすいのは、この2つが公式リポジトリに入るまでの条件が決まっていることである。homebrew/core の formulae は受け入れと変更と更新の前に人のレビューが通る必要があり、ライセンスも Debian Free Software Guidelines に沿ったオープンソースに限られる。homebrew/cask 側も同様にレビューを経る。誰かが勝手に登録した物が黙って降ってくる仕組みにはなっていない。

公式の外で配られている定義の集まりは tap と呼ばれる。tap を足せば非公式の formulae や casks も入れられるが、その時点で信頼の範囲が変わる。公式が案内しているのは、非公式の tap を使う前に信頼性の考え方を読むことである。

cask 特有の落とし穴として、アプリ自身が Homebrew の外で自動更新するものがある。この場合 brew upgrade では動かないため、更新も Homebrew 側で揃えたいなら brew upgrade --greedy を使う。バージョンが古いまま止まって見えるアプリは、壊れているのではなく自分で更新している。

入れられる機械の条件は思っているより上がっている

インストールできるかどうかの前提条件は、数年前の記事と現在で食い違っている。公式の導入手順が挙げている macOS の要件は、Apple Silicon の CPU と、macOS Sequoia（15）以降である。64ビットの Intel CPU は Tier 3 という位置づけになっており、OpenCore Legacy Patcher を使った構成も含めて Intel Mac は全部そこに入る。macOS 10.15 Catalina とそれより古い環境では動かない。

Apple Silicon 側の対応幅は、macOS 15 から 27 が最良かつサポート対象で、macOS 11 Big Sur から 14 Sonoma は非サポートながら動く場合があるという書き方になっている。「動く場合がある」は、詰まったときに助けが期待できない範囲という意味で読むのが安全である。

開発ツールの要否は条件付きになっている。Xcode か Command Line Tools が必要になるのは、formula をソースからビルドするときである。Apple Silicon では casks と bottle（ビルド済みバイナリ）は開発ツールなしで入る。一方 Intel の macOS は bottle を入れる場合でも開発ツールが必要になる。この非対称は、同じコマンドが機械によって1分で終わったりコンパイルを始めたりする理由になっている。

インストーラそのものにも条件がある。公式サイトに載っている1行のインストール方法は /bin/bash を使うため、zsh・fish・tcsh・csh では通らない。自動化の中で走らせてパスワードの入力待ちを避けたいときは、コマンドの前に NONINTERACTIVE=1 を付ける。macOS 向けには対話式と無人 MDM の両方に使える .pkg インストーラもあり、こちらは Apple Silicon 専用で、置き場所は同じ既定の prefix になる。

sudoが要る場面と要らない場面

Homebrew を避ける理由として挙がりやすいのが権限の話だが、実際の線引きは整理されている。インストールスクリプトが prefix を既定の位置に置くのは、最初の導入以降 formulae を入れるときに sudo を必要としないためである。一方で、一部の cask とシステムサービスは今も昇格した権限を求める。

sudo の呼び出しを明示的に止めたいときは環境変数で切る。

export HOMEBREW_NO_SUDO=1

これを設定しない状態では、sudo が見つからない場合や、権限を上げられないと判断できた場合、非対話のチェックが明確に拒否した場合にかぎって Homebrew 側が自動的に sudo を切る。パスワードを求められただけ、理由の分からない失敗だけ、という場面では通常どおりの動作が保たれる。sudo を切った状態では、インストーラやキーボードレイアウトのために sudo が要る cask はインストール前に弾かれる。書き込める場所を指定して入れる逃げ道もあり、brew install --cask --appdir="$HOME/Applications" <cask> の形になる。

複数の人が使う Mac や、管理者権限を持たないアカウントで運用する場合の道具も用意されている。専用のアカウントに Homebrew を持たせて他のアカウントからは実行だけを許す構成では、別のアカウントから brew as-brew-user install wget の形で所有者として実行する。MDM や Munki、Jamf のように root で走る仕組みから、いま画面にログインしている利用者として動かしたいときは brew as-console-user install wget を使う。どちらも root 所有の prefix は拒否され、ディレクトリの所有者が勝手に書き換わることはない。

入れた物の一覧を書き下しておく

brew install を1つずつ打った履歴は、時間が経つと再現できなくなる。これに対する公式の答えが Homebrew Bundle で、Brewfile に望む状態を書いておき、brew bundle で足りない依存を入れて古い物を更新する。宣言的な作り方なので、機械を入れ替えたときの復元手順が1ファイルに収まる。

$ cat Brewfile
brew "ffmpeg"
cask "firefox"

扱える対象は formulae と casks と taps だけではない。Mac App Store のアプリ、WSL 上の WinGet パッケージ、VSCode 拡張機能、Go・Cargo・uv・Flatpak のパッケージ、krew の kubectl プラグイン、そして brew services によるバックグラウンドサービスの起動までが同じファイルから扱える。新しい Mac を触り始めた日に、この1ファイルを置くだけで環境が揃う状態を作っておくと、あとで置き場所を探し回る作業自体が消える。

置き場所を追う作業そのものを短くする

ここまでの内容は、どれも「フォルダを見る」と「コマンドを打つ」の往復でできている。brew --prefix の出力を読み、そのパスを Finder で開き、中身を見て、またターミナルに戻って ls -l を打つ。1回は数秒でも、詰まっている最中は何十回も繰り返すことになる。

この往復を減らす方向で作られているファイル管理アプリもある。フォルダとターミナルとAIが同じ窓にある形にすると、いま見ているフォルダでそのままコマンドが打てるので、cd を打ち直す手数が消える。フォルダごとにターミナルが1つ割り当てられる作り方や、Git の状態がその場で見える点はできることにまとめられている。

長い処理を走らせたあと机を離れる場面にも同じ話が当てはまる。ソースからのビルドは数分かかることがあり、終わるまで画面を見ている時間は他に使える。手元の iPhone や iPad から Mac のターミナルを読んで返事だけ入れる使い方はiPhone・iPadから続きをで説明されている。無料で使える範囲と支払いが必要になる範囲の線引きは料金に書かれており、Mac だけで使う分には費用がかからない構成になっている。何を引き受けて何を引き受けないのかを先に知りたい場合は他のファイル管理との比較を読むと、編集機能を持たないことまで含めて明示されている。