社内には膨大なナレッジ——マニュアル、規程、過去のQ&A、技術文書——が眠っているのに、いざ質問しようとするとどこに答えがあるか分からない。かといって、ChatGPTのような汎用LLMに聞いても、社内文書を知らないので答えられず、無理に答えさせればもっともらしい嘘（幻覚）を返してくる。「AIに社内の知識を教えて、根拠を持って答えさせたい」——この願いに応えるのが、MaxKB（マックス・ケービー／Max Knowledge Brain）です。自社文書を取り込んでRAGのQ&Aボットやエージェントをノーコードで作れる、企業向けのオープンソースAI基盤で、開発元は1Panel-dev（1Panel/FIT2CLOUD）。GitHubで約21,800スター（2026年7月時点）を集める、この分野を代表する人気プロジェクトです。

この記事を読むと、①MaxKBで結局何ができるのか（自社文書を取り込んでRAGのQ&Aボットやエージェントをノーコードで作る）、②どんな課題を解決するのか（社内ナレッジの分散とLLMの幻覚）、③何を代替できるのか（自前のRAG構築、商用チャットボットSaaS）が分かります。そもそもRAGという仕組みを先に整理したい方は、RAG実装完全ガイド2026を合わせて読むと、MaxKBが内部で何をしているのかが立体的に掴めます。

MaxKB：自社文書を取り込んでRAGのQ&Aボットやエージェントをノーコードで作れる企業向けオープンソースAI基盤。ワークフロー・MCP・マルチモーダル対応
MaxKBは、自社の知識をAIに教え、根拠を持って答えさせる企業向けのRAG＋エージェント基盤。
この記事のポイント
  • ・MaxKBは、自社文書からRAGのQ&Aボット/エージェントをノーコードで作る企業向けOSS基盤（GPL-3.0・約21,800★）。
  • ・文書取込→分割→ベクトル化で幻覚を抑え、出典を辿れる根拠付き回答を返す。
  • ・ワークフローエンジン＋関数ライブラリ＋MCPツール利用で、複雑な業務も編成できる。
  • ・プライベート（DeepSeek/Llama/Qwen）とパブリック（OpenAI/Claude/Gemini/MiniMax）の両モデル対応。マルチモーダルも。
  • ・Dockerワンライナーで導入。Vue/Django/LangChain/PostgreSQL+pgvector構成。

1. MaxKBとは：RAG＋ワークフローの企業向けエージェント基盤

MaxKBの全体像：RAGパイプライン（文書取込→分割→ベクトル化で幻覚抑制）、エージェント/ワークフロー（ワークフローエンジン＋関数＋MCP）、ノーコード統合（既存業務システムに素早く組込）
MaxKBの全体像。RAG・エージェント/ワークフロー・ノーコード統合の3本柱で企業のAI活用を支える。

MaxKBは、公式の言葉で「エンタープライズグレードのエージェントを構築するためのオープンソースプラットフォーム」です。名前の由来は「Max Knowledge Brain（最大の知識の脳）」。ひとことで言えば、自社の知識をAIに与えて、根拠を持って答えるボットやエージェントを作るための土台です。汎用のLLMに「社内という文脈」を持たせ、あなたの組織専用の“知識の脳”に仕立てる——そんなイメージが名前によく表れています。

MaxKBが立っている場所を整理すると、次の3つを1つに束ねた点が特徴です。

・RAGパイプライン：文書のアップロードやWebクロールに対応し、自動でテキストを分割・ベクトル化して、幻覚を抑える
・エージェント/ワークフロー：強力なワークフローエンジン・関数ライブラリ・MCPツール利用で、複雑な業務プロセスを編成する
・ノーコード統合：第三者の業務システムに、コードを書かずに素早く組み込める

ここで押さえたいのは、MaxKBが単なる「チャットボット作成ツール」ではなく、RAGとエージェントの両方を1つにまとめた基盤だという点です。「文書に基づいて答える」というRAGの土台の上に、「ツールを呼び、条件で分岐し、業務を進める」というエージェントの機能が乗っている。「知識（RAG）」と「行動（ワークフロー/ツール）」を一体で扱えることが、企業利用でMaxKBが選ばれる理由です。

開発元の1Panel-dev（FIT2CLOUD）は、サーバー管理パネルの1Panelなどで知られる、オープンソースのインフラ系ツールを手がけるチームです。その出自もあってか、MaxKBは「個人が試すおもちゃ」ではなく、エンタープライズグレード（企業が本番で使える品質）を掲げています。約21,800スターという数字は、単なる話題性ではなく、実際に「社内のナレッジをAIで活かしたい」という企業ニーズの大きさを反映していると見てよいでしょう。特に、後述するプライベートモデル対応やセルフホスト前提の設計は、データを外に出せない企業にとって重要な選択理由になります。

ひとことで
  • ・MaxKB＝自社文書でRAGのQ&Aを作り、さらにワークフロー/ツールでエージェント化できる企業向け基盤。
  • ・「知識に基づいて答える」だけでなく「ツールを使って業務を進める」まで一体で扱える。

2. なぜ必要か：社内ナレッジの分散とLLMの幻覚を解決する

汎用LLMだけの課題（社内文書を知らない・幻覚・根拠を辿れない・Q&A構築が手作業）を、MaxKB（自社文書を取り込みRAG・文書に根ざした回答・出典を辿れる・ノーコード）で解決する対比図
MaxKBが解決するのは「汎用LLMは社内を知らず、幻覚を出す」という企業AIの根本課題。

MaxKBが解決するのは、企業が汎用LLMをそのまま使ったときに必ずぶつかる2つの壁です。

1つ目は社内ナレッジの分散。知識はマニュアル、規程、チャット履歴、技術文書などにバラバラに散らばり、「どこに答えがあるか」を人が探すのに時間がかかります。2つ目はLLMの幻覚。汎用LLMは社内文書を学習していないため、社内固有の質問には答えられず、無理に答えさせると事実と異なる「もっともらしい嘘」を返します。業務でこれは致命的です。

MaxKBは、これらをRAG（検索拡張生成）で解決します。汎用LLMの課題と、MaxKBによる解決を対応させると、こうなります。

汎用LLMだけの課題 MaxKBによる解決
社内文書を知らない 自社文書を取り込んでベクトル化し、検索できるようにする
もっともらしい幻覚 検索した文書に根ざして回答し、幻覚を抑制する
根拠を辿れない どの文書に基づいたかを辿れる回答にする
Q&A構築が手作業 ノーコードでQ&Aボット/エージェントを素早く構築
誤解しないでほしい点
  • ・RAGは幻覚を「抑える」もので、ゼロにする魔法ではない。取り込む文書の質と鮮度が回答精度を左右する。
  • ・機微なデータを扱うなら、パブリックモデルでなくプライベートモデルでの運用を検討する。

この必要性が効いてくるのは、社内に価値ある知識が蓄積されていて、かつ正確さが求められるほどです。趣味の雑談ならLLMの幻覚も許容できますが、顧客対応・社内ヘルプデスク・技術サポートのような場面では、根拠のない回答は信頼を損ないます。MaxKBは、その「根拠を持って答える」を、ノーコードで実現するための基盤です。

具体的な活用シーンを挙げると、イメージが掴みやすいでしょう。社内ヘルプデスクでは、就業規則や経費精算の手順を、社員が自然文で質問して即座に答えを得られます。カスタマーサポートでは、製品マニュアルやFAQを取り込んで、問い合わせ対応を一次受けさせられます。技術サポートでは、社内の技術文書やトラブルシューティング事例を根拠に、エンジニアの調べ物を高速化できます。いずれも共通するのは、「答えは社内文書のどこかにあるが、探すのが大変」という状況で、MaxKBが検索と回答をまとめて肩代わりする点です。しかも出典を辿れるため、回答が疑わしいときは元文書を確認できます。この「根拠が辿れる」性質が、業務利用での信頼性を担保します。RAG基盤の選択肢としてはRAGFlowやLightRAGもあり、MaxKBは「ノーコードで企業のQ&A・エージェントを作る」方向に特化している、と位置づけると選びやすくなります。

3. 主な機能：RAGパイプライン・ワークフロー・MCP・マルチモーダル

MaxKBの主な機能：文書取込＋Webクロール（自動分割・ベクトル化）、根拠付きQ&A、ワークフローエンジン、MCPツール利用、マルチモーダル、多モデル対応
MaxKBの主な機能。取り込み・回答・業務編成・ツール連携が1つの基盤に揃う。

MaxKBの機能は、「知識を取り込む」「根拠を持って答える」「業務を進める」の3つに大別できます。

RAGパイプライン：文書のアップロードとWebクロールに対応し、取り込んだ内容を自動でテキスト分割・ベクトル化します。これにより、質問に関連する箇所を検索して回答の根拠にできます。幻覚を抑える中核機能です。特に「Webクロール」に対応している点は実用的で、社内Wikiや公開ドキュメントサイトのように、更新され続けるWeb上の情報源をまるごと取り込めます。ファイルを1つずつアップロードするだけでなく、既存の知識が置かれている場所を指定して自動収集できるため、ナレッジベースの構築と維持の手間が大きく減ります。取り込んだ後の分割・ベクトル化は自動なので、利用者は「どこの情報を使うか」を指定するだけで済みます。

エージェント/ワークフロー：強力なワークフローエンジン、再利用可能な関数ライブラリ、そしてMCPツール利用を備えます。単純なQ&Aを超えて、「条件で分岐し、外部ツールを呼び、複数ステップの業務を自動で進める」エージェントを組めます。ここでMCP（Model Context Protocol）に対応している意義は大きく、MCPは今やAIと外部ツールを繋ぐ事実上の標準になりつつあります。MCP対応のツールなら、MaxKBのエージェントから呼び出して業務に組み込めるため、「社内文書に基づいて答え、必要なら外部システムを操作する」といった高度なエージェントを、エコシステムの資産を活かして構築できます。単なる「賢いFAQ」から「業務を実際に動かすエージェント」への橋渡しが、このワークフロー＋MCPの層です。

マルチモーダル：テキストだけでなく、画像・音声・動画の入出力にネイティブ対応します。文書だけでなく、多様な形式の情報を扱えます。図表を含む資料や、音声の議事録、動画マニュアルなど、企業のナレッジはテキスト以外の形式も多く、それらを扱えることは実務での適用範囲を大きく広げます。

多モデル対応：使うLLMを柔軟に選べます。

種別 対応モデル（例）
プライベート（自前運用） DeepSeek / Llama / Qwen
パブリック（API） OpenAI / Claude / Gemini / MiniMax

ノーコード統合：作ったQ&A・エージェントを、第三者の業務システムにコードを書かずに素早く組み込めるようにする機能を備えます。作ったボットを、社内ポータルやWebサイト、既存の業務アプリに埋め込む——といった連携を、開発工数をかけずに実現できます。せっかく高品質なQ&Aボットを作っても、社員が使う場所に届かなければ意味がありません。この「作ったものを、実際に使われる場所に素早く届ける」導線までを含めて提供している点が、MaxKBが「プラットフォーム」を名乗る理由であり、単なる開発ツールとの違いです。導入から社内展開までの距離が短いことは、AIプロジェクトが「作って終わり」で頓挫しがちな現実を考えると、見過ごせない実用的な強みです。

この「多モデル対応」は、企業利用で特に重要な意味を持ちます。というのも、企業がAIを導入するときの最大の懸念の1つがデータの取り扱いだからです。機微な社内文書を、外部のAPI（OpenAIやClaude）に送ることに抵抗がある、あるいはコンプライアンス上できない企業は少なくありません。MaxKBは、そうしたケースでDeepSeekやLlama、Qwenといったモデルを自前のサーバーで動かし、データを一切外に出さずにRAGを完結できます。逆に、社外秘でない情報を扱うなら、精度で勝るパブリックの高性能モデルを使えばよい。「扱うデータの機微度に応じてモデルを選べる」柔軟性は、企業が現実的にAIを導入するうえでの生命線であり、MaxKBが企業向けを標榜する所以でもあります。

設計思想が効くところ
  • ・RAG（知識）とワークフロー/MCP（行動）が1基盤に揃うため、Q&Aから業務自動化まで地続き。
  • ・プライベートモデル対応により、機微なデータを外に出さず自前で完結できる。
  • ・データの機微度に応じて、自前モデルとパブリックモデルを使い分けられる。

4. 仕組み：文書取込→分割→ベクトル化→根拠付き回答

MaxKBの中核であるRAGの流れを押さえると、「なぜ幻覚が抑えられるのか」が腑に落ちます。基本は「事前の取り込み」と「質問時の検索・回答」の2段です。

まず事前の取り込みでは、アップロードした文書やクロールしたWebページを、意味のまとまりごとに分割（チャンク化）し、それぞれをベクトルに変換してpgvector（PostgreSQLのベクトル検索拡張）に保存します。次に質問時には、ユーザーの質問もベクトル化し、意味的に近いチャンクを検索して取り出し、その内容をLLMに渡して根拠に基づいた回答を生成させます。この流れを図にすると次のようになります。

flowchart TD Doc["社内文書 / Webページ"] --> Split["テキスト分割
（チャンク化）"] Split --> Emb["ベクトル化"] Emb --> DB[("pgvector
ベクトルDB")] Q["ユーザーの質問"] --> QEmb["質問をベクトル化"] QEmb --> Search["意味検索
関連チャンクを取得"] DB --> Search Search --> LLM["LLMが回答生成
（取得した文書に根ざす）"] LLM --> Ans["根拠付きの回答"] Ans -.->|"ワークフロー/MCP"| Tool["外部ツール実行・業務編成"]

この図の肝は、LLMが「学習済みの記憶」ではなく「検索して取り出した自社文書」に基づいて答える点です。だから社内固有の質問にも答えられ、かつ幻覚が抑えられます。「質問に関連する自社文書を検索し、それを根拠にLLMが答える」——これがRAGの本質であり、MaxKBが企業で信頼される理由です。さらに図の右下のように、回答で終わらずワークフローやMCPツールに繋げれば、「答える」から「業務を進める」エージェントへと拡張できます。技術的には、Vue.js・Django・LangChain・PostgreSQL＋pgvectorという構成でこれを実現しています。

ここで、RAGの品質を左右する重要なポイントが2つあります。1つはチャンク（分割）のしかたです。文書を細かく切りすぎると文脈が失われ、大きく切りすぎると関係ない情報が混ざります。適切な粒度で分割することが、検索の精度に直結します。もう1つは取り込む文書の質と鮮度です。RAGは「検索した文書に基づいて答える」以上、元の文書が古かったり間違っていれば、回答もそれを忠実に反映してしまいます。つまりRAGは「LLMの幻覚」を抑える代わりに、「文書の正しさ」に責任を移すとも言えます。MaxKBを導入したら、ナレッジの整備・更新を運用に組み込むことが、回答品質を保つ鍵になります。

もう一段踏み込むと、MaxKBのようなプラットフォームを使う最大の利点は、この一連のRAGパイプラインを自分でコードから組まなくてよいことです。文書の読み込み、分割、ベクトル化、ベクトルDBへの保存、検索、プロンプト組み立て——これらをLangChainなどで一から実装するのは相応の手間がかかります。MaxKBは、それを管理画面のノーコード操作に落とし込んでいます。「RAGの仕組みは理解しつつ、実装は任せて、業務に集中したい」という企業にとって、これは大きな時短になります。

5. 導入：Dockerワンライナーと基本設定

MaxKBの導入フロー：docker runで1panel/maxkbを起動→8080にアクセスしadmin/MaxKB@123でログイン→使うLLMモデルを設定→文書を取り込んでナレッジ化しQ&A
導入はDockerワンライナー。起動→ログイン→モデル設定→文書取込の4ステップ。

導入は非常に手軽で、Dockerのワンライナーで起動できます。

docker run -d --name=maxkb --restart=always \
  -p 8080:8080 \
  -v ~/.maxkb:/opt/maxkb \
  1panel/maxkb

起動したら、ブラウザで http://localhost:8080 にアクセスします。初期ログイン情報は次のとおりです。

・ユーザー名：admin
・パスワード：MaxKB@123

ログイン後の基本的な流れはこうです。

・まず使いたいLLMモデルを設定する（プライベート/パブリックから選ぶ）
・文書を取り込む（アップロードまたはWebクロール）→自動で分割・ベクトル化される
・アプリ（Q&Aボット/エージェント）を作成し、ナレッジと紐づける
・必要ならワークフローやMCPツールを組み込み、業務エージェント化する
・作ったボットを公開、または業務システムに組み込む

導入直後にやるべきこと
  • ・初期パスワード（MaxKB@123）は必ず変更する。デフォルトのままの公開は危険。
  • ・外部公開する場合は、リバースプロキシでの認証・HTTPS化などを併せて設定する。

「docker run → 8080でログイン → モデル設定 → 文書取込」で、自社ナレッジのQ&Aボットが動き始めます。最新版はv2.10.3-lts（2026年7月）で、LTS（長期サポート）版が提供されている点も、企業利用での安心材料です。なお、より本格的な運用（永続化・バックアップ・スケール）を見据える場合は、公式のデプロイガイドに沿って構成を詰めるのが安全です。

「LTS版がある」ことの意味も補足しておきましょう。企業が業務システムにOSSを採用するとき、頻繁に破壊的な変更が入るバージョンは運用の重荷になります。LTS（Long-Term Support）版は、一定期間の安定性とセキュリティ修正が約束されるため、「一度組んだら、しばらくは大きな変更なく使い続けたい」という企業ニーズに合致します。MaxKBがLTS版を用意していることは、このプロジェクトが個人の実験ではなく、企業の本番運用を真剣に想定していることの表れです。導入時は、最新の機能追加を追いたいなら通常版を、安定運用を重視するならLTS版を、という選び方ができます。

6. 導入判断：向いている人・注意点

MaxKBの導入判断：社内ナレッジのQ&A化・プライベートモデルでの自前運用に刺さる一方、GPL-3.0や運用前提（永続化・認証）という注意点
導入判断の観点。琥珀色は価値が出る条件、⚠️はライセンス・運用面の注意点。

最後に、導入すべきかの判断材料を整理します。

MaxKBが向いている人

・社内ナレッジ（マニュアル・規程・技術文書）をAIで検索・回答できるようにしたい
・ノーコードで素早くQ&Aボットやエージェントを立ち上げたい
・機微なデータを扱うため、プライベートモデルで自前運用したい
・Q&Aにとどまらず、ワークフローやツール連携で業務を自動化したい
・Docker運用ができ、セルフホストしたい

慎重に判断すべきケース

・GPL-3.0を組み込めない製品に載せて外部配布したい（ライセンスに注意）
・運用リソース（サーバー・保守）を用意できない（セルフホスト前提）
・とにかく手軽なSaaSで完結させたい（MaxKBは自前運用が基本）

いくつか具体的な注意点も押さえましょう。まずRAGは万能ではないこと。幻覚を抑えますが、取り込む文書が古かったり不正確だったりすれば、回答もそれに引きずられます。文書の質と鮮度の管理が回答精度を支えます。次に運用は自分持ちであること。セルフホストなので、永続化・バックアップ・認証・HTTPS化といった運用は自分で行います。そしてライセンス（GPL-3.0）。社内運用なら影響は限定的ですが、製品への組み込み配布を計画するなら適用範囲の確認が必須です。

導入前チェック
  • ・RAGの精度は「取り込む文書の質と鮮度」次第。ナレッジの整備・更新を運用に組み込む。
  • ・セルフホスト前提。永続化・バックアップ・認証・HTTPSは自分で設定する。
  • ・GPL-3.0。製品への組み込み配布はライセンスの適用範囲を法務確認。

まとめ

MaxKBは、「自社の知識をAIに教えて、根拠を持って答えさせる」を、ノーコードで実現する企業向けのオープンソース基盤です。RAGで幻覚を抑えつつ、ワークフローとMCPツール連携で「答える」から「業務を進める」エージェントまで作れる——約21,800スターという支持は、多くの企業が「社内ナレッジをAIで活かしたい」という課題を抱えていることの裏返しでもあります。RAGという技術が研究段階から実用段階へ移り、それをノーコードで扱えるMaxKBのようなプラットフォームが求められている——この記事で見てきた流れは、まさに企業のAI活用が「実験」から「実装」へと進んでいる現在地を映しています。

結論
  • ・MaxKBは、自社文書からRAGのQ&A/エージェントをノーコードで作る企業向けOSS基盤（GPL-3.0・約21,800★）。
  • ・文書取込→分割→ベクトル化（pgvector）で幻覚を抑え、根拠付きで回答する。
  • ・ワークフロー＋関数＋MCPで業務を編成でき、マルチモーダル・多モデルに対応。
  • ・Dockerワンライナーで導入。プライベートモデルで自前完結もできる。
  • ・RAGの精度は文書の質次第。セルフホスト運用とGPL-3.0のライセンスに注意。

MaxKBの登場は、「RAGは特別な技術ではなく、企業が当たり前に使うインフラになりつつある」ことの表れでもあります。少し前まで、社内文書に基づくAIチャットボットを作るには、専門のエンジニアがRAGパイプラインを一から構築する必要がありました。MaxKBのようなプラットフォームは、その参入障壁を大きく下げ、「まず動かしてみて、業務にハマるか試す」ことを可能にします。もちろん、本格運用には文書整備・モデル選定・セキュリティ設定といった作業が伴いますが、入口が「docker run 一発」まで下がった意義は小さくありません。「社内の知識をAIで活かす」という目標が、一部の先進企業だけのものではなくなってきた——MaxKBはその流れを象徴するプロジェクトです。

「社内に知識はあるのに、AIが活かせていない」なら、MaxKBを docker run で立てて、手元の文書を1つ取り込んでみてください。RAGの仕組みはRAG実装完全ガイド2026を、他のRAG基盤との比較はRAGFlowやLightRAGを、それぞれ合わせて読むと選択の精度が上がります。

参照ソース

・1Panel-dev/MaxKB (GitHub) — 公式リポジトリ。RAG・ワークフロー・MCP・対応モデル・Docker導入の一次ソース（GPL-3.0）。
・MaxKB 公式サイト — 機能紹介・ドキュメントの入口となる公式サイト。
・MaxKB リリース（v2.10.3-ltsほか） — 最新版・LTS版の変更点を追える一次ソース。