AIが自動でメンテナンスし続けるナレッジベースをCursorで30分で作った

プロジェクトに関するドキュメントが15本ある。製品仕様書がここに、ミーティングの議事録がそこに、競合調査レポートはダウンロードフォルダのどこかに眠っている。

3ヶ月後、誰かにシンプルな質問をされる。そしてあなたは1時間かけて、かつて一度読んだあの1段落を探し回ることになります。

書類はある。知識はそこにある。でも散らばっていて、バラバラで、探せない。

知識労働者なら誰でも経験する「知識の迷子」状態です。

私はこの問題の解決策を見つけました。Andrej Karpathyの1ページのアイデア文書、AIコードエディタのCursor、無料のノートアプリObsidianを組み合わせたものです。そのアイデアから完全に動作するナレッジベースを作るまで約30分。どんなドキュメントを放り込んでも、構造化されたWikiページに変換し続けてくれます。

しかも私は、Wikiページを1ページも自分で書いていません。

Andrej KarpathyとはどんなAI研究者か
普通のAIツールとLLM Wikiは何が違うのか
3つの層と3つの操作
CursorでのLLM Wiki構築：3つのプロンプトで全て終わった
ファイル構造と実際の使い方
実際に使ってわかったこと
なぜwikiは続かないのか、そしてAIが変えること
TL;DR

Andrej KarpathyとはどんなAI研究者か

Karpathyの名前を知らなくても、彼がシェアしたものはAIコミュニティですぐ拡散します。OpenAIの創業メンバーで、テスラではAI・自動運転ビジョンチームを率いた人物で、技術の深い話を誰でもわかる言葉で説明することで知られています。私も彼のYouTubeの動画でお世話になっています。

最近、llm-wiki.mdという短いドキュメントを公開しました。製品でもアプリでもない。ただのアイデア文書です。AIエージェントを使ってパーソナルナレッジベースを構築・維持するパターンを、プレーンなMarkdownで書いたものです。

どんなAIエージェント（Claude、ChatGPT、Codexなど）にも貼り付けて使えるように設計されています。エージェントがそれを読んで仕組みを理解し、あなたのニーズに合わせた実装を作り上げます。

この1ページのアイデアが、今から紹介するものの全てのベースです。

普通のAIツールとLLM Wikiは何が違うのか

普通のAIツールはこう動きます。ドキュメントをアップロードして質問する。AIがファイルを検索して回答を生成する。これで十分機能しますが、AIは質問のたびに全てを忘れます。次の質問では最初から始まります。再読して、再検索して、再推論する。何も保存されない。何も積み上がらない。

LLM Wikiはこれを逆転させます。

AIが生のドキュメントを一度読んで、そこから構造化されたWikiを構築します。そのWikiはMarkdownファイルの集合体で、サマリーページ・製品ページ・概念ページ・用語集・比較表が全てWikiスタイルのリンクで繋がっています。新しいドキュメントを追加しても、最初からやり直しません。新しいソースを読んで、既存のWikiを更新し、必要な場所に追加し、矛盾を検出し、整合性を保ちます。

Wikiが積み上がり続ける成果物として機能します。使えば使うほど豊かになり、繋がりが増えていきます。

3つの層と3つの操作

LLM Wikiは3つのパーツから成り立っています。

raw/はあなたのドキュメントを置く場所です。PDF、Markdownファイル、クリップした記事、議事録、何でも構いません。AIはここから読み込むだけで、内容を変更しません。元データは手つかずのまま残ります。

wiki/はAIが全て作成・管理します。ページを構築し、クロスリファレンスを維持し、用語集を整備し、索引を更新します。あなたはブラウズするだけ。AIが書きます。

CLAUDE.mdは普通のAIをWiki専任の管理者として動かすための指示書です。どのページ種別が存在するか、新しいソースを処理するワークフロー、ページのフォーマット、問題チェックのタイミングが全て書かれています。

3つの操作も押さえておきます。

Ingest（投入） はドキュメントをraw/に置いてAIに処理を頼む操作です。AIはそれを読み込み、サマリーページを作成し、Wiki全体のエンティティページを更新し、新しい用語を用語集に追加し、索引を更新し、何をしたかをログに記録します。ソース1本で10〜15のWikiページに触れることもあります。

Query（質問） はWikiに問いかけます。AIは生のファイルではなくWikiを読んで回答します。役立つ回答はAnalysisページとしてWikiに保存できるので、質問すればするほどナレッジベースが豊かになります。

Lint（ヘルスチェック） はWikiの状態を確認します。矛盾、古い情報、リンクのない孤立ページ、欠けているクロスリファレンスを検出します。ナレッジベースのスペルチェックのようなものです。

CursorでのLLM Wiki構築：3つのプロンプトで全て終わった

実際に何が起きたかをそのまま書きます。

Cursorを開き、KarpathyのLLM Wiki原文を空のプロジェクトフォルダに入れ、AIに話しかけました。

プロンプト1

これは何ですか？テクニカルライターとして、どのように活用できますか？

Cursorはドキュメント全体を読んで、アイデアを私のロールにマッピングしました。

痛み	LLM Wikiによる解決
製品アップデートがドキュメント・Slack・メールに散在	全部投入すれば、AIが1つのWikiにまとめる
誰もメンテナンスしない用語集	AIが自動で構築・更新する生きた用語集になる
新しい製品やコードベースへのオンボーディング	仕様書とドキュメントを投入すれば、統合されたWikiが手に入る
一度やって捨てた競合調査	AIが時間とともに成長する比較分析を維持する

プロンプト2

計画を立てて、作成してください

たった5語です。Cursorはこのひとつのプロンプトでプロジェクトをまるごとプランして構築しました。raw/とwiki/フォルダの作成、エンティティ種別・ページフォーマット・9ステップのIngestワークフロー・Queryワークフロー・Lintワークフロー・セッション開始チェックリストを含むCLAUDE.mdの作成、そして4つのスターターWikiページ（index.md、log.md、overview.md、glossary.md）の作成まで、一気通貫で終わりました。

プロンプト3

Obsidianをセットアップしてください

CursorはHomebrewでObsidianをインストールし、Vaultを設定しました。新しいファイルはデフォルトでwiki/に保存、グラフビューはページ種別ごとに色分け、グラフビュー・検索・クイック切替のキーボードショートカットも設定済みです。

左にCursor（AIとの対話）、右にObsidian（リアルタイムでWikiをブラウズ）の2画面体制が完成しました。

ファイル構造と実際の使い方

リポジトリをクローンすると、次のような構成になります。

project-root/
│
├── llm-wiki.md              # Karpathyの原文アイデア文書
├── CLAUDE.md                 # スキーマ（Wikiの動かし方をAIに伝える）
│
├── raw/                      # ソースドキュメント（AIは読む、書かない）
│   └── .gitkeep
│
├── wiki/                     # AIが生成するナレッジベース
│   ├── index.md              # 全ページのカタログ
│   ├── log.md                # いつ何が起きたかの記録
│   ├── overview.md           # 全体像のサマリー（時間とともに進化）
│   ├── glossary.md           # 用語、定義、スタイルルール
│   └── sources/              # rawドキュメント1本につき1サマリー
│
└── .obsidian/                # 設定済みのObsidian Vault

この構造が機能する理由は、責任の分離が明確だからです。raw/はあなたのもの。wiki/はAIのもの。あなたはwiki/に書かない。AIはraw/を変えない。

Step 1: クローンする

git clone https://github.com/balukosuri/llm-wiki-karpathy
cd llm-wiki

Step 2: Cursorで開く

プロジェクトフォルダをCursorで開きます。AIはCLAUDE.mdを自動で読んで、Wikiの構造とルール全てを把握します。別のAIエージェント（Claude Code、Codexなど）を使う場合は、CLAUDE.mdの内容をエージェントのコンテキストに貼り付けます。

Step 3: Obsidianで開く

同じフォルダをObsidian Vaultとして開きます。Obsidianが入っていない場合は、Cursorにこう聞けばいいです。

Obsidianを私のためにセットアップしてください

インストールからVault設定まで全てやってくれます。

Step 4: raw/にソースを投入する

何でも構いません。製品仕様書やデザインドキュメント、ミーティングの議事録、クリップしたウェブ記事、スタイルガイド、PDFレポート、テキストとして保存したメールスレッド、受け付けます。

Step 5: 「投入して」と指示する

Cursorでこう打ちます。

raw/my-document.pdfを投入してください

AIはこの順番で作業します。

ドキュメントを読む
主要なポイントについて話し合う
wiki/sources/ にソースサマリーページを作成
見つけた製品・機能・ペルソナ・概念のページを新規作成
用語集を新しい用語で更新
索引を全新ページで更新
全体像が変わった場合は overview を更新
タイムスタンプ付きで wiki/log.md に全てを記録

Obsidianでページがリアルタイムに出現するのを見ると、初めてのときは少し驚きます。

Step 6: 質問する

全ソースで特定されている主なリスクは何ですか？

AIはWikiを読んで回答をまとめ、「これをWikiページとして保存しますか？」と聞いてきます。「はい」と答えると、その回答がWikiの恒久的なAnalysisページになります。質問がナレッジベースを豊かにする仕組みです。

Step 7: 使い続ける

ソースを追加するたびに、それまでの知識の上に積み上がっていきます。Overviewページが進化します。用語集が育ちます。クロスリファレンスが増えます。10〜15本のソースを投入すると、今まで気づいていなかったつながりをWikiが示してくれるようになります。

Step 8: ときどきLintをかける

10回Ingestするごとに一度くらい、こう打ちます。

Wikiをリントしてください

AIはページ間の矛盾、新しいソースで置き換えられた古い主張、リンクのない孤立ページ、言及されているのにページがない重要な概念、ページをまたいで不統一な用語を確認します。見つけた問題を報告し、どの修正を適用するか聞いてきます。

実際に使ってわかったこと

使い始めて気づいた、効果に差が出るポイントをまとめます。

ソースは1本ずつ投入する

まとめて複数のドキュメントをIngestすることもできますが、AIをガイドする機会を失います。サマリーを読んで、何を強調するかを伝えて、Ingest中に追加質問をする。あなたが関与するほどWikiは良くなります。

良い質問は保存する

質問して有用な回答を得たら、それをAnalysisページとして保存するようAIに指示してください。あなたの探索はWikiに蓄積されるべきで、チャット履歴の中に消えてはいけません。

グラフビューを使う

ObsidianでCmd+Gを押してみてください。どのページがハブで、どれが孤立していて、全体がどう繋がっているかを視覚的に確認できます。Wikiの成長を実感できる方法として、私はこれが一番好きです。

スキーマは自分用に書き換える

CLAUDE.mdは変更禁止ではありません。自分のドメインに新しいページ種別が必要なら（「APIエンドポイント」「顧客セグメント」「レシピのバリエーション」など）、スキーマに追加してAIに伝えてください。Wikiはあなたのニーズに合わせて変わります。

書く前に必ず用語集を確認する

何か書く前にwiki/glossary.mdを開きます。正しい用語、使ってはいけない用語、各選択の理由が全部あります。全部を頭に入れておかなくても、文章の一貫性が保てます。

自分でWikiページを書かない

この誘惑には負けないでください。あなたの仕事は良いソースを探して、良い質問をすること。AIの仕事はサマリー・クロスリファレンス・ファイリング・記録管理です。

なぜwikiは続かないのか、そしてAIが変えること

Wikiが廃れる理由は、知識へのこだわりが消えるからではありません。メンテナンスが重くなるからです。

クロスリファレンスの更新。サマリーの最新化。7ページ目と23ページ目が矛盾しないかの確認。用語集への新用語追加。新しいページと古いページのリンク設定。この作業は退屈で、繰り返しで、終わりがありません。だからWikiは古くなる。誰も信用しなくなる。やがて誰も開かなくなる。

AIはこの方程式を変えます。

AIはメンテナンスに疲れません。一度のパスで15ファイルを更新できます。新しい情報が古い主張と矛盾するときに検出します。用語集を最新に保ち、索引を完全に保ち、クロスリファレンスを整備し続けます。Wikiのメンテナンスコストがほぼゼロになります。

Karpathyは原文の中で、このアイデアが1945年のVannevar BushのMemexに関連すると述べています。文書を繋ぐ「連想の道筋」を持つパーソナルな知識ストアのビジョンです。私たちが作ったウェブはそれとは似ていません。公開で、ノイズが多く、文書間の繋がりはほとんど偶発的です。Bushのビジョンはプライベートで、キュレーションされ、深くパーソナルなものでした。LLM WikiはBushが想像したものに、過去80年間で作られたどんなものよりも近いと思います。Bushが解決できなかった部分は「誰がメンテナンスをするか」でした。今、その答えが出ました。

知識ベースの難しさは、読むことでも考えることでもありませんでした。ずっと、記録の維持だったのです。そしてそれはAIが最も得意とすることです。

TL;DR

問題：書類はある。でも知識がどこにあるかわからない。毎回一から探し直している。
LLM Wiki：AIがドキュメントを一度読んで、構造化されたWikiを構築・維持し続ける仕組み。RAWフォルダ（あなたのドキュメント）→ スキーマ（CLAUDE.md）→ Wikiフォルダ（AIが書く）の3層構造。
操作は3つ：Ingest（投入→自動更新）、Query（質問→回答をページ保存）、Lint（矛盾・孤立ページ検出）。
構築は30分：Cursorで「これは何か」「計画して作成」「Obsidianをセットアップ」の3プロンプトだけ。
続く理由：AIはメンテナンスに疲れない。クロスリファレンス更新も矛盾検出も用語集維持も全部AIの仕事。
あなたの仕事：良いソースを探すことと、良い質問をすること。それだけ。