Yyatmita

【第9回】127本の動画ノートを AI に渡したら、知識の地図ができた——LLM Wiki という考え方

Andrej Karpathy が提唱した LLM Wiki を Obsidian で実践。動画ノートから概念を抽出し、自動でリンクを張り、グラフビューで関係性を可視化するまでの PoC 記録

Obsidianをはじめました#obsidian#knowledge-management#llm-wiki#claude-code#rag
← 前の記事: 【第8回】ノートを3万件貯めたら、AIに使わせたくなった

ノートはたまった。でも「つながり」が見えない

このシリーズでは、動画メモから始めて、YAML、Dataview、タイムスタンプ、比較ノート、実験ノートと進んできました。ノートを保存して、整理して、検索して、記録して、比較して、実験する——6つの段階を経て、「使える知識」を育てる流れができた、というところまでが前回のまとめです。

でも、ノートが100本を超えたあたりから、別の問題が見えてきました。

たとえば、ある分野の動画ノートが127本ある。テーマは基礎理論、応用手法、ツールの使い方と多岐にわたる。フォルダには全部入っている。Dataview で条件検索もできる。でも、ノート同士がどうつながっているのかが見えない。

ある理論が20本のノートに出てくるとして、そのうちどれが入門でどれが応用なのか。ある手法とある理論はどう関係しているのか。あるツールはどの手法で使われているのか。

1本ずつノートを開けばわかる。でもそれは、127本を頭の中で全部覚えておくのと同じことです。

そんなときに出会ったのが、Andrej Karpathy の「LLM Wiki」というアイデアでした。

LLM Wiki とは何か

Andrej Karpathy は OpenAI のリサーチャーで、テスラの AI チームを率いていたことでも知られる人物です。2026年の春、彼が X（旧 Twitter）に投稿したアイデアが大きな反響を呼びました。

「LLM を使って個人のナレッジベースを作っている。ベクターデータベースも RAG パイプラインも不要。Markdown ファイルだけでいい」

彼が提案したのは、こういう構造です。

my-wiki/
├── raw/        ← 生データを入れる場所
├── wiki/       ← LLM が自動生成するページ
│   ├── index.md
│   └── log.md
└── CLAUDE.md   ← LLM への指示書

raw/ にソースとなる文章——論文、記事、メモ——を放り込む。すると LLM（この場合は Claude Code）がそれを読み、wiki/ に整理されたページを自動生成する。概念ごとにページを分け、ページ同士にリンクを張り、目次（index.md）まで作ってくれる。

つまり LLM に「読んで、まとめて、つなげて」を全部やらせる。人間がやるのは、生データを raw/ に入れることだけ。

いくつかの概念を整理しておく

LLM Wiki の話をすると、いくつかの技術用語が出てきます。先に整理しておきます。

RAG（Retrieval-Augmented Generation）

「検索で情報を引っ張ってきてから、AI に回答させる」手法です。

たとえば社内ドキュメントが1万件あるとします。質問されたら、まずその1万件から関連しそうなものを検索で絞り込み、上位数件を AI に渡して回答を生成させる。AI が持っていない最新情報や社内固有の情報を扱えるようになるのがメリットです。

従来の RAG では、テキストを「ベクター」と呼ばれる数値に変換して、意味的に近い文章を高速に見つける仕組み（ベクターデータベース）を使います。これには専用のインフラが必要で、セットアップに手間がかかります。

LLM Wiki のアプローチ

Karpathy の LLM Wiki は、この RAG の「簡易版」ともいえる考え方です。

ベクターデータベースは使いません。代わりに、よく整理された Markdown ファイルとリンク構造で知識を管理します。AI が質問に答えるときは、まず index.md（目次）を読み、そこからリンクをたどって関連ページだけを読む。全文を読む必要がないので、トークン（AI が処理するテキストの量）を大幅に節約できます。

ある X ユーザーは、383個のバラバラなファイルと100件以上の会議録を LLM Wiki にまとめたところ、AI への質問時のトークン消費が95%減ったと報告しています。

なぜ Obsidian と相性がいいのか

LLM Wiki の実体は「リンクでつながった Markdown ファイル群」です。それはまさに Obsidian が得意とする形式です。

Obsidian の [[リンク]] 記法でページ同士をつなぎ、グラフビューで関係性を可視化する。LLM が生成したリンク構造を、人間が目で確認できる。この組み合わせが、LLM Wiki を「ただの AI 出力」から「育てられるナレッジベース」に変えてくれます。

実際にやってみた

理屈はわかった。でも本当に使えるのか。手元にある動画ノート127本で試してみることにしました。

素材: ある FX チャンネルの動画ノート127本

あるトレーダーの YouTube チャンネルの動画を、1本ずつ Obsidian のノートにしたものが127本あります。各ノートには、動画の要約・主要ポイント・書き起こしが含まれています。

テーマは幅広い。相場理論、波動分析、スキャルピング手法、インジケーター、チャートパターン——ひとつのチャンネルの中に、体系的な知識がバラバラに散らばっています。

ステップ 1: フォルダ構造を作る

まず、既存の動画ノートを raw として扱い、その隣に wiki/ フォルダを作りました。

my-topic/
├── video-notes/   ← raw（動画ノート127本）
├── wiki/          ← これから AI が生成するページ
└── CLAUDE.md      ← AI への指示書

CLAUDE.md には、wiki ページのフォーマットやリンクのルールを書いておきます。「概念ページにはこういう構造で書いてね」「ソースノートへのリンクはこう張ってね」という指示書です。

ステップ 2: まず20本を読ませて、概念を抽出する

127本を一度に読ませるとトークン消費が大きいので、まず20本に絞って試しました。

Claude Code に「この20本の要約と主要ポイントを読んで、概念・手法・インジケーター・チャートパターンに分類して」と指示します。すると、こんな結果が返ってきました。

  • 概念: 16項目——相場理論の基礎、トレンド判断の手法、時間帯ごとの市場特性など
  • 手法: 15項目——ブレイクアウト系、反転系、スキャルピング系など
  • インジケーター: 14項目——移動平均線の活用法からオリジナルツールまで
  • チャートパターン: 11項目——反転パターン、継続パターン、不安定パターンなど

20本のノートから、56の概念が抽出されました。

ステップ 3: wiki ページを自動生成する

抽出された56項目それぞれについて、wiki ページを生成させます。1ページの構造はこんな形です。

# 概念名
 
## 概要
1-3文の説明
 
## 詳細
- 具体的な内容
- 使い方や注意点
 
## 関連ソース
- [[video-notes/動画ノートA]] — この動画での解説内容
- [[video-notes/動画ノートB]] — 別の文脈での言及
 
## 関連ページ
- [[wiki/関連する概念]]
- [[wiki/関連する手法]]

ポイントは2種類のリンクです。[[video-notes/...]] は元の動画ノート（raw）へのリンク。[[wiki/...]] は他の wiki ページへのリンク。これで、概念と元データが双方向につながります。

グラフビューで見えたもの

56ページの wiki が生成された時点で、Obsidian のグラフビューを開いてみました。

ノードがずらりと並び、リンクの線が網目のように張り巡らされています。中心にあるのは基礎理論や環境認識といった土台の概念。そこから放射状に手法やパターンが伸びている。

見えてきたのは、このチャンネルの知識体系には明確な階層があるということです。

まず土台に基礎理論がある。その上にトレンド分析や環境認識がある。さらにその上に、具体的な手法が乗っている。そしてそれらを支えるインジケーター群がある。

1本ずつ動画を見ていたときには、各動画が独立した「テクニック紹介」に見えていました。でも wiki にして俯瞰すると、全体がひとつの体系として設計されていることがわかります。基礎理論を理解していないと、その上に乗る手法の意味がわからない。だから講師は何度も「まず基礎から」と言っていたんだ、と腑に落ちました。

これは127本を全部読んでもなかなか見えないものです。LLM が「つながり」を明示してくれたことで、初めて構造が見えた。

浅さの問題と、深さの作り方

ここまでの話を聞くと、万能に思えるかもしれません。でも正直に書いておくべきことがあります。

最初に生成された wiki ページは、浅い。

たとえばあるインジケーターのページ。最初は「移動平均線を中心にバンドを表示するインジケーター。エントリー根拠の複数化に使用」としか書かれていませんでした。これは教科書の1行目と同じで、講師固有の知見がまったく入っていません。

なぜ浅いか。AI が読んだのが「要約」と「主要ポイント」だけで、書き起こし全文を読んでいなかったからです。要約にはエッセンスが凝縮されていますが、具体的な手順やよくある間違い、講師独自の視点といった「厚み」は、書き起こしの中にしかありません。

そこで、そのインジケーターだけ「深く書き直し」を試みました。127本のノートからキーワード検索すると、15本のノートで言及されていました。そのうち専門的に解説している2本の書き起こしを全文読ませて、wiki ページを再生成。

結果、28行だったページが100行に。具体的には——

  • 「よくある間違い」として講師が明確に否定しているエントリー方法
  • 推奨する具体的なエントリー手法（水平線との組み合わせが必須）
  • オリジナルツールを使った応用テクニック
  • 見送るべきパターン（特定の市場イベント時、準備不足の状態）
  • 「理論の暗記は不要。実践で使い込むこと」という実践者ならではのスタンス

——こうした「この講師にしか言えないこと」が詰まったページになりました。教科書のコピーではなく、127本の動画を横断して蒸留された知識です。

つまり LLM Wiki は、最初から完璧なものができるわけではない。まず浅く広く構造を作り、必要なところから深くしていく。その段階的なプロセスこそが、この方法の本質だと思います。

RAG との違いをもう少し

技術に興味がある方のために、従来の RAG との違いをもう少し掘り下げます。

従来の RAG

ドキュメント → チャンク分割 → ベクター変換 → ベクターDB に格納
質問 → ベクター検索 → 上位k件を取得 → LLM に渡して回答生成

「意味的に近い」チャンクを数学的に見つける仕組みです。数百万件のドキュメントでも高速に検索でき、企業のナレッジベースではこちらが主流です。ただし、ベクター変換の精度に依存するため、文脈を跨いだ関係性は見落としやすい。

LLM Wiki

ドキュメント → LLM が読んで理解 → wiki ページ + リンク構造を生成
質問 → index.md を読む → リンクをたどって関連ページを読む → 回答

LLM が「理解して書き直した」知識を、リンクでつないだ構造です。検索ではなく「ナビゲーション」で情報にたどり着く。ベクターDB も embedding も不要。コストはトークン消費のみ。メンテナンスは lint（整合性チェック）で済む。

使い分け

Karpathy 自身が言うように、数百ページまでなら LLM Wiki、数百万ドキュメントなら従来の RAG。個人の知識管理なら、LLM Wiki で十分です。

個人的に感じた最大の違いは「構造が目に見える」ことです。ベクターDB の中身は人間には見えませんが、wiki ページは普通のテキストファイルなので、Obsidian で開いて読めるし、グラフビューで眺められる。AI が作った知識構造を人間が検証できる。これは思った以上に大きなメリットでした。

今の段階でわかったこと

PoC（概念検証）なので、まだ完成形ではありません。でもいくつかのことがわかりました。

うまくいったこと:
  • 127本のノートから56の概念が自動抽出され、ページ間のリンクが張られた
  • グラフビューで知識の全体構造が可視化された
  • 「基礎理論が土台、その上に手法が乗る」という階層が見えた
  • 必要に応じて特定ページだけ深く書き直せる
課題:
  • 最初の生成は浅い。書き起こし全文を読ませないと、講師固有の知見が抜ける
  • 全ページを深くするにはトークン消費が大きい
  • 新しいノートを追加したときの「差分更新」の仕組みはまだない

次のステップとしては、別のチャンネルの動画ノートも混ぜていくことを考えています。同じ概念でも、チャンネルごとに切り口が違う。それが1つの wiki ページに集約されたら、「この人はこう言っている、別の人はこう言っている」と並べて比較できるようになる。個人のメモが、本当の意味でのナレッジベースになっていく。

追記: 翌日、全ページを深掘りしてみた

ここまでが PoC の最初の到達点でした。記事を書いた翌日、続きをやってみたら、想像していなかった景色が見えてきたので追記します。

バックグラウンドエージェントという発見

最初の深掘りは「1ページずつ手動で書き直す」やり方でした。これを51ページ分やるのは現実的じゃない。そこで Claude Code のサブエージェントをバックグラウンドで並列起動するという運用を試しました。

「このページとこのページとこのページを、それぞれ別エージェントで深掘りして」
↓
3つのエージェントが同時に走る。書き起こしを読み、ページを書き直し、保存する。
↓
こちらは何も承認しない。完了通知だけ受け取る。

普段 Claude Code を使うと、ファイル編集のたびに承認プロンプトが出ます。これがバックグラウンドエージェントだと出ない。エージェント自身が完結したタスクとして動くので、こちらは「6つ起動して」と言って待つだけ。これに気づいてから一気に進みました。

並列度は6前後にしておきました。質が落ちるからではなく、単純にメモリ不足で落ちないかが怖かっただけです。実際にはもっと並列で回せたかもしれません。

結果、2ページだった深掘り済みが、半日で51ページ全てになりました。グラフビューを開き直すと、線の太さが明らかに変わっています。スカスカだった関連リンクが、ページ間で密に張り巡らされている。

query レイヤーという3層目

ここからが本題です。深掘りが終わった全ページを眺めていて、ふと気になりました。「この51ページに散らばっている手法を、環境認識＋エントリーポイント＋コツの完結したセットとして何個取り出せるんだろう？」

これは1ページに収まる情報ではありません。ある手法のエントリー条件はインジケーターのページに、損切り基準は基礎理論のページに、コツはチャートパターンのページに——という具合に分散しています。51ページを横断して、初めて1つの「使える手法」が浮かび上がる。

Claude Code に、wiki 全体を読んで「完結した手法」を抽出するよう頼みました。返ってきたのは22個。スキャルピング系10、デイトレ系5、兼用5、秒スキャ2。それぞれに環境認識・エントリー・損切り・コツ・出典ページが揃っています。

これを1つの新しいページとして wiki に保存しました。ただ、ふと思ったんです。これは概念でも手法でもインジケーターでもパターンでもない。wiki を横断して合成された成果物だ。

Karpathy の元のアイデア（gist）では、構造は raw / wiki / schema(CLAUDE.md) の3つで、「query」という層は明示されていません。でも、横断クエリの結果を wiki に書き戻して保存できるようにしたとき、これは明らかに raw でも wiki ページでもない第3のレイヤーだと感じました。Karpathy の枠組みに、自分なりの query 層を1段足したくなった、という方が正確です。

PoC の結論をアップデートする

最初の結論では「LLM Wiki は段階的に深くしていくもの」と書きました。これは間違いではありませんが、不完全でした。実際にやってみた感覚としては、こうです。

LLM Wiki は3段階で育つ（※3段階目は私の運用上の拡張）:

  1. 浅い wiki — raw を読んで構造だけ作る。グラフビューで階層が見える
  2. 深い wiki — 各ページに講師固有の知見が入る。1ページ単位で「使える」資料になる
  3. query レイヤー — wiki を横断して、目的別の合成を生成し、その成果物を wiki に書き戻す。複数ページに分散した情報が、1つの実践的な答えに結晶する

3段階目に到達して初めて、「ノートの集積」が「使える知識」になった実感がありました。1段階目は地図、2段階目は事典、3段階目はガイドブック——そんなイメージです。

ベクターDB を使う従来の RAG では、3段階目を直接やろうとします。でも検索結果の上位k件を AI に渡しても、こういう「複数ページにまたがる暗黙の構造」は拾えません。LLM Wiki が wiki という中間層を持つことの意味は、まさにこの3段階目を可能にすることなんだと、やってみて腑に落ちました。

まず1つのフォルダから

LLM Wiki を始めるのに、特別な準備はいりません。

必要なのは Obsidian のフォルダと Claude Code だけ。ベクターデータベースのセットアップも、サーバーの構築も、プログラミングの知識もいりません。

あなたの Obsidian に、すでにノートが20本以上たまっているフォルダはありませんか？ レシピでも、読書メモでも、仕事の議事録でも。そのフォルダの隣に wiki/ を作って、Claude Code に「このノートから概念を抽出して wiki ページを作って」と言うだけです。

5分後には、あなたのノートの間に、今まで見えていなかったつながりが浮かび上がっているかもしれません。

前回の記事: 【第7回】「あの動画どこだっけ」から始まった——Obsidian で知識が育つまで