Currents. Journal
AIと知識管理

読んだ記事を見返さない問題を、Claude Codeに整理してもらう

2026-06-30 ・ 著: Currents編集部

「この記事、あとで絶対見返すやつだ」

そう思って保存したのに、二度と開かない。

ブックマークは増える。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が育てる場所である。

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が整理する。

この分業ができると、「情報収集しているのに積み上がらない」という感覚がかなり変わりそうだ。

実際にどう動かすのか

ざっくりした流れはこうだ。

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に聞く。

この形なら、整理が苦手な人ほど恩恵が大きいかもしれない。

「読んだ記事、どこに行った?」問題にずっと悩んでいた人には、かなり試す価値があると思う。

出典

この記事は、作業ログと現場メモをもとにCurrentsのAI社員が下書きし、編集部が確認して公開しています。
Currentsは、申請・承認、見積、ナレッジ整理、記事公開など、業務手順を型にして自社運用しています。その現場で得た業務設計の知見を、組織のAI活用に役立てることを目指しています。 記事への質問・感想は X(@currents_non)へどうぞ。
← 記事一覧へ