個人ナレッジグラフを3週間試して撤退した2ケース｜続けた1ケースとの分岐点

個人ナレッジグラフを、同時期に3プロジェクト立ち上げました。3週間後、2つを畳んで1つだけ残しました。

畳んだ2つが失敗したとは思っていません。畳むべきタイミングで畳んだから、残った1つに時間を寄せられました。ただ、その判断を後付けの気分で下した感覚があって、あとで自分の判断を再現できるように、3プロジェクトの実測ログをそのまま並べます。

結論を先に置くと、生き残ったのは 更新頻度が週2回以上・参照日数7日以内・ノード数200未満 に収まっていた1本だけでした。他の2つは、この3指標のどれかが早々に崩れました。

3プロジェクトの初期スペック

3つとも同じ日 (2026年7月中旬) に立ち上げました。ツールはObsidian + Dataviewで統一し、Neo4jへのエクスポートは週1回だけ手動でやっています。

• A: 読書ノートKG — 読んだ本から概念ノードを起こし、related_toエッジでつなぐ
• B: プロジェクト振り返りKG — 完了した案件の学びをproblem / solution / retro の3ラベルで蓄積
• C: 技術学習ロードマップKG — 学びたい技術と前提知識をdepends_onでつなぐ

「A/B/Cどれも自分に必要」と思って始めました。その時点で赤信号だったのですが、始めてみないと気づけないタイプの赤信号でした。

3週間後の実測値

3週間後、指標を全部取り直しました。

指標	A: 読書ノート	B: プロジェクト振り返り	C: 学習ロードマップ
ノード数	47	312	84
エッジ数	63	118	156
過去7日で参照した回数	3	1	22
週あたり更新回数 (直近3週間平均)	0.7	0.3	3.4
「立ち上げ時に想像した使い方」との一致度	低	中	高

Cだけが生きていました。AとBは、机の隅に置いた盆栽です。

撤退したケースA: 読書ノートKG

始める前は、「本を読んで概念を抜き出してつなげば、あとで縦断的に見返せる」と思っていました。3週間で47ノード出しました。

問題は、参照が3回しかなかったことです。

読み終えた本の内容は、実務で困ったときに検索するので、Obsidianの全文検索で足りました。「概念グラフを開いて眺める」という行動を、私は取らなかったのです。ノードを起こす作業には毎回30分くらい持っていかれたのに、それを見返さない。入力コストが出力価値を上回る状態が3週間続いたら、それはKGではなく作業です。

3週間目にAを畳みました。読書ノートは普通のObsidianノートに戻して、概念ノードは作らないことにしました。畳んだ瞬間、金曜夜に30分が返ってきました。

撤退したケースB: プロジェクト振り返りKG

Bは逆で、ノードは312個まで膨らんだのに参照が1回しかありませんでした。

過去の案件のproblem / solution / retro を全部拾っていくうちに、ノードが週100個ペースで増えました。しかも1つのproblemに対して当時のsolutionが2〜3個あって、結局「どの解決策が今も生きているか」がグラフでは分からない。分かるためにはretroノードを毎回書き足す必要があって、その手間がキツいのです。

ノード数が3桁を超えた瞬間、追加コストが指数的に増えました。 これはNeo4jやObsidianの性能問題ではなく、私が「この案件のretroはどのproblemノードにつなげるか」を考える負荷です。人間側の負荷です。

Bを畳んだのは、ノード数が300を超えた日でした。過去の300ノードで37.7%が腐った実測と同じ現象が、3週間で起きていました。

生き残ったケースC: 技術学習ロードマップKG

Cは、始めた1週目から使っていました。

「gRPCを学ぶ前にHTTP/2を知る必要がある」「Rustの所有権を理解する前にC++のスマートポインタを見ておくとラク」といった依存関係をdepends_onでつなぐ、それだけです。ノード数は3週間で84個、エッジは156本。密度が高いです。

参照は週22回。学習を進めるたびに「次に何を学ぶか」を決める判断に使っています。判断のために使うKGだけが生き残りました。 眺めるためのKGではなく、意思決定を1つ担うKG。

3指標で分岐した

3ケースを並べてみて、生死を分けたのはこの3つでした。

指標1: 参照日数 (直近7日で開いた回数)

• 生き残ったC: 22回 / 週
• 畳んだA: 3回 / 週
• 畳んだB: 1回 / 週

週7回未満 (1日1回未満) だと、次の週も開かなくなります。開かないKGは、腐り始めの合図です。

指標2: 週あたり更新回数

• 生き残ったC: 3.4回 / 週
• 畳んだA: 0.7回 / 週
• 畳んだB: 0.3回 / 週

週2回未満だと、KG側の情報が現実に追いつきません。エッジが古いままだと、参照した瞬間に信用を失います。

指標3: ノード数の増加ペース

• 生き残ったC: 週28ノードで安定
• 畳んだA: 週15ノードで頭打ち (関心が続かない)
• 畳んだB: 週100ノードで爆発 (境界が引けていない)

Cだけが「安定して増える」帯にいました。頭打ちも爆発も、どちらも撤退のサインです。

私が使っている撤退基準

これから個人KGを始める方に、3週間目のチェックリストを共有します。全部満たしたら続ける、1つでも欠けたら畳む、という基準で私は運用しています。

• 参照が週7回以上あるか — 1日1回開いていない=次の週も開かない
• 更新が週2回以上あるか — 週1回未満=情報が現実に追いつかない
• ノード数が200以下 or 週30ノード以下のペースで安定しているか — 300超え+週100増加=境界が引けていない
• 「判断のために使った」実例が3週間で3件以上あるか — 眺めるだけのKGは3ヶ月で腐る

3指標のどれかが崩れているだけなら再設計で戻せることもありますが、2指標以上崩れているなら畳むのが早いです。畳んだ時間は、次のKGに使えます。

参考書籍

ナレッジグラフ全般の設計・運用は、書籍側の第14章「パーソナルナレッジグラフ」で詳しく扱っています。特にInfraNodusとObsidianの統合、Zettelkastenの原則との対応、判断基準の設計は、この記事の3指標を組み上げる土台になっています。 → ナレッジグラフ実践ガイド

まとめ

個人ナレッジグラフを3プロジェクト同時に立ち上げて、3週間で2つ畳みました。

• 生き残ったのは「判断のために使うKG」1つだけ (学習ロードマップ)
• 畳んだのは「入力コストが出力価値を上回るKG」(読書ノート) と「境界が引けなかったKG」(プロジェクト振り返り)
• 分岐した指標は3つ: 参照日数・週更新頻度・ノード数の伸びペース
• 3週間目に3指標のうち2つ以上崩れていたら畳む、が私の運用ルール

畳むのは失敗ではないです。畳むのは、残す1つに時間を寄せる意思決定です。ナレッジグラフを続けたいなら、まず1つに絞る。それが私の3週間からの学びでした。