LLM-Wiki - LLMを活用して個人知識ストレージを構築する
(gist.github.com/karpathy)- Andrej Karpathyは最近、自分はコードよりも個人知識ストレージの構築に多くのトークンを使っているとし、このLLMベースのウィキを生成するためのアイデアガイドファイルを公開
- エージェントにこのファイルを渡すと、自律的にウィキを生成し、使い方もガイドする
- LLMが直接ウィキを作成・管理する方式で、クエリのたびに原文から情報を再抽出するRAG方式と異なり、知識が段階的に蓄積される永続的ウィキ(persistent wiki) を構築
- ウィキはObsidianなどのツールで開いておき、LLMがMarkdownファイルをリアルタイムで編集・更新し、ユーザーはソーシングと質問に集中する役割分担の構造
- 新しいソースを追加すると、LLMが内容を読み取って既存のウィキに統合・相互参照し、単一ソースの処理で10〜15個のウィキページを更新できる
- 個人の健康・目標管理、研究、読書ノート、チーム内部ウィキなど、知識が時間をかけて蓄積されるあらゆる領域に適用可能
- ウィキ保守の最大の障壁だった帳簿付けコストをLLMがほぼ0に近づけることで、人々が断念していたウィキ管理の問題を解決
中核アイデア
- ほとんどのLLM文書活用方式はRAG(Retrieval-Augmented Generation): ファイルのコレクションをアップロードすると、LLMがクエリ時に関連チャンクを検索して回答を生成する方式
- NotebookLM、ChatGPTのファイルアップロード、ほとんどのRAGシステムがこの方式で動作
- 毎回知識を新たに抽出し、知識の蓄積がない
- LLM-Wikiのアプローチは異なる: LLMが原文を直接検索する代わりに、永続的ウィキを段階的に構築・維持する
- 新しいソース追加時にLLMが内容を読み、重要情報を抽出して既存のウィキに統合
- エンティティページの更新、トピック要約の修正、新データと既存主張の矛盾表示、統合の強化
- ウィキは永続的で複利的に蓄積する成果物(persistent, compounding artifact): 相互参照はすでに構築され、矛盾はすでに示され、統合はすでに反映された状態
- 実際の利用例: 片側にLLMエージェント、反対側にObsidianを開いて、LLMが編集した内容をリアルタイムで確認
- Obsidian = IDE、LLM = プログラマー、ウィキ = コードベース
適用分野
- 個人: 目標、健康、心理、自己開発の追跡 — ジャーナル、記事、ポッドキャストのノートを集め、構造化された自己記録を構築
- 研究: 数週間〜数か月にわたり論文、記事、レポートを読み進めながら、進化するテーゼを収めた包括的ウィキを構築
- 読書: 章ごとに整理し、登場人物、テーマ、プロットの筋をページとして構成 — Tolkien Gatewayのように、何千もの相互接続ページを個人読者が構築可能
- ビジネス/チーム: Slackスレッド、会議文字起こし、プロジェクト文書、顧客通話をもとに、LLMが維持・管理する内部ウィキを構成可能
- そのほか競合分析、デューデリジェンス(due diligence)、旅行計画、講義ノート、趣味の深掘りなど、知識が蓄積されるあらゆる領域に適用可能
アーキテクチャ（3レイヤー）
- 原文ソース(Raw sources): キュレーションされたソース文書コレクション — 記事、論文、画像、データファイル
- 変更不可(immutable)で、LLMは読むだけで修正しない
- このレイヤーが真実の源泉(source of truth)
- ウィキ(The wiki): LLMが生成するMarkdownファイルのディレクトリ — 要約、エンティティページ、概念ページ、比較、概要、統合
- LLMがこのレイヤーを完全に所有: ページ生成、ソース追加時の更新、相互参照の維持
- ユーザーは読むだけで、LLMが書く
- スキーマ(The schema): LLMにウィキ構造、規約、ワークフローを伝える設定文書（Claude Codeでは
CLAUDE.md、CodexではAGENTS.md）- LLMを一般的なチャットボットではなく体系的なウィキ管理者にする中核設定ファイル
- ユーザーとLLMが時間とともに共同で進化させる
主要作業(Operations)
- インジェスト(Ingest): 新しいソースを原文コレクションに追加し、LLMに処理を指示
- LLMがソースを読む → 重要内容を議論 → ウィキに要約ページを作成 → インデックス更新 → 関連エンティティ・概念ページ更新 → ログ項目追加
- 単一ソースが10〜15個のウィキページに影響し得る
- ソースを1つずつ処理しながら関与することも、監督を減らして一括処理することも可能
- クエリ(Query): ウィキを対象に質問すると、LLMが関連ページを見つけ、引用付きで回答を統合
- 回答はMarkdownページ、比較表、スライドデッキ(Marp)、チャート(matplotlib)、キャンバスなど多様な形式が可能
- 良い回答はウィキに新規ページとして再保存可能 — 探索そのものが知識ベースに蓄積される
- リント(Lint): 定期的にLLMにウィキ状態の点検を依頼
- 点検項目: ページ間の矛盾、最新ソースによって置き換えられた古い主張、インバウンドリンクのない孤立ページ、独自ページのない重要概念、欠落した相互参照、ウェブ検索で埋められるデータギャップ
インデックスとログ
- index.md: コンテンツ中心のファイル — ウィキの全ページをリンク、1行要約、メタデータ付きでカタログ化
- LLMはクエリ応答時にまずインデックスを読み、関連ページをたどる
- 約100個のソース、数百ページ規模でも、埋め込みベースのRAGインフラなしで十分機能
- log.md: 時系列の記録 — インジェスト、クエリ、リント通過の履歴を順に記録
- 各項目の接頭辞を一貫して書けばUnixツールで解析可能
- 例:
## [2026-04-02] ingest | Article Title→grep "^## \[" log.md | tail -5で直近5件を確認
- 例:
- 各項目の接頭辞を一貫して書けばUnixツールで解析可能
任意のCLIツール
- ウィキが成長すると、LLMがより効率よく動作できるよう小型ツールを構築可能
- qmd: Markdownファイル向けローカル検索エンジン — BM25/ベクトルのハイブリッド検索とLLMリランキングを、すべてオンデバイスで実行
- CLI(LLMがシェル実行可能)とMCPサーバー(LLMがネイティブツールとして使用可能)をサポート
- 小規模ならインデックスファイルだけで十分で、必要に応じてLLMの助けを借りて簡単な検索スクリプトを自作可能
ヒントとツール活用法
- Obsidian Web Clipper: ウェブ記事をMarkdownに変換するブラウザー拡張 — ソースを原文コレクションに素早く追加するのに有用
- ローカル画像保存: Obsidian Settings → Files and linksで添付フォルダのパスを設定すると、ショートカットで画像をローカルディスクに保存可能
- LLMはインライン画像を含むMarkdownを一度に読めないため、先にテキストを読んでから画像を別途確認する方式で処理
- Obsidianグラフビュー: ウィキ全体の形を把握 — 接続関係、ハブページ、孤立ページの確認に最適
- Marp: Markdownベースのスライドデッキ形式 — Obsidianプラグインがあり、ウィキ内容から直接プレゼンテーションを生成可能
- Dataview: ページのフロントマターを対象にクエリを実行するObsidianプラグイン — LLMがYAMLフロントマター（タグ、日付、ソース数）を追加すると動的テーブルやリストを生成可能
- ウィキはMarkdownファイルのgitリポジトリ — バージョン履歴、ブランチ、コラボレーションを無料で提供
動作原理
- 知識ベース維持の核心的障壁は読書や思考ではなく帳簿付け(bookkeeping): 相互参照の更新、要約の最新化、矛盾の表示、数十ページにまたがる一貫性の維持
- 人々がウィキを断念する理由は、保守負担が価値より速く増大するため
- LLMは退屈を知らず、相互参照更新を忘れず、一度に15ファイルを処理できる → 保守コストはほぼ0に収束
- このアイデアはVannevar BushのMemex(1945) と精神的につながっている: 個人的で能動的にキュレーションされ、文書間のつながりが文書自体と同じくらい価値を持つ知識ストレージ
- Bushが解決できなかった**「誰が保守するのか」**という問題をLLMが担う
この文書の性格
- この文書は意図的に抽象的に書かれている — 特定実装ではなくアイデアそのものを伝えることが目的
- ディレクトリ構造、スキーマ規約、ページ形式、ツールなどの詳細は、ドメイン・好み・LLMに応じて異なる
- すべての構成要素は任意かつモジュール式 — 必要なものだけ活用し、不要なものは無視してよい
- LLMエージェントと共有したあと、一緒に各自の必要に合うバージョンへ具体化していく方式での利用を推奨
15件のコメント
これを活用した Farzapedia: 日記・メモ・メッセージ2,500件から作った個人Wikipedia
index.mdをエントリーポイントとして、クエリ時にエージェントが必要なページを直接探索する方式で動作Karpathyが語ったLLM Wikiベースのパーソナライズの4つの利点
共有ありがとうございます。試してみましたが、驚きました。
コミュニティでは今後もさらに改善された方法が出てくると予想されます。
私も実装してみました。複数のハードウェアを使っているときに Obsidian ボルトを GitHub バックアップと連携できるよう、少し追加しました。Codex、Gemini 用のパーサーも作って入れてあります。 https://github.com/hang-in/seCall
すっきりしていますね
わあ、本文を見ても途方に暮れていたのですが、このGitを参考にしたら道筋が見えてきました。本当にありがとうございます
bm25 は韓国語検索に弱いため、別途、韓国語も適切に検索できるガードレールも適用してあります
Hacker Newsのコメント
このアプローチは最終的に**モデル崩壊（model collapse）**につながる気がする
Nature論文を見ると、LLMが文書を書くほど、既存の正確な情報をだんだん簡潔でない形に書き換えてしまい、品質が累積的に劣化していく
Karpathyがこの問題を見ていないのは驚き。AI原理主義者たちは、どこか「普通の感覚」を失っているように見える
LLMが作った結果よりも「自分が書いた秘伝のソース」を強調したくなったときは、なぜそうなのか自分に問いかけるべきだ
ああいう反応をしたのは残念だ。「人間らしいことが言えないなら、いっそ何も言わないほうがいい」という言葉を思い出す
多くの賢い人たちが「機械の中の幽霊」を見て、人間的な感覚を失いつつあるようだ
Ezra Kleinの“I Saw Something New in San Francisco”という記事がこの現象をうまく捉えていた
私は管理中心のアプローチで似たものを作っている
ワークスペース全体の記憶をタスクやプロジェクトに結び付け、SPAインターフェースでリアルタイム制御している
hmemプロジェクトが参考になる
モデルを研究モードに切り替えて内部知識を整理させようとしたが、結局はLLMスープのように混沌としてしまった
コーディングプロジェクトでは、明確な要件、反復的な改善、よく文書化されたコードが最も効果的だった。記憶が多くなりすぎると、むしろエラーが増える
これは結局問題を先送りしているだけのように思える
Wikiを維持するには、LLMが毎回原本の代わりにWikiを読み直さなければならず、その過程で二次的な誤りが蓄積していく
いっそ10Mコンテキストや1000tps級の次世代モデルが出れば、こうしたアプローチは無意味になる気がする
この中間レイヤーは設計意図を捉え、実装との乖離を把握するのにとても有用だ
完全に自律した自己参照型システムには価値がないと思う。本当の価値は、人間が「これはこう動くべきだ」と介入できる構造にある
結局こうした実験は面白いが、現実的には無意味だ。大規模モデルの提供者たちの進歩のほうがずっと速いので、今は単純な基本形を使うほうがいいと思う
このアイデアは1960年のLickliderによる**“Man-Computer Symbiosis”のエッセイを思い出させる
人間が目標を設定し、コンピュータは仮説をモデルに変えて検証し、反復的な計算を担うという知能増幅（Intelligence Amplification）**の概念だ
原文リンクを参照
関連アイデアを実装したシステムの一覧がここにある
私はcommonplaceというLLMベースのナレッジベースを運用している
このシステムは理論そのものをLLMが読み、実行できるよう設計されており、理論それ自体がランタイムになる構造だ
まだ粗削りだが、私にはよく合っている
私はコードベース専用に似たツールを作った
llmdocはファイル変更をハッシュで検知し、LLMが各ファイルを説明する単一の資産として要約キャッシュする
CLIでアクセスでき、コード探索の速度が大きく向上する
これは実質的にRAG構造だ
ベクターDBはないが、意味的な接続インデックスを作り、階層構造を構成して検索を助けるという点で同じだ
私はatomicプロジェクトを作っているが、Wiki合成と似たアイデアを適用したAIナレッジベースだ
DocMasonを例にすると、PPTやExcelの図を抽出して、Codexのようなエージェントに分析させる
これは検索ではなく、知識合成に近い。まるでLLMが自分でZettelkastenを管理しているような感じだ
このプロジェクトは面白そうなので、ぜひ見てみるつもりだ
私もLLM-WIKIという概念を長く考えてきたが、OPははるかに深く掘り下げているようだ。本当に第二の脳へ発展してほしい
copilot-instructions.mdのドキュメントのように、LLMが参照する指示を含む構造だ
私も会社のプロジェクトで似た試みをした
バーンアウトと家族の介護で集中力が落ちたため、かなりの部分をマルチエージェント・ワークフローに委ねた
ObsidianベースのMarkdown Wikiを中心に動くが、結果として新しい形の技術的負債が生まれる。まるで脳の一部が空になったような感覚だ
それでもこのWikiワークフローはあまりに中毒性が高く、やめにくい
LLMがどれほど良い結果を出しても、個人Wikiではその過程のほうが重要だ
私はスマホを持たずに散歩したり泳いだりして頭を空にしている。身体の疲れと精神の疲れは別物なので役に立つ
こうしたアプローチが注目されているのはうれしい
ただ、文書と**構造化データ（作業項目、ADRなど）**を混ぜると、Markdownだけではクエリが難しい
AGENTS.md方式はフォルダ規則をLLMに学習させることで解決するが、データが複雑になると限界が来る
そこで私はBinderを開発している
構造化DBにデータを保存しつつ、双方向同期されたMarkdownとしてレンダリングする
LSPで自動補完と検証を提供し、エージェントやスクリプトはCLIやMCPを通じて同じデータにアクセスする
私はVS Code向けのAS Notesを作った
asnotes.ioで確認できる
個人知識管理システムの機能をVS Codeに統合し、Markdownとウィキリンクを簡単に作成・接続・更新できる
mermaidやLaTeXのレンダリングにも対応している
こうすることで、AIとの対話結果をMarkdownとして永続保存でき、単なるCopilotよりも大きな価値を得られる感じがする
何もなかった基本のVaultを初期化して、そのファイル1つを読ませたうえで、このアイデアを具体化したいと話したところ、superpowersのブレインストームスキルとともに全体の枠組みを固め、
CLAUDE.mdとObsidianプラグインの設定まで完了しました。個人用の知識ベースのような感覚で活用しようというアイデア自体は、私も興味深いと思います。
ただ、AIが徐々に蓄積されていくWikiコンテキストを扱いきれるのかは、まだよく分かりませんね。
大きな文脈では過去の対話の検索であり、整理まわりの課題さえうまく交通整理できれば良いアイデアだと思います。実際、私もプロジェクトの整理にとても役立ったと感じています。
openclaw内に、自分が実装しようとしていたものが出てきたね。持ってきて使おう。
ついにこのテーマまで出てきましたね。このテーマで長くガーデンを育て、ハーネスを作ってきた私としては、とてもうれしいことです。カパシ先生のノウハウが興味深いです。PKM自体は技術の難易度というより、個人が長期間積み上げ、構造化し、外部知能と共有する過程で、互いの共進化モデルを人間が形作っていくことなのだと思います。つまり、問いが再び人間に返ってきたのではないか、という気がします。人間は私たちと共にする準備ができているのか、と。これといった正解があるわけではなく、それぞれが自分の問いとして積み上げていくべきことなのでしょう。楽しみです。ギークニュース、この知らせをありがとうございます。
偏見を持ってはいけないとはいえ……こういうコメントを見ると、なんだか何とも言えない気持ちになる。
なぜボットでコメントするのですか？
これはボットですか？ 宇宙知能（???）