ローカルLLMで社内文書を活用：AnythingLLMの選び方とチーム導入

5人のチームでローカルLLMを使うなら、AnythingLLMは、Docker版を自社でホストし、個別のログインとローカルモデルを組み合わせる構成が適しています。文書チャットを自社サーバー内で運用できますが、クラウドモデルを選ぶと、回答に使うテキストはそのプロバイダーへ送られます。ファイルの保存先がローカルというだけでは、会話を社内だけにとどめられるとは限りません。

AnythingLLMは、まず社内文書への質問に答える仕組みを作り、その後でアシスタントに必要なツールを追加したい場合に向いています。個人ならDesktop、共有サーバーならDocker、インフラ運用をMintplex Labsに任せるならマネージドのCloudを選びます。

2026年11月5日に、プロジェクトの公式サイト、ドキュメント、GitHubリポジトリで確認しました。 以下は、公開ドキュメントに基づく導入手順に、推奨するアクセス制限を加えたものです。性能試験やセキュリティ試験を実施済みという意味ではありません。

AnythingLLMとは？用途に合うエディションの選び方

AnythingLLMは、選んだモデルを中心に、チャット画面、文書検索、ワークスペース、エージェントを組み合わせるアプリです。チームで使うサーバー版は、アプリをコンテナで動かすソフトウェアであるDockerで提供されます。回答を生成するのは大規模言語モデル、つまりLLMです。AnythingLLMは、業務上の質問に答えるための文書、会話、利用可能なツールをモデルに渡します。

社内図書館に例えると分かりやすいでしょう。ワークスペースは閲覧室、文書は書架です。検索インデックスが役立つ箇所を探し、モデルが目の前に用意された文章から回答を書きます。その司書を社内に置くか、外部サービスに任せるかによって、テキストを見る相手が変わります。

DesktopとDockerの機能比較では、ユーザー管理とワークスペースのアクセス制御はDockerの機能です。全員のノートパソコンにDesktopを入れても、一元管理できるチーム向けサービスにはなりません。

マネージドCloudは、Mintplexが運用する分離されたAWSインスタンスを使います。他の顧客から分離される利点はありますが、ファイルを自社設備内に置く要件は満たしません。また、公開されている制限により、組み込みLLM、MCPによるツール接続、独自コードのエージェントは使えません。MCPは、エージェントを外部ツールにつなぐための標準です。モデルについては、対応するモデルサービスに接続して使います。組み込みエージェントと独自の実行コードは、別の機能として考える必要があります。

経営者が決めるのは、誰がサーバーの保守を担うかです。IT担当者が確認するのは、どのデータや認証情報が外部に出てよいかです。「文書は自社の機器内に置く」が要件なら、Dockerとローカル処理から始めます。

ローカルLLMの選定はアプリの導入と分けて考えます

AnythingLLMはローカルとクラウドのモデルプロバイダーに接続できるため、アプリを導入しても特定のモデル系列に縛られるわけではありません。プロバイダー設定では、システム全体の既定値、ワークスペースごとの上書き、エージェント用モデルを区別しています。

組み込みエンジンは、モデルを配信・実行する層であるLemonadeと、対応するローカルモデルを動かすソフトウェアのllama.cppを使います。ダウンロード可能なモデルの配布形式であるGGUFファイルに対応しています。ドキュメントにはLlamaとPhiの例があり、DockerのガイドではQwenも紹介されています。同じ系列ならハードウェア要件も同じだと思い込まず、使うマシンに収まるモデルを選びます。

外部のローカル接続先には、モデル用のデスクトップアプリ兼サーバーであるLM Studioや、LocalAIがあります。クラウドではOpenAIのチャットモデル、AnthropicのClaudeモデル、Google Geminiに加え、汎用のOpenAI互換エンドポイントにも接続できます。リポジトリの連携一覧には、ほかのプロバイダーも掲載されています。

これらは接続先の選択肢であり、どのモデルも文書、画像、ツール呼び出しを同じ水準で扱えるという保証ではありません。読みやすい回答を書けても、ツールを選び間違えたり、長い指示を守れなかったりするモデルもあります。

AnythingLLMとOllamaは連携できます

Ollamaは独立したモデル実行エンジンで、AnythingLLMにローカルで生成した回答を提供できます。AnythingLLMは、そのエンジンの周りに文書ワークスペースとアクセス制御を加えます。すでにローカルモデルのサービスが安定して動いているなら、それを使い続けるところから始めるのが妥当です。

新規導入なら、後述の手順で扱うDockerの任意機能である組み込みモデルエンジンも使えます。チーム向けエディションを選んだからといって、別のモデルサーバーを追加する必要はありません。

機密情報を扱う業務ワークスペースでは、ローカルのチャットモデルを選び、エージェント用モデルも確認します。別のワークスペースでは、データポリシーが許せばクラウドプロバイダーを使えます。ただし、埋め込みモデルは別に設定するシステム全体の共通項目です。この柔軟性には、その前提が伴います。

AnythingLLMのRAGは文書をどう活用しますか？

AnythingLLMの文書検索は、モデルに関連箇所を渡す仕組みです。すべてのファイルをモデルに恒久的に学習させるわけではありません。検索拡張生成、つまりRAGでは、元の資料を検索し、選んだテキストをモデルに送る質問に挿入します。

埋め込みとは、関連するテキストを照合するための数値表現です。アプリは文書をチャンクに分割し、埋め込みを生成して、検索できるインデックスを保存します。質問が来ると、検索によって回答に役立つチャンクを選びます。モデルのコンテキストウィンドウは、指示、履歴、取り出した文章を含め、一度に参照できるテキストの量です。

文書の渡し方は、実務上は次のように使い分けます。

• チャットに文書を添付する：そのファイルについて支援が必要な場合に使います。AnythingLLMは既定で全文を挿入しますが、コンテキストウィンドウの制約を受けます。添付ファイルの範囲は、そのワークスペースとスレッドに限られます。
• ワークスペースに文書を埋め込む：繰り返し使うナレッジにしたい場合に使います。そのワークスペース内の各スレッドと、アクセス権を持つユーザーが利用できるようになります。

文書の取り扱いガイドは、この共有範囲の変化を明示しています。最初の会話を個人的なものと感じていたとしても、責任者の下書きを共有ワークスペースに移せば、それは共有の判断です。

例えば、承認済みの返品規定をサポート用ワークスペースに入れます。「返品を承認する前に、担当者は何を確認すべきですか？」は検索に適した質問です。一方、「全ファイルにある例外をすべて列挙してください」には、関連する抜粋だけでは裏付けられない広い範囲の確認が必要です。回答を網羅的なものとみなす前に、元の規定を確認します。

最初の文書活用の試行には、Queryモードを使います。アップロードした資料から回答し、関連情報がない場合はその旨を伝える設計です。Chatモードはモデルの一般知識も使い、Agentモードはツールを呼び出せます。これらはドキュメントに記載されたチャットモードです。新しいワークスペースはAgentモードで始まる場合があるため、意識して選びます。

AnythingLLMに社内の機密文書を預けても安全ですか？

AnythingLLMでは構成要素を自分たちで選べます。ただし、プライバシーはテキストを扱うすべての構成要素の設定次第です。「ローカル」という表示より、実際にどこで処理されるかを確認することが大切です。

ファイルと保存済みテキスト。 Desktopはアプリのデータをローカルの保存ディレクトリに置きます。ストレージのリファレンスでは、解析済み文書、埋め込みのキャッシュ、データベース、直接アップロードしたファイルが挙げられています。Dockerでは、アプリの保存ディレクトリをサーバー上に永続化します。マネージドCloudでは、同じ種類のアプリデータがホスティング先のインスタンスに置かれます。

埋め込みとインデックス。 既定のLanceDB設定は、ベクトルインデックスをAnythingLLMのインスタンス上に保存します。テキストをローカルで処理するなら、組み込みの埋め込み機能を使い続けます。クラウドの埋め込みプロバイダーを選ぶと、生成したベクトルをローカルに保存していても、埋め込み対象のテキストはそのプロバイダーに送る必要があります。リモートのベクトルデータベースを選べば、インデックスの保存先も外部に増えます。埋め込みとインデックス化したテキストは、匿名化されたものではなく業務データとして扱います。

回答のリクエスト。 クラウドのチャットモデルには、回答に使うプロンプト内容、つまり質問、渡された会話の文脈、検索された文書テキストが送られます。文書の添付やピン留めによって、全文が渡されることもあります。元のPDFがサーバーに残っていても、機密の文章は外部に出る可能性があります。送信先のコピーには、そのプロバイダーの利用規約と保持設定が適用されます。AnythingLLMがリモート推論へのリクエストを社内にとどめることはできません。

エージェントと外部サービス。 Web検索、外部API、MCPツールは、情報を外部に送ることがあります。ローカルモデルを使っても、外部サービスまでローカルになるわけではありません。完全に社内向けの文書アシスタントなら、外部スキルを無効にし、機密ファイルを追加する前に利用可能なツールを確認します。

特に重要なのが、埋め込み設定のドキュメントにある、埋め込み機能はシステム全体で共通、チャットモデルはワークスペースごとに変更可能という点です。ローカルのチャットモデルを使うワークスペースでも、文書がクラウドの埋め込みサービスに送られる可能性があります。機密業務と外部処理を許す業務で埋め込みの方針を分ける必要があるなら、ワークスペースのモデル上書きで分離できると思わず、インスタンスを分けます。

削除とアクセスの解除も区別します。ワークスペースから文書を取り除いても、解析済みファイルとキャッシュは文書ライブラリに残ります。プライバシーと削除のガイドによると、ワークスペースを横断して解析済みの元データと埋め込みキャッシュを削除するには、My Documentsから削除します。バックアップや外部サービス上のコピーには、別途保持期間の管理が必要です。

テレメトリーも、モデルへの通信とは別の設定です。利用状況のテレメトリーはPrivacy、またはDISABLE_TELEMETRY=trueで無効にできます。それによって、設定済みのクラウドプロバイダー、ツール接続、モデルのダウンロードが無効になるわけではありません。

Docker版を5人のチームで使うための導入手順

Linuxサーバー、永続化したアプリ用ストレージ、ローカルモデル、個別アカウントを用意して始めます。以下は、新規インストールでDockerが導入済みであり、IT担当者が既存のプライベートネットワークとサーバー上のHTTPSリバースプロキシを通じて、認証付きアクセスを提供できる前提です。

Dockerのシステム要件にある最低限の目安は、アプリ本体に対してRAM 2GB、2コアCPU、ストレージ5GBです。ローカル推論や5人の同時利用を保証する構成ではありません。モデル、文書、同時リクエストに応じてメモリとディスクを追加します。IntelまたはAMDのマシンで既定のLanceDBを使う場合は、サーバーや仮想マシン内でAVX2が利用できるかを確認します。ARM64は別のビルドを使います。

1. 1

   永続ストレージを作り、アプリを起動します

   サーバーの運用担当者として実行します。公式のインストールコマンドを基に、HTTPSプロキシ向けにWebポートをループバックにバインドし、再起動設定、テレメトリーの無効化、ローカル推論の有効化を加えています。

   export ANYTHINGLLM_STORAGE="$HOME/anythingllm"
   mkdir -p "$ANYTHINGLLM_STORAGE"
   touch "$ANYTHINGLLM_STORAGE/.env"
   sudo chown -R 1000:1000 "$ANYTHINGLLM_STORAGE"
   
   docker pull mintplexlabs/anythingllm:latest
   docker run -d \
     --name anythingllm \
     --restart unless-stopped \
     -p 127.0.0.1:3001:3001 \
     --cap-add SYS_ADMIN \
     -v "$ANYTHINGLLM_STORAGE:/app/server/storage" \
     -v "$ANYTHINGLLM_STORAGE/.env:/app/server/.env" \
     -e STORAGE_DIR=/app/server/storage \
     -e DISABLE_TELEMETRY=true \
     -e ENABLE_BUILT_IN_LLM=true \
     mintplexlabs/anythingllm:latest

   マウントによって、コンテナを置き換えてもデータが残ります。所有者の設定は、イメージのドキュメントに記載されたユーザー1000:1000に合わせています。保存エラーが出ても、誰でも書き込めるディレクトリにして解決しないでください。SYS_ADMINは公開コマンドに沿った指定ですが、コンテナに広範な権限を与えるため、管理されたインフラ上で運用します。詳細は公式のDockerインストール手順を参照してください。

2. 2

   ローカルモデルを選び、文書処理もローカルに保ちます

   初期設定でBuilt-inを選び、サーバーに適したモデルをダウンロードします。埋め込み機能は組み込みのものを、ベクトルデータベースはローカルのものを使い続けます。業務ファイルをアップロードする前に、Settings > AI Providers > LLMで選択中のモデルを確認します。

   Dockerの組み込みモデルガイドでは、コンテナ起動時にENABLE_BUILT_IN_LLM=trueを指定する必要があります。マウントした.envに書くだけではエンジンは有効になりません。上のコマンドはCPUで推論します。NVIDIAのアクセラレーションを使う場合は、ガイドにあるContainer Toolkitの前提条件を満たし、--gpus allを追加します。AMDとIntelのGPUには、それぞれデバイスとグループの設定があります。

   インターネット接続があるうちに、エンジン、モデル、必要なランタイムをダウンロードします。全員を招待する前に、試行対象の業務でCPUの性能を確かめます。組み込みエンジンが同時に読み込めるモデルは1つなので、共有での試行も1つのモデルから始めます。

3. 3

   チームに公開する前に個別ログインを有効にします

   サーバー上でhttp://127.0.0.1:3001を開くか、管理用トンネルでそのループバックのサービスに接続します。Security & Accessでマルチユーザーモードを有効にし、最初の管理者アカウントを作ります。いったんログアウトされるので、新しい認証情報でログインし直します。

   この5人の例では、ユーザー管理から同僚4人を作成または招待し、それぞれにDefaultロールを付けます。自分のAdminアカウントと合わせて5人です。ロールのドキュメントによると、Defaultユーザーがチャットできるのは、明示的に追加されたワークスペースだけです。Managerはすべてのワークスペースを閲覧できるため、特定の部署の文書だけを見る同僚には権限が広すぎます。Adminはシステム全体にアクセスできます。ドキュメント上、マルチユーザーモードへの切り替えは元に戻せません。

4. 4

   ワークスペースを作り、各自のブラウザーから接続します

   承認済みの手順書用にShared Operationsを作り、5人全員のアカウントを追加します。アクセスを制限する資料にはOwnersを作り、利用すべき人だけを割り当てます。文書はそれぞれ適切なワークスペースに置きます。機密資料をShared Operationsに埋め込んで、プロンプトで隠そうとしてはいけません。

   既存のHTTPSリバースプロキシで、チーム用に選んだホスト名への接続を、このサーバーのhttp://127.0.0.1:3001に転送します。ネットワークアクセスもスタッフに制限します。この構成では、Webポートを直接外部公開しません。各メンバーはHTTPSのアドレスを開き、自分のアカウントでログインします。

5. 5

   利用を広げる前に受け入れ確認を行います

   承認済みの少量の文書と、代表的な質問10件から始めます。そのうち2件は、文書だけでは答えられない質問にします。回答の根拠箇所、一般ユーザーが使えるワークスペース、アクセスを拒否すべきユーザーの動作を確認します。その後、5人全員が代表的なリクエストを同時に送り、遅延とメモリ使用量を観察します。

   コンテナを停止するか、整合性を保てるバックアップ手法を使い、永続ストレージとマウントした設定をまとめてバックアップします。文書と設定内の秘密情報を含むため、バックアップも保護します。通常の更新前に、導入したイメージのバージョンまたはダイジェストを記録し、試行環境を復元できるか確認します。

既存の外部ローカルモデルサーバーを使う場合は、コンテナからの接続経路を確認します。コンテナ内のlocalhostは、そのコンテナ自身を指し、ホスト側のモデルサービスを指すわけではありません。ホストへの接続ガイドでこの違いを確認し、到達可能なアドレスを使います。モデルサービスの接続元も、信頼できる相手に制限します。

エージェントとMCPでは、何がワークスペースの外に出ますか？

エージェントは文書チャットに操作を加えます。ツールを使って情報を取得したり作業を実行したりするため、権限には読み取る文書と同じだけ注意が必要です。

Settings > Agent Skillsでは、業務に必要なスキルだけを選びます。既定で有効になっているものもあります。エージェントの設定ガイドでは、ワークスペースごとにエージェント用モデルを選ぶこともできます。最初の試行は、すべての業務システムへのアクセスを与えるより、承認済みの規定を検索する仕事から始めるほうが適切です。

Model Context Protocol、つまりMCPは、アプリからモデルをツールにつなぐための共通の仕組みです。AnythingLLMのMCP設定は、コマンドで起動するローカルサーバーとリモート接続に対応しています。ツールはディレクトリの読み取り、データベースへの問い合わせ、別サービスの呼び出しなどを行えます。その操作範囲を決めるのは、渡した認証情報です。

DockerのMCPガイドによると、セルフホストのDocker版はMCP Toolsに対応しますが、Resources、Prompts、Samplingには対応しません。設定は、永続ストレージディレクトリ内のplugins/anythingllm_mcp_servers.jsonに置きます。変更後はAgent Skillsを開き、Refreshを実行します。

ローカルで起動したMCPサーバーはコンテナ内で動きます。参照できるのはコンテナ内のパスと明示的にマウントされたファイルであり、ホストの任意のフォルダーではありません。手作業で導入したツールの依存関係は、コンテナの置き換えで失われることがあるため、本格的に利用する前に再現可能な導入方法を用意します。

ワークスペースの制限が、ツールのデータベース認証情報にも及ぶとは考えないでください。ツールには権限を絞ったアカウントを渡し、そのアクセス範囲を別途確認します。まず読み取り専用で試すと、レコードの変更やメッセージ送信を許可する前に、影響を確認しやすくなります。

AnythingLLMの代替ツールは、どんな場合に選ぶべきですか？

共有の文書ワークスペースが業務の中心なら、AnythingLLMを選びます。強みは文書チャットやMCPを独占的に提供することではなく、必要な要素をまとめて使える点にあります。

幅広い共有チャット画面を求めるならOpen WebUI

複数のモデルサービスを使う汎用的なセルフホストの画面が主目的で、拡張機能も自分で設定したいなら、Open WebUIを最初の候補にするとよいでしょう。ドキュメントはプロバイダー接続と拡張性を扱い、現行の基本機能ガイドでは文書添付と再利用できるナレッジベースを説明しています。

稼働中のOpen WebUIが文書とアクセスの要件を満たしているなら、そのまま使います。画面を変えるだけでは、元の文書の質やモデルの不適合は解決しません。担当者と利用者を明確に割り当てた少数の文書ワークスペースを軸に導入したいなら、AnythingLLMが向いています。

ユーザーごとのツール接続が必要ならLibreChat

各自の認証情報でツールに接続する必要があるなら、LibreChatを詳しく検討する価値があります。MCPドキュメントでは、ユーザーごとの接続、認証情報、OAuthログインに加え、チャットやエージェントに紐づくツールを説明しています。

個別に利用権限を与える業務システムがある企業には、これが具体的な検討理由になります。その分、接続の管理と、ツールを確実に呼び出せるモデルの選定が必要です。小規模な共有規定集に限られたツールを組み合わせるなら、ワークスペースを軸に設定するAnythingLLMのほうが、導入までの道筋は分かりやすいでしょう。

AnythingLLMとLM Studioの使い分け

LM Studioは、主にローカルモデルをダウンロードし、動かして比較したい個人に向いています。現行アプリのドキュメントはMCP、API配信、ヘッドレス運用も扱い、オフライン利用ガイドにはローカルでの文書チャットも含まれます。そのため、単体のツールとしても、別のアプリの背後で動くモデルサービスとしても役立ちます。

ワークスペースごとにアクセス権を割り当てる共有文書アプリが決め手なら、AnythingLLM Dockerを選びます。モデルの運用が決め手なら、LM Studioを選びます。違いは必要な層であって、片方だけが文書を読めるということではありません。

モデルを動かす基盤の選び方は、OllamaとLM Studioの比較を参照してください。どちらもハードウェアや配信の要件に合わない場合は、Ollamaの代替ツールガイドでほかのランタイムを紹介しています。

「プライベートAI」で過大評価されがちなこと

「ローカルで動く」は構成についての説明であり、データの行き先をすべて示すものではありません。ローカルの画面からクラウドモデルを呼ぶことも、ローカルモデルから外部ツールを呼ぶことも、クラウドの埋め込み機能でローカルのインデックスを作ることもあります。

「すべての文書と会話できる」という表現も、通常の検索が参照する範囲を大きく見せすぎています。検索は文章の一部を選ぶため、回答を変える重要な例外を見落とすことがあります。文書を追加してもモデルが恒久的に学習するわけではなく、引用元の文章が結論を裏付けているかも確認が必要です。

また、インストールの最低要件はチームでの性能保証ではありません。体感を左右するのは、モデル、コンテキスト長、埋め込み処理の負荷、重なって発生するリクエストです。サーバーの担当者が決まり、具体的な文書業務があるなら導入を進めます。誰がファイルにアクセスしてよいか、どのような回答を合格とするかが決まっていないなら、まずそこを整理します。既存システムがその要件を満たしているなら、使い続けます。

よくある質問

AnythingLLMは信頼できるプロジェクトですか？

はい。Mintplex Labsが開発するオープンソースプロジェクトで、コードとインストール用ドキュメントが公開されています。これは出自を確認できるという意味であり、選んだモデル、プラグイン、サーバー設定の安全性を認証するものではありません。

LLMは何に使えますか？

LLMは文章の生成や要約、質問への回答、下書きの作成に使えます。ここでの具体的な業務は、承認済みの文書群から関連箇所を使って質問に答えることです。エージェントを使うと、操作を行うツールを追加できます。

無料で使えるオープンソースのAIモデルはありますか？

はい。ダウンロードしてローカルで実行できるモデルがあります。ただし、AnythingLLMのMITライセンスがモデルの重みにも適用されるとは考えず、各モデルのライセンスと商用利用条件を確認してください。ハードウェアと管理には費用がかかります。

OllamaでLLMをローカル実行できますか？

はい。Ollamaで適切なモデルを動かし、到達可能なそのサービスにAnythingLLMを接続します。Dockerでは、ホストのlocalhostアドレスがコンテナ内でもそのまま使えるとは考えず、コンテナのネットワーク構成を確認します。

OllamaとAnythingLLMの主な違いは何ですか？

Ollamaはモデルを実行する層を提供します。AnythingLLMは、その層を利用できる文書、ワークスペース、エージェントのアプリを提供します。両者は連携でき、現行のAnythingLLM Dockerには任意で使える組み込みエンジンもあります。

LLMをローカルで最も安く動かすにはどうすればよいですか？

まず手元にあるハードウェアと、その機器に収まるモデルから始め、必要な仕事を十分な速さで処理できるか確認します。追加のハードウェアを買うのは、ボトルネックを特定してからです。処理内容と許容できる待ち時間を抜きに、誰にとっても最安の構成を決めることはできません。

最も性能が低いLLMはどれですか？

そのような呼び方で、実用的な共通ランキングを作ることはできません。流暢な文章を書けても、文書検索やツール利用には失敗するモデルがあります。情報源に答えがないと認めるべき場合も含め、自分たちの質問で評価します。

最も賢いローカルLLMはどれですか？

適切な選択は、業務、利用できるメモリ、許容できる遅延で変わります。ハードウェアに収まるモデルを使い、情報源に基づく回答の正確さとツールの動作を評価します。ドキュメントに基づく本記事は、ベンチマークの勝者を示すものではありません。

LLMをローカルで動かすにはRAMがどれくらい必要ですか？

AnythingLLMのDesktopの要件では、基本的なローカル利用の推奨値としてRAM 16GBと8コアCPUが示されています。サーバーには、選んだモデルと重なるリクエストを処理する余力も必要です。これよりずっと小さいアプリ本体だけの最低要件は、ローカル推論に必要なメモリ総量を示すものではありません。

次の業務日に始めること

IT担当者を決め、サーバー、承認済みの文書群、明確な受け入れテストを任せます。ローカル推論、組み込みの埋め込み機能、ローカル保存、Queryモードから始め、不要なツールは無効のままにします。残りの4人を招待するのは、ワークスペースの権限を確認してからです。クラウドモデルが必要になったら、設定を変える前に、どのテキストを外部に出してよいかを明確に決めます。

小規模な企業でAIを業務に役立てるための実践的な情報は、ニュースレターに登録してお読みください。