OpenKB は、VectifyAI が公開しているオープンソースの LLM ナレッジベースツールです。

これは、ドキュメントをチャンク化し、ベクトル化し、問い合わせ時にコンテキストを組み直すだけの従来型 RAG システムではありません。OpenKB はまず生のドキュメントを構造化された wiki にコンパイルします。そこには文書要約、概念ページ、相互参照、後続の問い合わせ、lint チェックが含まれます。言い換えると、資料を継続的に整理していくナレッジベース CLI に近い存在です。

プロジェクト：https://github.com/VectifyAI/OpenKB

先に結論

OpenKB で注目したい点は 3 つあります。

1. ナレッジベースを専用データベースに閉じ込めず、通常の Markdown ファイルとして出力する。
2. PageIndex で長い PDF を処理し、ベクトル DB なしの長文ドキュメント検索を重視している。
3. 「知識のコンパイル」を重視し、毎回ゼロから検索するのではなく、LLM が要約、概念ページ、相互リンクを生成する。

そのため OpenKB は、論文読解、プロジェクト文書、社内資料、技術仕様、製品調査、個人ナレッジベースのように、資料を長期的に蓄積する場面に向いています。

一方で万能の代替ではありません。高並行のオンライン Q&A、複雑な権限管理、Web 管理画面、企業向け監査、大規模なマルチテナント機能が必要なら、現時点の OpenKB は完全な企業ナレッジプラットフォームというより、開発者向けツール兼ナレッジベースのプロトタイプに近いです。

OpenKB とは

OpenKB は Open Knowledge Base の略です。

CLI として動作し、知識庫に入れた原始ドキュメントを変換、整理、要約し、一連の wiki ファイルを生成します。公式 README の説明は明快です。OpenKB は LLM を使って原始ドキュメントを構造化された相互リンク付き wiki スタイルのナレッジベースへコンパイルし、PageIndex によってベクトルレスな長文ドキュメント検索を支援します。

対応する入力形式は次の通りです。

• PDF
• Word
• Markdown
• PowerPoint
• HTML
• Excel
• プレーンテキスト
• markitdown で変換できるその他の形式

生成されたナレッジベースは wiki/ に置かれ、主に次の内容を含みます。

• index.md：ナレッジベースの概要
• log.md：操作タイムライン
• AGENTS.md：ナレッジベース構造とメンテナンス方針
• sources/：変換後の原文
• summaries/：各ドキュメントの要約
• concepts/：ドキュメント横断の概念ページ
• explorations/：保存された問い合わせ結果
• reports/：lint レポート

この設計の最大の利点は透明性です。ブラックボックスの検索インターフェイスから答えを受け取るだけでなく、Markdown ファイルを直接開いて知識庫を確認できます。

従来型 RAG との違い

従来型 RAG の典型的な流れは次のようなものです。

1. ドキュメントをチャンクに分割する。
2. embedding を生成する。
3. ベクトルデータベースに保存する。
4. 問い合わせ時に関連チャンクを取得する。
5. それらを LLM に渡して回答を生成する。

この流れは成熟しており、Q&A システムにも向いています。ただし、知識そのものは本当の意味では蓄積されません。質問のたびに、関連片を探し、コンテキストを組み立て、回答を生成し直すことになります。

OpenKB の考え方は「先に整理し、それから問う」に近いです。

1. ドキュメントを raw/ に入れる。
2. 短いドキュメントは markitdown で Markdown に変換する。
3. 長い PDF は PageIndex でツリーインデックスと要約を生成する。
4. LLM が文書要約を生成する。
5. LLM が既存の概念ページを読み、ドキュメント横断の概念を作成または更新する。
6. ナレッジベースの索引、ログ、相互リンクを更新する。

その結果、新しいドキュメントを 1 つ追加することは、単に検索可能なファイルを 1 つ増やすことではありません。十数個の wiki ページが更新されることもあります。知識は概念ページに書き込まれ、既存資料と接続されます。

これは人間がナレッジベースを維持する方法に近いです。新しい資料が入ったら、保管するだけではなく、トピックページを更新し、差分を要約し、参照を追加します。

PageIndex が解決する問題

長文ドキュメントは、RAG と LLM ナレッジベースにとって常に難所です。

長い PDF を単純に多数の chunk に分けると、次の問題が起きやすくなります。

• 章や節の関係が失われる。
• 表、画像、脚注を扱いにくい。
• 検索される断片が細かすぎて、回答に全体構造が欠ける。
• コンテキストウィンドウが大きくても、文書全体を詰め込むのは適切ではない。
• 要約の連鎖が長いと、細部が圧縮されて失われやすい。

OpenKB は長い PDF の処理に PageIndex を使います。プロジェクト説明によると、PageIndex は長文ドキュメントに対してツリーインデックスと要約を作成し、LLM が全文を直接読むのではなく、文書ツリー上で推論できるようにします。

この路線の要点は「ベクトル類似度が最も高い数段落」を探すことではありません。モデルが文書の階層構造を利用して関連内容を見つけられるようにすることです。研究レポート、論文、マニュアル、目論見書、コンプライアンス文書のような長い資料では、この考え方はかなり有効です。

OpenKB はデフォルトでオープンソース版 PageIndex をローカル実行できます。OCR、複雑な PDF 処理、より高速な構造生成が必要な場合は、PAGEINDEX_API_KEY を設定して PageIndex Cloud を使うこともできます。

インストールとクイックスタート

OpenKB は pip で直接インストールできます。

1

pip install openkb

GitHub の最新バージョンを入れることもできます。

1

pip install git+https://github.com/VectifyAI/OpenKB.git

ソースから開発用にインストールする場合：

1
2
3

git clone https://github.com/VectifyAI/OpenKB.git
cd OpenKB
pip install -e .

ナレッジベース用ディレクトリを作成します。

1
2

mkdir my-kb && cd my-kb
openkb init

ドキュメントを追加します。

1
2

openkb add paper.pdf
openkb add ~/papers/

質問します。

1

openkb query "What are the main findings?"

対話モードに入ります。

1

openkb chat

新しいファイルを自動処理したい場合は watch モードを使います。

1

openkb watch

その後 raw/ にファイルを置くと、OpenKB が自動的に wiki を更新します。

LLM 設定

OpenKB は LiteLLM を通じて、OpenAI、Claude、Gemini など複数のモデルプロバイダーに対応します。

モデルは初期化時に設定できますし、.openkb/config.yaml に書くこともできます。

1
2
3

model: gpt-5.4
language: en
pageindex_threshold: 20

モデル名は LiteLLM の provider/model 形式に従います。OpenAI モデルでは provider 接頭辞を省略できます。

1

model: gpt-5.4

Anthropic や Gemini のモデルは通常、次のように書きます。

1

model: anthropic/claude-sonnet-4-6

1

model: gemini/gemini-3.1-pro-preview

API key は .env に入れます。

1

LLM_API_KEY=your_llm_api_key

PageIndex Cloud を有効にする場合は、さらに追加します。

1

PAGEINDEX_API_KEY=your_pageindex_api_key

よく使うコマンド

OpenKB のコマンドは開発者にとって扱いやすいです。

• openkb init：新しいナレッジベースを初期化する。
• openkb add <file_or_dir>：ファイルまたはディレクトリを追加する。
• openkb remove <doc>：ドキュメントを削除し、関連する wiki ページ、画像、レジストリ、PageIndex 状態を整理する。
• openkb query "question"：ナレッジベースに対して単発の質問を行う。
• openkb chat：複数ターンの対話に入る。
• openkb watch：raw/ を監視し、自動更新する。
• openkb lint：構造と知識の健全性を確認する。
• openkb list：索引済みドキュメントと概念を一覧する。
• openkb status：ナレッジベースの統計を表示する。

openkb chat は、連続した探索には openkb query より向いています。セッションの再開、一覧、削除に対応し、チャット内では /status、/list、/add <path>、/save、/lint のような slash commands も使えます。

Markdown wiki が重要な理由

多くのナレッジベースツールで厄介なのは移行コストです。

資料が専用データベース、専用インデックス、専用フォーマットに入ると、直接確認、編集、バックアップ、移行するのが難しくなります。OpenKB は結果を通常の Markdown として書き出すため、既存ツールと自然に組み合わせられます。

最も直接的な使い方は、Obsidian で wiki/ を開くことです。

• 要約ページをそのまま読める。
• 概念ページを [[wikilinks]] で相互接続できる。
• グラフビューで知識間の関係を確認できる。
• 問い合わせ結果を explorations/ に保存できる。
• AGENTS.md でナレッジベースの維持方法を定義できる。

これにより OpenKB は単なる Q&A ツールではなく、個人やチームの知識整理パイプラインにもなります。

向いている場面

OpenKB は特に次の場面に向いています。

• 論文や技術レポートの読解。
• プロジェクト文書の整理。
• 製品調査資料庫。
• オープンソースプロジェクト周辺の文書ナレッジベース。
• 社内規程、会議メモ、説明資料の整理。
• 個人 Obsidian ナレッジベースの自動メンテナンス。
• 長い PDF、PPT、Word、Web 資料の構造化。

大量のドキュメントに向き合うとき、単に「一問一答」したいだけでなく、資料を徐々に閲覧可能、再利用可能、追跡可能な知識庫にしたいなら、OpenKB の方向性は合っています。

使うときの注意点

第一に、OpenKB は LLM の品質に依存します。

要約、概念ページ、相互リンクはモデルによって生成されます。モデルが強いほど知識コンパイルの品質は安定します。モデル能力が不足していると、概念抽出、矛盾検出、ドキュメント横断の統合は弱くなります。

第二に、コストは先に見積もるべきです。

大量の長文ドキュメントを一度に投入すると、LLM 呼び出しコストは低くありません。まず小規模な資料セットで試し、出力構造と品質を確認してから範囲を広げるのがよいです。

第三に、生成された wiki には人間の確認が必要です。

OpenKB は資料を整理できますが、事実の完全な正確性を自動保証するものではありません。重要な知識庫では、要約、概念ページ、引用関係を人間が確認する必要があります。

第四に、機密資料には慎重に扱う必要があります。

クラウド LLM や PageIndex Cloud を使う場合、文書内のプライバシー、営業秘密、コンプライアンス要件に注意してください。社内資料では、モデルプロバイダー、データ保持方針、アクセス境界を先に確認するのが安全です。

第五に、現時点では CLI ツール寄りです。

ロードマップでは Web UI、データベースストレージ、大規模コレクション対応、階層型概念インデックスが挙げられています。ただし現在の段階では、チームメンバーがコマンドラインに慣れていない場合、導入のハードルはまだあります。

Obsidian、NotebookLM、企業 RAG との関係

OpenKB と Obsidian の関係は、「自動整理レイヤー」と「閲覧・編集レイヤー」と考えると分かりやすいです。

Obsidian は人間が書き、直し、閲覧し、リンクを作るのに向いています。OpenKB は原始ドキュメントを Obsidian に入れられる wiki へまとめるのに向いています。

OpenKB と NotebookLM の違いは、「ローカルで制御しやすいこと」と「開かれたファイル形式」にあります。

NotebookLM は資料を入れてすぐ質問や要約を行う体験に優れています。OpenKB は、整理結果をローカルディレクトリに残し、Markdown として継続的に管理したい開発者に向いています。

OpenKB と企業 RAG の関係は、置き換えではなく補完です。

企業 RAG は権限、監査、サービス化、アクセス分離、監視、安定したスループットを重視します。OpenKB は、読みやすく編集しやすく長期的に蓄積できる知識レイヤーを作るのに向いています。将来的にオンライン Q&A を作る場合でも、OpenKB が生成した wiki は高品質なコーパスとして使えます。

おすすめのワークフロー

OpenKB を試すなら、次の順番がよいです。

1. テスト用のナレッジベースディレクトリを作る。
2. 同じテーマのドキュメントを 3 から 5 件入れる。
3. openkb add を実行する。
4. wiki/ を開いて要約と概念ページを確認する。
5. openkb query で具体的な質問をいくつか試す。
6. openkb lint でナレッジベースの健全性を確認する。
7. Obsidian で wiki/ を開き、リンクグラフが意味を持つか見る。
8. 品質を確認してから、より大きなドキュメント集合を取り込む。

最初から数百ファイルを一気に投入しないほうがよいです。まず自分の資料タイプをうまく理解できるか、特に表、画像、長い PDF、複数文書の概念統合を確認しましょう。

まとめ

OpenKB の価値は、LLM ナレッジベースを「問い合わせ時に一時的にコンテキストを組む」段階から一歩前に進めることです。まず資料を wiki として整理し、その wiki 上で質問、チャット、検査、継続的なメンテナンスを行います。

この方向性はすべての Q&A システムに合うわけではありませんが、長期的な蓄積が必要な知識作業には向いています。Markdown ファイル、Obsidian 互換、PageIndex による長文処理、複数モデル対応、CLI ワークフローを組み合わせると、開発者や調査型ユーザーにとって実用的なナレッジベースツールになります。

大量の PDF、レポート、Web ページ、論文、プロジェクト文書を持っているなら、OpenKB は試す価値があります。成熟した企業ナレッジベースをすぐ置き換えるものではないかもしれませんが、資料整理の入口としては実用的です。まずドキュメントを読める、リンクできる、追跡できる知識に変え、その上で LLM を働かせることができます。

参考リンク：

• VectifyAI/OpenKB
• OpenKB プロジェクトページ
• PageIndex
• markitdown
• LiteLLM