物事がヒットするのとは成功体験が得られるかどうかが重要かもしれない。CD-ROMドライブが普及したのは、男性の欲望を誰もが共感するコンテンツのタイトルがリリースされたからという都市伝説があるが。。。その時代は正しくパソコン少年だったが、周りでそんな話はなかった。不思議と。大学が大学だったからかもしれないが。
仕事上では、POCまで進めば受注までいくことが多く、当時のボスに、「どうしてそうなの」と聞かれたのだが、答えは単純で、手元でまず自分がPOCをやって、お客さんはその後をなぞっているだけなので、失敗する確率がめちゃくちゃ少ない。要は出来ゲームだった。
なので、デモは見せる成功体験なので、見栄え、パフォーマンスがめちゃくちゃ重要。動きますと言ってモタモタしていたらお客さんは買ってくれない。それくらい、最初の出会いは大事だったりする。
で、もし、POCがそれでもうまくいかない場合はどうするの？それは、自宅のラボで検証してもらっていた。
いずれにせよ、「まずはPOCしましょう」は、それは「試してガッテン」ではない。
閑話休題
Open WebUI + Ollama の導入記事では、よく以下のような最小構成が紹介されている。（これは動かさない前提なので適当に書いてある。）
cat << ‘EOF’ > compose.yml
services:
ollama:
image: ollama/ollama:latest
container_name: ollama
restart: unless-stopped
volumes:
– ollama:/root/.ollama
ports:
– “11434:11434”
open-webui:
image: ghcr.io/open-webui/open-webui:main
container_name: open-webui
restart: unless-stopped
depends_on:
– ollama
ports:
– “3000:8080”
volumes:
– open-webui:/app/backend/data
environment:
OLLAMA_BASE_URL: http://ollama:11434
volumes:
ollama:
open-webui:
EOF
起動はこれだけ
docker compose up -d
docker exec ollama ollama pull <好きなモデル>
ブラウザで以下にアクセスします。
http://<DockerホストのIPアドレス>:3000
確かにこれで Open WebUI + Ollama は問題なく動く。しかし、この構成はあくまで「起動するだけ」。 この状態だとモデル選択がガチャ状態になりやすい。とりあえず大きなモデルを選んでみる、動かなければ小さなモデルにする、といったウィンドウショッピング的な試行錯誤を繰り返すことになる。その結果、VRAM不足や品質不足に悩まされ、「Open WebUIは使いにくい」という印象を持ってしまいがちである。大きすぎるモデルを選ぶとVRAMやRAMが不足し、小さすぎるモデルを選ぶと品質やツール利用が不安定になる。さらにOpen WebUI の便利な機能を使っても、動作が安定しないことがある。
なぜか？
-
ユーザのチャットAIへの問い合わせの仕方が自然と、検索エンジンの延長の質問から、もう少し複雑な依頼に変化してきている。
以前の質問
Google検索の代わりに近い質問：
「京都のおすすめ観光地を教えて」
今の質問
だいぶAIになれた人の質問：
-
8月に女友達2人で京都旅行します。
-
予算3万円。
-
インスタ映え重視です。
-
ホテル候補を探し、天気予報を確認し、予約サイトのURLも付けて、旅行計画書を作ってください。
このように、単なる『質問』から『依頼』へ変わってきている。つまりユーザは既にAgent AI時代の質問をしている。しかし、多くのOpen WebUI環境は、まだチャットボット時代の設定のままである。
-
Open WebUIは既に別物になっている
Open WebUIは当初、Ollamaのフロントエンドとして使われることが多かった。しかし、Web Search、Knowledge(RAG)、Tools、MCPなどの機能が追加され、現在では単なるチャットUIというよりAgent AIプラットフォームに近い存在になっている。従来のモードとAgent AIのモードの２つがあり、今のユーザは、もはや初期のLLMチャットでの質問はあまりせず、Agent AIに頼むような質問をしてくる。従来のモードで、今風の質問をしても、期待するような動きはしない。あくまでも質問者の質問の仕方とOpen WebUIのモードを合わせてあげる必要がある。つまり、うまく動かないなぁと思っている状態は、双方の期待値の相違がずれているに過ぎない。
少し設定を足すだけでかなり使いやすくなる compose.yml
最低限このくらいは最初から入れる。OLLAMA_CONTEXT_LENGTHは、VRAMが16GBあるいは、UMA:32GBであれば “65536”にしてもいいかも。
cat << ‘EOF’ > compose.yml
services:
ollama:
image: ollama/ollama:latest
container_name: ollama
restart: unless-stopped
ports:
– “11434:11434”
volumes:
– ./ollama:/root/.ollama
environment:
TZ: Asia/Tokyo
OLLAMA_HOST: 0.0.0.0:11434
OLLAMA_CONTEXT_LENGTH: “32768”
OLLAMA_KEEP_ALIVE: “1h”
OLLAMA_NUM_PARALLEL: “1”
OLLAMA_MAX_LOADED_MODELS: “2”
gpus: all
open-webui:
image: ghcr.io/open-webui/open-webui:main
container_name: open-webui
restart: unless-stopped
depends_on:
– ollama
ports:
– “3000:8080”
volumes:
– ./open-webui:/app/backend/data
environment:
TZ: Asia/Tokyo
USER_AGENT: OpenWebUI-Ollama-Lab/1.0
WEBUI_SECRET_KEY: “PLEASE_CHANGE_ME_TO_64_HEX_CHARS_GENERATED_BY_OPENSSL_RAND_32HEX” # openssl rand -hex 32
OLLAMA_BASE_URL: http://ollama:11434
DEFAULT_MODELS: qwen3.5:9b
TASK_MODEL: qwen2.5:0.5b
RAG_EMBEDDING_ENGINE: ollama
RAG_EMBEDDING_MODEL: nomic-embed-text
DEFAULT_MODEL_METADATA: >
{
“capabilities”: {
“file_context”: true,
“vision”: false,
“file_upload”: true,
“web_search”: true,
“image_generation”: false,
“code_interpreter”: false,
“terminal”: false,
“citations”: true,
“status_updates”: true,
“builtin_tools”: true,
“usage”: true
}
}
DEFAULT_MODEL_PARAMS: >
{
“stream_response”: true,
“function_calling”: “native”,
“think”: false,
“reasoning_tags”: false
}
EOF
モデル取得
実は、モデル選びはかなり重要で、日本語を扱うなら、Qwen系はかなり使いやすい。また、9Bクラスになると、ローカルLLMとしての実用感がかなり出る。9Bクラスでも比較的軽量であり、32K程度であれば16GB VRAM環境でも実用的に動作する。なので、Qwenのモデルは高性能な割に、お財布にもVRAMにも優しい。
docker compose up -d
docker exec ollama ollama pull qwen3.5:9b
docker exec ollama ollama pull qwen2.5:0.5b
docker exec ollama ollama pull nomic-embed-text
この構成では、役割を以下のように分ける。実質チャットで使うモデルは、
qwen3.5:9bのみ。|
用途
|
モデル
|
|---|---|
|
通常Chat / Agent的な利用
|
qwen3.5:9b |
|
タイトル生成 / タグ / 分類などの内部処理
|
qwen2.5:0.5b |
|
RAG用Embedding
|
nomic-embed-text |
この設定で何が変わるか
重要なのはこの5つ。
DEFAULT_MODELS: qwen3.5:9b
TASK_MODEL: qwen2.5:0.5b
RAG_EMBEDDING_ENGINE: ollama
RAG_EMBEDDING_MODEL: nomic-embed-text
DEFAULT_MODEL_PARAMS: >
{
“stream_response”: true,
“function_calling”: “native”,
“think”: false,
“reasoning_tags”: false
}
DEFAULT_MODELS ：最初から実用的なモデルを使える。マシンスペックに応じて大きくしてもいい。TASK_MODEL ：Open WebUIはチャット以外にも、タイトル生成、タグ生成、検索キーワード生成など様々な裏方処理を行っている。これらに毎回9Bモデルを使う必要はない。RAG_EMBEDDING_MODEL ：Knowledge / RAG を使う準備ができる。そして一番効くのが、
{
“stream_response”: true,
“function_calling”: “native”,
“think”: false,
“reasoning_tags”: false
}
これにより、Open WebUI のツール利用を Native Function Calling 前提になり、最初は面白いかもしれないが、多くの利用者は「早く答えて欲しい」ので最終的にはThinkingは邪魔になる。この設定は、Thinkingを要求しなくなり、だいぶ扱いやすくなる。
function_calling を native にしておかないと、従来方式の Tool Calling （レガシーモード）が利用される。現在の Open WebUI は Native Function Calling を中心に機能追加が進んでいるため、Native を利用することを推奨する。（現時点では、OpenWebUIのデフォルトがレガシーモード）
Thinkingは、本当に深く考えてもらいたいリサーチやログの確認ではオンにすべきだが、ほとんどの用途では、入れなくてもいい。これは、今のモデルがだいぶ賢くなったので、Thinkingを入れなくてもかなりまともな回答が返ってくるかからである。
もしもうすでに起動している環境をもっているならば、以下の設定をすると同等の効果が得られる。
Admin Panel -＞Settings->Models 右上のSettings
Model Parametersを開く
以下のように設定して、Saveをクリック
まとめ
Open WebUI + Ollama は、最小 compose.yml だけでも起動する。しかし、それは「動く」だけ。
モデルの選択を正しく行い
qwen3.5:9b
qwen2.5:0.5b
nomic-embed-text
最低限のモデルの設定
DEFAULT_MODELS
TASK_MODEL
RAG_EMBEDDING_MODEL
DEFAULT_MODEL_METADATA
DEFAULT_MODEL_PARAMS
をしておく。
実際には DEFAULT_MODELS や TASK_MODEL よりも、DEFAULT_MODEL_PARAMS の function_calling=native などのパラメータの設定の方が影響が大きい。これを設定することで Open WebUI は単なるチャットUIではなく、Tool Calling を前提とした Agent 的な動作をしやすくなる。
Open WebUIが使いにくいのではない。成功体験を得られる初期設定になっていないだけである。
Open WebUI + Ollama は導入よりも初期設定の方が重要である。
Docker Composeで起動するだけなら5分で終わる。
しかし、最初の成功体験を作れるかどうかはその後の数行の設定で決まる。
CD-ROMもそうだった。
POCもそうだった。
そしてOpen WebUIも同じである。