システム診断と使用状況分析

Libre WebUI は、管理者向けにインスタンスの 2 つのリアルタイム画面を提供します。ホストとランタイムを診断するシステムページと、モデルおよびプロバイダーの使用状況を分析する使用状況ページです。どちらもバックエンドと画面の両方で管理者専用です。どちらのページを読み取っても、データはデプロイ内に留まります。任意の外部テレメトリーは、運用担当者が別途設定するオブザーバビリティ経路です。

サイドバーの管理者用項目、タブメニューの管理者用ショートカットから開くか、/system と /usage へ直接アクセスします。管理者以外はどちらのページも開けません。サインイン中のアカウントから admin ロールが失われると、管理者タブは閉じられます。

システム診断

システムページ（/system）には、次の情報が表示されます。

ホスト: ホスト名、プラットフォーム、カーネルリリース、アーキテクチャ、稼働時間、論理 CPU 数、CPU モデル、ロードアベレージ、プロセスがコンテナ化されているように見えるか。CPU 使用率のパーセンテージはなく、CPU 負荷はロードアベレージだけです。
ランタイム: アプリケーションのバージョン、Node.js のバージョン、プロセス ID、プロセス稼働時間、作業ディレクトリ。
メモリ: ホストメモリの合計、空き、使用量、およびプロセスの RSS とヒープの値。
ファイルシステム: ランタイムファイルシステム（/）とデータディレクトリ（DATA_DIR）の容量と使用量。
ネットワーク: インターフェース名とアドレス。Linux では受信／送信バイト数のカウンターも表示。
Docker: Docker ソケットを利用できる場合に、エンジンのバージョン、ホスト OS、カーネル、エンジンが報告する CPU とメモリ、コンテナ数、簡略化したコンテナ一覧。

このページは、タブにフォーカスがある間は 30 秒ごとに更新され、手動更新ボタンもあります。バックエンドのエンドポイントは GET /api/system です。認証、有効な管理者ロール、ユーザーごとに 15 分あたり 120 リクエストのレート制限で保護されています。応答は一切キャッシュされず（Cache-Control: no-store）、リクエストごとに最新の値を収集します。

Docker ソケットへの依存

Docker セクションは、Work ランタイムおよび対話型ターミナルと同じ方法でエンドポイントを解決します。設定されていれば WORK_DOCKER_SOCKET（常にローカル Unix ソケットのパス）、それ以外は DOCKER_HOST（unix:// URL、またはフィルタリング済み Docker API プロキシなどの平文 HTTP tcp:// エンドポイント）、どちらもなければ /var/run/docker.sock を使用します。ssh://、npipe://、TLS 検証を有効にした tcp:// エンドポイントには、意図的に問い合わせません。リクエストは読み取り専用のエンジン GET（バージョン、情報、コンテナ一覧）だけで、タイムアウトは 4 秒、応答サイズには上限があり、コンテナ一覧は 100 件までです。

利用可能なソケットがなくても、ページの他の部分は動作します。Docker パネルにはリクエスト全体を失敗させる代わりに、ソケットがマウントされていない、マウント済みだが読み取れない、デーモンに到達できない、リモートエンドポイントである、といった利用不可の理由が表示されます。

ページに表示される情報と閲覧者

コンテナ一覧は意図的に簡略化され、短い ID、名前、イメージ、状態、作成時刻だけを含みます。環境変数、ラベル、マウント、コンテナコマンド、inspect ペイロードは一切含まれず、応答内のどこにも資格情報は現れません。

それでも、ページには実際のインフラ情報が表示されます。ホスト名、作業ディレクトリ、内部 IP アドレス、Libre WebUI 自身だけでなく Docker ホスト上のすべてのコンテナ名とイメージです。これは信頼モデルに沿っています。Docker デプロイでは、すべての Libre WebUI 管理者が実質的にホスト管理者でもあります（Docker を参照）。この点を踏まえて admin ロールを付与してください。

使用状況分析

使用状況ページ（/usage）は、ユーザーに帰属するモデルおよびプロバイダーの処理をグラフ化します。計測は対応する各実行境界で行われ、現在は次の処理を対象とします。

ローカル Ollama の Chat 呼び出しと Ollama ベースの Work 呼び出し
インストール済みエージェント CLI の Chat 呼び出しと Strands エンジンの呼び出し
プラグイン経由のストリーミング・非ストリーミング Chat
プラグインの埋め込み、画像生成、音声認識、音声合成、音声、動画
プラグイン経由の Work 呼び出し

所有ユーザーのいないバックグラウンド処理は、意図的に架空のアカウントへ割り当てないため、計測対象になりません。呼び出しが失敗またはキャンセルされた場合も記録されます。

各イベントには、次の情報が記録されます。

提供元・プラグイン ID と表示名のスナップショット（ollama と agent-cli:* もプラグインと同じ台帳を使用）
機能（chat、embedding、image、stt、tts、audio、video）
モデル
状態：success、error、cancelled（中断したストリームはキャンセル扱い）
提供元が使用量を返した場合だけトークン数
機能に応じた単位数（TTS の文字、画像、埋め込み入力、動画ジョブ、音声バイト）
開始から終了までの時間とタイムスタンプ
要求したユーザー ID

それ以外は保存されません。プロンプト、応答、プロバイダーのエンドポイント、資格情報、プロバイダーのエラー本文が使用状況テーブルへ書き込まれることは決してありません。失敗した呼び出しは status = 'error' としてだけ記録されます。イベントは選択したアプリケーションデータベース（ソロモードでは SQLite、チームモードでは PostgreSQL）に保存され、400 日間保持されます。古い行は、書き込み時に 1 日 1 回を上限として適宜削除されます。計測は設計上ベストエフォートであり、モデルやプロバイダーへのリクエストを失敗させることは決してありません。

ページでは、管理者専用の 1 つのエンドポイント GET /api/plugins/usage?days=<1..365>（デフォルト 30）を通じて、7 日、30 日、90 日の期間を選択できます。呼び出し総数、報告されたトークン数、成功率、平均レイテンシ、そしてトークン使用量が報告された呼び出しの割合を表示します。このページの閲覧は読み取り専用で、デプロイ済みの既存の使用状況台帳を利用します。

エージェント使用量

上部付近のエージェント欄（CLI エージェントと Strands エンジンの呼び出し）は Claude Code、Codex、OpenCode、Pi、Strands を個別に表示します。呼び出し数、報告トークン数、失敗・キャンセル数、平均時間、上位 20 モデルを示します。エージェント合計は提供元・モデル表の表示上限とは独立し、選択期間の該当呼び出しをすべて含みます。ページ全体の合計の一部であり、追加課金イベントではありません。

記録がない場合はこの期間に記録された呼び出しはありませんと表示します。CLI のインストールやログイン状態を示すものではありません。使用量メタデータがなければトークン数は未報告と表示し、推測はしません。ページが見えている間は 20 秒ごとに更新し、手動更新もできます。

CLI の使用量は 1 回の実行と CLI が報告したトークン数を記録します。累積スナップショットは以前のものを置き換え、重複ステップは除外します。キャッシュと推論カウンターは各 CLI の規約に沿って合算し、内数を二重に数えません。キャンセルや、一部の応答の後に異常終了した実行も実際の結果を保持します。

Strands の呼び出しは Strands エージェントに集計されます。このエンジンには独自のモデルプロバイダーがなく、エンジンが行うモデル呼び出しはすべて Libre WebUI の Ollama またはプラグインプロバイダーを経由します。LWUI 外の呼び出しは取り込まず、トークン数のない古い記録も未計測のままです。

エンドポイントは上限付きの内訳を agents に公開し、カウンターがゼロでも 5 つの対応名を含めます。読むだけで CLI 検出、エージェント起動、提供元への接続は行いません。このフィールドのない旧サーバーは提供元内訳に残るエージェント記録を表示できますが、欠けたエージェントを確実なゼロ使用量とは表示しません。

モデルとプロバイダーを調べる

モデルの色は、日別グラフ、年間アクティビティカレンダー、モデルテーブル、プロバイダーのバーを結び付けます。色に加えて、モデル名、値、選択状態の表示も添えられます。アクティビティカレンダーは選択した期間に関係なく常に直近 365 日を対象とし、各日の色はその日に最も使われたモデルを表します。

日別グラフは呼び出しとトークンを切り替えられます。凡例でモデルにポインターを合わせるか、キーボードフォーカスを移すと、そのモデルの線をたどれます。モデルを選択するとハイライトが固定され、もう一度選択すると解除されます。すべてのモデルを表示を選ぶとリセットされます。モデルテーブルからもハイライトを操作できます。ハイライトは強調を変えるだけで、日別合計、テーブルの値、プロバイダー合計は変わりません。

グラフ上でポインターを動かすか、日ごとの使用状況を確認を使うと、その日の合計とモデル内訳を確認できます。日別スライダーはキーボード操作に対応し、矢印キーで日を移動し、Home/End で最初と最後の日へ移動します。日別のバケットとそのラベルは UTC を使います。

既定では、グラフは選択期間の呼び出し数上位 12 件のモデル名を表示します。トークン表示のときも同じです。それ以外のモデルも個別に確認できます。テーブルまたはプロバイダーの詳細でモデルにフォーカスするか選択すると、その 12 件の外にあるモデルでも正確な日別の線が読み込まれます。読み込み中のメッセージには、要求したモデル名が表示されます。

追加したモデルの線はその他のモデルから切り離され、残りのグループからはそのモデルの呼び出し、報告されたトークン、失敗が除かれます。グラフに含まれる名前付きモデルの線は最大 13 本と残りのグループで、日別の値は同じ合計と一致し続けます。すべてのモデルを表示を選ぶと既定の表示に戻ります。

日別の線は、記録されたモデル名が同じ呼び出しをプロバイダーをまたいでまとめます。モデルテーブルはプロバイダーとモデルの組み合わせを個別に保持するため、同じモデルが複数のプロバイダーの下に現れることがあります。名前付きのモデルは、既定のグラフに含まれないものも含めて、テーブルとプロバイダーのバーで固有の色を保ちます。

プロバイダーの詳細には、各プロバイダーのリクエスト比率、モデルごとに分割されたバー、報告されたトークン数、失敗またはキャンセルされた呼び出し、平均応答時間が表示されます。機能構成は、モデルとプロバイダーの内訳の下に引き続き表示されます。

トークン合計に含まれるのは、プロバイダーが使用状況メタデータを報告した呼び出しだけです。カバレッジの割合によって、報告が部分的であることが分かります。欠けているトークン数を、リクエスト数や別のモデルから推定することはありません。報告されたトークンがまったくない期間では、トークン表示に説明が出ますが、そのリクエスト履歴は呼び出し表示で引き続き確認できます。

エンドポイントは modelSeries に日別のモデルデータを含みます。省略可能な model クエリパラメーターは、既定の上位 12 件に加えて、記録された正確なモデル名を 1 つ要求します。例: GET /api/plugins/usage?days=30&model=<encoded-model-name>。これは同じ管理者専用の読み取り専用エンドポイントで、ローカルの使用状況台帳を照会するだけであり、履歴の取得のためにモデルプロバイダーを呼び出すことはありません。

省略可能な to パラメーターは、リクエストの終了境界をミリ秒単位の Unix タイムスタンプに固定します。model と併用する必要があり、サーバーの現在時刻以前の非負の安全な整数だけを受け付けます。個別のモデルを読み込むとき、ブラウザーは概要の range.to を送信し、UTC の日と年の境界を保ったまま、そのタイムスタンプより後の呼び出しを除外します。to を指定しない場合、エンドポイントは現在時刻を使います。

モデルを読み込んでも、概要のカード、テーブル、プロバイダー合計、色はそのまま残ります。その日別の線が追加されるのは、レスポンスの時間範囲と日別合計が概要と一致する場合だけです。この時間境界はデータベースを凍結するものではありません。過去分の追加投入や削除によって合計が変わった場合、ブラウザーはモデルの線を表示する前に概要を更新します。

古いサーバーが modelSeries を返さない場合、グラフは集計されたすべてのモデルの系列を表示し、モデル別の内訳が利用できないことを説明します。モデルテーブルは引き続き利用できます。ブラウザーが期間合計や年間カレンダーから日別のモデル履歴を推測することはありません。

計測を無効にする切り替えはありません。このデータは複数アカウントを横断して集約されるため、閲覧は管理者に限定されます。

使用状況ページは、呼び出し、単位、トークン、レイテンシ、結果を報告します。これらのイベントに、適用日付き料金、支出内訳、予算、アラート、会計エクスポートが必要な場合は、コストガバナンスを追加してください。一致する料金がないイベントや、プロバイダーから使用状況が報告されなかったイベントは、無料扱いせず、価格未設定として明示されます。

OpenRouter の帰属表示

0.18.0 以降、OpenRouter へのリクエストでは、OpenRouter のアプリ帰属ヘッダー（HTTP-Referer: https://librewebui.org、アプリケーションタイトル、カテゴリのヒント）を通じてアプリケーションを識別します。このヘッダーを送信するのは、リクエスト先が https://openrouter.ai 自体の場合だけです。カスタム経路やセルフホスト経路には決して送らず、ローカルに保存する情報も増えません。