NISHIO Hirokazu[Translate]
KarpathyのLLM Wiki勉強会
KarpathyのLLM Wikiについて話す
今回GPT5アイコンのついているツリーはChatGPT 5.5 Pro、KarpathyのLLM WikiがついているアイコンはKarpathyのLLM Wikiが生成しています
KarpathyのLLM Wiki」は、何らかアイコンがないと出力したAIを明示しにくいので適当に生成させたもの

gpt5Karpathy = Andrej Karpathy(アンドレイ・カルパシー)。現代AI界隈ではかなり影響力のある研究者・教育者です。
2015年のOpenAI立ち上げ時のメンバー。
2017年にTeslaへ移り、Autopilotのコンピュータビジョン系AIを率いました。
Stanfordの有名講義 CS231n: Convolutional Neural Networks for Visual Recognition の中心人物でもあり、YouTubeやGitHubでもニューラルネット、LLM、nanoGPTなどをかなりわかりやすく教える人として知られています。
2024年にEureka Labsを創業: 現在はAI教育プラットフォーム Eureka Labs を作っていて、LLM101nなどの教育コンテンツを展開しています。
vibe coding」という言葉を広めた人でもある
LLM Wiki文脈でのKarpathyは、ざっくり言うと 「チャットを一過性の会話で終わらせず、LLMが読み書きできるMarkdown Wikiとして知識を蓄積する」方向を提案・実践している人 です。
2026-04-05にフォローアップの投稿ブートストラップのGistが共有された、このGistが"LLM Wiki"というタイトルなのでこの名前で呼んでいる
理論の新しさよりも、実装負荷の低さ
気をつけないと、どんどんと色々な要素を付け加えてゴテゴテしたシステムになってしまう
多くのニーズに対してそんな複雑なシステムは必要なくGist1枚でOKであることを示した
RAGと言う言葉がバズり出した2023年前半には確かにコンテキスト長が4Kしかなかった(GPT-3.5)ので「色々工夫してなんとか実現するしかない状況」だった。2026年現在は256倍の1Mになってる(Claude Opus 4.7)
以前概念マップ勉強会で話したGraphRAGの頂点やエッジがとてもリッチになったものとも解釈できる(=Markdownのページとページ間のリンクになった)
GraphRAGに関しては「三つ組」のレベルまで簡素化することが性能を落とすという議論もあり、「グラフ」ってとこまで抽象化しないでリッチな文脈を保ってた方がいいんじゃないのという方向性があった
これを面白いと思っていろいろ試してみている
2026-05-07時点で20個以上作ってるのでいろいろ比較して語れそう
(内容を語れないものも多い / ちょっと試してみただけであまり発展していないものもある)

Wikiについて
「Wiki」という言葉荷物イメージが人によって割と異なっていると思う
A: 他人が作ったものを読むイメージ
このイメージの人が一番多いと思う、具体例はWikipedia
コンテンツ文中の単語から他のページへのリンクがある情報表現形態
B: チームでの情報共有のために書く場所のイメージ
これはAと違って「自分が書くこと」がイメージに含まれている
だがその書き方はチーム/組織のカルチャーによってまちまち
B-1: Aのスタイルの「リンクの豊富なドキュメントによる知識のネットワーク」を共同生産してるケース
B-2: 「単なる共有のドキュメント置き場」になってるケース
暗黙の前提として「他のチームメンバーに共有するため」という目的が仮定されがち
C: 個人での情報整理のために作るもののイメージ
「他人に共有するため」ではない
C-1: 非公開で他人に見せないケース
C-2: 「読んでもよいが、読む必要はない」というノリで公開されているケース
このCosense「西尾泰和の外部脳」は基本はC-2のスタンスで公開されている場で、たまに今回のように「他人に共有するため」の講義資料を置いている(B)
今回の文脈「KarpathyのLLM Wiki」では、メインフォーカスは「C-1: 非公開で他人に見せない」だ
データのフォーマットが「コンテンツ文中の単語から他のページへのリンクがある情報表現形態」なのでWikiと呼ばれているが、個人的には投稿1の"LLM Knowledge Base"の方が適切な表現で、さらに言えばほとんどの場合で"Personal LLM Knowledge Base"だと思う
Personalなので当然「実物をありのままに」他人に共有することが困難で、公開しやすいものだけ公開され、公開されたものだけを見る人は公開によるバイアスが乗ったものしか観測できない
だからみんな自分で色々なデータで試してみるべきだと思う

作ってみよう
個人的なデータが入ってるものは見せられないし、作るプロセスを紹介した方がいいので新しく作る
テーマは適当に決める、ちょうどgpt-realtime-2が周囲で話題になってたのでこれにしてみよう
適当にフォルダを作って、llm-wiki.md を置く。ついでにrawフォルダも作っておく
なにかrawに入れよう
個人的なWikiなら個人的なデータを入れたりする
今回はそれだとデモできないのでGPT 5.5 Proに解説させてみる
Markdownでコピーしてrawに置く
Claude Codeに整理してという
この提案も面白いけど、まずは一旦Wiki整備に集中することにする
今回の目的だと「サーベイ」なので僕の手元にあるデータは少なくネット上にあるデータが多いからWebSearchはやってもらった方がいいね
プロトタイプ案も作ってくれるんだ、親切〜
しばらく待つ
CLAUDE.md
データ追加の例
GPT Proで追加でサーベイした想定
またrawにおいてingestを指示する
KarpathyのLLM Wiki取り込みで見えた論点
thinker-responder が「速い音声 + 深い思考」の事実上のベスト構成として複数事例で示唆されており、wiki の concept として独立ページに昇格させた
評価軸が「自然さ」より通話成功率・割り込み回復率・タスク完了率にシフトしている(Genspark / Bluejay / Zillow)
Sokuji の整理は wiki の comparisons ページに足りていなかった「実装視点」を補ってくれる
thinker-responder
質問回答できる
新しいアイデアを思いついた想定
「スマートスピーカーのようなウェイクワード呼びかけでセッションが始まって音声でやりとりできるプロトタイプを作りたかったらどうしたらいいかな?」
詳しいことを聞いてくる
設計メモのページができた
見てみる
なるほど〜
同一内容をGPT Proに投げたもの
こちらはClaude Codeが途中で挟んできたような「今回は実装したいのか設計ドキュメントを作りたいのか」という質問が挟まらずに大体同程度の時間(7分)走って、疑似コードや設定ファイルが出力されている
これもingestしておけばいい
すぐにでもプロトタイプ作成に着手できそうだけど、今日は他にすることがあるから一旦ここで保留
保留している間に関連した記事を見かけたりしたらingestしたらいいし、質問やアイデアが生まれたらClaude Codeに話しかければいい
こういうイメージ
1: まずスタートがある(今回は「gpt-realtime-2」ってのが出たらしいな)
2: AIにサーベイさせたり考察させたりして「探索」が行われ、マップが広がっていく
どういうことが可能なのか、どういう部品が必要なのか、の地図ができる
たとえば、部品「ローカルでのウェイクワードエンジン」を実現するには2つ選択肢があり、それぞれどういうメリットがあるか
3: いつかのタイミングでもっと具体的なゴール「こういうものが作りたい」が生まれてから
4: 今までの探索範囲の中からそれに関係するものを集めて形にする

KarpathyのLLM Wikiの3つのアクションの定義
Ingest
>Ingest. You drop a new source into the raw collection and tell the LLM to process it. An example flow: the LLM reads the source, discusses key takeaways with you, writes a summary page in the wiki, updates the index, updates relevant entity and concept pages across the wiki, and appends an entry to the log. A single source might touch 10-15 wiki pages. Personally I prefer to ingest sources one at a time and stay involved — I read the summaries, check the updates, and guide the LLM on what to emphasize. But you could also batch-ingest many sources at once with less supervision. It's up to you to develop the workflow that fits your style and document it in the schema for future sessions.
>取り込み。新しいソースを「raw collection」に追加し、LLMに処理を指示します。処理の流れの一例:LLMがソースを読み込み、重要なポイントをユーザーと議論し、Wikiに要約ページを作成し、インデックスを更新し、Wiki内の関連するエンティティや概念のページを更新し、ログにエントリを追加します。1つのソースで、10~15のWikiページに影響を与えることもあります。 個人的には、ソースを1つずつ取り込み、その過程に関与し続けることを好みます。つまり、要約を読み、更新内容を確認し、LLMに対して何を強調すべきかを指示するのです。しかし、監督を最小限に抑えて、多くのソースを一度にバッチ処理することも可能です。自分のスタイルに合ったワークフローを構築し、将来のセッションのためにスキーマに文書化するのは、あなた次第です。
KarpathyのLLM Wiki1ソースが10〜15ページに触れる という量的記述が重要。単発の要約ではなく既存ネットワークへの編み込み作業であることを示唆している。
1. raw/の新ファイルを読む
2. 既存wikiページと照合
3. 関連ページを更新 or 新規作成
4. index.mdを更新
5. log.mdに記録
nishio僕はオリジナルのものに加えてこう追記してある
>If given file is like a.txt rename properly.
Query
>Query. You ask questions against the wiki. The LLM searches for relevant pages, reads them, and synthesizes an answer with citations. Answers can take different forms depending on the question — a markdown page, a comparison table, a slide deck (Marp), a chart (matplotlib), a canvas. The important insight: good answers can be filed back into the wiki as new pages. A comparison you asked for, an analysis, a connection you discovered — these are valuable and shouldn't disappear into chat history. This way your explorations compound in the knowledge base just like ingested sources do.
>クエリ。ウィキに対して質問を投げかけます。LLMは関連するページを検索し、それらを読み込み、出典を明記した回答を生成します。回答は質問の内容に応じて、マークダウンページ、比較表、スライド資料(Marp)、グラフ(matplotlib)、キャンバスなど、さまざまな形式で出力されます。重要な点は、優れた回答は新しいページとしてウィキに保存できるということです。 あなたが求めた比較、分析、発見した関連性——これらは貴重なものであり、チャットの履歴の中に埋もれてしまうべきではありません。このようにして、取り込まれた情報源と同様に、あなたの探求の成果もナレッジベースに蓄積されていきます。
KarpathyのLLM WikiKarpathyの記述では Query の中に filing back が埋め込まれている。回答が「チャット履歴に埋もれて消える」のを防ぐ仕掛け。
回答が次の回答の文脈になる → 複利効果の中核
同じ質問を繰り返さなくて済む
探索 = wiki強化 という正のフィードバックループ
nishio
質問をして、出てきた回答を見て人間が「それをfill backしといて」というケースだけでなく
「これはfill backしときましょうか?」とAIの側が言ってくるケース
ひと段落ついた時に僕が「このログにfill backすべき知見はある?」と聞くケース
特に実装的なやり取りをした後にやる
「3つあります、1は新規ページの追加で〜、2と3は既存ページの更新です」みたいなことをAIが言う
nishio
これは人間のアナロジーだと質問は言語化を促す
目的が明確になってからその目的達成のための生成をしているとも言える
>Lint. Periodically, ask the LLM to health-check the wiki. Look for: contradictions between pages, stale claims that newer sources have superseded, orphan pages with no inbound links, important concepts mentioned but lacking their own page, missing cross-references, data gaps that could be filled with a web search. The LLM is good at suggesting new questions to investigate and new sources to look for. This keeps the wiki healthy as it grows.
>Lint: :定期的にLLMにウィキの健全性チェックを依頼しましょう。具体的には、ページ間の矛盾、新しい情報源によって古くなった主張、外部リンクのない孤立ページ、言及されているにもかかわらず専用ページがない重要な概念、欠落している相互参照、ウェブ検索で補えるデータの欠落などを確認します。LLMは、調査すべき新たな質問や探すべき新しい情報源を提案するのが得意です。これにより、ウィキが成長するにつれて健全な状態を維持することができます。
KarpathyのLLM Wiki
機械的検出=孤立ページ、壊れたリンク、未登録
意味的検出=矛盾、stale claim、概念不足の判断、新質問の提案
>The LLM is good at suggesting new questions to investigate and new sources to look for.
→ Lintは単なる健全性チェックではなく、wikiの成長方向の提案 までやる。
nishioAIが自動的に呼び出してることもある
Wiki横断で「しばらくLintをやってないものを発見する仕組み」を作って、寝る前に実行するつもりだったが、予想よりも自動的に整えられていることが多い

体験談
家計Wiki: 「必要な情報」が後から分かる
猫Wiki: 高速膨大な情報インプットから心を守る
LLM Wiki自体のLLM Wiki: 研究目的のWikiとプロジェクト目的のWikiの区別
dd2030-wikiでの具体例

家計Wiki
LLM Wiki以前から確定申告を手伝わせるつもりでClaude Codeに色々な詳細データを与えていた
確定申告とは違うけど友達がGPTの指示の通りに株取引したら自分より儲けるって言ってて興味を持ったので自分の資産を分析させたかった
これをLLM Wiki化した。初期の3〜4個のうちの一つ
必要な情報が後からわかる
「他に必要なデータある?」とLLM Wikiに聞くことで何が必要なデータかわかる
人間は事前に「適切な判断に必要なコンテキスト情報」を特定して全部渡すことが難しい
具体例「家族構成は?年齢は?」
確かにそれを把握しないで将来の計画ができるわけがないね
具体例「保険金の支払いがあるが、この保険契約の内容は?」
即答できない
保険証書を出してきて概要を読ませたら解約返戻金テーブルも見せてと言われた、解約した方が良い可能性を検討されてる!
具体例「年金ねっとの情報を見て」
言われるまで思いつかなかったが「株式と債券のバランス」という文脈において年金は強い債券的性質を持っている
年金額が利息になるような債券とみなせる

猫Wiki
高速膨大な情報インプットから心を守る
緊急入院して毎日血液検査をしてる猫の情報を整理
多い時には1日2〜3枚の血液検査結果のデータと、医師の話、GPT Proによる各種の概念の解説
まず初日に検査データをGPT Proに与えて解説させたが、未知概念が急激に増えるので人力での整理の速度が追いつかない
追いつかないまま翌日にはまた新しい検査結果がくる
状況を理解できないのは強いストレス
4/30
>毎日20個も数字が書かれた検査データの紙をもらう上に今日は元々の病院の1枚に加えて大学病院でも2枚もらった(し多分明日以降2枚ずつ来る)
>先生の解説やデータの読み方は人間(僕)が手動で整理してたんだけど、妻が状況を把握して安心したり、先生の話を聞いて理解しやすいようにまとめることまで射程に入れるともうキャパオーバーなので、ここでLLM Wikiを使えばいいのではないかという気持ちになっている
このとき緊急入院から4日目
14個目のLLM Wikiを作った
KarpathyのLLM Wikiによるタイムラインまとめからのnishioの要約
2026-04-27(月) 朝9時 — かかりつけ病院
朝にかけてたくさん嘔吐
来院 → 輸液を投与
2026-04-27(月) 17時 — 容態悪化、紹介
嘔吐が止まらない(1時間に1回ペース) / よだれが止まらない
別の病院に移送
低カリウム血症、急性腎不全の可能性
2026-04-28(火) 血液検査(2回目)— 「何らかの炎症」の判断
急性腎不全というほどではないがなんらか他の臓器に炎症がありそう
2026-04-28(火) 画像検査— 膵炎判明
膵臓の腫れ → 急性膵炎
2026-04-29(水) 13時
抗炎症薬が膵炎に効かない
別途ビリルビン値が上昇、肝臓・胆管の問題の可能性
16時なら大学病院が受け入れ可能とのこと
2026-04-29(水) 大学病院 — 入院後のエコー所見
心肥大が見られる
腹腔内の脂肪の炎症(膵周囲脂肪の炎症と推定)— 中等症以上の膵炎で見られる所見
胸水(胸腔内に液体貯留)
~2026-05-02
腎臓は安定
fPL上限越え: 膵炎を強く支持
改善: SAA 136.9 → 68.7、WBC 217 → 209.9 → 全身炎症は下がってきている
悪化(肝胆道系): 総ビリルビン 2.5 → 5.3、ALP 157 → 334(いずれも大きく悪化)
血糖と貧血がで始める
医師所見
肝臓に肥満細胞腫(MCT)がありそう
胆管が太くなっている
ステロイドの点滴で肥満細胞腫と炎症を抑える
~2026-05-04
「全身炎症・腎臓・電解質はかなり改善してきたが、胆汁うっ滞/黄疸だけがまだ進んでいる」という結果
治療が効いている部分(SAA・K・腎数値・血糖・Alb・Hct・嘔吐)と、まだ効いていない/遅れて悪化している部分(T-Bil・ALP・fPL高値)が分かれる
2026-05-05
大幅改善(肝胆道系) :
総ビリルビン 7.6 → 1.5(劇的に低下) — 黄疸の山を越え始めた
ALP 450 → 148(同じく大幅低下)→ 完全な胆管閉塞が進行し続けるシナリオは大きく弱まった
貧血は進行している
自力での摂食がみられる
~2026-05-07
fPL(膵炎の指標)が計測範囲内に戻り始める
2026-05-10
退院
感想
序盤(急性腎不全~急性膵炎)がやばい
猫が明日にも死ぬかもしれない状況で、何が起きてるのかを理解するために未知の用語が数十個出現する
時間と精神の余裕があるならGPT Proに聞けば説明はしてくれるが、情報量の多さを精神が受け止めきれない
4日の血液検査の結果を1日分ずつGPT Proが解説した、これを個別に人間が読むのではなくLLM Wikiが読んで「どのようなことが起きているか、それを示しているのはこの値で、時系列ではこう変化している」のように再構成して示してくれる。人間にとっての飲み込みやすさが違う。
(さすがに気を回す余裕がなくてgit管理してなかったので初期に自分が見ていたものを復元できないが)
長期的視点
ChatGPT 5.5 Proのコンテキスト長さがいくら長くても、初期に書いた情報を覚え続けてくれるか信用できない
Claude Codeみたいにコンテキストが埋まって自動でcompactionがかかって、昔のことはぼんやりとしか覚えてない状態になるのではという不安感がある
それに対してこちらはrawファイルは一切いじられることなく手元のファイルシステムにあるので「何も消えない」という安心感がある
GitHubにpushするなりDropboxの中に置くなり任意のバックアップ方法でバックアップすればいい
特に異なる日にちょっとずつ足していったデータが時系列で整理されてるのが振り返るのにとても良い
fPLとは何をはかってるのか、どういう病気を見るためのものなのか、どう値が変化したかetc.

dd2030-wikiでの具体例
出来事
昨年11月ごろに「新規参加者向けの解説ページが必要では」という話題になる
2025-11-22— NISHIO さんが Slack#コミュニティ運営で「GPT-5.1 に新規参加者向け解説を作らせた」と投稿
その後Aさんがこの内容をWebページに追加するPRを作成、Bさんがマージ
2025-12-02— C さんが deno lume への大規模リニューアルでパス修正
2026年5月に「このページってなんだっけ?」「最新の情報に追従してない」と話題になった
僕もBさんもCさんも「なんだっけ?」となった
SlackログとGitHubの両方を読めるLLM Wikiに質問したら上記のような経緯ですよと教えてくれた
考察
こういう「目立った名前のついているプロジェクト」の隙間のタスクが複数人の手によってちょっとずつ進んだようなケースでは、議事録に全体像が残らないので半年後に由来がわからなくなりがち
これは「すべてのデータをインデクシングする必要はない、AI Agentにrawデータを検索する手段があればいい」の実例
僕はGitHubを軽く調査して「12/1ぐらいにCさんがやったと思う」と思ったのだが結果的にそれは間違いだった
nishioQ: これをどうやって突き止めたのかのプロセスの解説が欲しい
KarpathyのLLM Wiki
2つのソースがある:
/tmp/oss_weekly_reporter/data/ — Slack/GitHubの週次アーカイブ(要約あり)
GitHubリポジトリ本体 — コミット履歴の真実
まずアーカイブ側で議論の文脈を、後でリポジトリ側でコミット事実を確認する2段構えにした。
議論の発生時期を絞る
「12/1ぐらい」を信じすぎず、前後(11月後半〜12月前半)の週をまとめてgrep
→ ヒットしたのは 11月19-26週。これで「12/1」の記憶は1〜2週ずれていることが判明。
ヒットしたファイル github_report-website.md を文脈付きで読むと、 Issue #180 が見つかった:
起票者: Bさん(Cさんではない)
起票日: 2025-11-22
内容: 「NISHIOさんがGPT-5.1で生成した文章をそのままサイトに載せるのはどうか」
この時点で「CさんがAI生成した」という仮説は崩れた。
コミット履歴で裏取り
議論だけでは「実際に誰がページを作ったか」は不明。リポジトリをcloneして git log:
→初出はBさん、Cさんは後の構造リニューアル時の運搬役と確定
内容の同一性確認
初出コミットの中身が「NISHIOさんがGPT-5.1で生成した文章」と一致するかを git show d686234 -- markdown/newcomer.md で目視確認


LLM Wiki自体のLLM Wiki
LLW Wikiを知ったとき、まずGrokでKarpathyの投稿に対する反応をかき集めてLLMにingestさせた
だいぶ大きくなってきた中で、別のWikiに「株分け」したくなった
研究(サーベイ)目的のWikiとプロジェクト目的のWikiの区別
体系化された知識ネットワーク自体が目的であるケース
整合性のある大きなネットワークが目的
ChatGPT Proなどでのサーベイからのingestが多い
人間が哲学的な質問をしてAIが回答してfill back
なんらかの目的(ソフトウェア開発etc)があるケース
知識ネットワークの拡大が主目的ではなく、例えば実装などが目的
その過程で経験したトラブルや試行錯誤などの知識を保存したい
作業から得られた具体的知識をfill back
前者はどんどん抽象的になっていく
抽象的な知識の方が広い範囲に応用しやすい(=違う知識と結合しやすい)のでWikiの中心的ページになっていく
後者は具体のレイヤーに接続する必要がある
サーベイのWikiから具体的なプロジェクトを明示して「関連しそうなページをコピーして」と言えばOK
相互にお互いのWikiのことを知っているのでfill backする時に「あっちに書こうか?」という問いかけが発生する

20件の観察から
KarpathyのLLM Wiki実験を通じて nishio のメンタルモデルが更新された箇所
気づき1:
事前は「LLM Wiki は継続的に育てるもの」というイメージがあったが、実測すると 対象が固定/有限なwikiは1日で立ち上げて凍結するのが自然 だった。これらは「途中で飽きた」のではなく「対象が有限で網羅完了した」もの
気づき2: 個人系の wiki は予想以上に育つ
個人系の wiki はいずれも raw データが小さいのに wiki が膨らんだ。個人データそのものは少量でも、一般知識との接続点が多数生まれる(個人的データを土台にして一般的な専門知識が再構築・再配置される の実証)。
これは「LLM Wikiが最も価値を出すのは個人系」という仮説を強く裏付けた。
事前は「組織系・書籍系の方が大規模なデータを扱えるので有利」と思っていたが、逆転した。
気づき3:
2026-04-20 に4件、2026-05-02 に3件の量産日がある。当初は「外部刺激(記事・投稿・締切)が偶然集中した」と思っていたが、ingest対象を見ると 対象がバラバラ(書籍/組織/思想/設計)。つまり外部要因ではなく 自分側のメンタルエネルギーや「思いつきの収束」が同期している。これは「LLM Wikiを作るコスト」が十分下がったため、思考がある臨界を超えると複数を同時に立ち上げる行動が出る、という仮説を生む。
気づき4: kabuwake は「育った結果」、計画的分割ではない
annotation-wiki への kabuwakeは、事前計画で分けたのではなく 本wikiが膨らんで「実装フェーズの議論が研究wikiを汚染し始めた」結果として 発生した。
これは事前は「最初から実装wikiを別に作る」発想で対応しようとしていたが、実際は 「育ってから分ける」方が、何を分けるべきかが明確になる(ishoku のYAGNI性と同型)。
気づき5: wiki森は「自然に役割分担する」
事前は「23個もあると管理コストが膨大」という直感があったが、実測すると 同時にactiveなのは6件のみ、残りは休んでいる。人間の注意配分は wiki数ではなく active数で決まる。「wiki森は自然に注意配分を圧縮する」という運用知見。






"Engineer's way of creating knowledge" the English version of my book is now available on [Engineer's way of creating knowledge]

(C)NISHIO Hirokazu / Converted from [Scrapbox] at [Edit]