WeKnora導入手順｜Tencent製RAG基盤をDockerで【2026年9月】

Q: ベクトルDBは後から変更できますか？

RETRIEVE_DRIVER の変更自体は環境変数の書き換えだけですが、既存インデックスは移行されないため再インデックスが必要です。.env.example には、Milvusの距離指標（MILVUS_METRIC_TYPE）を変更した場合はコレクションの再作成が必要とも明記されています。運用開始後の変更は「設定変更」ではなく「移行作業」として計画してください。

Q: RAGとReActエージェント、どちらのモードを使うべきですか？

「規程の何条に何と書いてあるか」のような単発の事実照会はRAGのクイックQ&A（knowledge-chat）、「A文書の価格戦略とB文書の市場分析を突き合わせて」のような複数ステップの照合はReActエージェント（agent-chat）が向きます。エージェント経路は検索・ツール呼び出しを自律的に組み立てる分、応答時間とトークン消費が増えます。

2026.09.22 公開 27分で読める

この記事の結論

TencentがMITで公開するRAG基盤WeKnoraの導入手順。Docker Composeでの起動、.envの3分岐、REST API・CLI・MCP連携、RAGFlow/Difyとの違いを2026年9月22日時点の一次情報で整理。

「社内のPDFやWordを、データを外に出さずにRAG化したい。結局、何をインストールするのが一番早いのか？」

2026年9月22日時点で、その問いに対する有力な答えのひとつが、TencentがMITライセンスで公開しているWeKnoraです。git clone から docker compose up -d まで4コマンド叩けば、文書パース・チャンキング・ベクトル検索・LLM推論・Web UI・REST APIが一式そろった状態で PH_0_ に立ち上がります。ベクトルDBもLLMも自分で選び直せて、全部を自社ネットワークの内側に置けます。

まず現在地を日付付きで押さえておきましょう。2026年9月22日時点のスナップショットは次のとおりです。

最新版: v0.8.0（2026年9月3日リリース）
GitHub: Tencent/WeKnora — 28,674スター / 3,858フォーク（2026年9月22日にGitHub APIで取得した値）
ライセンス: MIT（同梱サードパーティ部品はそれぞれの原ライセンスに従う）
実装言語: Go。デプロイはDocker Compose / Kubernetes（Helm chart同梱）
立ち位置: 公式READMEによれば、WeKnoraは微信対話開放プラットフォームの中核技術フレームワークとして使われている

以下は、実際の .env.example の変数名、docker-compose.yml が開けるポート、APIドキュメントの実在エンドポイントを一次ソースから拾い直し、社内文書をRAG化する手順として並べ直したものです。

WeKnoraは「RAG」「ReActエージェント」「自動Wiki」の3枚重ね

WeKnoraを「RAGツール」と一言で呼ぶと、半分くらい取りこぼします。公式READMEはこの製品を3つのコア能力の組み合わせとして説明しています。

RAGベースのクイックQ&A — 知識ベースに対する通常の検索拡張生成。日常的な「あの規程どうなってたっけ」を拾う層
ReActエージェント — 知識検索・MCPツール・スキルサンドボックス・Web検索を自律的に組み合わせて、複数ステップのタスクを処理する層
Wikiモード — エージェントが生の文書を、相互リンクされた構造化Markdownのナレッジベースへ自動で蒸留する層。ナレッジグラフ表示、手編集、改訂履歴、行単位の差分、ロールバックまで持つ

3層目のWikiモードはv0.5.0でGAになった機能で、一般的なRAG製品にはあまり見かけません。「文書を投げ込んで検索する」だけでなく、「投げ込んだ文書から読める社内Wikiを生やし、それを人間が直せる」ところまで守備範囲に入っています。

検索まわりで選べる手札

検索の実装として用意されているのは、BM25によるスパース検索、密ベクトル検索、GraphRAG、親子チャンキング、そしてpgvectorの1024次元埋め込みに対するHNSWインデックスです。用語がピンと来ない場合はリランク・ハイブリッド検索の解説とチャンキング戦略、グラフ側はGraphRAG実践ガイドを先に読むと、設定画面の項目がそのまま分かります。

読み込める文書フォーマット

公式の機能表に列挙されているのは、PDF / Word / Txt / Markdown / HTML / EPUB / MHTML / 画像 / CSV / Excel / PPT / JSON / XMindの13種。v0.8.0からはOfficeファイルをanydocでプロセス内パースできます。マインドマップ（XMind）が入っているのは珍しい部類です。

外部データソースからの自動同期にも対応し、Feishu wiki / Feishu Drive / Lark / GitLab / Tencent IMA / Notion / Yuque / DingTalk Docs / RSS が公式一覧に載っています。GitLabとTencent IMAはv0.8.0で追加されたばかりです。

Docker Composeで最小構成を立ち上げる

前提はDocker / Docker ComposeとGitだけです。公式READMEのGetting Startedに書かれている手順をそのまま引くと、こうなります。

# 動作環境: Docker Engine + Docker Compose v2, Git
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。

git clone PH_8_
cd WeKnora
cp .env.example .env    # 中のコメントを読みながら編集する
docker compose pull     # イメージを取得
docker compose up -d    # コアサービスを起動

起動後のアクセス先は次の3つです。docker-compose.yml の ports 定義を確認すると、いずれも環境変数で差し替えられるようになっています。

用途	URL	ポートを変える環境変数
Web UI	http://localhost	`FRONTEND_PORT`（既定80）
バックエンドAPI	http://localhost:8080	`APP_PORT`（既定8080）
Langfuseトレーシング	http://localhost:3000	`LANGFUSE_WEB_PORT`（既定3000）
MCPサーバー	http://localhost:8082	`MCP_PORT`（既定8082→コンテナ8000）

ポイント: 80番が埋まっている開発機は珍しくないので、先に .env へ FRONTEND_PORT=8000 のように書いてから起動すると後が楽です。

プロファイルで足す、足さない

デフォルトの docker compose up -d はコアサービスだけを起動します。追加コンポーネントはComposeプロファイルで足す設計で、公式表に載っているのは次の4つです。

# 使えるプロファイル: neo4j（ナレッジグラフ）/ minio（オブジェクトストレージ）
#                   langfuse（トレーシング）/ full（全部入り）
docker compose --profile neo4j --profile langfuse pull
docker compose --profile neo4j --profile langfuse up -d

docker compose down    # 停止

ローカルのOllamaモデルを使う場合は、起動前に ollama serve を上げておくようREADMEが指示しています。.env の既定値は OLLAMA_BASE_URL=http://host.docker.internal:11434 なので、コンテナからホストのOllamaを見に行く設定が最初から入っています。

アップグレードで踏みやすい罠

READMEに明示的な注意書きがあります。docker compose up -d だけを叩くとローカルのキャッシュイメージが再利用され、UIのバージョン表示がダウンロードしたリリースとずれる、というものです。

# .env の WEKNORA_VERSION を目的のリリース（例: 0.8.0）に設定、または latest のまま
docker compose pull     # WEKNORA_VERSION に一致するイメージを取得
docker compose up -d    # 新しいイメージでコンテナを作り直す

DBマイグレーションはバージョン更新時に自動で走る設計（AUTO_MIGRATE=true が既定）ですが、本番で上げる前のバックアップは変わらず必要です。

もっと軽く試したいときのSQLiteプリセット

リポジトリのルートには .env.example とは別に .env.lite.example が置かれています。中身を見ると、PostgreSQLもRedisも使わない軽量プリセットになっているのが分かります。

# .env.lite.example の主な中身（コメント行を除いた抜粋）
DB_DRIVER=sqlite
DB_PATH=./data/weknora.db
RETRIEVE_DRIVER=sqlite
STORAGE_TYPE=local
STREAM_MANAGER_TYPE=memory
CONCURRENCY_POOL_SIZE=3
WEKNORA_SANDBOX_MODE=disabled
ENABLE_GRAPH_RAG=false

ノートPCで挙動だけ見たい用途ならこちらが素直です。フル版の .env.example は DB_DRIVER=postgres / STREAM_MANAGER_TYPE=redis / CONCURRENCY_POOL_SIZE=5 が既定値です。

.envで決まる3つの分岐 — ベクトルDB・モデル・ストレージ

WeKnoraの設計思想は、パース→ベクトル化→検索→LLM推論の各段を差し替え可能にすることにあります。その差し替えはほぼ全部 .env で起きます。.env.example は約800行、v0.7.2で公開された公式ドキュメントサイトは約150の環境変数を扱うと説明されています。全部を読む必要はなく、最初に決めるべき分岐は3つです。

分岐1: ベクトルDB（RETRIEVE_DRIVER）

検索エンジンの選択は RETRIEVE_DRIVER 一本です。.env.example のコメントによれば postgres / elasticsearch_v7 / elasticsearch_v8 / opensearch / qdrant / milvus / weaviate / doris / tencent_vectordb が指定でき、カンマ区切りで複数ドライバを並べられます（並列検索のタイムアウトは MULTI_STORE_RETRIEVE_TIMEOUT_SEC）。

# 既定はPostgreSQL（pgvector）
RETRIEVE_DRIVER=postgres

# Qdrantに切り替える例
# RETRIEVE_DRIVER=qdrant
# QDRANT_HOST=qdrant
# QDRANT_PORT=6334
# QDRANT_REST_PORT=6333
# QDRANT_COLLECTION=weknora_embeddings
# QDRANT_API_KEY=your_qdrant_api_key

ポイント: 迷ったら既定のpgvectorのまま始めるのが安全です。追加コンテナが不要で、1024次元の埋め込みにはHNSWインデックスが効きます。各選択肢の特性はAIエージェント用ベクトルDB比較で整理しています。

分岐2: LLMと埋め込みモデル

対応プロバイダは公式表で20以上。OpenAI / Azure OpenAI / Anthropic（Claude）/ DeepSeek / Qwen（Alibaba Cloud）/ Zhipu / Hunyuan / Doubao（Volcengine）/ Gemini / MiniMax / NVIDIA / Novita AI / SiliconFlow / OpenRouter / Requesty / LiteLLM / Ollama が並びます。埋め込み側は Ollama / BGE / GTE / Zhipu / OpenAI互換API です。

LiteLLMはv0.8.0で入ったので、ここを経由すれば対応表にないプロバイダも実質的に差し込めます。完全オフライン運用ならOllama + BGE/GTEですが、埋め込みモデルを途中で変えると再インデックスが必要な点は他のRAG基盤と同じです。判断軸はEmbeddingモデル選定ガイドがそのまま使えます。

分岐3: ストレージと秘密鍵

STORAGE_TYPE の既定は local（実体は LOCAL_STORAGE_BASE_DIR=/data/files）で、MinIO / AWS S3 / Volcengine TOS / Alibaba OSS / Kingsoft KS3 / Huawei OBS に切り替えられます。v0.7.0からはワークスペースごとに複数のストレージインスタンスを持ち、知識ベース単位で紐づけられます。

本番で必ず手を入れるべきなのが秘密鍵の3点です。.env.example のF1セクションに「生産務必改默认値（本番では既定値を必ず変更すること）」と明記されています。

# まず値を生成する（.env はシェルではないので、コマンド置換は展開されません）
openssl rand -hex 32   # JWT_SECRET 用
openssl rand -hex 16   # SYSTEM_AES_KEY 用（32バイトのASCIIになる）
openssl rand -hex 32   # SYSTEM_SIGNING_KEY 用

# 生成した値を .env に貼り付ける
# JWT署名鍵（空なら起動時にランダム生成される）
JWT_SECRET=ここに openssl rand -hex 32 の出力

# AES-256マスター鍵。DB内のAPIキー等の機密フィールドを暗号化する。32バイト必須
# 失うと暗号化済みデータは復旧不能。アップグレード時は既存の鍵を引き継ぐこと
SYSTEM_AES_KEY=ここに openssl rand -hex 16 の出力

# 埋め込みセッションと署名付きURL用の独立鍵（未設定ならSYSTEM_AES_KEYにフォールバック）
SYSTEM_SIGNING_KEY=ここに openssl rand -hex 32 の出力

SYSTEM_AES_KEY の暗号化対象は、テナントのAPIキー、モデルのAPIキー、ベクトルDBの認証情報、Web検索プロバイダのキーなどです。この鍵を紛失すると復号できず、UI上は空欄になって再入力が必要になります。鍵管理を .env のベタ書きで済ませず、シークレットマネージャや環境変数注入に寄せておくのが安全です。この手の設計判断はRAGのデータセキュリティ実装の観点とセットで考えると漏れが減ります。

あわせて、本番では DISABLE_REGISTRATION=true（新規登録の禁止）も検討してください。

REST API・CLI・MCPから社内システムに配線する

実務では、既存の社内システムから叩けるかどうかが本番です。WeKnoraは入り口を4系統持っています。

REST API

公式APIドキュメントによれば、ベースURLは /api/v1、認証はHTTPヘッダ X-API-Key、追跡用に X-Request-ID の付与が推奨されています。APIキーはWeb画面でアカウント登録後、アカウント情報ページから取得します。文書アップロードは multipart/form-data です。

# 文書をアップロードして知識を作成
# 注意: -F/--form を使うときは Content-Type を手動で付けないこと（ボディが壊れます）
curl --location 'http://localhost:8080/api/v1/knowledge-bases/kb-00000001/knowledge/file' \
  --header 'X-API-Key: sk-xxxxx' \
  --form 'file=@"/path/to/shanai-kitei.pdf"' \
  --form 'enable_multimodel="true"' \
  --form 'metadata="{\"source\":\"manual_upload\"}"'

レスポンスの parse_status が processing なら解析タスクがキューに入った状態です。重複は409、サイズ超過は400（上限は MAX_FILE_SIZE_MB、既定50）。

検索はハイブリッド検索エンドポイントです。

# ベクトル召回＋キーワード召回のハイブリッド検索
curl --location --request POST \
  'http://localhost:8080/api/v1/knowledge-bases/kb-00000001/hybrid-search' \
  --header 'X-API-Key: sk-xxxxx' \
  --header 'Content-Type: application/json' \
  --data '{
    "query_text": "経費精算の締め日は",
    "vector_threshold": 0.5,
    "match_count": 10
  }'

リクエストボディの主なパラメータのうち、実務でよく効くものを抜き出します。

パラメータ	型	用途
`query_text`	string	クエリ本文（必須）
`vector_threshold`	number	ベクトル類似度のしきい値（0〜1）
`match_count`	integer	返す件数の上限
`disable_keywords_match` / `disable_vector_match`	boolean	片方の召回を切って挙動を切り分ける
`knowledge_base_ids`	string[]	知識ベース横断の召回（同一埋め込みモデルが前提。パスの`:id`より優先）
`skip_context_enrichment`	boolean	親子/近傍チャンクの文脈補完をスキップ

会話系は POST /api/v1/knowledge-chat/{session_id}（RAG経路）と POST /api/v1/agent-chat/{session_id}（ReAct経路）がSSEで用意されています。最も正確な仕様は PH_18_ のSwagger UIですが、マウントされるのは GIN_MODE != release のときだけで、本番デプロイでは既定で無効です。

画像・添付の直リンク（意外と詰まるところ）

回答本文の画像は、既定では resource://<handle> という内部参照で返ります。ブラウザから直接は読めず、クライアントが認証付きの GET /files?file_path=<参照> をもう一度叩く必要があります。自社アプリに組み込むなら ?resource_urls=public（リクエスト単位）か RESOURCE_URL_MODE=public（デプロイ全体）で直リンクを返させ、この往復を省けます。

ただし公式ドキュメントは制約も明記しています。直リンクは期限付きの匿名読み取り可能URL（WeKnora発行のgrantは2時間、MinIOの署名付きURLは24時間）なのでログに残さないこと、埋め込みチャネルでは常に handle になること、知識ベースを限定したAPIキーでは403になること、の3点です。

CLI

weknora はターミナルとAIエージェントの両方から叩く前提の公式CLIです。READMEによればエージェントファースト設計で、全コマンドが既定で安定したJSONエンベロープを返し（型付きエラーコードは終了コードにマップされる）、人間が読むときだけ --format text を付けます。

weknora profile add prod --host PH_19_ --use
weknora auth login
weknora kb list
weknora link --kb my-knowledge-base    # カレントディレクトリを紐づける
weknora doc upload notes.md
weknora chat "設計ドキュメントを要約して"

CI用途では WEKNORA_API_KEY と WEKNORA_HOST を環境変数で渡せば auth login が不要になり、認証情報がディスクに書かれません。

MCPサーバー

MCP経由でClaude DesktopやCursorから社内知識ベースを引かせる構成も公式サポート済みです。PyPIパッケージは tencent-weknora-mcp、ツール数29、トランスポートはstdio / SSE / HTTPの3種。MCP設定ガイドのClaude Desktop向け設定例はこれです。

{
  "mcpServers": {
    "weknora": {
      "command": "uv",
      "args": [
        "--directory",
        "/path/WeKnora/mcp-server",
        "run",
        "run_server.py"
      ],
      "env": {
        "WEKNORA_API_KEY": "your_api_key_here",
        "WEKNORA_BASE_URL": "http://localhost:8080/api/v1"
      }
    }
  }
}

PyPI経由なら pip install tencent-weknora-mcp、あるいは uvx --from tencent-weknora-mcp weknora-mcp-server でも起動できます。MCPサーバーがうまく繋がらないときの切り分けはMCPサーバーのデバッグ手順にまとめた流れがそのまま使えます。

コーディングエージェント向けプラグイン

v0.8.0では、DeepSeek Harness（dsh）の公式プラグイン @wxg-prc-cpg/dsh-weknora が追加されました。dsh plugin --profile web add @wxg-prc-cpg/dsh-weknora でコーディングエージェントに社内文書を渡せます。追加されるのは読み取り専用の4ツール——weknora_search（ハイブリッド検索、出典パッセージを原文のまま返す）、weknora_read_document（1文書のパッセージを順序どおり再構成）、weknora_ask（引用付きの回答）、weknora_list_knowledge_bases——で、書き込み経路がないためエージェントが社内コーパスを壊す心配がありません。

自作RAGとWeKnora、書かなくて済むコードの境界線

「LangChainやLlamaIndexで自作したほうが自由が利くのでは」という判断は当然あります。パイプラインを細かく制御したいなら自作のほうが早い場面もあります。ただ、統合基盤を入れると何を書かずに済むのかを具体的に並べると、判断材料になります。

領域	自作した場合に自分で用意するもの	WeKnoraが最初から持っているもの
文書パース	PDF/Office/画像ごとのパーサ選定と例外処理	13フォーマット対応、anydocによるプロセス内Officeパース
取り込み運用	再パース、進捗表示、失敗タスクのリトライ	バッチ再パース、解析トレースのタイムライン、失敗タスクの検査と手動リトライ
チャンク管理	チャンク結果の確認手段（多くの場合DB直見）	UI上でのチャンク編集、バージョン差分、ロールバック、編集後の自動再インデックス
権限	ユーザー/テナント分離の実装	4階層RBAC（Owner / Admin / Contributor / Viewer）、リソース単位のオーナーシップ、ワークスペース単位の監査ログ
APIキー管理	発行・失効・スコープ制御の自作	機能単位の権限付与と知識ベース単位の制限が付いたスコープ付きAPIキー
観測性	トレース基盤の接続	Langfuse統合（ReActループ・トークン・ツール呼び出しの追跡）
チャネル	Slack等への接続を個別実装	Slack / Teams系を含む10種のIMチャネル連携

逆に、パイプラインの一段を独自実装したい——自社専用パーサを挟む、リランカーを自前モデルにする——が要件の中心なら自作ライブラリのほうが素直です。WeKnoraの「モジュール差し替え可能」は、あくまで公式が用意した選択肢の範囲での話です。判断軸はAIエージェント実装ロードマップと合わせて考えてください。

RAGFlow・Difyと並べたときの立ち位置

セルフホスト可能なRAG基盤はWeKnoraだけではありません。2026年9月22日時点のGitHub API値で、代表的な3つを同じ基準で並べます。

比較軸	WeKnora	RAGFlow	Dify
提供元	Tencent	InfiniFlow	LangGenius
GitHubスター（2026-09-22）	28,674	91,127	156,816
ライセンス	MIT	Apache-2.0	Apache 2.0の改変版（追加条件あり）
マルチテナントSaaS提供	ライセンス上の追加制限なし	ライセンス上の追加制限なし	書面許諾なしでの運用は不可（商用ライセンスが必要）
強み	RAG＋ReActエージェント＋自動Wikiの3層、IMチャネルの広さ	複雑PDFのレイアウト理解に寄せた文書優先アーキテクチャ	ノーコードのワークフロービルダー、エコシステムの厚さ
エコシステムの規模	3者の中では最も小さい	中規模	最大

正直に言うと、WeKnoraが全部の観点で勝つわけではありません。

Difyが勝つ観点: 非エンジニアを巻き込んだ内製やプロトタイピングの速度。ノーコードのワークフロー編集と日本語情報量・コミュニティ規模（スター数で約5.5倍）は明確に上です。社内で「まず触ってもらう」フェーズが長い組織はDifyのほうが立ち上がります
RAGFlowが勝つ観点: 表組みや図表キャプション、スキャンPDFが大量に混ざるコーパスの読み取り。文書理解そのものに投資したアーキテクチャで、Apache-2.0という枯れたライセンスも採用側の説明コストが低い
WeKnoraが勝つ観点: ライセンスの素直さ（MITで、マルチテナント運用に関する追加条件がない）、LLM・ベクトルDB・ストレージの選択肢の広さ、そしてWikiモードと長期記憶まで含んだ守備範囲の広さ

Difyのライセンス条文には、書面による許諾なしにソースコードでマルチテナント環境を運用してはならない、フロントエンドのロゴ・著作権表記を削除改変してはならない、と明記されています。純粋な社内利用なら問題にならない条項なので、「自社内で使うだけか、顧客に提供するか」で評価が割れると理解しておけば十分です。

つまずきやすい5つのポイント

失敗1: アップグレード時に pull を飛ばす

❌ 新しいリリースを取得したあと docker compose up -d だけ実行する
⭕ .env の WEKNORA_VERSION を設定 → docker compose pull → docker compose up -d の順で実行する

なぜ重要か: READMEが明示する落とし穴です。「更新したはずなのに新機能が出てこない」の典型的な原因がこれです。

失敗2: SYSTEM_AES_KEY を空のまま本番に上げる

❌ .env.example をコピーしただけで SYSTEM_AES_KEY= を放置する
⭕ openssl rand -hex 16 で生成して明示的に設定し、アップグレード時も同じ鍵を引き継ぐ

なぜ重要か: この鍵はDB内のAPIキー、モデル認証情報、ベクトルDB認証情報などを暗号化しています。.env.example のコメントには、鍵が欠けているか長さが合わないと暗号化済みフィールドを復号できずUI上で空欄になり再入力が必要、鍵を失えば復旧不能、と明記されています。

失敗3: multipart アップロードに Content-Type を手で付ける

❌ curl -F 'file=@...' --header 'Content-Type: application/json'
⭕ -F/--form だけを使い、Content-Typeはcurlに任せる

なぜ重要か: -F を使うとcurlが境界文字列込みの multipart/form-data を自動設定します。手動でヘッダを足すとボディが誤ってパースされる、と公式APIドキュメントが明記しています。

失敗4: 検索ヒットが悪い原因を切り分けずにチューニングする

❌ vector_threshold をいきなり下げて件数を稼ぐ
⭕ disable_keywords_match と disable_vector_match を片方ずつ立てて、どちらの召回が効いていないかを先に確定させる

なぜ重要か: ハイブリッド検索は2系統の召回の合成です。「ベクトル側が拾えていないのか、キーワード側なのか」を分離せずにしきい値を触ると、直したつもりの設定が別の質問群を壊します。切り分け用のフラグが公式に用意されているのはそのためです。

失敗5: 公開インターネットにそのまま出す

❌ 動いたのでリバースプロキシだけ立ててグローバルIPに露出させる
⭕ 内部ネットワーク/VPN内に置き、DISABLE_REGISTRATION=true を設定し、ファイアウォールとアクセス制御を構成する

なぜ重要か: READMEのSecurity Noticeが、v0.1.3以降ログイン認証を備えたうえで、なお本番は内部/プライベートネットワークに置き公開ネットワークへ直接露出させないことを強く推奨しています。社内文書を入れる基盤である以上、ここを緩めるとインシデントの規模が文書の総量になります。

よくある質問

WeKnoraは無料で使えますか？

本体はMITライセンスのオープンソースで、ライセンス費用はかかりません（同梱のサードパーティ部品は各原ライセンスに従います）。実際のコストはサーバー費用と、外部LLM APIを使う場合の従量課金です。Ollamaでローカルモデルを使えばAPI課金はゼロにできますが、その分のGPU/CPUは自前で用意することになります。

社内RAGを構築するとき、最小構成は何が必要ですか？

DockerとDocker Composeが動くサーバー1台、そして回答生成に使うLLM（外部APIまたはローカルOllama）です。既定構成ではPostgreSQL（pgvector）とRedisがComposeに含まれるので、別途DBを用意する必要はありません。挙動だけ見たいならSQLite・インメモリ構成の .env.lite.example が軽く済みます。

ベクトルDBは後から変更できますか？

RETRIEVE_DRIVER の変更自体は環境変数の書き換えだけですが、既存インデックスは移行されないため再インデックスが必要です。.env.example には、Milvusの距離指標（MILVUS_METRIC_TYPE）を変更した場合はコレクションの再作成が必要とも明記されています。運用開始後の変更は「設定変更」ではなく「移行作業」として計画してください。

日本語の文書でもきちんと動きますか？

UIは日本語を含む多言語に対応し、リポジトリには日本語READMEも用意されています。ただし検索精度を決めるのは埋め込みモデルとチャンキング設定なので、日本語コーパスなら日本語に強い埋め込みモデルを選ぶことが前提です。公式の埋め込み対応は Ollama / BGE / GTE / Zhipu / OpenAI互換API です。

RAGとReActエージェント、どちらのモードを使うべきですか？

「規程の何条に何と書いてあるか」のような単発の事実照会はRAGのクイックQ&A（knowledge-chat）、「A文書の価格戦略とB文書の市場分析を突き合わせて」のような複数ステップの照合はReActエージェント（agent-chat）が向きます。エージェント経路は検索・ツール呼び出しを自律的に組み立てる分、応答時間とトークン消費が増えます。

WeKnoraとRAGFlow、どちらを選ぶべきですか？

コーパスがレイアウトの複雑なPDFやスキャン文書中心ならRAGFlow、エージェント機能やIMチャネル連携、Wiki化まで含めて1つの基盤に寄せたいならWeKnora、という切り分けが素直です。自社プロダクトに組み込んでマルチテナントで提供する構想があるなら、MITのWeKnoraとApache-2.0のRAGFlowはどちらも追加条件がなく、ライセンス面では同列です。

結論

WeKnoraは、「社内文書をRAG化する」という課題に、パーサからWeb UI・権限管理・監査ログまでを一式まとめて渡してくるタイプの基盤です。2026年9月22日時点でv0.8.0、MITライセンス、GitHubスターは28,674。エコシステムの規模ではDifyやRAGFlowに届きませんが、ライセンスの素直さと守備範囲の広さで明確な選択理由が立ちます。

導入を検討するなら、進め方はこの順序が現実的です。

まず手元で: .env.lite.example ベースでノートPCに立て、自社の代表的な文書を10本ほど投げて検索品質を見る。期待に届かなければ、埋め込みモデルとチャンキングの問題か、コーパスが構造化されていない問題かを切り分ける
次に検証環境で: .env.example ベースの構成に移し、JWT_SECRET / SYSTEM_AES_KEY / SYSTEM_SIGNING_KEY を生成して DISABLE_REGISTRATION=true を設定。APIキーを発行して、既存の社内システムから hybrid-search を叩けるところまで配線する
最後に本番判断: 内部ネットワークへの配置、ベクトルDBの選定、Langfuseによる観測性、鍵管理の運用ルールを決める。ここを詰めずに公開範囲を広げないこと

RAGの基盤選定は、モデル選びより「どこまで自分で運用する気があるか」で決まります。WeKnoraは機能を広く抱えるぶん運用の面積も広い選択肢なので、運用を引き受ける担当が決まっているかどうかが、実は最大の判断材料です。

運営元 Uravation よりAIエージェントを構想から本番運用まで進める順番と、体制・KPIの決め方をまとめた資料を無料で公開しています。 AIエージェント導入ロードマップを受け取る（無料）

参考・出典

Tencent/WeKnora — GitHub（参照日: 2026-09-22。スター28,674 / フォーク3,858 / Go実装、対応フォーマット・モデル・ベクトルDB一覧、起動手順、Security Noticeを確認）
WeKnora v0.8.0 リリース — GitHub Releases（参照日: 2026-09-22。2026年9月3日公開、anydoc・長期記憶・DeepSeek Harnessプラグイン・LiteLLM対応を確認）
WeKnora LICENSE — GitHub（参照日: 2026-09-22。MIT本文と、サードパーティ部品が各原ライセンスに従う旨を確認）
WeKnora API ドキュメント — GitHub（参照日: 2026-09-22。/api/v1、X-API-Key認証、Swagger UIの公開条件、resource_urlsの制約を確認）
WeKnora .env.example — GitHub（参照日: 2026-09-22。RETRIEVE_DRIVERの選択肢、SYSTEM_AES_KEYの生成と紛失時挙動、MAX_FILE_SIZE_MBを確認）
WeKnora MCP 設定ガイド — GitHub（参照日: 2026-09-22。tencent-weknora-mcp と設定例を確認）
Dify Open Source License — GitHub（参照日: 2026-09-22。マルチテナント運用とロゴ表記の追加条件を確認）
infiniflow/RAGFlow — GitHub（参照日: 2026-09-22。Apache-2.0 / スター91,127を確認）
WeKnora 公式サイト — Tencent（参照日: 2026-09-22）

この記事を読んで導入イメージが固まってきた方へ

Uravationでは、AIエージェントの要件整理、PoC設計、社内導入、研修まで一気通貫で支援しています。

30分無料相談を予約支援実績を見る

※ 本記事の情報は2026年9月時点のものです。サービスの料金・仕様は変更される可能性があります。最新情報は各サービスの公式サイトをご確認ください。