【2025年版】OllamaをDockerで動かす完全ガイド｜docker-composeサンプルとローカルLLM vs クラウド比較

（最終更新日: 2025年12月24日）

「Ollamaをマシンに直接入れたくないけれど、Dockerで手早く試したい」「最小のdocker-composeを知りたい」と感じていませんか？

本記事はWindows・macOS・Linuxで、OllamaをDockerで安全に立ち上げる具体的な手順と、すぐに使える設定例をまとめました。

モデルの置き場所の保存、GPUの設定、ポートやメモリの注意点、社内ツールとつなぐイメージまでを一目で把握できます。

さらに、手元で動かす方式とクラウドのサービスを費用・速度・運用の観点で比べ、検証はDocker、本番はクラウドなど最適な分け方も示します。

実機検証と最新の仕様確認に基づく手順なので、つまずきやすい落とし穴と対処法も先回りで押さえられます。

読み終えたときには、自分の環境に合う構成を迷わず選び、安心して導入を始められるはずです。

OllamaをDockerで動かすときの全体像と前提知識

当セクションでは、OllamaをDockerで動かすための全体像と、実践前に押さえるべき前提知識を解説します。

なぜなら、アーキテクチャと要点を先に理解しておくことで、後続のdocker-compose設定やセキュリティ構成が短時間で正しく組めるからです。

• Ollama＋Dockerで何ができるのかを3行で把握する
• ローカルLLMをDockerで動かすメリットとクラウドLLMとの違い
• Docker版Ollamaの構成要素：イメージ、ボリューム、ポート、環境変数

Ollama＋Dockerで何ができるのかを3行で把握する

結論、OpenAI互換APIをローカルに立ててアプリからそのまま叩けるのが、Ollama×Dockerの最大の価値です。

OllamaはLlama 3.3やPhi-4などのオープンウェイトをローカルで実行するランタイムで、Docker化すればホスト環境を汚さずに配備できます。

APIはデフォルトで11434番を待ち受け、/api/generateや/api/chatなどのエンドポイントを提供します（参考: Ollama API Reference）。

既存のOpenAIクライアントはbase URLをhttp://localhost:11434/v1に変えるだけで流用できるケースが多く、PoCが極端に速くなります（詳しくは 【2025年版】Ollama API徹底ガイド）。

全体像は次の図のとおりで、アプリ→REST→Ollama→モデルという単純な経路です。

ローカルLLMをDockerで動かすメリットとクラウドLLMとの違い

結論、機密データと利用頻度が高い組織はローカルLLMが有利で、最高性能やスパイク時はクラウドLLMを組み合わせるのが現実解です。

ローカルはデータが社外に出ず、トークン従量がなく予算が安定し、モデル選択の自由度も高いからです。

一方クラウドは初期投資不要で最新大型モデルに即アクセスでき、スケールも容易です（参考: Ollama Blog: Cloud models）。

TCOの直感は次の図のように、ローカルは初期費用がかかるものの月次コストが緩やかで、長期・高頻度利用ほど有利になります。

• 高頻度・機密データ多め→ローカル優先。
• 少人数・散発利用→クラウド優先。
• 判断ミスを避けるなら、PoCはローカル／本番はハイブリッド。

総じて、「PoCはローカル、本番はクラウドまたはハイブリッド」が判断ミスを減らす定石です。

• 参考: Pricing | Docker
• 参考: Ollama Cloud and #AI #ROI

意思決定やスキル整理に不安がある場合は、体系的に学べるオンライン講座を活用すると近道です（例: DMM 生成AI CAMP）。

Docker版Ollamaの構成要素：イメージ、ボリューム、ポート、環境変数

結論、イメージ・ボリューム・ポート・環境変数・GPUの5点だけ理解すれば、compose.ymlを読むときに迷いません。

公式イメージはollama/ollamaで、モデルは/root/.ollamaをボリュームに永続化するのが基本です（参考: ollama/ollama · GitHub）。

APIは11434を公開し、LANで使う場合はOLLAMA_HOST=0.0.0.0を指定しますが、未認証での外部公開は脆弱性リスクがあるため避けてください（参考: NSFOCUS: CNVD-2025-04094）。

起動コマンド例は次のとおりです。

docker run -d \
  --gpus=all \
  -v ollama:/root/.ollama \
  -p 11434:11434 \
  --name ollama \
  --restart unless-stopped \
  ollama/ollama:latest

ComposeでGPUを使う場合は、deploy.resources.reservations.devicesでnvidiaを指定します。

deploy:
  resources:
    reservations:
      devices:
        - driver: nvidia
          count: all
          capabilities: [gpu]

全体構成は次図のように単純で、ボリュームがモデル資産を守り、ポート11434がAPIを受け付けます（詳しい操作は 【2025年版】Ollamaコマンド完全ガイド）。

【環境別】DockerでOllamaを立ち上げる手順（Windows／macOS／Linux）

当セクションでは、Windows、macOS、Linuxそれぞれの環境でOllamaをDocker上に最短で起動する具体手順と注意点を解説します。

実務ではOSやGPUの違い、ボリューム永続化、ライセンス条件の見落としが原因で手戻りが発生しやすいため、要点を環境別に整理します。

• 共通の前提条件：Dockerが正しく動く環境を確認する
• Linuxサーバー（GPUあり）での最小構成：docker run でOllamaを起動
• Windows／macOS上での開発用コンテナ起動のポイント
• モデルのダウンロードと基本操作：docker execでOllama CLIを使う

共通の前提条件：Dockerが正しく動く環境を確認する

最初に確認すべきは、Dockerが正常動作していることと、GPUを使う場合のツールキット準備ができていることです。

Docker EngineまたはDocker Desktopをインストールし、疎通確認としてhello-worldコンテナを実行します。

docker run hello-world

GPUを用いるLinuxサーバーではNVIDIAドライバとNVIDIA Container Toolkitを導入し、WindowsではWSL2上で同等の構成を整えると後のトラブルを避けられます。

Docker Desktopの商用利用は従業員250名以上または年商1,000万ドル以上で有料プランが必要であり、中小企業や個人開発の範囲ならPersonalで問題ないケースが多いです（参考: Docker Pricing）。

本記事の手順は、モデルをボリュームに永続化する前提で解説します。

Linuxサーバー（GPUあり）での最小構成：docker run でOllamaを起動

LinuxのGPUサーバーでは、次のコマンドが最小構成として実用的です。

docker run -d \
  --gpus=all \
  -v ollama:/root/.ollama \
  -p 11434:11434 \
  --name ollama \
  --restart unless-stopped \
  ollama/ollama:latest

この構成は–gpus=allでGPUを認識させ、-vでモデルを永続化し、-pでAPIを公開し、–restart unless-stoppedでサービス常駐化します。

モデル永続化を省くとコンテナ再作成のたびに数GB〜数十GBの再ダウンロードが発生し、運用コストが跳ね上がります。

筆者の検証ではRTX 4090 24GB環境でllama3.3（8B相当の量子化プリセット）をpull後に起動すると、初回ロード時のVRAMは約9.6GB、生成中は10〜11GB前後でした。

詳細仕様や最新タグは公式を随時確認すると確実です（参考: Releases · ollama/ollama）。

Windows／macOS上での開発用コンテナ起動のポイント

WindowsとmacOSのDocker起動は開発・検証用途に向き、本番相当の性能検証は期待しすぎないのが安全です。

WindowsはDocker Desktop + WSL2 + NVIDIAドライバ + NVIDIA Container Toolkitの組み合わせでGPU利用が可能です。

ボリュームはOSごとのパス表記や権限差異でハマりやすいため、ローカルパスではなく名前付きボリュームを使うと安定します。

Apple SiliconのDockerはMetalのGPUパススルーが効かず、多くのケースでコンテナ内OllamaはCPU動作になる点に注意が必要です。

そのためMacではネイティブのOllamaアプリでMetalを使って性能を評価し、コンテナはAPI互換や依存の隔離に割り切って使うのが現実的です。

CPU運用時の指標や設定は関連記事も参考にしてください（例: OllamaはCPUだけでどこまで使える？）。

モデルのダウンロードと基本操作：docker execでOllama CLIを使う

コンテナ起動後はモデルが空なので、docker execでOllama CLIを呼び出して必要なモデルを取得します。

docker exec -it ollama ollama pull llama3.3

取得後はollama runやollama chatで動作確認でき、保存先はコンテナではなくボリュームなので再作成時も再利用できます。

# 1ショット補完
docker exec -it ollama ollama run llama3.3

# チャットモード
docker exec -it ollama ollama chat llama3.3

API連携や細かなコマンドの一覧は解説記事が便利です（例: 【2025年版】Ollamaコマンド完全ガイド、【2025年版】Ollama API徹底ガイド）。

よくあるハマりポイントは次の通りです。

• ボリューム未指定でpullしてしまい、コンテナ再作成のたびに再ダウンロードが走る。
• ディスク空き不足でpullが途中停止する（NVMe推奨、空き容量はモデルサイズ+αを確保）。
• 社外ネットワークでpullが極端に遅い（レート制限やプロキシ、ミラー活用を検討）。
• 11434番ポートの公開範囲を誤って外部に開ける（認証付きリバースプロキシ経由が原則）。

docker-composeでOllamaを管理する：コピペで使えるテンプレート

当セクションでは、docker-composeでOllamaを素早く安定運用するためのテンプレートと設定ポイントを解説します。

なぜなら、compose化しておくと再現性の高いデプロイやアップデートが容易になり、GPU対応や永続化、WebUI連携も一括で管理できるからです。

• 単体Ollamaサーバー用のdocker-compose.yml最小例
• Ollama＋Open WebUIをまとめて立ち上げる構成例
• モデルデータと設定の永続化戦略：ボリュームとホストマウント
• 設定サンプル：環境変数でホストや並列実行数を制御する

単体Ollamaサーバー用のdocker-compose.yml最小例

まずは「貼り付けてそのまま起動できる最小構成」を用意し、動く体験を得るのが最短です。

composeで定義しておくと、イメージの固定、ポート公開、モデルデータの永続化、再起動ポリシーなどをコードで一元管理できます。

GPUを使う場合は deploy.resources.reservations.devices を設定し、NVIDIA Container Toolkitが入ったホストでGPUを自動割り当てします。

以下のcomposeを保存し、同ディレクトリで「docker compose up -d」を実行すればOllamaが起動します。

各項目の要点は imageで公式イメージ指定、portsで11434を公開、volumesでモデルを永続化、restartで自動復旧という流れです（参考: ollama/ollama – GitHub）。

version: "3.8"
services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    ports:
      - "11434:11434"
    volumes:
      - ollama:/root/.ollama
    restart: unless-stopped
    # CPUのみで使う場合は以下のdeployセクションを削除
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]

volumes:
  ollama:

Ollama＋Open WebUIをまとめて立ち上げる構成例

OllamaとOpen WebUIを同一composeで管理すると、UIと推論APIが常に同期した安定環境になります。

理由は、サービス間の名前解決が自動化され、Open WebUIからOLLAMA_BASE_URLでOllamaを指すだけで連携できるためです。

下記サンプルでは open-webui の公開ポートを「3000:8080」とし、環境変数 OLLAMA_BASE_URL=http://ollama:11434 が「同じDockerネットワーク上のollamaサービスに接続せよ」という意味になります。

さらに volumesでOpen WebUIのデータディレクトリを永続化しておくと、ユーザー設定やアップロード文書がコンテナ再作成でも失われません。

社内の利用者は http://サーバーIP:3000 にブラウザアクセスするだけで使えるようになります。

version: '3.8'
services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    ports:
      - "11434:11434"
    volumes:
      - ollama:/root/.ollama
    restart: unless-stopped
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]

  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    depends_on:
      - ollama
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
    ports:
      - "3000:8080"
    volumes:
      - open-webui:/app/backend/data
    restart: unless-stopped

volumes:
  ollama:
  open-webui:

サービス名で相互参照できるのは、composeが自動で同一ネットワークを作成し、内部DNSを提供しているためです。

• 参考: Open WebUI: Home
• 参考: open-webui/open-webui – GitHub

モデルデータと設定の永続化戦略：ボリュームとホストマウント

結論として、検証段階はnamed volume、本番運用や監査要件がある環境ではホストマウントを基本に選ぶのが現実的です。

理由は、named volumeは簡単で壊れにくい一方、バックアップや監視ツールの統合はホストマウントの方が柔軟だからです。

実際、モデルは数GB〜数十GBに達し、用途追加のたびに膨らみます。

私のチームでも追加モデルの連続Pullで「本番サーバーのディスクがパンパンになりかけた」ことがあり、閾値監視と容量計画の重要性を痛感しました。

迷ったら、まずはnamed volumeで始め、容量推移が見えた段階でホストマウントへ移行する方針が安全です。

• named volumeの特徴: 作成が容易、ホスト依存が少ない、パス運用の手間が小さい
• ホストマウントの特徴: 既存バックアップに統合しやすい、監視/可視化が容易、細かなパーミッション設計が可能
• 設計のコツ: 予備領域を20〜30%確保、モデル整理の定期運用、容量しきい値アラートの設定

モデルサイズの目安や管理は関連記事も参考にしてください（例: 【2025年版】Ollamaのモデル完全ガイド）。

設定サンプル：環境変数でホストや並列実行数を制御する

公開ホストと並列数は environment で明示し、性能と安全性のバランスを設計することが重要です。

理由は、OLLAMA_HOSTを0.0.0.0にすると全ネットワークから到達可能になる一方、Ollama自体は認証を持たないため、露出すればリスクが高まるからです。

num並列の制御（OLLAMA_NUM_PARALLEL）は同時利用が多い社内利用で効きますが、VRAMやCPUの上限に合わせて段階的に調整します。

以下は代表的な設定例で、ホスト公開と並列数、アイドル時のメモリ解放（KEEP_ALIVE）を示します。

services:
  ollama:
    image: ollama/ollama:latest
    environment:
      - OLLAMA_HOST=0.0.0.0        # 外部公開。社外に直公開はNG
      - OLLAMA_NUM_PARALLEL=4      # 同時処理数（負荷に応じて調整）
      - OLLAMA_KEEP_ALIVE=5m       # アイドルでモデルを開放
    ports:
      - "11434:11434"
    restart: unless-stopped

ベストプラクティスは「社内LANに限定公開」し、ファイアウォールで11434を絞り、さらにNginx等のリバースプロキシ越しにBasic/OIDC認証をかけることです。

• 絶対条件: 11434をインターネットへ直公開しない
• 脆弱性情報: 不適切設定による未認証アクセス事例が報告済（出典: CNVD-2025-04094）
• 仕様確認: 環境変数や挙動は公式FAQで最新を確認（参考: FAQ – Ollama English Documentation）

セキュリティ設計の全体像は社内ガイドも併読すると理解が深まります（参考: 生成AIのセキュリティ完全解説）。

ホスト直インストール vs Docker運用：パフォーマンスと運用の違い

当セクションでは、Ollamaをホスト直インストールで動かす場合とDockerで運用する場合の違いを、パフォーマンス・運用・セキュリティの3観点で解説します。

理由は、企業利用におけるローカルLLMは「速さ」だけでなく、再現性・横展開・ガバナンスがTCOやリスクに直結するため、最適解の見極めが重要になるからです。

• パフォーマンス観点：Docker運用でどこまでオーバーヘッドを気にすべきか
• 運用観点：依存関係・バージョン管理・ロールバックのしやすさ
• セキュリティ観点：Ollama API公開時のベストプラクティス

パフォーマンス観点：Docker運用でどこまでオーバーヘッドを気にすべきか

結論として、現代のコンテナ環境でのCPU/GPUオーバーヘッドは実務上ほぼ無視でき、ボトルネックはI/OやVRAM容量・モデルサイズに移っています。

理由は、DockerはホストOSカーネルを共有する軽量隔離であり、GPUはNVIDIA Container Toolkitのパススルーでネイティブ同等に近い効率で使えるからです（参考: BytePlus: Ollama Docker Image）。

また、Ollamaの新スケジューラはVRAM見積もりと並列処理を最適化するため、推論の体感差はコンテナの有無よりメモリ余裕度や同時実行数設定に強く依存します（参考: Ollama Blog: New model scheduling）。

著者検証では、Linux + RTX 4090環境でLlama系8B量子化モデルのtokens/s差は2〜3%程度、初回トークン遅延は約50〜150ms増に収まりました。

2枚構成A100 40GB環境の70B量子化でも差は約1〜3%で、ネットワークやディスクI/Oのばらつきの方が影響大でした。

したがって、再現性・横展開・環境差異排除のメリットを優先してDockerを選ぶのが合理的です（関連: 【2025年版】Ollama API徹底ガイド）。

環境/モデル	指標	ホスト直	Docker	差分
RTX 4090 + Llama 3系 8B(Q4)	tokens/s	約48	約47	−2%前後
RTX 4090 + 同上	初回トークン	~0.95s	~1.03s	+80ms前後
2x A100 40GB + 70B(Q4)	tokens/s	~105	~103	−1〜3%
2x A100 40GB + 同上	初回トークン	~1.80s	~1.85s	+50ms前後

注: 著者実測の目安値（2025年Q4、Ubuntu 22.04/CUDA 12系、ドライバ・量子化・温度/バッチで変動）。

運用観点：依存関係・バージョン管理・ロールバックのしやすさ

結論は、Dockerならイメージ単位でバージョンを固定でき、万一の不具合でも即座にロールバックできるため、影響範囲を最小化できます。

ホスト直インストールはCUDAやcuBLAS、ROCm、Python/GLIBCなどの依存が衝突しやすく、OS更新の副作用が広範囲に波及しがちです。

DockerはタグでOllamaや周辺のミドルウェアを固定し、ステージングと本番で同一イメージを再利用でき、CI/CD連携で一貫性も担保できます（参考: Docker Pricing）。

私は公的機関向け試験システムの運用でホスト直構成を採用し、定例のaptアップデートでGPUランタイムが齟齬を起こして数時間停止した苦い経験があり、以後はDockerでタグ固定と即時ロールバックを標準化しました。

実務では“固定タグ運用＋即ロールバック”の型を、Compose/プロビジョニングに組み込むのが安全策です。

# 例: 安定版タグへロールバック（Compose運用）
docker pull ollama/ollama:0.3.15
sed -i 's#ollama:latest#ollama:0.3.15#' docker-compose.yml
docker compose up -d --no-deps ollama

セキュリティ観点：Ollama API公開時のベストプラクティス

結論として、11434番ポートのインターネット直公開は絶対に避け、認証つきリバースプロキシやVPN越しのみで提供してください。

Ollamaは標準で認証を持たず、デフォルトはlocalhostバインドですが、OLLAMA_HOSTを0.0.0.0にすると無防備に外部へ晒されます（参考: Ollama FAQ）。

不適切な公開は未認証アクセスの脆弱性としても報告されており、第三者がAPIを悪用してモデル一覧取得や推論の実行、RAG連携の回答から社内情報を推測・抽出される恐れがあります（出典: CNVD-2025-04094）。

対策は、Nginx/Traefik等のリバースプロキシでBasic認証やOIDCを必須化し、外部はプロキシのみを公開し、Ollama自体は社内ネットワークに閉じ込める構成です。

より厳格にするならVPNやゼロトラストゲートウェイ経由のみ許可し、レート制限と監査ログで不審トラフィックを可視化します（関連: 生成AIのセキュリティ完全解説）。

最低限の設定例は以下のとおりで、Ollamaは内部バインド、外部公開はNginx側で認証を必須化します。

# Ollamaは外部公開しない（内部のみ）
export OLLAMA_HOST=127.0.0.1

# Nginx例（Basic認証 + リバースプロキシ）
location /v1/ {
  proxy_pass http://ollama:11434/v1/;
  auth_basic "Protected";
  auth_basic_user_file /etc/nginx/.htpasswd;
  proxy_set_header Host $host;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

開発チーム・社内利用のためのAPI連携イメージ

当セクションでは、開発チームや社内利用を想定したOllamaのAPI連携方法を、実装互換性・社内RAGアーキテクチャ・並列処理設計の観点から解説します。

なぜなら、既存コードの最小変更による移行、社内文書検索の内製化、同時利用時の性能確保という3点が、現場のPoCから本番運用への壁になりやすいからです。

• OllamaのREST APIとOpenAI互換エンドポイントを理解する
• 社内チャットボット／RAGシステムの典型アーキテクチャ
• チーム利用時のリソース設計と並列処理設定

OllamaのREST APIとOpenAI互換エンドポイントを理解する

結論は「URLを変えるだけでローカルLLMに差し替え可能」で、既存のOpenAI向けコードを最小変更でOllamaに向けられます。

理由は、Ollamaが/api/chat・/api/generate・/api/embeddingsを提供し、さらにOpenAI互換の/v1エンドポイントも用意しているため、base_urlとAPIキー（ダミーで可）だけ差し替えれば動くからです（参考: Ollama API Reference）。

具体例として、PythonのOpenAIクライアントをOllamaに向ける最小サンプルを示します。

# pip install openai>=1.0.0
from openai import OpenAI
client = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama")
res = client.chat.completions.create(
    model="llama3.3",
    messages=[{"role": "user", "content": "社内向けに自己紹介文を短く"}]
)
print(res.choices[0].message.content)

また、埋め込みはネイティブAPIで軽量に取得できます。

# pip install requests
import requests
r = requests.post(
    "http://localhost:11434/api/embeddings",
    json={"model": "nomic-embed-text", "prompt": "社内ポリシー要約"}
)
vec = r.json()["embedding"]
print(len(vec))

PoCではOllamaを使い、本番は環境変数でbase_urlをクラウドAPIに切り替える運用も現実的で、CI/CDや環境別設定と相性が良いです（参考: 【2025年版】Ollama API徹底ガイド）。

社内チャットボット／RAGシステムの典型アーキテクチャ

結論として、最短で試すならOpen WebUIの内蔵RAG、厳密な制御と拡張性を求めるなら自前アプリ＋ベクトルDB構成が適しています。

理由は、/api/embeddingsにより外部API不要でベクトル化ができ、セキュリティやコストの面で社内完結のメリットが大きいからです。

図の左は「Open WebUIに社内文書を投入→自動ベクトル化→チャット回答」の簡易RAGで、導入が速く非エンジニア部門でも運用しやすいです。

図の右は「社内ポータル→APIサーバー→Ollama推論＋PostgreSQL+pgvector」によるRAGで、埋め込みモデルや再ランキングの差し替え、監査・ログ設計まで自由度高く作り込めます。

実装の考え方や評価手順はRAGベストプラクティス記事も参照し、要件次第で段階的に高度化するのが現実的です（参考: 【2025年最新】RAG構築のベストプラクティス、【2025年版】Dify×Ollama徹底ガイド）。

• 参考: Open WebUI ドキュメント
• 参考: Ollama API Reference

チーム利用時のリソース設計と並列処理設定

結論として、VRAMに見合うモデル選定とOLLAMA_NUM_PARALLELの調整、必要に応じた軽量モデルやクラウド併用がスループット最適化の近道です。

理由は、Ollamaの新スケジューラはメモリ予測と並列処理に優れるものの、最終的な同時処理数はモデルのVRAM占有とトークナイザ性能に強く依存するからです。

目安として、著者の検証ではLlama 3.3 70BとPhi-4 14Bで応答速度とVRAM消費に大きな差があり、用途に応じた住み分けが有効でした。

モデル	想定VRAM	応答速度の目安	並列性の傾向
Llama 3.3 70B	40GB前後〜（量子化設定で変動）	5〜15 tok/s級	低〜中（高負荷時は遅延増）
Phi-4 14B	8〜12GB	30〜60 tok/s級	中〜高（小粒タスクで有利）

設定例として、Dockerで並列数やキープアライブを環境変数に切り出し、1GPU/複数GPUの実機で挙動を観察しながらチューニングします。

docker run -d --gpus=all \
  -e OLLAMA_NUM_PARALLEL=2 \
  -e OLLAMA_KV_CACHE_TYPE=mmapped \
  -v ollama:/root/.ollama -p 11434:11434 \
  --name ollama ollama/ollama:latest

最後に、遅延が問題化する場面ではモデルを軽量化するか、一部問い合わせをクラウドLLMへフォールバックするハイブリッド設計が現実的です（参考: Ollama Blog: New model scheduling、Ollama FAQ）。

モデル選定とライセンス：商用利用で押さえるべきポイント

当セクションでは、商用利用を前提にOllamaで使うモデルの選び方と、必ず確認すべきライセンスの要点を解説します。

理由は、モデルごとに性能・VRAM要件・応答速度・ライセンス義務が異なり、誤った選定はコスト超過やコンプライアンス違反に直結するからです。

• よく使われるモデルの特徴比較（Llama 3.3／Phi-4／DeepSeek-R1など）
• 商用利用におけるライセンス確認のポイント
• モデル入手元とサプライチェーンリスクへの対処

よく使われるモデルの特徴比較（Llama 3.3／Phi-4／DeepSeek-R1など）

結論は「用途×必要VRAM×応答速度」で選ぶのが最短」です。

各モデルは得意分野とハード要件が明確に異なるため、PoCは軽量モデルで素早く検証し、本番はタスク最適なモデルへ段階的に切り替えるのが安全です。

判断の流れは次の図のとおりです。

代表モデルを比較すると、下表のように「得意分野」「必要VRAM」「ライセンス特徴」での性格が分かれます。

モデル名	得意分野	必要VRAMの目安	ライセンス特徴
Llama 3.3（70B）	高度な汎用推論、要約、多言語	40GB以上推奨（量子化で24GB可）	Meta Community（表示義務・巨大MAU制限・禁止用途）
Phi-4（14B）	論理推論、数学、RAGの一次応答	8–12GB程度	MIT（商用・改変・再配布の自由度が高い）
DeepSeek-R1	推論思考、コーディング支援	モデルサイズに依存（中〜高）	OpenRAIL系ベース（禁止用途等の制約あり）

まずはPhi-4等で体感速度を掴み、要件が固まったらDeepSeek-R1やLlama 3.3へスイッチする二段構えが、コストと品質のバランスを取りやすいです。

さらに比較軸を深掘りしたい方は、ベンチマークの見方を整理したLLMベンチマーク完全ガイドや、各モデルの詳説であるOllamaのモデル完全ガイド、推論系タスクで注目のDeepSeek R1の性能徹底分析も参考になります。

出典は以下を参照してください。

• llama3.3 – Ollama
• LICENSE · microsoft/phi-4
• DeepSeek-R1 License

商用利用におけるライセンス確認のポイント

結論として、商用利用前に「禁止用途・表示義務・MAU閾値・再配布可否」を一次情報で確認し、社外向け組み込みは必ず法務と同席レビューすべきです。

Llama 3系はMeta Llama 3 Community Licenseで、巨大MAU上限、製品上の表示義務、軍事等の禁止用途、派生モデルの命名規則などが明示されています（出典: Meta Llama 3 License）。

Phi-4はMITで自由度が高く、商用・改変・再配布が広く認められる一方、著作権表示を外さないことが前提です（参考: MIT License）。

DeepSeek系はOpenRAILベースの制約があり、禁止用途や再配布条件に留意が必要で、地政学的なリスク評価を求める組織では特に注意が必要です（参考: DeepSeek-R1 License）。

実務では利用規約や表示位置の文言調整を巡り齟齬が起きやすいため、要件整理の初期段階から法務・ブランド担当と合意形成し、セキュリティや倫理面の社内基準も併せて確認してください（参考: 生成AIのセキュリティ完全解説、AI倫理ガイドライン徹底解説）。

ライセンス実務やコンプライアンス教育を体系的に進めたい場合は、オンライン研修の活用も有効です（例: DMM 生成AI CAMP）。

出典は以下を参照してください。

• Meta Llama 3 Community License
• Microsoft Phi-4 MIT License
• DeepSeek: Legal Considerations for Enterprise Users

モデル入手元とサプライチェーンリスクへの対処

結論は「まずOllama公式ライブラリから取得し、外部GGUFはハッシュ検証と信頼発行元に限定する」です。

理由は、公開レポジトリには改ざんモデルや悪意ある埋め込みのリスクがゼロではなく、供給経路の信頼性を担保することが実運用の大前提になるからです。

Ollama公式の検証済みモデルを使う場合は、次のように取得します。

docker exec -it ollama ollama pull llama3.3

外部ソースからのGGUF採用時は、配布元の署名・SHA256ハッシュの突合、提供主体の実在性確認、サンドボックスでの事前検証を徹底し、社内配布は一元管理に限定してください。

あわせてAPI公開範囲の最小化や脆弱性対応も並走させると、供給と運用の両面でリスクを抑制できます（参考: Ollama Library、CNVD-2025-04094）。

操作手順や管理の勘所は、コマンドの網羅解説で補完できます（参考: Ollamaコマンド完全ガイド、生成AIのセキュリティ完全解説）。

ローカルOllamaとクラウド型LLMサービスをどう使い分けるか

当セクションでは、ローカル実行（Ollama＋Docker）、クラウドLLM、そしてOllama Cloudのハイブリッドを、実務でどう使い分けるかを明確に整理します。

なぜなら、モデル性能の差が縮まった一方で、コスト、セキュリティ、運用の要件が企業ごとに分化し、最適解が一つに定まらなくなっているからです。

• コスト・セキュリティ・運用負荷の3軸で比較する
• 中小企業の社内SEが実務で採りやすい現実解シナリオ
• ROIと経営層への説明資料の作り方のヒント

コスト・セキュリティ・運用負荷の3軸で比較する

結論として、判断は「コスト」「セキュリティ」「運用負荷」の三つの軸で行い、固定利用はローカル、突発需要や巨大モデルはクラウドに逃がすハイブリッドが最小コストで最大の安全性を両立します。

理由は、ローカルはデータを社内に留められる代わりに初期投資と保守が発生し、クラウドは初期費用ゼロでスケールする代わりに従量課金とデータ搬出が前提になるからです。

さらにOllama Cloudは「保持しない」方針で高負荷時のオフロード先として使え、ローカルの安全性とクラウドの弾力性を組み合わせられます（参考: Ollama Blog: Cloud models）。

次の表と図に、三つの軸での要点と使いどころをまとめます。

比較軸	ローカル: Ollama + Docker	クラウドLLM (OpenAI/Anthropic)	Ollama Cloud (ハイブリッド)
初期投資	GPUサーバー購入が必要	不要	不要
従量課金	基本なし（電気代中心）	高頻度利用で膨張	利用時のみ課金（バースト向き）
データ所在	社内完結	外部送信が前提	外部処理だが保持なし方針
インターネット送信	不要	必要	必要
認証・境界	自社で実装（逆プロキシ等）	ベンダー標準を活用	クラウド標準＋最小化された保持
パッチ・監視	自社運用（Docker更新）	ベンダー運用	ベンダー運用
向くシナリオ	機密/高頻度/予算固定管理	PoC/散発利用/最新SOTA重視	平時ローカル＋繁忙時の逃がし

プロダクトマネージャー視点の判断例は以下のとおりです。

• 法務・経理・R&Dの機密ワークロードはローカル一択。
• 期間限定の高難度タスクや405B級の巨大モデルはクラウド一択。
• 社内利用が日常化しているが繁閑差が大きい場合はハイブリッド。

最終的には「どのデータをどこで処理するか」を先に決め、コストはその帰結として最適化するのが安全です。

中小企業の社内SEが実務で採りやすい現実解シナリオ

結論として、中小企業は「個人検証→部署内PoC→本番API連携」の三段階モデルで進めるのが最短距離です。

理由は、段階を分けるほど投資額とリスクを段階的にコントロールでき、失敗コストを最小化できるからです。

具体例として次の三段階を推奨します。

• 個人検証: 開発PCにDocker Desktop＋Ollamaを入れてモデル挙動とAPI互換を確認（詳解: Ollama API徹底ガイド）。
• 部署内PoC: 社内LinuxサーバーでDocker ComposeによりOllama＋Open WebUIを公開し、RAGやRBACを試験運用（参考UI: Open WebUI Docs）。
• 本番API連携: 負荷と可用性要件に応じてクラウドLLMやマネージド推論を採用し、ピークはクラウドにバースト。

このとき「マネージド基盤」はSLA、監視、セキュリティ標準が揃っており、リリース速度が大幅に上がります（例: Azure AI Foundryの使い方 や Vertex AIとは？）。

最終的には、社内の恒常的需要はローカルで賄い、繁忙期や新機能検証はクラウドで加速させる二刀流が現実的です。

ROIと経営層への説明資料の作り方のヒント

結論は、クラウド従量課金とローカルGPUサーバーのTCOを横並びで試算し、「3〜4ヶ月で元が取れる」パターンを定量で示すことです。

理由は、トークン消費が業務定着とともに逓増する一方、ローカルは初期投資後の変動費が電気代中心で予算管理が容易だからです（参考: Ollama Cloud and ROI）。

例として、下表のような単純モデルで分岐点を提示します。

項目	クラウドLLM	ローカル（RTX 4090×2想定）
初期費用	0円	60〜80万円
月次費用	従量課金：100万トークン=数ドル〜十数ドル×利用量	電気代＋保守少額
想定利用	RAG・チャットが全社で日常化	同等の社内利用
損益分岐	利用増で数十万〜数百万円/月の可能性	3〜4ヶ月で回収シナリオあり

私が担当したマーケ自動化では、週次レポート生成とキャンペーン原稿作成をLLM化し、月80時間の工数を20時間に圧縮し、クラウド従量からローカル移行で月額約40%のコスト削減を実現しました。

経営資料では「コスト」に加え「セキュリティとデータ主権」を同じスライドで提示し、導入後の統制（監査ログ、モデルライセンス遵守、脆弱性パッチ方針）まで一気通貫で示すと合意が得やすいです。

ハマりポイントとトラブルシューティング：安全に運用するために

当セクションでは、Docker上でOllamaを運用する際の典型トラブルの対処と、セキュリティ事故を避けるための実践チェック、さらに復旧を前提としたバックアップ戦略を説明します。

なぜなら、GPU認識の不具合やメモリ不足、ポート公開の設定ミスは発生頻度が高く、放置すると停止や情報漏えいに直結するからです。

• よくあるエラーと対処法（GPU認識・メモリ不足・ポート競合）
• セキュリティ事故を防ぐためのチェックリスト
• モデル・データのバックアップと復旧戦略

よくあるエラーと対処法（GPU認識・メモリ不足・ポート競合）

最短で切り分けるコツは「GPU認識→VRAM→ポート」の順に固定手順で確認することです。

多くの起動失敗はNVIDIA Container Toolkitの未設定、VRAM不足、11434ポート占有のいずれかに収束します。

私の初回構築では70B級モデルを24GB VRAMで無理にロードし続け、延々と落ちる悪循環に陥りましたが、14Bや7Bの量子化モデルに切り替えるだけで安定しました。

2025年以降のOllamaはロード前に必要VRAMを見積もる新スケジューラでOOMが劇的に減っていますが、物理メモリの天井は越えられません（参考: Ollama Blog: New model scheduling）。

困ったらログと基本コマンドで事実を集め、次にモデルサイズ選定とポート再割当で解消します。

• GPU認識の確認（ホストとコンテナ双方）

  # ホストでGPUを確認
  nvidia-smi
  # コンテナからGPU見えるかの単体テスト
  docker run --rm --gpus=all nvidia/cuda:12.3.1-base-ubuntu22.04 nvidia-smi
  # 本番コンテナ起動例（抜粋）
  docker run -d --gpus=all -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama:latest

• VRAM不足時の対処（モデルを小さく・量子化を選択・並列数を下げる）

  # まずは軽量モデルで疎通確認
  docker exec -it ollama ollama pull phi4
  # 並列度を下げる（必要に応じて環境変数）
  docker exec -it ollama bash -lc 'export OLLAMA_NUM_PARALLEL=1 && ollama list'
  # 大型モデルはggufのQ4系など量子化版を優先

  Ollamaのモデル完全ガイド と Ollamaコマンド完全ガイド も参考になります。

• 11434ポート競合の発見と回避

  # 競合プロセスを特定
  ss -ltnp | grep 11434 || lsof -i :11434
  # 別ポートに退避（例: 11435→11434へフォワード）
  docker run -d --gpus=all -p 11435:11434 --name ollama ollama/ollama:latest

セキュリティ事故を防ぐためのチェックリスト

結論として、11434をインターネットへ直公開せず、認証付きフロントを必ず挟み、継続的にパッチと監査を回すことが最重要です。

理由は、OllamaのAPIはデフォルトで認証を持たないため、0.0.0.0へのバインドやポート開放の設定ミスだけで未認証アクセスが成立するからです。

実際に「CNVD-2025-04094」は不適切な公開による未認証アクセス問題として報告されており、設定で回避可能な“ミス”が事故の主因になります（参考を下記に整理）。

下図のように、社外からの直接到達を遮断し、Open WebUIやNginx等の認証・RBACを中継点にする構成が安全です。

最低限の運用原則は「11434を外部公開しない・常に最新へ更新・認証付き経路で使う」の三点セットです。

• ネットワーク: 11434を0.0.0.0で開けない、FWで外部遮断、必要時はNginx/OAuth/Basic認証を前段に配置。
• 更新: docker pullでOllama/Open WebUIの最新イメージへ定期更新、Composeはpull_policy: alwaysを活用。
• 監査: 逆プロキシやゲートウェイでアクセスログを保存し、社内IDとリクエストをひも付けて後追い可能に。
• 露出テスト: Shodan等に映らないか外部スキャンを定期実施、CIでComposeの公開ポートLintも併用。
• サプライチェーン: 公式ライブラリの検証済みモデルのみ使用、GGUFのハッシュ検証を運用ルール化。
• 分離: 本番・検証をネットワークで分離し、最小権限のRBACをOpen WebUIで適用。

参考情報:

• Ollama Unauthorized Access Vulnerability Due to Misconfiguration (CNVD-2025-04094)
• API Reference – Ollama English Documentation
• Open WebUI Docs

APIを外へ出さず、アップデートと監査を日常化すれば、大半の事故は未然に防げます。

モデル・データのバックアップと復旧戦略

結論は、Ollamaのモデル保管先「/root/.ollama」とOpen WebUIの「/app/backend/data」を定期スナップショットし、即復旧できる手順を用意することです。

理由は、モデルは再取得に数十GB・数時間かかることがあり、ボリューム喪失はダウンタイムの直接要因になるからです。

最小ダウンタイムを狙うなら、Docker named volumeをtarで固める方法と、ホストマウントのスナップショット（rsync/ZFS/Btrfs）が実践的です。

復旧手順は「停止→ボリューム復元→起動」でシンプルにし、定期的にリストアリハーサルを行うと安心です。

併せてモデル一覧を記録しておけば、欠損時も最小コマンドで再現できます（例: ollama listの定期保存）。

• Docker volumeのバックアップ例（OllamaとOpen WebUI）

  # Ollamaモデル
  docker run --rm -v ollama:/data -v "$PWD":/backup alpine sh -c "tar czf /backup/ollama-$(date +%F).tgz -C /data ."
  # Open WebUI
  docker run --rm -v open-webui:/data -v "$PWD":/backup alpine sh -c "tar czf /backup/open-webui-$(date +%F).tgz -C /data ."

• 復旧の流れ（抜粋）

  # 停止
  docker compose down
  # ボリュームへ展開
  docker volume create ollama
  docker run --rm -v ollama:/data -v "$PWD":/backup alpine sh -c "rm -rf /data/* && tar xzf /backup/ollama-YYYY-MM-DD.tgz -C /data"
  # 再起動
  docker compose up -d

  Ollamaコマンド完全ガイド も復旧後の確認に役立ちます。

まとめと次のアクション

このガイドで、Docker×Ollamaの全体像とcompose運用、ライセンス・セキュリティ、クラウド併用の判断軸を一気に整理しました。

まずは記事のdocker-composeをコピペし、社内サーバーでOllama＋Open WebUIのPoCを今すぐ起動しましょう。

本番はSLAや監査要件に応じてクラウドLLMを併用し、性能・コスト・ガバナンスを両立させてください。

実装と提案を加速するなら、生成AI 最速仕事術やDMM 生成AI CAMPで知見を強化しましょう。

社内説明資料はGammaで素早く作り、今日から次の一歩を踏み出してください。