---
title: "Open WebUIとは｜使い方・インストール・APIキー発行をv0.12.0で実測解説"
url: "https://www.issoh.co.jp/tech/details/4607/"
published: 2024-12-23
updated: 2026-10-13
categories: ["LLM・RAG"]
publisher: "株式会社一創"
---

# Open WebUIとは｜使い方・インストール・APIキー発行をv0.12.0で実測解説

Open WebUIは、OllamaやOpenAI互換APIにつないで使う、自分のサーバーで動かすAIチャット画面です。本記事では2026年10月10日公開のv0.12.0をDockerで実際に起動し、インストール、日本語化、APIキーの有効化と発行、curlとPythonからの呼び出しまでを確かめた結果をもとに解説します。公式ドキュメントどおりに書いても動かない箇所（`/v1`で始まるURL、エンドポイント制限の書き方）も、実測した応答コードと合わせて示します。

## まとめ：Open WebUIの要点と導入判断

- 本体は無料。最短はDockerの1コマンドで、ブラウザの`http://localhost:3000`から使い始められる。最新版はv0.12.0（2026年10月10日）。
- モデルは内蔵しない。ローカルLLMはOllama、クラウドはOpenAI互換APIを「接続」に登録して使う。
- APIキーは既定で無効。管理者が有効化してから、各ユーザーがSettings → Accountで`sk-`で始まるキーを発行する。
- APIのベースURLは`/api`。`/v1`を指定するとHTMLや405が返り、OpenAIのSDKは失敗する（v0.12.0で実測）。
- ライセンスはBSD-3にブランディング保持義務を加えた独自ライセンス。任意の連続30日間の利用者が50人を超える場合、ロゴや名称の変更・削除には、著作権者の事前の個別書面許可か、それを認めるEnterpriseライセンスが必要。

APIだけを使うなら、展開後のサイズが標準版の約7分の1になるslimイメージで足ります。以下、仕組み、導入、初期設定、API、ライセンスの順に解説します。

## Open WebUIとは｜読み方・料金・できること

Open WebUI（オープン・ウェブ・ユーアイ）は、公式ドキュメントで「拡張性が高く、機能豊富で使いやすい、完全オフライン動作を前提とした自己ホスト型AIプラットフォーム」と説明されています。ソースコードは公開されていますが、現行ライセンスはOSI承認のオープンソースライセンスではありません。ChatGPTに近い画面を、自社のサーバーやPCの中だけで動かせます。アップロードした文書本体は既定でローカルファイルとして保存され、チャット履歴と文書のメタデータは手元のデータベース（既定はSQLite、`DATABASE_URL`でPostgreSQLに切替可）に保存されます。

Open WebUI本体は無料ですが、接続先のクラウドAPIやサーバーの利用料金は別途かかる場合があります。ブランドの差し替え（ホワイトラベル）や専任サポートを含むEnterpriseライセンスは有償で、[公式のEnterpriseページ](https://docs.openwebui.com/enterprise/)には価格表がなく、想定する利用者数（seats）を添えて営業窓口に問い合わせる方式です。開発は活発で、[GitHubのリリース一覧](https://github.com/open-webui/open-webui/releases)では2026年7月27日のv0.11.0から10月10日のv0.12.0までに6版が出ています。

### 主な機能｜チャット・RAG・Web検索・権限管理・MCP

中心は、複数モデルを切り替えるチャット、アップロード文書やナレッジを参照させるRAG、回答前に検索するWeb検索、グループ単位で使えるモデルや機能を絞る権限管理（RBAC）の4つです。画像生成エンジンとの連携、MCPツールの接続、FunctionsやPipelinesによる独自処理の差し込みは、運用が固まってから足す発展機能です。同じチャット内でモデルを切り替えると会話の文脈も引き継がれます。機密情報を扱うチャットはクラウドモデルへ切り替えず、補助タスクや外部ツールの送信先もローカルに限定してください。

### v0.12.0の主な変更点｜2段階認証・リアルタイム音声・モデル編集画面

[v0.12.0のリリースノート](https://github.com/open-webui/open-webui/releases/tag/v0.12.0)は追加52項目、修正243項目の大型更新です。社内導入で効くのは次の3つです。

- 2段階認証：管理者がAdmin Settings → Authenticationか`ENABLE_MFA`で全員に認証アプリを必須にできる。紛失時は`open-webui mfa reset`で復旧用トークンを発行する。
- リアルタイム音声通話：音声モードの通話方式をRealtimeに切り替えると、OpenAIのRealtime音声モデル（既定はgpt-realtime-2.1-mini）が雑談を受け持ち、本題はチャットで選んだモデルに渡す。
- モデル編集画面の作り直しと、モデル・ツール・関数の版履歴：保存のたびに版が残り、以前の版との比較や差し戻しができる。

画面構成が大きく変わったため、v0.11系の画面で作った社内手順書は更新が必要です。

## OllamaとOpenAI互換APIの接続先｜構成と設定項目

Open WebUIはモデルを内蔵しない「フロント」で、回答を作るエンジンは別に用意して管理者設定の「接続」（Settings → Admin → Connections）から登録します。接続先は2系統です。

### Ollama接続｜Dockerからホストへの接続先設定

Ollamaは、Llama・Gemma・Qwenなどのオープンモデルを手元で動かす基盤で、既定では`http://localhost:11434`でAPIを待ち受けます。Open WebUIをDockerで、OllamaをホストOSで動かす場合、コンテナから見た宛先は`http://host.docker.internal:11434`です。起動時に固定するなら環境変数`OLLAMA_BASE_URL`で渡します。Ollamaで取得済み（`ollama pull`済み）のモデルは、モデル選択欄に自動で並びます。

### OpenAI互換API接続｜クラウド・自前推論サーバーの登録

もう1系統は、OpenAI互換のエンドポイントを持つ相手です。管理者設定の「接続」→「OpenAI」にベースURLとAPIキーを入れると、OpenAI本家のほか、[vLLM](/tech/details/15786/)やllama.cppのサーバーモードも同じ枠で追加できます。公式のQuick StartにはAnthropic、vLLM、llama.cppそれぞれの接続手順ページがあります。

## Open WebUIのインストール｜Docker・Compose・pip・uv

公式に用意された導入経路はDocker、Python（pip・uv）、Kubernetesです。まず試すならDockerが最短です。コマンドは[公式Quick Start](https://docs.openwebui.com/getting-started/quick-start/)に沿っています。

### Dockerで起動する｜1コマンドとイメージタグの選び方

```
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
```

`your-secret-key`は`openssl rand -hex 32`の出力に置き換えます。この鍵を固定しないと、コンテナを作り直すたびに全員がログアウトされます。`-v`のボリュームには履歴・ユーザー・設定が入るので、外さないでください。起動後は`http://localhost:3000`を開きます。

本番では`:main`を避け、`:v0.12.0`のような版タグに固定するのが安全です。公式の説明では`:main`と`:latest`はmainブランチに変更が入るたびに作り直される同じイメージで、最新の安定版を指すものではありません。NVIDIA GPUを使うなら`:cuda`に`--gpus all`を付け、Ollamaを同じコンテナに入れたいなら`:ollama`を選びます。

### Docker Compose構成｜OllamaとOpen WebUIの同時起動

```
services:
  ollama:
    image: ollama/ollama
    volumes:
      - ollama:/root/.ollama
    restart: unless-stopped

  open-webui:
    image: ghcr.io/open-webui/open-webui:v0.12.0
    ports:
      - "3000:8080"
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
      - WEBUI_SECRET_KEY=${WEBUI_SECRET_KEY}
    volumes:
      - open-webui:/app/backend/data
    depends_on:
      - ollama
    restart: unless-stopped

volumes:
  ollama:
  open-webui:
```

`WEBUI_SECRET_KEY`は同じディレクトリの`.env`に書けば`docker compose up -d`で読み込まれます。モデルの取得は`docker compose exec ollama ollama pull llama3.1`のようにOllama側のコンテナで実行します。

### pipとuvで導入する｜Python 3.11・3.12限定

```
pip install open-webui
open-webui serve
```

pip版は`http://localhost:8080`で立ち上がります。v0.12.0の`pyproject.toml`は`requires-python = ">= 3.11, < 3.13.0a1"`で、Python 3.13以降には入りません。uvなら`DATA_DIR=~/.open-webui uvx --python 3.11 open-webui@latest serve`です。`DATA_DIR`を省くと、データがuvのキャッシュ内に置かれ、キャッシュ削除で消えます。NVIDIA GPUの無いLinuxでは、先に`pip install torch --index-url https://download.pytorch.org/whl/cpu`でCPU版PyTorchを入れておくと、CUDAライブラリの取得を避けられます。

### 標準イメージとslimの違い｜サイズ・起動時間・メモリの実測

v0.12.0の時点で、文書の埋め込みや音声認識のモデルを省いた`:slim`イメージが用意されています。両方を同じ環境（colima上のDocker、4vCPU・メモリ5.78GiBのx86\_64 VM）で初回起動し、`/health`が応答するまでの時間と、起動後の待機時のメモリ（`docker stats`）を各1回測りました。

| 項目          | :v0.12.0（標準） | :v0.12.0-slim |
| ----------- | ------------ | ------------- |
| 展開後のイメージサイズ | 6.37GB       | 872MB         |
| 初回起動から応答まで  | 101秒         | 27秒           |
| 待機時のメモリ     | 1.20GiB      | 292MiB        |
| 初回起動後のデータ領域 | 1.1GB        | 804KB         |

標準版のデータ領域が1.1GBになるのは、初回起動時に埋め込みモデル（923MB）と音声認識モデル（142MB）がボリュームへ置かれるためです。2回目以降の起動は35秒でした。slimでも、チャットとAPI、テキスト系ファイルの読み込みは動きます。PDFやOffice文書の抽出、RAGの埋め込み、音声入力には外部サービスが必要です。RAGにはさらにpgvectorを有効にしたPostgreSQLが必要で、VECTOR\_DB=pgvectorとPGVECTOR\_DB\_URLを設定します。抽出・埋め込み・検索の設定不足では503になる場合があり、音声入力のローカルWhisperは選択できないと[Quick Startの説明](https://docs.openwebui.com/getting-started/quick-start/)にあります。クラウドAPIのフロントとして使うならslim、文書検索まで1コンテナで完結させたいなら標準版、という分け方で迷いません。

## 初期設定の使い方｜管理者作成・日本語化・モデル追加

### 初回アカウント登録｜管理者の作成と新規登録の自動停止

初回アクセスで登録したアカウントが管理者になります。v0.12.0で試すと、最初の登録が終わった時点で管理者設定の`ENABLE_SIGNUP`が自動で`false`に切り替わり、2人目以降は管理者がユーザー追加画面から作る形になりました。ソース（`routers/auths.py`）でも、利用者が1人になった直後にこの設定を落とす処理が入っています。社内で自己登録を許すなら、管理者設定から登録を開け直し、既定の役割（`pending`＝承認待ち）のまま管理者が承認する運用にします。

### 日本語化｜Settings → General → Language

画面右上のアカウントメニューからSettings → General → Languageで「Japanese (日本語)」を選ぶと、表示が日本語に切り替わります。v0.12.0の言語定義ファイルには64言語が登録され、日本語のコードは`ja-JP`です。全員の既定を日本語にしたい場合は、起動時に環境変数`DEFAULT_LOCALE=ja-JP`を渡します。ただし[環境変数リファレンス](https://docs.openwebui.com/reference/env-configuration/)のとおり、各ユーザーが選んだ言語のほうが優先されます。

### モデルの追加と既定モデルの指定

Ollamaで取得済みのモデルと、「接続」に登録したプロバイダのモデルが選択欄に並びます。v0.12.0からはグループごとに既定モデルを決められるので、部署ごとに新規チャットの初期選択モデルを変えられます。利用できるモデル自体を制限するには、別途モデルのアクセス権を設定します。

## Open WebUIのAPIキー発行手順｜有効化からキー生成まで

Open WebUIは自身がOpenAI互換のAPIサーバーとしても動くので、既存のOpenAI向けクライアントの向け先を変えるだけで使えます。ただしAPIキーは既定で無効です。手順は[公式のAPI Keysページ](https://docs.openwebui.com/features/authentication-access/api-keys)に沿っています。

### APIキーの管理者設定｜機能の有効化とユーザー権限

有効化前にキーを作ろうとすると、v0.12.0では403と`API key creation is not allowed in the environment.`が返りました。管理者がSettings → Admin → Authenticationで「API Keys」をオンにします（環境変数なら`ENABLE_API_KEYS=true`）。管理者以外のユーザーは、有効化後も同じ403になります。グループの機能権限（Features Permissions）で「API Keys」を許可するか、`USER_PERMISSIONS_FEATURES_API_KEYS=true`で既定権限として与えてください。

### ユーザーがAPIキーを発行する｜Settings → Account

アカウントメニューのSettings → AccountにあるAPI keysの欄で「Create new secret key」を押すと生成されます。実測では`sk-`で始まる35文字でした。1アカウントが持てるキーは1本だけで、作り直すと古いキーは即座に401になります。有効期限はなく、作成者の権限をそのまま引き継ぐので、外部連携には権限を絞った専用ユーザーを作ってそのユーザーで発行します。キーは`Authorization: Bearer`のほか、`x-api-key`ヘッダーでも受け付けました（ヘッダー名は`CUSTOM_API_KEY_HEADER`で変更可）。

## Open WebUI APIの呼び出し方｜curl・Python SDK・ファイルAPI

以下はDocker版（ポート3000）の例です。pip版なら8080に読み替えます。Python例を実行する環境には、事前に`pip install openai`でSDKを入れておきます（検証時は2.48.0）。エンドポイントの一覧は[公式のAPI Endpointsリファレンス](https://docs.openwebui.com/reference/api-endpoints)にあります。

### curlで疎通確認する｜モデル一覧とチャット補完

```
export OPENWEBUI_API_KEY="sk-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

# モデル一覧（ここで返る id を model に指定する）
curl -H "Authorization: Bearer $OPENWEBUI_API_KEY" \
  http://localhost:3000/api/models

# チャット補完
curl -X POST http://localhost:3000/api/chat/completions \
  -H "Authorization: Bearer $OPENWEBUI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"llama3.1","messages":[{"role":"user","content":"hello"}]}'
```

どちらもOpenAIの標準形式で応答します。互換用に`/api/v1/models`と`/api/v1/chat/completions`も同じ処理に入ります。v0.8.4からは、Anthropic Messages API形式で受ける`/api/v1/messages`も追加されており、v0.12.0で`x-api-key`ヘッダー付きで送るとAnthropic形式の応答が返りました。

### PythonのOpenAI SDKから呼ぶ｜base\_urlは/apiまで

```
import os
from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:3000/api",
    api_key=os.environ["OPENWEBUI_API_KEY"],
)

res = client.chat.completions.create(
    model="llama3.1",
    messages=[{"role": "user", "content": "Open WebUIの特徴を3行で"}],
)
print(res.choices[0].message.content)
```

OpenAIのSDKは`base_url`の後ろに`/chat/completions`を付けて送るので、`/api`か`/api/v1`までを渡します。Open WebUIを経由させると、ユーザーごとの権限やモデル制限がAPIにもそのまま効きます。Ollama単体のAPIをPythonから呼ぶ例は[Ollama Web Searchの使い方](/tech/details/9059/)で扱っています。

### RAG用のファイルAPI｜文書をアップロードして根拠に指定

```
# 1. ファイルをアップロード（応答JSONの id を控える）
curl -X POST -H "Authorization: Bearer $OPENWEBUI_API_KEY" \
  -H "Accept: application/json" \
  -F "file=@./manual.pdf" http://localhost:3000/api/v1/files/

# 2. 処理状況を確認（completed になるまで待つ）
curl -H "Authorization: Bearer $OPENWEBUI_API_KEY" \
  http://localhost:3000/api/v1/files/YOUR_FILE_ID/process/status

# 3. そのファイルを根拠にチャット補完
curl -X POST http://localhost:3000/api/chat/completions \
  -H "Authorization: Bearer $OPENWEBUI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"llama3.1",
       "messages":[{"role":"user","content":"返品の条件を要約して"}],
       "files":[{"type":"file","id":"YOUR_FILE_ID"}]}'
```

抽出と埋め込みは非同期で進むので、2の応答が`{"status":"completed"}`になってから3を送ります。既存のナレッジに足すなら`POST /api/v1/knowledge/{id}/file/add`に`{"file_id": "..."}`を送ります。画面からのファイル添付とRAGチャットの組み方は[OllamaとOpen WebUIでファイルをアップロードしRAGチャットを実現する方法](/tech/details/2381/)で手順を追っています。

## APIで詰まる3つの落とし穴｜v0.12.0で実測した挙動

ここからは公式ドキュメントに明記が無い、または例の書き方どおりだと失敗する挙動です。v0.12.0のコンテナに、固定文を返すOpenAI互換の検証用サーバーを上流モデルとしてつなぎ、各URLへの応答を確かめました。

### /v1で始まるAPI接続先｜HTML応答と405エラー

| リクエスト                         | 応答           |
| ----------------------------- | ------------ |
| GET /api/models               | 200（JSON）    |
| GET /api/v1/models            | 200（JSON）    |
| GET /v1/models                | 200（画面のHTML） |
| POST /api/chat/completions    | 200（JSON）    |
| POST /api/v1/chat/completions | 200（JSON）    |
| POST /v1/chat/completions     | 405          |

`/v1/models`は404にならず、ブラウザ向けの画面のHTMLが200で返ります。OpenAI Python SDK 2.48.0で`base_url`を`http://localhost:3000/v1`にすると、チャットは`APIStatusError`（405）、モデル一覧はJSONでない応答を解釈できず`AttributeError`で落ちました。ほかのOpenAI互換サーバーの感覚で`/v1`を付けた場合、エラー内容からは原因が分かりにくいので、まず`base_url`が`/api`で終わっているかを確かめてください。

### エンドポイント制限｜許可パスとの完全一致・配下判定

管理者設定の「API Key Endpoint Restrictions」で許可パスを`/api/models,/api/chat/completions`にすると、`/api/v1/models`と`/api/v1/chat/completions`は403になりました。同じ処理に入るURLでも、許可リストの文字列と一致しないと通りません。照合は「完全一致、または許可パスの配下」で、`utils/auth.py`のソースもこの条件です。公式のAPI Keysページでも、設定手順の例は`/api/v1/...`、運用の推奨例は`/api/...`と節によって書き方が分かれているので、クライアントが実際に呼ぶパスに合わせて書きます。制限はキーごとではなくインスタンス全体に効くため、全連携先が使うパスの和集合を並べることになります。

### files付きAPIの実測｜検索語生成を含む2回の上流呼び出し

ファイルを指定してチャット補完を1回呼ぶと、上流の検証用サーバーには2回リクエストが届きました。1回目は検索語を作るための依頼（”Analyze the chat history to determine the necessity of generating search queries”で始まるプロンプト）、2回目が文書の抜粋を添えた回答の依頼です。従量課金のAPIを上流にしていると、その分だけトークン消費が増えます。検索語の生成は`ENABLE_RETRIEVAL_QUERY_GENERATION`（既定`true`）で止められ、止めずに軽いモデルへ回すなら`TASK_MODEL`（外部接続のモデルなら`TASK_MODEL_EXTERNAL`）で指定します。

## Web検索の設定手順｜有効化とバックエンドの選び方

Web検索は既定で無効です（`ENABLE_WEB_SEARCH`の既定は`false`）。管理者設定のWeb検索で機能をオンにし、検索バックエンドを選んでAPIキーやURLを入れます。v0.12.0のソースにはSearXNG、Google PSE、Brave、Tavily、Exa、Ollamaなど30種類以上の実装があり、設定値は[公式のWeb検索ドキュメント](https://docs.openwebui.com/features/chat-conversations/web-search)にプロバイダ別のページがあります。OllamaのWeb検索APIをバックエンドにする設定は[Ollama Web Searchの使い方](/tech/details/9059/)で解説しています。

## 外部ツール連携と文書同期｜MCP・oikb

MCPは[公式ドキュメント](https://docs.openwebui.com/features/extensibility/mcp)によればv0.6.31以降でネイティブに対応し、トランスポートはStreamable HTTPのみです。stdioやSSEで動くMCPサーバーは、OpenAPI互換に変換するプロキシのmcpoを挟みます。MCPサーバーはつないだユーザーの権限で動くため、追加できるのは管理者だけです。MCPの仕組みは[MCP（Model Context Protocol）とは？AIと外部ツールをつなぐ標準規格の仕組みをわかりやすく解説](/tech/details/5736/)が入口になります。

社内文書をナレッジへ自動で同期したいなら、公式の[oikb](https://github.com/open-webui/oikb)（MIT、Open WebUI 0.9.6以上が必要）が使えます。ローカルのディレクトリやGitHub、Confluence、S3などから、変更のあったファイルだけをAPIキー経由で送るCLIです。内部では`/api/v1/files`と`/api/v1/knowledge`を呼ぶので、エンドポイント制限をかけているなら、この2つを許可リストに足します。

## Open WebUIのライセンス｜50ユーザー条件とブランディング保持

[公式のライセンスページ](https://docs.openwebui.com/license)によれば、2025年4月19日のv0.6.6から、BSD-3-Clauseにブランディング保護条項を加えた「Open WebUI License」に変わりました。公式自身がOSI承認のオープンソースではないと明記しており、「MITライセンス」と書いた解説は誤りです。

v0.12.0のLICENSEファイルの第4項では、UI上の「Open WebUI」の名称・ロゴの変更や削除を禁じ、例外を3つに限っています。直近30日間（rolling thirty day period）の利用者が50人以下、著作権者から書面の許可を得た、ブランド変更を認めるEnterpriseライセンスを結んだ、のいずれかです。50人以下の社内利用ならロゴ差し替えも自由です。それを超える規模でブランドを隠して自社製品として提供するなら、書面許可かEnterpriseライセンスのどちらかを先に得ておく必要があります。

## Open WebUIを採用すべきでない場面｜代替UIとの選び分け

推論速度の問題はUIを替えても解決しないので、そこはモデルとハードウェアの側で手当てします。UIの選定で見るべきなのは、ブランド条件と保守体制が自社に合うかです。次に当てはまるなら、別のUIや運用形態を先に検討します。

- 50人を超える利用者に自社ブランドだけで提供したい：ブランディングを外すには、著作権者の事前の個別書面許可か、変更を認めるEnterpriseライセンスが必要。MITライセンスの[LibreChat](/tech/details/17653/)やAnythingLLMのほうが摩擦が少ない。
- セキュリティ更新の判断や定期バックアップに人手を割けない：v0.12.0のように画面全体が変わる更新もあり、有効期限の無いAPIキーの棚卸しも自分の責任になる。
- GPUが無く、CPUだけで大型モデルを動かすつもりでいる：UIを入れても速度は変わらない。軽量モデルに割り切るか、クラウドAPIを接続する前提で計画する。

逆に、データを手元に置きたい、複数モデルを1画面で使い分けたい、社内ツールからOpenAI互換APIで呼びたい、という要件がはっきりしているなら有力です。社内向けチャットの要件整理や既存システムとの連携まで含めて検討する場合は、[一創のAIチャットボット開発](/service/ai/chatbot/)で構成の比較から相談を受け付けています。ローカルLLMそのものの前提は[ローカルLLMとは？クラウド型との違い・必要スペック・Ollamaでの構築手順を解説](/column/details/12964/)で整理しています。

## よくある質問

### Open WebUIとは何で、どう読みますか？

Open WebUI（オープン・ウェブ・ユーアイ）は、OllamaやOpenAI互換APIに接続して使う、自己ホスト型のAIチャット画面です。ChatGPTに似た画面を自分のサーバーやPCで動かせます。2026年10月時点の最新版はv0.12.0（10月10日公開）です。

### Open WebUIはいくらですか？無料で使えますか？

本体は無料です。接続先のクラウドAPIやサーバーの費用は別にかかります。有償のEnterpriseライセンス（ホワイトラベルや専任サポートを含む）は価格が公開されておらず、利用者数を伝えて問い合わせる方式です。ただし任意の連続30日間の利用者が50人を超える場合、ロゴや名称の変更・削除には、著作権者の事前の個別書面許可か、変更を認めるEnterpriseライセンスが必要です。

### Open WebUIを日本語化するにはどうすればいいですか？

Settings → General → Languageで「Japanese (日本語)」を選びます。全ユーザーの既定を日本語にするなら、起動時に`DEFAULT_LOCALE=ja-JP`を渡します。各ユーザーが選んだ言語はこの既定より優先されます。

### Open WebUIのAPIキーはどこで発行しますか？

管理者がSettings → Admin → Authenticationで「API Keys」を有効にしたあと、各ユーザーがSettings → AccountのAPI keys欄で「Create new secret key」を押します。管理者以外が発行できないときは、グループの機能権限でAPI Keysが許可されているかを確認してください。

### Open WebUIのAPIでチャットを呼ぶURLは何ですか？

`POST /api/chat/completions`です。モデル一覧は`GET /api/models`です。OpenAIのPython SDKなら`base_url`に`http://localhost:3000/api`を指定します。`/v1/chat/completions`（`/api`なし）は405になります。

## 関連記事

- [OllamaとOpen WebUIでファイルをアップロードしRAGチャットを実現する方法](/tech/details/2381/)
- [LibreChatとは？Docker構築手順と社内AIチャット基盤の採用判断](/tech/details/17653/)
- [Ollama Web Searchの使い方｜APIキー設定・料金・Python実装【2026年9月】](/tech/details/9059/)
- [ローカルLLMとは？クラウド型との違い・必要スペック・Ollamaでの構築手順を解説](/column/details/12964/)
- [vLLMとは？PagedAttentionの仕組み・使い方とOllama・TensorRT-LLMとの違いを実装者目線で解説](/tech/details/15786/)

---

出典: [Open WebUIとは｜使い方・インストール・APIキー発行をv0.12.0で実測解説](<https://www.issoh.co.jp/tech/details/4607/>)（株式会社一創）