Open WebUIをWindowsで使う方法｜Docker・Ollama・保存データの確認

先に結論：Open WebUIはモデルruntimeではなくWeb UI・platform

Open WebUIは、チャット画面、会話履歴、文書・知識機能、provider接続などをまとめるweb platformです。Ollamaはモデルを管理・提供するruntimeなので、両者は同じ役割ではありません。Open WebUIへ接続したproviderが外部APIなら、Open WebUIを自宅PCで動かしていても入力の送信先は外部になります。

現行版v0.11.4とWindowsの「動かない」を分ける

2026-09-24に公式release pageは、9月21日公開のv0.11.4をLatestとして示しています。stableのversion tag、main/latestのrolling image、Windows hostとcontainerの接続、standardとslimの機能差は別の確認対象です。Open WebUIのrelease番号だけで、Ollamaの起動・GPU・モデル応答まで確認済みとは扱いません。

main-slimは小さくても、標準imageと同じlocal machine-learning stackを内包するわけではありません。Windows host側のOllamaなどcontainerから到達できるserviceを使うことはできますが、RAGにはembedding providerとpgvectorが必要で、PDF・Word・presentationには別のdocument extraction engineを設定します。application DBはSQLiteまたはPostgreSQL、file storageはlocalのみです。local modelをimage内で動かす場合やpgvector以外のvector client・object storage・MySQL/MariaDBを使う場合はstandard imageを選びます。

画面が開かない、containerがrestartする、Open WebUIは開くがOllamaへ届かない、更新後にdatabase migrationが失敗する、文書を追加するとembeddingで止まる、は同じ「Open WebUIが動かない」ではありません。まずimage tag・container log・volume・接続元を一つずつ固定します。

• Open WebUI v0.11.4 release - 現行Latestとslim imageの変更を確認する
• Open WebUI v0.11.3 migration note - 0.11.0〜0.11.2からのmigration修正を見る
• Quick Startのimage tag・slim要件 - main/latest、version tag、standard/slim、database・storage・RAGの条件を見る

Windowsで始める前に決めること

Open WebUIにはDocker以外の導入経路もありますが、ここではWindows初心者が構成を再現しやすいDocker Desktop/WSL経路に絞ります。実機へのインストールやDockerの実行はこのページから代行しません。

Docker Desktop・WSLからOpen WebUIを起動する

1. Docker DesktopをWindowsで起動し、WSL2 backendと必要なresourceを確認する。
2. Open WebUIの公式image tagを選び、rolling tagかversion pinかを記録する。
3. 再作成してもログイン状態を失わないよう、実値を共有しない固定WEBUI_SECRET_KEYを用意する。
4. named volumeを/app/backend/dataへマウントしてcontainerを作る。
5. ブラウザでlocalhost:3000を開き、最初の管理者設定を確認する。

docker pull ghcr.io/open-webui/open-webui:main

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

公式Quick Startのmain/latestはrolling tagとして案内されています。`your-secret-key`は公式例に沿って生成した固定値へ置き換え、実値を記事・ログ・共有ファイルへ残しません。再現性や更新影響を抑えたい場合は、volume backupと利用時点のversion tag・image digestを記録してから更新します。

• 3000はWindowsブラウザ側のport、8080はcontainer内のOpen WebUI portです。
• 既に3000を使うアプリがあれば、左側だけ別portに変え、ブラウザで開くURLも合わせます。
• --add-host=host.docker.internal:host-gatewayは、containerからWindows host上のOllamaへ到達するための入口です。
• WEBUI_SECRET_KEYを固定しないままcontainerを再作成すると、ログイン状態を失う原因になります。
• volumeを省略した起動は、containerの作り直し時に履歴や設定を失う原因になります。
• Docker Desktop、WSL、Open WebUIのversionが変わるため、手順を実行する前に公式Quick Startを再確認します。

OllamaをWindows hostからつなぐか、同じcontainer系で動かすか

最初の切り分けでは、OllamaをWindows側で単独起動し、Open WebUIだけをcontainerで動かす構成が原因を追いやすい場合があります。このときOpen WebUI containerから見たlocalhostはWindows hostではないため、公式のOllama接続手順にあるhost.docker.internalを使う境界を理解します。

Open WebUIにはOllamaを含むimage tagもありますが、別にWindows Ollamaを動かしている状態で二つのmodel runtimeを同時に使い始めると、model、port、保存場所の切り分けが難しくなります。最初はどちらが推論を担当するかを一つに決めます。

• OllamaをWindowsに入れる - Ollama本体を単独で確認する
• OllamaのOpenAI互換API - /v1とnative APIの境界を確認する
• Open WebUIのOllama接続 - host.docker.internalとmodel管理を公式docsで確認する

Open WebUIへproviderを追加する

公式のprovider接続フローでは、Ollama、OpenAI-compatible API、Open ResponsesなどをOpen WebUIのConnectionsから追加します。providerを追加する前に、runtime単体でmodelが応答することを確認し、その後にURL・認証・model IDを一つずつ入力します。

1. OllamaまたはAPI providerを単独で起動し、モデル名とportを確認する。
2. Open WebUIの管理設定にあるConnectionsでproviderの種類を選ぶ。
3. Docker containerから到達できるURLを設定する。Windows hostならlocalhostではなくhost.docker.internalが候補になる。
4. model list、短い入力、ログを確認し、問題がなければ文書・tools・複数providerへ広げる。

OpenAI-compatible接続では、Open WebUIがmodels endpointを確認できない場合やmodel IDが一覧に出ない場合があります。まずprovider自身の/modelsと実際のIDを確認し、公式docsにあるallowlistや手入力の手順を、providerごとの仕様として扱います。

画像・PDFをRAGへ渡すときはvision chatとfile extractionを分ける

Open WebUIの現行Models docsでは、Visionはvision-capable base modelが必要な画像分析、File Uploadは添付入口、File Contextは有効時だけ添付ファイルをRAG処理する機能、Citationsはknowledge・web search・builtin toolsのsourceを表示する機能として分かれています。画像を添付して説明させることと、PDFや画像を検索可能なknowledgeへ入れて引用を返すことを同じ成功条件にしません。

OpenAI-compatible providerをRAGに使う場合、Open WebUI公式docsはChat Completionsだけでなく`/v1/embeddings`を必要endpointとして挙げています。チャットが返ること、画像を見られること、embedding・検索・引用が動くことは別々に確認します。

1. 入力を「画像への質問」「正確な文字・座標の抽出」「PDF/画像の検索・引用」のどれかに分ける。
2. Vision、File Context、Knowledge、Citationsを設定し、base modelのvision対応とproviderの`/v1/embeddings`対応を個別に確認する。
3. 画像PDFは`PDF_EXTRACT_IMAGES`やDoclingの抽出設定を確認し、OCR・table・picture descriptionの工程と出力を記録する。
4. Doclingを使う場合は、Open WebUI docsのcommunity tutorialであることを踏まえ、picture descriptionをlocal modelとAPIへ分ける。設定名の`picture_description_local`と`picture_description_api`を別経路として記録し、API modeでは`DOCLING_SERVE_ENABLE_REMOTE_SERVICES=true`が必要なため、外部送信先・認証・ログを確認する。
5. confidenceが低い文字、型番、金額、日付、表は元画像へ戻って照合し、原本・抽出結果・chunk・引用sourceを別々に残す。

Open WebUIをWindows上で動かし、VLMやDoclingをlocalに置いても、provider・embedding endpoint・picture description API・モデル取得・volume・ログの経路が自動的にlocal-onlyになるわけではありません。逆に、画像をVLMへ渡せることだけでOCRのboundsやRAGの引用sourceが得られるとも扱いません。

• Open WebUI Models capability - Vision、File Context、Knowledge、Citationsの境界を見る
• Open WebUI Docling extraction - PDF・画像、OCR、table、picture descriptionのlocal/APIを確認する
• Open WebUI environment configuration - PDF_EXTRACT_IMAGES、RAG_TEMPLATE、chunk、embeddingの設定を見る
• OpenAI-compatible provider requirements - RAGに必要な/v1/embeddingsとchat endpointを確認する
• Windows AI Text Recognition - 文字・位置境界・confidenceをVLMの説明と分ける
• LM Studioの画像入力 - VLM、model capability、画像形式、mmprojの条件を見る
• PDF抽出・OCR・表の崩れ - 抽出結果を元PDFと照合する
• RAG引用faithfulness - 引用範囲と回答を別に検証する

保存データと更新を分けて管理する

Open WebUIの公式Docker例では、container内の/app/backend/dataをnamed volumeへ保存します。ここにはOpen WebUI側の設定や会話・文書に関わるデータが入るため、imageを更新する操作とvolumeを削除する操作を同じものとして扱いません。

• 更新前に、使用中のimage tag、volume名、Open WebUIのversion、provider URLを記録する。
• volumeを残したままimage更新を検討し、先にバックアップと復元手順を確認する。
• main/latestのrolling更新をproductionの固定版と同じ前提にしない。
• containerを削除して作り直す場合も、同名volumeを意図せず削除・初期化しない。

• Open WebUI Security - chat storage、管理者可視性、temporary chatを確認する
• 履歴・ログ・プライバシー - runtimeとUI側の保存を分けて確認する

つながらないときの順番

Open WebUIの接続エラーは、モデル性能より前に「どのプロセスから、どのURLへ接続しているか」を確認します。container内のlocalhost、Windows hostのlocalhost、外部URLを同じ意味で入力しないことが最初の切り分けです。

OllamaをWindows hostでlocalhostにbindしている場合、containerから到達させるためにhost側のlisten設定を変更する案内が必要になることがあります。ただし0.0.0.0への公開はLANからの到達範囲を広げる可能性があるため、Windows firewall、認証、利用ネットワークを確認せずに変更しません。

公式のConnection Errors docsでは、到達できないendpointがあるとmodel listの読み込みが遅くなることも案内されています。複数providerを一度に設定せず、接続を一つずつ追加します。

「ローカル」の範囲と安全設定

Open WebUIを自分のWindows PCで動かすことは、入力が必ずPC内だけに留まることを意味しません。Ollamaの推論、Open WebUIの履歴、外部providerのAPI送信、ブラウザからのdirect connectionは別の経路です。

• 最初はlocalhostのみで使い、LANやインターネットへ公開しない。
• 外部providerを追加する場合は、送信されるprompt・添付文書・model・保持期間・料金を確認する。
• API keyを記事、スクリーンショット、ログ、共有volumeへ残さない。
• 管理者が会話を見られる構成や、temporary chat・暗号化の範囲を公式Security docsで確認する。
• browser-directのexperimental connectionはCORSとブラウザ側のkey保存が関係するため、最初の構成にしない。

• Open WebUI Security - self-hostedのデータ管理と管理者権限を確認する
• Direct Connections - ブラウザ直結のCORS・API key境界を確認する
• ローカルAIのプライバシー - localという言葉と実際の送信先を分ける

Open WebUIの公式セキュリティ告知：構成ごとの影響条件

Open WebUI公式のsecurity advisoryを網羅した一覧ではありません。このWindows/self-hostedガイドでは、構成値と照合しやすい6件を選んでいます。6件は2026年8月30日から9月9日に公開され、いずれもv0.11.1で修正済みです。2026-09-24の公式release一覧ではv0.11.4がLatestでした。告知ごとに前提条件が異なり、Windowsやself-hostedというだけで該当するわけではありません。稼働中のimage tagと、次の設定が有効かを照合してください。

• High・OAuth/OIDCとSCIM: 0.6.41以上0.11.1未満が対象範囲です。SQLiteでOAuth/OIDC sign-inまたはSCIM provisioningを有効にしている場合に照合不具合が関係します。SQLiteは既定DBですが、OAuth/OIDCとSCIMは既定で無効です。PostgreSQLは影響しません。意図的な別アカウントへのログインには、`OAUTH_SUB_CLAIM`などでsubject claimをusername/emailのような利用者が変更できる値に設定した追加条件があります。provider割当てIDでも、記号を含む通常IDの誤照合は起こり得ます。SCIM経由の操作には特権bearer tokenが必要です。
• High・Playwright web loader: 0.9.6以上0.11.1未満が対象範囲です。WEB_LOADER_ENGINE=playwrightと到達可能なPlaywright browserがあり、認証済み利用者がingestionやweb searchへURLを渡せる構成で、攻撃者がそのhostnameの権威DNSを管理し、browserから内部serviceへ到達できる場合のSSRFを確認します。既定のweb loaderは影響しません。
• Moderate・tool serverへのsession cookie: 0.6.27以上0.11.1未満が対象範囲です。同じrequestに2つ以上の外部tool serverを付け、sessionまたはsystem OAuthを使う接続が処理順の最後にある場合の条件です。bearer認証の別serverへcookieが渡る可能性があります。tool serverは既定で設定されず、0〜1台、または該当OAuth接続がない構成は対象外です。
• Moderate・built-in knowledge tool: 0.7.0〜0.11.0が対象範囲です。Qdrant、Elasticsearch、OpenSearch、Milvus、openGauss、Oracle 23ai、Pinecone、S3 Vectors、Weaviateのbackendに加え、built-in knowledge toolが有効（既定）で、toolを呼べるmodelに別のknowledgeを直接割り当てず、利用者に非公開のknowledge baseが1つ以上ある条件を確認します。既定のChromaとpgvector、MariaDB、Valkeyは影響しません。この経路で露出するのはknowledge baseのID・名前・説明で、文書本文や書き込み権限ではありません。
• High・built-in server-side web fetchとAzure: v0.11.1未満が対象範囲です。RAG URL ingestionまたはweb searchのserver-side fetchを、verifiedな認証利用者が呼べる状態で、`ENABLE_LOCAL_WEB_FETCH=false`（既定）のaddress filterが有効、かつ`WEB_FETCH_FILTER_LIST`に対象addressを追加していない条件を照合します。admin roleやspecial workspace permissionは不要です。Azure platform channelへの影響はOpen WebUI hostがAzure上にある場合です。これは既存のPlaywright web loader advisoryとは別のfetch経路です。advisoryは特定secretの取得を確認したとは述べていません。`ENABLE_LOCAL_WEB_FETCH=true`はfilterを無効化してinternal addressへのfetchを許可する設定なので、回避策として有効化しないでください。
• Moderate・OAuth token exchangeとrole policy: 0.8.0以上0.11.1未満が対象範囲です。`ENABLE_OAUTH_TOKEN_EXCHANGE=true`（既定false）と、`ENABLE_OAUTH_ROLE_MANAGEMENT=true`および`OAUTH_ALLOWED_ROLES`または`OAUTH_ADMIN_ROLES`の併用を確認します（role managementも既定off）。有効期限内のprovider access tokenと、provider subjectに既にlink済みのaccount、または`OAUTH_MERGE_ACCOUNTS_BY_EMAIL`有効時に一致する既存email accountが必要です。IdPから許可roleが消えても、token exchangeで既存roleのsessionが続く可能性があります。新規account作成やrole昇格を行う問題ではありません。v0.11.1は同じrole判定をtoken exchangeにも適用し、許可roleがなければ403で拒否します。

OAuth token exchangeでは、v0.11.1のrole-policy修正とは別に、issuing clientのtrust境界を確認します。`ENABLE_OAUTH_TOKEN_EXCHANGE`は既定falseで、v0.11.0から利用できる`OAUTH_TOKEN_EXCHANGE_TRUSTED_CLIENT_IDS`もopt-inです。リストが未設定・空なら、v0.11.1以降でもclient checkは自動で有効にならず、providerが有効と認めるtokenの発行clientは制限されません。

このclient checkにはRFC 7662 token introspectionが必要です。Open WebUI公式docsが非対応として挙げるGoogle、Microsoft Entra ID、GitHub、Feishuでは、このリストによるclient制限を使えません。対応providerでtoken exchangeを必要として有効化する場合は、公式docsに沿ってtrusted client IDsを設定してください。token exchangeが不要なら有効にせず、v0.11.1のrole-policy修正だけでclient trustまで解決したとは判断しないでください。

選定した6件のadvisoryに該当する構成では、各advisoryの手順とimage tagを確認し、v0.11.1以降へ更新してください。設定名だけで影響を断定せず、実際のDB・loader・tool server・vector backend・server-side fetch経路を確認します。

• GHSA-wpmr-8h3q-fwj7: OAuth・SCIM identity matching - affected versionとSQLite・OAuth/OIDC・SCIMの条件
• GHSA-4v28-j6q3-5m4r: Playwright web loader SSRF - Playwright設定、URL入力、内部networkの条件
• GHSA-p78m-89r6-pgf7: tool server session cookies - tool server数とsession/system OAuthの条件
• GHSA-pcvc-8vrv-8q6w: knowledge tool vector filters - affected vector backendと露出するmetadataの範囲
• GHSA-34r3-9m95-vq73: server-side web fetch / Azure - Azure host、RAG URL ingestion・web search、address filterの条件
• GHSA-wvm9-9g5j-623f: OAuth token exchange role policy - token exchange・role management・既存accountの条件
• GHSA-rq84-p6rr-vf89: OAuth token exchange client trust - role policyとは別のissuing-client boundaryとv0.11.0の設定
• OAuth Token Exchange Client Trust - trusted client IDs、RFC 7662、provider対応とopt-in境界
• Open WebUI SSO: OAuth token exchange - 既定offのendpointとtrusted client IDsの公式案内
• OAuth token exchange environment variables - client IDs、introspection、token exchange rate limitの設定仕様

関連記事

• LM StudioとOllamaの比較 - 単体GUI・runtime・API連携の違いを見る
• ローカルAI APIサーバー比較 - LM Studio・Ollama・Janのendpointと認証を比較する
• ローカル文書チャットの選び方 - Open WebUI・AnythingLLMなど文書UIの役割を比較する
• AnythingLLMでPDFを読む - 文書を追加するUI側の保存と検索を確認する
• Ollamaのモデル保存場所 - Ollamaのmodel cacheとOpen WebUIのvolumeを分ける

公式確認日

情報確認日: 2026-09-24。Open WebUI公式のv0.11.4 release、Quick Startのstandard/slim image要件、v0.11.3 migration note、provider接続、Ollama接続、OpenAI-compatible接続、Connection Errors、Security、Network Diagrams、Direct Connectionsと、設定値照合用に選定した6件のsecurity advisoryを確認しました。OAuth token exchangeのclient trustは別の境界としてGHSA-rq84-p6rr-vf89と公式Accepted Risk / SSO / environment configuration docsを照合しています。Docker image tag、database・file storage・vector store、Windows/WSLの条件、migration、provider protocol、接続画面、保存範囲は更新されるため、実行前に公式docsとadvisoryを再確認してください。