プラグイン

Libre WebUI はプラグインを使用して、ローカルの Ollama に加え、外部 AI プロバイダーやモデル機能へ接続します。

プラグインの種類

種類	用途
チャット／補完	プロバイダー API のテキストおよびチャットモデル
埋め込み	文書検索およびメモリ用のベクトル埋め込み
画像生成	画像モデルおよび ComfyUI 形式のバックエンド
テキスト読み上げ	音声合成プロバイダー
音声認識	文字起こしプロバイダー
音声生成	サウンドおよび音声生成プロバイダー
動画生成	非同期の動画生成プロバイダー

プラグインは静的なモデルマップを公開でき、対応している場合はプロバイダー API から利用可能なモデルを更新できます。

組み込みプロバイダーファミリー

Libre WebUI には、一般的なサービス向けのプロバイダー定義が含まれています。

OpenAI および OpenAI 互換 API
Anthropic
Google Gemini
Groq
Moonshot AI の Kimi Code
Mistral
OpenRouter
Hugging Face
GitHub Models
ローカル Apple Silicon 推論用の MLX LM
ComfyUI
ElevenLabs

プロバイダーカタログは頻繁に変わります。プラグインがライブモデル検索に対応している場合は、UI を最新情報の基準として扱ってください。

所有権と認可

プラグイン定義はインスタンス全体で共有される設定です。すべての /api/plugins ルートで認証が必要で、定義をアップロード、インストール、更新、削除できるのは管理者だけです。有効化はこれと異なり、各認証済みユーザーが共有プラグインを自分のアカウントについてのみ有効または無効にできます。この状態は SQLite に保存され、他のユーザーの有効なプロバイダーに影響することなく、バックエンドの再起動後も維持されます。

アップグレード時には、従来のグローバルな .status.json 有効化リストが、 Libre WebUI にコンパイルされたトラストアンカーと完全に一致する定義についてのみ、既存アカウントへ一度だけコピーされます。従来のカスタム定義またはシャドウ定義は隔離され、無効のままです。この移行後に作成されたアカウントでは、プラグインは何も有効化されていない状態から始まります。

組み込み定義が信頼されるのは、正規化した内容がバックエンドにコンパイルされたハッシュと一致する場合だけです。書き込み可能な定義は、正規化されたソースパスと定義全体のハッシュによって SQLite で承認されます。管理者によるインストール、更新、再インポートでその承認が記録され、ファイルを直接変更すると無効になります。承認と更新ではファイルを置き換える前に全アカウントの有効化状態が解除されるため、各ユーザーは確認済みの定義を再度有効にする必要があります。アップグレード前のカスタム定義は、カタログへの表示、モデル検索、資格情報の受け入れ、各機能の実行を行えるようにする前に、管理者が再インポートする必要があります。

プラグイン変数は用途別に分けられます。認識される次の接続ルーティング変数を保存できるのは管理者だけです。

endpoint、base_url、api_path、models_endpoint、api_url、 image_endpoint、embedding_endpoint、stt_endpoint、tts_endpoint、 voice_clone_endpoint、api_mode、model、model_id。機能で宣言された config.endpoint_variable、config.models_endpoint_variable、または config.voice_clone_endpoint_variable も、別の名前が使われていても接続ルーティングとして扱われます。

管理者以外のユーザーも、temperature やストリーミング設定などの生成コントロールを引き続き保存できます。管理者以外が所有する古いルーティング行は無視され、設定済みの値として返されず、そのアカウントでプラグイン変数を完全にリセットすると削除されます。これにより、後からロールが昇格したときに、休止中のルートが知らないうちに復活することを防ぎます。

資格情報

資格情報は、環境変数またはユーザー設定から取得できます。

環境変数の例：

OPENAI_API_KEY=sk-...
ANTHROPIC_API_KEY=sk-ant-...
GROQ_API_KEY=gsk_...
GEMINI_API_KEY=...
MISTRAL_API_KEY=...
OPENROUTER_API_KEY=sk-or-...
KIMI_API_KEY=...
GITHUB_API_KEY=github_pat_...
ELEVENLABS_API_KEY=...

共有デプロイでは通常、各ユーザーが自分のプロバイダー料金と制限を管理できるため、ユーザー単位の資格情報が適しています。環境変数のキーは、単一ユーザーのインストール、デモ、または管理対象デプロイに便利です。

環境変数のキーがフォールバックとして使われるのは、リクエストがシャドウされていない組み込みプラグイン定義のルーティングおよび認証プロジェクションを使用している間だけです。インポートした定義、組み込み ID をシャドウする書き込み可能な定義、または管理者が保存した接続ルーティングの上書きには、同じアカウントで保存した資格情報が必要です。 Libre WebUI は環境変数へのフォールバックを許可する前に、ルートエンドポイント、認証フィールド、機能エンドポイントとエンドポイント変数セレクター、認識されるルーティング変数の定義とデフォルトを比較します。標準コンテナレイアウトのように従来のプラグインディレクトリと組み込みプラグインディレクトリが同じパスを共有する場合でも、コンパイル済みマニフェストハッシュが最終的な基準です。上書きされたパッケージマニフェストが独自の信頼を確立することはできません。

この規則は、検索、Chat、Work、可用性チェック、機能カタログに適用されます。これにより、カスタムエンドポイントやアップグレード前のカスタムマニフェストへ、運用担当者が管理するシークレットが送られることを防ぎます。

ユーザーが保存した資格情報は、保存時点で有効だった定義ソース、完全な定義ハッシュ、認証コントラクト、機能エンドポイントとセレクター、有効なルーティング値に結び付けられます。ルートまたは定義を変更すると、ユーザーが新しい宛先を確認して資格情報を再保存するまで、古い資格情報は利用できません。バインドのない従来の資格情報が受け入れられるのは、アンカー済みの組み込みルートと完全に一致する場合だけです。初めて正常に使用された時点で、復号したキーを返す前にバインドが書き込まれます。

OpenAI 互換プロバイダー

多くのプロバイダーは OpenAI 互換 API を公開しています。プラグインでは次を定義できます。

完全な API エンドポイント URL
API キーの環境変数
チャットエンドポイントの動作
埋め込みの対応状況
モデル検索の動作
任意のモデルマップフォールバック

プロバイダーがライブモデル検索に対応していない場合、Libre WebUI は設定済みのモデルマップを使用します。インポートしたプラグイン JSON では、Libre WebUI が対応する通信形式のいずれかを既に使用するプロバイダーを設定できます。対応形式は OpenAI Chat Completions、OpenAI Responses、 Anthropic Messages、Gemini です。JSON だけで任意の独自プロトコルを変換することはできません。リクエスト、ストリーミング、ツール呼び出し、応答の形式が異なるプロバイダーには、小さなバックエンドアダプターが必要です。

OpenAI 画像生成

組み込みの OpenAI プロバイダーは、 https://api.openai.com/v1/images/generations で Image API を公開します。現在のモデルは gpt-image-2 です。既存の互換デプロイ向けに、非推奨の gpt-image-1.5、gpt-image-1、gpt-image-1-mini ID もカタログに残っていますが、新しい設定では gpt-image-2 を選択してください。

画像生成では Chat と同じ有効な OpenAI 資格情報、つまり現在のユーザーが保存したキー、または信頼済みの組み込みプロバイダーの環境変数フォールバックを使用します。カスタム Chat エンドポイントが誤って画像リクエストを受け取らないよう、独立した任意の image_endpoint 上書きがあります。組み込みの Image API エンドポイントを継承するには、 image_endpoint を空のままにします。

画像の選択はプロバイダーで修飾されます。2 つの画像プラグインが同じモデル ID を公開しても、 Libre WebUI は画像パネルで選択したプロバイダーだけへリクエストを送ります。GPT Image の応答では base64 画像データを使用します。Libre WebUI はそのデータをアプリ内画像へ変換し、現在のユーザーのギャラリーに保存します。Image API ルートには認証が必要で、直接の生成リクエストには pluginId と model の両方を含める必要があります。n には 1 から 10 の JSON 整数を指定できます。数値文字列と小数値は、プロバイダーへ到達する前に拒否されます。

Chat Completions と Responses API のモード

OpenAI 互換の補完プラグインでは、chat_completions または responses のどちらかのリクエストセマンティクスを使用できます。組み込みの OpenAI プラグインでは、 設定 → プラグインからこれを選択できます。

接続設定は次の順序で解決されます。

設定されている場合、完全な endpoint の上書き。
base_url と任意の api_path。
プラグインの従来の endpoint。

プラグインマニフェストのエンドポイントと完全に一致するエンドポイント値は、上書きではなくマニフェストのデフォルトとして扱われます。これにより、アップグレード後に古い保存済みデフォルトが新しいベース URL をシャドウすることを防ぎます。実際のカスタム完全エンドポイントは、引き続き最優先です。

デフォルトパスは、Chat Completions モードでは /chat/completions、Responses モードでは /responses です。base_url には https://api.example.com/v1 のような API ルートを指定します。互換プロバイダーが別の相対パスで操作を公開する場合は api_path を使用します。完全なエンドポイントには操作パス全体を含める必要があり、他の 2 つのフィールドより優先されます。既知の /chat/completions、/completions、または /responses サフィックスによってリクエストセマンティクスが確定します。カスタムエンドポイントパスでは、選択した api_mode が維持されます。

インポートしたプラグイン JSON でも、同じデフォルトを指定できます。

{
  "endpoint": "https://api.example.com/v1/chat/completions",
  "api_mode": "responses",
  "base_url": "https://api.example.com/v1",
  "api_path": "/responses"
}

Responses リクエストは input、max_output_tokens、フラット化した関数ツール、 store: false を使用し、ステートレスな継続のため暗号化された推論内容を要求します。完了した Responses 出力とストリーミング中の出力は、Libre WebUI の Chat および Work のイベント形式へ正規化されます。完全で順序どおりの出力 Item 配列が最大 64 Items かつ 90 KB の場合に限り、再生状態が保持されます。Items は正確に保持され、フィールド単位で切り詰められることはありません。再生可能な Items には、一意で空ではない ID と型が必要で、メッセージ、推論、関数呼び出しの構造は、ツール呼び出しが発行される前に検証されます。大きすぎる Chat 状態は、正規化された表示履歴へフォールバックします。Chat は対応するツール出力を永続化しないため、生の関数呼び出し Items も破棄します。上限内の正確な再生状態がないツール付きの Work 応答は、ツールの副作用が発生する前に拒否されます。

SQLite ベースの Chat ストレージは保持されたプロバイダー状態をメッセージとともに暗号化し、 Work はツール専用状態をメッセージ API から返されない非表示のコンテキスト行に保存します。ハッシュ化したスコープによって、再生は同じプロバイダー、モデル、Responses モード、最終的に設定されたエンドポイント、選択した資格情報の不透明な一方向フィンガープリントへ結び付けられます。 API キーのローテーション後を含め、このスコープが変更されると、Libre WebUI はプロバイダー固有の Items を認証境界を越えて送信せず、正規化されたメッセージ履歴へフォールバックします。実行中の Work もルーティングと資格情報のフィンガープリントを取得し、プロバイダーの各ラウンドの直前に再検証します。モード、エンドポイント、API キーを変更すると、以前のツール状態を別のリクエストが受け取る前に実行が停止します。ツール付きの状態は、Work が副作用を実行する前に、再生上限と永続化メタデータラッパー全体の 100 KB 上限の両方に収まる必要があります。永続化した Work バッチが中断された場合、欠落した各ツール結果は、正確な呼び出し ID と結果不明の警告付きで復元されます。これにより、プロバイダーは副作用の可能性がある操作をむやみに繰り返さず、ワークスペースを調べられます。不完全な Responses 結果は、成功した Chat または Work ターンとして扱われません。その incomplete_details.reason は保持され、呼び出し元に表示されます。

モデル検索はどちらの操作パスからも /models を導出します。たとえば、 https://api.example.com/v1/responses の検索先は https://api.example.com/v1/models です。互換性のあるモデル一覧エンドポイントがないプロバイダーでも、手動の model_map を使用できます。検索は現在のユーザーの変数と資格情報に限定されます。結果は共有プラグインマニフェストへ書き込まず、ユーザーごとに永続化されます。検索は、有効化、明示的な更新、API キーの変更、接続変数の変更、変数のリセット後に実行されます。無関係な生成変数を保存してもネットワークリクエストは発生しません。

検索は自動的にも実行されます。プラグイン一覧を読み取ると、カタログが存在しないか PLUGIN_MODEL_DISCOVERY_TTL_MS より古い有効な補完プロバイダーが再検索されるため、アプリケーションを再読み込みすると、有効化時点のカタログではなくプロバイダーの現在のモデルが反映されます。プロバイダーごとのバックオフにより、到達できないプロバイダーをリクエストごとに調査することを防ぎ、期限によって遅いプロバイダーが応答を遅延させることを防ぎます。期限を超えた更新結果は、次のリクエストで提供されます。最終的に導出された検索 URL は、ユーザーの資格情報を読み取る前、または認証ヘッダーを作成する前に検査されます。URL がインポートしたプラグインマニフェスト由来の場合も同じです。検索およびプロバイダー機能のリクエストは HTTP リダイレクトに従いません。最終的な Chat、Work、モデル一覧、画像、埋め込み、文字起こし、音声、ボイスクローン、オーディオ、または動画エンドポイントを直接設定してください。これにより、検証済み URL から未検証のリダイレクト先へ資格情報が転送されることを防ぎます。

プロバイダーエンドポイントでは HTTP または HTTPS を使用できます。HTTP では API キー、プロンプト、ツール結果、生成内容がトランスポート暗号化なしで送信されるため、信頼できるネットワーク上のセルフホスト型ゲートウェイに限って使用してください。ゲートウェイが TLS に対応している場合は常に HTTPS を推奨します。リクエストはバックエンドから送信されます。コンテナデプロイでは http://ai-gateway:8080/v1 のようなサービス URL を使用し、 localhost は Libre WebUI コンテナ自体を指します。画像生成を含むプラグイン機能ルートでは、リクエストを行う認証済みアカウント用のエンドポイント変数と資格情報が解決されます。 Libre WebUI に未認証の単一ユーザーモードはありません。

機能固有のエンドポイント

Chat エンドポイントの上書きは、画像、埋め込み、文字起こし、テキスト読み上げ、音声、動画の各機能から分離されています。複数機能を持つプラグインでは image_endpoint、 embedding_endpoint、stt_endpoint、tts_endpoint、または config.endpoint_variable で指定した別の変数を公開できます。ボイスクローンのルートでは、同様に config.voice_clone_endpoint_variable を指定できます。これらのフィールドを空にすると、プラグインで宣言された機能エンドポイントが使用されます。汎用の Chat endpoint が機能の上書きに使われることはありません。

組み込みの GitHub Models プラグインでは、任意の上書きが空の場合、現在の models.github.ai/inference/chat/completions エンドポイントを継承します。Hugging Face プラグインは、埋め込み、画像、テキスト読み上げにタスク固有の hf-inference/models/{model} ルートとペイロードを使用し、それらのリクエストを Chat エンドポイントには送りません。

エンドポイントの上書き

endpoint 変数には、操作パスを含む完全なリクエスト URL を指定します。たとえば、 OpenAI 互換チャットプラグインでは通常、https://provider.example だけでなく https://provider.example/v1/chat/completions のような URL を使用します。インポートした従来のプラグイン設定では、この変数が api_url と呼ばれることがあります。 Libre WebUI はこの別名を受け入れますが、両方が存在する場合は空でない endpoint が常に優先されます。

HTTP および HTTPS の絶対エンドポイント URL が受け入れられ、その他のプロトコルは拒否されます。 HTTP は資格情報とリクエスト内容をトランスポート暗号化なしで送るため、信頼できるネットワーク上のセルフホスト型ゲートウェイを対象としています。プライベートなデプロイ境界の外へ出るルートには HTTPS を推奨します。上書きを空にすると、プラグイン定義の完全なエンドポイントが使用されます。無効な上書きを明示的に指定した場合、暗黙にデフォルトへルーティングされることなく拒否されます。

プロバイダーリクエストはリダイレクトに従いません。最終的に検証された操作 URL を直接設定してください。リダイレクト応答は、資格情報またはリクエスト内容を次のホップへ転送する代わりに、プロバイダーエラーとして報告されます。

リクエストは Libre WebUI バックエンドから送信されることに注意してください。コンテナ内では localhost はコンテナ自体を示し、コンテナホストや別のサービスを自動的に指すことはありません。ゲートウェイのコンテナサービス名、またはコンテナランタイムが提供する場合は host.docker.internal のようなホストから到達可能な名前を使用してください。

モデル検索

設定 → プラグインには、このフロー用のプロバイダー接続ワークスペースがあります。左ペインでプロバイダーを検索して選択し、右ペインで有効状態と実際のモデルカタログを確認します。設定を選択するまで、プロバイダー設定は折りたたまれたままです。これにより、エンドポイント、資格情報、高度な生成コントロールはデフォルト表示から外れます。

チャットおよび補完プロバイダーでは、モデルを更新を実行すると、選択したプロバイダーを検索した後、プラグインカタログと Chat のモデル一覧の両方が再読み込みされます。カタログは読み取り専用です。行には、現在のユーザーが検索した ID と、プラグイン定義の機能モデルマップが表示されます。機能ラベルは、どのプラグインルートがモデルを掲載しているかを示すもので、ヘルスチェックではありません。フォールバックまたは手動管理するモデル ID は、検索済みの行を編集せず、プラグイン JSON の model_map で追加します。

プラグインを有効にすると、Libre WebUI はそのアカウントの有効なエンドポイントと資格情報を使用してモデル検索を試みます。管理者のカスタムルートには、同じアカウントで保存した資格情報が必要です。環境変数フォールバックは、信頼済みのマニフェストルートだけに使用されます。互換 API の場合、 Libre WebUI は完全なエンドポイントからモデル一覧 URL を次のように導出します。

/models で終わる URL はそのまま使用します。
/chat/completions、/completions、/responses、/embeddings、/messages など、既知の操作サフィックスは /models に置き換えます。
それ以外の場合は、パスに /models を追加します。

導出 URL を使用できないプラグインは、models_endpoint を明示的な完全モデル一覧 URL として公開できます。これは導出より優先され、同じ送信先 URL ポリシーの対象となり、リダイレクトに従わずにリクエストされます。endpoint、api_url、models_endpoint、base_url、 api_path、または api_mode を保存またはリセットすると、UI が再読み込みする前に、現在のユーザーが検索したカタログが消去されて更新されます。

すべてのカスタムルートは、資格情報を選択する前に解決および検証されます。保存されたカスタムルートでは、資格情報ポリシーがサーバー環境変数のキーへフォールバックしてはいけません。代わりに、そのルート用のユーザー単位のキーを設定してください。環境変数フォールバックは、信頼済みプラグイン定義で指定されたエンドポイント専用です。

検索では、data 配列にモデル ID を含む OpenAI 互換応答を想定します。有効化はその試行が終わるまで待機するため、最初のプラグイン一覧更新に検索済みカタログを含められます。成功した結果はユーザーごとに保存され、そのユーザーのプラグインビューへ重ねられます。Libre WebUI は共有プラグイン JSON を書き換えず、あるユーザーが検索したモデル ID を別のアカウントへ公開しません。プロバイダーに互換性のあるモデル一覧エンドポイントがない、到達できない、または別の応答形式を返す場合、通常の有効化ではそのユーザーの以前の検索結果が維持されます。意図的に接続フィールドを変更すると古いカタログが先に消去されるため、新しいルートを検索できない場合はプラグインの model_map フォールバックが使われます。

接続ルーティングを保存またはリセットすると、次の検索を試行する前にそのアカウントの以前の検索済みカタログが消去されるため、ある宛先から取得したモデルがルート変更後も選択可能なまま残ることはありません。

プラグインの状態、Work の可用性、モデルカタログ、機能ルートでは同じユーザーコンテキストと資格情報の境界が使用されます。たとえば画像モデルの可用性、エンドポイント変数、資格情報は、リクエストを行うユーザーについて解決されます。

Chat での厳密なプロバイダー選択

モデル ID はグローバルに一意ではありません。Ollama モデルと複数の有効なプラグインが、すべて example-model という名前のモデルを公開する可能性があります。そのため Chat は、生のモデル ID と任意のプロバイダー識別情報を一緒に保存します。

providerType: "ollama" は、ローカルまたは設定済みの Ollama ルートを示します。
providerType: "plugin" と providerId の組み合わせは、1 つの特定プラグインを示します。

プロバイダーで修飾し URL エンコードした値は、モデル選択画面で衝突しないキーとしてのみ使われます。リクエストでは引き続きプロバイダーの生のモデル ID が送信されます。Ollama とプラグイン間、およびプラグイン同士で重複するモデル名は別々の選択肢のままで、チャットを再度開くと保存した選択が正確に復元されます。

明示的なプロバイダー識別はフェイルクローズします。選択したプラグインが無効化、削除された、またはそのモデルを公開しなくなった場合、Libre WebUI は保存された選択を利用不可として表示し続け、同じモデル名を持つ別のプロバイダーへ暗黙に切り替えません。再び生成するには、プロバイダーを再有効化するか、別のモデルを明示的に選択してください。

プロバイダー識別情報が保存される前に作成されたセッションと設定では、providerType と providerId が未設定または null の場合があります。元のプロバイダーを確実に復元できないため、これらの従来レコードでは互換性のため過去の名前だけによるルーティングを維持します。選択画面では Ollama またはプラグインのラベルを推測せず、「プロバイダー未記録」と表示します。具体的なプロバイダー項目を選択すると、それ以降のリクエスト用に正確なプロバイダーが記録されます。新しいペルソナ選択では persona:<id> の UI 識別情報を維持し、Ollama ベースとして記録されます。

プロバイダー設定と継承

設定 → プラグインを開き、プロバイダーの設定を選択します。プロバイダーパネルはデフォルトで閉じています。管理者は共有定義と接続ルーティング値を管理できます。その他の認証済みユーザーは、プロバイダーの有効化、自分の API キーの保存、自分の生成コントロールの変更ができますが、UI にはプラグインのアップロード、インストール、エクスポート、削除、ルーティングコントロールは表示されません。

管理者には接続の上書きが最初に表示されます。サンプリングなどの専門的なコントロールは、デフォルトで閉じている詳細パラメーター内にあります。継承された接続値と生成値は、プロバイダーデフォルトのヒント付きの空欄として表示されます。Libre WebUI は、パネルを開いただけでマニフェストのデフォルトをアカウントの保存済み設定へコピーしません。

保存時に送信されるのは、現在の編集セッションで変更したフィールドだけです。保存済みの非機密値を消去すると、そのアカウントの上書きが削除され、プロバイダーのデフォルトに戻ります。マスクされた機密フィールドを空のままにしても変更されません。デフォルトにリセットを実行すると、そのアカウントに管理が許可されているすべての変数上書きが削除されます。保存またはリセットに失敗した場合、ユーザーが再試行できるよう、未保存の値はエディターに表示されたままになります。

この違いはカスタムエンドポイントで重要です。管理者はエンドポイントを空のままにしてプラグインの組み込み URL を継承するか、完全で互換性のある URL を入力して、その管理者のプロバイダー接続用に上書きします。

Work でのプラグイン

Work では、Ollama と Ollama Cloud に加えて、有効な completion および chat プラグインを使用できます。プラグインを使用する Work の実行が受け入れられるのは、次の条件を満たす場合だけです。

プラグインが有効である。
モデルが現在のユーザーの検索済みカタログ、またはプラグインで設定されたモデルマップに存在する。
現在の管理者が利用できる資格情報がある。

Work は選択したプロバイダーの種類とプラグイン ID を、タスクおよび各実行と一緒に保持します。そのため、ルーティングはモデル名だけでなく、保存された正確なプロバイダーに基づきます。Ollama モデルと同じ名前のモデルを持つプラグインを有効にしても、既存タスクのルートが知らないうちに変更されることはありません。

Work は、OpenAI 互換、Anthropic、Gemini のネイティブなリクエスト／応答形式を介してツール呼び出しを適応させます。プロバイダーが通常のチャット補完を提供していても、選択するモデルはツール呼び出しに対応している必要があります。プロバイダーがツールを拒否したり、互換性のない応答を返したりすると、別のプロバイダーへフォールバックすることなく実行は失敗します。

リモートの Work 実行では、プロバイダーへ複数回リクエストする場合があります。プロバイダーは Work のシステムプロンプト、会話コンテキスト、ツール定義、要求されたツール結果を受信します。ツール結果には、ソースファイル、ディレクトリ一覧、コマンド出力が含まれる場合があります。Libre WebUI は Work 内に、ユーザーごとに閉じられるリモートプロバイダー開示を表示します。それでも運用担当者は、機密性の高いプロジェクトでサービスを有効にする前に、プロバイダーの料金、保持、学習ポリシーを確認してください。

埋め込み

埋め込み対応プラグインは、文書の埋め込み設定に表示されることがあります。Libre WebUI は、 nomic-embed-text、bge、e5、gte などのモデル名から、埋め込み用と思われる Ollama モデルも検出します。

埋め込みモデルが見つからない場合、UI はローカルのデフォルト候補として nomic-embed-text を使用します。