社内ChatGPT基盤にLibreChatが選ばれる理由｜競合OSS比較

部署ごとに ChatGPT を契約し、開発チームは Claude、マーケティングチームは Gemini を使っています。気づけば会話履歴は各サービスに散らばり、誰がどのモデルにどれだけ課金しているのか把握できなくなっていませんか。こうした状態を整理する手段として、セルフホスト型の AI チャット基盤を社内に一本化する選択肢が検討されます。

ところが、いざ OSS の候補を探し始めると今度は別の壁に当たります。チャット UI を備えた OSS は数多く公開されており、スター数だけを見ても優劣は判断できません。どのプロジェクトが「社内の複数ユーザーに配る基盤」として要件を満たすのか、日本語で比較した情報はほとんど見つかりません。

その候補の一つが LibreChat です。主要な AI プロバイダーを 1 つの UI に統合するセルフホスト型のプラットフォームで、MIT ライセンスのもとで公開され、マルチユーザー認証と管理パネルを備えています。チャット UI の体裁は ChatGPT に近く、既存の利用者に大きな学習コストをかけずに移行先として提示しやすい設計です。

一方で、活発に開発されている OSS には「更新のたびに破壊的変更を確認する」という運用コストが付いて回ります。実験的と公式に明示されている機能もあり、どこまでを本番前提で使えるのかは公式の記述を読み分ける必要があります。

本記事では、LibreChat の機能範囲、競合 OSS（Open WebUI・Dify・LobeHub・AnythingLLM）との違い、Docker での導入要件、そして導入前に押さえるべき運用上の注意点を整理します。なお本記事は公式サイト・公式ドキュメント・README・GitHub API の取得値をもとにした整理であり、実機検証に基づく性能評価やスクリーンショットの提示は含みません。採用可否を判断するための地図として読み進めてください。

LibreChatとは｜複数AIモデルを1画面に統合するセルフホスト型OSS

LibreChat は、README で「self-hosted AI chat platform that unifies all major AI providers in a single, privacy-focused interface」（主要な AI プロバイダーをプライバシー重視の単一インターフェースに統合するセルフホスト型 AI チャットプラットフォーム）と定義されているプロジェクトです。チャット機能に加えて、AI エージェント、Model Context Protocol（MCP）対応、Artifacts、Code Interpreter、カスタムアクション、会話検索、エンタープライズ向けのマルチユーザー認証を備えると記載されています。公式サイトは LibreChat 公式サイト、ソースコードと README は danny-avila/LibreChat で公開されています。

リポジトリの客観指標は以下のとおりです（GitHub API での取得値、2026 年 10 月 10 日時点）。

アーカイブ済みではなく、他リポジトリのフォークでもない独立したプロジェクトであり、ライセンスも MIT として明示されています。2023 年 2 月の作成から 3 年半以上にわたって開発が続き、最終 push は 2026 年 10 月 9 日です。

注目したいのは、リポジトリの description が自らを「Enhanced ChatGPT Clone」と名乗り、GitHub の topics にも chatgpt-clone が含まれている点です。つまり UI 設計の出発点は「ChatGPT の操作感の再現」にあります。社内展開時に「今まで使っていた ChatGPT と見た目が違いすぎて定着しない」という問題が起きにくいことは、基盤選定では軽視できない要素です。topics には mcp anthropic azure vertex-ai responses-api なども並び、対応範囲の広さが示されています。

このセクションで挙げた数値は、以降のセクションで「採用すべきか」を判断する際の土台になります。スター数やフォーク数の多さは関心の広さを示しますが、それだけで「自社に合う」ことは意味しません。次に、社内基盤として選ばれる具体的な理由を見ていきます。

社内ChatGPT基盤にLibreChatが選ばれる3つの理由

LibreChat の機能は公式 README に長大なリストとして掲載されていますが、社内 AI チャット基盤としての採用判断に効く軸は大きく 3 つに整理できます。ここでは機能名を並べるのではなく、その機能が社内運用のどの課題を解くのかという観点で読み替えます。

主要プロバイダーとOpenAI互換APIを横断できるモデル選択

1 つ目は、モデル選択の自由度です。README の AI Model Selection では、Anthropic（Claude）、AWS Bedrock、OpenAI、Azure OpenAI、Google、Vertex AI、そして Azure を含む OpenAI Responses API への対応が挙げられています。さらに Custom Endpoints という仕組みで、OpenAI 互換 API をプロキシを介さずに接続できると記載されています。

ローカル／リモートのプロバイダーとしては、Ollama、AMD Lemonade、groq、Cohere、Mistral AI、Apple MLX、koboldcpp、together.ai、OpenRouter、Helicone、Perplexity、ShuttleAI、Deepseek、Qwen などが README に列挙されています。

これが解く課題は明確です。部署ごとに別サービスを契約していた状態を、1 つの UI と 1 つの認証基盤の下に集約できます。モデルの切り替えがユーザー側の操作で完結するため、「要約は安価なモデル、コード生成は高性能モデル」といった使い分けを、契約を増やさずに実現できる設計になっています。

なお、個別プロバイダーごとの具体的な設定例（Ollama の YAML 定義など）は本記事の調査範囲では確認できなかったため提示しません。実際の接続設定を検討する段階では、後述する設定ファイルの公式リファレンスを参照してください。

マルチユーザー認証と管理パネルによる組織運用

2 つ目は、組織で配るための機能が最初から入っていることです。README の Multi-User & Secure Access では OAuth2、LDAP、メールログインへの対応が挙げられ、モデレーションとトークン消費管理のツールが内蔵されていると記載されています。

さらに Admin Panel として、ブラウザ UI からユーザー・グループ・ロール・設定の上書きを管理でき、再デプロイなしで権限を変更できる管理画面が用意されています。この管理画面は Docker Compose のスタックに同梱されると README に明記されています。

個人用途の OSS チャット UI を社内展開しようとすると、ほぼ必ず「誰がどこまで使えるか」の設計で止まります。LDAP や SSO を含む既存の社内認証に載せられること、そして権限変更にデプロイ作業を伴わないことは、情報システム部門が運用を引き受けられるかどうかの分水嶺になります。LibreChat はここを標準機能としてカバーしています。

MITライセンスとセルフホストによるデータ統制

3 つ目はライセンスとホスティング形態です。LibreChat のライセンスは MIT であり、改変や社内向けの内製拡張を行う際の制約が軽いことが利点になります。後述する競合比較のとおり、この点は OSS AI チャット基盤のなかでも差が出る部分です。

README の Configuration & Deployment では、Proxy / Reverse Proxy / Docker での構成に加え、S3 と CloudFront を使ったメディア配信、そして完全ローカル構成とクラウド構成の双方を選べることが記載されています。社内ネットワーク内に閉じた構成から、クラウド上のマルチテナント構成まで、同一の OSS で段階を踏める点は移行計画を立てやすくします。

ここで注意したいのは、セルフホストであること自体が情報管理上の安全を保証するわけではない点です。README の表現は privacy-focused、self-hostable という範囲にとどまり、実際の統制レベルは接続先のモデル API、ネットワーク構成、権限設計の作り込みに依存します。「自社のインフラに置ける」という条件が得られるだけで、統制そのものは設計の責任範囲として残ります。セルフホスト型 OSS の運用設計という観点では、セルフホスト型 OSS チャット基盤 Mattermost のような他カテゴリの事例も参考になります。

エージェント・MCP・Code Interpreterというチャットを超える機能範囲

LibreChat を「ChatGPT 風の UI を持つチャットアプリ」として捉えると、採用判断を誤る可能性があります。エージェント機能群がプロジェクトの中核を占めており、ここを使うかどうかで評価が変わります。詳細は 公式ドキュメントの Agents ページ にまとまっています。

Agentsをノーコードで構築する流れ

公式ドキュメントによると、Agents は複数のモデルプロバイダーを使ってカスタム AI アシスタントをノーコードで作成する機能です。OpenAI の Assistants API や GPTs に近い位置づけですが、対応モデルの範囲がより広いと説明されています。

作成の流れは次のように記載されています。エンドポイントメニューで「Agents」を選んで Agent Builder を開き、名前・説明・システム指示・モデル・アバターを設定します。会話の起点となる Conversation Starters は最大 4 件まで登録できます。続いて Tools と Skills を追加して保存すると、ドロップダウンからの選択、またはチャット入力欄での @ メンションで呼び出せるようになります。

社内運用の観点では、この「ノーコードで作れて、メンションで呼べる」という形が重要です。経理向けの問い合わせ応答アシスタント、開発規約に沿ったレビュー補助アシスタントといった用途別エージェントを、各部署の担当者自身が用意できる余地が生まれます。

File Search・Code Interpreter・MCP・Actionsの役割分担

Agents に追加できるツールは、公式ドキュメントで次の 4 種として説明されています。

Code Interpreter については、README で Python、Node.js（JavaScript / TypeScript）、Go、C / C++、Java、PHP、Rust、Fortran のサンドボックス実行に対応すると記載されています。実装は ClickHouse の code-interpreter をベースとしており、セルフホストが可能です。

Actions は OpenAPI 仕様を起点にツールを生成するため、社内に既存の REST API があれば、仕様書を与えるだけで AI から呼び出せる形に持ち込めます。MCP は外部ツール連携の標準的な口として位置づけられており、リポジトリの topics にも mcp が含まれています。

最新の v0.8.8 では、再利用可能な指示バンドルである Skills（SKILL.md 形式）、Subagents、そして Agent Management API（beta）が加わったことが README の What's New に記載されています。Agent Management API は Agent・Agent ファイル・Skills の CRUD と、OIDC アイデンティティによるマシンクライアント認証に対応し、OpenAPI / Swagger UI が公開されると説明されています。社内の別システムからエージェント定義を管理したい場合の足がかりになります。

ACLとViewer／Editor／Ownerの3段階権限

エージェントを部署横断で共有する運用では、権限設計が避けられません。公式ドキュメントによると、Agent ごとに ACL を持ち、ユーザー単位・グループ単位・ロール単位・全体公開のいずれかで共有できます。権限は Viewer / Editor / Owner の 3 段階で、作成者と管理者は ACL に関わらず全操作が可能と記載されています。

この粒度は「部署内でだけ共有」「全社公開するが編集は作成者のみ」といった典型的な運用を無理なく表現できる水準です。一方で共有時の情報露出には公式が注意喚起しており、この点は後述の運用上の注意点で改めて取り上げます。

ここまでを踏まえると、適合判断の分岐が見えてきます。純粋にチャット UI を一本化したいだけであれば LibreChat の機能は過剰かもしれません。逆に、用途別エージェントの配布や社内 API との連携まで見据えているなら、別途エージェント基盤を用意する必要がなくなる分、選定の合理性は高くなります。

競合OSSとの違い｜Open WebUI・Dify・LobeHub・AnythingLLM

セルフホスト型の AI チャット・エージェント基盤には有力な OSS が複数あります。ここでは GitHub API で取得した指標と、各プロジェクトの README / description の記述に基づいて位置づけを整理します。

リポジトリ指標で見る4プロジェクトの位置づけ

スター数だけを見れば Dify と Open WebUI が LibreChat を大きく上回りますが、4 つの軸で分解すると目的の違いが浮かび上がります。

1 つ目の軸は主眼です。LibreChat は会話 UI そのものが中心、Open WebUI はローカル LLM 運用の総合インターフェース、Dify はワークフロー／パイプラインの構築、LobeHub は複数エージェントの常時運用と、解こうとしている問題が異なります。

2 つ目は実装言語です。LibreChat・Dify・LobeHub は TypeScript、Open WebUI は Python、AnythingLLM は JavaScript が主要言語です。社内で内製拡張や不具合調査を行う前提なら、自チームの得意な言語とスタックを合わせられるかは実務上の選定理由になります。

3 つ目はライセンス形態です。LibreChat と AnythingLLM は MIT として判定されますが、Open WebUI・Dify・LobeHub の 3 件は GitHub 上のライセンス判定が NOASSERTION となっています。これは SPDX の標準ライセンスとして判定されない独自ライセンスまたは改変ライセンスであることを示します。各ライセンスの具体的な制約内容については本記事では断定せず、商用利用やブランド表示に関する条件は各プロジェクトのライセンス原文を個別に確認する必要がある、という点のみ指摘します。

4 つ目は組織運用機能です。認証方式（LDAP / OAuth2 / SSO）、権限の粒度、管理 UI の有無が該当します。LibreChat はここを標準機能として備えており、企業内の複数ユーザーへ配る前提で評価した場合の強みになります。

選定軸別の向き・不向き

上記を要件ベースに裏返すと、次のような対応になります。

ここで挙げた「第一候補」は優劣の評価ではありません。各プロジェクトの README と description が掲げる主眼に照らした対応づけです。実際の選定では複数要件が同時に存在するため、どの要件を最優先に置くかを先に決めることが、比較を前に進める近道になります。なお、セルフホスト型の AI アシスタント OSS という括りでは セルフホスト型 AI アシスタント OSS Octop のような別系統のプロジェクトも存在し、用途が絞られている場合は候補に入ります。

Dockerでの導入手順とlibrechat.yamlの設定

採用判断には「導入にどれだけの前提と作業が必要か」の見積もりが欠かせません。公式ドキュメントの Docker ローカルインストールガイド に記載された手順をもとに、必要な前提と設定ファイルの責務を整理します。手順の網羅よりも「どのファイルが何を決めるのか」の見通しを優先します。

docker composeで起動するまでの最短手順

公式ドキュメントが挙げる前提は Git と Docker（Docker Desktop が推奨）です。リモートサーバー向けの構成は別ガイドに分離されています。ローカル構築の手順は以下のとおり記載されています。

git clone https://github.com/LibreChat-AI/LibreChat.git
cd LibreChat
cp .env.example .env
docker compose up -d

出典: https://www.librechat.ai/docs/local/docker

Windows 環境では cp の代わりに copy .env.example .env を使うと案内されています。初回起動はイメージの取得に数分かかり、起動後は http://localhost:3080 にアクセスします。単一テナント構成では最初に登録したアカウントが管理者になるとドキュメントに明記されているため、検証環境であっても最初のアカウント登録は管理対象として扱う必要があります。

更新手順についても、以下のコマンド列が示されています（Linux / Mac 向けの記載）。

docker compose down

# Linux/Mac
docker images -a | grep "librechat" | awk '{print $3}' | xargs docker rmi

git pull

docker compose pull

docker compose up

出典: https://www.librechat.ai/docs/local/docker

停止・古い LibreChat イメージの削除・ソース更新・イメージ取得・再起動という 5 コマンドで構成されます。古いイメージを削除する行は、git pull で取り込んだ新しい定義と手元の古いイメージが食い違わないようにするための工程です。Windows 環境向けには、同じ目的を PowerShell で実行するコマンド例（docker images -a --filter "reference=..." から docker rmi に渡す形）が別途案内されています。また環境の権限設定によってはコマンドに sudo を付ける必要があるとドキュメントに注記されています。この一連の手順は、後述するバージョン更新の注意点とセットで運用手順に組み込むべき部分です。

ドキュメントには既知の注意点も記載されています。Apple Silicon の Mac では既定の MongoDB イメージが AVX 命令を要求するため起動時にクラッシュすることがあり、上書き設定ファイルで旧バージョンの MongoDB イメージを指定する回避策が案内されています。またポート 3080 が競合する場合はホスト側ポートを変更し、コンテナが即終了する場合は docker compose logs api を確認するよう示されています。

.env・librechat.yaml・docker-compose.override.ymlの責務分担

LibreChat の設定は 3 つのファイルに分かれており、役割の違いを押さえておくと設定変更時に迷いません。

上書き設定ファイルは、example からコピーして作成します。

cp docker-compose.override.yml.example docker-compose.override.yml

出典: https://www.librechat.ai/docs/local/docker

Docker 構成で librechat.yaml を使う場合は、コンテナ内へのマウントが必要です。ドキュメントには以下の記述例が掲載されています。

services:
  api:
    volumes:
      - type: bind
        source: ./librechat.yaml
        target: /app/librechat.yaml

出典: https://www.librechat.ai/docs/local/docker

設定の反映には再起動が必要で、docker compose down のあと docker compose up -d を実行するよう案内されています。

librechat.yaml 自体の仕様は 設定ファイルの公式リファレンス にまとまっています。既定の配置場所は .env と同じプロジェクトルートで、CONFIG_PATH 環境変数を指定すれば別のパスに置けます。ファイル先頭にはバージョン行を持ち、主要な項目は UI オプションを扱う interface と、カスタムエンドポイントを定義する endpoints です。フィールドの完全な一覧は別のリファレンスページに分離されています。

カスタムエンドポイントの設定では、apiKey に user_provided を指定すると、ユーザーが Web UI から自分の API キーを入力できるようになると説明されています。全社で 1 つの API キーを共有するのか、利用者が各自のキーを持ち込むのかという運用方針を、設定ファイルのレベルで選べることになります。

導入に必要な作業量そのものは、Docker Compose の運用経験があるチームにとって大きな負担ではありません。見積もりで重くなるのは、むしろ付随コンポーネントの運用と権限設計です。次のセクションで、その点を公式の記述から確認します。

導入前に確認すべき運用上の注意点

ここまでは採用を支持する側の材料を整理しました。採用判断では、むしろ「何が運用コストとして残るか」を先に把握しておく方が後の手戻りを減らせます。公式の記述に基づいて 4 点を取り上げます。

バージョン更新と実験的機能の扱い

最終 push が 2026 年 10 月 9 日、最新タグ v0.8.8 のタグ付与が 2026 年 10 月 1 日という開発ペースは、機能追加の速さを示す一方で更新負荷の裏返しでもあります。README 自身が「Please consult the changelog for breaking changes before updating.」（更新前に破壊的変更についてチェンジログを確認してください）と明記しており、更新前の changelog 確認を運用手順に組み込む必要があります。v0.8.8 の公式チェンジログ では、運用者向けの YAML・環境変数・既定値・移行に関する変更が設定バージョン別のページに分けて案内されています。

もう一点、機能の成熟度の読み分けが必要です。v0.8.8 で追加された Attached workspaces（Agent ごとの既定ワークスペースを選択し、ツリー検査・ファイル読み取り／検索／編集・時間上限付きの Bash 実行を許可する機能）は、公式に「highly experimental」と明示されています。Agent Plugins も実験的機能として位置づけられています。一方で Agent Management API は beta と表記されています。

つまり、公式自身が成熟度のラベルを付けて区別しているため、本番運用の前提に組み込む機能を選ぶ際はこのラベルを確認すべきです。実験的機能に依存した社内ワークフローを作ってしまうと、次のバージョンで仕様が変わった際の影響範囲が読めなくなります。

なお v0.8.8 では、コード実行とファイル書き込みに対する承認制御（Ask / Allow / Deny、および信頼できる環境向けの Full access）が用意されたことも README に記載されています。エージェントにコード実行を許す構成を採る場合は、この制御レベルを運用ポリシーとして先に決めておくのが妥当です。

権限設計とエージェント共有時の情報露出

エージェント共有に関して、公式ドキュメントは明確な注意喚起を行っています。指示文や添付ファイルは Editor 以上の権限を持つユーザーにのみ表示されますが、会話を通じて Agent が内容を外部に漏らす可能性があるため、公開前に指示文を堅牢にしておく必要があるという記述です。

これは権限設定だけでは情報露出を防ぎきれないという意味です。システムプロンプトに社内の非公開情報や接続先の詳細を書き込んだまま全社公開すると、Viewer 権限のユーザーが会話経由でその内容を引き出せる余地が残ります。全社公開するエージェントの指示文には何を書かないか、というルールを運用規程として先に決めておく必要があります。

付随コンポーネントの運用負荷とOpen Issuesの読み方

LibreChat は単一のアプリケーションコンテナで完結する構成ではありません。README の記述からは、MongoDB、会話検索、RAG API（LibreChat-AI/rag-api として別リポジトリで公開）といった複数のコンポーネントが関わる構成であることが読み取れます。Resumable Streams では、接続断後の応答再開とマルチタブ／マルチデバイス同期に加え、Redis を併用した水平スケール構成への対応が挙げられています。

これは「Docker Compose で立ち上がる」という手軽さの裏側に、データストアとキャッシュ層の運用が含まれることを意味します。バックアップ、バージョン更新、容量監視の対象が増えるため、専任の運用担当を置けない場合はマネージドな SaaS と総コストを比較する方が合理的な場面もあります。前述した Apple Silicon 環境での MongoDB イメージの問題も、この付随コンポーネント起因の事例です。

Open Issues は 884 件です。この数字単体では品質の良否を判断できません。スター数 45,469・フォーク数 9,335 という規模のプロジェクトでは、機能要望や質問も Issue として積み上がるためです。

実務的に意味があるのは、自社が使おうとしている機能領域に未解決の Issue が集まっていないかを、採用判断の前に検索して確認することです。認証方式、特定のモデルプロバイダー、Docker 構成など、依存する範囲を絞って Issue を読むことで、導入後に遭遇しうる既知の問題を事前に把握できます。

LibreChat採用判断のチェックリスト

ここまでの内容を、要件と適合の対応として畳みます。新しい情報は加えず、判断を言語化するための整理です。

LibreChat が適合しやすい条件

• 複数の商用 AI API を横断して使い分けたく、契約とコストを 1 箇所に集約したい
• 既存の ChatGPT 利用者が多く、操作感を大きく変えずに基盤だけ差し替えたい
• LDAP・OAuth2・SSO を含む既存の社内認証に載せる必要がある
• MIT ライセンスのもとで改変・内製拡張を行う前提がある
• 用途別エージェントの配布や社内 API 連携（MCP / Actions）まで視野に入っている
• Docker Compose とデータストアの運用を引き受けられるチームがある

他候補を先に検討すべき条件

• Ollama 等のローカル LLM 運用が中心で、RAG の拡張性を最優先したい（Open WebUI）
• 会話 UI よりも業務フロー・パイプラインの GUI 構築が主目的である（Dify）
• 複数エージェントの常時稼働と運用管理が中心課題である（LobeHub）
• ローカル完結のドキュメント対話に用途が絞られている（AnythingLLM）
• 運用担当を置けず、マネージドな SaaS の方が総コストで有利と見込まれる

次の確認先としては、機能の全体像とバージョンごとの変更点を追える公式リソースが起点になります。LibreChat 公式ドキュメント で機能と設定のリファレンスを確認し、依存する機能領域の成熟度ラベル（実験的 / beta / 安定）を読み分けたうえで、自社要件に照らした検証計画を立てるのが現実的な進め方です。

関連情報

社内向け AI チャット基盤の構築や、OSS を起点とした内製開発の進め方についてご検討中の方は、お問い合わせフォーム からご相談いただけます。要件が固まる前の技術選定の段階からでもご相談を承っています。