Miniforge公式READMEには、Mac向けの配布名としてMacOSX-arm64とMacOSX-x86_64が案内されています。公式READMEのこの違いを見落とすと、再インストールしても問題は残ります。

症状 → 最短の対処
インストーラーが終了する、condaが見つからない、依存関係を解けない、パッケージをimportできない。まずこの4層に分け、該当する証拠を保存してから修復してください。全環境の削除や上書きインストールは、原因が判明するまで止めます。

このガイドは、初めてmacOSでPython研究環境を作る大学院生、Intel・Windows・LinuxからApple Siliconへ移行する研究者、研究室向けに再現可能なconda環境を引き渡す技術担当者向けです。

最初に4層へ分けて、削除を止める

反復的な再インストールは、アーキテクチャ、PATH、依存関係、ネイティブライブラリの問題を直しません。次の観察結果で分岐します。

  • インストーラーが途中で終了する
    → インストーラーの種類、終了コード、表示された最後の20行を保存します。
  • インストール後にconda: command not foundになる
    → ShellのPATHと初期化設定を調べます。
  • UnsatisfiableErrorなどで環境を作れない
    → チャンネル、対象ビルド、バージョン制約、通信失敗を分離します。
  • 環境は作れるがimportに失敗する
    → Python本体、ネイティブライブラリ、Jupyterカーネルの対応を確認します。

ログを残さずに削除すると、研究室の別端末で同じ失敗を再現できません。課題名、使用したインストーラー名、実行日時、エラーメッセージを1つのテキストへまとめてください。

第一段階：arm64とインストーラーを照合する

ターミナルで次を実行します。

uname -m
file ~/Downloads/Miniforge3-*.sh

uname -mがarm64なら、原則としてMacOSX-arm64を選びます。実際のファイル名はMiniforgeの最新Releaseで確認してください。x86_64版はIntel向けです。Rosettaを利用する構成は、Intel専用ツールなど明確な理由がある場合だけ別環境として扱います。AppleのRosetta説明でも、Intel向けアプリをApple Silicon上で動かすための仕組みとして説明されています。

次に、インストール先を確認します。

ls -ld ~/miniforge3 ~/mambaforge 2>/dev/null
file ~/miniforge3/bin/python 2>/dev/null

古いx86_64環境が残っている場合、すぐに消さず「旧環境」と記録してください。新しいarm64環境と比較できるため、移行時の依存関係調査に役立ちます。公式配布物以外の再パッケージ版の挙動を、Miniforge公式の対応範囲だと判断しないでください。

注意：インストーラーが失敗した場合は、表示されたエラー、対象ファイル名、インストール先を保存してから次へ進みます。原因不明のまま同じコマンドを何度も実行すると、Shell設定だけが複雑になります。

第二段階：conda、PATH、Shell初期化を直す

インストールは成功したのにcondaが見つからない場合、次の出力を保存します。

echo $SHELL
type -a conda
echo $PATH
conda info --base

type -a condaで複数の場所が表示されるなら、古いMiniforge、別のconda、システム側の実行ファイルが競合しています。~/.zshrcを先にバックアップし、conda initializeの範囲、Miniforgeのbinパス、重複したPATHを確認してください。設定ファイル全体を上書きする方法は避けます。

cp ~/.zshrc ~/.zshrc.backup
grep -n "conda\|miniforge\|mambaforge" ~/.zshrc

修正後に新しいターミナルを開き、type -a condaとconda info --baseを再確認します。base環境が自動で有効になること自体は、初期化設定の結果である場合があります。研究用プロジェクトでは、baseへパッケージを追加し続けず、課題ごとに新しい環境を作る方が切り分けやすくなります。conda公式の環境管理手順も、環境の作成・一覧表示・書き出しを分けて説明しています。

第三段階：conda-forgeの解決失敗を分解する

osx-arm64向け研究パッケージが見つからない場合、原因は1つとは限りません。次の順序で調べます。

  1. チャンネル設定が意図したものか確認する。
  2. パッケージにosx-arm64ビルドが存在するか確認する。
  3. Pythonや主要ライブラリのバージョン制約を確認する。
  4. ダウンロードURL、証明書、学内ネットワークの失敗を分ける。
  5. baseではなく空の検証環境で再試行する。

conda-forgeを追加しただけで、研究プロジェクトが再現できるとは限りません。特定のパッケージがApple Silicon用に提供されていない場合、対応版へ下げる、別パッケージへ置き換える、Intel構成を独立して検証する、といった選択が必要です。解決が成功しても、実データを処理できるとは限りません。

第四段階：importとJupyterLabの経路を一致させる

「ターミナルでは動くのにJupyterLabでは失敗する」場合、Notebookが別のPythonを使っていることがあります。まず次を実行します。

which python
python -c "import sys; print(sys.executable)"
which jupyter
jupyter kernelspec list

表示されたPythonのパス、Jupyterのパス、カーネルのパスが同じ環境に属しているかを照合します。動的ライブラリのエラーなら、Pythonパッケージだけでなく、arm64とx86_64のネイティブ依存が混在していないかを確認します。

JupyterLabの導入方法は公式インストール文書を基準にしてください。起動できたかだけで判断せず、課題に使う入力データの縮小版で、読み込み、解析、出力保存まで確認します。

研究室で渡せる環境にする手順

本機に複数のcondaが残っている、移行履歴が長い、研究室に安定したMacがない。こうした場合は、隔離したApple Silicon Macで最小環境を作ると、問題がプロジェクト由来か端末由来かを分けられます。

  1. uname -mで対象Macのアーキテクチャを記録します。
  2. Miniforge公式Releaseから対応するインストーラーを取得します。
  3. 課題専用の新しいconda環境を作成します。
  4. 必須パッケージだけを追加し、主要なimportを確認します。
  5. 実際の研究データを小さくしたサンプルで処理します。
  6. environment.ymlなどへ環境定義を書き出します。
  7. 別のクリーン環境で再作成し、同じ結果になるか確認します。
  8. Pythonのパス、Jupyterカーネル、入力データの保存場所を引き渡し資料へ記載します。

交付前の可否チェック

  • [ ] arm64またはx86_64の選択理由を記録した
  • [ ] conda info --baseが意図したインストール先を示す
  • [ ] baseではなく課題専用環境を使っている
  • [ ] 主要パッケージのimportを確認した
  • [ ] JupyterLabが同じPython環境を参照している
  • [ ] 実データの縮小サンプルを最後まで処理した
  • [ ] 環境を書き出し、別環境で再作成した
  • [ ] エラー全文と修正内容を記録した

研究現場のケース

Windowsで作った環境定義をApple Silicon Macへそのまま移すと、Pythonパッケージの一覧は同じでも、ネイティブ依存だけが解決できないことがあります。逆に、クリーンなarm64環境では最小構成が作成できるなら、原因はMac全体ではなく、旧環境の固定バージョンや混在したPATHに絞れます。

この切り分けが済む前に、既存環境を丸ごと移行しないでください。先に最小構成と実サンプルを再現し、その後に必要な依存だけを一つずつ追加します。

よくある判断をFAQで確認する

Miniforgeを入れた後、condaコマンドがない

インストール先が存在するか、現在のShellがzshか、PATHに別のcondaが先にないかを確認します。~/.zshrcを保存してから初期化設定を修正し、新しいターミナルで再確認します。

Apple Siliconではどのインストーラーを選ぶか

uname -mがarm64なら、通常は公式のMacOSX-arm64版です。Intel向けのx86_64版は、Rosettaを使う独立した検証目的に限定します。

condaをactivateできない場合

type -a conda、conda info --base、echo $SHELLを保存します。複数のインストール先をPATHへ残さず、設定ファイル全体を消去せずに初期化部分だけを修正します。

osx-arm64用の研究パッケージがない場合

conda-forgeの設定だけで解決しない場合があります。対象パッケージのビルド、バージョン制約、通信失敗を分け、対応版または別アーキテクチャの検証環境を別に用意します。

既存環境と遠隔Macをどう選ぶか

手元のMacを使い続ける利点は、物理ファイルや周辺機器へ直接アクセスできることです。一方、複数のconda履歴が残っている、Shell設定を共有している、研究室のLinux・Windows端末しか使えない場合は、原因の再現と環境の引き渡しに時間がかかります。

購入は長期的に固定した重い処理や物理インターフェースが必要な場合に向きます。ただし、短期の論文解析、授業、移行検証だけなら初期費用と保守の負担が先に発生します。クリーンなApple Silicon環境を研究期間だけ使いたいなら、MACCOMEの日本語案内から利用形態を確認し、Mac miniの注文案内も比較材料にしてください。

実験室の既存環境には、古いPATH、共有設定、Intel向け依存、利用できないmacOS環境という欠点があります。これらを抱えたまま直すより、MACCOMEで利用できる遠隔Mac上に最小環境を作り、実サンプル、書き出し、再作成まで確認する方が、原因判定と一時的な研究作業を分離しやすい場合があります。長期の固定負荷や物理接続が必要なら自購入を選び、環境再現や短期の算力・検証環境が目的ならレンタルを候補にしてください。