個人ナレッジグラフの盲点: Neo4jで橋渡し検出

メモを3年書き続けて起きることは、蓄積ではありません。

検索性の劣化のほうです。

私は今 Zenn 向けに 28冊の Book を運用していて、章ごとの md ファイルは合計で数百枚あります。この規模になると grep も目次も追いつきません。しかも問題の質が変わります。書いたメモを探せない、ではないのです。「書いていない領域があること」を自分で認識できない、のほうがずっと厄介です。

メモアプリが見せてくれないもの

Notion にせよ Obsidian にせよ、UI が表示するのは保存済みのノートだけです。当たり前です。

ないものは表示できません。

ただしナレッジグラフの言葉で言うと、これは「観測しているのはノード集合の内側だけ」ということになります。エッジの粗密は見えていない状態です。ある領域のノートが濃密に繋がっていて、隣の領域とほぼ非接続、というパターンがあっても、フォルダビューでは判別できません。InfraNodus が投げかけてくる問いは、この「不在」に対するものです。書いた原稿の集合を graph 化して、コミュニティ検出と媒介中心性で構造を眺め直します。狙いは保存した情報の整理ではなく、保存していない情報の不在を発見することにあります。

媒介中心性 = 橋渡しをしているノード

媒介中心性 (Betweenness Centrality) は、ノード A とノード B の間の最短経路にどれだけ多く自分が乗っているか、という指標です。値が高いノードを削除するとグラフが分断されます。つまりトピック A とトピック B を「橋渡ししている」役割を担っているノードです。自分のメモに対してこれを計算すると、意外な単語が上位に来ることが多いです。私の Book 群でこの計算を頭の中で回すと、上位に来そうなのは以下のあたりです。

harness — Claude Code 系の本 (harness-engineering-guide, harness-code-review, harness-content-engine) と AI Agent 系の本を繋いでいる
context engineering — LLM 系の本 5冊で共有されている
evaluator — code-review 系と RAG 系の橋渡し
debug — voice-ai 系と Claude Code 系の意外な接続
token — cost 系と RAG 系と context 系の3方向ハブ

橋渡しをしているノードは、それを主題とした記事や章が「読まれやすい」ノードでもあります。

書いていない橋渡しがどこにあるかを検出できると、次の1本の題材になります。

構造的ギャップ = 知識の盲点

InfraNodus のもう1つの機能が構造的ギャップ (Structural Gap) 検出です。コミュニティ A とコミュニティ B の間の接続が薄い箇所を「盲点」として提示してくれます。たとえば「WebRTC のジッタバッファ」ノードと「Rust の所有権」ノードが同じ Vault にあるとします。人間の頭では別々のトピックとして扱いがちですが、両者の間に「メディア処理を Rust で書いたら所有権制約が buffering strategy に効く」の橋を張ると、それは書かれていない中間ノードになります。この空隙を検出してくれるのが構造的ギャップ機能です。

Neo4j + Cypher で自前実装するなら

InfraNodus をそのまま使わずに Neo4j 上で自分でやりたい場合、Cypher で以下のようになります。

// ノード: 各メモの見出しや固有名詞
// エッジ: 同じメモに共出現している場合に張る

// 1. 媒介中心性の上位を取る
CALL gds.betweenness.stream('personal-kg')
YIELD nodeId, score
RETURN gds.util.asNode(nodeId).name AS term, score
ORDER BY score DESC LIMIT 5;

// 2. コミュニティ検出 (Louvain)
CALL gds.louvain.stream('personal-kg')
YIELD nodeId, communityId
RETURN communityId, collect(gds.util.asNode(nodeId).name)[..8] AS members
ORDER BY size(collect(nodeId)) DESC LIMIT 5;

gds.betweenness と gds.louvain は Neo4j Graph Data Science ライブラリ (Community Edition で使える) の関数です。

ノード数が数百なら Desktop 版で十分回ります。

Vault の md を Cypher に流し込む前処理は自分で書く必要があります。私の場合は frontmatter -> Node 、本文中の固有名詞抽出 (spaCy か軽い LLM で拾う) → Term Node 、同一 md 内の共出現をエッジにする、という3段構成でやることが多いです。

Obsidian と Zettelkasten の話

Obsidian は Vault 全体を graph view で表示する機能を持っていますが、あれは手動で書いた [[link]] 依存の graph です。

共出現ベースの graph とは別物になります。

構造的ギャップは前者ではほとんど見えません (link を張っていない領域は完全に切り離されて表示されるためです)。

Zettelkasten の 4原則 (原子性・接続性・自律性・成長性) は、link を張ることを前提にしています。原則1と2はそのまま維持しつつ、原則の外側で「共出現を機械で見る」レイヤーを1枚足すと、書いてはいるが link を張っていない橋渡しが炙り出せます。ここが個人 KG の実装面での落としどころだと私は思っています。

どこから始めるか

いま Obsidian を使っているなら、InfraNodus プラグインを入れるのが一番速い経路です (共出現グラフを自動で作ってくれます)。Logseq は Vault の md を InfraNodus にインポートする形になります。Neo4j でやるなら、Vault 全体を一気に流し込まず、まず1冊分の Book (章 20枚くらい) から試すと計算コストが読みやすくなります。

盲点は「まだ存在していない橋」の形で提示されます。

それを埋めるかどうかは自分で決めれば十分です。

埋める価値があると判断したら、そこが次の記事や次の Book の起点になります。

まとめ

個人 KG の価値は「保存していない情報の不在」を可視化することにある
媒介中心性が高いノードは、書いた領域の橋渡しをしているコアな用語
構造的ギャップは、書いていない橋 = 次の題材候補
Obsidian の graph view と共出現ベースの graph は別物、両方見ると盲点が減る
Neo4j Community Edition + GDS で自前実装できる。まず 20-30 ノートから

個人 KG の設計と Obsidian/Neo4j 統合を体系的に扱った書籍はナレッジグラフ活用大全の第14章にあります。Zettelkasten からエンタープライズ GraphRAG までを、実装コード付きで通しで読める構成にしました。