ターミナルで何度も同じ科研ソフトを入れ直しても、command not found、コンパイル失敗、ダウンロードエラーが消えない状態です。
今週の最短ルートは、Homebrewを先に削除せず、元のコマンドと最初に出た有効なエラーを保存し、前置き、アーキテクチャ、Xcode Command Line Tools、bottle、通信、個別ソフトの順に確認することです。元のMacだけで再現するなら、クリーンなApple Silicon Macで同じ最小構成を試してから、修復、移行、遠隔Macの利用を選びます。
この手順を読むべき人
Apple Silicon Macで初めてHomebrewを使い、ターミナルのエラーを読み切れない大学院生向けです。Python、R、神経画像、生物情報学系の依存関係を再現したい研究者にも適しています。
研究室の共有macOS環境を保守し、Mac本体の問題とソフトウェア配布側の問題を分けたい技術担当者にも使えるrunbookです。
最初のログを残して、再インストールを止める
インストールを繰り返すと、最初の原因が後続エラーに埋もれます。まず、実行したコマンド、最初に意味のあるエラー、brew config、brew doctor、対象ソフトのログを別ファイルへ保存します。
which brew
brew config
brew doctor
brew info <formula>
brew自体が呼び出せない場合は、エラー画面を消さず、シェルの種類と実行したコマンドも記録します。Homebrew公式のトラブルシューティング手順も、一般的な修復より先に診断情報を集める流れです。
| 観察した症状 | 最初に確認する層 | そこで止める条件 |
|---|---|---|
command not found |
実行ファイルの場所とシェル設定 | which brewが空のまま |
| ダウンロード失敗 | 接続先、プロキシ、証明書、取得ファイル | 検証を無効にしないと進まない |
| bottleがない | OS、CPU、formula、tapの対応範囲 | 対応範囲を確認できない |
| コンパイル失敗 | Xcode Command Line ToolsとSDK | 最初のコンパイラーエラーが不明 |
| インストール後に呼べない | PATH、リンク、実行権限 | brew infoと実体の場所が不一致 |
ここで「Homebrewを壊した」と決めつけないことが重要です。問題が起きている層を特定できないまま削除すると、比較に必要な証拠まで失います。
brewの場所が違うときは、PATHより先に構成を比べる
Apple Silicon環境では、Homebrew公式インストール文書が示す標準的な前置きは/opt/homebrewです。一方、既存のIntel向け環境では/usr/localが使われることがあります。実際の構成は、Homebrew公式のインストール説明と手元の出力を照合します。
uname -m
type -a brew
which brew
brew --prefix
uname -mが示す実行環境と、brew --prefixの結果が想定と異なる場合、単純なPATH追加では解決しません。ターミナルを別の実行モードで開いていたり、古いシェル設定が残っていたりすると、同じ端末で別のbrewを呼び出すことがあります。
Apple Siliconでbrewのパスが複数見つかった場合はどうしますか。
まず両方の場所を記録し、インストール済みformulaとtapを一覧化します。古いディレクトリを先に削除せず、必要なformulaが代替環境で再現できるかを確認します。HomebrewのFAQにも、複数環境やPATHに関する確認事項があります。
brew list --formula
brew tap
brew bundle dump --file=~/Brewfile
Brew Bundleを含む公式マニュアルに沿って一覧を保存すると、環境を捨てずに比較できます。
| 確認対象 | 原生Apple Silicon環境 | 遺留Intel環境との混在時 |
|---|---|---|
brewの実体 |
/opt/homebrew側を確認 |
/usr/local側が先に呼ばれることがある |
| 優先確認 | shellenvと現在のシェル | PATH、シェル設定、実行モード |
| 低リスク対応 | 現在の構成を記録 | Brewfileで代替環境を検証 |
| 避ける操作 | 不要な再インストール | 旧ディレクトリの即時削除 |
コンパイルエラーはXcodeの状態とSDKを分けて見る
bottleが使われるインストールと、ソースからのビルドは別の経路です。コンパイラーやリンカーのエラーが出たからといって、対象の科研ソフトを繰り返し入れ直しても、開発ツールの不足は直りません。
まず、Xcode Command Line Toolsの状態を確認します。AppleのCommand Line Tools公式手順で、インストール方法と選択中の開発ディレクトリを照合します。
xcode-select -p
clang --version
xcrun --show-sdk-path
macOS Tahoe 26への更新後に突然ビルドできなくなった場合は、OS変更の影響と断定せず、SDKの選択、ライセンス確認、ツールの再選択を順に調べます。ログでは大量に出る警告ではなく、最初のコンパイルエラー、ヘッダー不足、リンク失敗の箇所を見ます。
macOS Tahoe 26へ更新した後、Homebrewの科研ソフトが入らない場合はどう切り分けますか。
更新前後でbrew config、xcode-select -p、対象formulaの情報を比較します。公式formulaが要求するOSやCPUの範囲と、上流ソフトのインストール説明が一致しないなら、ツールチェーンだけを直しても成功しません。
システムライブラリを偽装するリンク、セキュリティ機能の無効化、出所不明の古いコマンドは使いません。成功したように見えても、研究データの再現性と共有環境の安全性を損ないます。
bottle不足と依存関係は、対象formulaへ戻って確認する
No bottle availableは、Homebrew本体の破損を意味しません。OSの対応範囲、CPUアーキテクチャ、formulaの公開状態、第三者tap、上流プロジェクトの配布方針を個別に確認します。
brew info <formula>
brew deps <formula>
brew search <keyword>
Homebrew Formulaeの公式検索で、対象ソフトに対応するbottle、依存関係、現在の配布情報を確認します。formulaページだけで判断できない場合は、対象ソフトの公式インストール文書へ戻ります。
bottleがないなら、必ずソースビルドが必要ですか。
必ずしもそうではありません。公式インストーラー、上流が提供する別形式、対応する別formulaがある場合は、そちらが安全なことがあります。逆に、ソースビルドを選ぶなら、コンパイラー、SDK、依存ライブラリが揃っているかを確認し、研究で使う最小タスクまで通す必要があります。
Python、R、Fortran、X11などが依存関係に出ても、最初から各エコシステム全体を入れ直しません。最初に失敗したコンポーネントだけを調査し、そこから先のエラーを新しい原因として扱わないようにします。
| 状態 | 可能性 | 次の判断 |
|---|---|---|
| formulaにbottleがある | 前置き、OS、取得、権限の問題 | ログと環境を修正 |
| bottleが対象環境にない | 対応範囲または公開状態の問題 | 公式配布物を比較 |
| 依存formulaで停止 | 最初の依存コンポーネントの問題 | 依存先を単独確認 |
| 上流の対応範囲外 | Homebrewだけでは解決困難 | その経路を停止 |
権限と通信は、sudoで一括修正しない
permission deniedが出たら、エラーになった書き込み先、所有者、実行ユーザーを確認します。Homebrewは基本的に単一ユーザーで使う設計が中心です。Homebrew公式FAQの前提から外れる研究室の共有Macでは、個人の環境と共有環境の境界を先に設計します。
id
ls -ld "$(brew --prefix)"
ls -ld "$(brew --prefix)/bin"
Homebrewの前置き全体に対して、出所不明の再帰的な所有者変更を実行してはいけません。sudo brew installを常用する方法も、問題の所有者を隠すだけです。
通信エラーは、タイムアウト、証明書、プロキシ、取得元の障害、チェックサム不一致を分けます。環境変数を確認し、上流ファイルが現在も公開されているかを確認します。検証を飛ばしたり、チェックサムを無効化したりする対応は、科研ソフトでは採用しません。
クリーンなMacで再現して、環境の去就を決める
元の端末でだけ失敗するのか、同じformulaと依存関係で広く失敗するのかを分けます。Brewfile、または手作業で整理した最小依存リストを使い、クリーンなApple Silicon Macで同じインストールと代表的な科研タスクを実行します。
研究室にMacがない場合、Homebrewの失敗をどう再現しますか。
既存のLinuxやWindows環境を無理にmacOSへ置き換えるのではなく、周期利用できる遠隔Macで最小構成を再実行します。MESHLAUNCHのMac環境の案内を確認し、必要な期間だけ検証環境を確保する方法も選択肢になります。
ただし、実測していない構成、所要時間、料金、交付条件を推測して比較してはいけません。クリーン環境で成功した場合だけ、元の環境を直す時間と移行する時間を比較します。
| 再現結果 | 判断 | 推奨する次の行動 |
|---|---|---|
| 両方で同じformulaが失敗 | ソフトまたはformula側の問題 | 上流文書とIssueを確認 |
| 元のMacだけ失敗 | ローカル環境の問題 | 修復と移行を比較 |
| クリーン環境だけ失敗 | OSや構成差の問題 | 対応範囲を再確認 |
| インストール後のタスクだけ失敗 | 科研ソフト固有の依存問題 | 最小データで個別検証 |
完了判定は、コマンドを呼び出せることだけにしません。代表的なデータを処理できること、結果を所定形式で出力できること、接続を切って再接続した後も作業状態を復元できることを確認します。
作業前に使うチェックリスト
- [ ] 実行したインストールコマンドと最初の有効なエラーを保存した
- [ ]
which brew、type -a brew、brew --prefixを記録した - [ ] シェルの実行アーキテクチャとHomebrewの前置きを照合した
- [ ]
brew configとbrew doctorの出力を保存した - [ ] Xcode Command Line ToolsとSDKの選択状態を確認した
- [ ] 対象formulaのbottleと対応範囲を確認した
- [ ] 依存関係の最初の失敗コンポーネントを特定した
- [ ] 書き込み先、所有者、実行ユーザーを確認した
- [ ] プロキシ、証明書、取得元、チェックサムを分けて調査した
- [ ] Brewfileまたは最小依存リストを作成した
- [ ] クリーンなApple Silicon環境で代表的な科研タスクを再実行した
- [ ] 修復、移行、遠隔Mac利用の判断条件を記録した
既存環境を残したまま再現性を確認したい場合は、Apple Silicon向けMac構成の案内も比較材料になります。二つのbrewを共存させる場合も、削除ではなく、呼び出される実体、formula一覧、研究タスクの結果を記録してから決めます。
現在のMacで場当たり的にPATHを足す方法は、短期的にはコマンドを呼べても、共有環境では誰がどのbrewを使ったか分からなくなる欠点があります。古い前置きを残したまま権限を一括変更すると、別の研究者の環境や再現性を壊す可能性もあります。Homebrewの長い履歴を整理できない場合は、購入前に周期利用できるMESHLAUNCHのクリーンな遠隔Macで最小依存と代表タスクを試し、成功を確認してから本番環境を移す方が、今回のような単発のインストール障害には合理的です。