10分でローカルChatGPT構築: Open WebUI + Ollama (2026年版)
もしあなたが「ChatGPTがOpenAIのサーバーではなく、自分のラップトップ上で動けばいいのに」と考えたことがあるなら、Open WebUI + Ollamaこそが求めているスタックです。Open WebUIは洗練されたチャットインターフェースを提供し、Ollamaはモデルをローカルで実行します。APIキー不要、トークン単位の課金なし、データがマシン外に出ることもありません。このガイドでは、ターミナルを開いてから最初のチャットを行うまでを約10分で完了させ、その後に多くのチュートリアルが省略しがちな要素（音声入出力、Pipelines、MCP、Apple Siliconのベンチマーク、Caddyを使ったクリーンなHTTPS経路）を追加していきます。
主なポイント:
- Open WebUIはセルフホスト型のChatGPT風フロントエンドであり、Ollamaはそれを動かすローカルモデルランナーです。
- 単一コンテナのDocker構成であれば、準備済みのマシンで約10分で最初のチャットが可能です。
- 「接続できない」エラーの9割は、
OLLAMA_BASE_URLをhttp://host.docker.internal:11434に設定することで解決します。- Open WebUIの真価は、Pipelines/Functions、ネイティブRAG、音声入出力、MCPにあります。これらはLM Studioでは実現できません。
Open WebUI + Ollamaとは何か？
Open WebUIは、Ollama（および他のローカルLLMランタイム）にChatGPT風のチャットUIを提供するオープンソースのセルフホスト型Webインターフェースです。これらを組み合わせることで、APIキー不要、トークン単位のコストなし、完全なデータ管理権限を持ったプライベートAIモデルを自分のマシンで実行できます。Open WebUIはチャット層、Ollamaはモデル層を担当します。両者はポート11434でHTTP通信を行い、これがアーキテクチャのすべてです。
名前が似ているため混同されがちですが、それぞれの役割を分解してみましょう。
- Open WebUI: 実際に使用するブラウザアプリ。マルチユーザー対応、RAG組み込み、プラグインシステムを搭載。Docker内ではポート8080で動作します（ホスト側では3000にマップします）。
- Ollama: モデルサーバー。GGUFファイル（AIモデルにおける
.mp3のようなもの）を取得し、CPU/GPUに読み込んで、ポート11434で整理されたHTTP APIを公開します。 - Models: 実際の重みファイル。
llama3.2:3b、qwen2.5:14b、deepseek-r1:7bなど。ollama pullで取得でき、Ollamaのモデルライブラリに一覧があります。
この組み合わせが優れている理由：プライバシー（データはローカルに残る）、コスト（トークン単位の費用ゼロ）、オフライン対応、標準でのマルチユーザーサポート、そして本格的なプラグインエコシステムです。この分野の初心者であれば、ハードウェア面についてはローカルでLLMを実行するガイドをご覧ください。
公式のOpen WebUIドキュメントは標準的な参照先ですので、ブックマークしておきましょう。簡潔ですが、正確です。
Open WebUIをOllamaと一緒にインストールするには？（クイックセットアップ）
DockerとOllamaをインストールし、その後 docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data --name open-webui ghcr.io/open-webui/open-webui:main を実行します。http://localhost:3000 にアクセスし、管理者アカウントを作成し、Admin → Settings → Connections → Ollama からモデルを取得して、チャットを開始します。所要時間：準備済みのマシンで約10分です。
以下に全手順をステップバイステップで示します。
1. Docker Desktopをインストールする。Mac/Windowsの場合はdocker.comから入手するか、Linuxの場合は apt install docker.io を実行します。
2. Ollamaをインストールする
# macOS / Linux
curl -fsSL https://ollama.com/install.sh | sh
# Windows: download installer from ollama.com3. スターターモデルを取得する。ほぼすべての環境で高速に動作し、有用さを感じるには llama3.2:3b から始めるのがおすすめです。最強のオプション一覧を確認したい場合は、ベストなオープンソースLLMリストをご覧ください。
ollama pull llama3.2:3b4. Open WebUIコンテナを実行する（標準コマンド）:
docker run -d \
-p 3000:8080 \
--add-host=host.docker.internal:host-gateway \
-v open-webui:/app/backend/data \
--name open-webui \
--restart always \
ghcr.io/open-webui/open-webui:main5. http://localhost:3000 を開く。サインアップします（最初のユーザーが自動的に管理者になります）。これでチャットが可能になります。
プロのヒント: Apple Silicon Macでは、OllamaをDocker内ではなくネイティブに実行してください。これは設計によるもので、OllamaがMetal GPUを使用できるようにするためです。Open WebUIはDocker内で実行され、両者は
host.docker.internal:11434を介して通信します。
「10分」という約束について：これは、Dockerがすでにインストールされており、約2GBのイメージ取得と約2GBのモデル取得のために十分なインターネット速度がある「ウォームスタート」時の数値です。キャッシュのない状態で初めてのDockerインストールを行う場合、さらに10分追加してください。接続が遅い場合は、さらに5分追加します。マーケティング用の数字ではなく、正直な基準値です。
Docker Compose: プロダクションレディなセットアップ
Open WebUI と自立型の Ollama サービスを組み合わせた、再現性のあるマルチコンテナ構成が必要な場合、Docker Compose がよりクリーンな選択肢です。1つのYAMLファイルで両方のサービス、共有ネットワーク、永続化のための名前付きボリュームを宣言し、単一の docker compose up -d で再デプロイできます。サーバー、ホームラボ、またはチームでの利用に最適です。
人がハマりやすいポイントは、両方のサービスをCompose内で実行する場合、OLLAMA_BASE_URL=http://ollama:11434（Composeサービス名）を設定することです。host.docker.internal ではありません。Dockerの内部DNSがサービス名を自動的に解決します。
services:
ollama:
image: ollama/ollama:latest
container_name: ollama
ports:
- "11434:11434"
volumes:
- ollama:/root/.ollama
restart: always
open-webui:
image: ghcr.io/open-webui/open-webui:main
container_name: open-webui
ports:
- "3000:8080"
environment:
- OLLAMA_BASE_URL=http://ollama:11434
volumes:
- open-webui:/app/backend/data
depends_on:
- ollama
restart: always
volumes:
ollama:
open-webui:起動します:
docker compose up -d
docker compose logs -f強調すべき2点があります。第一に、ここではバインドマウントよりも名前付きボリューム（下部の ollama: および open-webui:）の方が優れており、Dockerが権限を管理し、チャット履歴や設定がコンテナの再構築後も生存します。第二に、1つのOpen WebUIからローカルのOllamaおよびリモートのOpenAI/Anthropicに単一のURL経由でアクセスしたい場合は、前に LiteLLMプロキシ を配置します。ランタイム層の選定中であれば、ベストなローカルLLMツール のまとめ記事でOllama、vLLM、LM Studioなどを比較しています。
GPUアクセラレーション: NVIDIA、AMD、およびApple Silicon
Ollama は、NVIDIA Container Toolkit経由でNVIDIA GPUを、Linux上のROCm経由でAMD GPUを、Metal経由でApple Silicon GPUをネイティブに自動検出します。Open WebUIに --gpus all を渡す必要はありません。GPUが必要なのはOllamaのみです。各プラットフォームでの最速セットアップは異なり、「なぜこんなに遅いのか」という問題の多くは、Ollamaを間違った場所で実行していることに起因します。
NVIDIA (Linux + Windows WSL2)
NVIDIA Container Toolkit をインストールし、その後 --gpus all を付けてDockerでOllamaを実行します。
docker run -d --gpus=all \
-v ollama:/root/.ollama \
-p 11434:11434 \
--name ollama \
ollama/ollamaモデルが読み込まれている間に nvidia-smi で確認すると、GPUプロセスリストに ollama が表示されるはずです。OLLAMA_NUM_GPU 環境変数を使用すると、他のワークロードとVRAMを共有している場合にレイヤー数を制限できます。
Apple Silicon (M1/M2/M3/M4)
Ollamaはネイティブに実行し、Docker内では実行しないでください。2026年初頭現在、DockerへのMetal GPUパススルーはまだ存在しないため、Mac上のDocker化されたOllamaはCPUにフォールバックし、M3 Maxが2015年のThinkPadのように感じられる原因となります。Open WebUIは引き続きDocker内で実行され、host.docker.internal:11434 を介してOllamaに到達します。
16 GB RAMのM2 Proで llama3.2:3b を実行した場合、およそ45-55 tokens/sec です。llama3.1:8b は ~22-28 tokens/sec に低下します。qwen2.5:14b は ~9-12 tokens/sec でギリギリ実用範囲内であり、チャットには問題ありませんが、バッチ処理には苦痛を伴います。数値は量子化とコンテキスト長によって異なりますが、オーダーとしてはこのようなものです。
"Tokens/sec by Model and Hardware"
データテーブル
| "Model" | "Apple M2 Pro 16GB" | "RTX 3060 12GB" | "RTX 4090 24GB" |
|---|---|---|---|
| "llama3.2:3b" | 50 | 75 | 180 |
| "llama3.1:8b" | 25 | 45 | 110 |
| "qwen2.5:14b" | 11 | 22 | 65 |
AMD (Linux上のROCm)
Ollama 0.5+ は、RDNA2/RDNA3カード（RX 6000/7000シリーズ、MI200/MI300データセンターチップ）向けのROCmサポートを提供しています。専用のイメージを使用します。
docker run -d --device=/dev/kfd --device=/dev/dri \
-v ollama:/root/.ollama \
-p 11434:11434 \
--name ollama \
ollama/ollama:rocmAMDのパフォーマンスは2025年を通じて意味のある差を縮めてきました。まだNVIDIA級ではありませんが、もはや科学実験の域を出ています。
Open WebUIにRAG（独自のPDF）を追加するには？
Open WebUI にはネイティブRAG機能が搭載されています。プロフィール → Workspace → Knowledge をクリックし、ナレッジベースを作成して、PDF、Wordドキュメント、Markdown、またはテキストファイルをドロップします。背後では、Open WebUIがドキュメントをチャンク分割し、設定された埋め込みモデル（デフォルトは nomic-embed-text）でベクトル化し、ChromaDB に保存して、クエリ時に検索します。外部サービスは不要です。
セットアップには追加の手順が1つ必要です。まず埋め込みモデルを取得します。
ollama pull nomic-embed-textその後、Admin → Settings → Documents で、埋め込みモデルを nomic-embed-text に設定します。チャンクサイズ（デフォルト1500）とオーバーラップ（デフォルト100）は好みに合わせて調整します。典型的な落とし穴は、小さなモデルでコンテキストウィンドウを超えてしまうほど大きなチャンクを使用することです。4Kコンテキストの llama3.2:3b を実行している場合、1500トークンのチャンクでは実際の質問に対する余地がほとんど残らないため、オーバーラップ80でチャンクサイズを800に下げます。
チャットでナレッジベースを使用するには、# と入力してコレクションを選択します。または、Workspace → Models でカスタムモデルに永続的にアタッチします。Web検索も同様に機能し、Admin → Settings → Web Search でプロバイダー（SearXNG、Brave、またはTavily）を有効にすると、モデルがライブ結果を取得できます。
RAGの深い比較については、RAGツール のまとめ記事をご覧ください。また、大規模スケールでChromaDBでは不十分な場合は、ベクターデータベースのオプション の解説記事でQdrant、pgvector、およびトレードオフについて説明しています。
音声入出力: ローカルAIと会話する
Open WebUI は、音声認識（STT）と音声合成（TTS）の両方をサポートしています。STTには、APIキー不要でローカル実行可能な faster-whisper を使用します。TTSには、OpenAIのTTS APIを接続するか、coqui-tts のようなローカルエンジンを実行できます。有効にすると、チャットボックスにマイクアイコンが表示され、ローカルAIが音声で応答します。
Admin → Settings → Audio に移動します。2つのエンジン、2つのドロップダウンメニューがあります。
STTパス: Whisper (Local) を選択し、モデルサイズ（tiny、base、small、medium、または large）を選びます。モデルは初回使用時に自動ダウンロードされます。ほとんどのラップトップには base が適しており、GPUに余力があれば medium を選択します。
TTSパス: 最も簡単なのはOpenAI TTSです。APIキーを貼り付け、tts-1 と音声（alloy、novaなど）を選択します。完全ローカルパスの場合、別のDockerイメージを使用した coqui-tts エンジンを利用します。多くの人は、実用的な中間策としてローカルWhisper + OpenAI TTSを採用しており、入力音声はボックス外に出ず、出力は短いテキスト文字列のAPI呼び出しのみとなります。
この選択は環境変数を使用してコンテナに組み込むことができます。
docker run -d \
-e WHISPER_MODEL=base \
-e AUDIO_STT_ENGINE=whisper \
-p 3000:8080 \
--add-host=host.docker.internal:host-gateway \
-v open-webui:/app/backend/data \
--name open-webui \
ghcr.io/open-webui/open-webui:main完全なオーディオリファレンスは Open WebUI GitHub ドキュメントにあります。
Pipelines & Functions: Open WebUIのキラー機能
Pipelines と Functions は、フォークせずにOpen WebUIを拡張する方法です。Pipelinesは、フィルター、モデルルーター、または完全なカスタムハンドラーとして機能する外部Pythonサービスです。Functionsは、Open WebUI自体内に存在するインラインPython（Filter、Action、またはPipe）です。これらが組み合わさることで、真剣なユーザーにとってOpen WebUIがLM Studioを上回る理由となっています。
3種類のFunctionタイプをそれぞれ一文で説明します。
- Filter: メッセージの前後処理を行います（個人情報マスキング、汚染語フィルタリング、プロンプト書き換え）。
- Action: チャットUI内のボタンで、Pythonをトリガーします（再要約、Notionへの保存、SQLクエリ実行）。
- Pipe: 完全なカスタムモデルハンドラーです（リモートAPIへのルーティング、複数モデルのチェーン、エージェント構築）。
以下は、ユーザーのプロンプトからモデルに到達する前にメールアドレスを削除する最小限のFilterです。
from pydantic import BaseModel
import re
class Filter:
class Valves(BaseModel):
priority: int = 0
def __init__(self):
self.valves = self.Valves()
def inlet(self, body: dict, __user__: dict = None) -> dict:
for message in body.get("messages", []):
if message.get("role") == "user":
message["content"] = re.sub(
r"[\w\.-]+@[\w\.-]+",
"[REDACTED_EMAIL]",
message["content"],
)
return bodyこれを Admin → Settings → Functions → New にドロップし、保存して、任意のモデルでオンに切り替えます。完了です。
外部Pipelinesの場合、Open WebUIと一緒に専用のコンテナを起動します。
pipelines:
image: ghcr.io/open-webui/pipelines:main
container_name: pipelines
ports:
- "9099:9099"
volumes:
- pipelines:/app/pipelines
restart: alwaysその後、Admin → Settings → Connections で、http://pipelines:9099 をOpenAI互換APIとして追加します。Admin → Settings → Pipelines で .py ファイルをアップロードします。公式の Pipelinesリポジトリ には、翻訳ルーター、Langfuseロギング、関数呼び出しなど、多数の例があります。
MCP: Open WebUIを外部ツールに接続する
Open WebUI 0.6+ は Model Context Protocol (MCP) をサポートしており、これによりローカルモデルがClaude Desktopと同じプロトコルを通じて、外部ツール、ファイル検索、GitHub、Slack、独自のカスタムサーバーを呼び出すことができます。Pipelineを書かずにローカルモデルに実際のツール使用能力を与えるための最もクリーンな方法です。
Admin → Settings → Tools でMCPサーバーを追加します。サーバーURLを貼り付け、名前を付け、モデルごとに有効化します。モデルはチャット中にいつ呼び出すかを決定します。プロトコルの端から端までの解説は Model Context Protocol (MCP) ガイド にあり、同じパターンですが、Claude Desktop側ではなくOpen WebUI側からの視点です。
これが重要な理由：2026年半ば現在、MCPに触れているOpen WebUIチュートリアルはほぼありません。ClaudeやCursorの設定でMCPサーバーを標準化している場合、Open WebUIを全く同じサーバーに向けることができます。1つのプロトコルで、すべてのクライアントに対応します。
Open WebUIがOllamaモデルを検出できないのはなぜ？（トラブルシューティング）
Open WebUI は読み込まれるがモデルドロップダウンが空の場合、コンテナが Ollama に到達できていません。9割の場合、修正方法は --add-host=host.docker.internal:host-gateway フラグと OLLAMA_BASE_URL=http://host.docker.internal:11434 の設定です。host-gatewayフラグなしのLinuxでは、Dockerのブリッジネットワークはホストのポート11434を表示できません。クライアントのLinuxマシンで初めてこれをデプロイした際、まさにこの問題に遭遇し、1時間を失いました。
頻度の高い順に3つの根本原因があります。
-
--add-hostフラグの欠如（Linuxで最も一般的）。macOS Docker Desktopはhost.docker.internalを自動的に設定しますが、Linuxでは明示的なフラグが必要です。 -
Ollamaが
127.0.0.1のみにバインドされている。コンテナの観点からは、これは到達不可能です。修正方法:bashOLLAMA_HOST=0.0.0.0:11434 ollama serveまたは、Linuxのsystemdユニットで
Environment="OLLAMA_HOST=0.0.0.0:11434"を設定します。 -
ファイアウォール/アンチウイルスが11434をブロックしている。あまり一般的ではありませんが、
ufw、Windows Defender、または企業のエンドポイント保護を確認してください。
診断として、Open WebUIコンテナ内からこれを実行します。
docker exec open-webui curl http://host.docker.internal:11434/api/tagsモデルリストを含むJSONが返される場合、ネットワークは正常であり、問題はOpen WebUIの設定にあります（Admin → Connections → Ollama URLを確認）。ハングしたり拒否される場合、ホスト側の問題であり、原因#2から開始してください。
Open WebUI vs LM Studio vs Jan vs AnythingLLM
Open WebUI は、マルチユーザー、RAGの深さ、Pipelines/Functionsで勝ります。LM Studio は、箱から出してすぐのGPUパフォーマンスと洗練されたシングルユーザーUIで勝ります。Jan は、摩擦の少ない初回実行で勝ります。AnythingLLM は、ドキュメント取り込みの使いやすさで勝ります。チーム向けのセルフホスト型ChatGPT代替品を探している場合、答えはOpen WebUIです。
| 機能 | Open WebUI | LM Studio | Jan | AnythingLLM |
|---|---|---|---|---|
| マルチユーザー | はい | いいえ | いいえ | はい |
| ネイティブRAG | はい（深い統合） | プラグインのみ | 基本 | はい（最高のUX） |
| プラグイン / 拡張機能 | Pipelines + Functions | 限定 | Extensions | Plugins |
| GPUサポート | Ollamaバックエンド経由 | 組み込み（最高） | 組み込み | バックエンド経由 |
| 最適な用途 | セルフホスト型チーム | ソロデスクトップパワーユーザー | 初めてのローカルAI | ドキュメント重視のワークフロー |
結論: ゲーム用GPUでモデルを実行してチャットしたいだけのソロ開発者であれば、LM Studioの方がセットアップが速いです。チーム向けのプライベートChatGPTを構築したり、本格的なRAGを行ったり、カスタムPythonロジックを配線したりする場合、Open WebUIが唯一の現実的な選択肢です。より広範な ベストなローカルLLMツール の投稿では、これらのUIの下にあるランタイム層（vLLM、llama.cpp、Ollama）を比較しています。
Open WebUIをHTTPS経由で安全に公開するには？
2つのクリーンな経路があります。本番環境に近いLet's Encrypt証明書のためのOpen WebUI前の5行の Caddyfile、またはポート開放ゼロでチームと共有するための Cloudflare Tunnel です。どちらもOpen WebUIを localhost:3000 に保ちながら、HTTPS付きのクリーンな公開URLを公開します。ドメインのDNSを制御できるかどうかによって選択してください。
Caddy経路では、ドメインをボックスに向け、次に以下を行います。
ai.example.com {
reverse_proxy localhost:3000
}これが設定のすべてです。Caddyは初回リクエスト時に自動的にLet's Encrypt証明書を取得します。caddy run --config Caddyfile を実行するか（またはsystemdユニットを使用）。完全なリファレンス: Caddy docs。
Cloudflare Tunnel経路では、cloudflared tunnel create open-webui を実行し、Cloudflareゾーンでホスト名をルーティングしてから、cloudflared tunnel run を実行します。ポート開放ゼロ、TLSはCloudflareが処理します。「ファイアウォールに穴を開けずにチームに参加させたい」場合に最適です。
厳守ルール: ポート3000を生のままパブリックインターネットに公開してはいけません。Open WebUIのサインアップはデフォルトで開かれており、URLにアクセスした誰でもアカウントを作成できます。WEBUI_AUTH=False はLANでは問題ありませんが、公開用では決して使用しないでください。常にリバースプロキシの前に配置し、認証済みサインアップのホワイトリスト登録を行ってください（アカウント作成後に Admin → Settings → General → "Enable Signup" をオフにします）。
TechsyがローカルLLMデプロイメントにアプローチする方法
私たちは、データをOpenAIに送信できない（または送信したくない）法律、医療、および社内ツールチームの顧客向けに Open WebUI + Ollama セットアップを出荷してきました。パターンが十分に繰り返されるため、最初から書くことはなくなりましたが、すべてのデプロイメントには同じ3つの優先事項があります。
私たちが実際に行うこと:
- ハードウェアと予算に合わせてモデルを適切にサイジングする。 3B〜8Bの範囲が、多くの場合スイートスポットに当たります。レイテンシと月間コストが重要な場合、大きいものが常に優れているわけではありません。
- デプロイメントを強化する。 前面にCaddyを配置し、サインアップを無効化し、バックアップされた名前付きボリューム上に
/app/backend/dataを配置し、週次スナップショットを取得し、実際の災害復旧計画を立てます。 - 組織固有のニーズのためにPipelinesを配線する。 個人情報マスキングフィルター、社内SharePointやConfluenceを指すカスタムRAGパイプライン、安全なシェルアクセスのための関数呼び出しツールなど、チャットUIを社内で実際に有用にする要素です。
セットアップをスキップして、稼働中のプライベートAIスタックを受け取りたい場合は、無料相談を予約 してください。スコーピングをお手伝いします。
まとめ
3つの簡単な要約:
- 単一コンテナ経路: 最初のチャットへの最速ルート。準備済みのマシンで正直に10分。
- Docker Compose: 再起動後も生存させる必要があるものすべてに実際に必要なもの。
- Pipelines + RAG + MCP: LM StudioやJanよりもOpen WebUIを選ぶ価値を生む防衛線。
10分で自分自身のAIとチャットしています。そこから先はすべて漸進的です。ドキュメントがあるときにRAGを追加し、携帯電話で使用したいときにCaddyを追加し、実際の作業を行わせたいときにPipelinesを追加します。ローカルモデルの選択について深く掘り下げたい場合は、ローカルでLLMを実行するガイド でハードウェア面を詳細に説明しています。
FAQ
Open WebUIをOllamaと一緒にインストールするには？
3つのステップ: Docker Desktopをインストールし、Ollamaをインストールし（macOS/Linuxでは curl -fsSL https://ollama.com/install.sh | sh）、次に標準的なOpen WebUIコンテナを docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data --name open-webui ghcr.io/open-webui/open-webui:main で実行します。http://localhost:3000 を開き、管理者アカウントを作成します。
Open WebUIは無料ですか？
はい、Open WebUIはMITライセンスで完全にオープンソースです。セルフホスティングは無料です。支払うのはそれを実行するハードウェア（ラップトップ、ホームラボサーバー、またはクラウドVM）のみです。オプションの有料要素には、音声用のOpenAI TTS APIや、Open WebUIのOpenAI互換コネクタ経由でアクセスされる商用モデルが含まれます。コア機能はすべて無償です。
Open WebUIはOllamaなしで実行できますか？
はい、Open WebUIはOpenAI互換のAPIであればどれとも通信できます。OpenAI直接、LiteLLMプロキシ経由のAnthropic、vLLMサーバー、llama.cppのHTTPサーバー、GroqやTogetherなどのホスト型プロバイダーを指すことができます。しかし、「Open WebUI + Ollama」は、Ollamaがモデル管理を極めてシンプルにするため、標準的なローカルAIの組み合わせです。
Open WebUIがOllamaに接続できないのはなぜ？
最も一般的な原因: --add-host=host.docker.internal:host-gateway フラグの欠如、およびOpen WebUIの設定で OLLAMA_BASE_URL が設定されていないこと。2番目に一般的な原因: Ollamaが 127.0.0.1 のみにバインドされており、コンテナ内から到達不可能であること。修正方法: OLLAMA_HOST=0.0.0.0:11434 ollama serve。迅速な診断には docker exec open-webui curl http://host.docker.internal:11434/api/tags を実行します。
Open WebUIにモデルを追加するには？
最も簡単な経路: ホストから ollama pull llama3.2:3b （またはollama.com/libraryの任意のモデル）を実行します。モデルはOpen WebUIのドロップダウンに自動的に表示され、再起動は不要です。あるいは、Open WebUIで Admin → Settings → Connections → Ollama に移動し、UI内のpullボタンを使用します。いずれにせよ、モデルはOllama側に存在します。
Open WebUIとLM Studioの違いは何ですか？
LM Studioは、モデル管理とチャットに焦点を当てたシングルユーザーのデスクトップアプリで、強力なGPUデフォルト、滑らかなUI、マルチユーザー機能なしです。Open WebUIは、複数のユーザーをサポートし、ネイティブRAG、音声入出力、Pipelines/Functions、およびMCPを備えたセルフホスト型サーバーです。異なる対象者: LM Studioはソロのデスクトップパワーユーザー向け、Open WebUIはチーム、または拡張可能なプライベートChatGPTを求める人向けです。
携帯電話でOpen WebUIを使用できますか？
はい、Open WebUIは完全にレスポンシブであるため、任意のモバイルブラウザで動作します。HTTPS（Let's Encrypt証明書付きのCaddy、またはCloudflare Tunnel）とペアリングすると、完全に機能するモバイルチャットアプリになります。iOSまたはAndroidでホーム画面に追加すると、ネイティブに近いPWA体験が得られます。ただし、認証なしで公開用に公開しないでください。
Open WebUIを更新するには？
最新のイメージをプルして再起動します: docker pull ghcr.io/open-webui/open-webui:main && docker stop open-webui && docker rm open-webui その後、元の docker run コマンドを再実行します。名前付きボリュームはすべてのデータ、チャット履歴、ユーザー、RAGコレクション、および設定を保持します。Docker Composeの場合: docker compose pull && docker compose up -d。更新は概ね週次で提供されます。
Open WebUIは音声チャットをサポートしていますか？
はい、音声認識（ローカル faster-whisper 経由）と音声合成（OpenAI TTS APIまたはローカル coqui-tts 経由）の両方をサポートしています。Admin → Settings → Audio で両方を設定します。有効にすると、チャットボックスにマイクアイコンが表示されます。実用的なセットアップは、ローカルWhisperプラスOpenAI TTSで、完全オフライン入力、高速でクリーンな出力を実現します。環境変数の設定については上記の音声入出力セクションをご覧ください。
Open WebUIにPDFを追加するには？
プロフィール → Workspace → Knowledge → New collection をクリックし、PDF、Wordドキュメント、Markdown、またはテキストファイルをアップロードします。Open WebUIはドキュメントをチャンク分割し、nomic-embed-text でベクトル化し（まず ollama pull nomic-embed-text で取得）、ChromaDBに保存します。チャットで #collection-name を使用して任意のコレクションを参照するか、カスタムモデルに永続的にアタッチします。