物事がヒットするのとは成功体験が得られるかどうかが重要かもしれない。CD-ROMドライブが普及したのは、男性の欲望を誰もが共感するコンテンツのタイトルがリリースされたからという都市伝説があるが。。。その時代は正しくパソコン少年だったが、周りでそんな話はなかった。不思議と。大学が大学だったからかもしれないが。
仕事上では、POCまで進めば受注までいくことが多く、当時のボスに、「どうしてそうなの」と聞かれたのだが、答えは単純で、手元でまず自分が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も付けて、旅行計画書を作ってください。
-
実際の天気予報や予約サイトの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のモードを合わせてあげる必要がある。つまり、うまく動かないなぁと思っている状態は、双方の期待値の相違がずれているに過ぎない。
Agent AIを有効にすると
正しく日程表を提案してくれる。
同じgpt-oss:20bでもかなり化ける。
少し設定を足すだけでかなり使いやすくなる compose.yml
最低限このくらいは最初から入れる。OLLAMA_CONTEXT_LENGTHは、VRAMが16GBあるいは、UMA:32GBであれば “65536”にしてもいいかも。
なお、構築済みの環境やOpen WebUI Desktopの場合は、後半に記載してあるGUI設定で同等のことが可能。
以下、NVIDIA環境の設定例。
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:latest
ENABLE_WEB_SEARCH: “true”
WEB_SEARCH_ENGINE: “duckduckgo”
DDGS_BACKEND: “auto”
YOUTUBE_LOADER_LANGUAGE: “ja,en”
WHISPER_LANGUAGE: ja
AUDIO_TTS_VOICE: Default
AUDIO_TTS_VOICE: Default
DEFAULT_MODEL_METADATA: >
{
“capabilities”: {
“file_context”: true,
“vision”: true,
“file_upload”: true,
“web_search”: true,
“image_generation”: false,
“code_interpreter”: true,
“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
その他GPU環境の場合は、 gpus: all を書き換える。
モデル取得
実は、モデル選びはかなり重要で、日本語を扱うなら、Qwen系はかなり使いやすい。また、9Bクラスになると、ローカルLLMとしての実用感がかなり出る。9Bクラスでも比較的軽量であり、32K程度であれば16GB VRAM環境でも実用的に動作する。なので、Qwenのモデルは高性能な割に、お財布にもVRAMにも優しい。
VRAM/UMAが64GB以上あるのであれば、qwen3.5:9bの代わりにqwen3.6:35b-a3bにしてもよい。
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:latest |
GPUのメモリの利用量は以下
root@gx10-e3f4:~# docker exec ollama ollama ps
NAME ID SIZE PROCESSOR CONTEXT UNTIL
qwen2.5:0.5b a8b0c5157701 1.8 GB 100% GPU 32768 59 minutes from now
qwen3.5:9b 6488c96fa5fa 9.9 GB 100% GPU 32768 57 minutes from now
root@gx10-e3f4:~# docker exec ollama ollama ps
NAME ID SIZE PROCESSOR CONTEXT UNTIL
nomic-embed-text:latest 0a109f422b47 595 MB 100% GPU 2048 59 minutes from now
トータルで12GB程度
この設定で何が変わるか
重要なのはこの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を入れなくてもかなりまともな回答が返ってくるかからである。
この環境でサポートされる機能
この環境は、単体のOpen WebUI環境なので、全ての機能は使えなく、使えたとしても品質が落ちるケースもあるが、実は、Open WebUIでできる機能は、単純なLLMチャット以外にも以下の機能をサポートしている。単純なLLMチャットの使い方と比較してもかなり豊富な機能がデフォルトで使えるようになっている。
モデルに依存する機能
Qwen 3.5はでサポートされている機能でOpen WebUIで使えるものを全て有効にした。
ただし、Web検索は単純に動くようにしただけなので、安定しないかもしれない。
|
Capability
|
機能
|
テストプロンプト
|
期待結果
|
|---|---|---|---|
|
file_upload
|
ファイル添付
|
PDFを添付して「要約してください」
|
ファイルを受理する
|
|
file_context
|
添付ファイルを文脈利用
|
PDF添付後「この文書の結論を教えて」
|
文書内容を参照して回答
|
|
vision
|
画像理解
|
スクショ添付して「内容を説明してください」
|
画像解析
|
|
web_search
|
Web検索
|
「Open WebUI最新版を調べて」
|
Searching Web表示
|
|
code_interpreter
|
Python実行
|
「Pythonで素数を求めて」
|
Python実行
|
有効にするにはチャット入力時に以下のトグルで有効にする必要がある。
これ以外にもMCPを登録すれば、MCPの機能も使えるようにできる。
RAG検索
Workspaceを開き、Knowlege Baseを作成して、ファイルを登録をしておく。検索文字列に # をつけて参照したいファイルやWorkspaceを選択して、その後にプロンプトを入力する。
ただし、単体Open WebUI環境なので、PPTや画像の文字認識はできず、認識していたとしても精度は良くないかもしれない。
また、このRAG検索は、ファイルをインポートして、Open WebUIにコピーしているので、今のNASについているような、ファイルサーバでのRAG検索のような使い方はできないので注意。
Agent AI的な機能
現在時刻の確認：
単純なLLMチャットでは現在時刻では答えられないが、答えることが可能。
カレンダー登録：
「6/1 18:00に新宿で友人に会う。カレンダーに登録しておいて」のような入力をするとカレンダー登録をしてくれて、時間が近づくと通知をしてくれる。ただし、Googleカレンダーのようなカレンダーとの連携はできず、あくまでもOpen WebUIのカレンダーへの登録となる。
ノート作成：
「以下の内容をノートに保存して
Open WebUIのRAG検証メモ
・Knowledge確認
・Embedding確認
・Citation確認
と入力するとノートに保存してくれる。このプロンプトの出力は積極的にノートに保存される。
まとめ
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も同じである。
（参考）すでに構築済み環境・Open WebUI Desktop環境の場合
以下の設定をするとcompose.ymlでの設定と同等の効果が得られる。
Admin Panel -> Settingsで設定を変更する。
Models
右上のSettings
Model ParametersとModel Capabilitiesを設定
Model Capabilities
以下のように設定して、Saveをクリックして保存。
CapabilitiesのImage CreationとTerminal以外を全てオンにする。Builtin Toolsは、全てオンで構わない。
Model Parameters
以下のように設定して、Saveをクリックして保存。
Documents
RAG向けのEmbedding Modelを入力する。Saveをクリックして保存。
Web Search
Web Searchを有効にして、Web Search EngineをDDGSにし、DGGS BackendをAutoにする。
Web Search系は、別コンテナで担当させたり、APIキーをいれてサービスを使わないと高品質なソースが得られない場合がある。
Saveをクリックして保存。
Interface
Local Task Modelを指定する。Saveをクリックして保存。
Audio
音声読み上げの設定。Saveをクリックして保存。
このボタンを押すと読み上げてくれるが、OSによっては英語でしか読み上げてくれない場合がある。
音声入力自体は可能だが、ブラウザの制限で、Open WebUIへアクセスするURLがhttps:// あるいは、http://localhostではないと有効にならない。