Granular Access Control

LibreChatは、認証の上に完全な認可システムを搭載しています。アクセス権は「すべてか無か」ではありません。アプリ内のすべての共有可能なエンティティ（エージェント、プロンプト、MCPサーバー、リモートエージェント、ファイル、会話）は独自のアクセス制御リスト（ACL）を持っており、すべての機能はユーザー、グループ、ロール、または公開ごとに個別に有効化または制限することができます。

このページでは、小規模なチームで全員が自由に共有する環境から、Entra IDグループの同期、カスタムロール、委任された管理者を利用するエンタープライズ環境まで、組織に合わせて権限をモデル化できるよう、各要素がどのように組み合わさっているかを説明します。

アクセスモデルの概要

LibreChatの認証には、組み合わせて機能する3つの独立したレイヤーがあります。

これら3つすべてが、同じ4つの主要なタイプについて評価されます：

• User: 個別のLibreChatアカウント
• Group: ユーザーの集合（ローカル、または Entra ID から同期）
• Role: 権限プロファイルの名称（例: USER、ADMIN、または任意のカスタムロール）
• Public: インスタンス上のすべての認証済みユーザー

レイヤー 1: 機能権限 (ロールベース)

機能レベルの権限は、特定のロールに対してアプリの全機能を制御します。これらは、「このロールのユーザーはエージェントを作成できるか？」、「プロンプトを公開共有することは許可されているか？」、「コードインタープリターを呼び出せるか？」 といった疑問に対する答えとなります。

組み込みシステムロール

LibreChatには、常に存在し削除できない2つのシステムロールが付属しています。

• ADMIN: インスタンスに最初に登録されたアカウントに割り当てられます。管理者はすべてのリソースの閲覧、設定の変更、管理パネルへのアクセス、およびプラットフォーム全体にわたる動作の構成を行うことができます。
• USER: すべての新規アカウントに割り当てられるデフォルトのロール。

管理者は、MongoDB内のユーザードキュメントを更新することで手動で昇格させることができます。詳細は Administrator Controls を参照してください。

権限タイプ

各ロールは、権限タイプ × アクションの行列を保持します：

SHARE と SHARE_PUBLIC の違いは重要です。特定のユーザーやグループとエージェントを共有する権限（SHARE）をロールに付与しつつ、インスタンス上の全員に対してエージェントを公開する権限（SHARE_PUBLIC）は与えない、といった設定が可能です。

機能権限の設定

機能権限を管理する推奨される方法は、LibreChat Admin Panel を使用することです。これにより、各ロール（作成したカスタムロールを含む）の権限マトリックスを直接編集できます。変更はLibreChatを再デプロイすることなく反映され、グローバルな USER デフォルトではなく、変更したい特定のロールに対してのみ適用されます。

カスタムロール

USER および ADMIN に加え、管理者は独自の機能権限マトリックスを持つカスタムロールを作成できます（v0.8.5で導入。詳細は #12528 を参照）。ユーザーは複数のロールを保持でき、その有効な権限は保持しているすべてのロールの和集合となります。カスタムロールは管理パネルから管理されます。

ロールおよびグループ単位の構成オーバーライド

機能フラグに加え、v0.8.5ではDBベースの設定オーバーライドシステムが導入されました（#12354）。これにより、特定のグループやロールに対して、異なる librechat.yaml 形式の設定 を割り当てることが可能になります。例えば、「Research」グループには、デフォルトとは異なるエンドポイントへのアクセス権、より高い再帰制限、および異なるエージェント機能を持たせることができます。オーバーライドはログイン時に解決され、ベースとなる設定の上に構成されます。

レイヤー 2: リソース ACL (エンティティごとの共有)

LibreChatのすべての共有可能なリソースには、ロールベースの権限とは独立した独自のアクセス制御リスト（ACL）があります。これにより、SHARE権限を持つ個々のユーザーは、自身のエージェント、プロンプト、またはMCPサーバーへのアクセス権を_誰に_付与するかを選択できます。

リソースタイプ

現在、リソースACLは以下に適用されます：

• エージェント (agent)
• プロンプト / プロンプトグループ (promptGroup)
• MCP Servers (mcpServer)
• リモートエージェント (remoteAgent)。 Agents API 用
• Files (file)。通常、それらを使用するリソースから継承されます。
• Projects (project) は継承をサポートしており、プロジェクトに共有されたリソースは自動的にACLを継承します。

アクセスロール (権限プリセット)

エンドユーザーに生のパーミッションビットを公開するのではなく、共有機能ではリソースタイプごとに3つの名前付きロールを使用します。

内部的には、権限は各（リソース、プリンシパル）のペアに対してビットマスク（permBits）として保存されます。スーパーセットは自動的に処理されるため、Editorを付与すると自動的にViewerも付与されます。

UIからアクセスを許可する

1. リソース（エージェントビルダー、プロンプトフォーム、MCPサーバー設定など）を開きます。
2. Share ボタンをクリックします（あなたがオーナーまたは管理者であるか、SHARE 権限が付与されている場合に表示されます）。
3. 共有ダイアログ内:
   • ピープルピッカーを使用して、追加するユーザー、グループ、またはロールを検索します。
   • プリンシパルごとにアクセスロール（Viewer / Editor / Owner）を選択してください
   • 必要に応じてPublic accessを切り替えて、インスタンス上の全員がリソースを閲覧できるようにします（SHARE_PUBLIC機能の権限が必要です）。
4. 保存します。付与対象者は、次回リフレッシュ時にリソースを確認できます。

Grantees に表示される内容

• Viewersは、関連するピッカー（エージェントのドロップダウンなど）でリソースをすぐに使えるアイテムとして表示します。ビルダーを開いたり、生の指示を確認したり、設定を変更したりすることはできません。
• Editorsはリソースの設定を開いて変更することはできますが、削除や再共有を行うことはできません。
• Ownersは元の作成者と同じUIを持ち、自由に削除や再共有を行うことができます。
• 元の作成者は、ACLの状態に関係なく常に完全な制御権を保持し、管理者はインスタンス上のあらゆるリソースを管理できます。

Project Inheritance

権限は親の project から継承できます。ACLエントリが継承されると、inheritedFrom リンクがソースを指し示します。これがLibreChatにおける「グローバル」プロジェクトの仕組みであり、グローバルプロジェクトに追加されたリソースは、プリンシパルごとにエントリを作成することなく、すべてのユーザーが利用できるようになります。

Layer 3: System Grants (Admin Capabilities)

System grants は、管理者レベルの機能に使用される個別の権限テーブルであり、「このユーザーは管理パネルにアクセスできるか？」や「このグループは MCP サーバーをグローバルに管理できるか？」といった問いに答えるものです。これらは常にプリンシパル（ユーザー、グループ、またはロール）と機能文字列に対してスコープが設定されます。

標準的な機能には以下が含まれます：

Manage（管理）権限は、対応するRead（読み取り）権限を暗黙的に含みます（例：manage:users を保持していると、自動的に read:users が付与されます）。SystemRoles.ADMIN ユーザーはすべての権限を暗黙的に保持しています。権限付与（grants）を使用することで、管理者以外のプリンシパルを完全な管理者権限にすることなく、管理者権限のサブセットを委譲することができます。

システム権限は、管理パネルを通じて付与および取り消しが行われます。

Principals in Depth

ユーザー

標準的な LibreChat アカウント。ユーザーは ローカル（メールアドレス/パスワード）または フェデレーション（OAuth2、OIDC、SAML、LDAP）のいずれかとなります。フェデレーションユーザーは外部 ID（idOnTheSource）と照合可能です。Entra ID の場合、これは OID であり、グループ同期を有効にするためのものです。

グループ

グループとは、名前付きのユーザーの集合です。LibreChatは以下の2つのソースをサポートしています：

• Local groups: 管理パネルから、またはデータベース上で直接作成および管理されます。メンバーはLibreChatのユーザーIDです。
• Entra ID (Azure AD) グループ: token reuse が有効な状態でユーザーが Azure OIDC 経由でログインした際に、Microsoft Graph から同期されます。同期された各グループは、Entra Object ID を idOnTheSource として保存し、LibreChat をテナントのメンバーシップと同期させ続けます。

グループは、あらゆるACL、peoplePicker検索、および設定のオーバーライドやシステム権限付与のプリンシパルターゲットとして表示されます。500人のグループと共有された単一のリソースは（500個ではなく）1つのACLエントリとして扱われ、Entraでのメンバーシップの変更は次回のログイン時に自動的に反映されます。

ロール

任意のシステムロールまたはカスタムロールをプリンシパルとして使用できます。エージェントをロール（例: SupportEngineers）と共有すると、個々のユーザーを指定することなく、現在そのロールを持つすべてのユーザーにアクセス権が付与されます。ロールベースの共有が管理者のみの関心事である環境では、interface.peoplePicker.roles を介して、ピープルピッカーからロールを非表示にすることができます。

Public

すべての認証済みユーザーに一致する特別なプリンシパルです。パブリック付与は、付与を行うユーザーがそのリソースタイプに対して SHARE_PUBLIC 機能権限を保持している場合にのみ許可されます。

People Picker Visibility

ピープルピッカー（共有ダイアログ内の検索ボックス）は、インスタンスレベルで制限をかけることで、デプロイメントに関連のないプリンシパルタイプを非表示にすることができます。

interface:
  peoplePicker:
    users: true
    groups: true
    roles: false

これは_検索UI_にのみ影響します。非表示のプリンシパルタイプに対する既存のACLエントリは引き続き機能し、通常通り適用されます。

ACL以前のバージョンからの移行

v0.8.0-rc3より前のバージョンでは、よりシンプルな所有権モデルが使用されていました。アップグレードを行うには、既存のAgentやプロンプトに引き続きアクセスできるようにするため、ACLマイグレーションを実行する必要があります。

ドライラン（変更のプレビュー）:

npm run migrate:agent-permissions:dry-run
npm run migrate:prompt-permissions:dry-run

実行:

npm run migrate:agent-permissions
npm run migrate:prompt-permissions

Dockerバリアントおよびバッチサイズオプションについては、エージェント移行ガイドを参照してください。

関連ドキュメント

• エージェント: 共有と権限
• インターフェース設定 (機能権限)
• 認証
• OpenID Connect トークンの再利用 (Entra ID グループ同期に必須)
• Azure / Entra ID OAuth2
• SharePoint 統合
• Agents API (Remote Agents)
• LibreChat 管理パネル