社内ナレッジ基盤にWeKnoraが選ばれる理由｜RAGFlowとの違い

社内に散らばった仕様書・議事録・ヘルプ記事を、自然文で検索できるようにしたい。この要件を OSS でセルフホストしようと調べ始めると、ほとんどの人が同じ場所で止まります。候補が多すぎて、比較軸が決まらないのです。

RAGFlow、Dify、Onyx、FastGPT、AnythingLLM。どのプロジェクトの README にも「ハイブリッド検索」「リランク」「マルチモーダル解析」「セルフホスト対応」と書かれています。機能リストを横に並べても差が見えず、結果としてスター数の多い順に試すか、最初に見つけたものをそのまま採用することになりがちです。

そこへ、Tencent が公開する WeKnora が候補に入ってきます。GitHub 上で 31,912 スター・4,255 フォークを集めている一方、日本語の解説記事はほとんど存在せず、「Tencent 製で 3 万スター」以上の判断材料が得られないのが現状です。

WeKnora を読み解く鍵は、機能リストではなく設計の軸にあります。このプロジェクトは「RAG（引用付き回答）」「Agent（マルチステップ実行）」「Wiki（ページ自動生成）」の 3 つを、同一のナレッジベース上で扱うことを中心に据えています。この軸が自社要件と合うかどうかが、採用判断の分岐点になります。

本記事では、公式リポジトリ・公式ドキュメント・GitHub API 取得値といった公開情報に限定して、WeKnora の構成、RAGFlow・Dify・Onyx との設計思想の違い、導入前に確認すべき制約を整理します。動作検証やインストール、スクリーンショットの取得は行っておらず、記述はすべて一次情報へのリンクに紐付けています。

社内ナレッジ基盤のOSS選定でつまずく3つの論点

比較軸が決まらない原因は、候補の数ではなく、自社要件がまだ言語化されていないことにあります。先に次の 3 つを決めておくと、各プロジェクトのスペックシートが判断材料として機能し始めます。

論点 1: 必要なのは「検索」までか、「タスク実行」までか。 社内文書を引用付きで検索できれば十分なのか、それとも「この CSV を集計して」「この社内システムにログインして情報を取ってきて」といったタスク実行まで任せたいのか。前者なら RAG エンジンの精度と文書解析の対応形式を見れば足りますが、後者はエージェントの実行環境（サンドボックス・ツール連携・ブラウザ操作）の有無が決定的になります。この違いは機能リストの表面では見分けにくく、プロジェクトの設計思想そのものに現れます。

論点 2: ドキュメントの鮮度を誰が維持するのか。 ナレッジ基盤が陳腐化する最大の理由は、検索精度ではなく「元ドキュメントが更新されない」ことです。評価すべきスペックは、外部サービスからの自動同期データソースの対応範囲と、取り込んだ文書を要約・再構成して維持する仕組みがあるかどうかです。人力で Wiki を書き続ける前提のツールと、生成・バージョン管理まで含むツールでは、運用工数が大きく変わります。

論点 3: セルフホスト要件をどこまで厳格に満たす必要があるか。 データ主権（社外へ送信しないこと）、ネットワーク配置（社内網限定か外部公開か）、権限管理（部署単位の分離・監査ログ）の 3 点を、社内規定に照らして具体化します。「セルフホスト可」と書かれていても、マルチテナント RBAC や監査ログを備えるものと、個人利用前提でユーザー分離を持たないものが混在しているため、ここは必ずスペックで確認する領域です。

以降では、この 3 論点を軸に WeKnora を見ていきます。

WeKnoraとは｜RAG・エージェント・Wikiを同一ナレッジベースで扱うOSS

WeKnora は、Tencent が公開しているオープンソースの LLM ナレッジプラットフォームです。リポジトリの説明文では「生のドキュメントを、クエリ可能な RAG・自律推論エージェント・自己維持型 Wiki に変える」と位置づけられており、公式ドキュメントでは「ナレッジベース Q&A システム」として整理されています（公式 Introduction）。

3つのモードがそれぞれ担う役割

公式ドキュメントの定義に沿うと、3 つのモードの役割は次のように分かれます。

重要なのは、この 3 つが別プロダクトではなく同一のナレッジベース上で動く点です。先に挙げた論点 1（検索までか、タスク実行までか）と論点 2（鮮度を誰が維持するか）を、1 つの基盤でまとめて扱おうとする設計になっています。

リポジトリの基本情報とメンテナンス状況

執筆時点（2026 年 10 月）の GitHub API 取得値は以下の通りです。

メンテナンス状況の読み方としては、まず archived=false / fork=false / disabled=false かつ公開状態（visibility=public）であり、最終 push が執筆時点の直近であることから、アクティブに開発が続いているプロジェクトと判断できます。一方で作成日が 2025 年 7 月と若く、オープン Issue が 652 件ある点は、仕様の変化が速い段階にあることを示しています。リリース履歴も v0.7.2（2026 年 8 月）、v0.8.0（2026 年 9 月）、v0.8.2（2026 年 9 月）と短い間隔で更新されており、バージョン追従の体制が前提になります。

ライセンス表記の確認が必要な理由

ライセンスについては、単純に「MIT ライセンスの OSS」と理解すると社内の法務確認で齟齬が生じます。事実関係は次の 3 層に分かれています。

1. GitHub API の license.spdx_id は NOASSERTION、表示名は Other です。つまり GitHub の自動判定ではライセンスが特定されていません。
2. 一方で LICENSE ファイル の本文は、第三者コンポーネントを除く本体を MIT License とする旨を明記し、MIT License の全文を含んでいます。README のバッジも MIT 表記です。
3. 同 LICENSE ファイルには、同梱される第三者コンポーネント（Apache-2.0 等を含む）の告知が併記されており、THIRD_PARTY_NOTICES.md および licenses/ ディレクトリに詳細が置かれています。

GitHub の判定が Other になっているのは、LICENSE ファイルが標準の MIT テンプレートと完全一致せず、独自の前文と第三者告知を含むためと考えられます。社内規定で「ライセンスが明示された OSS のみ利用可」と定めている場合、GitHub 上の表示だけで判断すると却下されかねないため、LICENSE 本文と第三者告知の 2 点を実物で確認する手順を踏むことをおすすめします。

WeKnoraのアーキテクチャと差し替え可能なバックエンド

採用判断では「既存の資産を活かせるか」が大きな比重を占めます。WeKnora は構成要素の多くを差し替え可能にしており、この点が後述する比較でも軸になります。

コンポーネント構成とポート

公式アーキテクチャ概要によると、標準構成は次のプロセス群で成り立っています。

Neo4j（ナレッジグラフ）、MinIO（オブジェクトストレージ）、SearXNG（Web 検索）は任意アドオンとして位置づけられています。文書アップロードは「API 受付 → 非同期タスク投入 → gRPC で解析 → ベクトル化 → 格納」という流れで、チャット応答は「クエリ理解 → 並列検索 → リランク → プロンプト組み立て → LLM ストリーミング」という同期パスで処理されます。

差し替え可能なバックエンドの選択肢

README の対応バックエンド一覧では、主要な構成要素がいずれも選択式になっています。

公式の検索エンジンのドキュメントでは、上記に加えて Lite 構成向けの SQLite（FTS5 + sqlite-vec）やグラフ専用の Neo4j も選択肢として挙げられています。既存の LLM 契約や運用中のベクトルDB を流用できるかどうかは、この一覧と自社環境を突き合わせれば判断できます。公式ドキュメントが想定シナリオとして「ベンダーロックインへの懸念」を明示している通り、差し替え可能性はこのプロジェクトが意識的に確保している設計要素です。

検索精度のための仕組み

検索については、ベクトル検索とキーワード検索を独立に実行し、順位ベースの RRF（Reciprocal Rank Fusion）で統合するハイブリッド構成が採られています。重みは設定可能で、エンジン固有のハイブリッド機能に依存しない方式です。キーワード側は PostgreSQL 構成では ParadeDB の pg_search による BM25 が使われ、Elasticsearch / OpenSearch ではネイティブ BM25 が利用されます（公式 検索エンジン）。

リランクはチャットパイプラインの専用ステージで実行され、リランクモデルのスコア・検索の基礎スコア・ソース重みを合成して最終順位を決める設計です。README の機能一覧ではこれに加えて親子チャンク分割と GraphRAG（Neo4j）が挙げられており、チャンク分割の詳細は別途チャンク設定のドキュメントで扱われています。

精度面で見逃せないのが、recall と BLEU / ROUGE によるエンドツーエンド評価が標準機能に含まれている点です。検索・生成のパラメータを変えたときの影響を数値で比較できるかどうかは、運用フェーズでのチューニング工数に直結します。

RAGFlow・Dify・OnyxとWeKnoraの違い｜OSS選定の判断軸

ここからが選定の本題です。先の 3 論点を軸に、主要な類似プロジェクトと並べて見ていきます。

主要3プロジェクトとの比較表

いずれも 2026 年 10 月 4 日時点の GitHub API 取得値です。

RAGFlow は DeepDoc による文書レイアウト解析を中核に据えており、「複雑な PDF から正確に抜き出す」ことが最優先要件なら第一候補になります。Dify は RAG を一機能として含むアプリ構築プラットフォームであり、エコシステムの規模も最大です。Onyx は社内 SaaS のコネクタを前提とした検索に主眼があります。WeKnora はこの 3 つのいずれとも重なりつつ、重心が「社内文書の理解と維持」に置かれている点が異なります。

WeKnoraを選ぶ判断材料になる4つの差分

スペック比較では見えにくい差分は、次の 4 点に集約できます。

1. Wiki 自動生成によるドキュメント鮮度の維持。 公式 Wiki ドキュメントによると、Wiki 機能はナレッジベースの文書から人物・製品・概念などのエンティティを抽出し、出典参照付きの Markdown ページ群を生成します。バージョン履歴は自動生成・エージェント編集・人手編集・ロールバックを区別して保持され、上限到達時のクリーンアップでは人手で書かれた内容が優先的に残されます。生成は Redis のタスクキュー経由で非同期に実行されます。論点 2（鮮度を誰が維持するか）に機能として踏み込んでいるのは、比較した中では WeKnora の特徴です。

2. エージェントの実行環境の具体性。 セッション永続の Docker / E2B / Cube サンドボックスでスキルを実行でき、チャット画面の横に対話型ターミナルとグラフィカルデスクトップを備えます。v0.8.2 で追加された BrowserSkill 拡張では、エージェントがユーザー自身の Chrome / Edge を操作し、ログインや CAPTCHA の局面では人に引き継ぐ設計になっています。論点 1 で「タスク実行まで任せたい」と判断した場合に、具体的な実行基盤が用意されている点が効いてきます。

3. 連携先の地理的な偏り。 データソースと IM チャネルの対応範囲は、WeCom / Feishu / DingTalk / Yuque / Tencent IMA といった中国圏のサービスが厚くなっています。Onyx が Slack / Google Workspace / Confluence など欧米 SaaS のコネクタを中心に据えているのと対照的で、実務ではここが最も明確な分岐点になります。日本企業の場合は、Slack / Confluence / Notion / GitLab / RSS といった共通部分で要件が満たせるかを確認する形になります。

4. 組織運用向けの管理機能。 4 ロールの RBAC と監査ログ、リソース単位の所有、ワークスペースごとの複数ストレージインスタンス、タスクキューのダッシュボードとワーカープール管理、Langfuse によるトレーシングが標準で揃っています。加えて UI は中国語・英語・日本語・韓国語・ロシア語に対応しており、日本語 UI は v0.8.2 で追加されています。論点 3（セルフホスト要件の厳格さ）に対する回答がスペックとして明示されている点は、社内導入の稟議で使いやすい材料です。

なお FastGPT（29,777 スター）と AnythingLLM（66,696 スター）も候補に挙がりますが、こちらは個人から小規模チームのローカル運用に重心があります。マルチテナント前提の権限設計や監査ログを必要としない規模であれば、むしろこの 2 つのほうが構成を軽く保てます。

逆にWeKnoraが向かないケース

採用しないほうがよいケースも明確です。

• 連携したい SaaS が欧米系に偏っている場合: Slack / Google Workspace / Confluence 中心の環境で、コネクタの網羅性を最優先するなら Onyx のほうが要件に近くなります。
• 個人利用・低リソース環境が前提の場合: 標準の Docker 構成は 4 コア CPU / 8GB メモリが目安であり、マルチテナント前提の管理機能は過剰になります。Lite 構成という選択肢はありますが、素直に軽量なプロジェクトを選ぶ判断もあり得ます。
• 明示的なライセンス表記が社内規定上必須の場合: GitHub 上の表示が Other である点が稟議で問題になるなら、Apache-2.0 を明示している RAGFlow のほうが社内調整の手数が少なくなります。
• 文書レイアウト解析の精度が単独の最重要要件である場合: 複雑な表組みや図版からの抽出精度が成否を決めるなら、そこを中核に据えた RAGFlow と直接比較すべきです。

WeKnora導入前に確認すべき制約とリスク

要件が合いそうだと判断できた場合に、着手前に潰しておきたい確認事項を整理します。

動作要件とデプロイ方式の選び方

公式インストールドキュメントでは、標準 Docker 構成のハードウェア目安を 4 コア CPU / 8GB メモリ（モデル重みは別途）としています。ディスクはナレッジベース規模に比例して必要になります。見落としやすいのは、ParadeDB が既定で x86-64-v2 相当の CPU アーキテクチャ（SSE4.2 / POPCNT を含む）を前提とする点です。古い物理サーバーや一部の仮想環境では、ここで足元をすくわれる可能性があります。

デプロイ方式は 4 種類です。

標準構成の起動手順は README に次の形で記載されています。

git clone https://github.com/Tencent/WeKnora.git
cd WeKnora
cp .env.example .env    # Edit .env as needed, see comments in the file
docker compose pull     # Pull the latest images
docker compose up -d    # Start core services

出典: https://github.com/Tencent/WeKnora （README "Run with Docker Compose"、引用は改変なし）

起動後のアクセス先は Web UI が http://localhost、バックエンド API が http://localhost:8080、Langfuse のトレーシングが http://localhost:3000 です。

セキュリティ・運用上の前提

README には本番運用についての警告が明記されています。ログイン認証は同梱されていますが、インターネットではなく社内・プライベートネットワークに配置すること、情報漏えいを防ぐためサービスをパブリックネットワークに直接公開しないこと、ファイアウォール規則とアクセス制御を適切に構成すること、セキュリティパッチのため最新版へ定期更新することが強く推奨されています。「外部公開して社外パートナーにも使わせる」という構成を想定しているなら、設計段階で前提のずれを確認しておく必要があります。

セキュリティ機能としては、4 ロールの RBAC と監査ログ、スコープ付き API キー、OIDC、AES-256-GCM による資格情報の暗号化、SSRF 対策としてのアウトバウンド制御（ホワイトリスト専用モードを含む）が挙げられています。公式ドキュメントは、マルチテナント構成では機微な資格情報向けに AES-256 暗号化の設定が必要であると注記しています。

運用で最も事故につながりやすいのは鍵の扱いです。.env の JWT_SECRET と SYSTEM_AES_KEY は一度生成したらアップグレード時も保持する必要があり、SYSTEM_AES_KEY を取り違えると保存済み資格情報の復号に失敗します。バックアップ手順に含めておくべき項目です。

バージョン追従とドキュメント言語の負担

v0.8.2 のリリースノートには、破壊的変更として DingTalk チャネルの Stream モード専用化（webhook からの移行はマイグレーションで自動実行）、サンドボックスコマンドの実行ユーザーが root に変更された点、PostgreSQL と SQLite のデータベースマイグレーションが必要な点が記載されています。リリース間隔が短いプロジェクトでは、こうしたアップグレードノートの確認が運用ルーチンに組み込まれているかが前提条件になります。

もう一つの実務的な負担がドキュメントの言語です。公式ドキュメントは約 360 の API エンドポイントと約 150 の環境変数をカバーする規模ですが、README 自身がドキュメントを「(in Chinese)」と明記しています。一方で UI は日本語に対応し、README には日本語版も用意されています。つまり「使う分には日本語で足りるが、深くチューニングしたり API を叩き込む段階では中国語ドキュメントに当たる必要がある」という非対称な状態です。詳細設定や API 連携まで踏み込む計画なら、翻訳を前提とした工数を見込んでおくほうが安全です。

日本企業がWeKnoraの採用を判断するためのチェック観点

ここまでの内容を自社要件に当てはめるためのチェック観点を整理します。すべてに答えられる状態になれば、採用可否の判断は十分に下せます。

1. 必要なのは検索までか、タスク実行までか。 引用付き回答で足りるなら RAG 中心のプロジェクトで十分です。CSV 集計やブラウザ操作まで任せたいなら、WeKnora のエージェント実行環境が候補として意味を持ちます。
2. 既存の LLM 契約・ベクトルDB を流用するか。 対応バックエンド一覧と自社の契約・運用中ミドルウェアを突き合わせ、追加調達なしで動く構成を描けるか確認します。
3. 連携したい SaaS が対応データソース・IM チャネルに含まれるか。 Confluence / Notion / GitLab / Slack / RSS などの共通部分で要件を満たせるかを具体的なサービス名で確認します。
4. Wiki 自動生成が自社の運用課題に効くか。 ドキュメントが陳腐化する問題を抱えているなら差別化要素になりますが、文書管理が既に機能しているなら評価優先度は下がります。
5. GitHub 上の Other ライセンス表示が社内規定で許容されるか。 LICENSE 本文（MIT）と第三者コンポーネントの告知を確認し、法務レビューの見通しを立てておきます。
6. 中国語ドキュメントを読める体制があるか。 詳細設定・API 連携まで踏み込むなら、翻訳または読解の工数を計画に入れます。
7. 4 コア / 8GB 以上と x86-64-v2 相当の CPU を確保できるか。 既存サーバーで流用する場合は CPU 世代まで確認します。モデルをセルフホストするなら重み分のリソースも別途必要です。
8. 破壊的変更への追従体制があるか。 短いリリース間隔でアップグレードノートを確認し、マイグレーションを計画的に適用できる運用になっているかを見ます。
9. 本番ネットワーク設計が公式推奨と整合するか。 社内・プライベートネットワークへの配置という前提で設計できるかを確認します。

最初に当たる一次情報としては、日本語版 README が読みやすい入口になります。機能範囲の確認はここで済ませ、要件の詰めは公式ドキュメントで行う流れが効率的です。

まとめ

WeKnora の設計の軸は、RAG・エージェント・Wiki という 3 つのモードを同一のナレッジベース上で扱うことにあります。社内文書の検索だけでなく、タスク実行とドキュメントの鮮度維持までを 1 つの基盤でまとめたい場合には、有力な候補になり得ます。

一方で、文書レイアウト解析の精度を最優先するなら RAGFlow、LLM アプリの構築フロー全体を扱いたいなら Dify、欧米 SaaS のコネクタ網羅性を重視するなら Onyx のほうが要件に近くなります。優劣ではなく、設計の軸がどこに置かれているかの違いです。

選定時に見るべきは、「検索までかタスク実行までか」「ドキュメントの鮮度を誰が維持するか」「セルフホスト要件をどこまで厳格に満たす必要があるか」の 3 点です。この 3 つを自社の言葉で定義できれば、各プロジェクトのスペックシートは判断材料として機能し始めます。WeKnora についてはそのうえで、ライセンス表記の確認、中国圏 SaaS 寄りの連携範囲、中国語ドキュメントへの対応体制という 3 つの実務的な論点を押さえておけば、採用可否の判断は十分に進められます。

関連情報

社内ナレッジ基盤や RAG を使った社内検索の内製化、OSS を活用した技術検証・PoC の受託開発をご検討中の方は、お問い合わせフォーム からご相談ください。要件の整理段階からご相談いただけます。