Ollama + Open WebUI をVPS（Ubuntu）にセルフホストする手順2026

AI・ローカルLLM活用中級
OllamaOpen WebUIUbuntuVPSLLMDockerセルフホスト

結論: Ubuntu 24.04のVPS上でOllama（LLM推論エンジン）とOpen WebUI（ChatGPT風ブラウザUI）を組み合わせることで、クラウドLLMへの依存を断ちつつ社内データを外部に出さないAI環境を構築できる。ただし、CPU-onlyのVPSでは推論速度に実用上の限界がある。スペック判断を先に行うこと。

ChatGPT PlusやAPIの費用が積み上がっている。あるいは、社内の文書や顧客データをOpenAIのサーバーへ送ることへの懸念が拭えない。そういった理由でセルフホストLLMを調べ始めた情シス担当の方向けに、2026年3月時点で動作確認された構成をもとに手順を整理する。

コマンドはcomputingforgeeks.com（https://computingforgeeks.com/install-open-webui-ollama-linux/）がUbuntu 24.04.2 LTS / Ollama 0.18.2 / Docker 29.3.0 / Open WebUI 0.8.10の環境で検証したものを基準とする。それ以外の数値については出典を明示するか「要確認」と断る。

なぜクラウドLLMをやめてVPSで動かすのか

費用、データ主権、依存の3点が主な動機になる。

費用: ChatGPT PlusはUIアクセスに月$20、APIはトークン課金が別途発生する。複数人が使う環境では合計額がすぐに膨らむ。セルフホストに移行すれば、VPS代と電気代だけになる。

データ主権: クラウドLLMにプロンプトとして送った内容は、利用規約上サービス側のサーバーを通過する。顧客情報・設計書・財務データをプロンプトに含める場合、送信先を自社管理のサーバーに限定したい。

依存脱却: サービスの価格改定・API仕様変更・サービス終了リスクをゼロにはできないが、ミドルウェアを自社インフラで持つことで移行コストを自分でコントロールできる。

一方で、CPU-only環境の限界は先に認識しておく必要がある。GPUなしのVPSでは、7Bパラメータのモデルでも1トークン/秒前後の生成速度になることが多く、会話として快適に使える水準には届かないケースがある。実用速度を求めるならGPU付きVPSが必要になる。その選定については後述する。

構築前に確認するスペック要件

「自分のVPSで動くか」をコスト・時間・設定の前に判断する。

最小構成と用途別の目安

Ollamaの公式ドキュメントおよびlocalaimaster.comの調査（2026年公開）によると、Ollamaが動作するための最小要件は以下のとおり。

  • RAM: 8GB
  • ストレージ: 空き10GB以上
  • CPU: AVX2命令対応の64bit CPU
  • GPU: 不要（CPU-onlyで動作する）

用途別のRAM・VRAM目安は localaimaster.com のモデル別テーブル（2026年）から引用する。

モデルRAMまたはVRAM備考
Llama 3.2 (8B)4.9GB（RAM）/ 6GB（VRAM）CPU-only可
Llama 3.3 (70B)40.0GB（RAM）/ 48GB以上のGPU または24GB × 2CPU-onlyは実用外

Llama 3.2の8Bモデルを動かすだけなら8GB RAMのVPSで理論上は動作する。ただし、OSとOpen WebUIのコンテナが消費するメモリを引いた残りがモデルのロードに使われるため、16GB以上を推奨する。

ディスク容量の実態

モデルファイルのサイズは大きい。Llama 3.2の8Bモデルはollama pull後に4〜5GB程度を消費する。モデルを複数試すなら、ストレージは40GB以上を確保しておくと余裕がある。

GPU付きVPSについて

GPU付きVPSはCPU-onlyと比べて月額が大きく変わる。各社のプランと価格は変動が速いため、具体的な金額はConoHaやさくらのクラウド、Vultrなど各社公式を直接確認する（2026年6月時点で比較した記事は内部リンク先を参照）。

構築手順（Ubuntu 24.04 + Docker）

以下はUbuntu 24.04.2 LTSのVPSでroot権限またはsudoが使えることを前提とする。

Step 1 — Dockerのインストール

2026年3月時点の検証環境ではDocker 29.3.0を使用している。Ubuntuのaptリポジトリには古いバージョンが含まれることがあるため、Docker公式のリポジトリを追加してインストールする。

# 既存の古いバージョンを削除
sudo apt remove docker docker-engine docker.io containerd runc

# 必要なパッケージを追加
sudo apt update
sudo apt install -y ca-certificates curl gnupg lsb-release

# Dockerの公式GPGキーを追加
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | \
  sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

# リポジトリを追加
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
  https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# インストール
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# インストール確認
docker --version

dockerグループへの追加も済ませておく（rootで操作しない場合）。

sudo usermod -aG docker $USER
newgrp docker

Step 2 — Ollamaのインストール（ホスト直接）

Ollamaは公式のインストールスクリプトで導入する。ホスト上に直接インストールする構成を選ぶことで、後述するOpen WebUIのDockerコンテナとのネットワーク接続がシンプルになる。

curl -fsSL https://ollama.com/install.sh | sh

インストール後、OllamaはSystemdのサービスとして自動起動される。

sudo systemctl status ollama

active (running) と表示されれば起動成功。

Step 3 — DockerコンテナからOllamaへの接続設定

ここが既存の解説記事で抜けているケースが多い箇所。

デフォルト設定ではOllamaは127.0.0.1:11434にバインドされる。これはLoopbackアドレスへの待ち受けなので、Dockerコンテナの内部からlocalhost:11434に接続しようとしても到達できない。

解決策はOLLAMA_HOST=0.0.0.0:11434を環境変数として設定し、Ollamaをすべてのインターフェースで待ち受けさせること。Systemdのサービスファイルをdropinで上書きする方法が最も安定している。

# systemd override ディレクトリを作成
sudo mkdir -p /etc/systemd/system/ollama.service.d

# override.confを作成
sudo tee /etc/systemd/system/ollama.service.d/override.conf <<EOF
[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"
EOF

# systemdをリロードしてOllamaを再起動
sudo systemctl daemon-reload
sudo systemctl restart ollama

再起動後に待ち受けアドレスを確認する。

sudo ss -tlnp | grep 11434

0.0.0.0:11434が表示されれば設定完了。

注意: この設定によってポート11434がVPS上のすべてのインターフェースで待ち受け状態になる。後述のファイアウォール設定でこのポートを外部に公開しないこと。ポート11434を公開した状態にすると、誰でもAPIを叩いてCPU・GPU時間を消費できる状態になる（glukhov.org、2026年）。

Step 4 — モデルのダウンロード

Ollamaの公式モデルライブラリからモデルを取得する。人気モデルのランキングはOllama公式ライブラリページ（ollama.com/library）でダウンロード数順に確認できる。

8GB RAMのVPSで動作確認された最小構成を試したい場合は1Bまたは4Bモデルが適切。

# Gemma 3の4Bモデル（computingforgeeks.comの検証環境で使用）
ollama pull gemma3:4b

# または最小サイズを確認したい場合
ollama pull llama3.2:1b

ダウンロード完了後、動作確認。

ollama run gemma3:4b "Hello"

レスポンスが返ってくれば推論は動いている。

Step 5 — Open WebUIの起動（Docker Compose）

Open WebUI（ChatGPT風のブラウザUIをセルフホストするOSSプロジェクト）をDockerで起動する。

公式のQuick Startコマンドはシングルコンテナでの起動。

docker run -d \
  -p 3000:8080 \
  -v open-webui:/app/backend/data \
  --name open-webui \
  ghcr.io/open-webui/open-webui:main

ただし、OllamaがホストにインストールされているためコンテナがホストのOllamaへ接続できるよう--add-hostオプションが必要になる。

docker run -d \
  -p 3000:8080 \
  --add-host=host.docker.internal:host-gateway \
  -e OLLAMA_BASE_URL=http://host.docker.internal:11434 \
  -e WEBUI_SECRET_KEY=<任意の長いランダム文字列> \
  -v open-webui:/app/backend/data \
  --name open-webui \
  --restart always \
  ghcr.io/open-webui/open-webui:main

WEBUI_SECRET_KEYが未設定のままだと、再起動のたびにセッションが無効化されてログインが切れる。必ず設定すること。値はopenssl rand -hex 32などで生成した文字列を使う。

起動確認。

docker ps
docker logs open-webui

この時点ではhttp://<VPS-IPアドレス>:3000でアクセスできる状態。ただし、本番環境ではHTTPのまま使わない。次のセクションでHTTPS化する。

初回アクセス時に管理者アカウントの作成画面が表示される。このアカウントが管理者権限を持つ。

Nginx + Let’s Encrypt で HTTPS 公開

VPS上でHTTPのまま公開すると通信が平文で流れる。Open WebUIへのログイン情報も含まれるため、必ずHTTPSを設定する。

証明書取得（certbot）

Nginxが動いている場合はいったん停止してから証明書を取得する。

sudo apt install -y certbot
sudo systemctl stop nginx

# スタンドアロンモードで証明書取得
sudo certbot certonly --standalone -d your-domain.example.com

sudo systemctl start nginx

your-domain.example.comはVPSのIPアドレスにDNSのAレコードを向けたドメインに置き換える。

Nginx設定（WebSocket + ストリーミング対応）

Open WebUIはWebSocketとHTTPストリーミングを使う。両方に対応したNginx設定が必要。

sudo apt install -y nginx
sudo tee /etc/nginx/sites-available/open-webui <<'EOF'
server {
    listen 80;
    server_name your-domain.example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name your-domain.example.com;

    ssl_certificate /etc/letsencrypt/live/your-domain.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/your-domain.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;

        # WebSocket対応
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        # ストリーミング対応
        proxy_buffering off;
        proxy_cache off;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}
EOF

sudo ln -s /etc/nginx/sites-available/open-webui /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

proxy_buffering offとproxy_cache offを省略するとLLMのレスポンスが途中で止まったように見えることがある。ストリーミング応答には必須の設定。

CaddyによるHTTPS（NginxのかわりにCaddyを使う場合）

Caddyは証明書の自動取得・更新に対応しており、設定ファイルがよりシンプル。NginxのReverse Proxy設定に慣れていない場合はCaddyを検討してもよい。

your-domain.example.com {
    reverse_proxy localhost:3000
}

この3行がCaddyでの最小設定。HTTPSへのリダイレクトと証明書取得が自動で行われる。ただしCaddyはubuntuのapt標準リポジトリには含まれないため、Caddy公式のインストール手順に従う。

セキュリティ設定 — 公開前に必ずやること

Open WebUIをインターネットに公開する前に確認すべき設定が4点ある。見落とすと本番稼働後に問題になる。

1. ポート11434を外部に公開しない

Ollamaが待ち受けるポート11434はVPSのファイアウォールでブロックする。このポートにアクセスできると、認証なしでAPIを叩けてしまう。

# UFWを使う場合
sudo ufw deny 11434
sudo ufw allow 80
sudo ufw allow 443
sudo ufw allow 22
sudo ufw enable

2. 新規ユーザーの承認を手動制にする

Open WebUIはデフォルトで新規登録したユーザーがすぐにログインできる設定になっていることがある。管理者パネルから「New User Default Role」をpendingに変更し、管理者が承認するまでアクセスできないようにする。

設定箇所: Open WebUI管理者パネル → Admin Settings → Users → Default User Role

3. レートリミットの設定

Nginxのレートリミットを使い、同一IPからの過剰なリクエストを制限する。

# /etc/nginx/nginx.conf の http ブロック内に追加
limit_req_zone $binary_remote_addr zone=openwebui:10m rate=10r/m;
# open-webui の server ブロック内 location / に追加
limit_req zone=openwebui burst=20 nodelay;

4. Dockerイメージのバージョンをピンする

ghcr.io/open-webui/open-webui:mainのようにmainタグを使うと、コンテナ再起動時に予期せずバージョンが上がることがある。本番環境では特定バージョンタグを使うか、更新前にChangelog（Open WebUIのGitHubリポジトリ）を確認してから行う。

よくある失敗と対処（症状別チェックリスト）

症状1: Open WebUIからOllamaに接続できない（「Connection refused」）

原因: OllamaがLoopbackアドレス（127.0.0.1）にのみバインドされており、DockerコンテナからのリクエストがOllamaに届かない。

対処: Step 3のsystemd overrideでOLLAMA_HOST=0.0.0.0:11434を設定してOllamaを再起動する。docker runに--add-host=host.docker.internal:host-gatewayと-e OLLAMA_BASE_URL=http://host.docker.internal:11434を追加する。

症状2: Nginxのプロキシ経由でLLMの応答がブロックされる・止まる

原因: proxy_bufferingがデフォルトで有効のため、ストリーミングレスポンスがバッファリングされて表示が止まる。

対処: Nginx設定にproxy_buffering off;とproxy_cache off;を追加してNginxをリロードする。

症状3: Let’s EncryptでSSL証明書が取得できない

原因: ドメインのAレコードがVPSのIPに向いていない、またはポート80がファイアウォールでブロックされている。

対処: DNSの伝播が完了しているか確認する（dig your-domain.example.com）。UFWで80番ポートを開放する。

症状4: 再起動後にログインセッションが無効になる

原因: WEBUI_SECRET_KEYが未設定のため、再起動のたびにセッションキーが変わる。

対処: docker runまたはdocker-compose.ymlに-e WEBUI_SECRET_KEY=<固定の文字列>を追加して、コンテナを作り直す。

症状5: モデルのダウンロードが途中で止まる

原因: VPSのストレージ空き容量不足、またはネットワークタイムアウト。

対処: df -hでストレージを確認する。容量不足なら不要なモデルをollama rm <モデル名>で削除する。タイムアウトならollama pullを再実行する（中断箇所から再開される）。

症状6: CPU使用率が100%のまま下がらない・サーバーが重い

原因: CPU-only環境でパラメータの大きすぎるモデルを動かしている。1Bや4Bでも推論中はCPUを占有する。

対処: より小さいモデルに切り替える（例: gemma3:1b）。複数リクエストを同時に処理しないよう同時接続数を制限する。CPU-only VPSで複数ユーザーが同時に使う構成は実用的ではないと認識する。

CPU-only VPS での実用限界と次のステップ

CPU-only VPSでOllama + Open WebUIを構築したあと、実際に使い始めると次の壁にあたることが多い。

生成速度: 7B〜8Bクラスのモデルで1〜数トークン/秒。英語でも日本語でも体感では「遅い」と感じる水準になりやすい。社内の複数人が同時に使う想定では、CPU-onlyは現実的ではない。

日本語性能: モデルによって日本語対応の精度が大きく変わる。どのモデルが日本語用途に適しているかは各モデルの公開ページやコミュニティの評価を参照する（本記事執筆時点では特定モデルの対応状況を確認できていないため断定しない）。

次の選択肢:

  1. GPU付きVPSに移行する — 速度の問題は解消する。コストは上がる。選定基準については別記事で整理している。

  2. クラウドLLMとの使い分けにとどめる — 社内機密データのみをセルフホストLLMに向け、速度が必要な用途はAPI経由で処理する構成。

  3. 構築・設定を代行業者に委託する — VPSの選定・OS設定・モデル選定・ユーザー管理まで含めて外部に依頼する。相場感については別記事を参照する。

設定の途中で詰まった場合、または本番環境に移す前に構成を確認したい場合は、メールで相談を受け付けています。スコープの確認だけでも構いません。

ローカルLLM構築・実装の相談はこちら

まとめ

  • Ollama + Open WebUI をUbuntu VPSにセルフホストすることで、クラウドLLMへの費用・データ漏洩懸念・依存を減らせる
  • 最小要件はRAM 8GB・空きストレージ10GB・AVX2対応64bit CPU（GPUは不要）。ただし実用には16GB RAM以上を推奨する
  • 最大の詰まりポイントはOllamaのバインドアドレス。systemd overrideでOLLAMA_HOST=0.0.0.0:11434を設定しないとDockerコンテナからOllamaへ到達できない
  • Nginx設定ではproxy_buffering offとproxy_cache offを忘れるとストリーミング応答が止まる
  • ポート11434は外部に公開しない。ファイアウォールで必ずブロックする
  • CPU-only VPSでは生成速度に実用限界があり、複数ユーザー同時利用には不向き

よくある質問

Q: GPUなしのVPSでも実際に動きますか？

動作はします。ただし、生成速度はGPU環境と比べて大幅に遅くなります。Ollamaの公式ドキュメントおよびlocalaimaster.comの情報によると、最小要件（8GB RAM・AVX2対応CPU）を満たせば起動・推論は可能です。1人が試験的に使う用途であれば許容できる速度のことがありますが、複数人での業務利用には向きません。

Q: Open WebUIとOllamaのバージョンが更新されたら設定は変わりますか？

本記事はcomputingforgeeks.comの2026年3月検証（Ubuntu 24.04.2 / Ollama 0.18.2 / Open WebUI 0.8.10）を基準としています。特にOpen WebUIは更新頻度が高く、UI・設定項目・環境変数名が変更されることがあります。導入時はOpen WebUI公式ドキュメント（docs.openwebui.com）で最新の変更を確認してください。

Q: Docker Composeでまとめて管理できますか？

できます。Ollamaをコンテナとして動かすDocker Compose構成も存在しますが、ホスト直接インストール構成と比べてGPUパススルーの設定が複雑になることがあります。本記事では2026年3月に動作確認されたホスト直接インストール構成を採用しています。

Q: ポート3000をそのままブラウザから使っていいですか？

本番・社内向けでの利用には推奨しません。HTTPのままではログイン情報を含む通信が平文で流れます。Nginx + Let’s EncryptでHTTPS化してから使用してください。

Q: 日本語でも使えますか？

モデルによります。どのモデルが日本語対応しているか・どの程度の精度かは、Ollamaの公式ライブラリページ（ollama.com/library）や各モデルの説明文を参照してください。本記事執筆時点では特定モデルの日本語対応状況を個別に確認できていないため、特定の推奨はしません。

関連記事

AI・ローカルLLM活用n8n + Ollama：ローカルLLMをワークフロートリガーとして使う実装例AI・ローカルLLM活用プライベートGPT（機密データ対応LLM）の設計パターン4選AI・ローカルLLM活用社内RAGの精度を上げる5つのチューニング：チャンク設計からRerankerまで
記事一覧に戻る