【失敗談あり】M3 MacにHomebrewでPythonを入れてハマった話【RosettaとHomebrewの罠】

M3 MacBook AirでPython環境をHomebrewで整理しようとしたら、Rosetta経由でIntel版を入れてしまっていて大混乱。私の失敗談から、Apple Siliconに最適な構築法を解説します。

Pythonの開発環境って、一度ぐちゃぐちゃになると立て直すのが本当に大変ですよね。

私のMacは「グローバルのPython」の他に「HomebrewのPython」を導入していて、さらにはPyenvやvenvを使っていたので、どれが実行されているのか分かりづらい状態になっていました。

そこで一念発起して、「改めてHomebrewでPythonを一元管理しよう！」と決めて、環境の整理を始めたんです。ところが、これがまさかの落とし穴。

which python3 をいくら確認しても /usr/bin/python3 のままで、HomeBrew用のパスを通しても反映されず、pipを使おうとすればエラーが出る始末。

調べてみると、なんと自分のMacにはRosettaモードでインストールされたIntel版のHomebrewが入っていたことが発覚。

実は以前、ある記事で「MacではIntel用Homebrewの方が安定」と紹介されていたのを信じ、Macデビューしたばかりだった私はRosettaモードでIntel版のHomebrewを導入していたんです。結果として、Apple Silicon用の構成と噛み合わず、多くの不具合を引き起こすことに。

この記事では、そんな私の環境構築失敗談を通して、Apple Silicon MacでPythonを正しく扱うためのポイントと、避けるべき罠を共有します。

✅ この記事の要点
・Apple SiliconではRosettaモードでHomebrewを入れるべきではない
・Homebrewは /opt/homebrew にインストールされるのが正解
・Pythonのパッケージ管理は仮想環境を使うのがベスト
・pip install 時のエラーはPEP 668による仕様なので、焦らず対処法を知ることが大切

結論：Apple Silicon Macでは、Rosettaモード＋Intel版Homebrewは使わない方がいい

Apple Silicon（M1/M2/M3）を搭載したMacでは、RosettaモードでIntel版HomebrewをインストールしてPythonを管理しようとすると、高確率で環境が混乱します。

そのため、Apple Silicon用に最適化されたHomebrew（/opt/homebrew）を使うべきです。これが最初の結論であり、この記事の一番のポイントです。

理由はシンプルで、Intel向け（x86_64）のツールとApple Silicon向け（arm64）のツールは共存させると挙動が不安定になるからです。特にHomebrewのようなパッケージ管理ツールは、どちらのアーキテクチャ向けにインストールされたかによって、すべての挙動（インストール先のパス、実行環境、依存パッケージのアーキテクチャ）が変わってしまいます。

私はこのことを知らず、過去にRosettaモードでIntel版のHomebrewを入れたまま、Python環境を整理しようとしました。結果、which python3 を実行しても /usr/bin/python3（macOS内蔵のPython）しか出てこず、せっかくHomebrewで入れたPythonが使われない状態が続きました。

which python3
# => /usr/bin/python3

さらに、pip install flet を試みた際には、次のようなエラーが発生しました：

error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try brew install xyz...

このエラーの根本原因も、Intel版HomebrewがApple Siliconと合っていない状態で動作していたことです。

私のように、「環境がごちゃごちゃしてきたから整理しよう」と思った人こそ、Rosettaモードを切って、Apple Silicon用Homebrewに統一することが、最初の大きな一歩になります。

なぜIntel版Homebrewを使ってしまったのか

今思えば当然なのですが、当時の私は「Intel用Homebrewが安定」「M1/M2 MacでもRosettaモードでHomebrewを入れよう」といった記事をいくつか読み、その通りに実行してしまいました。

特に /usr/local にインストールされるIntel版Homebrewの方が、昔からのツールやスクリプトとの互換性が高い――そんな言葉を信じてしまったのです。

実際、私が過去にHomebrewを導入したときは、Macを使い始めてまだ間もない頃でした。そんな中でHomeBrewというパッケージ管理ツールを知り、ネットにあった記事を信じて、Rosettaモードを通じてPythonを導入することに何の疑いもありませんでした。

Rosettaモードでターミナルを開き、以下のようなコマンドでHomebrewを導入しました。

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

これにより、/usr/local にHomebrewがインストールされ、brew install python を行っても、インストールされるのはIntel向けPythonになりました。もちろん、当時の私はそれで問題ないと思い込んでいました。

ところが、環境整理を決意し「よし、HomebrewでPythonを一元管理しよう」と考えたとき、その“過去の選択”が足を引っ張り始めたのです。

which python3 は /usr/local/bin/python3 を指し、.zshrc にどんなに PATH=”/opt/homebrew/bin:$PATH” を書いても反映されない。ふと気づいて which brew を確認すると、そこでも /usr/local/bin/brew という表示が返ってきました。

which brew
# => /usr/local/bin/brew

which python3
# => /usr/local/bin/python3

nano ~/.zshrc

source ~/.zshrc

つまり、私はApple Silicon(M3)のMacBook Airを使いながら、Intel Mac用のHomebrewとPythonを意図的に使っていたんです。

Apple Silicon時代の「正解」とは違う方法を、そのまま信じて実行していたことが、今回の混乱の根本原因でした。

ハマりポイント：PATHを設定してもpythonがグローバル設定のまま

HomebrewでPythonをインストールしたのに、which python3 を実行するといつまで経っても 結果が反映されない。

これはApple Silicon MacでHomebrewの管理下にあるPythonを使いたい人が、稀に直面する罠だと思います。

私も、.zshrc に何度もPATHを追加・修正しながら、なぜか内蔵のPythonが優先されてしまう状況に悩まされました。

たとえば、以下のように書いたはずの .zshrc：

export PATH="/opt/homebrew/bin:$PATH"
alias python="python3"
alias pip="pip3"

それでも、ターミナルで確認するとこの状態です。

which python3
# => /usr/bin/python3

このときは本当に混乱していて、.zshrc の書き方が悪いのか、それとも何かPATHの設定順序に問題があるのかと疑っていました。

しかし、いろいろ見直した結果、原因は「.zshrc の中にあった別のPATH定義が上書きしていたこと」でした。

export PATH="/usr/local/bin:/usr/bin:/usr/sbin:/bin:/sbin:/Users/********/develop/flutter/bin"

この行が後からPATHをまるごと上書きしてしまい、それまで設定していた /opt/homebrew/bin の指定が完全に無効になっていたのです。

具体的には以下の内容を、、、

export PATH="/opt/homebrew/bin:$PATH"
alias python="python3"
alias pip="pip3"

# ここを修正しました。↓↓
export PATH="/usr/local/bin:/usr/bin:/usr/sbin:/bin:/sbin:/Users/********/develop/flutter/bin"

export FLUTTER_TEST_ARM64=true
export PATH="$HOME/.rbenv/bin:$PATH"
eval "$(rbenv init -)"
export DOTNET_ROOT="/usr/local/opt/dotnet/libexec"
export PATH="$DOTNET_ROOT:$PATH"

↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓

export PATH="/opt/homebrew/bin:$PATH"
alias python="python3"
alias pip="pip3"

# Flutterパスを追加（上書きじゃない！）
export PATH="$PATH:/Users/********/develop/flutter/bin"

export FLUTTER_TEST_ARM64=true
export PATH="$HOME/.rbenv/bin:$PATH"
eval "$(rbenv init -)"
export DOTNET_ROOT="/usr/local/opt/dotnet/libexec"
export PATH="$DOTNET_ROOT:$PATH"

このように変更したことで、パスの上書きを防ぎました。

改めて .zshrc を適用し直したところ、ようやく which python3 の結果が変わりました。

which python3
# => /opt/homebrew/bin/python3

このときは本当にうれしかったのを覚えています（笑）。

一見細かい部分ですが、PATHの優先順位と上書きの罠は、Apple Siliconでの環境構築において非常に重要なポイントです。

pip installで“externally-managed-environment”エラーが出た

ようやく which python3 が /opt/homebrew/bin/python3 になって一安心…と思いきや、今度は pip install コマンドで新たなエラーに直面しました。

flet をインストールしようとしたときのことです。

pip install flet

すると、以下のようなエラーメッセージが表示されました。

error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try brew install xyz, ...

一見すると何のことやら分かりにくいエラーですが、これは 最近のHomebrew Python環境の新仕様（PEP 668）によって、pipによるグローバルなパッケージインストールが制限されたことによるものです。

HomebrewでインストールしたPythonは、「システム管理下の環境」とみなされ、そこに pip install でパッケージを入れると、Homebrewの整合性が壊れる可能性があるため、pipが自動的にブロックするようになっているんです。

つまり、pip install が拒否されるのは正しい挙動。

これを回避するには、以下のいずれかの方法を取る必要があります。

解決策①：仮想環境を使う（最も推奨）

python3 -m venv .venv
source .venv/bin/activate
pip install flet

仮想環境内であれば、pipは自由にパッケージをインストールできます。システムにも影響しないので、最も安全で汎用的な方法です。

解決策②：–break-system-packagesを付ける（応急処置）

pip install flet --break-system-packages

これは強制的にシステム環境にインストールする方法ですが、Homebrew環境を壊すリスクがあるため、基本は非推奨です。私は一度試しましたが、やはり仮想環境での運用に切り替えました。

この経験から、Apple Silicon + Homebrew + Python の組み合わせでは、「最初から仮想環境で作業を始める」ことが最大の防御策だと痛感しました。

そもそもRosettaってなに？必要なケースは？

今回の問題の背景にあった「Rosettaモード」。

Macに詳しくない人にとっては、そもそも「Rosettaってなに？」という状態かもしれません。私自身、正確に理解していたわけではなく、なんとなく「Intel向けアプリを動かすための仕組み」くらいの認識しかありませんでした。

🔍 Rosettaとは？

Rosettaは、AppleがIntel製CPU（x86_64）からApple Silicon（M1/M2/M3など、arm64）へ移行するにあたって導入したトランスレーションレイヤーです。

簡単に言えば、Intel向けに作られたアプリやコマンドを、Apple Silicon上で動かすためのエミュレーターです。

たとえば、昔のPhotoshopやIntel向けのCLIツールなどがRosettaを通して動くようになります。

💻 ターミナルもRosettaで起動できる

実は、ターミナルアプリ自体も「Rosettaモード」で起動することができます。

Finderでターミナルの情報を開き、「Rosettaで開く」にチェックを入れれば、Intel向けの環境として動作させることができるんです。

私はまさにこの設定を使い、意図的にRosettaモードでHomebrewを導入していました。

⚠️ でもPython開発には不要！

ここが今回の重要なポイントです。

PythonやHomebrewなど、Apple Siliconに対応しているツールについては、Rosettaモードは基本的に使う必要がありません。

むしろ、使ってしまうことで「Intel用Homebrewが入る」「パスが複雑になる」「環境が混在する」といった問題を引き起こします。

✅ Rosettaが必要な場面（限られます）

• 古いIntel専用のアプリをどうしても動かしたいとき
• 一部の開発ツールがまだarm64非対応の場合（2025年現在では稀）

つまり、普段の開発やPython環境の構築では、Rosettaは不要どころか、混乱の元になる存在なのです。

まとめ：Apple SiliconユーザーがPython環境を整えるために

今回の私の失敗談を振り返ってみると、環境構築でハマる要因の多くは「古い情報を鵜呑みにしたこと」と「Apple Siliconの特性を正確に理解していなかったこと」にあったと感じます。

特に、RosettaモードでIntel版のHomebrewを入れていたことで、

• Pythonが /usr/bin/python3 や /usr/local/bin/python3 を指してしまう
• pip install がエラーで止まる
• PATHをいくら直しても反映されない

といった問題が次々に発生しました。最終的にIntel版Homebrewをアンインストールし、Apple Silicon（arm64）向けにHomebrewとPythonをクリーンに再インストールすることでようやく環境が整いました。

私と同じように「そろそろ環境を整理しよう」と思った人にこそ、この記事が少しでもヒントになればうれしいです。

🔜 次回予告

次回は、今回少しだけ触れた「pip installで怒られる理由（PEP 668）」についてもう少し深掘りしながら、仮想環境の作り方やpipの使い方、VS Codeとの連携まで詳しく紹介していきます！

ここまでお読みいただきありがとうございました。それでは次の記事でお会いしましょう。
それじゃまたね、ばいばいっ！