※この記事は、個人技術ブログ CodeArchPedia.com の技術メモ（要約）です。
データ分析プロジェクトで scipy を使っていたら、突然 ImportError: cannot import name 'triu' from 'scipy.linalg' に出くわした。最初は単なるタイプミスかと思ったが、どうやら scipy や依存ライブラリのバージョン更新が原因で、インポート先が変わってしまったらしい。この手の依存関係の衝突は、環境構築で最も手間のかかるポイントだ。
何が起きたか（課題）
大規模なデータパイプラインを動かそうとした際、以下の状況でエラーが頻発した。
-
gensimや他の機械学習ライブラリが、古いバージョンのscipyの構造を前提としてコードが書かれていた。 -
scipyがメジャーアップデートを繰り返し、線形代数系の関数 (triuなど) の格納場所が変更された。 - 結果として、コードは通るのに実行時に関数が見つからないという状況に陥った。
これは、依存関係地獄の典型例だ。放置すると、特定の環境でしか動かない不安定なコードベースになってしまう。
どう解決したか（概要）
解決のアプローチは、環境をクリーンにし、依存ライブラリ間の整合性を強制的に揃えることだった。闇雲にパッケージを入れ替えるのではなく、以下の手順を順序立てて実行した。
-
仮想環境の再構築: まず、システム環境を汚さないため、
venvやcondaを使ってクリーンな環境を新しく作成した。これが全ての基本だ。 -
ライブラリの最新化: 依存関係が複雑な場合、まずは
scipyと依存元であるgensimを同時に最新版へアップグレードした。
pip install --upgrade scipy gensim
これで多くの場合、関数が正しいパスに移動していれば解決する。もし特定の古いバージョンでないと動かない場合は、互換性のあるバージョンを見つけ、requirements.txt でバージョンを明示的に固定する戦略を取った。
依存関係の管理には、Poetry や Pipenv を導入し、ロックファイルを使って環境の再現性を担保することが、シニアエンジニアとしては鉄則だと改めて認識した。
効果（Before/After）
以前は、ある環境では動いても、CI/CD環境や他の開発者の環境ではこの ImportError が再発していた。原因がバージョン不一致だと特定できた後、バージョン管理ツールを導入した結果、デプロイ環境での失敗がほぼゼロになった。特に、scipy のようなコンパイル依存性のあるライブラリでは、環境の再現性がパフォーマンスと安定性に直結する。
| 項目 | 対策前（手動管理） | 対策後（Poetry/Pipenv導入） |
|---|---|---|
| エラー再発率 | 高（週に数回） | ほぼゼロ |
| 環境構築時間 | 30分〜1時間（依存解決） | 5分以内（ロックファイル適用） |
🚀 詳細な設定とコードはこちら
具体的なWAFのルール設定や、より詳細なログ解析データは元のブログで公開しています。