「ローカルのDockerコンテナでは完璧に動いていた推論APIが、クラウドのGPUインスタンスにデプロイした途端にエラーを吐く。コンテナなのだから環境差異はないはずだろう？」
開発現場では、バックエンドエンジニアからこのような疑問が寄せられるケースが少なくありません。彼らは優秀なWeb開発者であり、DockerやKubernetesの扱いにも長けています。しかし、AI推論サーバー（Inference Server）の構築となると、その「Web開発の常識」が逆に足かせとなってしまうことがあるのです。
Webアプリケーションの世界では、Dockerは「Write Once, Run Anywhere（一度書けばどこでも動く）」を実現する魔法の箱でした。しかし、AI、特にGPUを利用する深層学習モデルの世界では、この魔法には強力な「但し書き」が付きます。
今回は、WebエンジニアがAI推論基盤を構築する際によく陥る「3つの誤解」について、技術的なレイヤーを一段掘り下げて解説します。これは単なるトラブルシューティングではなく、堅牢なMLOps環境を構築し、ビジネス価値を最速で生み出すための設計思想のアップデートです。
なぜ「DockerでAI」はWebアプリのようにいかないのか
まず、前提となる認識を合わせましょう。WebアプリとAI推論アプリのコンテナ化における決定的な違いは、「ハードウェアへの依存度」です。
一般的なWebアプリ（例えばNode.jsやGoで書かれたAPIサーバー）は、CPUとメモリさえあれば動作し、OSのシステムコールを通じてハードウェアリソースを利用します。Dockerコンテナはカーネルをホストと共有しつつ、ユーザーランド（ライブラリや実行ファイル）を隔離するため、OSのディストリビューションが違っても高いポータビリティを発揮します。
「Write Once, Run Anywhere」が通用しないAIの特殊事情
一方、AI推論、特にディープラーニングモデルの推論は、行列演算を高速化するためにGPU（主にNVIDIA製）を酷使します。ここで問題になるのが、アプリケーション（PyTorchやTensorFlow）からGPUハードウェアまでの距離です。
WebアプリがOS標準のシステムコールで事足りるのに対し、AIアプリはCUDAという並列コンピューティングプラットフォームを経由してGPUに命令を送ります。このCUDAのエコシステムは進化が速く、例えばComfyUIのような最新のAIツールでは、パフォーマンスを最大化するために特定のCUDAバージョン（13系など）やPyTorchの最新版（Nightlyビルド等）との組み合わせが推奨されるケースが増えています。
このように、コンテナ内のライブラリバージョンと、ホスト側のGPUドライバが密接に連携しなければならない点が、AI特有の難しさです。「Dockerなら環境を隠蔽できる」というWebの常識は、GPUアクセラレーションが必要な瞬間に崩れ去ります。コンテナの壁を越えてハードウェアリソースを正しく認識させるには、NVIDIA Container Toolkitなどの適切な構成が不可欠です。
開発環境と本番環境の乖離が生むコスト
多くの開発現場では、開発用のPC（例えばMacBook ProやWindowsのWSL2）ではCPU推論や異なるアクセラレータ（Metalなど）で動作確認を行い、本番環境（Linuxサーバー + NVIDIA GPU）でCUDAを使おうとする傾向があります。
特にWindows環境での開発では、TensorFlowなどがネイティブGPUサポートを終了し、WSL2（Windows Subsystem for Linux 2）上での実行が標準となるなど、開発環境の構築手法自体も変化しています。さらに、本番機とはGPUのアーキテクチャやドライババージョンが異なるケースも一般的です。
この時、「コンテナに入れているから大丈夫」と高を括っていると、デプロイ直後に CUDA error: no kernel image is available for execution on the device といったエラーログと対面することになります。これはコードのバグではなく、インフラ設計のミスです。最新のAIモデルが要求する環境と、実際にデプロイするインフラの整合性を無視した結果と言えるでしょう。まずは動くプロトタイプを作り、本番環境との差異を早期に検証するアジャイルなアプローチが求められます。
誤解①：「Dockerならホスト環境を完全に無視できる」
最初の、そして最大の誤解はこれです。Webサーバーの開発であれば、ホストOSにDocker Engineさえ導入されていれば、コンテナの中身がUbuntuだろうがAlpine Linuxだろうが、ホスト環境を意識する必要はほとんどありません。しかし、GPUリソースを使用するAIコンテナの場合、ホスト環境を「無視」することは構造的に不可能です。
透過できない「GPUドライバ」の壁
DockerコンテナからNVIDIA GPUを利用するためには、NVIDIA Container Toolkit（旧 nvidia-docker）が必要です。このツールが何を行っているか、その仕組みを正確に理解しているでしょうか？
実は、GPUを利用するためのドライバは大きく2つのレイヤーに分かれています。
- カーネルモードドライバ: Linuxカーネルモジュールとして動作し、GPUハードウェアを直接制御する部分。
- ユーザーモードドライバ: CUDAライブラリなど、アプリケーションが利用するAPIを提供する部分。
Dockerコンテナの中に内包できるのは、2の「ユーザーモードドライバ（CUDA Toolkitなど）」だけです。1の「カーネルモードドライバ」は、コンテナ化することができず、ホストOSにインストールされたものを共有して使うしかありません。
たとえDockerのバージョンが最新（Server/Client構成が更新された環境）であっても、この物理的な制約は変わりません。コンテナがいかに独立していようとも、ホストOSに入っているGPUドライバのバージョンに強く依存するのです。コンテナ内で最新のCUDAバージョンを使いたくても、ホスト側のドライバが古ければAPIの不整合により動作しません。
CUDAバージョンとカーネルモジュールの整合性問題
NVIDIAはドライバとCUDAバージョンの互換性マトリクスを公開していますが、これを軽視して環境構築を行うと、デプロイ段階で重大な障害に直面します。
例えば、コンテナイメージのベースに最新のCUDAを含むイメージを指定したとします。このコンテナが正常に起動し、GPUを認識するためには、ホスト側のGPUドライバがそのCUDAバージョンをサポートする要件（特定のバージョン番号以上）を満たしている必要があります。
「Dockerを使えば環境構築の手間が省ける」というのはアプリケーション層においては正解ですが、AIインフラに関しては「ホスト側のドライバ管理」というタスクからは逃れられません。これを忘れて、クラウドプロバイダーが提供する古いマシンイメージを使ってインスタンスを立ち上げると、コンテナ内のAIモデルがGPUを認識できず、CPUフォールバックや起動エラーを引き起こす原因となります。
Dockerやcontainerdのバージョンアップによりセキュリティや管理機能が強化されても、この「カーネルとハードウェアの結びつき」は抽象化できない領域であることを、アーキテクトとして認識しておく必要があります。
誤解②：「コンテナイメージは極力軽量化すべき（Alpine Linux信仰）」
Web開発、特にGo言語などの静的リンクバイナリを扱う界隈では、コンテナイメージのベースにAlpine Linuxを採用するのが長らくベストプラクティスとされてきました。数百MBのUbuntuイメージに対し、Alpineなら数MBで済む。セキュリティ面でもアタックサーフェスが小さく魅力的です。
しかし、Pythonを中心としたAIエコシステムにおいて、安易なAlpine Linuxの採用は「茨の道」への入り口と言わざるを得ません。
AIライブラリと軽量Linuxディストリビューションの相性
Alpine Linuxは、標準Cライブラリとして軽量なmusl libcを採用しています。一方、UbuntuやDebian、そして世の中のほとんどのLinuxディストリビューションはglibc（GNU C Library）を採用しています。
問題は、PyTorch、TensorFlow、NumPy、Pandasといった主要なAI/データサイエンス系ライブラリが配布しているビルド済みバイナリ（Wheel）が、基本的にmanylinux、つまりglibc環境を前提に最適化・コンパイルされていることです。
Alpine環境で pip install torch を実行すると、適合するバイナリが見つからず、ソースコードからのコンパイルが走ることがあります。あるいは、Alpine向けに非公式にビルドされたパッケージを探すことになりますが、これにはセキュリティリスクや更新の遅れが伴います。巨大なPyTorchをソースからビルドしようとすれば、複雑な依存関係の解決に加え、数十分から数時間のビルド時間を要することも珍しくありません。
ビルド時間と互換性のトレードオフ
「イメージサイズを数百MB削る」ために、「ビルド時間を大幅に増やし、未知の互換性トラブルのリスクを負う」ことは、AIプロジェクトにおいては合理的なトレードオフとは言えません。ビジネスへの最短距離を描くためには、無駄なビルド時間を削減し、本質的な開発にリソースを集中させるべきです。
Docker Engine自体が進化し、最新バージョンでパフォーマンスやセキュリティ機能が向上しても、このライブラリレベルの依存関係（glibc vs musl）という根本的な構造は変わりません。実際、NVIDIAが公式に提供しているCUDAベースイメージも、基本はUbuntuやRed Hat UBI（Universal Base Image）ベースです。
AI推論サーバーにおいては、素直にDebian (slim) や Ubuntu ベースのイメージを使うのが、安定稼働への近道です。軽量化を図りたい場合は、OSの種類を変えるのではなく、マルチステージビルドを活用してビルド時の依存関係（コンパイラやヘッダーファイルなど）を最終イメージから除外するアプローチが推奨されます。glibcのある標準的な環境で動かすこと、これがAI開発における再現性と生産性を保つための重要なポイントです。
誤解③：「モデルファイルはコンテナイメージに含めるべき」
「アプリケーションコードと必要なデータはすべてコンテナイメージにパッケージングする」。これはWebアプリケーション開発においては標準的なプラクティスであり、イミュータブルインフラストラクチャの理想形とも言えます。しかし、AIモデル（特に重みファイル）をDockerイメージの中に COPY コマンドで埋め込んでしまうのは、多くの場合、運用を破綻させるアンチパターンとなります。
数GB単位のモデル更新が招くデプロイのボトルネック
近年のLLM（大規模言語モデル）や高精細な画像生成モデルは、軽量なものでも数GB、大規模なものでは数十GBから数百GBのサイズになります。これをDockerイメージに含めると、システム全体に以下のような深刻な副作用をもたらします。
- イメージサイズの肥大化とスケーリング遅延: 巨大なイメージは、ビルド、レジストリへのプッシュ、各ノードでのプル、展開のすべてに時間がかかります。オートスケーリングで新しい推論ノードが立ち上がる際、イメージのプルに数分から十数分かかってしまえば、急激なトラフィックスパイクに即応できず、サービス品質の低下を招きます。
- レイヤーキャッシュの効率低下と帯域圧迫: モデルの微調整（Fine-tuning）や再学習を行ってモデルファイルを更新すると、Dockerのレイヤーキャッシュが無効になります。推論コード（Pythonスクリプト等）が一行も変わっていなくても、数GB単位のレイヤーを再度転送することになり、ネットワーク帯域とストレージコストを無駄に消費します。
推論コードとモデルデータのライフサイクルの違い
システム設計の観点から見ると、「推論ロジック（コード）」と「学習済みモデル（データ）」は、ライフサイクル（変更のタイミングと頻度）が根本的に異なります。
- 推論コード: APIの仕様変更、ライブラリのバージョンアップ、バグ修正などで不定期に更新されます。
- モデルデータ: データの蓄積に応じた定期的な再学習や、精度の劣化（ドリフト）検知によるトリガーで更新されます。
これらを密結合させてしまうと、モデルを更新するたびにコンテナビルドが必要になり、逆にコード修正のたびに巨大なモデルのコピーが発生します。これらを分離して管理し、疎結合な状態を保つのがMLOpsおよびLLMOpsの鉄則です。
推奨されるアプローチは、以下の通りです：
- 実行時ダウンロード（Runtime Download）: コンテナ起動時（Entrypointスクリプトなど）に、オブジェクトストレージ（S3、GCSなど）やモデルレジストリから、指定されたバージョンのモデルを動的にダウンロードします。これにより、コンテナイメージは軽量な状態（コードとライブラリのみ）を保てます。
- ボリュームマウント（Volume Mounting）: Kubernetesなどのオーケストレーターを利用する場合、モデルデータを永続ボリューム（PV）として管理し、推論コンテナにRead-Onlyでマウントします。複数のポッドでモデルデータを共有でき、ディスク効率も向上します。
このように「ロジック」と「巨大なステート（モデル）」を分離することで、CI/CDパイプラインは高速化し、運用チームはモデルのバージョン管理とロールバックをより柔軟に行えるようになります。
真にポータブルなAI推論基盤を築くための設計原則
ここまで、Web開発の常識がAI開発で通用しない理由を解説しました。では、私たちはどのようにして「真にポータブル」で安定した推論基盤を築けばよいのでしょうか。
ONNX Runtime / Triton Inference Serverの活用検討
特定のフレームワーク（PyTorchなど）に依存しすぎると、環境構築が複雑になります。モデルをONNX形式などの標準フォーマットに変換し、ONNX RuntimeやNVIDIA Triton Inference Serverのような専用の推論サーバーを利用することを検討してください。
これらはNVIDIAによって高度に最適化されたDockerイメージが提供されており、モデルファイルを外部からマウントするだけで、高速な推論APIを立ち上げることができます。自分で app.py を書いてFlaskやFastAPIでラップするよりも、遥かにパフォーマンスが高く、環境依存のトラブルも少なくなる可能性があります。まずは既存の最適化されたツールを活用し、スピーディーに検証サイクルを回すことが重要です。
環境定義のコード化（IaC）と組み合わせる
結局のところ、Dockerコンテナ単体では完結しません。ホスト側のドライババージョンを含めた環境定義が必要です。
TerraformやAnsibleなどのIaC（Infrastructure as Code）ツールを用いて、「適切なGPUドライバがインストールされたホストOS」を自動構築する仕組みを整えましょう。AWSなら、Deep Learning AMIを使用するようLaunch Templateで定義するのも良いでしょう。
「コンテナの中」だけでなく、「コンテナの外（ホスト）」まで含めてコードで管理する。これが、AI時代における真の「Write Once」への近道です。
まとめ
AI推論サーバーの構築は、Webアプリケーション開発の延長線上にありながら、異なる考慮事項が必要です。Dockerは強力なツールですが、物理層（GPU）との結びつきを無視しては機能しません。
- ホスト依存を直視する: GPUドライバはホスト側の責務。バージョン整合性を常に意識する。
- OSは標準を選ぶ: 軽量化のためにAlpineを選ばず、Ubuntu/Debianで安定性を取る。
- データとロジックを分離する: 巨大なモデルファイルはイメージに含めず、外部から注入する。
これらの原則を守ることで、AIプロジェクトは「手元では動くのに」という問題から解放され、ビジネス価値を生み出すことに集中できるはずです。技術の本質を見極め、最短距離で成果を出すための基盤作りを進めていきましょう。
コメント