2026 Open WebUI 0.13.0 アップグレード前に確認すべきことは？

判断：アップグレードは可能ですが、イメージを差し替えるだけで完了とは判断できません。 0.13.0にはデータベース移行が含まれるため、先にバックアップと復元手順を確認し、複数インスタンスまたは複数Workerを使う場合は公式の指示どおり全インスタンスを同期して更新してください。チームでは、画面やツール呼び出し、子Agentの既定動作が変わる可能性も事前に確認します。

この記事は、単一インスタンスを運用し、更新と検証の準備をしたい開発者向けです。
複数インスタンスやWorkerを管理する運用担当者は、版をそろえる手順と更新後の確認点を整理できます。
端末やツール、子Agentを使うチームでは、更新に伴う操作上の影響を先に評価できます。

最終更新：2026年11月7日。公開日と変更点はOpen WebUIの公式リリース記録、移行と同期更新の要件は公式更新ガイドおよび公式バージョン記事で確認しています。公開前にも後続の修正や案内を確認してください。

更新前：0.13.0への変更と現在の構成を照合する

Open WebUI 0.13.0は2026年11月3日に公開され、公式案内ではデータベース移行が含まれると説明されています。そのため、通常のアプリケーション更新と同じ感覚で新しいイメージを起動し、問題があれば古いイメージに戻すだけ、という計画にはできません。公式リリース記録と更新に関する公式案内で、自分の環境に関係する変更を確かめてください。

Open WebUI 0.13.0への更新は、どの順で進めればよいですか。
まず、現在動いている版、デプロイ方式、インスタンス数、Workerの構成を記録します。次に、公式の更新ガイドで自分の方式に合う手順を確認し、バックアップの復元可能性を確かめてから更新します。手順やデータ配置が異なる環境へ、別の構成向けコマンドをそのまま流用しないでください。

確認結果は、たとえば次のように更新前の記録へ残します。値は自分の環境から転記し、空欄のまま更新を始めないことが重要です。

現在の版：<記録した版>
デプロイ方式：<Docker Compose / Python など>
インスタンス数・Worker構成：<実環境を記録>
永続データ・外部データベース：<実環境を記録>
復元先での読み取り確認：<完了 / 未完了>

Open WebUIのセルフホストでは、稼働中のコンテナだけを見ても、実際に保護すべきデータや設定の全体像をつかめないことがあります。永続化先、外部データベースの有無、環境変数、独自設定を、それぞれ実際の構成に沿って特定してください。

Open WebUIの更新前には、何をバックアップすればよいですか。
利用中の永続データ、外部データベースを使っている場合はそのデータベース、環境変数や設定ファイルなど、復元に必要なものを対象にします。データの置き場所はデプロイ方式や個別の設定で異なるため、決め打ちのディレクトリ一覧を使わず、現在のCompose設定や運用記録と照合してください。認証情報を含む設定は、保管先や閲覧権限にも注意が必要です。

バックアップの作成だけでは不十分です。更新前に、別の場所でデータを読み取れること、復元先を使えること、復元後にどのイメージと設定で起動するかまで確認します。データベース移行後に旧版へ戻す際、イメージだけを戻せば元どおりになるとは限りません。データベース移行に関する公式トラブルシューティングも確認し、アプリケーションとデータを一貫した状態に戻す計画を用意してください。

設定確認にDocker Composeを使っている場合は、更新前に次のコマンドで展開後の構成を確かめられます。

docker compose config

これは構成を確認するためのコマンドであり、更新そのものを実行する手順ではありません。Docker Composeの公式コマンド説明に沿って結果を確認し、環境変数などの機密情報が含まれる場合は、出力をそのまま共有したり、公開ログへ貼り付けたりしないでください。

更新の実行前：同期更新と延期の条件を分ける

複数インスタンスや複数Workerを使う環境では、版の不一致が一時的に起きても構わないと自己判断しないでください。公式の更新案内は、該当する構成では全インスタンスを同期して更新するよう求めています。切り替えの順序や停止時間の扱いは構成によって異なるため、公式ガイドと自分のデプロイ方式を照合します。

複数インスタンスやWorkerは、同じタイミングで更新する必要がありますか。
公式の案内に従い、対象となる複数インスタンスは同期して更新してください。新旧の版が混在したまま運用する計画では進めず、全インスタンスの更新を調整できない場合は、作業を延期して更新枠を確保するのが安全です。構成を分散して運用している場合は、公式の拡張ガイドも参照してください。

次のチェックリストで、作業開始か延期かを判断できます。

• [ ] バックアップを別の場所で読み取れ、復元手順も確認済みです。未確認なら、更新を始めず復元検証を行います。
• [ ] 現在の版、デプロイ方式、永続データ、主要設定を記録しました。不明な項目があれば、先に構成を棚卸しします。
• [ ] 複数インスタンスまたは複数Workerがある場合、全対象を同期して更新できます。調整できなければ部分更新を始めず、作業を延期します。
• [ ] チームで使う画面、ツール、子Agentの変更を確認し、更新後の担当者と検証項目を決めました。影響を評価できていなければ、更新前に関係者と確認します。
• [ ] 移行ログと起動状態を確認でき、異常時に変更範囲を広げず停止できます。確認手段がなければ、記録方法を整えてから作業します。

コミュニティで端末機能がどの構成で利用できるかを尋ねる声があっても、それは公式な提供条件や更新手順の根拠にはなりません。自分の環境で有効な機能、権限、設定を確認し、版番号だけから利用可否を決めないでください。

更新中：方式に合う公式手順で変更範囲を管理する

Open WebUIの更新方法はデプロイ方式によって異なります。DockerとPythonで同一のコマンドを使うと決めつけず、公式更新ガイドから該当方式の手順を選んでください。未確認のコマンドやデータパスを追加せず、変更した内容と実行順を記録します。

作業は次の順に進めます。

1. 現在の版、起動状態、インスタンス構成、関連設定を記録します。
2. 永続データとデータベースを退避し、復元先で読み取りを確認します。
3. 使用中のイメージタグ、主要な環境変数、設定ファイルの保管場所を記録します。環境変数の確認には公式リファレンスを使い、現在の設定と照合してください。
4. 適用する更新手順を、デプロイ方式に応じた公式ガイドから選びます。
5. 複数インスタンスやWorkerを利用している場合は、公式要件に沿って全対象を同期して更新します。
6. 起動状況とログを確認し、データベース移行の完了を確かめます。
7. 異常が出たら更新対象を増やさず、ログ、移行状況、退避データを確認してから、用意した復元計画に切り替えます。

作業記録は、たとえば「更新手順：公式ガイドの該当方式を参照／全インスタンス：版を照合済み／データベース移行：ログとアプリ動作で確認」のように残します。これは記録例であり、実際のコマンド出力ではありません。移行結果を確認できないまま次の変更を重ねると、原因の切り分けが難しくなります。

更新後：移行状態とチームの主要操作を照らし合わせる

画面が表示されても、それだけでアップグレード完了とは判断できません。起動状態、データベース移行の結果、アカウント認証、過去の会話、知識ベース、保存済み設定を、更新前に記録した状態と比較します。問題が出た項目は、該当するログや公式の移行トラブルシューティングと照合してください。

0.13.0への更新後は、ツール呼び出しの何を確認すればよいですか。
公式リリース情報では、ツール呼び出しのラウンド上限や子Agentの制限に関する既定動作の変更が案内されています。具体的な動作を以前の版の記憶で決めつけず、0.13.0の公式変更案内を読み、チームで有効にしている操作を実際に試します。

次の項目を、利用中の機能に絞って確認してください。

• ログインと会話履歴：実際のチームアカウントでログインし、過去の会話を開けるか確認します。
• 知識ベースと設定：保存済みデータが見えるだけでなく、必要な操作ができるかを確かめます。
• モデル接続とツール：チームで使う接続先とツールを試し、処理が完了するか、失敗時にログを追えるかを確認します。
• 画面上の操作箇所：公式案内にあるボタン位置の変更を確認し、既存の手順書や利用者向け説明を必要に応じて直します。
• ツール呼び出しと子Agent：利用中のタスクを実行し、ラウンド上限や制限の既定動作がチームの想定と合うかを確認します。

これらの動作は0.13.0について案内された変更として確認し、すべての版に共通する仕様として扱わないでください。更新直後に問題が見つかった場合は、画面表示だけで正常とせず、データベース移行の状態と更新前の記録に戻って確認します。

安定後：アプリケーションと推論処理の負荷を分けて見る

更新後にサーバーを見直す場合は、Open WebUIのアプリケーション処理とモデルの推論処理を分けて考えます。必要なCPU、メモリー、ストレージ、ネットワークは、実際のインスタンス数や有効機能、監視結果から評価してください。測定していない資源量や性能を、一般的な最低要件として断定することはできません。

モデルを別の環境で実行している構成では、Open WebUI側の変更だけを理由に推論用サーバーまで増強する必要があるとは限りません。一方、同一機器でデータベースやモデル処理も動かしている場合は、更新後の利用状況とログを確認し、各サービスの負荷がどこで発生しているかを分けて記録します。サーバーのメモリーとディスクを検討する際は、容量選びの案内も参照できます。保守時の接続方法を見直す場合は、SSH接続の案内を確認してください。

Open WebUIのセルフホストでは、更新頻度だけでなく、データの復元を自分で行えるか、複数の実行単位を同時に管理できるかも運用負担を左右します。共有型の仮想サーバーでは、物理CPUをほかの利用者と共有する構成の場合に負荷変動の影響を受けることがあり、仮想化層によって物理機器やメモリー構成を直接選べないこともあります。長期間動かすアプリケーションやデータベースで専有環境を管理したい場合は、共有型のまま続ける場合とAMD物理サーバーを借りる場合を、実測した負荷と必要な管理範囲で比べてください。

OSFP CloudはGPUを提供していないため、GPUを必要とする推論を前提に選ぶサービスではありません。また、短時間だけ動かす用途や負荷がごく小さい用途では、物理サーバーの専有が適さない場合もあります。必要であれば、OSFP Cloudで実際に選べる構成と条件を確認し、更新後の運用要件に合うか判断してください。