8月19日、Casey Newtonが「An LLM wiki changed how I work」と題した記事を公開した。LLMを使って構築した個人知識ベース（wiki）が「今年試したデスクワーク効率化の中で、断然最も役立つ取り組みだった」と言い切る内容で、具体的なセットアップから運用上の限界まで包み隠さず書かれている。Andrej Karpathyが発端となったこのアイデアがどう実際の仕事を変えたか、詳しく見ていく。

KarpathyのLLM wikiとは何か

今年4月、AI研究者のAndrej Karpathyがポストした一つのアイデアが、生産性オタクたちの間で話題を集めた（※元記事が参照するXポストのURLは x.com/karpathy/status/2039805659525644595 だが、投稿IDが通常の番号帯と異なるため、リンク先が正常に表示されない場合がある。元記事本文でKarpathyの投稿として紹介されているものをそのまま参照している）。「LLMを使って、調査テーマごとの個人知識ベースを構築している」というものだ。具体的には、ソース文書をローカルフォルダに追加し、LLMにその内容を抽出・整理させてMarkdownのwikiとして保存、新しい資料を追加するたびに更新していく。

Karpathyは「vibe coding」という言葉の生みの親でもある人物だ。vibe codingとは、細かい実装の詳細を気にせず「雰囲気」や意図をLLMに伝えながらコードを書き進めるアプローチを指す造語で、2025年初頭から開発者コミュニティ全体に広まった。そのKarpathyの発言だけに影響力は大きく、数時間のうちにGitHubリポジトリ、YouTube動画、Substack記事が溢れ、LLM wiki構築のHowToがネット上に大量生産された。

Newtonはこのアイデアを「infohazard」と形容している。「infohazard」はもともと「知ることで害が生じうる情報」を指すセキュリティ・倫理分野の概念だが、ここでNewtonが使うのはその転用であり、「知ってしまった以上、実行せずにはいられなくなる危険な情報」という意味での自己注釈だ（編集部補足：原文でNewton自身がこの意味で使っている）。知ってしまった以上、数週間を費やして構築することになったが、結果として冒頭の評価に至った。

実際のセットアップと運用

Newtonの構成はシンプルだ。ターミナルにGhosttyを使い、Claudeに「Karpathy式LLM wikiを作るプロンプトを書いて」と依頼。生成されたスクリプトを貼り付け、Obsidian上にMarkdownファイル群として展開した。

※元記事では利用したClaudeのモデルとして具体的なバージョン名が記載されているが、編集部では2026年8月時点でその正式名称を公式情報から確認できなかったため、ここでは「Claude」と表記する。同様に後述のOpenAIモデルについても同様の理由でモデル名の記載を控える。

まずPlatformerの全アーカイブ（2020年以降の記事）をwikiに投入。Claudeが登場人物・企業・概念を抽出してMarkdownファイルに整理した。Metaのページだけで1万2000語超、1300以上の内部リンクを持つという規模だ。

毎朝、ジャーナルを書いた後、Obsidianのウェブクリッパー（URLをMarkdownに変換する機能）で気になる記事をwikiに保存する。スクリプトがその記事を読み込み、既存ページへの追記や新規ページの生成を自動で行う。現在、1440以上のwikiページがローカルに存在し、ClaudianというObsidianプラグインを通じてwikiに直接質問できる。

どう役立つか：具体的なユースケース

記事の中で特に説得力があるのが、OpenAI / Hugging Faceのエージェント侵害事件を例にした説明だ。数週間にわたって断片的に情報が出てきた複雑なケースで、毎日「エージェントはどこから、どこへ逃げたのか」を整理してwikiページを確認することで、ポッドキャスト出演や記事執筆の準備時間を大幅に削減できたという。原文ソースへのリンクも保持されているため、ハルシネーション（LLMの事実誤認）のチェックも行いやすい。

また、wikiは旧来の「blips」システム（注：長期追跡テーマを手動でまとめるメモ）を自動化した形にもなっている。毎日読んだ記事から「tokenmaxxing」「youth social media bans」「AI copyright」といった新概念のページが自動生成され、「ホーム」ページには今週の注目トピックがまとめられる。これを見て「AI and Congress」というトピックに気づき、ポッドキャストのネタとして提案した、という実例も紹介されている。

メンテナンスコストと限界

良いことばかりではない。Newtonは正直にデメリットも書いている。

• ページが長くなりすぎると手動でコンパクト化が必要
• コードのエラーでスクリプトが止まることがある
• LLMが生成するテキストが「超圧縮された、ほぼ読めないスタイル」になりがち（この指摘やこれはX上でも共感を集めている）

スタイルの問題については、別のLLMにAP通信スタイルへの書き直しを依頼して対処したという（※こちらも利用モデル名は元記事記載のものを確認できなかったため省略する）。

「自分に特化しすぎていて、万人に自信を持って勧めるには無理がある」と述べつつも、「自己組織化する知識ベースは、2008年にEvernoteを初めてインストールした日から始まったプロセスの、ある種の到達点だ」とも書いている。

継続して使っているツール

wikiの話が中心だが、記事では周辺ツールにも触れている。いずれもwikiを補完する形で使われており、情報の収集・蓄積・検索というワークフローの異なる層を担っている。

• Raycast: SpotlightをReplaceするランチャー。Window管理、クリップボード履歴、AI検索などを集約。Windowsにも対応した
• Capacities: デイリージャーナルとリンク管理に使用。タグで過去の記事を即座に検索できる。wikiに取り込む前の「一次受け皿」的な役割を果たす
• Recall: Chrome拡張でYouTube動画のテキスト要約を生成。「聴くべき」ポッドキャストを素早くスキャンするために活用し、要約をwikiへ流し込む起点にもなる

逆に、Notionのエージェント検索は「動くけど習慣にならなかった」として使用をやめた。検索UIが分散しており、ソース引用も不十分だったと理由を挙げている。

詳細はAn LLM wiki changed how I workを参照していただきたい。