Homebrew 7.0.0でIntel Macが切られた — ボトル供給はすでに停止、2027年9月の本当の意味

はじめに

2026年9月13日、Homebrew 7.0.0 がリリースされた。並行ダウンロードによる高速化、脆弱性スキャンコマンド brew vulns、ネイティブGUIの BrewUI といった追加もあるが、話題をさらったのは破壊的変更のほうだ。Intel Mac (x86_64) が Tier 3 に降格し、macOS Sonoma 14 も同じく Tier 3 に落ちた。

ただ、このニュースは「2027年9月から Intel 向けの新規ボトルが出なくなる」という形で流通している。これは正確ではない。ボトルの供給はすでに止まっているし、しかもそれは 7.0.0 のリリースより2週間以上前の出来事だった。この記事では、実際に何がいつ起きたのか、なぜ起きたのか、そして Apple Silicon ユーザーも他人事ではない理由を整理する。

何が起きたか — 供給停止は2026年8月28日

まず時系列を正しく並べる。

Homebrew の公式ドキュメント Support Tiers における Tier 3 の定義はこうだ。

CI coverage is unavailable; bottles will rarely be built or published.

つまり Tier 3 に落ちた時点で、ボトル（プリビルドのバイナリパッケージ）は「ほぼ作られない・公開されない」。これは将来の予告ではなく、現在の状態を指している。

そして実際の停止日はさらに手前にある。Homebrew の Discussion #7044 によれば、macOS Intel の CI ランナーは2026年8月28日に停止した。当初アナウンスされていた9月の期限より3日ほど早い。つまり 7.0.0 のリリースノートは、すでに起きていた事実をポリシーとして追認する文書だった。

では2027年9月は何なのか。Support Tiers はこう書いている——その時点以降、Intel システムは “Unsupported” になり、Homebrew を Intel 上で動かす機能そのものが削除される。ボトルが出なくなる日ではなく、brew が起動しなくなる日だ。

この違いは実務上大きい。「2027年までは今まで通り」と考えていると、brew upgrade が突然ソースビルドに落ちて LLVM や FFmpeg のコンパイルに数十分〜数時間かかる、あるいはビルドに失敗してインストールできない、という事態に今日ぶつかる。

なぜ起きたか — Homebrew の意思決定ではない

ここが本質的なポイントで、これは Homebrew が主体的に選んだ打ち切りではない。依存の連鎖の末端で起きた現象だ。

Homebrew のボトルは GitHub Actions 上でビルドされている。そして GitHub 側の Intel ランナーには、Apple のアーキテクチャ移行に連動した撤退スケジュールがある。macOS 13 (Ventura) ランナーイメージは2025年末に停止し、Intel 環境が必要なユーザー向けには macos-15-intel ラベルが用意されたが、actions/runner-images の告知によればこれが最後の x86_64 イメージで、2027年8月までの提供となっている。

Apple が x86_64 を切る → GitHub が Intel ランナーを畳む → Homebrew がボトルを焼けなくなる、という順序だ。メンテナの MikeMcQuaid はこの構図をそのまま述べている。

If the biggest companies in the world cannot support macOS Intel x86_64 any longer, sadly neither can we.

さらに、8月28日の前倒し停止の直接の引き金は期限ですらなく、インフラの性能崩壊だった。メンテナの SMillerDev によれば、テスト前のセットアップ時間が数秒から2時間超に劣化し、ビルド全体が「10倍以上」の時間を要するようになって全プラットフォームにバックログが波及した。解消の見込みが立たず、繰り上げて落とすしかなかった、という経緯である。

代替として公式に案内されているのは MacPorts だ。古い macOS のサポートが厚く、ソースビルド前提の設計なので Intel でも成立しやすい。

コミュニティ側の回避策としては、GitHub の無料 macos-15-intel ランナーで Sequoia 向けボトルを焼き続ける intel-bottles のような試みがある。HOMEBREW_NO_INSTALL_FROM_API=1 と HOMEBREW_CORE_GIT_REMOTE で homebrew-core のフォークを向かせる方式だ。ただしこれも macos-15-intel ランナーの寿命（2027年8月）に縛られるうえ、qtwebengine のようにビルドに5時間50分かかり GitHub の6時間上限に収まらない巨大 formula は端から対象外になる。土台が同じである以上、避難先にはならない。

Apple Silicon なら安全、ではない

「M1以降を使っているから関係ない」と読み飛ばすと危ない。降格したのは CPU アーキテクチャだけではないからだ。

Support Tiers の分類はこうなっている。

Intel x86_64 macOS: 全バージョンが Tier 3
Apple Silicon macOS: 最新3バージョンのみ Tier 1。Big Sur 11 〜 Sonoma 14 は Tier 3
Linux: glibc 2.39 以上の Ubuntu が Tier 1、glibc 2.13〜2.38 は Tier 2

Tier 1 は Sequoia 15 / Tahoe 26 / Golden Gate 27 の3世代。つまり Apple Silicon 機であっても Sonoma 14 に留まっていれば Intel と同じ Tier 3 扱いになる。業務都合で OS を上げていない開発機、Xcode のバージョンを固定している CI、検証用に残している古い Mac——このあたりが静かに射程に入る。

実質的な支持ラインは「Apple Silicon かどうか」ではなく「Apple Silicon かつ最新3世代の macOS か」だ。加えて 7.0.0 では .pkg インストーラが Apple Silicon + Sequoia 15 以降限定になり、macOS 10.15 (Catalina) 以前は完全にサポート終了した。新登場の BrewUI に至っては Tahoe 26 以降が必要で、brew install homebrew-app で入る。

もうひとつの破壊的変更 — 任意のRubyから宣言的ステップへ

Intel の話に隠れがちだが、tap や formula を自分で持っている人にはこちらのほうが作業が発生する。

formula の post_install と cask の flight ブロック（preflight / postflight など）が非推奨になり、宣言的な *_steps に置き換わった。cask 側は preflight_steps / postflight_steps / uninstall_preflight_steps / uninstall_postflight_steps というスタンザになる。公式 tap ではすでに旧形式が拒否されており、サードパーティ tap は2027年12月11日まで警告付きで動作する。なお、ひとつの formula が post_install と post_install_steps の両方を定義することはできない。

移行は brew style --fix が典型的なケースを自動変換してくれるが、複雑なブロックは手作業で宣言的ステップに書き直す必要がある。

この変更の狙いは、一見バラバラに見える 7.0.0 の他の変更と一本の線でつながっている。任意の Ruby コード実行を、検証可能なデータに落とすという方向だ。操作とパスが明示的に宣言されていれば、バリデーションもサンドボックス化も、署名付き API での配信もできる。実際 7.0.0 では、macOS 側で cask のアプリ起動・Mach サービス・Unix ソケット接続が制限され、Linux 側のサンドボックスは Bubblewrap から Landlock に置き換わった（依存パッケージも Docker の権限昇格も不要になる）。修正された脆弱性 GHSA-5263-whxq-77hp が「悪意ある cask が LaunchServices 経由でインストールサンドボックスの外でコードを実行できた」というものだったことを踏まえると、一連の変更が同じ問題意識から出ていることが分かる。

エンジニアへの影響と、今日やること

実務への落とし込みは3点に絞れる。

1. Intel Mac が開発機・CI に残っているなら、猶予は「2027年9月まで」ではない。 ボトルはもう来ない。brew install がソースビルドに落ちる前提でスケジュールを見積もり直す必要がある。CI で Intel macOS ランナー上の brew install に依存しているパイプラインは、ビルド時間の急増かジョブのタイムアウトとして顕在化する。Apple Silicon への移行か、MacPorts か、そもそも Docker/Linux に寄せるかの判断を今期中に置いたほうがいい。

2. OS バージョンを棚卸しする。 Apple Silicon でも Sonoma 14 以下は Tier 3。brew config で自分の環境がどの Tier にいるかを確認し、Tier 1 の3世代に載せる計画を立てる。

3. 自作 tap があるなら brew style --fix を今流す。 2027年12月11日まで警告で動くとはいえ、警告を出し続ける tap は利用者の信頼を削る。同時に brew vulns を回して足元の脆弱性も確認しておきたい。--severity=high で優先度を絞り、--deps で依存も含め、--json を CI に組み込める。アドバイザリDBは OSV フォーマット（GitHub Security Advisories や Go の脆弱性DBと共通）で、CC0 ライセンスでダウンロードできるため、社内のセキュリティパイプラインに組み込むこともできる。npm や Cargo では当たり前だった機能が、ようやく追加のtapなしで使えるようになった。

まとめ

Homebrew 7.0.0 で Intel Mac は Tier 3 に降格したが、ボトル供給は2026年8月28日にすでに停止済み。7.0.0 は事後の追認にあたる
停止の前倒しはポリシーではなく、CI のセットアップ時間が数秒から2時間超に劣化したインフラ崩壊が直接の引き金だった
2027年9月は「ボトルが止まる日」ではなく「Homebrew が Intel 上で動かなくなる日」
安全圏は「Apple Silicon」ではなく「Apple Silicon かつ最新3世代の macOS」。Sonoma 14 は Apple Silicon でも Tier 3
post_install / flight ブロックの *_steps 移行、cask サンドボックス強化、Landlock 採用は、任意のコード実行を検証可能な宣言に置き換えるという一貫した方向の現れ

この一件が示しているのは、パッケージマネージャの「サポート」がもはやプロジェクト単独の意思では決まらないという構造だ。Apple のアーキテクチャ移行が GitHub のランナー提供を決め、それが Homebrew のボトルを決める。自分のツールチェーンがどの企業のインフラの上に乗っているかを把握しておくことが、そのまま移行計画の精度になる。

今日のその他のニュース

マイクロソフトが Rust を社内 Tier 1 言語に Rust が C++ / C# / TypeScript と並ぶ Tier 1 に昇格。技術的な核は独自バックエンド rustc_codegen_utc で LLVM を置き換え、MS の C コンパイラ (UTC) に接続した点にある。これにより Rust ↔ C++ の言語横断インライン化や SPGO、post-link 検査が通る。「Rust を採用した」ではなく「既存の C++ ツールチェーン資産を Rust に適用可能にした」という順序が要点。(Publickey)

シンボルを削った libflutter.so から TLS 証明書検証関数を特定する手法 13アプリ × 9エンジンバージョンで再現性を確認した報告。Flutter は Dart 側が BoringSSL を持つため OS の証明書ストアや Java 層のフックが効かず解析しづらいとされてきたが、その前提が崩れる。Dart 側の検証に依存した SSL pinning はバイナリパッチで無効化されうる前提で、サーバー側検証や改ざん検知を組む必要がある。(Reddit r/FlutterDev)

エラー対応設計: 例外と障害を区別しよう 「障害」はシステムが機能を提供できず自己復旧もできない状態だけを指し、監視アラートの対象はそこだけ。同じ TypeError が環境障害にもバグにもなるため例外型での分岐は成立しない。指針は「その場所で処理できる例外だけを catch し、残りは単一のエラーハンドラまで伝播させる」。(Qiita)