結論

Open WebUIは、OllamaやOpenAI互換APIのLLMを、ChatGPTのような画面で使える自分で動かすWebアプリです。RAG・ユーザー管理も入っています。

この記事でわかること

  • インストール5通りの判断表とDockerの6手順
  • Ollama・vLLMへ送られるリクエスト11件の実物
  • 「つながらない」エラー原文6種と直し方

2026年10月22日更新|Open WebUI 0.12.3のソースと公式ドキュメントで確認

ブラウザは Open WebUI だけと話し、Open WebUI のバックエンドが Ollama や vLLM などのモデルのサーバーへ取り次ぎます。

flowchart TD
    B[ブラウザ<br>localhost:3000] --> W[Open WebUI<br>コンテナ内は 8080]
    W --> O[Ollama<br>:11434]
    W --> V[vLLM など]
    W --> R[RAG<br>ベクトルDB]

よく調べられることの答えを先にまとめます。

知りたいこと 答え 詳しい節
何ができる? 複数のLLMのチャット・RAG・Web検索・ユーザー管理 Open WebUIとは
いちばん早い入れ方 docker run … ghcr.io/open-webui/open-webui:main Dockerでインストール
開くURL Docker は http://localhost:3000、pip は 8080 Dockerでインストール
Ollama につながらない コンテナからは host.docker.internal:11434 よくあるエラー
vLLM をつなぐ 接続に http://host.docker.internal:8000/v1 OpenAI互換API
日本語にする 設定 → 一般 → 言語で「日本語」 初期設定
文書を読ませる チャットで #、またはナレッジベース RAG
料金 無料。50人を超えるならロゴ・名前は変えない ライセンス

確認環境:Open WebUI 0.12.3(PyPI で 2026年10月16日公開)のソース一式(PyPI の配布物)を読み、Ollama の URL の既定値・RAG の既定値・ヘッダーの組み立て・OpenAI 形式から Ollama 形式への変換を確かめました。リクエストの実物は、Ubuntu 24.04.4 LTS・Python 3.11.15・aiohttp 3.14.3(Open WebUI 0.12.3 が指定する版)で、Ollama 互換と OpenAI 互換の擬似サーバー(127.0.0.1:33111 と 33121)を立て、ソースと同じ形で組み立てたリクエストを送って記録したものです。Docker から Ollama につながらない状態は、iproute2 6.1.0 の ip netns で「ホスト」と「コンテナ」の2つのネットワークを作って再現し、Open WebUI と同じ aiohttp で出たエラー原文を載せています。インストールの手順・画面の操作・ライセンスは docs.openwebui.com と GitHub で確認しました(確認日 2026年10月22日)。

本記事の内容は、ご自由にお使いください。
ご利用の際は、出典として本ページへのリンクを記載いただけますようお願いします。

(記載例)出典:株式会社RJC「Open WebUIとは|インストール・使い方・Ollama接続とRAG設定」

Open WebUIとは:できること・料金・ライセンス

この節では、Open WebUI が何をするソフトで、何ができて、お金がかかるのかが分かります。

Open WebUI(オープン・ウェブ・ユーアイ)は、LLM(大規模言語モデル)をブラウザのチャット画面から使うための、自分のPCやサーバーで動かす Web アプリです。 README は "a self-hosted AI platform" と説明し、Ollama と OpenAI 互換の API に対応していると書いています。モデルそのものは入っておらず、Ollama・vLLM・LM Studio・OpenAI などの「モデルを動かすサーバー」につないで使う画面とサーバーです。

1ChatGPT のような画面

会話の履歴・ピン留め・アーカイブ、複数のモデルを並べて同時に聞く、Markdown・数式の表示。スマホでも使え、PWA としてホーム画面に置けます。

2いろいろなモデルをまとめる

ローカルの Ollama と、vLLM・LM Studio・OpenAI・OpenRouter など OpenAI 互換の API を、1つの画面のモデル一覧に並べます。

3RAG(文書を読ませる)

PDF などを取り込み、質問に関係する部分を探してモデルに渡します。ナレッジベース・ハイブリッド検索・Web 検索にも対応します。

4チームで使う機能

ログイン、管理者・ユーザー・承認待ちのロール、グループごとの権限、モデルごとの公開範囲、LDAP・OAuth・SCIM。

README の主な機能を、使う場面ごとにまとめました。

分類 できること 設定する場所
チャット 履歴・複数モデルの同時比較・プロンプトの保存 チャット画面・ワークスペース
モデル Ollama・OpenAI 互換 API の接続、モデルの取得 管理者パネル → 設定 → 接続
RAG 文書・URL の取り込み、ナレッジベース、ハイブリッド検索 管理者パネル → 設定 → ドキュメント
Web 検索 SearXNG・Brave・Tavily など多数の検索サービス 管理者パネル → 設定 → ウェブ検索
ツール Tools・Functions・MCP・OpenAPI のツールサーバー ワークスペース・設定
音声・画像 音声入力・読み上げ・音声通話、画像の生成と編集 管理者パネル → 設定 → オーディオ・画像
管理 ユーザー・グループ・権限・利用状況の分析 管理者パネル → ユーザー
データ SQLite か PostgreSQL、ベクトル DB は9種類から 環境変数

料金とライセンス(2026年10月22日時点)

Open WebUI 自体は無料で使えます。 有料の SaaS ではなく、自分で動かすソフトです。かかるのは、動かすサーバーの費用と、つないだ API(OpenAI など)の利用料です。企業向けのサポートやロゴの差し替えを含む Enterprise ライセンスもあり、公式ドキュメントでは価格は公開されておらず、問い合わせの形です。

ライセンスは、v0.6.6(2025年4月19日)から Open WebUI License です。BSD-3-Clause の条文に、次の条件(第4項)が足されています。

項目 内容(LICENSE ファイルと公式ドキュメント)
商用・社内利用 できる。社内の人数に上限は無い
「Open WebUI」の名前・ロゴ 変えたり消したりできない
変えてよい場合 30日間の利用者が50人以下、書面の許可、Enterprise ライセンス
v0.6.5 までのコード BSD-3-Clause のまま
OSI の「オープンソース」か 公式の FAQ は、v0.6.6 以降は OSI 承認のライセンスではないと説明

ロゴや名前を変えずに使うなら、人数に関係なく社内で使えます。 自社の名前に差し替えて50人を超える人に出すときは、Enterprise ライセンスが要ります。正確な条件は、LICENSE の全文で確かめます。

0.12系の主な変更(2026年10月)

0.12.0 は 2026年10月10日、この記事で読んだ 0.12.3 は 10月16日の公開です。CHANGELOG から、使う人に関係の大きいものを挙げます。

追加された機能 内容
2段階認証 管理者が認証アプリでのサインインを全員に必須にできる(ENABLE_MFA)
リアルタイム音声通話 OpenAI の Realtime モデルで音声のやり取り
ナレッジベースの画面 フォルダーとファイルを並べ、元のファイルと検索される文章を見比べる
モデル・ツールの版の履歴 保存のたびに版が残り、前の版に戻せる
グループの入れ子 親グループの権限を子グループが引き継ぐ
ツール検索 ツールが多いとき、名前と説明だけを渡して必要なものを探させる

Open WebUIの仕組み:OllamaやOpenAI互換APIとのつながり

この節では、画面で何かをしたときに、Open WebUI がどのサーバーに何を送っているかが分かります。

ブラウザは Ollama や vLLM に直接つながりません。 ブラウザは Open WebUI のサーバー(バックエンド)とだけ話し、バックエンドが設定された URL へリクエストを取り次ぎます。リポジトリの TROUBLESHOOTING.md も、画面からの /ollama/api/tags は、バックエンドの OLLAMA_BASE_URL/api/tags と同じだと説明しています。

このため、接続の URL は「Open WebUI のサーバーから見た住所」で書きます。 Open WebUI を Docker で動かしているなら、コンテナの中から見た住所です。ここを取り違えるのが、「つながらない」の原因の大半です(後の「よくあるエラー」の節で再現します)。

0.12.3 のソースで確かめた、画面の操作とバックエンドが送るリクエストの対応です。

画面の操作 Ollama へ OpenAI 互換 API へ
接続の確認(Verify Connection) GET /api/version GET /models
モデル一覧を出す GET /api/tags・GET /api/ps GET /models
チャットを送る POST /api/chat POST /chat/completions
文書の埋め込み(RAG) POST /api/embed POST /embeddings
モデルを取得する POST /api/pull (無し)

OpenAI 互換 API の URL は /v1 まで含めて登録するので、実際に届く道は /v1/models・/v1/chat/completions になります。

Ollama の接続

URL は http://ホスト:11434(/api は付けない)

Ollama 独自の API(/api/chat)で話す

モデルの取得・削除も画面からできる

OpenAI 互換 API の接続

URL は http://ホスト:8000/v1 のように /v1 まで

API キーは Authorization: Bearer で送られる

vLLM・LM Studio・llama.cpp・OpenAI・OpenRouter など

Open WebUIのインストール方法と必要な環境

この節では、Docker・pip・uv などの入れ方の違いと、自分に合う方法の選び方が分かります。

公式ドキュメントが案内する入れ方は、Docker(推奨)・Docker Compose・Python(pip・uv・conda)・Kubernetes(Helm)です。macOS・Windows・Linux 用のデスクトップアプリ(open-webui/desktop)もあります。

入れ方 向いている人 開くURL・注意
Docker(:main) Ollama は別に入っている。まず試したい localhost:3000。データはボリュームに残る
Docker(:ollama) Ollama も一緒に1つのコンテナで動かしたい GPU を使うなら --gpus=all
Docker Compose Ollama と Open WebUI を別のコンテナで管理したい リポジトリの docker-compose.yaml
pip Docker を使わず Python で動かしたい localhost:8080。Python 3.11・3.12 だけ
uv Python の版を気にせず1行で起動したい uvx --python 3.11 open-webui@latest serve
3.11・3.12pip で使える Python3.13 は未対応(公式)
1.62GB:main イメージ(圧縮時):slim は約197MB
106MB0.12.3 の wheel 1つ依存は106個(PyPI)

チャットの文章を作るのは、つないだ先の Ollama・vLLM です。 GPU や大きなメモリが要るのは主にそちらの側です。Open WebUI の標準イメージは、RAG 用の埋め込みモデル(既定は sentence-transformers/all-MiniLM-L6-v2)などを自分の中で動かすため、イメージが大きくなっています。:cuda は、それらを NVIDIA GPU で動かすためのイメージです。

Docker イメージのタグの違いです(公式ドキュメント)。

タグ 中身
:main(:latest と同じ) 標準。推奨
:slim 埋め込みなどのローカルの ML モデルを含まない軽量版。ベクトル DB の既定が pgvector になる
:cuda・:cuda126 NVIDIA GPU 用(CUDA 12.8・12.6)
:ollama Ollama を同梱
:dev 開発中の版(毎日変わる)
:v0.12.3 など 版を固定。本番はこちらが安全

slim と CUDA、slim と Ollama 同梱は組み合わせられません。

Dockerでインストールする(手順とコマンド)

この節では、Docker で Open WebUI を起動して、ブラウザで開くまでの手順が分かります。

Docker Desktop(Windows・Mac)か Docker Engine(Linux)が入っていることが前提です。Docker Desktop では、設定の Resources で Docker に割り当てるメモリを確かめておきます。Ollama も Docker で動かす場合、モデルの大きさより少ないとモデルを読み込めません。

1

秘密鍵を作る

openssl rand -hex 32 で64文字の文字列を作り、控えておきます。ログインの署名に使う鍵で、毎回同じ値を使います。

WEBUI_SECRET_KEY

2

Ollama を用意する

ホストに Ollama を入れてモデルを1つ取得しておくか、:ollama タグで同梱のものを使います。

ポート 11434

3

docker run で起動する

下のコマンドで起動します。-v open-webui:/app/backend/data が、ユーザー・会話・設定を残す場所です。

-p 3000:8080

4

ブラウザで開く

http://localhost:3000 を開きます。起動直後は準備に少し時間がかかります。

docker logs で確認

5

管理者アカウントを作る

最初に作ったアカウントが管理者になり、その後の新規登録は止まります。パスワードは控えておきます。

初期設定の節

6

モデルを選んで話す

画面左上のモデル一覧に Ollama のモデルが出れば、つながっています。出なければ「よくあるエラー」の節へ。

接続の確認

秘密鍵は次のように作ります(手元の OpenSSL 3.0.13 で 64 文字になることを確かめました)。

openssl rand -hex 32

公式ドキュメントの標準のコマンドです。your-secret-key を作った鍵に置き換えます。

docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway \
  -v open-webui:/app/backend/data -e WEBUI_SECRET_KEY=your-secret-key \
  --name open-webui --restart always ghcr.io/open-webui/open-webui:main
オプション 意味
-p 3000:8080 ホストの 3000 番を、コンテナの 8080 番(Open WebUI が待つポート)につなぐ
--add-host=host.docker.internal:host-gateway コンテナの中から host.docker.internal でホストに届くようにする(Linux で必要)
-v open-webui:/app/backend/data 会話・ユーザー・設定・取り込んだ文書を名前付きボリュームに残す
-e WEBUI_SECRET_KEY=… 鍵を固定する。無いとコンテナを作り直したときに全員がログアウトされる
--restart always PC の再起動後も自動で起動する

目的別のコマンドです(公式ドキュメント)。

# Ollama を同梱(CPU だけ)
docker run -d -p 3000:8080 -v ollama:/root/.ollama -v open-webui:/app/backend/data \
  -e WEBUI_SECRET_KEY=your-secret-key --name open-webui --restart always ghcr.io/open-webui/open-webui:ollama

# Ollama を同梱(NVIDIA GPU)
docker run -d -p 3000:8080 --gpus=all -v ollama:/root/.ollama -v open-webui:/app/backend/data \
  -e WEBUI_SECRET_KEY=your-secret-key --name open-webui --restart always ghcr.io/open-webui/open-webui:ollama

# Ollama が別のサーバーにある
docker run -d -p 3000:8080 -e OLLAMA_BASE_URL=https://example.com -v open-webui:/app/backend/data \
  -e WEBUI_SECRET_KEY=your-secret-key --name open-webui --restart always ghcr.io/open-webui/open-webui:main

# OpenAI の API だけを使う
docker run -d -p 3000:8080 -e OPENAI_API_KEY=your_secret_key -v open-webui:/app/backend/data \
  --name open-webui --restart always ghcr.io/open-webui/open-webui:main

# 1人で使う(ログイン画面なし)
docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway -e WEBUI_AUTH=False \
  -v open-webui:/app/backend/data -e WEBUI_SECRET_KEY=your-secret-key --name open-webui --restart always ghcr.io/open-webui/open-webui:main

WEBUI_AUTH=False は、ユーザーが1人もいない状態で始めるときだけ使えます。 0.12.3 のソース(routers/auths.py)では、既にユーザーがいると次のエラーで止まります。複数人で使う予定があるなら、最初からログインありで始めます。

You can't turn off authentication because there are existing users. If you want to disable WEBUI_AUTH, make sure your web interface doesn't have any existing users and is a fresh installation.

ポートを変える

ホスト側のポートを変えるのは -p の左の数字です。3000 番が他のアプリで使われているなら -p 3001:8080 にして http://localhost:3001 を開きます。右の 8080 は、コンテナの中で Open WebUI が待つポート(Dockerfile の PORT=8080)なので変えません。3000 番を使っているプロセスは、Linux・Mac なら lsof -i :3000 で調べられます。

Docker ComposeでOllamaと一緒に起動する

Open WebUI のリポジトリにある docker-compose.yaml(0.12.3 の配布物に含まれるもの)は、Ollama と Open WebUI を別のコンテナで起動する形です。

services:
  ollama:
    volumes:
      - ollama:/root/.ollama
    container_name: ollama
    pull_policy: always
    tty: true
    restart: unless-stopped
    image: ollama/ollama:${OLLAMA_DOCKER_TAG-latest}

  open-webui:
    build:
      context: .
      dockerfile: Dockerfile
    image: ghcr.io/open-webui/open-webui:${WEBUI_DOCKER_TAG-main}
    container_name: open-webui
    volumes:
      - open-webui:/app/backend/data
    depends_on:
      - ollama
    ports:
      - ${OPEN_WEBUI_PORT-3000}:8080
    environment:
      - 'OLLAMA_BASE_URL=http://ollama:11434'
      - 'WEBUI_SECRET_KEY='
    extra_hosts:
      - host.docker.internal:host-gateway
    restart: unless-stopped

volumes:
  ollama: {}
  open-webui: {}

同じ Compose の中では、http://ollama:11434 のようにサービス名で相手に届きます。 localhost ではありません。WEBUI_SECRET_KEY= が空なので、.env などで鍵を入れてから使います。build: があるのでリポジトリを clone した場所で使う前提の形です。イメージを取ってくるだけなら build: の3行を消しても動く書き方です。

docker compose pull
docker compose up -d
docker exec -it ollama ollama pull qwen3:4b    # Ollama のコンテナにモデルを取得
docker compose logs -f open-webui              # 起動のログを見る
docker compose down                            # 止めて片付ける(ボリュームは残る)

compose.yaml の書き方は、関連記事「Docker Composeの使い方|compose.yamlの書き方と開発環境の作り方」で扱っています。

更新・停止・削除とデータの場所

やりたいこと コマンド
動いているか見る docker ps
ログを見る docker logs -f open-webui
止める・始める docker stop open-webui・docker start open-webui
更新する docker rm -f open-webui → docker pull ghcr.io/open-webui/open-webui:main → 同じ docker run
消す(データは残す) docker rm -f open-webui
データも消す docker volume rm open-webui(戻せない)

更新するときは、同じボリューム(-v open-webui:/app/backend/data)と同じ WEBUI_SECRET_KEY で起動し直します。 コンテナを消しても、ボリュームが残っていれば会話とユーザーは残ります。公式ドキュメントは、更新の前に毎回データのボリュームのバックアップを取るよう案内しています。

pip・uvでインストールする(Dockerを使わない)

この節では、Docker を使わず Python で Open WebUI を動かす方法と、そのときのデータの置き場所が分かります。

# pip(Python 3.11 か 3.12 の仮想環境で)
python3.11 -m venv venv
source venv/bin/activate          # Windows は venv\Scripts\activate
pip install open-webui
open-webui serve                  # http://localhost:8080

# データの置き場所とポートを指定する
DATA_DIR=~/.open-webui open-webui serve --port 3000

# uv(Python の版ごと用意して起動する)
DATA_DIR=~/.open-webui uvx --python 3.11 open-webui@latest serve

# 更新
pip install -U open-webui

Windows の PowerShell で uv を使うときは、公式ドキュメントの次の形です。

$env:DATA_DIR="C:\open-webui\data"; uvx --python 3.11 open-webui@latest serve

0.12.3 のソース(open_webui/__init__.py)で確かめた open-webui serve の動きです。

項目 0.12.3 の動き
待つアドレス 既定は --host 0.0.0.0(同じネットワークの他の PC からも開ける)
ポート 既定は --port 8080
秘密鍵 WEBUI_SECRET_KEY が無ければ、起動した場所の .webui_secret_key を読む。無ければ作る
データ DATA_DIR が無ければ、入れた Python の site-packages/open_webui/data
版の確認 open-webui --version

DATA_DIR を指定しないと、データが Python の環境の中に置かれ、環境を作り直すと消えます。 また、鍵のファイルは「起動した場所」に作られるので、毎回同じ場所から起動するか、WEBUI_SECRET_KEY を指定します。自分の PC だけで使うなら --host 127.0.0.1 にすると、他の PC からは開けなくなります。

初期設定:管理者アカウント・日本語化・モデルの追加

この節では、初めて開いたあとにやることを、画面の場所つきで順に確かめられます。

  • 1管理者アカウントを作る最初の画面「管理者アカウントを作成」で作った人が管理者。パスワードを無くすと設定に入れなくなる
  • 2表示を日本語にする右上のアイコン → 設定 → 一般 → 言語で「日本語」。0.12.3 は 65 の言語ファイルを持つ
  • 3接続を確かめる管理者パネル → 設定 → 接続。Ollama の URL の横の「接続を確認」
  • 4モデルを取得するOllama の管理(Manage)から「Pull a model from Ollama.com」。モデル選択の欄に名前を打っても取得できる
  • 5既定のモデルを決める管理者パネル → 設定 → モデル。グループごとの既定のモデルも決められる(0.12.0〜)
  • 6新規登録の扱いを決める管理者パネル → 設定 → 認証の「新規登録」。許可すると新しい人は「承認待ち」になる

日本語の言語ファイル(ja-JP)はありますが、翻訳されていない項目は英語のまま出ます。 0.12.3 の ja-JP を見ると、「Manage Ollama API Connections」は「Ollama API接続の管理」、「Verify Connection」は「接続を確認」、「Knowledge」は「ナレッジベース」と訳されています。この記事の画面の名前は、その日本語の表示に合わせています。

Hugging Face の GGUF のモデルは、取得の欄に hf.co/{ユーザー名}/{リポジトリ名}:{量子化} の形で書くと取れます(例:hf.co/ggml-org/gemma-3-270m-it-GGUF:Q8_0)。Ollama のコマンドでの取得・一覧・削除は、関連記事「Ollamaの使い方|ローカルLLMのコマンド一覧とAPIの呼び方」で扱っています。

Ollamaとの接続設定

この節では、Ollama がどこで動いているかによって、どの URL を書けばよいかと、設定の場所が分かります。

設定の場所は、管理者パネル → 設定 → 接続の「Ollama API接続の管理」です。 起動時に環境変数 OLLAMA_BASE_URL で渡すこともできます。

URL は「Open WebUI がどこで動いていて、Ollama がどこで動いているか」で決まります。

Open WebUI Ollama 書く URL
pip・uv(ホストで直接) 同じ PC http://localhost:11434
Docker 同じ PC(ホスト) http://host.docker.internal:11434
Docker(--network=host) 同じ PC(ホスト) http://127.0.0.1:11434(画面は 8080)
Docker Compose 同じ Compose のサービス http://ollama:11434
どれでも 別のサーバー http://192.168.1.50:11434 など
Docker(:ollama 同梱) 同じコンテナの中 http://localhost:11434(自動)
Podman 同じ PC(ホスト) http://host.containers.internal:11434

OLLAMA_BASE_URL を書かなかったときの既定の値は、0.12.3 の config.py で次のようになっていました。

動かし方 既定の URL(ソースで確認)
Docker イメージ(ENV=prod・OLLAMA_BASE_URL=/ollama) http://host.docker.internal:11434
Docker イメージ(:ollama 同梱) http://localhost:11434
pip・uv http://localhost:11434
Kubernetes(K8S_FLAG あり) http://ollama-service.open-webui.svc.cluster.local:11434

URL を指定しなかったときに 11434 番が開いていなければ、12434 番も試します(0.12.3 の _resolve_ollama_base_url)。どちらも開いていなければ、そのままの URL で起動します。

Docker の既定が host.docker.internal なので、Linux で --add-host=host.docker.internal:host-gateway を付け忘れると、名前が引けずにつながりません。 Docker Desktop(Windows・Mac)は、この名前を最初から使えます。

Ollama側の設定:OLLAMA_HOST

Ollama の FAQ は「Ollama binds 127.0.0.1 port 11434 by default.」と説明しています。自分の PC の中からの接続しか受けない、という意味です。Docker のコンテナや別のサーバーの Open WebUI からつなぐときは、Ollama 側に OLLAMA_HOST=0.0.0.0:11434 を設定して再起動します。

Ollama の動かし方 設定のしかた(Ollama の FAQ)
Linux(systemd) systemctl edit ollama.service の [Service] に Environment="OLLAMA_HOST=0.0.0.0:11434" → systemctl daemon-reload → systemctl restart ollama
macOS のアプリ launchctl setenv OLLAMA_HOST "0.0.0.0:11434" → Ollama を再起動
Windows タスクバーで Ollama を終了 → ユーザーの環境変数に OLLAMA_HOST → スタートメニューから起動

外から届くようになるので、ファイアウォールで Open WebUI のサーバーからだけ受けるようにします。

複数のOllamaをつなぐ

接続は複数登録でき、同じ名前のモデルがあると、Open WebUI がランダムに振り分けます(簡単な負荷分散)。公式ドキュメントによれば、振り分けるには各サーバーのモデル ID が一字一句同じで、Prefix ID も同じ(または空)である必要があります。接続の「モデルID」に書いたモデルだけを表示する、許可リストとしても使えます。

Open WebUIがOllamaに送るリクエスト(実物)

0.12.3 のソースのとおりにリクエストを組み立て、Ollama 互換の擬似サーバー(127.0.0.1:33111)に送って、届いた中身を記録しました。擬似サーバーは推論をせず、固定の返事を返します。

送った順番と応答です。

GET http://127.0.0.1:33111/api/version -> 200 application/json; charset=utf-8
  {"version": "0.0.0-s331"}
GET http://127.0.0.1:33111/api/tags -> 200 application/json; charset=utf-8
  {"models": [{"name": "qwen3:4b", "model": "qwen3:4b", "modified_at": "2026-10-22T09:00:00+09:00", ...
GET http://127.0.0.1:33111/api/ps -> 200 application/json; charset=utf-8
  {"models": []}
POST http://127.0.0.1:33111/api/chat -> 200 application/x-ndjson
  {"model": "qwen3:4b", "created_at": "2026-10-22T12:00:00Z", "message": {"role": "assistant", "content": "(擬似Ollamaの"}, "done": false}
  {"model": "qwen3:4b", "created_at": "2026-10-22T12:00:00Z", "message": {"role": "assistant", "content": "固定の返事)"}, "done": false}
  {"model": "qwen3:4b", "created_at": "2026-10-22T12:00:01Z", "message": {"role": "assistant", "content": ""}, "done": true, "done_reason": "stop", "prompt_eval_count": 31, "eval_count": 2}
POST http://127.0.0.1:33111/api/chat -> 404 application/json; charset=utf-8
  {"error": "model 'qwen3' not found"}

チャットのとき、擬似サーバーに届いたリクエストです。モデルの詳細設定(Advanced Params)で temperature 0.6・コンテキスト長 8192・最大トークン 512 を指定した場合の形です。

{
 "method": "POST",
 "path": "/api/chat",
 "headers": {
  "Content-Type": "application/json",
  "Accept": "*/*",
  "User-Agent": "Python/3.11 aiohttp/3.14.3"
 },
 "body": {
  "model": "qwen3:4b",
  "messages": [{"role": "user", "content": "Open WebUIとは?"}],
  "stream": true,
  "options": {"temperature": 0.6, "num_ctx": 8192, "num_predict": 512}
 }
}

記録から分かることです。

  • 画面のチャットは、Ollama の OpenAI 互換の道(/v1/chat/completions)ではなく、Ollama 独自の /api/chat に届きます。 返事は1行ずつの JSON(NDJSON)で少しずつ届き、Open WebUI がそれを OpenAI の形に直して画面に流します。
  • OpenAI の名前の max_tokens は、Ollama の名前の num_predict に直され、options の中に入ります(apply_model_params_to_body_ollama)。コンテキスト長も options.num_ctx として送られます。
  • 接続に API キーを書かなければ、Authorization ヘッダーは付きません。書けば Authorization: Bearer … が付きます(get_headers_and_cookies)。
  • モデル名が1文字でも違うと、Ollama は 404 と model '…' not found を返します。 qwen3 と qwen3:4b は別の名前です。

OpenAI互換API(vLLMなど)を追加する

この節では、vLLM・LM Studio・llama.cpp・OpenAI などを Open WebUI に追加する手順と、そのとき送られるものが分かります。

管理者パネル → 設定 → 接続の「OpenAI API接続の管理」で +(接続を追加)を押し、URL と API キーを入れて保存します。 保存しただけでは接続を試さないので、「接続を確認」で /models を呼んで確かめます。/models に対応しないサービスは、「モデルID」に使うモデルの名前を手で足します。

つなぐ先 URL の例(公式ドキュメントなど) API キー
vLLM(ホストで vllm serve) http://host.docker.internal:8000/v1 --api-key に付けた値(無ければ任意)
LM Studio http://localhost:1234/v1 空
llama.cpp(llama-server) http://localhost:10000/v1 空
OpenAI https://api.openai.com/v1 OpenAI の API キー
Anthropic https://api.anthropic.com/v1 Anthropic の API キー
Google Gemini https://generativelanguage.googleapis.com/v1beta/openai Gemini の API キー(末尾の / なし)
Azure OpenAI https://my-resource.openai.azure.com/openai/v1 Azure のキー。デプロイ名をモデルIDに

表の localhost は、Open WebUI を pip で動かしている場合です。Docker で動かしているなら、ホストで動くサーバーは host.docker.internal に置き換えます。接続の詳細設定の「Provider」は、Default・Azure OpenAI・llama.cpp・LM Studio・LiteLLM から選べ、vLLM は Default のままで使います。vLLM の起動のしかたは、関連記事「vLLMとは|使い方・インストール・OpenAI互換APIとOllamaとの違い」で扱っています。

送られるリクエストと401(実物)

vLLM と同じ形で、/v1/models と /v1/chat/completions に答え、Bearer sk-s331-local 以外を 401 で断る擬似サーバー(127.0.0.1:33121)に、0.12.3 のソースと同じ形で送りました。

GET http://127.0.0.1:33121/v1/models -> 200 application/json; charset=utf-8
  {"object": "list", "data": [{"id": "Qwen/Qwen3-8B", "object": "model", "created": 1792656000, "owned_by": "vllm"}]}
GET http://127.0.0.1:33121/v1/models -> 401 application/json; charset=utf-8
  {"error": "Unauthorized"}
POST http://127.0.0.1:33121/v1/chat/completions -> 200 text/event-stream
  data: {"id": "chatcmpl-s331", "object": "chat.completion.chunk", ..., "choices": [{"index": 0, "delta": {"role": "assistant", "content": ""}, "finish_reason": null}]}
  data: {"id": "chatcmpl-s331", "object": "chat.completion.chunk", ..., "choices": [{"index": 0, "delta": {"content": "(擬似OpenAI互換の固定の返事)"}, "finish_reason": null}]}
  data: [DONE]

チャットのときに届いた中身です。

{
 "method": "POST",
 "path": "/v1/chat/completions",
 "headers": {
  "Content-Type": "application/json",
  "Authorization": "Bearer sk-s331-local",
  "Accept": "*/*",
  "User-Agent": "Python/3.11 aiohttp/3.14.3"
 },
 "body": {
  "model": "Qwen/Qwen3-8B",
  "stream": true,
  "stream_options": {"include_usage": true},
  "messages": [{"role": "user", "content": "Open WebUIとは?"}],
  "temperature": 0.6
 }
}
  • 接続に登録した URL の後ろに /chat/completions が足されます。 登録を http://…:8000(/v1 なし)にすると /models・/chat/completions に届き、/v1 の下で待つ vLLM には当たりません。
  • API キーは Authorization: Bearer で送られます。キーが違うと /models が 401 になり、接続の確認が失敗してモデル一覧にも出ません。
  • ストリーミングで、モデルが使用量を返せる設定のとき、0.12.3 は stream_options.include_usage: true を足します(main.py)。トークン数を集計するためです。
  • 送り先の URL に openrouter.ai が含まれるときだけ、HTTP-Referer: https://openwebui.com/ と X-Title: Open WebUI が足されます(utils/headers.py)。

ユーザー情報を転送するヘッダー

vLLM の前に置いたゲートウェイなどで「誰が使ったか」を記録したいときは、ENABLE_FORWARD_USER_INFO_HEADERS=true で起動します。接続の詳細設定の Headers に独自のヘッダーを書くと、{{USER_ID}}・{{MODEL_ID}} などが置き換えられて送られます。両方を設定して送ったときに届いたヘッダーです。

{
 "Content-Type": "application/json",
 "X-OpenWebUI-User-Name": "Yamada Taro",
 "X-OpenWebUI-User-Id": "u-0001",
 "X-OpenWebUI-User-Email": "yamada@example.com",
 "X-OpenWebUI-User-Role": "user",
 "Authorization": "Bearer sk-s331-local",
 "X-Tenant": "team-a",
 "X-Caller": "u-0001"
}

名前とメールアドレスが、つないだ先のサーバーに送られます。 外部のサービスにつなぐ接続で有効にするときは、送ってよい情報かを確かめます。0.12.3 では FORWARD_USER_INFO_HEADER_JWT_SECRET を設定すると、個別のヘッダーの代わりに署名つきの JWT を1つ(X-OpenWebUI-User-Jwt)送ります。

RAG(文書の取り込み)の設定

この節では、文書を読ませる2つの方法と、RAG の既定値、モデルに実際に渡される文章が分かります。

文書を読ませる方法は2つあります。 チャットの入力欄にファイルを添付するか # を打ってファイルや URL を選ぶ方法と、ワークスペース → ナレッジベースで文書の集まりを作り、モデルやチャットに付ける方法です。ナレッジベースは、同じ資料を何度も使うとき・チームで共有するときに向いています。

flowchart TD
    F[文書を追加<br>PDF・URL など] --> C[文字を取り出し<br>チャンクに分ける]
    C --> E[埋め込み<br>ベクトルにする]
    E --> D[ベクトルDB<br>既定は Chroma]
    Q[質問] --> D
    D --> M[近いチャンクを<br>テンプレートに入れてLLMへ]

RAG の考え方と、自分で Python で作る方法は、関連記事「RAGの作り方|Pythonで動かす最小構成と精度の上げ方」で扱っています。

RAGの既定値(0.12.3のソースで確認)

設定の場所は、管理者パネル → 設定 → ドキュメントです。環境変数でも最初の値を渡せます。

画面の項目 環境変数 既定値(config.py)
埋め込みモデル RAG_EMBEDDING_MODEL sentence-transformers/all-MiniLM-L6-v2
埋め込みモデルエンジン RAG_EMBEDDING_ENGINE 空(Open WebUI の中で動かす)
チャンクサイズ CHUNK_SIZE 1000
チャンクのオーバーラップ CHUNK_OVERLAP 100
トップ K RAG_TOP_K 3
ハイブリッド検索 ENABLE_RAG_HYBRID_SEARCH オフ
フルコンテキストモード RAG_FULL_CONTEXT オフ
ベクトル DB VECTOR_DB chroma(slim は pgvector)
1000字チャンクサイズの既定分け方は文字数(character)
3件質問ごとに探すチャンクRAG_TOP_K の既定
1,445字既定の RAG テンプレート文書の前に毎回付く英文の指示

既定の埋め込みモデルは英語向けの小さなモデルです。 日本語の文書で見つけたい部分が出てこないときは、埋め込みモデルを多言語のものに変えるか、埋め込みモデルエンジンを Ollama にして Ollama の埋め込みモデルを使います。埋め込みモデルを変えたら「再インデックス」が要ります。 前のモデルで作ったベクトルとは比べられないためです。公式ドキュメントによれば、チャットに直接添付したファイルは再インデックスの対象外なので、もう一度アップロードします。

埋め込みをOllamaにしたときのリクエスト(実物)

埋め込みモデルエンジンを Ollama にすると、文書のチャンクはまとめて Ollama の /api/embed に送られます。0.12.3 の generate_ollama_batch_embeddings と同じ本文を、擬似サーバーに送りました。

{
 "path": "/api/embed",
 "body": {
  "input": [
   "Open WebUI の既定のチャンクサイズは 1000、重なりは 100。",
   "RAG の検索件数(Top K)の既定は 3。"
  ],
  "model": "nomic-embed-text:latest",
  "truncate": true
 }
}
POST http://127.0.0.1:33111/api/embed -> 200 application/json; charset=utf-8
  {"model": "nomic-embed-text:latest", "embeddings": [[0.01, 0.01, 0.01, 0.01], [0.02, 0.02, 0.02, 0.02]]}

埋め込み用のモデル(この例では nomic-embed-text)を、Ollama で先に取得しておきます。

モデルに渡される文章(実物)

見つかったチャンクは <source> タグで囲まれ、既定の RAG テンプレートの {{CONTEXT}} に入り、ユーザーの質問の前に付けられて送られます(RAG_SYSTEM_CONTEXT が false の既定のとき)。0.12.3 の DEFAULT_RAG_TEMPLATE をそのまま使い、2つのチャンクで組み立てて /api/chat に送ったときの content です(長いので途中を省きます)。

### Task:
Respond to the user query using the provided context, incorporating inline citations in the format [id] **only when the <source> tag includes an explicit id attribute** (e.g., <source id="1">).

### Guidelines:
- If you don't know the answer, clearly state that.
- If uncertain, ask the user for clarification.
- Respond in the same language as the user's query.
(中略)

<context>
<source id="1" name="rag-memo.md" resource-type="file" resource-id="file-01">Open WebUI の既定のチャンクサイズは 1000、重なりは 100。</source>
<source id="1" name="rag-memo.md" resource-type="file" resource-id="file-01">RAG の検索件数(Top K)の既定は 3。</source>
</context>

チャンクの既定値は?
  • 返事の中の [1] のような番号は、<source id="1"> に対応する出典の印です。
  • テンプレートは管理者パネル → 設定 → ドキュメントの「RAG テンプレート」で変えられます。公式ドキュメントは、{{QUERY}} を書くと質問が2回入るので書かないよう案内しています。
  • テンプレート(1,445字)+チャンク3件(各1000字まで)+質問が毎回入ります。 Ollama のコンテキスト長が小さいと、先頭が切れて文書を読まずに答えることがあります。

文書を読まない・途中で切れるとき

公式ドキュメントは、Ollama が 24GiB 未満の GPU では既定のコンテキスト長が 4096 トークンになることを挙げ、モデルの詳細設定でコンテキスト長を 8192 以上(できれば 16000 超)に上げるよう案内しています。上の実物のとおり、画面で設定した値は options.num_ctx として Ollama に送られます。

症状 よくある原因 直し方
文書があるのに「分からない」と答える 日本語に弱い埋め込みモデル、トップ K が少ない 多言語の埋め込みモデル、トップ K を増やす、ハイブリッド検索
返事が空・途中で止まる コンテキスト長が足りず先頭が切れる モデルの詳細設定で num_ctx を上げる
埋め込みモデルを変えたら何も見つからない 前のモデルのベクトルと次元が違う 管理者パネル → 設定 → ドキュメントで再インデックス
PDF の表や画像の文字が読めない 既定の取り出し方では読めない形式 コンテンツ抽出エンジンを Tika・Docling などに
文書全体を読ませたい RAG は一部だけを渡す フルコンテキストモード(長い文書はコンテキスト長に注意)

ユーザー・権限の管理

この節では、ロールの違いと、チームで使うときに最初に決める設定が分かります。

ロールは「管理者(admin)」「ユーザー(user)」「承認待ち(pending)」の3つです。 0.12.3 の既定(DEFAULT_USER_ROLE=pending)では、新しく登録した人は承認待ちになり、「アカウント承認待ち」の画面で止まります。管理者が管理者パネル → ユーザーでロールを user に変えると使えるようになります。

ロール できること 主な設定
管理者 接続・ドキュメント・認証などすべての設定、ユーザーの承認 最初のアカウント
ユーザー 許可されたモデル・機能でチャット 権限とグループで細かく制御
承認待ち 何もできない。承認を待つ画面 DEFAULT_USER_ROLE の既定
環境変数 既定(0.12.3) 意味
WEBUI_AUTH True ログインを使う。False は1人用(ユーザーがいない最初だけ)
ENABLE_SIGNUP True(管理者ができると止まる) 新規登録の画面を出す
DEFAULT_USER_ROLE pending 新規登録した人のロール
ENABLE_MFA (0.12.0〜) 認証アプリでの2段階認証を全員に必須にする
WEBUI_SECRET_KEY 空 ログインの署名の鍵。固定しないと作り直しで全員ログアウト

権限はグループで足していく形です。 公式ドキュメントによれば、ユーザーの権限は「ロールの権限」と「入っているグループの権限」を合わせたものになります。「チャットを消せる」「Web 検索を使える」などの項目を全体の既定で絞り、必要な人のグループにだけ許可を足します。モデルやナレッジベースは、グループや個人ごとに公開範囲を決められます。

社内向けに公開する前に、次を確かめておくと安全です。

  • 1WEBUI_SECRET_KEY を固定したかコンテナを作り直しても同じ鍵になるようにする
  • 2新規登録を誰に許すか決めたか許すなら承認待ちのまま、管理者が1人ずつ承認する
  • 3つないだ API キーの権限は最小か公式は、管理用ではなく推論だけに使えるキーを推奨
  • 4HTTPS とリバースプロキシを設定したかWebSocket のヘッダーとバッファリングを無効にする設定が要る(エラーの節)
  • 5データのボリュームをバックアップしているか更新の前に毎回
  • 6ユーザー情報の転送を有効にしていないか外部の API に名前とメールアドレスが送られる設定

Open WebUIのAPIを使う(APIキーとcurl・Python)

この節では、Open WebUI を API として呼び、登録したモデルや RAG をプログラムから使う方法が分かります。

Open WebUI 自身も OpenAI 互換の API を持っています。 管理者が管理者パネル → 設定 → 認証で「API キー」を許可し、各ユーザーが設定 → アカウントでキーを作ります。キーは Authorization: Bearer で送ります(リバースプロキシが Authorization ヘッダーを使っている場合は x-api-key)。

道 用途
GET /api/models 使えるモデルの一覧
POST /api/chat/completions OpenAI 互換のチャット
/ollama/… Ollama の API をそのまま中継(例:/ollama/api/tags)
POST /api/v1/files/ ファイルのアップロード(RAG 用)
POST /api/v1/knowledge/{id}/file/add ナレッジベースにファイルを足す
curl -H "Authorization: Bearer YOUR_API_KEY" http://localhost:3000/api/models

curl -X POST http://localhost:3000/api/chat/completions \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "qwen3:4b", "messages": [{"role": "user", "content": "Open WebUIとは?"}]}'

OpenAI の Python SDK から呼ぶときは、base_url を /api までにします(SDK が後ろに /chat/completions を足すため)。

from openai import OpenAI

client = OpenAI(base_url="http://localhost:3000/api", api_key="YOUR_API_KEY")
r = client.chat.completions.create(
    model="qwen3:4b",
    messages=[{"role": "user", "content": "Open WebUIとは?"}],
)
print(r.choices[0].message.content)

ファイルのアップロードは裏で処理されるので、GET /api/v1/files/{id}/process/status で完了を待ってからナレッジベースに足します。 早すぎると 400 になると公式ドキュメントは説明しています。

Web検索・ツール(MCP)の設定

この節では、モデルに Web 検索や外部のツールを使わせる設定の入口が分かります。

機能 設定の場所 内容
Web 検索 管理者パネル → 設定 → ウェブ検索 SearXNG・Google PSE・Brave・Tavily・DuckDuckGo などから選び、検索結果を RAG と同じ形で渡す
URL を読む チャットで # に続けて URL ページを取り込んで質問できる
ツール ワークスペース → ツール Python で書いた Tools・Functions を足す
MCP・OpenAPI 管理者パネル → 設定 → 連携 MCP(MCPO 経由も可)や OpenAPI のツールサーバーを接続として足す

Web 検索は、オンにしただけではモデルが調べに行きません。 検索サービスを選んで API キーなどを入れ、チャットの入力欄で Web 検索を有効にしてから送ります。社内のプロキシの中で動かしているときは、HTTPS_PROXY と NO_PROXY の設定で検索だけ失敗することがあります(次の節)。

Open WebUIのよくあるエラー(接続できない・ポート・Dockerのネットワーク)

この節では、「つながらない」の原因を、エラー原文から引いて直せます。

Docker で動かしているときの「つながらない」は、ほとんどが「コンテナの中の localhost は、コンテナ自身」という1点です。

ホストで動く Ollama に、Docker の Open WebUI からつなぐとき

つながらないURL に http://localhost:11434。コンテナの中の localhost はコンテナ自身で、そこに Ollama はいない
→
つながるURL に http://host.docker.internal:11434。Linux は --add-host=host.docker.internal:host-gateway も付け、Ollama は OLLAMA_HOST=0.0.0.0

pip で動かしているなら、localhost のままでつながる

ネットワークを再現して出したエラー原文

ip netns で「ホスト(10.33.1.1)」と「コンテナ(10.33.1.2)」の2つのネットワークを作り、ホスト側で Ollama 互換の擬似サーバーを 11434 番で待たせました。コンテナ側から、Open WebUI と同じ aiohttp で /api/version を呼んだ結果です。

--- A: コンテナから http://localhost:11434(Ollama はホストで 127.0.0.1:11434)
Connection error: Cannot connect to host localhost:11434 ssl:default [Connect call failed ('127.0.0.1', 11434)]
--- B: コンテナからホストの住所 http://10.33.1.1:11434(Ollama は 127.0.0.1 だけで待つ)
Connection error: Cannot connect to host 10.33.1.1:11434 ssl:default [Connect call failed ('10.33.1.1', 11434)]
--- C: Ollama を 0.0.0.0:11434 で待たせ直して B と同じ URL
200 {"version": "0.0.0-s331"}
--- D: C のまま http://localhost:11434
Connection error: Cannot connect to host localhost:11434 ssl:default [Connect call failed ('127.0.0.1', 11434)]
--- E: ポートの書き間違い http://10.33.1.1:11435
Connection error: Cannot connect to host 10.33.1.1:11435 ssl:default [Connect call failed ('10.33.1.1', 11435)]
--- F: Compose のサービス名が引けない http://ollama:11434
Connection error: Cannot connect to host ollama:11434 ssl:default [Temporary failure in name resolution]
--- G: 届かない住所 http://10.33.2.9:11434
Connection error: Cannot connect to host 10.33.2.9:11434 ssl:default [Network is unreachable]

host.docker.internal を 10.33.1.1 に向けた curl でも、C の状態ではモデル一覧が返りました。

curl --resolve host.docker.internal:11434:10.33.1.1 http://host.docker.internal:11434/api/tags
{"models": [{"name": "qwen3:4b", "model": "qwen3:4b", "modified_at": "2026-10-22T09:00:00+09:00", ...

A と D から、Ollama の待ち方をどう変えても、コンテナの中の localhost には届かないことが分かります。 B から C への変化は、Ollama 側の OLLAMA_HOST の違いです。Open WebUI のログに出る Connection error: … は、0.12.3 の send_get_request が例外をそのまま書く形なので、上の原文と同じ形で出ます。

プロキシの環境変数の影響も確かめました。Open WebUI は aiohttp を trust_env=True で使うため、HTTP_PROXY があると Ollama への接続もプロキシに向かいます。

--- HTTP_PROXY=http://10.33.1.1:3128(プロキシは動いていない)
Connection error: Cannot connect to host 10.33.1.1:3128 ssl:default [Connect call failed ('10.33.1.1', 3128)]
--- 同じ設定に NO_PROXY=10.33.1.1 を足す
200 {"version": "0.0.0-s331"}

エラーに出ている住所が Ollama ではなくプロキシの住所なら、NO_PROXY に Ollama の住所を足します。

エラー原文と直し方の表

エラー・症状 原因 直し方
Open WebUI: Server Connection Error バックエンドから Ollama・API に届かない 下の Connection error の行をログで見て原因を分ける
Connect call failed ('127.0.0.1', 11434) Docker の中から localhost を見ている host.docker.internal:11434 か Compose のサービス名
Connect call failed ('ホストのIP', 11434) Ollama が 127.0.0.1 だけで待っている Ollama に OLLAMA_HOST=0.0.0.0
Temporary failure in name resolution host.docker.internal やサービス名が引けない Linux は --add-host=host.docker.internal:host-gateway、Compose は同じネットワークに
エラーの住所がプロキシ HTTP_PROXY が Ollama への接続にも効いている NO_PROXY に Ollama の住所を足す
/models が 401 API キーが違う・無い 接続の API キーを直す。vLLM は --api-key の値
/models が 400・401・403 だが会話はできるサービス /models を持たない・認証が違う 「モデルID」に手で足す
model '…' not found(404) モデル名が一字違う・取得していない ollama list の名前と合わせる
モデル一覧の表示が遅い 届かない接続の待ち(既定10秒)がある 不要な接続を消す、AIOHTTP_CLIENT_TIMEOUT_MODEL_LIST=3
http://localhost:3000 が開けない -p の左右の取り違え、別のアプリが 3000 番を使う -p 3001:8080 などにして開き直す
… is not an accepted origin アクセスする URL が CORS の許可にない CORS_ALLOW_ORIGIN にその URL を足す
返事が {}、## や ** が崩れる リバースプロキシが SSE をためて分け直す nginx で proxy_buffering off; と WebSocket のヘッダー
作り直したら全員ログアウト WEBUI_SECRET_KEY を固定していない 鍵を決めて毎回同じ値で起動
You can't turn off authentication because there are existing users. ユーザーがいる状態で WEBUI_AUTH=False ログインありで使う(無しは新規のときだけ)
間違った URL を保存して画面に入れない 保存した設定が環境変数より優先される RESET_CONFIG_ON_START=true で起動し直す

保存した設定は、環境変数より優先されます。 一度画面で接続を保存したあとに OLLAMA_BASE_URL を変えても反映されないのはこのためで、画面で直すか、ENABLE_PERSISTENT_CONFIG=false か RESET_CONFIG_ON_START=true を使います(公式のトラブルシューティング)。

リバースプロキシ(nginx)の後ろに置くときの、公式ドキュメントの設定です。

location / {
    proxy_pass http://your-open-webui-upstream;
    proxy_buffering off;
    proxy_cache off;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    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;
}

nginx の proxy_pass の書き方は、関連記事「Nginxリバースプロキシ設定|proxy_passの書き方と502/504対処」で扱っています。ブラウザで localhost が開けないときの切り分けは、関連記事「localhostで接続が拒否されましたの原因と解決方法」で扱っています。

つながらないときの調べ方の順番

flowchart TD
    A{Open WebUI は<br>Docker?} -->|いいえ| B[localhost<br>:11434]
    A -->|はい| C{Ollama は<br>どこ?}
    C -->|Compose| D[ollama<br>:11434]
    C -->|ホスト| E[host.docker<br>.internal:11434]
    E --> F[Ollama 側で<br>OLLAMA_HOST<br>=0.0.0.0]
# 1. ホストで Ollama が答えるか
curl http://localhost:11434/api/version
# 2. コンテナの中から届くか(標準イメージには curl が入っている)
docker exec open-webui curl -s http://host.docker.internal:11434/api/version
# 3. Open WebUI のログで原因の行を見る
docker logs open-webui 2>&1 | grep -i "connection error"

1 が答えて 2 が答えないなら、Docker のネットワークか OLLAMA_HOST の問題です。どちらも答えて画面に出ないなら、管理者パネル → 設定 → 接続の URL(保存済みの値)を確かめます。

Open WebUIとOllama・LM Studio・Difyの違い

この節では、似た名前で出てくるツールとの役割の違いが分かります。

ツール 主な役割 Open WebUI との関係
Open WebUI 複数の LLM を使うチャット画面とサーバー(RAG・ユーザー管理つき) この記事の主題
Ollama ローカルでモデルを動かす本体と API(11434番) Open WebUI の接続先
vLLM GPU でモデルを速く配る推論サーバー(OpenAI 互換) OpenAI 互換の接続先
LM Studio モデルの取得と実行・チャット画面を持つデスクトップアプリ ローカルサーバー(1234番)を接続先にできる
Dify LLM アプリやワークフローを作るプラットフォーム 作るものが違う(会話の画面か、アプリの部品か)

どれを使うかの判断表です。

やりたいこと 選ぶもの
1人で、ターミナルからモデルを試す Ollama だけ
社内の人に ChatGPT のような画面で使ってもらう Open WebUI + Ollama か vLLM
同時に多くの人が使い、速さが要る Open WebUI + vLLM
外部の API とローカルのモデルを1つの画面で使い分ける Open WebUI(接続を複数登録)
手順の決まった処理を LLM で自動化するアプリを作る Dify などのワークフローのツール

よくある質問

Q. Open WebUIとは何ですか?読み方は? A. 「オープン・ウェブ・ユーアイ」と読みます。Ollama や OpenAI 互換の API につないで、ChatGPT のような画面で LLM を使えるようにする、自分で動かす Web アプリです。RAG・Web 検索・ユーザー管理も入っています。

Q. Open WebUIは無料ですか?商用利用はできますか? A. 無料で、商用・社内で使えます。2026年10月22日時点のライセンス(Open WebUI License)では、「Open WebUI」の名前やロゴを変えたり消したりできるのは、30日間の利用者が50人以下の場合などに限られます。

Q. Open WebUIのインストールはDockerとpipのどちらがよいですか? A. 公式は Docker を推奨しています。Python で入れる場合は 3.11 か 3.12 の環境が要り、DATA_DIR を指定しないとデータが Python の環境の中に置かれます。Ollama も一緒に動かすなら :ollama タグか Docker Compose が手軽です。

Q. Open WebUIからOllamaに接続できないのはなぜですか? A. Docker の中から localhost:11434 を見ていることが多い原因です。URL を http://host.docker.internal:11434 にし、Linux では --add-host=host.docker.internal:host-gateway を付け、Ollama 側は OLLAMA_HOST=0.0.0.0 にします。原因ごとのエラー原文は「よくあるエラー」の節にあります。

Q. Open WebUIを日本語化するには? A. 右上のアイコン → 設定 → 一般 → 言語で「日本語」を選びます。翻訳されていない項目は英語のまま表示されます。

Q. Open WebUIのポートを変えるには? A. Docker では -p 3001:8080 のように左の数字を変えます。pip・uv では open-webui serve --port 3000 です。コンテナの中の 8080 は変えません。

Q. Open WebUIでvLLMを使うには? A. 管理者パネル → 設定 → 接続の OpenAI API接続に、http://host.docker.internal:8000/v1 のように /v1 まで含めた URL と、vLLM の --api-key の値を登録します。

Q. Open WebUIのRAGで日本語の文書がうまく検索されません。 A. 既定の埋め込みモデル(all-MiniLM-L6-v2)は英語向けです。多言語の埋め込みモデルに変えて再インデックスし、Ollama のコンテキスト長(num_ctx)を 8192 以上に上げると改善することがあります。

Q. Open WebUIのデータはどこに保存されますか? A. Docker では /app/backend/data(-v open-webui:/app/backend/data のボリューム)、pip・uv では DATA_DIR の場所です。会話・ユーザー・設定・取り込んだ文書が入るので、更新の前にバックアップを取ります。

Q. Open WebUIをAPIから使えますか? A. 使えます。設定 → アカウントで API キーを作り、http://localhost:3000/api/chat/completions に Authorization: Bearer で送ります。OpenAI の SDK なら base_url="http://localhost:3000/api" です。

Q. 新しく登録したユーザーが使えません。 A. 既定では新しいユーザーは「承認待ち」になります。管理者パネル → ユーザーでロールを user に変えるか、DEFAULT_USER_ROLE を変えます。

まとめ

  • Open WebUI は、Ollama や OpenAI 互換 API につないで使う、自分で動かすチャット画面とサーバー。無料で、50人を超えるなら名前・ロゴは変えない。
  • いちばん早い入れ方は Docker(localhost:3000)。WEBUI_SECRET_KEY を固定し、-v open-webui:/app/backend/data を毎回付ける。pip・uv は Python 3.11・3.12 と DATA_DIR。
  • 接続の URL は「Open WebUI のサーバーから見た住所」。Docker からホストの Ollama は host.docker.internal:11434、Compose なら ollama:11434。Ollama 側は OLLAMA_HOST=0.0.0.0。
  • チャットは Ollama の /api/chat に、max_tokens は options.num_predict に直されて届く。OpenAI 互換は登録した URL+/chat/completions に Bearer つきで届く。
  • RAG の既定は チャンク 1000・重なり 100・トップ K 3・英語向けの埋め込みモデル。埋め込みを変えたら再インデックス。
  • 新規登録の人は承認待ち。権限はロールとグループを足し合わせて決まる。

参考・出典

確認日はいずれも 2026年10月22日です。

  • Open WebUI ドキュメント「Quick Start」:https://docs.openwebui.com/getting-started/quick-start/
  • Open WebUI ドキュメント「Starting with Ollama」:https://docs.openwebui.com/getting-started/quick-start/connect-a-provider/starting-with-ollama
  • Open WebUI ドキュメント「Starting with OpenAI-Compatible Servers」:https://docs.openwebui.com/getting-started/quick-start/connect-a-provider/starting-with-openai-compatible
  • Open WebUI ドキュメント「Connection Errors」:https://docs.openwebui.com/troubleshooting/connection-error/
  • Open WebUI ドキュメント「Retrieval Augmented Generation (RAG)」:https://docs.openwebui.com/features/chat-conversations/rag/
  • Open WebUI ドキュメント「Role-Based Access Control」:https://docs.openwebui.com/features/authentication-access/rbac/
  • Open WebUI ドキュメント「API Endpoints」:https://docs.openwebui.com/reference/api-endpoints
  • Open WebUI ドキュメント「License」:https://docs.openwebui.com/license
  • Ollama ドキュメント「FAQ」(OLLAMA_HOST・既定のコンテキスト長):https://docs.ollama.com/faq
  • GitHub「open-webui/open-webui」(README・LICENSE・CHANGELOG・TROUBLESHOOTING.md):https://github.com/open-webui/open-webui
  • PyPI「open-webui 0.12.3」(ソース一式):https://pypi.org/project/open-webui/
  • issoh「Open WebUI(v0.12.0)導入ガイド」:https://www.issoh.co.jp/tech/details/4607
  • Apidog「Open WebUIとOllamaの使い方」:https://apidog.com/jp/blog/open-webui-ollama/
  • Zenn「DockerでOllama × Open WebUI を最小構成で起動し、ローカルLLMを試す」:https://zenn.dev/kondonator/articles/445d7906ca6c53

本記事の内容は、ご自由にお使いください。
ご利用の際は、出典として本ページへのリンクを記載いただけますようお願いします。

(記載例)出典:株式会社RJC「Open WebUIとは|インストール・使い方・Ollama接続とRAG設定」

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。

WE ARE HIRING

RJCで一緒に開発しながら、
成長を楽しみませんか?

RJCは、Web・モバイル・AIを活用した開発プロジェクトで、テックリードやPM・PMOも活躍するシステム開発会社です。会社を知る、待遇を確かめる、話を聞いてみる。気になるところ見てみてください!

  • 127日年間休日
  • 12時間平均残業時間
  • 毎日ガチャ遊びココロも大切にする福利厚生。アマギフなどの賞品ラインナップ!

ほかにも、チケットレストラン、書籍読み放題、2年ごとの慰労報奨(休暇 or 金一封)、11期連続の黒字決算。

ABOUT RJC RJCがどんな会社か知る 考え方、研修、働き方、福利厚生、社員の前職まで。RJCのことが丸わかり! RJC丸わかりページへ JOB DESCRIPTION 仕事内容・待遇を見てみる 仕事内容、給与・待遇、選考の流れ。経験者も未経験も!応募前に知りたいこと、まとめました! 募集要項を見る ENTRY エントリーする エントリーは1〜2分・履歴書不要です。まずは話を聞いてみたい、という方でも歓迎です! エントリーフォームへ

RJCで一緒に開発しながら、 成長を楽しみませんか?