📋 FAQ

Sponsored by n8n

Does your interface have a backend yet? Try n8n

💡 なぜDockerを使用するのか？

Dockerがすべての人にとって好ましい選択肢ではないことを理解していますが、このアプローチはプロジェクトの設計や運用効率の中心です。私たちは、本プロジェクトのDockerへの取り組みを基本的な側面と位置付けており、他のデプロイ方法を探している方々にはコミュニティ主導の代替手段を探求することを推奨します。

Q: ロゴやブランディングをどうカスタマイズするのですか？

A: テーマ、ロゴ、ブランディングをカスタマイズするには、企業専用機能を利用できる**Enterprise License**をご利用ください。

企業向けソリューションやブランディングのカスタマイズについて詳しくは、営業チームまでお問い合わせください: 📧 [email protected]

Q: なぜ登録が必要ですか？私のデータはどこに送信されていますか？

A: セキュリティ向上のため、管理者ユーザーとして登録が必要です。これにより、Open WebUIが外部アクセスにさらされた場合でも、データの安全が確保されます。重要なのは、すべてがローカルに保持されることです。私たちはあなたのデータを収集しません。登録時にすべての情報はサーバー内に保存され、デバイスを離れることはありません。あなたのプライバシーとセキュリティが最優先であり、データを常にあなたの管理下に置いています。

Q: Dockerコンテナがホスト上のサービスにlocalhostで接続できないのはなぜですか？

A: Dockerコンテナ内では、localhostはホストマシンではなくコンテナ自身を指します。この違いはネットワーキングにおいて重要です。ホストで動作しているサービスへコンテナから接続を確立するには、localhostの代わりにDNS名host.docker.internalを使用すべきです。このDNS名はDockerによって特別に認識され、このような接続を容易にします。これによりホストをコンテナ内から到達可能なエンティティとして扱い、通常のlocalhostの範囲制限を回避します。

Q: ホストのサービスをDockerコンテナにアクセス可能にするにはどうすればよいですか？

A: ホスト上で動作するサービスをDockerコンテナがアクセス可能にするには、それらのサービスを全ネットワークインターフェースでリスンするように設定し、localhostのみを対象とする127.0.0.1ではなく、IPアドレス0.0.0.0を使用してください。この設定により、サービスは任意のIPアドレスからの接続を受け入れることが可能となり、Dockerコンテナも含まれます。この設定を行う際、特に外部アクセスの可能性がある環境で操作する場合には、安全性への影響を理解しておくことが重要です。ファイアウォールや認証などの適切なセキュリティ対策を導入することでリスクを軽減できます。

Q: Open WebUIが更新されません。コンテナを再度プル/再起動しましたが、何も変わりません。

A: Open WebUIの更新には新しいDockerイメージをプルするだけでは不十分です。更新が反映されない理由と反映させる方法は以下の通りです:

1. Dockerイメージの更新: コマンドdocker pull ghcr.io/open-webui/open-webui:mainはDockerイメージを更新しますが、実行中のコンテナやそのデータは更新しません。
2. Dockerボリューム内の永続データ: Dockerボリュームはコンテナのライフサイクルとは独立してデータを保存し、更新時にもデータ（例: チャット履歴）が維持されます。
3. 更新の適用: 既存のコンテナを削除し（ボリュームは削除されない）、更新されたイメージを使用して既存のボリュームをアタッチした新しいコンテナを作成することで、更新を反映させます。

このプロセスにより、アプリケーションが更新されてもデータは安全です。

Q: コンテナを削除するのはなぜですか？データを失うのではないですか？

A: コンテナを削除するとデータを失うのではないかという懸念はよくありますが、Dockerボリュームを正しく使用していればデータが失われる心配はありません。以下の理由をご覧ください:

• ボリュームはデータを保持します: Dockerボリュームはコンテナのライフサイクル外でデータを永続化するよう設計されています。データがボリュームに保存されている限り、コンテナに何が起きてもデータは安全です。
• 安全な更新プロセス: Open WebUIを更新する際、古いコンテナを削除しても、データがボリュームに保存されている限り影響を受けません。重要なのは、docker volume rmなどのコマンドでボリュームを明示的に削除しないことです。

正しい更新手順（新しいイメージをプル、ボリュームを削除せずに古いコンテナを削除し、更新イメージと既存のボリュームで新しいコンテナを作成）に従うことで、アプリケーションコードが更新されてもデータは変更されず安全です。

Q: ディストリビューション提供のDockerと公式Dockerパッケージのどちらを使うべきですか？

A: Open WebUI を実行する際には、ディストリビューションに付属の Docker バージョンではなく、公式の Docker パッケージの使用を推奨します。公式の Docker パッケージは、最新機能、バグ修正、セキュリティパッチが頻繁に更新され、最適なパフォーマンスとセキュリティが保証されます。また、host.docker.internal のような重要な機能をサポートしており、ディストリビューションに付属のバージョンでは利用できない場合があります。この機能は、Docker コンテナ内での適切なネットワーク設定と接続に不可欠です。

公式 Docker パッケージを選択することで、さまざまな環境で一貫した動作が得られ、トラブルシューティングの信頼性が向上し、Docker の最新技術へのアクセスが可能となります。さらに、より広範な Docker コミュニティとリソースが公式パッケージと一致しているため、遭遇する可能性のある問題に関する豊富な情報とサポートを利用できます。

Open WebUI を実行するために必要なものはすべて、データを含めてあなたの管理下およびサーバー環境内に留まり、プライバシーとセキュリティへの取り組みを強調しています。公式 Docker パッケージのインストール手順については、Docker の公式ドキュメントサイトの Docker エンジンのインストール ガイドを参照してください。

Q: Docker で GPU サポートは利用可能ですか?

A: Docker での GPU サポートは、プラットフォームによって異なります。公式には、Windows 用 Docker と Linux 用 Docker エンジンでは GPU サポートが提供されていますが、Linux 用 Docker Desktop や MacOS では現在 GPU サポートが提供されていません。この制限は、GPU アクセラレーションを必要とするアプリケーションを利用する場合に重要です。最良の体験を得るために、公式に GPU 統合をサポートしているプラットフォームで Docker を使用することをお勧めします。

Q: Open WebUI が Docker の使用を推奨する理由は何ですか?

A: Docker を使用する決定は、一貫性、依存関係の分離、および異なる環境でのデプロイの簡素化を確保する能力に基づいています。Docker は互換性の問題を最小限に抑え、基盤となるシステムに関係なく WebUI を迅速に機能させるプロセスを合理化します。この利点を活用するために、プロジェクトの管理者が採用した戦略的な選択です。Docker に学習曲線があることは理解していますが、デプロイとメンテナンスにおける利点は非常に大きいです。我々は Docker がすべての人に好まれるわけではないことを理解していますが、このアプローチはプロジェクトの設計と運用効率の中心にあります。異なるデプロイ方法を探している方には、コミュニティ主導の代替手段を探索することをお勧めします。

Q: デプロイで Speech-to-Text (STT) と Text-to-Speech (TTS) が機能しないのはなぜですか?

A: デプロイ内で Speech-to-Text (STT) および Text-to-Speech (TTS) サービスを正常に機能させるには、HTTPS が必要な場合があります。現代のブラウザはセキュリティ対策を施しており、STT および TTS などの特定の機能が安全な HTTPS 接続でのみ動作するように制限しています。デプロイが HTTPS を使用するように設定されていない場合、これらのサービスが期待通りに機能しない可能性があります。デプロイを HTTPS 経由でアクセス可能にすることで、これらの問題を解決し、STT/TTS 機能を完全に利用できるようになります。

Q: なぜ Open WebUI は組み込みの HTTPS サポートを含まないのですか?

A: HTTPS サポートを含むオールインワンソリューションの要望を理解していますが、そのようなアプローチではユーザー基盤の多様なニーズを十分に満たせない可能性があります。プロジェクト内で HTTPS を直接実装することは柔軟性を制限し、すべてのユーザーの特定の要件や好みに一致しない可能性があります。ユーザーが独自の環境に応じた設定を調整できるようにするため、HTTPS 処理の導入を本番デプロイにおいてユーザー側に委ねています。この決定により、より大きな適応性とカスタマイズ性が実現します。我々は HTTPS 設定に関する公式ドキュメントを提供していませんが、コミュニティメンバーが経験に基づいた洞察や提案を共有することでガイドを提供する場合があります。

Q: 更新/再起動/新しいソフトウェアをインストールした後に Open WebUI が動作しなくなりました！

A: 更新や新しいソフトウェアのインストール後に Open WebUI が起動しない場合、特にバックエンド依存関係用の仮想環境を使用していない場合、直接インストール方法が原因である可能性があります。直接インストールは、環境の変更（更新や新しいインストールによる既存の依存関係の変更など）に敏感です。このような問題を回避し、安定性を確保するためには、バックエンドの requirements.txt 依存関係管理に仮想環境を使用することをお勧めします。これにより、Open WebUI の依存関係を他のシステムパッケージから分離し、このような問題のリスクを最小限に抑えることができます。

Q: 更新/再起動後にログインができなくなり、新しいアカウントを作成したが、チャット履歴がすべて消えてしまった。

A: この問題は、Dockerコンテナが/app/backend/dataへのボリュームをマウントせずに作成された場合、または指定されたOpen WebUIのボリューム（例では通常open-webuiと名前付けされています）が意図せず削除された場合によく発生します。Dockerボリュームは、コンテナのライフサイクルを超えてデータを保持する上で重要です。再起動後に新しいアカウントを作成する必要がある場合、既存のデータが格納されているボリュームを接続せずに新しいコンテナを起動した可能性があります。データを失わないようにするため、Dockerの実行コマンドに正しいデータの場所を指すボリュームマウントを必ず含めてください。

Q: ログインができず、新しいアカウントを作成したら、管理者によるアカウントの有効化が必要と言われました。

A: この状況は、最初のセットアップ時に作成された初期管理者アカウントのパスワードを忘れた場合に発生します。最初のアカウントは自動的に管理者アカウントとして指定されます。管理者アカウントにアクセスできない状態で新しいアカウントを作成すると、管理者による有効化が必要になります。最初の管理者アカウントの資格情報の紛失は避けるようにしてください。管理者アカウントを回復する手順については、管理者パスワードリセットガイドを参照してください。

Q: Open WebUIがSSLエラーで起動できません。なぜですか？

A: Open WebUIを起動する際に発生するSSLエラーは、SSL証明書の欠如やHuggingFace.coの設定ミスによるものと思われます。この問題を解決するには、hf-mirror.comのようなHuggingFaceのミラーを設定し、Dockerコンテナを起動する際にそれをエンドポイントとして指定します。-e HF_ENDPOINT=https://hf-mirror.com/というパラメータを使用して、Dockerの実行コマンド内でHuggingFaceミラーアドレスを定義します。例えば、以下のようにDockerの実行コマンドを変更できます：

docker run -d -p 3000:8080 -e HF_ENDPOINT=https://hf-mirror.com/ --add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main

Q: Open WebUIのRAGの結果が非常に悪い、または全く動作しません。なぜですか？

A: Ollamaを使用している場合、Ollamaではデフォルトで2048トークンのコンテキスト長が設定されています。これにより、取得したデータがコンテキストウィンドウに収まらず、全く使用されない可能性があります。

Open WebUIでの**RAG（取得強化生成）**のパフォーマンスを向上させるには、コンテキスト長を大幅に増加させる必要があります（8192トークン以上）。これにより、取得したドキュメントがモデルの応答に効果的に寄与できるようになります。

Ollamaモデルのパラメータを設定して、より大きなコンテキストウィンドウを許可するように構成してください。この設定は、チャット画面またはモデルエディターページから確認および変更できます。これによりRAG体験が大幅に向上します。

Q: Open WebUIはMCP（モデルコンテキストプロトコル）をサポートしていますか？

A: はい、Open WebUIはMCPツールサーバーを公式にサポートしています。ただし、OpenAPI互換のプロキシを通じてのみ利用可能です（openapi-servers）。これにより、最適な互換性、セキュリティ、保守性を確保しています。

MCP（および他のバックエンドプロトコル）をブリッジするために、以下の目的に特化したプロキシ実装を提供しています：👉 https://github.com/open-webui/mcpo

この設計選択は、いくつかの主要な原則によって動機付けられています：

• 📘 標準優先：OpenAPIはRESTfulサービス定義および契約駆動のサービス相互運用の事実上の標準です。OpenAPIを通じて統合を調整することで、アップグレードやデプロイメントの中でも再現可能でスキーマ駆動の動作が可能になります。
• 🔒 セキュリティ隔離モデル：プロキシを通じてMCPを統合することで、バックエンドプロトコル動作をサンドボックス化および隔離し、攻撃面を減少させ、境界レベルでの監査、認証、および観測可能性を向上させます。
• ⚙️ プロトコル抽象化：統一されたOpenAPIスキーマを通じて異種バックエンド（例：MCP）をサポートすることで、Open WebUIがバックエンドに依存せず、予測可能なランタイム動作を維持します。
• ⛓️ 分離されたデプロイトポロジー：プロキシベースのアーキテクチャにより、ツールサーバー（例：MCP）がフロントエンドのプレゼンテーションから独立して進化できるため、高度にモジュール化された本番環境や分散ワークロードを促進します。

要するに：MCPはサポートされていますが、MCPツールサーバーがOpenAPI互換プロキシを介して前面にある場合に限ります。このアーキテクチャ的決定は意図的であり、Open WebUIがスケーラブルで安全かつ保守可能であり続けることを保証します。

さらなるサポートが必要ですか？

他に質問や懸念があれば、GitHub Issues ページまたはDiscordチャンネルでお気軽にお問い合わせください。より詳しい情報や支援を提供します。