閉域網・エッジの呪縛を断つ：Conda-Packによる「動くPython環境」の完全パッケージングとCI/CD自動化
こんにちは。DevOpsリードチーフエンジニアの私だ。
開発者のローカルマシン（MacBookや高性能PC）では完璧に動作するAIモデルやデータパイプラインが、セキュアな閉域網（エアギャップ環境）、工場やプラントのエッジデバイス、あるいは外販先のオンプレミスサーバーに持ち込んだ瞬間、dependency hell（依存関係の地獄）の前に沈黙する――この悪夢に幾度となく直面してきたはずだ。
「`pip install` を走らせようにもインターネットに接続できない」
「`conda install` が依存関係の解決（SAT solver）に何時間も唸った挙句、タイムアウトする」
「Dockerコンテナを使おうにも、現場のレガシーOSやセキュリティポリシーがそれを許さない」
こうしたインフラの制約を鮮やかに、そして根本から粉砕する技術が `conda-pack` だ。
今回は、単なる「Conda環境のバックアップツール」としての使い方ではなく、CI/CDパイプラインと完全に統合し、あらゆるオフライン環境へミリ秒単位で「同一のバイナリ環境」をデプロイする、プロフェッショナル向けのエキスパート知見を授けよう。
—
1. なぜ `conda-pack` なのか？：内部アーキテクチャとバイナリポータビリティの真実
まず、Pythonの依存関係管理におけるパラダイムを整理する。
一般的な `environment.yml` や `requirements.txt` を用いたデプロイは、ターゲット環境で「その場でビルド・解決（Resolve & Build）」を行う。これは、ターゲット環境にインターネット接続、適切なコンパイラ（gcc, MSVCなど）、そしてPyPIやAnaconda Cloudへの名前解決が常時開かれていることを前提とした、脆いアプローチだ。
一方、`conda-pack` は、指定したConda仮想環境のディレクトリツリー丸ごと（Pythonインタプリタ、動的リンクライブラリ `.so` / `.dll`、C拡張モジュール、インストールされた全パッケージ）をアーカイブし、完全な静的（あるいは相対パスリンク化された）ポータブル成果物に変換する。
`conda-pack` の内部動作メカニズム
1. 環境のスキャンとシリアライズ: 指定されたConda環境パス（例: `/opt/conda/envs/ml-core`）を走査する。
2. ハードコードパスの置換（Shebang / Rpath rewriting）: Pythonスクリプトの先頭にあるシバン（`#!/opt/conda/envs/ml-core/bin/python`）や、ELFバイナリの `RPATH` / `RUNPATH` を、アーカイブ展開先の相対パス（またはプレースホルダー）に書き換えるパッチ処理を行う。
3. アーカイブ化: tar.gz や zip として圧縮する。
これにより、ターゲットマシン側に Conda自体がインストールされていなくても、Python実行環境がその場で起動する。この「環境の自己完結性（Self-containment）」こそが、オフ分野の現場において圧倒的なアドバンテージとなる。
—
2. 実践：本番グレードの環境構築とパッケージング手順
ただパッケージを作るだけなら公式ドキュメントを見ればいい。ここでは、クロスプラットフォームの罠（特に glibc のバージョン依存性）を回避しつつ、実運用に耐えうる堅牢な手順を示す。
> ⚠️ 最重要アーキテクトの知見（OSとアーキテクチャの制約）
> `conda-pack` は、ビルドした環境（ホストOS）と、実行する環境（ターゲットOS）のOSディストリビューション、カーネルバージョン、CPUアーキテクチャが完全に一致している必要があります。
> 例えば、Ubuntu 22.04 (x86_64) でパックした環境は、CentOS 7 や macOS では動作しません。閉域網環境へ配布する場合は、「ターゲット環境と同一のOSイメージを持つDockerコンテナ内」で `conda-pack` を実行するのが、DevOpsにおける絶対の鉄則です。
ステップ1: クリーンな環境の構築と依存関係の固定
開発者のマシンではなく、クリーンなDockerコンテナ（例: `python:3.10-slim` ベースにMinicondaを導入したもの）上で作業を開始する。
1. 新規Conda環境の作成（余計なパッケージを入れない）
conda create -n production-env python=3.10 -y
2. 環境のアクティベート
conda activate production-env
3. 厳密なバージョンを指定してパッケージをインストール
※ pipとcondaの混在は依存関係破損の元凶。極力condaチャネルを優先する。
conda install -c conda-forge numpy=1.24.3 pandas=2.0.3 scikit-learn=1.3.0 -y
pip install –no-deps custom-ai-lib==1.2.0 # 外部依存のない独自ライブラリの例
ステップ2: Conda-Packのインストールとアーカイブ生成
ホストまたはコンテナ内に `conda-pack` を導入し、アーカイブを生成する。
conda-pack自体のインストール（ベース環境、あるいは任意の環境に）
conda install -c conda-forge conda-pack -y
出力先ディレクトリを作成
mkdir -p /app/dist
環境をアーカイブ化（–ignore-editable で開発用editableモードのゴミを除外）
–force は既存アーカイブの上書き
conda pack -n production-env \
-o /app/dist/production-env.tar.gz \
–ignore-editable \
–compress-level 6
これで、`/app/dist/production-env.tar.gz` に数千のファイルとライブラリが凝縮された、完全に独立したポータブル環境が完成する。
—
3. ターゲット環境（オフライン・閉域網）での展開とアクティベーション
インターネットが一切通じないターゲットマシンに `production-env.tar.gz` をUSBメモリやセキュアなファイル転送で持ち込んだとする。展開と利用のフローは以下の通りだ。
1. 任意のディレクトリにターゲットフォルダを作成
mkdir -p /opt/app/venv
2. アーカイブを展開（tarコマンドを使用）
tar -xzf production-env.tar.gz -C /opt/app/venv
3. 【超重要】パックされた環境内のスクリプトやパスを現在の絶対パスに再配線（リロケーション）する
Conda-Packは展開時に自動でパス書き換えを行いますが、手動で移動させた場合などは以下を実行します
/opt/app/venv/bin/conda-unpack
これで環境のセットアップは完了している。Pythonを実行してみよう。
フルパスで直接インタプリタを叩く
/opt/app/venv/bin/python -c “import numpy; print(numpy.__version__); print(‘Environment successfully activated offline!’)”
もしシェル上で通常のアクティベートを行いたい場合は、通常のCondaコマンドではなく、環境内にある専用のスクリプトを読み込ませる。
スクリプトのソースを読み込む（activateスクリプトのパスが自動調整されている）
source /opt/app/venv/bin/activate
通常通りpythonコマンドが利用可能になる
python -c “import pandas as pd; df = pd.DataFrame({‘status’: [‘online’, ‘offline’]}); print(df)”
—
4. CI/CDパイプラインへの完全統合：自動ビルドスクリプト
手動でコンテナを立ち上げてパックするのはエンジニアの仕事ではない。GitLab CI や GitHub Actions を用いて、マスターマージ時に自動でオフライン用アーカイブを生成し、アーティファクトとして保存するパイプラインを構築する。
以下に、実戦投入可能な GitHub Actions 워크플로우 (YAML) の完全版を示す。
name: Build Portable Conda Environment
on:
push:
branches:
- main
paths:
- ‘environment.yml’ # 依存関係定義に変更があった場合のみビルド
jobs:
build-pack:
runs-on: ubuntu-22.04 # ターゲット環境と同一のOSを指定
steps:
# 1. リポジトリのチェックアウト
- name: Checkout Repository
uses: actions/checkout@v4
# 2. Minicondaのセットアップ（公式Actionを使用）
- name: Setup Miniconda
uses: conda-incubator/setup-miniconda@v3
with:
auto-update-conda: true
python-version: “3.10”
activate-environment: “build-env”
environment-file: environment.yml
auto-activate-base: false
# 3. パッケージングツールの導入
- name: Install Conda-Pack
shell: bash -l {0}
run: |
conda install -c conda-forge conda-pack -y
# 4. ターゲット環境のパック実行
- name: Pack Conda Environment
shell: bash -l {0}
run: |
mkdir -p dist
# 指定した環境名(build-env)をアーカイブ化
conda pack -n build-env -o dist/ml-env-ubuntu2204.tar.gz –ignore-editable
# 5. 生成物をCI/CDのアーティファクトとして保存（有効期限30日）
- name: Upload Artifact
uses: actions/upload-artifact@v4
with:
name: portable-python-env
path: dist/ml-env-ubuntu2204.tar.gz
retention-days: 30
このパイプラインにより、開発者が `environment.yml` を更新してコミットするだけで、数分後には完全にセキュアでオフラインデプロイ可能なバイナリが生成される。インフラエンジニアは、この成果物（tar.gz）をダウンロードし、ターゲットサーバーに配置するだけでデプロイが完了する。
—
5. エキスパートが直面する罠とパフォーマンス最適化ハック
最後に、現場でこの手法をスケールさせる際に必ずぶ壁と、その回避策を授けよう。
ハック1: アーカイブサイズの肥大化対策（不要なキャッシュとテストの排除）
Conda環境には、コンパイル済みのヘッダーファイルや、テスト用のダミーデータ、不要なロケールファイルが含まれがちだ。何も対策しないと、1つの環境が 2GB~3GB に膨れ上がることもある。
対策: パック前にキャッシュを完全にパージし、不要なファイルを削除する。
condaおよびpipのキャッシュを完全削除
conda clean –all -f -y
pip cache purge
環境内の不要なファイル（__pycache__, .pyc, ユニットテスト用ディレクトリ）を削除
find /opt/conda/envs/production-env -type d -name “tests” -exec rm -rf {} +
find /opt/conda/envs/production-env -type f -name “.pyc” -delete
これにより、アーカイブサイズを 30% 〜 50% 削減できる。エッジデバイスへの転送速度向上に直結する。
ハック2: 実行時パーミッションとシェアードライブラリ（SO）の欠落
ターゲットマシンに glibc のマイナーバージョン差分がある場合や、特定のシステムライブラリ（`libGL.so.1` など、OpenCV等が依存するGUI/画像処理ライブラリ）が欠けている場合、Pythonのインポート時に `ImportError: libGL.so.1: cannot open shared object file` といったエラーが発生する。
根本的解決策:
Conda-Packはあくまで「Pythonパッケージ層」をパックするものであり、OSカーネル層の共有ライブラリまでは同梱しない。そのため、ターゲットマシンの最低限の前提パッケージ（`libgl1-mesa-glx`, `libgomp1` 等）は、デプロイ先OSのパッケージマネージャー（`apt` や `yum`）で事前にインストールしておくこと。これらを網羅した「プロビジョニング用シェルスクリプト」を `conda-pack` のアーカイブとセットで配布するのが、真にプロフェッショナルなDevOpsの作法である。
—
総括
`conda-pack` を用いたポータブル環境の構築は、単なる「裏技」ではない。それは、インターネット接続やビルド環境の有無という、インフラ起因の不確実性を完全に排除し、「コードと環境をひとつのアトミックな成果物として扱う」というモダンなデプロイ思想の具現化である。
閉域網、エッジAI、セキュアなオンプレミス。どのような悪条件の現場であっても、この手法をパイプラインに組み込んでおけば、あなたの書いたAIコードは、一分の狂いもなく、その大地で最高のパフォーマンスを発揮して即座に起動するだろう。
さあ、今すぐビルドスクリプトを書き換え、依存関係の呪縛から開発現場を解放せよ。