OllamaをDockerComposeで開発環境に組み込む方法｜アプリ・DB・LLMを一括起動してチーム共有を効率化する手順

宮崎智広 この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
ＨＯＭＥ ＞ Linux技術 リナックスマスター.JP（Linuxマスター.JP） ＞ ローカルLLM ＞ OllamaをDockerComposeで開発環境に組み込む方法｜アプリ・DB・LLMを一括起動してチーム共有を効率化する手順
「Ollamaを毎回手動で起動するのが面倒で、チームメンバーへの環境共有ができない」
「アプリ・データベース・LLMがバラバラに動いていて、開発環境の再現性が低い」

そんな悩みを抱えるLinuxエンジニアは多いはずです。この記事では、Docker Composeを使ってOllamaをWebアプリやデータベースと同一スタックで管理し、docker compose up 一発で全サービスを起動できる開発環境の構築手順を解説します。
モデルの永続化設定、コンテナ間の接続方法、起動順序の制御まで、実際の開発現場で使える構成を順を追って説明します。Ollamaをホストに直接インストールする基本手順についてはUbuntu ServerでローカルLLMを構築する方法で解説しているため、本記事はDocker Compose統合に絞って進めます。

この記事のポイント

・docker-compose.yml の ollama サービス定義と GPU パススルー設定で環境を統一できる
・アプリコンテナからは http://ollama:11434 のサービス名でAPIに接続する
・named volume と OLLAMA_MODELS 環境変数でモデルをコンテナ再起動後も保持する
・healthcheck と depends_on の組み合わせで起動順序を確実に制御できる


OllamaをDockerComposeで開発環境に組み込む方法｜アプリ・DB・LLMを一括起動してチーム共有を効率化する手順

「このままじゃマズい」と感じていませんか？
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら

DockerComposeでOllamaを管理するメリットと前提条件

Ollamaをホストに直接インストールして使うのも手軽ですが、開発チームで使う場合はDocker Composeで管理する方が圧倒的に便利です。

最大のメリットは「環境の再現性」です。docker-compose.yml と .env ファイルをGitに含めておけば、チームメンバーが git clone して docker compose up を実行するだけで、同じ構成のOllama環境が立ち上がります。
「自分の環境では動くのに他のメンバーの環境では動かない」という問題を根本から排除できます。

もう一つのメリットは「サービスの一元管理」です。WebアプリのAPIサーバー、PostgreSQL、Ollama、Open WebUIといった複数のサービスを一つの docker-compose.yml にまとめておけば、起動・停止・ログ確認がすべて docker compose コマンドで完結します。
開発中に「Ollamaを起動し忘れていた」というミスもなくなります。

本記事の手順を進めるにあたって、以下の環境を前提とします。

・Ubuntu 22.04 LTS または 24.04 LTS（WSL2上でも動作確認済み）
・Docker Engine 24.0 以降（docker compose v2 同梱）
・CPU推論の場合はメモリ16GB以上。GPU使用の場合はNVIDIA GPU＋nvidia-container-toolkit導入済み
・インターネット接続（初回のモデルダウンロードに必要）

Docker Engine のインストールがまだの場合は、公式ドキュメントの「Install Docker Engine on Ubuntu」を参照してください。docker compose version で v2.x と表示されれば準備完了です。

docker-compose.ymlの基本構成とOllamaサービス定義

まずプロジェクトディレクトリを作成し、基本的な構成ファイルを用意します。

1. ディレクトリとファイルを作成する


$ mkdir my-ai-app && cd my-ai-app
$ touch docker-compose.yml .env

2. docker-compose.ymlを記述する（CPU版）

以下がCPU推論を使う場合の基本構成です。 

services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    volumes:
      - ollama_models:/root/.ollama
    ports:
      - "11434:11434"
    environment:
      - OLLAMA_MODELS=/root/.ollama/models
    networks:
      - ai-network
    restart: unless-stopped

  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    ports:
      - "3000:8080"
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
    depends_on:
      - ollama
    networks:
      - ai-network
    restart: unless-stopped

volumes:
  ollama_models:

networks:
  ai-network:
    driver: bridge
volumes ブロックに ollama_models を定義することで、コンテナを削除・再作成してもダウンロード済みのモデルが保持されます。
networks に独自のブリッジネットワーク ai-network を定義しているため、同じネットワークに属するコンテナ同士はサービス名で通信できます。

3. GPU（NVIDIA）を使う場合の追記

NVIDIA GPUを持つホストでGPUを使いたい場合は、ollama サービスに以下の deploy セクションを追加します。 

  ollama:
    image: ollama/ollama:latest
    # （既存設定に以下を追記）
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]
このセクションを追加するだけでGPUパススルーが有効になります。ホスト側に nvidia-container-toolkit が正しく導入されていることが前提です。
CPU版との切り替えはこのセクションの有無だけなので、開発環境ではCPU版・本番では同じymlにGPU設定を追加、という運用も容易です。

アプリケーションコンテナからOllama APIに接続する設定

Docker Composeの最大の利点の一つが「サービス名でのコンテナ間通信」です。同一ネットワーク内のコンテナは、IPアドレスではなくサービス名をホスト名として使用できます。

OllamaのAPIエンドポイントは http://ollama:11434 になります。ホストからアクセスする場合は http://localhost:11434 ですが、同一Docker Composeネットワーク内の他のコンテナからは必ず http://ollama:11434 を使ってください。

PythonアプリのコンテナでOllama APIを呼び出す例を示します。 

import requests
import json

OLLAMA_URL = "http://ollama:11434"

def chat(prompt: str, model: str = "llama3.3:8b-instruct-q4_0") -> str:
    response = requests.post(
        f"{OLLAMA_URL}/api/generate",
        json={"model": model, "prompt": prompt, "stream": False},
        timeout=120,
    )
    response.raise_for_status()
    return response.json()["response"]

if __name__ == "__main__":
    result = chat("Linuxのinodeとは何か、100字で説明してください")
    print(result)
OLLAMA_URL を環境変数化しておくと、ホスト直実行時とDocker Compose時で切り替えやすくなります。


# docker-compose.yml の app サービスへの環境変数追加例
  app:
    build: .
    environment:
      - OLLAMA_URL=http://ollama:11434
    networks:
      - ai-network
Pythonコード側では os.environ.get("OLLAMA_URL", "http://localhost:11434") と書いておけば、Docker Compose外での単体テスト時も localhost にフォールバックします。

なお、業務用途でOllamaにどのモデルを使えばよいか迷う場合は、ローカルLLMのモデルを比較する方法でLlama3.3・Mistral・Gemma 3・Phi-4の特性と選び方を整理しているので参考にしてください。

初回起動とモデルダウンロードの手順

設定ファイルが用意できたら実際に起動して動作確認まで進めます。

1. バックグラウンドでコンテナを起動する


$ docker compose up -d
[+] Running 4/4
 ✔ Network my-ai-app_ai-network    Created
 ✔ Volume "my-ai-app_ollama_models" Created
 ✔ Container ollama                Started
 ✔ Container open-webui            Started

2. Ollamaコンテナ内でモデルをダウンロードする

初回はモデルファイルが存在しないため、コンテナ内で ollama pull を実行します。 

$ docker compose exec ollama ollama pull llama3.3:8b-instruct-q4_0
pulling manifest
pulling 966de95ca8a6... 100% ▕████████████████████████████████▏ 4.9 GB
pulling 59d05a09ca41... 100% ▕████████████████████████████████▏  182 B
verifying sha256 digest
writing manifest
success

$ docker compose exec ollama ollama list
NAME                             ID              SIZE      MODIFIED
llama3.3:8b-instruct-q4_0       a6eb4748fd29    4.9 GB    About a minute ago
ダウンロードしたモデルは ollama_models named volume に保存されるため、docker compose down 後に再起動しても再ダウンロードは不要です。

3. APIへの疎通確認

ホストから curl でAPIが応答することを確認します。 

$ curl -s http://localhost:11434/api/tags | python3 -m json.tool
{
    "models": [
        {
            "name": "llama3.3:8b-instruct-q4_0",
            "model": "llama3.3:8b-instruct-q4_0",
            "modified_at": "2026-08-10T12:00:00Z",
            "size": 4925000000,
            "digest": "a6eb4748fd29..."
        }
    ]
}
models にダウンロードしたモデルが表示されれば正常動作しています。
Open WebUIには http://localhost:3000 でアクセスできます。初回は管理者アカウントの作成画面が表示されます。

環境変数とボリュームでモデルを永続化する設定

開発環境では設定値を .env ファイルで管理するのが定石です。docker-compose.yml に直接ハードコードするよりも、チームごとに異なる設定やローカルのパス差異を吸収しやすくなります。

1. .envファイルに設定を書く


# .env
OLLAMA_IMAGE_TAG=latest
WEBUI_PORT=3000
OLLAMA_NUM_PARALLEL=2
OLLAMA_MAX_LOADED_MODELS=1

2. docker-compose.ymlで変数を参照する


services:
  ollama:
    image: ollama/ollama:${OLLAMA_IMAGE_TAG:-latest}
    environment:
      - OLLAMA_NUM_PARALLEL=${OLLAMA_NUM_PARALLEL:-1}
      - OLLAMA_MAX_LOADED_MODELS=${OLLAMA_MAX_LOADED_MODELS:-1}
:- 記法でデフォルト値を指定しておくと、.env ファイルが存在しない場合でも動作します。

ボリュームについては named volume（ollama_models）を使う方法のほか、ホストディレクトリをマウントする bind mount も選択肢です。ホストの特定ディレクトリにモデルをまとめて管理したい場合は以下のように記述します。

  ollama:
    volumes:
      - /data/ollama/models:/root/.ollama/models
ホストパス /data/ollama/models にモデルが保存されるため、複数のComposeプロジェクトでモデルを共有したい場合に便利です。ただし複数プロジェクトが同時に同一パスを読み書きすると競合が起きることがあるため、開発用と本番用を分ける場合はnamed volumeを推奨します。

OLLAMA_NUM_PARALLEL は同時に処理できるリクエスト数です。開発PCのメモリが限られている場合は 1 に抑えておく方がモデルロードの失敗を防げます。OLLAMA_MAX_LOADED_MODELS はメモリ上に保持するモデル数で、複数モデルを切り替えながら検証する場合は 2 以上に増やしてください。

ヘルスチェックとdepends_onで起動順序を制御する

Docker Composeの depends_on だけでは「コンテナが起動した」ことしか保証されず、「サービスが応答できる状態になった」ことは保証されません。Ollamaの起動には数秒かかることがあり、その前にアプリコンテナがAPIを叩きにいくと接続エラーになります。

これを防ぐには healthcheck と depends_on の condition: service_healthy を組み合わせます。

1. ollamaサービスにhealthcheckを追加する


  ollama:
    image: ollama/ollama:latest
    healthcheck:
      test: ["CMD", "curl", "-sf", "http://localhost:11434/api/tags"]
      interval: 10s
      timeout: 5s
      retries: 5
      start_period: 15s
start_period: 15s はOllamaの初期化完了を待つ猶予時間です。この期間中のヘルスチェック失敗はリトライカウントに含まれません。

2. 依存サービス側でconditionを指定する


  app:
    build: .
    depends_on:
      ollama:
        condition: service_healthy
    networks:
      - ai-network
これで app コンテナはOllamaのヘルスチェックが healthy になるまで起動を待機します。
Open WebUIにも同様の設定を適用すると、起動直後の「Ollama接続エラー」画面が表示されなくなります。

ヘルスチェックの状態は以下のコマンドで確認できます。 

$ docker compose ps
NAME          IMAGE                   STATUS
ollama        ollama/ollama:latest    Up 2 minutes (healthy)
open-webui    ghcr.io/open-webui...   Up About a minute
app           my-ai-app-app           Up 30 seconds
STATUS 列に (healthy) と表示されれば正常です。(starting) と表示されている間は依存サービスが待機中であることを示しています。

よくある問題とトラブルシューティング

Docker Compose環境でOllamaを使う際に現場でよく遭遇するトラブルと対処法をまとめます。

1. アプリコンテナからconnection refusedになる

原因の大半は「URLに localhost を使っている」か「ネットワーク設定が抜けている」のどちらかです。
コンテナ内では localhost はそのコンテナ自身を指すため、別のサービスには必ずサービス名（ollama）を使ってください。

また、アプリコンテナが ai-network に参加していない場合も接続できません。docker compose config を実行してネットワーク設定を確認してください。

2. GPUが認識されない

docker compose exec ollama nvidia-smi を実行してGPUが見えるか確認します。見えない場合は以下をチェックします。

・nvidia-container-toolkit がインストールされているか
・sudo systemctl restart docker でDockerを再起動したか
・deploy.resources.reservations の記述が正しいか（インデントミスに注意）

3. コンテナ再起動のたびにモデルが消える

docker compose down -v を実行すると named volume ごと削除されます。モデルを保持したまま停止するには docker compose down（-v なし）を使ってください。
CI/CDなどで意図せず -v が付いていないか確認することを勧めます。

4. モデルのダウンロードが途中で止まる

大容量モデル（Llama3.3の70Bモデルで40GB超）のダウンロードはタイムアウトが発生することがあります。docker compose exec ollama ollama pull は対話端末で実行することで進捗を確認しながら完了を待てます。完了後はnamed volumeに保存されるため、再実行は不要です。

社内イントラ環境でのローカルLLM運用における情報セキュリティの考え方については、社内でChatGPTが使えないときの代替手段も合わせて参照してください。Docker Compose環境であってもモデルファイルや推論データのアクセス制御の考え方は共通です。

まとめ：DockerCompose＋Ollamaで再現性の高いAI開発環境を構築する

この記事では、Docker ComposeにOllamaを組み込んで開発環境を構築する手順を解説しました。
docker-compose.yml を一度整備しておけば、チーム全員が同じコマンドで同じAI環境を立ち上げられます。

各設定のポイントを以下にまとめます。

設定項目 推奨設定 用途・注意点
コンテナ間通信URL http://ollama:11434 サービス名＝ホスト名。localhostは使わない
モデルの永続化 named volume ollama_models docker compose down -v で削除されるので注意
GPU有効化 deploy.resources.reservations nvidia-container-toolkit が前提
ヘルスチェック curl -sf http://localhost:11434/api/tags start_period: 15s で初期化を待つ
起動順序制御 depends_on: condition: service_healthy healthcheck と必ずセットで使う
並列リクエスト数 OLLAMA_NUM_PARALLEL=1～2 開発PCのメモリ量に合わせて調整
モデル指定 llama3.3:8b-instruct-q4_0 量子化タグはサフィックス形式で指定


本番スケールへの展開を検討する段階になったら、Ubuntu ServerでローカルLLMを構築する完全ガイドでホスト直接インストールとの比較や、systemdサービス化による本番運用の設定も確認しておくことを勧めます。

Docker Compose＋Ollamaの実機構築を2日間のハンズオンで体験する

設定ファイルを自分で書いてデプロイするまでの流れを、実機GPU環境で手を動かしながら習得したい方向けに、「ローカルAIマスターセミナー」を開催しています。
少人数（最大8名）ZOOMハンズオン形式で実施しています。

＞＞ ローカルAIマスターセミナーの詳細を確認する
ローカルLLMの構築・運用に関する関連記事もあわせて参考にしてください。

・Ubuntu ServerでローカルLLMを構築する方法｜Ollamaで機密データを外に出さず業務AIを動かす完全ガイド
・社内でChatGPTが使えないときの代替手段｜機密データを守るローカルLLMという選択肢
・ローカルLLMのモデルを比較する方法｜Llama3.3・Mistral・Gemma・Phi-4をUbuntuで使い分けるポイント

関連記事

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら

Linux無料マニュアル（図解60P） 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広（みやざき ともひろ）

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。