LibreChat 管理パネル

LibreChat Admin Panelは、LibreChatのためのスタンドアロンなブラウザベースの管理インターフェースです。LibreChat本体と同じデータベースに接続し、granular access controlを支える管理タスクのためのGUIを提供します。これには、ユーザーおよびグループの管理、ロール管理、ロールやグループにスコープされた設定のオーバーライド、システムレベルの権限付与などが含まれます。

What It Does

管理パネルはシンクライアントです。すべてのデータはLibreChatのデータベースに存在し、すべてのアクションはLibreChat APIサーバー上のバージョン管理された /api/admin/* endpoint を経由します。これにより、管理者は以下の操作を一元的に行えるようになります。

• 設定の管理: 動的でスキーマ駆動型のフォームを通じて、すべての LibreChat 設定を表示および編集できます。設定スキーマに新しいフィールドが追加されると自動的に反映されるため、管理パネルのリリースは不要です。
• プリンシパルごとのオーバーライドを適用: 設定のオーバーライドを特定のロールやグループにスコープし、ログイン時に各ユーザーに適用される最終的な値を決定する優先順位ベースのカスケードを使用します。
• ユーザーの管理: インスタンス上のすべてのアカウントのリスト表示、検索、および閲覧を行います。
• グループの管理: グループの作成と削除、メンバーの追加と削除を行い、ACLやオーバーライドにおいてグループを第一級のプリンシパルとして使用します。
• ロールの管理: 組み込みの USER / ADMIN 以外のカスタムロールを作成し、機能権限マトリックスを編集し、ユーザーにロールを割り当てます。
• Issue system grants: 特定のユーザー、グループ、またはロールに対して、完全な管理者権限を付与することなく、管理機能（例: manage:users、read:usage、manage:mcpservers）を委任します。
• Authenticate: LibreChatのローカル管理者アカウントでログインするか、LibreChatインスタンスで有効になっている場合はOpenID SSO / SAML / サポートされているOAuthプロバイダー経由でログインします。

基盤となる権限モデル（プリンシパル、リソースACL、機能、およびレイヤーの構成方法）については、Access Control ページを参照してください。

アーキテクチャ

┌──────────────────┐         ┌──────────────────┐         ┌──────────────┐
│  Admin Panel     │ ───────▶│  LibreChat API   │ ───────▶│   MongoDB    │
│  (Bun + Vite)    │  HTTPS  │  /api/admin/*    │         │  (shared DB) │
└──────────────────┘         └──────────────────┘         └──────────────┘
       │                             │
       │ OAuth/OIDC/SAML redirect    │ Verifies admin access
       └─────────────────────────────┘

管理パネルは独立したサービスとして実行され、LibreChatとプロセスを共有しません。管理機能は、access:admin システム権限または SystemRoles.ADMIN ロールを通じてLibreChat側で検証されるため、パネル自体が本来持つべきでない権限を付与することはできません。

LibreChat が公開する管理 API サーフェスは以下の通りです：

はじめに

前提条件

• v0.8.5以降で実行中のLibreChatインスタンス（それ以前のバージョンでは管理者APIは利用できません）
• admin-panel コンテナ/ホストから LibreChat API へのネットワークアクセス
• LibreChat上の管理者アカウント：最初に登録されたユーザー（自動管理者）、Mongoで role: 'ADMIN' が設定されたユーザー、または access:admin 権限が付与されたプリンシパルのいずれか。

LibreChatに同梱（推奨）

LibreChatを公式のdocker-compose.ymlまたはdeploy-compose.ymlで実行する場合、管理パネルはサービスとして同梱されており、LibreChatと同時に自動的に起動するため、別途デプロイする必要はありません。

スタックを起動する前に、LibreChatの.envでパネルのセッションシークレットを設定してください。composeファイルはそれをパネルのSESSION_SECRETとして渡します：

# Min 32 characters. Generate with: openssl rand -hex 32
ADMIN_PANEL_SESSION_SECRET=replace-with-a-32-char-random-string

# Optional: host port for the default docker-compose
# ADMIN_PANEL_PORT=3000

# Optional: set true when the panel is served over HTTPS
# ADMIN_PANEL_SESSION_COOKIE_SECURE=false

composeファイルは残りの設定を自動的に接続します。API_SERVER_URLはapiサービスを指し、VITE_API_BASE_URLはブラウザ向けのOAuthリダイレクトのためにDOMAIN_CLIENTに従い、ADMIN_PANEL_URLはSSO後にLibreChatが管理者をパネルへ戻すように設定されます。これを使用しない場合は、admin-panelサービスを削除するか、Composeのprofilesエントリを使用して制限してください。

スタンドアロン（個別デプロイ）

管理パネルを単独でホストし、別の場所で実行されている LibreChat インスタンスに向けるには、GHCR から公開されているイメージを使用してください：

# 1. Create an env file
cp .env.example .env

# 2. Edit .env and set at minimum:
#    SESSION_SECRET=<random string, min 32 characters>
#    VITE_API_BASE_URL=http://host.docker.internal:3080

# 3. Start it
docker compose up -d   # http://localhost:3000
docker compose down    # stop

スタンドアロンの docker run:

docker run -p 3000:3000 \
  --add-host=host.docker.internal:host-gateway \
  -e SESSION_SECRET=replace-with-32-char-random-string \
  -e VITE_API_BASE_URL=http://host.docker.internal:3080 \
  ghcr.io/clickhouse/librechat-admin-panel:latest

開発用にローカルで実行する

git clone https://github.com/ClickHouse/librechat-admin-panel.git
cd librechat-admin-panel
cp .env.example .env    # then edit
bun install
bun dev                 # http://localhost:3000

環境変数

LibreChatのバンドルされたDockerスタックでは、管理パネルは admin-panel サービスとして実行されます。デフォルトの docker-compose.yml はこれを ADMIN_PANEL_PORT で公開します。deploy-compose.yml はこれを nginx を介して http://admin.localhost にルーティングし、APIサービス用に ADMIN_PANEL_URL を設定します。

LibreChat リダイレクト URL

管理パネルがLibreChatとは別のURLでホストされている場合は、LibreChat API環境で ADMIN_PANEL_URL を設定してください。パスプレフィックスを含む外部管理パネルのベースURLを使用し、末尾のスラッシュは省略してください：

ADMIN_PANEL_URL=https://admin.example.com/admin

Helmデプロイの場合は、valuesファイルで librechat.adminPanelUrl を設定してください。チャートはこれをLibreChatの管理用OAuthフローのために ADMIN_PANEL_URL としてレンダリングします：

librechat:
  adminPanelUrl: https://admin.example.com/admin

OpenID SSOの場合、${DOMAIN_SERVER}/api/admin/oauth/openid/callback をアイデンティティプロバイダーに登録してください。

キャッシュ制御

これらはLibreChatのキャッシュ環境変数を反映したものです。ADMIN_PANEL_* バリアントが優先され、設定されていない場合は共有のLibreChat相当の設定にフォールバックされます。

認証

管理パネルはLibreChatの認証スタックを再利用しており、独自のユーザーデータベースは持っていません。以下の2つのログインパスがサポートされています：

• ローカルアカウント: 管理者アクセスチェックを通過したLibreChatユーザーに対するユーザー名/パスワード。
• シングルサインオン: OpenID Connect、SAML、およびLibreChatインスタンス上で既に設定済みのソーシャルOAuthプロバイダー。ADMIN_SSO_ONLY=trueを設定すると、パスワードフォームを完全に非表示にできます。

LibreChatでは、すべてのリクエストに対してサーバーサイドで管理者アクセス権が検証されます。アカウントは以下のいずれかの条件を満たしている必要があります。

1. MongoDBで role: 'ADMIN' を持っているか、または
2. access:admin システム権限を保持していること（管理パネル自体を通じて別のプリンシパルに割り当てられます。詳細は System Grants を参照してください）。

セッションはCookieベースであり、SESSION_SECRETで暗号化され、ADMIN_SESSION_IDLE_TIMEOUT_MSに基づいてアイドル状態でのタイムアウトが発生します。

設定管理

このパネルは、LibreChatの設定をconfig schemaによって駆動される動的なフォームとしてレンダリングします。これには2つの有用な特性があります：

• 前方互換性: LibreChatが新しい設定フィールドをリリースすると、パネルはスキーマからそれを自動的に取得します。管理パネルのアップグレードや再デプロイは不要です。
• Layered overrides: ベース設定（librechat.yaml からの読み込み）は、ロールやグループごとにスコープされたプリンシパル単位のオーバーライドによって上書き（シャドウイング）される場合があります。ユーザーがログインすると、オーバーライドは優先順位に従って解決され、ベース設定にマージされることで、そのユーザーに適用される有効な設定が生成されます。

これはLibreChatのDB-backed per-principal configuration override systemの背後にあるインターフェースです。一般的な使用例：

• 「Research」グループに、より高い recursionLimit と追加の endpoint を付与する
• 「FinanceAdmins」ロールにMCPサーバーの管理を許可し、通常のユーザーには利用のみを許可します
• 外部委託業者グループに対して、より厳格な interface 権限を適用する

関連情報

• Access Control: 管理パネルの基盤となる権限モデル
• Interface Configuration: パネルが編集する機能フラグ
• Authentication: LibreChatにおけるユーザー認証
• v0.8.5 changelog: 管理者APIの基盤
• GitHub: ClickHouse/librechat-admin-panel: ソース、イシュー、リリース