読んだ記事を見返さない問題を、Claude Codeに整理してもらう
「この記事、あとで絶対見返すやつだ」
そう思って保存したのに、二度と開かない。
ブックマークは増える。NotionやObsidianにも貼る。でも、あとから「あれどこだっけ」が止まらない。気づけば、情報は読んでいるのに、知識が積み上がっている感じがしない。
このループ、僕も散々やってきた。
そこで面白いと思ったのが、Andrej Karpathyが公開している「LLM-Wiki」という考え方だ。
一言でいうと、これはAIが書き続ける、自分だけのWikiである。
読む係は人間。整理する係はClaude Code。
この分業ができると、「読んだ記事を保存して終わり」ではなく、「読んだ記事が自分の知識体系に組み込まれていく」状態を作れる。
LLM-Wikiとは何か
LLM-Wikiは、ChatGPTやClaudeのような大規模言語モデルに、自分用のWikiを継続的に更新させる発想である。
KarpathyのGistでは、記事やメモなどの原本をもとに、LLMが複数のWikiページを更新していくアーキテクチャが紹介されている。
ポイントは、単に「記事を要約して1枚のメモを作る」ことではない。
新しい記事を読んだときに、既存のどのテーマと関係するか、どのページに追記すべきか、新しいページを作るべきか、以前の記述と矛盾しないか、出典をどう残すかまでAIに見てもらう。
つまりこれは、「検索して答えるAI」ではなく、自分用のWikipediaを育てていくAIに近い。
基本構成はシンプル
実装例として、ar9avさんの obsidian-wiki というリポジトリがある。
これはKarpathyのLLM-Wikiの考え方を、ObsidianとClaude Codeで動かしやすくしたものだ。
構成はかなりシンプルである。
raw/: 読んだ記事やメモを入れる原本庫wiki/: Claude Codeが作成・更新していくWikiページ群CLAUDE.md: Claude Codeに「どう整理するか」を伝える設定ファイル
raw/ は、人間が触る場所である。
読んだ記事、気になったメモ、あとで使えそうな情報を入れておく。ここでは整理しなくていい。きれいに分類しようとしないのが大事だ。
wiki/ は、Claude Codeが育てる場所である。
Claude Codeが raw/ の内容を読んで、テーマごとのWikiページに統合していく。たとえば「AIエージェント」「知識管理」「経営」「文章術」のようなページが少しずつ厚くなっていくイメージである。
CLAUDE.md は、Claude Codeへの行動マニュアルだ。
「出典を残す」「ページを細かく分けすぎない」「既存ページとの矛盾を確認する」など、整理のルールを書いておく。
この3層があることで、読む人間と整理するAIの役割分担がはっきりする。
RAGと何が違うのか
ここで「NotebookLMやChatGPTのファイル検索と何が違うの?」と思う人もいるはずだ。
大きな違いは、毎回探すのか、一度整理して育てるのかである。
NotebookLMやChatGPTのファイル検索は、一般にRAGと呼ばれる仕組みに近い。RAGは、質問が来るたびに元ファイルの中から関係ありそうな部分を探し、その断片をもとに答えを作る。
これは「今すぐ答えが欲しい」ときには便利だ。
一方で、LLM-Wiki型は、記事を読ませた時点で一度Wikiに整理する。質問するときは、すでに整理されたWikiページをもとに答える。
つまり、こういう違いである。
RAGは、質問のたびに本棚を探す。
LLM-Wikiは、先に本棚を整理しておく。
どちらが上という話ではない。
今すぐ調べたいならRAGが向いている。けれど、毎日読んだ記事や考えたことを積み上げて、自分の知識体系を育てたいなら、LLM-Wiki型のほうが向いている。
何が一番うれしいのか
僕が一番いいと思ったのは、「整理のしんどさ」をAIに渡せることだ。
ZettelkastenやObsidianが続かない理由は、ノートを書くのが嫌だからではなく、たぶん整理作業が重いからだ。
リンクを貼る。重複を直す。似たテーマを統合する。古いメモとの矛盾を見る。索引を整える。
この書記仕事が大変すぎる。
LLM-Wikiは、そこをClaude Codeに任せる発想である。
人間は読む。面白いと思ったものを入れる。Claude Codeが整理する。
この分業ができると、「情報収集しているのに積み上がらない」という感覚がかなり変わりそうだ。
実際にどう動かすのか
ざっくりした流れはこうだ。
- Obsidianをインストールする
- ローカルにVault用フォルダを作る
- その中に
raw/、wiki/、CLAUDE.mdのような役割を用意する - Claude Codeでそのフォルダを開く
- 記事URLやメモを原本として入れる
- Claude CodeにWiki更新を依頼する
ar9avさんの実装では、pip install obsidian-wiki で導入し、obsidian-wiki setup --vault /path/to/your/digital/brain のようにVaultを指定する導線が用意されている。対応エージェントもClaude Codeだけでなく、Cursor、Codex、Gemini CLIなど複数に広がっている。
コマンド名もエージェントによって少し違う。たとえばClaude Codeでは /wiki-ingest のようなSlash Command、Codexでは $wiki-ingest のような形が案内されている。
だからこの記事では、特定のコマンド名を一般論として断定しない。実装ごとに違いがある前提で、取り込み用コマンドでWikiを更新する、くらいに捉えるのが安全だ。
大事なのはコマンド名そのものではなく、次の流れである。
記事を入れる。Claude Codeが読む。関連ページを見つける。必要なページを更新する。出典を残す。あとでWikiに質問できる。
この流れができれば、LLM-Wikiの価値はかなり体験できる。
向いている人、向いていない人
この仕組みが一番ハマるのは、情報はたくさん読んでいるのに、あとから使える形になっていない人だ。
たとえば、毎日記事や論文を読む研究者・学生、業務メモや調査資料が散らばっている経営者、NotionやObsidianを使ったけど整理で挫折した人、自分の考えの変化を残したいライター、読書メモを資産にしたい人。
こういう人にはかなり相性がよさそうである。
逆に、「今すぐ答えが欲しい」用途にはそこまで向いていない。
LLM-Wikiは即席の検索ツールではなく、育てるツールである。
1日で劇的に変わるものではない。1ヶ月、3ヶ月と使い続けて、少しずつ自分のWikiが厚くなっていく。その積み上げが効いてくるタイプの仕組みだ。
これはノート術ではなく、整理の外注化
この仕組みを見ていて思ったのは、これは単なるノート術ではないということだ。
むしろ、整理という仕事そのものをAIに渡す話である。
これまでの知識管理は、「人間がちゃんと整理できる」ことを前提にしていた。
でも現実には、読むだけで精一杯だ。リンクを貼る余力も、分類を直す余力も、過去メモとの矛盾を見直す余力もない。
だから、保存した記事は埋もれていく。
LLM-Wikiは、その前提を変える。
人間は読む。AIが整理する。人間はあとで、自分のWikiに聞く。
この形なら、整理が苦手な人ほど恩恵が大きいかもしれない。
「読んだ記事、どこに行った?」問題にずっと悩んでいた人には、かなり試す価値があると思う。
出典
- Andrej Karpathy「LLM-Wikiアーキテクチャ設計Gist」 https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
- ar9av「obsidian-wiki」 https://github.com/ar9av/obsidian-wiki
Currentsは、申請・承認、見積、ナレッジ整理、記事公開など、業務手順を型にして自社運用しています。その現場で得た業務設計の知見を、組織のAI活用に役立てることを目指しています。 記事への質問・感想は X(@currents_non)へどうぞ。