NOAH の GPCR Docker デプロイでハマった話：DSSP 依存関係の衝突から NVIDIA GPU・ネットワークプロキシまで

はじめに

昨日、たまたま Kojima らが Nature Structural & Molecular Biology に発表したばかりの論文 Universal pipeline for high-resolution GPCR structure determination を読んだ。この論文が焦点を当てているのは、GPCR 構造解析における極めて実際的な問題だ。G protein などの安定した結合パートナーを持たない inactive-state GPCR、特に antagonist-bound 状態では、高分解能 cryo-EM 再構成に耐える発現量・安定性・剛性を備えたコンストラクトを見つけるまで、TM5-ICL3-TM6 領域で融合位置を何度も試し替える必要が生じることが多く、実験によるスクリーニングのコストが非常に高い。

著者の手法は、互いに補完し合う二つの部分からなる。まず NOAH が TM5-TM6 融合コンストラクトを列挙し、ColabFold で構造を予測する。その後、リンカー領域が連続した α-helix を保っているか、局所 pLDDT、helix phase、融合タンパク質と膜境界との距離を順にチェックし、数百の組み合わせの中から、実験で検証する価値の高い少数の候補を絞り込む。さらに著者は、約 40 kDa でより剛性の高い de novo 融合パートナー ARK1 を設計し、cryo-EM 粒子のアライメントを助ける fiducial marker として、複数の Class A GPCR と異なるリガンド状態で検証を完了している。

この手法はボタンひとつで実験構造がすぐ得られるというものではなく、その後も発現、精製、試料調製、cryo-EM 計測が必要だ。現時点での体系的な検証も、主に Class A GPCR を対象にしている。とはいえ、inactive-state GPCR や antagonist complex に取り組んでいる課題、あるいは融合コンストラクトのスクリーニングで長く足踏みしている課題にとっては、初期の試行錯誤をかなり減らせる可能性がある。そこで、まず NOAH の計算パイプラインを再現し、手元や周辺の課題に役立つかを確かめてみることにした。この記事に記録しているのは、そのデプロイの過程で遭遇した問題だ。

第一歩として、NVIDIA GPU を搭載した Linux サーバーに NOAH をデプロイしてみた。NOAH は GPCRdb のデータ、DSSP、PPM3、ColabFold をオーケストレーションし、候補コンストラクトのスクリーニングを行う。プロジェクトには Dockerfile が用意されており、コマンド 3 つで起動できるように見えた：

git clone https://github.com/hekato-lab/noah_gpcr
cd noah_gpcr
docker build -t noah_gpcr .

だが、実際のデプロイはそううまくいかなかった。DSSP の依存関係の非互換、Docker で NVIDIA GPU が使えない、サーバーから外部リソースへのアクセスが不安定、実行パラメータの説明不足といった問題に次々と直面した。この記事には、原因特定の全過程と、最終的に再利用可能な形にまとめたデプロイ方法を記録する。

NOAH の現在の LICENSE は非商業的な研究・教育目的のみを許可しており、オリジナルまたは改変版を第三者へ再配布すること（公開 GitHub リポジトリへのアップロードを含む）を明確に禁止している。そのため、改変後の内容を公開することはできない。この記事で共有するのはデプロイの考え方とトラブルシューティングの経験だ。同じような問題に直面したら、この記事をコンテキストとして AI に渡してみてほしい。デプロイがずっとスムーズに進むはずだ。

1. ビルド失敗：DSSP と libmcfp のバージョン組み合わせが不安定

最初に直接 docker build を実行したとき、問題は DSSP 環境にあった。mkdssp と dssp は見つかるものの、バージョン確認や Biopython からの呼び出しでは正常に動作しなかった。つまり、問題は「DSSP がインストールされていない」ことではなく、DSSP と下層の libmcfp のバイナリインターフェースとの組み合わせが非互換だったのだ。

元の Dockerfile は、まず NOAH 用の Conda 環境を作成して DSSP をインストールし、その後で gsutil を別途インストールしていた。この 2 回の独立した Conda ソルバー実行により、先にインストール済みの間接依存関係が更新されてしまった可能性がある。さらに、元の PATH は ColabFold 環境を NOAH 環境より先に置いていたため、誤った環境のプログラムや動的ライブラリを呼び出してしまうリスクも高めていた。

最終的に採用した対処は次の 4 点だ：

1. dssp、libmcfp、gsutil を同じ Conda solve にまとめる。
2. 互換性を確認済みのバージョンに固定する：dssp=4.6.1、libmcfp=2.0.1。
3. NOAH 環境を ColabFold 環境より前に置く。
4. イメージのビルド段階で mkdssp --version と dssp --version を直接実行し、エラーをできるだけ早く顕在化させる。NOAH を長時間動かしてから失敗する事態を避けるためだ。

主な修正の方針は次のとおり：

ENV PATH=/opt/conda/envs/noah/bin:/opt/conda/envs/colabfold/bin:/opt/conda/bin:/opt/noah/ppm3_code:${PATH}

RUN ${CONDA_DIR}/bin/conda create -y -n ${NOAH_ENV} -c conda-forge \
    python=3.12 \
    pip \
    dssp=4.6.1 \
    libmcfp=2.0.1 \
    gsutil

RUN test -x /opt/conda/envs/${NOAH_ENV}/bin/mkdssp && \
    ln -sf mkdssp /opt/conda/envs/${NOAH_ENV}/bin/dssp && \
    /opt/conda/envs/${NOAH_ENV}/bin/mkdssp --version && \
    /opt/conda/envs/${NOAH_ENV}/bin/dssp --version

2. ホストで GPU が見えていても、Docker で GPU を使えるとは限らない

2 つ目の問題は GPU レイヤーで起きた。サーバー上で nvidia-smi が正常でも、NVIDIA ドライバが正常に動作していることしか証明できない。Docker で GPU をコンテナに公開するには、NVIDIA Container Toolkit のインストールと設定が別途必要だ。

まず、Docker が現在どの runtime を認識しているかを確認できる：

nvidia-smi
docker info | grep -i runtime

Ubuntu または Debian では、NVIDIA Container Toolkit 公式インストールドキュメントに従って設定した。以下のバージョン番号は、2026-08-30 時点で公式ドキュメントに記載されていた 1.20.0-1 だ。今後デプロイする際は、まず公式ページで現在のバージョンを確認してほしい。

sudo apt-get update
sudo apt-get install -y --no-install-recommends \
  ca-certificates \
  curl \
  gnupg2

curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey \
  | sudo gpg --dearmor \
      -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg

curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list \
  | sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' \
  | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list

sudo apt-get update

export NVIDIA_CONTAINER_TOOLKIT_VERSION=1.20.0-1
sudo apt-get install -y \
  nvidia-container-toolkit=${NVIDIA_CONTAINER_TOOLKIT_VERSION} \
  nvidia-container-toolkit-base=${NVIDIA_CONTAINER_TOOLKIT_VERSION} \
  libnvidia-container-tools=${NVIDIA_CONTAINER_TOOLKIT_VERSION} \
  libnvidia-container1=${NVIDIA_CONTAINER_TOOLKIT_VERSION}

sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

nvidia-ctk runtime configure はホストの /etc/docker/daemon.json を変更し、Docker が NVIDIA runtime を呼び出せるようにする。設定後は docker info だけを見るのではなく、実際に一時コンテナを起動して検証するのがよい。NVIDIA 公式が示すテストコマンドはこれだ：

sudo docker run --rm --runtime=nvidia --gpus all ubuntu nvidia-smi

このコマンドがコンテナ内で GPU 情報を出力できて初めて、GPU runtime の設定が完了したと言える。対応する公式の検証方法は Running a Sample Workload を参照。

3. Docker ビルドにプロキシを渡す

NOAH のイメージビルドでは、Conda、PyPI、GitHub、Google Cloud Storage などの外部サービスへのアクセスが必要になる。サーバーのネットワークが制限されている場合は、まずホストのターミナルでプロキシを設定するとよい：

export http_proxy="http://<PROXY_HOST>:<HTTP_PORT>"
export https_proxy="http://<PROXY_HOST>:<HTTP_PORT>"
export all_proxy="socks5://<PROXY_HOST>:<SOCKS_PORT>"

これらの export は、現在のホスト Shell とそこから起動した通常のプロセスにだけプロキシを設定するので、ホスト上の git clone などのコマンドのネットワーク問題は解決できる。ところが Docker は、イメージビルド中に Dockerfile の RUN 環境へこれらの環境変数を自動で渡してくれない。その結果、ホストではリポジトリのクローンが正常にできるのに、docker build 内の wget、Conda、pip、gsutil などは依然としてタイムアウトする。

そこでビルド時には、--build-arg でプロキシを明示的に渡す：

docker build --progress=plain \
  --build-arg HTTP_PROXY="$http_proxy" \
  --build-arg HTTPS_PROXY="$https_proxy" \
  --build-arg ALL_PROXY="$all_proxy" \
  -t noah_gpcr .

ここで $http_proxy、$https_proxy と $all_proxy はホストの現在の Shell から取得し、--build-arg でビルド環境へ渡す。プレースホルダを自分のプロキシアドレスに置き換えればよい。Docker にはすでに HTTP_PROXY、HTTPS_PROXY、ALL_PROXY などのプロキシ用ビルド引数が定義されているので、プロキシのために Dockerfile に永続的な ENV を追加する必要はない。そうしないと、プロキシアドレスがイメージの設定に残ってしまう可能性がある。詳しくは Docker CLI プロキシドキュメント を参照。

4. README の補足

元の README には最小限のコマンドしか書かれておらず、どのパラメータが必須なのか、デフォルト値は何か、結果がどこに書き出されるのかが体系的に説明されていない。コマンドをそのまま写すと、いくつかの疑問がすぐに浮かぶ。-m を省略するとどうなるのか？-f は必須なのか？--reverse は、逆スクリーニングを有効にするのか無効にするのか。そもそも、そんなパラメータがあることすら知らない人も多い。

NOAH の主要コマンドは次のようにまとめられる：

python run_noah.py \
  -n <GPCR> \
  -p <PPM3_CODE_DIR> \
  [INPUT_OPTIONS] \
  [RUN_OPTIONS]

最も重要なパラメータは以下のとおり：

もう 1 つの重要な点は、NOAH に独立した --output パラメータがなく、結果は現在の作業ディレクトリに書き出されることだ。ターゲット、コンフォメーション、融合タンパク質が異なる場合は、それぞれ別の空ディレクトリを使うべきだ。既存の結果ディレクトリでそのまま再実行すると、一部のファイルが排他方式で作成されるため失敗する可能性がある。

そこで、ターゲット、コンフォメーション、融合タンパク質を RUN_ID に含め、-m と -f を明示的に渡すことをおすすめする。デフォルト値に頼らないように：

export OUTDIR=/path/to/noah_runs
export RUN_ID=v2r-inactive-ark1

mkdir -p "$OUTDIR/noah_run/$RUN_ID"
mkdir -p "$OUTDIR/colabfold_cache"

docker run -d --rm \
  --gpus device=0 \
  --name noah_v2r_ark1 \
  -v "$OUTDIR/noah_run/$RUN_ID:/work/out" \
  -v "$OUTDIR/colabfold_cache:/root/.cache/colabfold" \
  noah_gpcr \
  bash -lc 'cd /work/out && /opt/conda/envs/noah/bin/python /opt/noah/run_noah.py -n v2r -p /opt/noah/ppm3_code -d /opt/noah/database -m Inactive -f ARK1'

ここでは --gpus device=0 を使い、0 番目の GPU だけをコンテナに公開している。これは「すべての GPU を公開してから CUDA_VISIBLE_DEVICES=0 を設定する」より直接的だ。Docker で GPU を指定する公式の説明は GPU access を参照。

現在の NOAH は候補コンストラクトごとに ColabFold を順番に呼び出すため、サーバーに GPU が複数枚あっても、コマンドで --gpus all を使えば自動的にほぼ線形の高速化が得られるわけではない。スケジューリングのロジックを自分で改造していないのであれば、1 つのタスクに 1 枚の GPU を割り当てる方が分かりやすく、異なるタスクを別々の GPU に振り分けるのも容易だ。

タスクをバックグラウンドモードで起動したら、次のように進捗を確認できる：

docker logs -f noah_v2r_ark1
nvidia-smi -l 2

5. なぜ改変版リポジトリを公開しないのか

後から来る人が同じ罠にはまらないように、Docker の依存関係ロックと README のパラメータ説明を整理し、個人の fork に修正をコミットしたこともある。しかし NOAH のプロジェクトライセンスはコードの再配布を明確に制限しており、オリジナルまたは改変版を公開 GitHub リポジトリにアップロードしてはならないとも明記されている。GitHub は公開リポジトリのネイティブ fork について別途プラットフォーム上の条項を設けてはいるが、ライセンス解釈の衝突を避け、作者が示した利用範囲を尊重するため、改変版リポジトリの公開配布はやめることにした。修正は自分の内部・非商業研究環境にのみ残している。

したがって、この記事ではデプロイの過程とトラブルシューティングの考え方だけを共有し、改変版リポジトリのリンクは提供しない。読者はオリジナルのリポジトリからコードを取得し、そのライセンスに従ってほしい。改変版の公開、第三者への配布、商業利用が必要な場合は、まず作者の明確な許可を得ること。

まとめ

今回の NOAH デプロイから得られた経験は、最終的に次の 4 点にまとめられる：

• 研究用イメージは Conda の動的ソルバーに完全に依存せず、重要なバイナリと基盤ライブラリは検証済みのバージョン組み合わせに固定する。
• ホストのドライバ、Docker Engine、NVIDIA Container Toolkit はそれぞれ別の 3 層のコンポーネントであり、nvidia-smi が正常でも、コンテナで GPU が使えるとは限らない。
• ネットワーク障害は、ホスト、Docker daemon、ビルドコンテナの 3 層に分けて切り分けること。プロキシは、実際にリクエストを発する層に設定しなければならない。

NOAH 自体のアイデアは非常に価値がある。しかし、それを安定して再現可能なサーバーワークフローにするには、環境の固定、GPU runtime、ネットワーク設定、実行ドキュメントの 4 つがすべて欠かせない。