Open WebUIは、セルフホストできるAIチャットUIです。チャット画面だけでなく、モデル接続、Knowledge、ユーザー管理などを一つの画面で扱えます。

この記事ではDockerでOpen WebUIを起動し、架空の社内規程をKnowledgeへ登録して、引用付きで回答できるところまでを構築します。

「セルフホスト＝文書が一切外部へ出ない」とは限りません。外部LLMや外部Embedding APIを選べば、プロンプトや抽出テキストはその接続先へ送信されます。データフローを必ず確認してください。

今回、実際に確認した環境

2026年8月18日にOpen WebUI 0.11.0をローカル起動し、Knowledgeの作成、Markdown文書3件の登録、チャットへのKnowledge添付、検索、引用表示まで操作しました。

項目	検証内容
Knowledge	社内規程（検証用）
文書	出張旅費規程、情報セキュリティ規程、入社初日ガイド
データ	すべて架空の「サンプル株式会社」
モデル接続	ローカルのOpenAI互換テストAPI
確認結果	1泊12,000円、5営業日以内、出典ファイルを表示

回答生成側は外部サービスへデータを送らず再現性を保つため、固定応答を返すローカルのテストAPIを使用しました。Knowledgeの取り込み・検索・チャットへのコンテキスト注入・引用表示はOpen WebUIの実機能です。本番評価では実際に採用するLLMへ差し替えて、回答品質とデータ送信先を再確認します。

完成構成

Open WebUIはUIとKnowledge管理を担当します。回答生成はOllamaなどのローカルモデル、またはOpenAI互換APIへ接続します。Knowledgeへ登録した文書は抽出・分割・埋め込みされ、検索時に関連チャンクがモデルへ渡されます。

1. Dockerで起動する

公式のQuick StartではDockerが推奨されています。まず検証用に1コンテナで起動します。

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

docker run -d \
  -p 3000:8080 \
  -v open-webui:/app/backend/data \
  --name open-webui \
  --restart always \
  ghcr.io/open-webui/open-webui:main

ブラウザでhttp://localhost:3000を開きます。最初に登録したユーザーが管理者になります。

Composeで管理する場合の最小例です。

services:
  openwebui:
    image: ghcr.io/open-webui/open-webui:main
    ports:
      - "3000:8080"
    volumes:
      - open-webui:/app/backend/data
    restart: unless-stopped

volumes:
  open-webui:

検証後に本番運用へ進む場合は、:mainではなくリリースバージョンへ固定し、更新前にバックアップと検証を行います。

2. モデルプロバイダーを接続する

管理画面のAdmin Settings → Connectionsから接続を追加します。

OpenAI互換APIの場合

Connections → OpenAIを開く
Add Connectionを選ぶ
API URLとAPI Keyを入力する
必要なら表示するModel IDをallowlistに追加する
保存してモデル選択画面からテストする

DockerコンテナからホストPC上のモデルサーバーへ接続する場合、URLのlocalhostは通常host.docker.internalへ置き換えます。

ローカル運用を優先するならOllama、既存のクラウド基盤を使うならOpenAI互換ゲートウェイやLiteLLMなどを接続できます。どれを選ぶ場合も、入力データの保存、学習利用、ログ保持、リージョンを確認します。

3. Knowledge Baseを作る

サイドバーからWorkspaceを開く
Knowledgeを選ぶ
Createで社内規程（検証用）を作る
架空のPDF、Markdown、Wordファイルをアップロードする
処理が完了したことを確認する

今回のKnowledgeには、架空のMarkdown文書3件が登録されていることを画面で確認しました。

Open WebUIには主に2つの取得モードがあります。

モード	向く文書
Focused Retrieval（RAG）	規程集、マニュアルなど大きい文書群
Full Context	短い用語集、回答ルールなど常に全文を渡したい文書

最初はFocused Retrievalを使います。Knowledgeはチャットで#から参照するか、Workspace → Modelsでカスタムモデルへ紐付けます。部署ごとのモデルを作ると、参照するKnowledgeを限定しやすくなります。

4. 回答ルールを設定する

カスタムモデルのSystem Promptへ、次のようなルールを入れます。

あなたは社内文書検索アシスタントです。
回答は添付されたKnowledgeの内容を優先してください。
根拠が見つからない場合は推測せず、「登録文書から確認できません」と答えてください。
回答には文書名または表示された引用を残してください。
複数文書で内容が矛盾する場合は、改定日を示して管理者への確認を促してください。

プロンプトだけで機密制御はできません。Knowledgeやモデルの権限、ネットワーク、ユーザー管理を併用します。

5. 引用を含めてテストする

次の3種類を混ぜて評価します。

正答あり: 国内出張の宿泊費上限はいくらですか？
複数文書: 出張申請から精算までの手順を順番に説明してください。
正答なし: 海外拠点への赴任手当はいくらですか？

確認するポイントは次の通りです。

正しい文書が引用されているか
引用部分と回答が一致しているか
数値、期限、例外条件を落としていないか
答えがない質問で推測していないか
質問の言い換えでも同じ根拠を取得できるか

実際にKnowledgeをチャットへ添付し、次の質問を送信しました。

国内出張の宿泊費上限と精算期限を、根拠文書とともに教えてください。

回答には「1泊12,000円（税込）」「帰着日の翌日から5営業日以内」が表示され、1 Sourceから01_出張旅費規程.mdを確認できました。

6. 検索精度を調整する

文書を増やす前に、失敗原因を分類します。

症状	見直す場所
正しい文書が検索されない	見出し、OCR、チャンクサイズ、Embedding
似た文書が混ざる	メタデータ、Knowledge分割、ハイブリッド検索
検索は正しいが回答が違う	System Prompt、モデル、渡すチャンク数
引用が粗い	抽出エンジン、表の読み取り、元ファイル形式

Open WebUIはベクトル検索に加え、設定によりBM25とのハイブリッド検索や再ランキングを利用できます。製品コードや規程番号のような完全一致が重要な文書では、キーワード検索を組み合わせる効果があります。

7. 本番運用の最低ライン

ローカルで動いた状態はPoCの入口です。社内公開前に次を整えます。

HTTPS対応のリバースプロキシまたはZero Trust経由にする
公開ポートを社内ネットワークへ限定する
WEBUI_SECRET_KEYを安全に固定・保管する
ユーザー登録を管理し、必要ならOIDC/SSOを使う
永続ボリュームとデータベースをバックアップする
コンテナイメージをバージョン固定する
チャット履歴、文書、API Keyの保持場所を確認する
モデル別・部署別の利用制限とコスト上限を設ける

Open WebUIは単一テナント前提のため、複数社や強いテナント分離が必要なSaaS用途では、アプリケーション分離や別構成を検討します。

まとめ

Open WebUIは、社内向けAIチャットのUIとKnowledgeを短期間で試すのに向いています。特に、モデルを差し替えて比較したい、画面を一から開発したくない、社内ネットワーク内で運用したい場合に有力です。

一方で、本番の難所はインストールではなく、認証、バックアップ、アップデート、文書権限、外部モデルへのデータ送信方針です。PoCの時点からデータフロー図と運用責任者を決めておくと、本番移行が止まりにくくなります。

導入判断・費用・運用体制を比較したい方へ

セルフホストが向く条件、モデル接続先、認証、文書権限、運用コストはRoot on公式ブログの「Open WebUIで社内AIチャットを構築する前に決める7項目」に整理しています。