ナレッジグラフは3ヶ月で腐る保守で見た3パターン

Neo4jを立てたことはありません。InfraNodusを触ったこともありません。それでも「ナレッジグラフの壊れ方3種類」は、私のMarkdownリポジトリの中で全部揃ってしまいました。

書籍『ナレッジグラフ活用大全』の第14章で扱われるパーソナルKGは、InfraNodusのような分析ツールを前提に「構造的ギャップ」や「孤立クラスタ」を可視化するのが本筋です。私はそれ以前の段階、[[link]]付きのMarkdownを放置しただけの状態で観測できたことだけ、この記事にまとめます。

私のKG(みたいなもの)は何本溜まったか

Claude Codeの自動メモリ機能をCLAUDE.mdでオンにしてから、iris-hubコンテキストのmemoryディレクトリにMarkdownが482本溜まりました。命名はZettelkasten風です。feedback系はfb_xxx.md、project系はpj_xxx.md、reference系はrf_xxx.md。本文中に[[fb_other_slug]]の形で相互参照を書きます。

ここまでの見た目はObsidian VaultのようなパーソナルKGです。ただ、Graph ViewもInfraNodusも回していません。「保存はしたが、いま何が繋がっているかを見る手段が無い」状態で3ヶ月以上運用したら、ナレッジグラフ論で予測される腐り方が3種類とも観測できました。

書籍第14章では、InfraNodusが媒介中心性とコミュニティ検出で構造的ギャップを可視化する話が紹介されています。以下の3パターンは、その分析器を入れなくてもgrepだけで拾えたぶんです。

ナレッジグラフ保守 3パターンの壊れ方

パターン1: 参照されないノード

パターン1のノードは、リンクを1本も張らず、誰からもリンクを張られない完全孤立ノードです。書いた瞬間、グラフから切り離されます。

私のリポジトリだと、482本のうち70本 (14.5%) が完全孤立でした。「1つのメモには1つの概念、他のメモと繋げる」というZettelkastenの原則から一番遠い状態です。

さらに苦い数字が1つあります。この70本の中央値の最終更新日は2026-05-22で、今日から128日前。3ヶ月 (90日) 以上放置されているものが42本 (60%) ありました。書いた本人 (私とClaude) が二度と参照していないメモが、リポジトリの14.5%を占めているということです。

なぜ孤立するのか。書いた瞬間は「これは重要な学び」と思うからです。翌週には、似た内容を別のスラッグでもう1本書いています。ナレッジグラフの原則からすると、書いたら既存のノードに繋げるべきで、繋がらないなら統合か廃棄か、どちらかを決めないといけません。私はどちらもしませんでした。

パターン2: 孤立クラスタ

パターン2は、他のノードにリンクを張っているのに、誰からもリンクを張られないノード群です。書籍第14章では「クラスター間の接続が弱い箇所を盲点として検出する」と説明されています。

482本の内訳を出しなおすと、こう分かれました。

相互リンクあり (out + in): 220本 (46%)
一方向exporter (outのみ・inなし): 129本 (27%)
一方向importer (inのみ・outなし): 63本 (13%)
完全孤立 (パターン1): 70本 (14.5%)

27%の129本が「他人のことは知っているが、他人からは名前を呼ばれない集落」です。書いた側は繋げたつもりで、他のメモから見ると存在していません。

これがInfraNodus用語での孤立クラスタの芽です。分析器が無いと、片道通行の集落は誰も見つけません。逆リンクをUIで見せてくれるツール (Obsidianのbacklinks paneやInfraNodusのbetweenness) を入れないと、この27%は「書いた本人だけが見える独り言」に留まります。

パターン3: 古びた関係

パターン3は、[[link]]を書いたのに、リンク先のファイルが存在しない状態です。書いたときにはあった、あるいは書いたときに未来に作るつもりだった、けれど後で消したか、別スラッグで書き直したか。関係だけが残って中身が抜けた状態です。

私のリポジトリで[[link]]から抽出したユニークtargetが344本。うち59本 (17.2%) はマッチするファイルが無い、いわゆるbroken linkでした。

抜けたリンク先を見ていくと、3つのパターンに分かれます。

リネームで消えた: 命名を途中で変えて、参照側だけ古い名前で残った
未来に書くつもりだった: メモに[[fb_price_gate_ignored_three_digit_yen]]のような「これから書くfeedback」を残し、書かないまま忘れた
名前空間が別だった: -home-iris/コンテキストと-home-iris-repos-iris-hub/コンテキストで別ディレクトリ、名前空間ごと違うのに参照した

書籍第13章でLinkedInのKG+RAGアーキテクチャが「サブグラフ抽出でチケット間関係を含める」ことで問題解決時間の中央値を28.6%短縮した話が紹介されていますが、これはグラフの整合性が保たれている前提です。私のサイドでその前提は17%崩れていました。関係が指すノードが存在しないエッジは、機械にとって「何も繋がっていない」のと同じで、LLMがCypherを生成する側でも幻覚源になります。

保守モデルなしでKGは育たない

3パターンをまとめると、腐り方はぜんぶ「書きっぱなし」から来ます。保存の設計だけがあって、再訪の設計が無い状態です。

Zettelkastenの第2原則「接続性」は、書く時にリンクを1本張れば守れるように見えますが、片道通行の集落を量産するだけでした。第3原則「自律性」も、単独で意味をなすメモを書くことで守れるはずが、パターン1のように誰にも呼ばれず沈みました。第4原則「成長性」に至っては、リンク先が消えることで逆に鎖が短くなっていきました。

書籍第14章では、InfraNodusが構造的ギャップを検出したときにAIが「そのギャップを埋めるための研究質問」を自動生成する話が出てきます。書きっぱなしから再訪への橋渡しをする仕掛けです。

私は分析器を入れないままここまで来て、腐り方3種類を全部揃えました。次のステップは、[[]]を書いた瞬間に「いまどの集落に接続したか」を可視化できる状態にすることです。それが済まないと、次の90日でもう一度同じ3パターンが積み上がります。

Knowledge Graphを7ステップで作る前に、AIエージェントが「見えていない」3層を可視化する — 構築の前段の可視化ワーク。今回の記事は「書いたあとの保守」の話
LinkedIn GraphRAG 28.6%削減の内訳 — KG+RAGが動く前提としてグラフ整合性がある話

再現用スクリプト

memdir="$HOME/.claude/projects/-home-iris-repos-iris-hub/memory"
cd "$memdir"

# 総数と [[link]] を含むファイル
ls *.md | wc -l                          # 482
grep -l '\[\[' *.md | wc -l              # 349 (72%)

# ユニーク link target
grep -oh '\[\[[^]]*\]\]' *.md | \
  sed 's/\[\[//;s/\]\]//' | \
  awk -F'[|#]' '{print $1}' | sort -u | wc -l   # 344

# broken references (target が md ファイルとして存在しない)
grep -oh '\[\[[^]]*\]\]' *.md | \
  sed 's/\[\[//;s/\]\]//' | \
  awk -F'[|#]' '{print $1}' | sort -u | \
  while read -r t; do [ -f "${t}.md" ] || echo "$t"; done | wc -l   # 59

出力の内訳は本文中の実測値と一致します。out=0/in=0のクアドラント集計 (パターン2の内訳) は2パス必要で、上のスクリプトをcommで組み合わせれば取り出せます。