IVGraph
アイデアの出発点
2026年4月4日、OpenAIの共同創業者で、TeslaのAI部門責任者を務めたAndrej Karpathyが、llm-wiki.mdという短いgistを公開しました。これはツールでもリポジトリでもありません。自分のLLMエージェント（Claude CodeやCodexなど）に渡すためのアイデアをまとめたファイルで、受け取ったエージェントがあなたと一緒に具体的な実装を詰めていくものです。数か月のうちに5,000を超えるスターを集め、コミュニティによる実装が生まれ、「LLM wiki」は人々が積極的に検索する言葉になりました。
gist自体にある一言の説明は、「ObsidianがIDE、LLMがプログラマー、wikiがコードベース」です。資料の選択と質問は引き続きあなたが主導し、執筆、保存・整理、相互参照はすべてLLMが担います。
LLM wikiとRAG：一度の知識統合か、終わりのない検索か
AIとドキュメントを組み合わせた製品の多くは、RAG（検索拡張生成）の仕組みで動きます。ファイルをアップロードすると、質問のたびにモデルが関連する断片を取得し、その場で回答を組み立てます。機能はしますが、どの質問もゼロからの出発です。質問と質問の間に、何も蓄積されません。
LLM wikiは、この流れを逆転させます。新しい資料が届くと、LLMはそれをすぐに読み、重要な内容を抽出して、既存のページのネットワークに統合します。エンティティごとのページを更新し、要約を見直し、以前の資料との矛盾を指摘します。知識は一度統合され、その後も最新の状態に保たれます。そのため、回答は毎回、生の断片ではなく、すでに統合された全体像を出発点にできます。
| RAG | LLM wiki | |
|---|---|---|
| 情報を統合するタイミング | 質問のたびに、その都度 | 資料の取り込み時に一度 |
| 質問と質問の間 | 何も蓄積されません | 知識が積み重なっていきます |
| 矛盾 | 毎回発見し直します（または見落とします） | 資料の取り込み時に指摘します |
| 有用な回答 | チャット履歴に埋もれます | ページとしてwikiに保存します |
3つの層
gistで示された構成は、意図的に最小限に抑えられています。
- 元の資料 — 記事、論文、文字起こし、データファイルです。変更せずに保持し、LLMは読みますが、編集はしません。
- wiki — LLMが生成し、相互にリンクしたページです。要約、エンティティごとのページ、概念のページ、比較などが含まれます。この層はすべてLLMが管理し、あなたはそれを読みます。
- スキーマ — wikiの構成と、取り込み・回答・保守の際の振る舞いをエージェントに伝えるルールファイル（CLAUDE.md、AGENTS.md）です。これにより、汎用チャットボットが、ルールに沿って働く司書になります。
日々のwiki運用は、3つの操作で成り立ちます。取り込み（資料を入れるとLLMが統合します。たった一つの記事で10–15ページが更新されることもあります）、質問（質問をすると、有用な回答が新しいページとしてwikiに保存されます）、点検（矛盾、古くなった記述、どこからもリンクされていない孤立ページを定期的に確認します）です。
LLM wiki、セカンドブレイン、ナレッジベースの違い
これらの言葉は意味が重なり、検索結果でも常に混同されています。明確に区別すると、次のようになります。
| 用語 | 意味 | 管理するのは誰か |
|---|---|---|
| ナレッジベース | 情報を整理して保管するもの全般 | 管理の手間を引き受ける人 |
| セカンドブレイン | 学んだことを記録し、整理する個人的な実践 | あなた |
| LLM wiki | LLMが知識を統合し、最新の状態に保つナレッジベース | LLM |
最後の列が、違いのすべてを物語っています。人々がwikiやセカンドブレインを使わなくなるのは、相互参照の更新や、古い記述と新しい資料の整合性確認といった管理の手間が、得られる価値よりも速く増えるからです。LLMは飽きません。だからこそ、手作業の仕組みがひっそりと途絶える場面でも、この方法は定着します。
構築方法
知識を現在どこに保存しているかに応じて、実用的な方法は3つあります。
- Markdownファイル + Obsidian — Karpathyが最初に示した構成です。資料用フォルダ、wikiページ用フォルダ、ルールを記したCLAUDE.md、そしてターミナル上のエージェントを用意します。Obsidianのクリッパーで記事を取り込み、グラフビューで成長していくwikiの形を確認できます。
- Notion + MCP — メモやデータベースをすでにNotionに保存しているなら、移行は不要です。NotionのMCPサーバーを通じてエージェントを接続し、ページを直接読み書きさせます。一連の手順は、Notion向けLLM wiki：Claudeによるセカンドブレイン + 3Dナレッジグラフで最初から最後まで詳しく紹介しています。
- チームのwiki — 同じサイクルに会議の文字起こし、ドキュメント、チャットのスレッドを取り込み、更新内容を人が確認します。チームの誰もやりたがらない保守をLLMが担うため、wikiを最新の状態に保てます。
ナレッジグラフの役割
wikiはテキストですが、その構造はグラフです。ページがノード、リンクがエッジに相当します。Karpathyのgist自体も、成長するwikiの形を把握する最良の方法としてグラフビューを勧めています。どのページがハブになり、どれが孤立し、どこにクラスターができているかを確認できます。点検操作は、文字どおりグラフの健全性チェックです。
LLM wikiをNotionに置く場合、この点はさらに重要です。Notionにはグラフビューが標準搭載されていないからです。IVGraphは、その不足を補います。ワークスペース内のすべてのページ、バックリンク、データベース間のリレーションを、インタラクティブな3Dナレッジグラフとして表示するため、LLMが構築しているwikiが実際に形になっていく様子を確認できます。エージェントも、IVGraph LLM APIを通じて同じ構造にプログラムからクエリを実行できます。
よくある質問
LLM wikiとは、簡単に言うと何ですか？
AIがあなたに代わって構築・管理するナレッジベースです。資料と質問を渡すと、AIがページを書き、相互にリンクし、更新します。一度統合した知識を最新の状態に保つ仕組みで、質問のたびに元のファイルを検索し直す方法とは正反対です。
KarpathyのLLM wikiはGitHubのどこにありますか？
リポジトリではなく、2026年4月4日に公開されたgist、llm-wiki.mdです。設計上、インストールするものはありません。アイデアを自分のエージェントに貼り付け、一緒に自分用のwikiを構築します。
LLM wikiとセカンドブレイン、どちらが必要ですか？
競合するものではありません。セカンドブレインは実践であり、その管理をLLMに任せた形がLLM wikiです。すでにメモを取っているなら、それを管理するエージェントを加えるのが次のステップです。役割の分担は、上の表をご覧ください。
Obsidianは必要ですか？
いいえ。LLMが読み書きできる保存先なら、どれでも使えます。ローカルのMarkdownファイルが最も軽量な選択肢です。すでにNotionに知識を保存しているなら、MCP経由でNotionを使うのが自然です。データベースや共同作業の機能も利用できます。