2026.09.16 AI

LibreChatとは？Docker構築手順と社内AIチャット基盤の採用判断

LibreChatは、OpenAI・Anthropic・Googleなど複数のモデルを1つの画面から切り替えて使えるMITライセンスのチャット基盤です。GitHubのスターは44,036、forkは9,042（2026年9月16日時点）。docker compose up -d の一行で立ち上がる手軽さが知られていますが、既定の設定ファイルは誰でも登録できる状態で、会話検索は無効、コンテナのイメージは開発版の最新を引く指定になっています。この記事では、起動する6コンテナの内訳、初回起動の手順、社内へ配るときに書き換える設定、RAGとMCPを足したときの費用、受託開発で採用してよい条件と見送るべき案件の型を扱います。数値と既定値は公式ドキュメントとGitHub上の設定ファイルにあたって確認しました。

まとめ：LibreChatを社内基盤に選ぶ条件と既定のまま出せない3点

LibreChatを入れるかどうかは、機能表ではなく運用体制で決まります。モデルのAPIキーを会社で一括管理し、月に一度はコンテナを上げ直す担当者がいるなら選択肢に入ります。担当者が決まらないなら、SaaSの法人プランを買う方が総額では安い。

既定値のまま社内に出せない箇所は3つあります。第一に ALLOW_REGISTRATION=true。URLを知っている人が誰でもアカウントを作れる状態で、社内LANの外に置けば外部からも登録できます。第二に SEARCH=false。検索用のMeilisearchコンテナは起動するのに、会話の全文検索は効きません。第三に、公式のdocker-compose.ymlがAPIサーバーに開発版イメージの latest を指定している点です。

この3点を先に潰してから、モデル接続とRAGの設計に進んでください。逆にすると、利用者を集めた後で認証方式を変えることになり、既存アカウントの扱いで手戻りが出ます。

LibreChatの構成要素とdocker composeで起動する6コンテナの役割分担

公式リポジトリのdocker-compose.ymlには6つのサービスが定義されています。単一コンテナのアプリではなく、データベースと検索エンジンとベクトルストアを含む構成です。内訳を知らずに入れると、バックアップ対象を見誤ります。

apiとmongodbとmeilisearchとvectordbが持つ役割の切り分け

APIサーバーは registry.librechat.ai/danny-avila/librechat-dev:latest を使い、.env の PORT（既定3080）で待ち受けます。会話とユーザー情報の保存先はMongoDB 8.0.20で、コンテナは mongod --noauth つまり認証なしで起動し、ホストの ./data-node にデータを置きます。会話の全文検索はMeilisearch v1.35.1、ファイルのベクトル検索はpgvector 0.8.0（PostgreSQL 15ベース）が担当し、その前段にrag_apiコンテナが立つ構成です。6つめは管理画面のadmin-panelで、3000番で待ち受けます。

役割が分かれている分、消えて困るデータも4か所へ分散します（退避先は後述）。同じくOSSでチャットUIを立てる構成としてはOllamaとOpen WebUIでファイルをアップロードしRAGチャットを実現する方法で扱った組み合わせがありますが、LibreChatは検索とベクトルストアを最初から別コンテナに分けている点が違います。

vectordbの認証情報は POSTGRES_USER: myuser と POSTGRES_PASSWORD: mypassword がそのまま書かれています。同じホストに他のサービスが同居する構成では上書きしてください。

SEARCH=falseが既定でMeilisearchの全文検索が効かない理由

配布される .env.example では SEARCH=false かつ MEILI_MASTER_KEY が空です。公式の環境変数リファレンスにも、検索には SEARCH=true とマスターキーの両方が要ると明記されています。キーは有効なUTF-8で16バイト以上が条件です。

ここが問い合わせの発生源になります。Meilisearchのコンテナは docker compose ps で起動中と表示されるため、利用者から「検索窓に入れても過去の会話が出てこない」と言われて初めて気づく形になりがちです。既存の会話は再インデックスが走るまで検索に乗らないため、利用者を集める前に有効化しておいてください。

MITライセンスとスター44,036件が示すOSSとしての継続性

ライセンスはMITで、GitHubのリポジトリで確認できます。社内向けにロゴや文言を差し替えて配布しても、著作権表示を残せば問題ありません。

スター44,036・fork9,042は2026年9月16日にGitHub APIで取得した実測値で、最終コミットも同日です。ただしOSSの継続性は個人メンテナへの依存度でも測るべきで、このプロジェクトは作者個人のリポジトリ配下にあります。基幹業務に載せるなら、フォークを自社側に持つ体制まで見ておいてください。

git cloneから3080番ポート表示までの構築手順と.envの必須4値

前提はGitとDockerだけです。公式のDocker導入手順ではリポジトリ取得・環境ファイル複製・起動の流れが示されており、ここではそのままでは止まる箇所を補います。

git cloneと.env.exampleのコピーから始める初回起動の4コマンド

作業ディレクトリで次の4行を順に実行します。Windowsでは3行目を copy .env.example .env に読み替えます。

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

初回はイメージ取得で数分かかります。完了後、ブラウザで3080番ポートを開くとログイン画面が出ます。公開前に自分の分だけ登録し、次のh3で触れる登録制限を掛けてから利用者へ案内する順序が安全です。

Apple Silicon搭載のMacでは、既定のMongoDBイメージがAVX命令を前提にしているため起動に失敗します。公式の回避策は docker-compose.override.yml で互換イメージに差し替える方法で、開発機がMacの案件は初日にここで止まります。

CREDS_KEYとJWT_SECRETに入れる乱数値の生成と桁数の条件

複製した直後の .env は、認証と暗号化に使う値が空欄です。公式ドキュメントの条件は明確で、CREDS_KEY は32バイト（16進数64文字）、CREDS_IV は16バイト（16進数32文字）、JWT_SECRET と JWT_REFRESH_SECRET はいずれも32バイト以上です。

値の生成はOpenSSLで済みます。openssl rand -hex 32 が64文字、openssl rand -hex 16 が32文字を返すので、前者を CREDS_KEY とJWT系に、後者を CREDS_IV に入れてください。

この4値を空のまま本番に出すと、利用者が画面から入れたAPIキーを保存できず、再ログインのたびに入力し直す状態になります。検証環境と本番で同じ値を使い回すのも避けてください。検証環境の .env が共有ドライブに残っていると、そこから本番のトークンを偽造できます。

user_providedのままか環境変数で配るかのAPIキー設計

.env.example では OPENAI_API_KEY・ANTHROPIC_API_KEY・GOOGLE_KEY がいずれも user_provided になっています。これは「利用者が画面から自分のキーを入れる」方式で、会社としてキーを配らない前提の既定値です。

社内基盤として配るなら、この値を実際のキーに置き換えます。分かれ目は費用の付け替え先です。部署ごとに予算を持たせるなら user_provided を残し、情報システム部門が一括で払うなら実キーを入れます。

librechat.yamlでのモデル接続設定と社内配布時の登録制限の書き方

モデルの追加と画面の挙動は librechat.yaml で制御します。公式のCustom Configでは現行スキーマとして version: 1.3.5 が示されています。認証まわりは .env 側の担当です。

endpoints.customでOpenAI互換APIとOllamaをつなぐ書式

OpenAI互換のエンドポイントであれば、endpoints.custom に並べるだけで画面のモデル一覧に出ます。公式が示すOllamaの設定例は次の形です。Docker上のLibreChatからホストのOllamaを見るときは、ホスト名を host.docker.internal に読み替えます。

version: 1.3.5
endpoints:
  custom:
    - name: "Ollama"
      apiKey: "ollama"
      baseURL: "http://host.docker.internal:11434/v1/"
      models:
        default: ["llama2", "mistral", "codellama"]
        fetch: true
      titleConvo: true
      titleModel: "current_model"
      modelDisplayLabel: "Ollama"

fetch: true はエンドポイント側が返すモデル一覧を起動時に取りに行く指定です。titleModel に current_model を置くと会話タイトルの生成にも同じモデルを使うため、GPU1枚の環境で余計なロードが走りません。同じ書式は自前の推論サーバーにも通用し、vLLMのOpenAI互換サーバーを立てている環境なら baseURL をそちらへ向けるだけで接続できます。

ALLOW_REGISTRATIONを止めてドメイン限定に切り替える手順

既定の .env.example は ALLOW_REGISTRATION=true と ALLOW_EMAIL_LOGIN=true です。公式の認証ドキュメントにある ALLOWED_REGISTRATION_DOMAINS に自社ドメインを列挙すれば、そのドメインのメールだけが登録できます。社外公開のサーバーなら、登録自体を false にして管理者が手動で払い出す方が確実です。

セッションの既定値も確認しておいてください。SESSION_EXPIRY は15分、REFRESH_TOKEN_EXPIRY は7日です。共用端末が混ざる職場では後者を短くし、個人端末のみなら伸ばして再ログインの手間を減らします。

OIDCやSAMLにも対応しているため、社内IdPがあるならそちらへ寄せてください。メール認証を残したままIdPを足すと、同一人物が2つのアカウントを持ち、会話履歴が分断されます。

CONFIG_PATHとdocker-compose.override.ymlでの反映

librechat.yaml はイメージの中に入っていないため、置いただけでは読まれません。docker-compose.override.yml でホスト側のファイルをマウントするか、.env の CONFIG_PATH で読み込み先を指定します。設定を変えたのに画面が変わらない相談は、ほぼマウント漏れです。

overrideファイルは docker-compose.override.yml.example を複製して作ります。本体のdocker-compose.ymlは先頭に「直接編集せずoverrideを使うこと」と書かれており、直接書き換えると次回の git pull で衝突します。ポート変更やMongoDBイメージの差し替えも同じファイルで扱ってください。なおYAMLの構文エラーがあると設定が丸ごと無視され、起動ログに警告が出るだけで本体は動き続けます。

RAG APIとMCPサーバーを足したときの構成変化と追加で出る費用

ファイルを読ませる機能と外部ツール連携は、どちらも既定のcomposeに土台が入っています。有効化の作業は軽く、月額に効くのは埋め込み処理の呼び出し回数です。

pgvectorとEMBEDDINGS_PROVIDERで決まる埋め込み費用の内訳

公式のRAG API解説によると、ベクトルはpgvector上の pgdata2 ボリュームに置かれ、埋め込みプロバイダは EMBEDDINGS_PROVIDER で選びます。既定は openai、既定モデルは text-embedding-3-small です。

費用が読みにくいのは、課金対象が会話数ではなくアップロードされたファイルの総トークン量である点です。100ページのPDFを10人が別々に上げれば、同じ内容を10回埋め込みます。共有ナレッジは管理者が1度だけ登録し、個人ファイルのみ各自に開放する切り分けを先に決めてください。

API費用をゼロにするなら、EMBEDDINGS_PROVIDER をollamaにして nomic-embed-text を使う構成へ切り替えられます。日本語の検索精度は落ちるため、社外秘の資料だけローカル埋め込みにする分け方が現実的です。

customUserVarsで利用者ごとにAPIキーを持たせるMCP設定

外部ツール連携は mcpServers ブロックで定義します。MCP（Model Context Protocol）の仕組みそのものは他クライアントと共通で、LibreChat側の特徴は接続方式を4種類（stdio・sse・websocket・streamable-http）から選べる点と、利用者ごとに認証情報を持たせられる点です。

mcpServers:
  backlog:
    type: streamable-http
    url: "https://example.com/mcp"
    headers:
      X-User-ID: "{{LIBRECHAT_USER_ID}}"
      X-Auth-Token: "{{API_KEY}}"
    startup: true
    customUserVars:
      API_KEY:
        title: "APIキー"
        sensitive: true

公式のMCP Serversリファレンスにある {{LIBRECHAT_USER_ID}} のようなプレースホルダを使うと、リクエストヘッダに利用者の識別子が入ります。チケット管理や社内検索のように「誰が聞いたか」で結果が変わるツールでは、この仕組みがないと全員が共通アカウントで見ることになり、権限管理が崩れる。sensitive: true を付けた値は画面上でマスクされます。

既定のdev:latestを固定タグへ置き換える運用の判断基準

ここからは日本語の導入記事がほとんど触れていない運用面です。バージョンの扱いを決めずに本番へ出すと、ある朝の再起動で画面が変わります。

v0.8.7以降がすべてrc扱いでlatest取得が404になる事実

GitHubのリリース一覧を2026年9月16日にAPIで確認したところ、最新はv0.8.8-rc3（2026年9月15日公開）、その前がv0.8.8-rc2（9月3日）、v0.8.7（6月24日）でした。特筆すべきは、これらがすべてprereleaseフラグ付きで、GitHubの「最新リリース」を返すAPIが404になる点です。

つまり「安定版はどれか」を機械的に判定できません。rc表記が付かない直近のタグはv0.8.7で、実務上はこれを基準に置きます。更新は月1本前後で、検証環境で1週間動かしてから本番タグを上げる段取りが要ります。

docker compose downから始める更新手順とデータの退避先

公式が案内する更新手順は、コンテナを停止し、既存イメージを削除し、git pull と docker compose pull を経て起動し直す流れです。イメージ削除を挟むのは、同じ latest タグのまま中身が入れ替わるためです。

ここで最初の論点に戻ります。公式のdocker-compose.ymlはAPIサーバーに librechat-dev:latest を指定しており、docker compose pull のたびに開発版の最新が降ってきます。本番では、overrideファイルで image を v0.8.7 のような固定タグに書き換え、上げる時期を自分で決めてください。

退避対象は4つです。会話データの ./data-node、検索インデックスの ./meili_data_v1.35.1、アップロードファイルの ./uploads、ベクトルの pgdata2 ボリューム。インデックスとベクトルは再生成できるため、日次のバックアップ対象は前2者に絞れます。

受託開発でLibreChatを採用してよい条件と見送るべき案件の型

立場を明確にします。LibreChatは「社内に配る汎用チャット画面」としては完成度が高く、「業務システムに組み込むチャット部品」としては向きません。

採用してよい3条件＝内製運用・複数モデル比較・データ持ち出し制限

採用が噛み合うのは次の3つが揃う場合です。コンテナを触れる担当者が社内にいること。複数のモデルを同じ画面で比べたい要件があること。会話ログを外部SaaSに置けない制約があること。3つめだけが理由なら、法人向けSaaSのデータ保持設定で足りる場面も多く、そこは正直に伝えるべきところです。

3条件が揃った企業では強い選択肢になります。モデルの乗り換えが設定ファイルの数行で済み、ベンダーロックインを避けられるためです。設計からモデル選定、社内展開までを外部に任せたい場合は、AIチャットボット開発で要件整理から支援しています。

見送る場面＝担当者不在の本番運用と業務ワークフローへの組み込み

見送るべき型は2つです。1つは、月次の更新作業を担える人が決まらない案件。OSSは入れた日が最も安全で、放置した分だけ脆弱性が積み上がります。もう1つは、基幹システムの画面内にチャットを埋め込みたい案件。LibreChatは独立したWebアプリであり、iframeで押し込む構成は認証とセッションの二重管理を生みます。

「とりあえず社内でAIを触らせたい」という動機だけの案件も、開始前に止める価値があります。目的が定まらないまま配ると、3か月後には月に数人しか開かない画面が残り、APIキーの管理コストだけが続く。用途を2つか3つに絞り、その業務の担当部署から先に配る進め方が現実的です。

Difyや自前実装と比べたときのLibreChatの守備範囲の線引き

比較の軸は「作りたいものが画面か、処理か」です。LibreChatは画面を配る道具で、条件分岐や外部API呼び出しを含む処理を組みたいならDifyでのチャットボット構築の方が近道です。両方を入れて、汎用チャットはLibreChat、業務ごとのボットはDifyと使い分ける構成も成り立ちます。

観点 LibreChat Dify
主な用途 社内配布のチャット画面 業務別ボットの構築
モデル切替 画面上で随時 アプリ単位で設定
処理の記述 不可（設定のみ） ワークフローで記述
外部連携 MCPサーバー経由 ツール・ノード

モデルをすべて自社内で完結させたい要件なら土台が変わります。推論サーバーの選定と日本語モデルの評価が先に来るため、ローカルLLMの事例と導入手順を踏まえてハードウェアの見積もりから始めてください。LibreChatは後から載せる画面として足せます。

よくある質問

導入検討の場で挙がる質問を5つ取り上げます。回答は公式ドキュメントと設定ファイルの実測に基づきます。

LibreChatは日本語で使えますか？

画面の言語設定に日本語が含まれており、メニューやボタンは日本語で表示されます。会話そのものの品質は接続先のモデル次第で、LibreChat側が翻訳や加工をすることはありません。ファイル検索の埋め込みモデルは既定が text-embedding-3-small で、専門用語の多い社内文書ではヒット率を自社データで実測してから本番判断にかけてください。

商用利用や社内配布にライセンス上の制限はありますか？

MITライセンスのため、商用利用・改変・再配布のいずれも可能です。条件は著作権表示とライセンス文を残すことだけで、顧客向けシステムの一部として納品する場合も同じ扱いになります。ただし接続先のモデル提供元には別途の利用規約があり、入力データの学習利用可否や地域制限は個別に確認が要ります。

ChatGPT Enterpriseの代わりになりますか？

画面の機能としては近い位置にありますが、運用責任の所在が正反対です。SaaSなら可用性とアップデートは提供元の責任で、LibreChatでは自社が負います。月額はサーバー費用とAPI従量課金だけで済むため、100人規模なら費用差は大きく出ます。その差額を運用工数で相殺できるかが判断軸で、担当者の工数を月8時間と置いて計算してみてください。

Ollamaでローカルモデルだけで動かせますか？

外部APIを一切使わない構成も組めます。librechat.yaml の endpoints.custom にOllamaを登録し、baseURL を host.docker.internal 経由で11434番に向けるだけです。埋め込みも EMBEDDINGS_PROVIDER をollamaに変えればローカルで完結。ただし応答速度はGPUの有無で大きく変わり、CPUだけの環境では実用に届かない場面が出てきます。

アップデートで設定やチャット履歴は消えますか？

消えません。会話はホストの ./data-node、アップロードファイルは ./uploads に置かれ、コンテナの入れ替えとは独立しています。ただし .env と librechat.yaml は git pull で衝突しうるため、更新前に控えを取ってください。MongoDBのメジャーバージョンが上がる更新では移行手順がリリースノートに載るので、タグを上げる前に目を通す運用にしておくと安全です。

関連記事

この記事に関連するサービス

資料請求

RELATED POSTS 関連記事

一覧へ戻る