OpenKB レビュー: ベクトルDBなしで文書をWikiにコンパイルする仕組みと導入判断
OpenKB: Open LLM Knowledge Base
ひと目でわかる
- これは何？
- OpenKB は LLM で文書を相互リンクされた Wiki に変換する CLI ツールで、検索には PageIndex の reasoning-based retrieval を使う。ベクトルDBを避けたいチームには魅力的だが、Wiki コンパイルのコストと品質管理が導入の分かれ目になる。
- 誰に向いている？
- OpenKB が向くのは、同じ文書群に対して繰り返し質問が発生し、そのたびに RAG がゼロから知識を再発見するコストを問題視しているチームだ。逆に、単発の検索しかしない用途や、コンパイル時の LLM コストを予算化できない場合は、素直に既存のベクトル検索を選ぶべきである。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 56 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
OpenKB が解決しようとしている問題は検索精度ではなく知識の蓄積
従来の RAG はクエリのたびに文書から知識を再発見する。README はこの点を「Traditional RAG rediscovers knowledge from scratch on every query. Nothing accumulates.」と表現している。つまり問題の所在は検索アルゴリズムではなく、消費した知識がどこにも残らないことにある。OpenKB は生の文書を一度 LLM でコンパイルし、要約、概念ページ、エンティティページ、相互参照を持つ永続的な Wiki として保持する。対象読者は、同じ資料群に対して繰り返し問い合わせが発生する環境、たとえば論文群を継続的に読む研究チームや、社内文書を横断して参照する技術組織である。単発の検索しかしないなら、この設計はオーバーヘッドにしかならない。
短い文書は全文を読み、長い PDF は PageIndex のツリーに委ねる
変換経路は文書の長さで分岐する。README の表によれば、短い文書は markitdown で Markdown に変換され、LLM が全文を読む。画像は pymupdf でインライン抽出される。一方、20ページ以上の PDF は PageIndex に渡され、ツリーインデックスと要約を生成したうえで、LLM は全文ではなくそのツリーを読む。これが「No Vector DB」を成立させている部分で、埋め込みベクトルの近傍探索ではなく、文書構造の階層をたどる推論ベースの検索になる。20ページという閾値は README の表に明記された値であり、境界付近の文書がどちらの経路に落ちるかは実運用で確認する価値がある。抽出結果は summary と concepts という形で Wiki 側に渡される。
インストールから最初のクエリまでの実際のコマンド
導入は pip install openkb から始まる。GitHub の最新版を使うなら pip install git+https://github.com/VectifyAI/OpenKB.git、開発目的で編集可能インストールにするならリポジトリを clone して pip install -e . を実行する。知識ベースの作成は mkdir my-kb && cd my-kb の後、openkb init で初期化する。文書投入は openkb add paper.pdf のようにファイル単体、openkb add ~/papers/ のようにディレクトリ単位、openkb add https://arxiv.org/pdf/2509.11420 のように URL 指定ができる。質問は openkb query "What are the main findings?"、対話は openkb chat で行う。LLM は LiteLLM 経由で複数プロバイダに対応し、モデルは openkb init 時または .openkb/config.yaml の provider/model 形式で指定する。例として anthropic/claude-sonnet-4-6 が挙げられており、OpenAI のモデルは gpt-5.4 のようにプレフィックスを省略できる。API キーは .env に LLM_API_KEY として書く。chatgpt/* や github_copilot/* のような OAuth デバイスフローを使うプロバイダではキー不要で、OpenKB はキー欠落の警告をスキップする。
Web UI と Skill Factory は Wiki の上に載る生成レイヤー
OpenKB は Wiki 基盤とジェネレータの二層構造をとる。ジェネレータ側には query、chat、Skill Factory があり、Wiki を別の成果物に変換する。openkb skill new my-expert "Reason like an expert on <your-topic>" は Wiki から配布可能なエージェントスキルを抽出するコマンドで、openkb visualize は知識グラフを、openkb deck new my-deck "An intro deck on <your-topic>" は単一 HTML ファイルのスライドを生成する。Web UI は pip install "openkb[web]" の後、openkb-web で http://127.0.0.1:7566/ に起動する。認証はデフォルトで無効であり、サーバを外部に公開する前に OPENKB_API_TOKEN を設定して bearer トークンを要求させる必要がある。UI 自体を開発する場合は cd frontend && npm install && npm run dev で Vite 開発サーバを立て、npm run build で openkb/web/ を再生成する。
Wiki がプレーンな .md であることがもたらす可搬性と制約
Wiki はプレーンな .md ファイルとクロスリンクで構成され、Obsidian でグラフビューとして開ける。ページは Google OKF 仕様に従うと README は述べており、エンティティページは人物、組織、場所、製品を自動抽出して同期される。この設計の利点は可搬性で、生成物をそのまま Git 管理下に置いたり、別のツールで読んだりできる。ただし制約も同じ場所にある。LLM が書き込んだ Markdown が正しいかどうかを検証する仕組みは README からは読み取れない。誤った要約や誤ったエンティティの関連付けが Wiki に混入した場合、それを検出するのは人間の目になる。コンパイル済みの知識を信頼するかどうかは、生成物をレビューする運用を回せるかどうかにかかっている。
向かないケース: 単発検索とコンパイルコストを許容できない場合
OpenKB が適さない場面は明確である。第一に、文書群への問い合わせが一度きりで、知識が蓄積される必要がない用途。コンパイルの手間が回収されない。第二に、LLM 呼び出しのコストを事前に見積もれない状況。文書の投入時に要約と概念抽出が走るため、投入量に比例してトークン消費が発生する。README にはコストの目安や上限に関する記述がないため、これは導入前に自分で測るしかない。第三に、抽出の再現性が要求される用途。LLM による要約とエンティティ抽出は確率的であり、同じ文書を入れても同一の Wiki が得られる保証は README からは確認できない。監査や規制対応で決定的な出力が必要なら、この設計は根本的に合わない。
従来の RAG との違いは検索方式ではなく知識の寿命
比較対象として素直なのは、埋め込みベクトルとベクトルDBを使う一般的な RAG である。両者の差は検索アルゴリズムの優劣ではなく、知識がクエリをまたいで残るかどうかにある。ベクトル検索は文書をチャンクに分割してインデックスを作り、クエリごとに類似チャンクを取得して LLM に渡す。文書間の矛盾や関連はその場で LLM が推論する。OpenKB は逆で、投入時に LLM が文書間の関係を整理して Wiki に書き込み、クエリ時はその整理済みの構造をたどる。したがって、文書の追加や更新のたびに Wiki を同期させる運用コストが発生する。ベクトルDBの運用に慣れたチームにとって、この同期処理は新しい監視対象になる。
ライセンスとメンテナンスの確認事項
ライセンスは Apache-2.0 で、商用利用や改変を含む広い権利が認められる。ただし依存関係のライセンスは別であり、特に PageIndex や LiteLLM がどの条件で提供されているかは、この記事の材料からは確認できない。配布物に組み込む場合は依存ツリー全体を確認する必要がある。メンテナンス面では、リリースが v0.4.4 から v0.4.5 へ短期間で進んでおり、v0.4.4-rc1 のようなリリース候補も切られている。活発に開発が続いている一方で、マイナーバージョン間で設定やコマンドが変わる可能性は残る。README は LiteLLM について「pinned to a safe version」と述べており、セキュリティ更新への追随方針が明示されている点は、依存の更新を自動化しているチームにとって確認材料になる。
編集部の結論
OpenKB が向くのは、同じ文書群に対して繰り返し質問が発生し、そのたびに RAG がゼロから知識を再発見するコストを問題視しているチームだ。逆に、単発の検索しかしない用途や、コンパイル時の LLM コストを予算化できない場合は、素直に既存のベクトル検索を選ぶべきである。導入前に確認すべきは、.openkb/config.yaml に設定する provider/model の形式と、PageIndex に渡す長文 PDF が実際にどのツリー構造へ分解されるかである。openkb add で数本の代表的な文書を投入し、wiki/ 配下に生成される .md の相互リンクが自分の文書の論理構造を保っているかを最初に見る。ここが崩れていれば、後段の query も chat も期待した精度にはならない。
コミュニティノート