ドキュメント/ナレッジ系OSSの選び方｜知識グラフ・図解生成・構造化抽出マップ

AIは数秒でコードを書き、長い文章を要約します。ところが、生成された大量の情報を人間が「理解できる・検索できる・あとで再利用できる」形に整える作業は、いまだに手作業の負担として残っています。 コードベースの全体像を把握するには数時間、社内ドキュメントから必要な一節を探すにも時間がかかる——この「情報を知識に変える」ギャップを埋めるのが、本記事でまとめるドキュメント/ナレッジ系OSSです。

このカテゴリのOSSは「検索して文脈を渡す」RAGの前段、つまりRAGに食わせる知識そのものを作る側に位置するものが多くあります。RAG全体の仕組みから整理したい場合は、先にRAGとは？仕組み・構築・ベクトルDB選定までの2026年実装マップを読むと、本記事の各ツールが「知識を作る道具」か「検索する道具」かをすっきり区別できます。

このカテゴリの定義——「情報→知識」変換の3系統

ドキュメント/ナレッジ系OSSは、入力（何を読むか）と出力（何を作るか）の組み合わせで大きく3系統に分かれます。 まず全体像を1枚の図で押さえます。

3系統は排他ではありません。抽出・構造化系で取り出した構造データを、ナレッジグラフ・知識ベース系に流し込み、最終的にコード→図解系で俯瞰する——という連携が現場では起こります。 この記事では、まず系統ごとに代表OSSを比較し、最後に「自分の課題から逆引きする」マトリクスと選定フローを置きます。

なぜ今「情報→知識」変換が重要なのか

このカテゴリが2026年に厚みを増しているのには、はっきりした背景があります。 LLMによってコードや文章の「生成」コストが劇的に下がった結果、ボトルネックが生成から理解・検索・再利用の側に移動したからです。

1つ目の理由は、コードの増加です。AIエージェントが書くコード量が増えるほど、人間がレビューし全体像を保つコストが膨らみます。コードベースを図や知識グラフに落とすツールは、この「読む側」の負担を直接削ります。

2つ目は、コンテキストの経済性です。LLMにコードベース全体を読ませると、トークン消費とコストが跳ね上がります。知識グラフで索引を作り「必要な範囲だけ」を渡せれば、ツールコールもコストも減らせます。GraphifyやCodeGraphが大幅な削減を報告しているのは、この経済性に直接効いているからです。トークン最適化の全体像はAIエージェントのトークン最適化ガイドでも整理されています。

3つ目は、RAGの普及です。RAGが当たり前になるほど、「検索される側」の知識ベースの質が結果を左右します。PDFをきれいにMarkdown化する、文書から型付き構造を取り出す——という前処理の良し悪しが、そのままRAGの精度に直結します。

コード→図解・アーキ系——コードベースを「読める図」に変える

最初の系統は、コードベースやリポジトリを解析して、アーキテクチャ図・知識グラフ・ドキュメントに変換するOSSです。 AIが書いたコードを人間がレビューする・新メンバーが全体像をつかむ・LLM自身が効率よくコードを読む、といった場面で効きます。

コードからローカルに構成ドキュメントを残したいなら、oh-my-mermaidが入口です。コマンド一発でMermaid図つきのアーキテクチャドキュメントを.omm/に生成し、Gitで履歴管理できます。 同じ「コード→知識グラフ」でも、AIエージェントのトークン削減を主目的にするならGraphifyと、その実践編であるgraphifyでトークンを71.5倍削減する知識グラフスキル、そしてMCPサーバーとして動くCodeGraphが候補になります。

対話的にコードベースを探索したいならUnderstand Anything、ASTでコード知識グラフを構築するCode Review Graphも同系統です。 リポジトリ全体を「読み物」に起こしたい場合は、AI Wikiを自動生成するDeepWiki-Openや、Geminiでドキュメントとアーキ図を同時に作るGoogle Code Wikiが便利です。

図そのものをピンポイントで作りたいケースもあります。自然言語の指示からUMLやシーケンス図を生成するfireworks-tech-graphは、コードベース全体ではなく「この処理の図が欲しい」に応えます。 変わり種として、設計会議の音声からリアルタイムでMermaid図を起こすMeet HLD Agentもこの系統に入ります。

この系統には2つの流派があります。1つは「人間が読む図・ドキュメントを作る」流派（oh-my-mermaid・DeepWiki-Open・Google Code Wiki・fireworks-tech-graph）で、レビューやオンボーディングのコストを下げるのが狙いです。 もう1つは「AIが効率よくコードを読むためのグラフを作る」流派（Graphify・CodeGraph・Code Review Graph・Understand Anything）で、こちらはLLMのツールコールとトークンを減らすのが狙いです。 同じ「コード→グラフ」でも目的が違うため、まず読む主体が人間かAIかを決めると候補が一気に絞れます。両方を兼ねたい場合は、Gitに残るMermaid出力を持つツール（oh-my-mermaid）と、AI向け索引を持つツール（CodeGraph）を併用するのが現実的です。

ナレッジグラフ・知識ベース系——文書と会話を「検索できる知識」に統合

2つ目の系統は、文書・ノート・会話を集約し、横断検索できる知識ベースやナレッジグラフを構築するOSSです。 社内ドキュメントの検索、個人のセカンドブレイン、AIメモリの永続化といった用途に向きます。

データ量の制限なく自前で「NotebookLMのようなもの」を持ちたいなら、SurfSenseが第一候補です。自己ホスト可能で、複数ソースを横断する知識ベースを構築できます。 知識を「グラフ」として持ち、AIの長期記憶に使いたいならcogneeが向きます。ナレッジグラフ型のRAGメモリで、Claude APIやMCPと連携できます。

Markdownノート派には、ノート同士を意味でつなぐRust製のAtomicが軽量です。 ひと味違うのがClaude Memory Compilerで、Claude Codeとの会話そのものをフックで自動キャプチャし、知識記事へコンパイルします。RAGを使わないindex.md方式という設計が特徴です。

「知識グラフ × 検索」を一体で持ちたいならLightRAG、既存のNotebookLMをPython APIから一括処理・自動化したいならnotebooklm-pyが、それぞれ実用的な選択肢になります。

この系統を選ぶときに効くのは、データの置き場所の判断です。社外秘の文書や個人の記録を扱うなら、クラウドのNotebookLMではなくセルフホスト型（SurfSense・Atomic・cognee）が安心です。 逆に、すでにNotebookLMを使っていて運用を自動化したいだけなら、ゼロから知識ベースを作り直さずnotebooklm-pyで一括処理に寄せるほうが速く済みます。 もうひとつの軸は「入力が何か」です。整ったMarkdownノートを育てるならAtomic、雑多な複数ソースをまとめて飲み込ませるならSurfSense、AIエージェントの長期記憶として使うならcognee、というように入力の質と用途で住み分けると迷いません。

データ抽出・構造化系——PDF/Web/音声から「構造データ」を取り出す

3つ目は、非構造な入力（PDF・Office文書・Web・会議音声）から、Markdownや型付きの構造データを取り出すOSSです。 RAGや知識グラフの「前処理」を担うことが多く、このカテゴリの土台になります。

テキストから「型」を選んで知識構造を取り出すならHyper-Extractが強力で、グラフからハイパーグラフ、時空間グラフまで標準で扱えます。出典の位置を保ったまま構造化したいならGoogle LangExtractが向きます。

PDFの取り扱いは選択肢が多く、表・数式・レイアウトを高精度にMarkdown化するMinerU、ページ単位でAI解析して知識ベースを作るAI Reads Booksが代表です。Office文書まで含めるならofficeParser、Rustで前処理速度を稼ぐならliteparseが候補になります。 どのPDF抽出OSSがライセンス・用途に合うか迷ったら、用途別・ライセンス別に8本を比較したAI PDF要約ツール8選が選定の近道です。

Webを対象にするなら、自然言語の指示で構造データを抜き出すScrapling、会議の音声を文字起こしして要点まで抽出するMeetilyが、それぞれ「Web→構造」「音声→構造」を担います。

この系統で見落としやすいのが出典の追跡です。抽出した知識が「元のどこから来たか」を保てるかどうかで、後工程のファクトチェックのしやすさが変わります。Google LangExtractがソース位置の追跡を備えているのはこの理由からで、決算資料や契約書のように根拠が重要な文書では効いてきます。 また、PDFは「テキストレイヤーがあるか」「表や数式が多いか」で最適なツールが変わります。表・数式・段組みが多い学術PDFや財務資料ならMinerUの精度が活き、軽量に大量処理したいならliteparseやofficeParserが向きます。入力の性質をひとことで言語化してから選ぶと、前処理の作り直しを避けられます。

用途×OSS 推奨マトリクス——課題から逆引きする

ここまでの3系統を、よくある課題から逆引きできるようにまとめます。

まず「入力（何を読むか）」で系統を絞り、次に「出力（何を作るか）」で1本に決めるのが迷わない順番です。入力がコードなら①、文書・会話の集約なら②、PDF/Web/音声の取り出しなら③、と当たりをつけてから上の表を引いてください。

導入ステップ——小さく試して計測する

新しい知識化OSSを本番に入れる前に、次の流れで小さく検証するのが安全です。

特にエージェントのトークン削減を狙う知識グラフ系は、効果がコードベースの構造に依存します。 GraphifyやCodeGraphの削減率は公式に報告されていますが、自分のリポジトリで「ツールコール数・トークン量・所要時間」を実測してから判断するのが堅実です。

3系統は単体で使うだけでなく、つなげると効果が大きくなります。たとえば社内ナレッジ検索を作るなら、次のような連携が現実的です。

・③抽出・構造化：散らばったPDF・議事録をMinerUやMeetilyでMarkdown・構造データに変換する
・②ナレッジグラフ・知識ベース：それらをSurfSenseやcogneeに流し込み、横断検索できる知識ベースにする
・①コード→図解：関連する社内コードの全体像はoh-my-mermaidで図にし、ドキュメントと並べて参照する

この「抽出→統合→俯瞰」の流れを一度パイプラインとして組んでおくと、新しい文書やコードが増えても同じ手順で知識化を回せます。 最初から全部をつなぐ必要はありません。最も痛い1工程を1本のOSSで置き換えるところから始め、効果を確認しながら前後の工程を足していくのが、破綻しない進め方です。

まとめ——「情報を知識に変える」道具を1本ずつ揃える

ドキュメント/ナレッジ系OSSは、AIが生み出す大量の情報を、人間とAIの双方が扱える知識へ橋渡しする道具です。 3系統で整理すると、自分の課題がどこに当たるかが見えてきます。

・コードを図やドキュメントにしたい → oh-my-mermaid・Graphify・CodeGraph・DeepWiki-Open
・文書や会話を検索できる知識にしたい → SurfSense・cognee・Atomic
・PDF/Web/音声から構造を取り出したい → Hyper-Extract・MinerU・Google LangExtract

まずは課題を1つに絞り、入力で系統を選び、比較表から1本を試す——この順番で、自分のワークフローに合う知識化OSSを少しずつ揃えていくのがおすすめです。 個別のツールはこのトピック配下の各解説記事で、インストールから使い方まで一次ソースで掘り下げています。

最後に強調したいのは、知識化は一度作って終わりではなく、運用し続けるものだという点です。コードも文書も日々変わるため、図やグラフ、知識ベースは定期的に再生成して鮮度を保つ必要があります。 この観点では、出力がローカルファイルとしてGit管理できるツール（oh-my-mermaid・CodeGraph）や、フックで自動更新されるツール（Claude Memory Compiler）が、運用の手離れが良く有利です。導入時には「最初の生成のしやすさ」だけでなく「更新の自動化しやすさ」も評価軸に入れておくと、半年後に陳腐化した図を放置する事態を避けられます。 このトピックは今後も新しいOSSが登場するたびに各系統へ追記していく予定なので、知識化の道具を探すときの起点として使ってください。

参照ソース

・oh-my-mermaid 公式リポジトリ（github.com/oh-my-mermaid/oh-my-mermaid）
・RAGとは？仕組み・構築・ベクトルDB選定までの2026年実装マップ