HomebrewをMacで使う｜何が入ったか後から確かめる

homebrew macで検索すると、インストールの1行と最初の数コマンドを並べた記事が並びます。そこまでは10分で終わります。詰まるのはその後です。半年経って brew list を打つと、覚えのない名前が数十件並んでいる。どれが自分で入れたもので、どれが何かの部品として一緒に入ったものなのか分からない。消していいのかも分からないので、そのまま増え続けます。この記事は、入れる手順を確かめたうえで、後から状態を読み取る側のコマンドまで通して整理します。

Homebrewはprefixの外にファイルを作らない、という約束で動いている

Homebrewの動きを1行で言うと、パッケージを専用の場所に展開して、そこから使う場所へリンクを張る仕組みです。公式サイトはこの構造を明示しています。

Homebrewは prefix の外部にファイルをインストールしません。各パッケージを Cellar 内の専用の keg にインストールし、そのファイルをHomebrewがインストールされている場所であるprefixへシンボリックリンクします。Apple Siliconでは /opt/homebrew 、Linux/WSLでは /home/linuxbrew/.linuxbrew 、Intel Macでは /usr/local がprefixになります。 出典: brew.sh

この2段構えを知っていると、後の疑問がほとんど解けます。ffmpeg を入れると実体は /opt/homebrew/Cellar/ffmpeg/バージョン番号/bin/ffmpeg に展開され、/opt/homebrew/bin/ffmpeg はそこへのリンクになります。バージョンごとにディレクトリが分かれているので、古い版が残っていても新しい版と衝突しません。prefixの場所は brew --prefix、Cellarの場所は brew --cellar、アプリ置き場は brew --caskroom で確かめられると公式サイトに例が載っています。

対応する環境も公開されています。公式サイトは、macOSのSonoma 14以降、Linux、Windows Subsystem for Linuxをサポートすると明記しています。古いmacOSでは動かないことがあるという話ではなく、支える範囲として書かれているのがこのmacOS 14以降です。手元のMacがこの範囲から外れているなら、入れる前にそこを確かめておく必要があります。

運営の形も知っておくと判断材料になります。Homebrewは従業員ではなくボランティアで運営されている非営利のプロジェクトで、会計上はOpen Source Collectiveがホストしています。寄付の受け口はGitHub Sponsors、Open Collective、Patreonの3つが案内されています。会社が保証している製品とは性質が違う、という前提で使う道具です。

入れる方法は2つある。スクリプトと.pkgインストーラー

公式サイトが案内している導入方法は2つです。1つは、ターミナルに貼り付ける形のインストールスクリプトです。公式は「このスクリプトは何を実行するのかを説明した後、実行する前に一時停止します」と書いています。つまり実行しても即座に書き換えが始まるわけではなく、内容を読んでから続けるかどうかを決められます。

もう1つは .pkg 形式のインストーラーです。公式は、対話型のインストールにも、無人のMDMインストールにも使えると案内していて、最新のGitHubリリースから入手できると書いています。会社支給のMacを何十台も同じ状態にしたいときは、こちらのほうが手数が少なくなります。個人のMacであっても、ターミナルに長い1行を貼ることに抵抗があるなら選べる道です。

どちらの方法でも、prefixの場所はチップの世代で決まります。Apple Silicon搭載機は /opt/homebrew、Intel搭載機は /usr/local です。この違いは後から効いてきます。ネット上の手順書が /usr/local を前提に書かれていると、Apple Silicon機ではパスが合いません。自分の環境のprefixがどちらかを最初に確かめておけば、以降の手順書を読み替えられます。

導入の直後に打つべきコマンドは brew doctor です。公式の説明書によれば、このコマンドはシステムに問題がありそうな箇所を確かめ、見つかった場合はゼロ以外の終了状態で終わります。ここで警告が出ても、公式は「これらの警告は問題を報告する際にメンテナーの調査を助けるためのもの」と注意しており、全部を消さないと使えないという意味ではありません。

formulaとcaskは別物で、更新のされ方も違う

Homebrewが扱うパッケージは2種類に分かれます。公式の説明では、formulaeはアップストリームのソースコードからコマンドラインツール、ライブラリ、サービスをビルドするパッケージ定義です。caskは、アプリケーションやフォント、プラグインといった、あらかじめビルドされたバイナリを導入するパッケージ定義です。

この違いは日々の運用に影響します。公式は、一部のcaskがHomebrewの外で自動更新されると書いています。アプリ自身が更新を確認して入れ替える形になっているため、Homebrewから見ると古い版のままに見えることがあります。Homebrew側でも更新したいなら brew upgrade --greedy を使うよう案内されています。この1語を知らないと、更新したつもりで取り残されている状態が生まれます。

品質の確かめ方も公開されています。homebrew/coreのformulaeは、受け入れ、変更、更新の前に人間によるレビューを通し、Debian Free Software Guidelinesに準拠したライセンスのオープンソースソフトウェアでなければならないと決められています。caskについても、受け入れ前に人間のレビューを通す仕組みです。公式の外にある配布元はtapと呼ばれ、誰でも独自の定義を維持できます。公式は、非公式のtapを使う前にtapの信頼性について読むよう促しています。導入元がどこなのかを意識せずに使うと、レビューを通っていない定義から入れることになります。

何が入っているかを後から確かめる4つのコマンド

ここが本題です。増えてしまった一覧を読み解くコマンドは、公式の説明書に揃っています。

brew leaves は、他のformulaやcaskの依存になっていないformulaを並べます。つまり、自分が目的を持って入れたものだけが出てきます。--installed-on-request を付けると手で入れたものに限定でき、--installed-as-dependency なら依存として入ったものだけを見られます。brew list の側にも同じ観点の絞り込みがあり、--installed-on-request と --no-installed-on-request で手動と依存を分けられます。--versions でバージョンを、--pinned で固定しているものだけを出せます。

brew deps は、あるformulaが何に依存しているかを並べます。複数のformulaを指定すると、その全部に共通する依存だけが出ます。逆向きが brew uses で、指定したformulaを依存として使っている側を並べます。消してよいかどうかを判断するときは、この逆向きが決定的です。誰も使っていないことを確かめてから外せば、他のコマンドが動かなくなる事故を防げます。

brew outdated は、更新版が出ているformulaとcaskを並べます。全部を更新する前にここを見れば、何が動くのかを事前に把握できます。この4つを順に打つだけで、「覚えのない名前が数十件」の状態が「自分で入れた10件と、その依存」に分解されます。分解できれば、消す判断ができるようになります。

Brewfileで、いまの状態を1ファイルに書き出す

コマンドで毎回調べる代わりに、状態そのものを書き出す方法があります。brew bundle dump は、公式の説明書によれば、インストール済みのcask、formula、イメージ、tapをまとめてBrewfileへ書き出します。出力先は現在のディレクトリか、--file で指定した場所です。説明書はこれを「インストール状態のスナップショットとして有用で、バージョン管理に入れて差分を取れる」と位置付けています。

この使い方が効くのは3つの場面です。1つ目はMacを買い替えたときで、Brewfileを持っていけば brew bundle で同じ状態を作り直せます。公式は、brew bundle が不足している依存を導入し、古いものを更新して、プロジェクトやマシンの設定を再現可能にすると説明しています。2つ目は、いつ何が増えたのかを追いたいときです。Brewfileをバージョン管理に入れておけば、差分が履歴になります。3つ目は、チームで環境を揃えるときです。

Brewfileが扱える対象は、formulaとcaskだけではありません。公式は、tap、Mac App Storeのアプリ、WSL上のWinGetパッケージ、VSCodeの拡張機能、Goのパッケージ、Cargoのパッケージ、uvのツール、Flatpakのパッケージ、krewのkubectlプラグイン、そして brew services によるバックグラウンドサービスの起動に対応すると書いています。環境の定義を1つのファイルに集められる範囲は、思っているより広いです。

使っていないものを外す順番

整理の手順は、確かめる側と消す側を分けて考えます。先に確かめ、そのうえで消します。

依存としてだけ入って、いまは誰も必要としていないものには専用のコマンドがあります。brew autoremove は、他のformulaの依存としてのみ導入され、現在は不要になったformulaを削除します。--dry-run を付けると、削除される予定のものを並べるだけで、実際には削除しません。最初は必ずこの下見を通してから、本番を実行する順番にします。

ダウンロードの残骸は別のコマンドが受け持ちます。brew cleanup は、古くなったロックファイルとダウンロード済みの古いファイルを取り除き、導入済みformulaの古いバージョンを削除します。説明書には、120日より古いダウンロードをすべて削除し、この日数は環境変数で調整できると書かれています。ディスクの空きが減っている原因がここにある環境は珍しくありません。

なお、Homebrewは匿名の集計データを送る仕組みを持っています。brew analytics で現在の状態を表示し、on と off で切り替えられます。何を送っているのかは公式の文書に説明があります。業務で使うMacでは、この設定を最初に確認しておくと後で聞かれたときに答えられます。

一覧を見る場所とコマンドを打つ場所を分けない

ここまでのコマンドは、どれも結果を読んで次を決める形で使います。brew leaves の出力を見て、気になる名前を brew uses に渡し、誰も使っていないことを確かめて外す。この往復が3回も続くと、出力をどこかに残しておきたくなります。Finderでフォルダを開き、ターミナルで結果を見て、テキストエディタに書き留める。窓が3つに増えた時点で、作業は途切れます。

フォルダの一覧とターミナルとAIとのやり取りが同じ画面にあると、この往復が1か所で終わります。brew --prefix で出たディレクトリをその場で左のサイドバーから開き、リンク先を目で追いながら、同じ窓の下で次のコマンドを打てます。出力をそのままAIに渡して「この中で消してよいものはどれか」と聞くこともできます。フォルダとターミナルとAIが同じ窓にある形は、確かめる作業の手数をそのまま減らします。何ができるのかはできることにまとまっています。

Cellarの中を見るときは、サイドバーの作りも効いてきます。/opt/homebrew/Cellar のような普段開かない場所を、案件のフォルダと並べて手元に出せる形になっていれば、探す手間がなくなります。ObsidianやCursorを2枚並べている状態との違いは他のファイル管理との比較に整理してあります。導入にかかる費用は料金、残った疑問はよくある質問に並んでいます。

入れることは1行で終わります。続けられるかどうかを決めるのは、入れた後に状態を読み取れるかどうかです。brew leaves と brew uses と brew bundle dump の3つを月に1回打つ習慣があれば、一覧が読めない状態には戻りません。