Open WebUI で Ollama に Web UI を足して、チームでローカル LLM を使う

Open WebUIとは、OllamaなどのローカルLLMをブラウザから使えるようにする、無料利用可能なWeb UIである。現行版はソースコードが公開されている一方、ブランド表示に関するライセンス条件があり、OSI承認のオープンソースライセンスではない。

個人がローカル LLM とチャットするだけなら、いまは Ollama の公式アプリ（macOS / Windows）でも始められます。問題が出てくるのは、それを社内の複数人で共有しようとした瞬間です。誰にアクセスを許すのか、利用者をどう増減するのか、ブラウザから安全に使わせるにはどうするのか。個人向けの仕組みのままチーム展開に踏み込むと、この「共有」の部分でつまずきます。Open WebUI は、まさにこの共有の層を埋めるために使われるツールです。

ローカル LLM をチームに展開したい管理者・エンジニアに向けて、Open WebUI が何を足してくれるのか、どう導入するのかを順に整理します。導入手順だけでなく、後半ではライセンスの落とし穴や機密データの扱いまで踏み込みます。

Open WebUI とは何か、なぜ Ollama に足すのか

Open WebUI は、ローカルで動く LLM を複数人で共有するための受け皿になるソフトウェアです（ソースコードは公開されていますが、後述のとおり OSI 承認オープンソースではありません）。Ollama 自体は推論を動かす「エンジン」で、個人で使うぶんには公式アプリからチャットできます。ただしエンジンとその個人向けアプリには、利用者を分けて管理する仕組みまでは含まれません。Open WebUI は、そのエンジンの前に「複数人で使うための受付と管理画面」を一枚かぶせる役割にあたります。この分担が、チーム利用を成立させる出発点になります。

Ollama 単体でもチャットはできます。公式アプリを使えば、モデルのダウンロードや会話、ファイルのドラッグ＆ドロップ、画像対応モデルの利用まで、1 台のマシンの中で完結します。足りないのは「複数人で 1 つの基盤を共有する」ための仕組みです。アプリはあくまで個人の手元で動く前提で、利用者ごとのアカウントや権限の管理は守備範囲の外。そこを担うのが Open WebUI の最も分かりやすい価値になります。

ChatGPT 風 UI が解決する「共有のしづらさ」

社内でローカル LLM を共有する場面を想像してみてください。一人ひとりが自分の PC に Ollama を入れて公式アプリで使う形でも個人利用はできますが、チームで足並みをそろえるとなると、各自のインストールやモデル管理がばらつき、誰が何を使っているかも見えなくなります。共有のサーバーに 1 つ立てて、ブラウザで URL を開いてログインする形にすれば、利用者は ChatGPT のような馴染みの操作で使え、管理側もアカウントやモデルを一元的に扱えます。

Open WebUI が提供するのは、まさにこの「すでに知っている操作感」。チャット画面、モデルの切り替え、会話履歴の保存といった基本機能が画面上でまとまっており、コマンドの知識がなくても使い始められます。技術者がセットアップを一度済ませてしまえば、あとは利用者ごとにアカウントを登録・承認し、必要な範囲のモデルや機能を割り当てれば使い始められます。導入の手間を一点に集約し、利用のハードルを全員ぶん下げられるのが、共有画面を足す本質的な意味です。

つまり、個人の PC でばらばらに使っていたローカル LLM を、共有サーバー上でチーム全員が同じ画面・同じ管理のもとで使えるツールへと変える。これがチーム展開の第一歩になります。

認証なし raw Ollama API の限界

Ollama はローカルで API サーバーとしても動きますが、既定の構成は基本的に個人利用を前提としています。raw な Ollama API はそれ自体に利用者認証の仕組みを持たず、アクセスできる人を絞り込む発想が標準では組み込まれていません。

これが何を意味するか。1 台のマシンで Ollama を立て、その API を社内の複数人で直接叩く構成にした場合、「誰がアクセスしているのか」「この人にこのモデルを使わせてよいのか」を制御する層が抜け落ちます。個人の開発機で自分だけが使うなら問題になりませんが、チームの共有基盤として広げる瞬間に、この「認証がない」という性質が運用上の弱点に変わる。

Open WebUI は、この API の手前に立つ受付係のような役割を担います。利用者はまず Open WebUI にログインし、その先で Ollama とやり取りする。API を直接さらすのではなく、認証とアクセス制御を備えた画面を一枚かませることで、共有に耐える構成へと引き上げられます。次の章では、その認証と権限管理の中身を具体的に見ていきます。

アカウントと RBAC で「チーム利用」が成り立つ仕組み

Open WebUI がチーム利用に向くと言われる根拠は、利用者ごとのアカウントと RBAC（ロールベースのアクセス制御）を標準で備えている点にあります。RBAC とは、利用者に「ロール（役割）」を割り当て、そのロールに応じて使える機能や範囲を変える仕組みのこと。Open WebUI の基本ロールは管理者（Admin）・一般（User）・承認待ち（Pending）の3種類で、管理者が新規ユーザーを承認し、各人が何にアクセスできるかを管理します。必要に応じて、管理者側でアカウント作成そのものを管理する構成も取れます。

認証のない API を全員で共有する構成と比べると、この差は決定的です。誰がアクセスしているのかを把握でき、利用者を後から追加・停止でき、権限を分けられる。チームで一つの基盤を回すうえで欠かせない管理の土台が、最初からそろっています。

ロールの違い（Admin・User・Pending）

Open WebUI を最初に立ち上げて登録したアカウントが管理者（Admin）になります。管理者は他のメンバーのアカウント発行や、利用できる範囲の設定など、基盤全体を運営する立場です。その後の新規ユーザーのロールは設定（DEFAULT_USER_ROLE）で決まり、チームや共有用途では新規ユーザーをいったん承認待ち（Pending）にして、管理者が承認するまで機能を使えないようにするのが公式の推奨です。承認後は一般（User）として、割り当てられた範囲のなかでチャットやモデルを使う立場になります。

この役割分担があることで、「設定や管理は情シス担当が握り、現場メンバーは使うだけ」という現実的な運用が組めます。全員が同じ権限だと、誤って設定を変えたり、想定外のモデルを呼び出したりする余地が生まれますが、ロールで層を分けておけばそうした事故を抑えられる。

ロールの正確な名称や、各ロールで何ができるかの細部は、バージョンによって変わる可能性があります。導入時には最新の手順・対応状況を公式ドキュメント（記事末尾の参考資料）で確認してください。ここで押さえておきたいのは、「管理する人」と「使う人」を分離できる構造が標準で備わっている、という大枠です。

raw API 共有との比較表

raw な Ollama API を直接共有する構成と、Open WebUI を経由する構成を並べると、チーム利用に向くかどうかの差がはっきりします。

表のとおり、両者は「優劣」というより「想定する使い方」が違います。raw API は自分一人、あるいは自前のアプリから呼び出す用途では身軽で十分。対して複数人が日常的に同じ基盤を使うなら、認証とユーザー管理とアクセス制御がそろった Open WebUI 経由のほうが、運用の安全性と管理のしやすさで明確に上回ります。チームで広げるという目的に絞れば、選ぶべきはこちらです。

Docker での導入手順とデータ永続化

Open WebUI の導入は、Docker を使う方法が一般的に案内されています。大まかな流れは三段階。まず土台となる Ollama を入れてモデルを用意し、次に Open WebUI のコンテナを起動し、最後にブラウザからアクセスして初期設定を済ませる、という順番です。

手順1として、先に Ollama をインストールし、ollama pull モデル名 のような形でモデルを一つ取得しておきます。Open WebUI はあくまで画面を提供する側で、実際に推論を動かすのは Ollama 側。土台がない状態では会話が成立しないため、モデルの準備を先に済ませるのが順序です。

手順2では、Open WebUI を Docker コンテナとして起動します。一般的には docker run でコンテナを立ち上げる案内がされており、起動後はブラウザで指定のアドレスを開くとログイン画面が表示されます。手順3として、最初のアカウントを作成すればそのまま管理者として使い始められる。ここまでが導入の基本的な道のりです。

コンテナイメージ名やポート番号、コマンドの正確な引数はバージョンや構成で変わりうるため、逐語のコマンドをそのまま転記するのは避けます。最新のインストール手順は公式のドキュメントを参照してください。ここでは「Ollama を用意 → Open WebUI を起動 → ブラウザで初期設定」という流れの全体像をつかんでおけば十分です。

データ永続化ボリュームを付ける理由

導入で見落とすと痛い目を見るのが、データの永続化です。Docker コンテナは作り直すとなかにため込んだデータが消える性質を持ちます。Open WebUI のアカウント情報や会話履歴はコンテナの内部に保存されるため、永続化の設定をしないままコンテナを再作成すると、登録したユーザーも履歴もまとめて失われる。

ボリュームを付けておけば、データ本体はコンテナの外側に保管されます。コンテナをバージョンアップのために作り直しても、保存先を同じボリュームに向けている限り、アカウントも履歴も引き継がれる。チームの利用基盤として継続運用するなら、この永続化は導入時点で必ず組み込んでおくべき設定です。

関連して知っておきたいのが WEBUI_SECRET_KEY です。これはログイントークンの署名などに使われる鍵で、明示的に指定していなくても、生成された鍵はデータディレクトリ内（.webui_secret_key）に保存され、次回起動時に再利用されます。そのため、データボリュームを永続化した単一インスタンス構成なら、手動で指定しなくても再起動のたびにログアウトするわけではありません。注意が要るのは、複数のインスタンスを負荷分散する構成です。この場合は全インスタンスで同じ WEBUI_SECRET_KEY を明示的に共有しないと、片方が発行したトークンをもう片方が弾いてログインできなくなります。なお、鍵を変更すると既存のログインセッションは無効になります。

別サーバーの Ollama に繋ぐ（OLLAMA_BASE_URL）

Open WebUI と Ollama を標準的な構成で同一マシン上に置く場合は、少ない設定で接続できます。ただし注意したいのは、Open WebUI を Docker で動かし、Ollama をホスト側で動かす構成です。この場合は OS やネットワークの条件によって、接続先（例: http://host.docker.internal:11434）を OLLAMA_BASE_URL で明示する必要が出てきます。「同一マシンだから無設定で必ず繋がる」とは限りません。

一方、構成によっては Ollama を別のサーバーに置き、Open WebUI はまた別のマシンから接続させたいこともあります。GPU を積んだ推論用サーバーに Ollama を集約し、Open WebUI はそこへ向けて繋ぐ、といった分離型の構成。この場合は接続先を明示する必要があり、一般的には OLLAMA_BASE_URL という環境変数で Ollama のアドレスを指定します。

接続先は配置構成しだいで、最小設定で繋がることもあれば、Docker のネットワーク条件や別サーバー構成で OLLAMA_BASE_URL の指定が要ることもあります。この勘所をつかんでおけば、小さく始めて後からサーバーを分ける、といった拡張にも対応できます。環境変数の正確な書式や、複数の Ollama を束ねる構成の詳細は変わる可能性があるため、実際の設定は公式ドキュメントの最新の記述で確認してください。

ライセンスの注意点（branding clause と業務利用可否）

導入を決める前に、もうひとつ確認しておきたいのがライセンス。Open WebUI は「オープンソース」として紹介されることが多いものの、その中身は一般的なイメージと少しずれています。導入判断者がここを誤解すると、後から社内のコンプライアンス確認でつまずきます。

Open WebUI は v0.6.5 までは BSD-3-Clause ライセンスで配布されていました。ところが v0.6.6 以降は、Open WebUI の名称・ロゴなどのブランド表示を原則として維持する条項（branding clause）を含む独自ライセンスに変わっています。そして公式自身が、このライセンスを OSI（Open Source Initiative）承認の「オープンソース」ライセンスではないと明記しています。つまり、無料で使えてソースコードも公開されているものの、厳密な意味での OSI 承認オープンソースではない、という位置づけです。なお、v0.6.5 までのコードには branding clause は適用されません。

なぜ「OSI 承認 open source ではない」のか

OSI が認めるオープンソースには、再配布の自由や、特定グループへの差別をしないことなど、満たすべき条件が定められています。branding clause のように「製品名やロゴの表示を一定条件で維持せよ」といった制約が入ると、その条件次第では OSI の定義から外れる。

ここで大事なのは、「OSI 承認ではない＝使ってはいけない」ではないという点です。ソースコードは公開され、多くの用途で無償利用できる状態は変わりません。あくまで「OSS と呼ばれているが、OSI の厳密な定義とは異なるライセンス形態である」という事実を、社内説明の際に正しく伝えられるかどうかが分かれ目になります。法務やセキュリティ部門に「完全な OSI オープンソースです」と説明してしまうと、後から食い違いが発覚しかねません。

業務利用・アクセス課金の条件

では業務で使えないのかというと、そうではありません。チームでの利用や業務システムへの組み込み、社内メンバーへのアクセス課金そのものは禁止されていません。ただし v0.6.6 以降は、原則として Open WebUI の名称・ロゴなどのブランド表示を残すことが条件になります。ブランドを外して自社専用 UI として見せたい場合は、公式が定める例外（小規模な利用、所定の貢献者、enterprise license など）に該当するかを確認する必要があります。具体的な人数・期間といった条件は変更される可能性があるため、公式のライセンス記述で確認してください。

ライセンスの正確な条文や、どのバージョンから何が変わったかは更新される可能性があります。導入の意思決定に関わる部分なので、自己判断で済ませず、必ず公式リポジトリのライセンスファイルを一次ソースとして確認してください。社内導入の稟議では、この一次ソースのリンクを添えておくと話が早い。

機密データを守る構成（外部送信が起きる場面）

ローカル LLM をわざわざ社内に置く動機の多くは、「データを外に出したくない」という一点に集約されます。Open WebUI と Ollama の組み合わせは、その要求に応えやすい構成。ただし「ローカルだから絶対に外部へ出ない」と無条件に思い込むのは危険です。実際には、設定や使う機能次第でプロンプトや検索クエリが外部へ送信される経路が存在します。

既定の状態、つまりローカルの Ollama に置いたモデルだけをチャットで使う構成では、入力したプロンプトも生成された回答も、社内のネットワーク内で完結するのが一般的です。問題は、便利な追加機能を有効にした瞬間に話が変わるという点。

外部送信が起きやすい代表的な経路

データが外部へ流れ得る代表的な経路は、外部モデルプロバイダへの接続と Web 検索です。ただし外部への通信経路はこの2つに限りません。後述するとおり、Tools や各種連携機能を有効にした場合も通信が発生し得ます。まずは分かりやすい2つから押さえます。

ひとつは、外部のモデルプロバイダへの接続。Open WebUI は OpenAI 互換の API を経由して、外部のクラウド LLM にも繋げられる作りになっているのが一般的です。この機能で外部モデルを呼び出すと、当然ながらプロンプトの内容はそのプロバイダのサーバーへ送られます。ローカルモデルと外部モデルを画面上で切り替えて使える利便性の裏返しで、切り替え先が外部なら通信も外部へ向かう。

もうひとつが、Web 検索連携です。Google や Brave、Tavily といった検索サービスと連携させると、ユーザーが入力した質問の一部が検索クエリとして外部の検索エンジンへ送られます。回答の鮮度を上げる便利な機能ですが、検索クエリそのものが社外に出ていく経路になる点は見落とせません。

この2つ以外にも、外部とつながり得る機能があります。Open WebUI には Tools や MCP、OpenAPI 連携といった拡張の仕組みがあり、これらは外部 API の呼び出しや Web スクレイピングなど、設定次第で社外との通信を伴う処理を実行できます。公式ドキュメントも、サーバー上でコードとして動くツールは「できることが広い」ぶん通信経路になり得ると注意を促しています。ほかに外部ストレージや外部の認証・監視基盤と連携する構成も、データの流れ先が増える要因です。「経路は2つだけ」と考えず、有効にした機能ごとに送信先を確認する姿勢が要ります。

機密用途で守るべき構成原則

守秘義務のある情報や、規制で社外持ち出しが制限されるデータを扱うなら、いちばん明確なのは、ローカルモデルのみを使い、外部モデルプロバイダ、Web 検索、Tools / MCP / OpenAPI 連携、外部ストレージなど、社外へ通信し得る機能をすべて無効化することです。これで「完全にローカル完結」させる構成になります。業務上どうしても外部連携が必要な場合は、送信されるデータ・送信先・利用者権限を確認したうえで、対象データを限定して使ってください。「完全に閉じる構成」と「必要な分だけ外部連携を許す構成」を分けて考えると、線引きがはっきりします。

加えて、前の章で触れたアクセス制御も併せて効かせるのが現実的です。誰が外部接続機能を使えるのかを RBAC で絞り、一般ユーザーには外部プロバイダ接続や Web 検索、各種連携機能の設定権限を渡さない。管理者だけが構成を握る形にしておけば、現場の操作ミスで機密プロンプトが外部モデルへ流れる事故を防ぎやすくなります。

もう一点、バックエンドに使う Ollama 側にも目を配る必要があります。Ollama 自体にもクラウドモデルや Web 検索といったオンライン機能があり、これらを使うとプロンプトがクラウドで処理されます。完全にローカル推論へ限定したいなら、Open WebUI 側の機能を絞るだけでなく、Ollama 側でも OLLAMA_NO_CLOUD=1 などでクラウド機能を無効化しておくのが確実です。UI とエンジンの両方で外部送信の口を閉じて、はじめて「ローカル完結」が成り立ちます。

「ローカルだから安全」ではなく、「ローカルモデルに限定し、外部送信機能を閉じているから安全」。この条件付きの理解が、機密用途では欠かせません。各機能が具体的にどこへ何を送るかは実装やバージョンで変わり得るため、本番投入の前に公式ドキュメントで通信経路を確認しておくと安心です。

よくある質問

Q. Open WebUI は無料で使えますか？

無料で入手でき、ソースコードも公開されています。ただし branding clause が付いたため、厳密には OSI 承認のオープンソースとは異なる扱いです。チーム利用や業務利用は条件付きで可能なので、ライセンスの詳細は公式の記述を確認してください。

Q. Ollama がないと動きませんか？

Ollama 専用ではありません。OpenAI 互換の API にも接続できる作りのため、外部のクラウド LLM を画面の裏側に置く使い方も一般的です。ただしローカル完結を狙うなら、Ollama などローカルのモデルに繋ぐ構成が前提になります。

Q. データは外部に送られますか？

ローカルモデルだけを使う既定の構成では、外部に送られないのが一般的です。一方で外部モデルプロバイダ接続や Web 検索、Tools / MCP / OpenAPI 連携などを有効にすると、プロンプトや検索クエリ、連携データが外部へ送信され得ます。機密用途ではこれらの外部通信機能を絞った構成にし、バックエンドの Ollama 側も OLLAMA_NO_CLOUD=1 などでクラウド機能を無効化してください。

Q. 商用利用できますか？

業務利用やアクセス課金そのものは可能です。ただし v0.6.6 以降は原則として Open WebUI のブランド表示を維持する必要があり、外す場合は小規模利用・所定の貢献者・enterprise license などの例外に該当するかを公式ライセンスで確認してください。v0.6.5 までのコードは BSD-3-Clause です。

Q. チームの人数に制限はありますか？

Open WebUI の公式ブランド表示を維持して社内利用する限り、ライセンス上の固定的な人数上限は示されていません。実際の同時利用上限は、サーバー性能や接続するモデルの規模に左右されます。1 台のサーバーに何人がぶら下がれるかは GPU や VRAM 次第で、大人数なら推論用サーバーの増強で対応します。ただし、ブランド表示を外して利用する場合は、30 日間で 50 ユーザー以下などの例外条件、または enterprise license の要否を公式ライセンスで確認してください。

まとめ

Open WebUI が担うのは、Ollama という推論エンジンの前に「複数人で使うための受付と管理画面」を一枚かぶせる役割でした。個人で使うだけなら Ollama の公式アプリでも事足りますが、アカウントと RBAC を備えた共有画面を被せることで、チーム全体が同じ基盤を安全に使えるようになる。ここが raw Ollama API を直接共有する方式との決定的な差です。

導入の道筋は、Docker で Open WebUI を立て、データ永続化ボリュームを設定し、Ollama への接続先は配置構成に応じて OLLAMA_BASE_URL で調整する、という流れに整理できます。その上で、アカウントと RBAC を使ってメンバーと権限を管理すれば、認証のない API をそのまま共有するより安全にチーム運用へ持ち込めます。

導入前に必ず押さえたいのが2つ。ひとつは、branding clause により厳密な OSI オープンソースではないというライセンスの実態。もうひとつは、外部プロバイダ接続や Web 検索、Tools / MCP などの連携機能を有効にすると「ローカル完結」が崩れるというセキュリティの条件です。この2点を社内に正しく共有できれば、Open WebUI はチームでローカル LLM を安全に共有する現実的な選択肢になります。まずは検証用に 1 台、Docker で小さく立ち上げるところから始めてみてください。

種別

ローカル LLM 向けブラウザ UI（Web フロントエンド）

提供形態

無料・ソースコード公開（branding clause により厳密な OSI 承認オープンソースではない）

主な導入方法

Docker コンテナでの起動が一般的

接続先指定

配置構成しだい。Docker 構成や別サーバーでは OLLAMA_BASE_URL の指定が要る場合あり

データの既定動作

ローカルモデルのみを使い外部連携を無効化した構成では外部送信を避けられる。外部プロバイダ接続・Web 検索・Tools / MCP 連携などを使うと、設定に応じて外部送信が発生し得る

参考資料

• Open WebUI 公式: GitHub リポジトリ（README・ライセンス）
• Open WebUI 公式: ドキュメント
• Open WebUI 公式: ライセンス解説（branding clause・業務利用）
• Ollama 公式サイト
• Ollama 公式: GitHub リポジトリ
• Docker 公式: ドキュメント