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項目」 に整理しています。