WeKnora を採用前に読む: RAG・ReAct エージェント・自動 Wiki を 1 つの Go サービスにまとめた構成
Open-source LLM knowledge platform: turn raw documents into a queryable RAG, an autonomous reasoning agent, and a self-maintaining Wiki.
ひと目でわかる
- これは何？
- Tencent が公開している WeKnora は、文書取り込みから検索、エージェント実行、Wiki 生成までを単一のセルフホスト型プラットフォームに統合した Go 製フレームワークだ。統合度の高さが利点である一方、そのぶん導入時に確認すべき設定面が広い。
- 誰に向いている？
- 向いているのは、文書が社内に散在していて、検索・エージェント・Wiki を別々の SaaS で組み合わせたくないチームだ。特に Feishu、Notion、Yuque、GitLab など既存の情報源を同期させたい場合、取り込みコネクタが本体に含まれる点は構成を減らせる。
- 商用利用できる？
- まず確認が必要です。このリポジトリのライセンスは自動分類の対象外なので、商用利用の前に LICENSE ファイルを読んでください。
- 今もメンテナンスされている？
- されています。最後のコミットは 1 日前です。
- 何の言語で書かれている？
- 主に Go です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
文書が「置き場所ごとに別システム」になっている問題を引き受ける
社内文書の検索基盤を作るとき、実際の作業は検索精度の調整ではなく、取り込み経路の整備に時間を取られる。Feishu の Wiki に仕様書があり、GitLab に設計メモがあり、Notion に議事録があり、共有ドライブに Excel と PDF がある。それぞれに別のインデクサを書くと、認証方式も更新検知の仕組みも別々になる。WeKnora はこの部分を本体側の機能として持つ。README によれば Feishu wiki、Feishu Drive、GitLab、Tencent IMA、Notion、Yuque、RSS からの自動同期に対応し、PDF、Word、画像、Excel、XMind を含む 10 以上の形式を扱う。対象読者は、社内文書を LLM で引けるようにしたいが、取り込みパイプラインを自前で書きたくない開発チームだ。とくに中国語圏の SaaS を情報源にしている組織では、コネクタが最初から入っている意味が大きい。
3 つの入口: 即答 RAG、ReAct エージェント、Wiki Mode
WeKnora の機能は 3 層に分かれている。1 つ目は通常の RAG 検索で、日常的な調べ物を想定した即答型の問い合わせだ。2 つ目は ReAct エージェントで、検索、MCP ツール、テナント単位のスキルカタログ、Web 検索を自分で組み合わせて多段のタスクを処理する。README はこのエージェントがセッションをまたいで持続する Docker / E2B / Cube のサンドボックスを使うと説明している。3 つ目が Wiki Mode で、エージェントが生の文書を相互リンクされた markdown のナレッジベースに蒸留し、知識グラフとして閲覧できる形にする。手動編集、リビジョン履歴、ワンクリックのロールバックも付く。この 3 層は独立した製品ではなく、同じ取り込み済み文書群に対する異なる問い合わせ方だ。RAG で足りる質問にエージェントを走らせると遅く高くつくので、どの層を主に使うかを先に決めたほうが構成が決まる。
チャンクと Wiki ページを「編集可能な成果物」として扱う設計
多くの RAG 基盤は、取り込んだチャンクを不変のインデックスとして扱う。検索結果が的外れでも、元文書を直して再取り込みするしかない。WeKnora はここを編集対象にしている。v0.7.2 の変更点として、UI 上で検索チャンクを直接編集でき、バージョンごとの差分とロールバックが可能で、編集後は自動で再インデックスされる。同じリリースで Wiki ページ側にもリビジョン履歴が入り、行単位の差分、ワンクリックのロールバック、ブラウザ上での手動編集ができる。これは運用の前提を変える。検索品質のチューニングが、パイプラインのコードを触る作業から、コンテンツを直す作業に移る。ただし、チャンクを手で直した内容と元文書が乖離していくリスクは残る。同期元を更新したときに手編集がどう扱われるかは README からは読み取れない。運用前に検証すべき点だ。
マルチテナント前提の権限モデルとスコープ付き API キー
WeKnora は個人向けのツールではなく、複数ワークスペースを抱える組織を想定して作られている。README では 4 階層のロールマトリクス、リソース単位のオーナーシップ、ワークスペース単位の監査ログを持つエンタープライズ向けマルチワークスペース RBAC と説明されている。加えて、プログラムから叩くためのスコープ付き API キーとプリンシパルモデルがある。これはつまり、API キーが何でもできる鍵ではなく、特定のプリンシパルに紐づく権限の集合として扱われるということだ。社内の複数部署に同じインスタンスを提供する場合、この粒度がないと結局デプロイを分けることになる。ここは WeKnora を選ぶ理由になりうる部分だ。一方で、4 階層のロールが自分の組織の権限設計にそのまま合うとは限らない。既存のディレクトリサービスとどう突き合わせるかは設計作業になる。
サンドボックス実行は v0.8.0 で前提が変わった
v0.8.0 の変更点で最も注意が必要なのは、スキルサンドボックスの実行基盤だ。セッション持続型の Docker / E2B / Cube バックエンドに整理され、テナント単位のネットワークポリシーが付き、Local のホストプロセス型バックエンドは削除され、Docker はオプトインになった。エージェントにコードやツールを実行させる設計を採る以上、実行環境の分離は避けられない。ホストプロセスで動かす選択肢が消えたことは、セキュリティ面では妥当だが、導入のハードルは上がる。コンテナを動かせない環境、たとえば制約の強いオンプレミスや、ネストした仮想化が使えない CI では、エージェント機能の一部がそもそも使えない可能性がある。RAG の即答だけを使い、エージェントとスキルを無効にする、という切り分けが現実的だ。
セルフホストと構成の差し替え: 何が分離できるのか
WeKnora は完全なセルフホストを前提としたモジュラー構成をうたっている。README によれば LLM、ベクトルデータベース、ストレージバックエンドを差し替え可能で、ワークスペース単位に複数のストレージバックエンドを持てる。LLM 側は OpenAI、DeepSeek、Qwen、Zhipu、Hunyuan、Gemini、MiniMax、NVIDIA、LiteLLM、Ollama を含む 20 以上のプロバイダに対応する。データ主権を重視する組織にとって、推論を Ollama や社内 LiteLLM に寄せられる点は実用的だ。観測性は Langfuse と統合され、エージェントの推論、トークン使用量、パイプラインのトレースを追える。運用面ではタスクキューのダッシュボードとワーカープールのガバナンスが用意されている。ここまでが README に書かれている範囲で、実際のスループットや遅延は公開資料からは判断できない。
始めるときに実際に触る設定
導入手順の詳細は README 本文では概説にとどまり、v0.7.2 で公開された VitePress の製品ドキュメントサイトに約 50 ページ、約 360 の API エンドポイント、約 150 の環境変数がまとめられている。Docker と Nginx による単独デプロイ、クイックスタート用のサンプルデータ、ローカル MCP のデモが含まれる。設定面で名前が確認できるのは、ファイルを第三者アプリから直接読ませるための resource_urls=public と、それに対応する RESOURCE_URL_MODE だ。既定では認証付きプロキシ経由でファイルを取得する必要があるところを、公開モードに切り替えると追加の認証呼び出しなしで画像やファイルを描画できる。便利だが、その名のとおりアクセス制御の外に出る設定なので、社外に出したくない文書を扱うワークスペースでは使わない。MCP 連携は公式 PyPI パッケージ tencent-weknora-mcp として配布されている。
向かないケースと、代わりに検討する構成
単一のベクトル検索 API が欲しいだけなら WeKnora は重い。RAG、エージェント、Wiki、RBAC、監査ログ、データソース同期、サンドボックスを 1 つのプロセス群にまとめた構成は、その大半を使わないなら運用対象を増やすだけだ。たとえば LlamaIndex や Haystack のようなライブラリは、取り込みと検索の部品を自分で組み、必要なものだけをアプリに埋め込む。WeKnora は逆で、動くサービスとして先に存在し、そこに自分のデータと権限設計を合わせる。この違いは、社内に「文書検索の窓口を 1 つ立てたい」のか「アプリの中に検索を組み込みたい」のかで決まる。前者なら WeKnora、後者ならライブラリのほうが素直だ。また、サンドボックスを動かせない環境ではエージェント層を諦めることになる。
ライセンス表記とメンテナンスの見え方
リポジトリのメタデータではライセンスが NOASSERTION と表示されるが、README のバッジは MIT を指しており、LICENSE ファイルへのリンクも MIT として貼られている。この不一致は導入前に自分で LICENSE 本文を確認すべき理由になる。ここから法的な判断はできないので、社内の法務やコンプライアンス基準に照らす作業は別途必要だ。メンテナンス面では、v0.7.1 が 2026-07-24、v0.7.2 が 2026-08-07、v0.8.0 が 2026-09-03 と約 1 か月間隔でリリースが続いている。ただし v0.8.0 のようにサンドボックスのバックエンドを削除し Docker をオプトインに変える変更が入るため、マイナー版でも設定の見直しが発生する前提で追従計画を立てたほうがよい。
編集部の結論
向いているのは、文書が社内に散在していて、検索・エージェント・Wiki を別々の SaaS で組み合わせたくないチームだ。特に Feishu、Notion、Yuque、GitLab など既存の情報源を同期させたい場合、取り込みコネクタが本体に含まれる点は構成を減らせる。逆に、単一のベクトル検索 API だけが欲しい場合や、サンドボックス実行を許容できない環境では過剰になる。v0.8.0 で Local ホストプロセス型のサンドバックエンドが削除され、Docker がオプトインになった点は移行時に必ず確認したい。最初に見るべきは docs の約 150 個の環境変数一覧と、自分のワークスペース構成をその RBAC の 4 階層に写像できるかどうかだ。
コミュニティノート