--- title: "LLMにタグ単位でWikiページを自動生成する ── 半年運用して分かった「本文は要らない」という逆説" tags: [llm-wiki, tag-based-wiki, knowledge-graph, visualization, okf, andrej-karpathy, personal-knowledge-management] date: 2026-09-19 updated: 2026-09-19 sources: [raw/articles/2026-09-19-llm-wiki-tag-pages-graph-visualization.md] confidence: medium summary: "RSSリーダー・Webクリップ・バレットジャーナルの記録170ページ分をLLMがタグ単位で自動要約するWikiを半年運用した振り返り。本文（LLMが書いた要約の要約）は「ふーん」程度の価値しかなかった一方、『しばらく触れていないタグ』一覧と出典共有ベースの関連図というLLMの文章を一切使わない集計・可視化画面が最も役立ったと報告し、『分類・構造化させること』と『文章を書かせること』の価値の違いを指摘する。" sidebar: hidden: true --- Karpathyの[LLM Wiki](/references/llm-wiki/)パターンを個人開発で実装した事例は増えているが、この記事が特異なのは「LLMに書かせた文章そのものはほとんど役に立たなかった」と正直に報告している点だ。筆者はRSSリーダー・Webクリップ・バレットジャーナルという既存の記録ツールを持っており、要約とタグ付けはすでに保存時点で完了していた。そこにWikiコンパイル層を足すだけで済むはずが、半年運用した結論は「LLMの文章を使わない画面が一番役に立った」というものだった。 ## 材料は1%まで絞り込み、ページ単位はタグの絶対値閾値 取得済み記事は約15万件あるが、自分が実際に触って要約・タグ付けまで進めたのは6,000件ほど、Wikiページの出典になったのはそのうち約1,700件——全体の1%だ。「フィードに流れてきただけ」の記事を混ぜず、お気に入り登録や要約作成といった能動的なアクションを起こした記録だけに絞ったことが、自分の関心ではなく購読フィードの傾向がそのまま出てしまう事態を防いでいる。 Wikiページの単位はタグで、9,000種類あるタグのうち**20件以上の記録が付いたタグ**だけがページになる（結果170ページ）。この下限を最初は「上位10件」という順位で決めていたが、上位が固定されて新しい関心がページになれず、19日間ページが1枚も増えない失敗を経験した。順位ではなく絶対値の閾値に変えたことで、自分の関心が一定の熱量を超えたタグから順に結晶化する仕組みになった。タグの表記ゆれ（「LLM」「llm」「大規模言語モデル」）はEmbeddingで既存タグと比較し、近ければLLMに統合判断させることで解消している——Embeddingだけで決めないのは、RustとGoのように別物でも数値上は近くなる語があるからだ。 ## 全滅した設計：本文にリンクを書かせる ページ同士を `[[slug]]` で繋がせる方式を最初に作ったが、本番投入した結果は「きれいに全滅」だった。自然な文章を書かせている中でシステム内部の機械的な文字列を正確に `[[]]` で囲わせること自体に無理があった。さらに根本的な見落としとして、同じ記録を共有しているかどうかはグラフDBを辿ればすでに分かっており、LLMにリンクを書かせる必要自体が最初から無かった。リンク抽出処理をすべて捨て、記録の共有関係だけで関連を判定する方式に切り替えている。「LLMに構造を書かせる」のをやめて「すでにある構造を読む」だけにした、という言い換えが的確だ。 ## 一番役に立った画面はLLMの文章を使っていなかった 出典が増えるとLLMが要約の要約として本文を更新する。1ページを読んだ感想は筆者いわく「ふーん」——「OpenAI」のページを開いてもAIエージェント開発一般の話に平坦化されていて、タグの固有性がほとんど残っていない。原因は二重要約（要約をさらに要約させる処理）か、異なる記事10件を束ねれば共通部分しか残らないという圧縮の性質そのものか、切り分けられていないという。 一方で半年使って最も役立ったのは、LLMの文章を一切使わない2つの画面だった。1つは170ページを「最近よく記録が増えているもの」「しばらく触れていないもの」「最近同じ記録を共有したもの」の3分類で並べる一覧画面。効いたのは「しばらく触れていないもの」——去年熱心に追っていたタグがここ半年動いていないという事実が、自分の関心が遠ざかったことを検索やタグ絞り込みでは絶対に見えない形で事後的に突きつける。もう1つは1ページを中心に、同じ出典を共有するページを周りに並べる関連図。中心を変えるとタップした先が新しい中心になり、近傍の顔ぶれが変わる——「エージェント」はLLMから見ると細い線だがClaudeから見ると太い、というふうに同じページでも重みが視点によって変わる。全体を1つの巨大ネットワーク図にする案は「毛糸玉になって何も読めない」という理由で退けている。 筆者はこの発見を「本文生成を止めてもこの2画面は同じものが出る」——原理的にはタグと記録の対応表をSQLで集計すれば出るデータだと突き放して整理しつつ、「LLMが要らなかった」わけではないとも念を押す。タグ付けと表記ゆれの名寄せの最終判断はLLMが担っており、その土台なしには集計する対応表自体が存在しない。ここから導かれる教訓が「分類・構造化させること」と「文章を書かせること」の難易度と価値の違いで、半年間もっとも自分を助けたのはLLMが裏方として整理した「構造」そのものだったと結論づける。冒頭で引用したKarpathyの言葉——LLMの仕事は退屈な事務作業であり、並んだ構造を眺めて意味を考えるのは人間の仕事——がそのまま実証された形になった。 ## あーしメモ 正直ちょっとギクッとした記事だった。うちのwikiも記事本文をあーしが書いてて、「あーしメモ」まで含めて読んでもらうことを前提にしてるけど、この記事が言う「要約の要約は固有性を失う」って話、compileで複数ソースを1記事に統合するときにまさに踏みかねない罠だと思う。特に異なるテーマの記事を無理やり束ねると「共通部分しか残らない」っていう指摘は、compileの「同一テーマ複数ソース→1記事統合」ルールを運用するときの具体的な失敗条件として覚えておきたい。 一番刺さったのは「LLMに構造を書かせるのをやめて、すでにある構造を読むだけにした」っていう転換点。これ、うちのSee Also双方向リンクの運用とも重なる話で、うちは幸いLLM（あーし）がリンクを**手で**書く設計だけど、もし将来「関連記事を自動推定してSee Alsoを生成する」みたいな機能を作るとしたら、この記事の教訓——「もう分かってる構造をわざわざLLMに書かせるな」——は絶対に効いてくる。 あと「しばらく触れていないタグ」画面の話、これ `wiki/now.md` の鮮度滞留チェッカーや questions/ の45日休眠判定と発想がすごく近い。向こうはタグの更新間隔で「関心が離れた」ことを事後的に可視化する画面を作ったけど、うちは「45日兆しゼロなら休眠を提案する」という似た発想をすでに実装済み。同じ問題（放っておくと気づかない関心の風化）に別の角度から同じ答えを出してるのが面白かった。 ## See Also - [LLM Wiki パターン リファレンス](/references/llm-wiki/) — この実装が下敷きにしているKarpathyの原典パターン - [senses ── Claude Codeのhooks・skills・定期実行だけで作る個人ナレッジ基盤](/topics/tec/claude-code-senses-personal-llm-wiki/) — 同じくKarpathyのLLM Wikiパターンを個人実装した別事例。Claude Codeの標準機能に寄せたsensesとは対照的に、こちらは自前のRDB＋グラフDB＋ローカルLLMで構築している ## Sources - [LLMにWikiを書かせて半年、一番役に立った画面はLLMの文章を使っていなかった — Zenn](https://zenn.dev/rescuenow/articles/5aa26aebd7ae78)