Open WebUI に OpenAI API を追加する場合のおすすめ設定と構成（予算5ドル編）

by
Local LLMを使っている人は、薄々気がついているかもしれないが、たとえGPT-OSS 120Bを入れたとしても、ChatGPTのようにポンポンとテンポよく、気が利く、整理された回答を返してくれるわけではない。同じGPT-5系のモデルであっても、APIのモデル単体とChatGPTは全く別物である。
さらに、同じGPT系であっても、GPT-5系モデルとGPT-OSSモデルでは性格や得意分野が大きく異なる。
ユースケースごとに、「このケースはクラウド」「このケースはローカル」と使い分ける必要がある。
また、ChatGPTに課金していたとしても、Open AIのモデルは、別払い契約なので、ChatGPTの有償プランに加入していても、OpenAI APIは別契約となるため利用できない。
 
また、OpenAIのモデルを利用するメリットは、単純な回答性能だけではない。
 
ローカルLLMの場合、
  • コンテキストサイズの選定
  • VRAMやメモリ容量の管理
  • KV Cacheの調整
  • 量子化方式の選択
  • モデル更新への追従
などを利用者自身が考える必要がある。一方でOpenAI APIの場合は、それらをほぼ意識する必要がない。利用者はモデルを選択するだけでよく、コンテキストサイズやメモリ消費量を気にせず利用できる。
ローカルLLMを日常的に運用していると当たり前になってしまうが、「モデルを選んだらすぐ使える」というのはクラウドLLMの大きなメリットの一つである。
 
自分は、保険として、$5だけ課金している。自分の場合、メインはChatGPTで、OpenAI APIはテストや検証用途が中心なので、有効期間1年の間に5ドルで十分足りてしまった。
 

Open WebUI に OpenAI API を追加する場合のおすすめ構成

月予算 5ドル を前提にすると、モデルを増やしすぎず、管理しやすい構成にするのが重要。

Connection設定

Connection Type External
URL: https://api.openai.com/v1
Auth: Bearer API key
Prefix ID: openai
Provider: Default
API Type: Chat Completions

Model ID

おすすめ例
もちろん、コストや要件によって自由に設定できるが、まずはOpenAI APIの特徴を体感するためのスタートラインとして、以下の2モデルをおすすめする。
gpt-5-mini
gpt-4o-mini
モデル一覧を自動取得すると全モデルが表示されて管理が難しくなるため、Model IDは明示指定することをおすすめする。
理由：
  • 高額モデルの誤利用を防げる
  • 管理者・利用者ともにモデル選択で迷わない
  • OpenAI側でモデルが追加されても勝手に表示されない
  • コスト管理、予測がしやすい

追加したモデルは、AllあるいはExternalに表示される。
 

おすすめモデル

最新、最高のモデルを使うのが一番いいが、まずはスタートラインとして、以下のモデルで開始することをおすすめする。
重要なのは、Local LLMのモデルと何が違うのかを確認する必要があるが、第一段階として、LLMモデルとして
回答の精度
回答の幅

1位: gpt-5-mini

料金
項目
価格
Input
$0.25 / 1M token
Output
$2.00 / 1M token
用途
  • Linux
  • Docker
  • Kubernetes
  • MCP
  • Open WebUI
  • 技術調査
  • ブログ執筆
現在のローカル環境
Qwen3.6:35B
Gemma
DeepSeek
を補完する用途として非常に相性が良い。
難しい調査だけ OpenAI に投げる運用ができる。

2位: gpt-4o-mini

料金
項目
価格
Input
$0.15 / 1M token
Output
$0.60 / 1M token
用途
  • メール要約
  • MCP操作
  • 日常会話
  • 文章整理
  • 軽い技術質問
非常に安価。

課金

あくまでも検証用途で、本番、常用用途ではないので、最低課金から開始する。
最低チャージ金額は前払い5ドルからで、有効期限は1年間となる。
不足した場合は、前払いを追加できる。
 
注意点
ChatGPTの課金を行なっている場合でも、Open AI Endpointを使う場合は、課金契約をする必要がある。（同じOpen AI提供でもChat GPTとは別サービス）

5ドルでどれくらい使えるか？

仮に1回の会話を
入力 5000 token
出力 2000 token
とします。

gpt-5-mini

計算
入力
5000 / 1,000,000 × 0.25
= $0.00125
 
出力
2000 / 1,000,000 × 2.00
= $0.00400
 
合計
= 約 $0.00525
理論値
$5 ÷ $0.00525
 
≒ 950回
実運用では履歴やRAGが増えるため
300～600会話
くらいが現実的。

gpt-4o-mini

計算
入力
5000 / 1,000,000 × 0.15
= $0.00075
 
出力
2000 / 1,000,000 × 0.60
= $0.00120
 
合計
= 約 $0.00195
理論値
$5 ÷ $0.00195
 
≒ 2500回
実運用では
1000～1500会話
程度は十分可能

おすすめ

ローカル
├─ Qwen3.6:35B
├─ DeepSeek
└─ Gemma
 
OpenAI
└─ gpt-5-mini
が最もバランスが良い。
 
さらに保険として
gpt-4o-mini
を追加しておくと、
  • 軽い処理 → gpt-4o-mini
  • 難しい技術調査 → gpt-5-mini
  • 普段はローカルLLM
という使い分けができる。

最終推奨設定

OpenAI 側の利用を5ドルに設定した場合。
Prefix ID:
openai
 
Model IDs:
gpt-5-mini
gpt-4o-mini
これがコスト・性能・運用のバランスが最も良い構成。
 

Open WebUIでの利用比較

普通にOpenAIモデルを指定すれば利用可能だが、２つのモデルをロードすることにより内容の比較ができる。
ちょっと解釈が異なる質問をいくつか聞いてみた。
今回の検証では、gpt-5-miniの方がレスポンスが速く、回答内容もより詳細な傾向が見られた。
 
比較の題材として、
  • 白の彩：明らかなこと
  • グレーの彩：賛否両論があること
  • 選択の彩：どこから考え始めるか
の３つを両モデルに質問してみた。
 
「紙を半分に100回折り続けた場合の厚さ」を両モデルに質問してみた。
この題材を選んだ理由は、一見すると単純な行為だが、真剣に計算すると非常に大きな数値となり、数式によって明確に説明できる事象だからである。
いわば、「明らかなこと」「白」であることを題材としている。このテストは「白の彩」を見るプロンプトである。
 
「丸山ワクチンについて」を両モデルに質問してみた。
この題材を選んだ理由は、単純な事実確認だけでなく、歴史的経緯、医学的評価、エビデンスの解釈など複数の観点が必要となるためである。
いわば、「賛否両論があること」「グレー」であることを題材としている。このテストは「グレーの彩」を見るプロンプトである。
そのため、モデルごとの情報整理能力や説明の深さを比較しやすい。
 
「アンドロイドは電気羊の夢を見るか？」という質問を両モデルに投げてみた。有名なSF映画の原作タイトルである。
Qwenは小説や映画の解説から入り、GPT-5-miniは哲学やAIの意識の問題から入り始めた。
いわば、何色もある絵の具のパレットから、まずどの色に筆を落とすかを見るため、つまり「選択の彩」を見るプロンプトである。
どちらも誤りではない。しかし、この結果はモデルが「何を知っているか」ではなく、「どこから考え始めるか」の違いをよく表している。
いくつか比較問題を試したが、「アンドロイドは電気羊の夢を見るか？」が最も面白い結果となった。
この問いには正解が存在しない。しかし、Qwenは作品解説から入り、GPT-5-miniは哲学やAIの意識という観点から入り始めた。
同じ問いに対して、どこから考え始めるかという違いがよく表れていた。
 
実は、
「自宅から徒歩3分の洗車場で自分の車を洗車したい。徒歩で行くべきか車で行くべきか」
というプロンプトも試してみた。
こちらの予想としては、どちらかのモデルが文脈を誤解して「徒歩で行く」と回答することを期待していたのだが、結果としては両モデルとも正しく「車で行く」と回答した。
比較テストとしては不採用となったが、モデルの常識や文脈理解を確認する題材としては面白いので、興味があれば試してみることをおすすめする。
 

Open WebUIでの利用分析

管理者専用の機能として、Open WebUIでは、モデルごとのにどれくらい使ったかなどの統計を取ることができる。
面白いのは、モデル単位で集計されるため、どのモデルが人気なのか、どれくらいのトークンを消費しているのかを把握できる点である。
さらにモデルに何を聞いたのかもわかる。クリックをすれば、チャット全文をみることもできる。
 
この機能は、管理者が全ての内容を確認できてしまうために、ユーザには通知する必要があるし、また、管理者は利用状況の可視化と利用者のプライバシー保護のバランスを取る必要がある。
 
Open WebUIにローカルLLMだけを登録して運用するというのも、実際には使いにくい場面がある。
用途に応じてクラウドモデルを併用することで、回答品質や作業効率は大きく向上する。また、実際に利用してみることで、自分や組織にとって本当に必要な利用形態が何だったのかに気付くきっかけにもなる。
さらに、「課金を避けたい」という理由だけでローカルLLMへ移行した場合、その判断が必ずしも適切ではなかったことに気付くケースもある。ローカルLLMにはローカルLLMのコストや運用負荷があり、クラウドLLMにはクラウドLLMのメリットがある。
重要なのは、ローカルかクラウドかという二択ではなく、用途に応じて適切に使い分けることである。
そのためにも、導入初期の段階で利用モデルや予算の上限、コスト管理の仕組みを設定しておくことをおすすめする。利用状況を可視化しながら運用することで、後から発生するかもしれない課金トラブルや予算超過にも対応しやすくなる。
まずは少額から始めてみる。そして実際の利用状況を見ながら、自分たちにとって最適なローカルLLMとクラウドLLMのバランスを探していくことが重要ではないだろうか。

 

 

 

 

 

 

コメントする