Anacondaからuv/venvへの移行で発生した「libomp衝突」の解決策：macOS環境でのデータサイエンス環境構築ガイド
本記事は、macOS（Apple Silicon）環境において、データサイエンスのコンペティション（Kaggle形式）で使用する環境を、従来のAnacondaからuvベースのvenv環境へ移行した際の技術的な課題と解決策を詳細にまとめたものです。筆者は、LightGBM、XGBoost、CatBoost、PyTorch (MPS)といった複数の機械学習ライブラリを組み合わせて使用しています。
移行作業中に遭遇した最大のトラブルは、「PyTorchのMPS学習が成功した直後にLightGBMを実行するとセグフォルト（Segmentation Fault）する」というものでした。この現象は、単体では発生しないという再現条件が重要な手がかりとなりました。根本原因は、PyTorchやscikit-learnがパッケージ内に同梱する独自の`libomp.dylib`（OpenMPランタイム）と、Homebrew経由でシステムが参照する`libomp.dylib`が、同一プロセス内で別ファイルとして二重にロードされ、OpenMPの初期化処理が衝突（衝突）していたためでした。
この問題を解決するため、筆者は、PyTorchやscikit-learnが同梱する`libomp.dylib`を物理的に削除し、代わりにHomebrewが提供する`libomp.dylib`へのシンボリックリンク（symlink）に置き換えるという手法を採用しました。これにより、プロセス内で使用されるOpenMPランタイムを一つに統一し、セグフォルトを解消しました。
また、環境構築の過程で、uv venvで作成した環境にはデフォルトでpipが含まれないため、必ず`uv pip install`を使用する必要がある点や、Anaconda本体の削除手順（`sudo rm -rf`など）も解説されています。本記事は、macOS環境で複雑なライブラリ群を扱う際の、汎用的なトラブルシューティングの型（環境変数の確認、バイナリの依存関係の調査など）を提供しています。
背景
データサイエンス分野では、PyTorch、LightGBM、XGBoostなど、異なるバックエンドライブラリが多数使用されるため、環境構築が非常に複雑になりがちです。特にmacOSのApple Silicon環境では、ライブラリ間の依存関係やOpenMPランタイムの管理が難しく、今回のような「ライブラリAの後にライブラリBを実行するとクラッシュする」という、特定条件下での衝突が頻繁に発生する背景があります。
重要用語解説
- libomp.dylib: OpenMP（Open Multi-Processing）のランタイムライブラリ。複数の計算を並列処理（マルチスレッド）で行う際に、ライブラリが使用する共通の仕組みを提供するファイル。衝突がセグフォルトの原因でした。
- venv: Pythonの仮想環境（Virtual Environment）の略。プロジェクトごとに独立したPython実行環境を構築し、ライブラリの依存関係がシステム全体や他のプロジェクトに影響を与えないようにするための仕組み。
- セグフォルト: Segmentation Fault（セグメンテーション違反）の略。プログラムがアクセスを許可されていないメモリ領域にアクセスしようとした際に発生する致命的なエラー。ライブラリの初期化衝突が原因で発生しました。
今後の影響
本知見は、macOS環境で複数の高性能計算ライブラリ（特にOpenMPを利用するもの）を扱う際の環境構築の標準的なトラブルシューティング手順を提供します。ライブラリのアップデートや環境移行の際、単なるパッケージの再インストールだけでなく、依存ライブラリの物理的な同一性（symlinkの維持）をチェックする重要性を再認識させ、今後の開発効率と安定性を大幅に向上させます。