10 万人が @karpathy の 投稿 をブックマーク:
その後、彼は完全な GitHub Gist を公開しました。星 5,000 以上。フォーク 1,400 以上。たった 2 日で。
ほとんどの人はそれもブックマークするでしょう。そして、何もしません。
難しいからではありません。誰も正確なプロンプトを教えてくれなかったからです。
それを解決します。
システム全体をステップごとに説明し、各ステップでコピペ可能なプロンプトを提供し、どこで機能しなくなるかをお伝えします。週末を無駄にして、スケールすると崩れるものを作らないようにするためです。
「人間の仕事は、情報源を厳選し、分析を指示し、良い質問をし、それが何を意味するかを考えることです。LLM の仕事はそれ以外のすべてです。」 — Andrej Karpathy
コンセプト (60 秒バージョン)
知識があちこちに散らばっていませんか？ 4 つのアプリに保存された記事。2023 年のブックマークで、二度と見返さないもの。存在を忘れていたフォルダにある会議のメモ。
現状、AI に自分の情報について質問すると、毎回ゼロから始まります。ドキュメントをアップロードし、質問し、回答を得る。次のセッション？ すべて忘れています。それが ChatGPT のファイルアップロード、NotebookLM、そしてほとんどの RAG システムの動作です。蓄積はゼロ。
Karpathy のアイデアはこれを逆転させます。
AI が毎回生のファイルを検索する代わりに、AI が情報源を一度読んで構造化された Wiki を編纂します。要約、相互参照、アイデア間の関連性、矛盾点の指摘。
すべて AI が維持。すべてシンプルな Markdown ファイルで。
次に質問するとき、AI は生のドキュメントを掘り返しません。すでに構築した Wiki を読みます。
関連性はすでにそこにあります。
統合はすでに読んだすべてを反映しています。
新しい情報源を追加するたびに、Wiki はより豊かになります。質問するたびに、Wiki にフィードバックできます。知識はリセットされるのではなく、複合的に成長します。
彼の成果：ある研究トピックについて約 100 記事、約 40 万語。彼は一言も書いていません。AI がすべてを書き、リンクし、分類し、維持しました。
データベースなし。埋め込みなし。ベクターストアなし。フォルダとテキストファイルのみ。
なぜ気にする必要があるのか？
今すぐ重要な 3 つのユースケース：
クリエイターやマーケッターなら、これはコンテンツリサーチエンジンです。競合分析、トレンド記事、オーディエンスインサイトを raw/ に放り込みます。Wiki は、手動では決して見つけられないパターンや角度を浮かび上がらせます。
ファウンダーやコンサルタントなら、これはクライアントワーク、市場調査、競合分析のためのセカンドブレインです。生成したすべてのレポートがシステムにフィードバックされます。3 ヶ月もすれば、あなたの AI はほとんどの新入社員よりもあなたのドメインに詳しくなります。
学生や研究者なら、これは Karpathy が実際に構築したものです。多数の論文にわたる深いリサーチを、AI がアイデアの関連性、著者間の意見の相違、残されたギャップを追跡します。
*これは多くのビジネス R&D ワークフローにも使用できます。
構築前に必要なもの
→ ローカルファイルを読み取る AI コーディングツール (Claude Code、Cursor、Codex、または類似のもの)
→ テキストエディター (Obsidian 推奨、VS Code、Notepad など何でも可)
→ 関心のあるトピックに関する 10 以上のソースドキュメント
→ 初期設定に 30 分、その後ソースごとに 10 分
以上です。特別なソフトウェアは不要。アカウント作成不要。プラグインのインストール不要。
この記事の残りは構築手順です。7 つのステップ。各ステップには、AI に貼り付ける正確なプロンプトがあります。順番に従ってください。
ステップ 1: フォルダ構造を作成する (2 分)
マシン上のどこかにこれを作成します：
1my-knowledge-base/2├── raw/ # ソースマテリアル。AI は読み取り専用で、変更しません。3│ └── assets/ # 画像、スクリーンショット、図4├── wiki/ # AI が管理する Wiki。あなたは読みます。AI が書きます。5├── outputs/ # クエリからのレポート、分析、回答6└── CLAUDE.md # この全体を機能させるスキーマファイル
3 つのフォルダ、1 つのファイル。ここで 2 分以上かけているなら、考えすぎです。
ステップ 2: スキーマファイルを書く (みんながスキップするステップ。スキップしないで)
スキーマは、汎用チャットボットと規律ある Wiki 管理者の違いを生みます。
AI に、ナレッジベースが何に関するものか、どのように整理するか、ソースを追加したり、質問したり、メンテナンスを実行したりするときに何をすべきかを指示します。
他のガイドは 10 行のテンプレートを提供します。こちらが、Karpathy の Gist に基づき、実際の使用向けに設計された完全なプロダクションスキーマです：
1# ナレッジベーススキーマ23## アイデンティティ4これは [あなたのトピック] に関する個人ナレッジベースです。5LLM エージェントによって維持されます。人間は情報源を厳選し、質問をします。LLM はそれ以外のすべてを行います。67## アーキテクチャ8- raw/ は不変のソースドキュメントを含みます。raw/ 内のファイルを決して変更しないでください。9- wiki/ はコンパイルされた Wiki を含みます。LLM がこのディレクトリを完全に所有します。10- outputs/ は生成されたレポート、分析、クエリ回答を含みます。1112## Wiki 規則13- 各トピックは wiki/ 内に独自の .md ファイルを取得します14- すべての Wiki ファイルは YAML フロントマターで始まります：15 ---16 title: [トピック名]17 created: [日付]18 last_updated: [日付]19 source_count: [このページの情報源となった raw ソースの数]20 status: [draft | reviewed | needs_update]21 ---22- フロントマターの後、1 段落の要約23- Wiki ページ間の内部リンクには [[topic-name]] を使用24- すべての事実主張はその情報源を引用：[Source: filename.md]25- 新しい情報が既存のコンテンツと矛盾する場合は、明示的にフラグを立てる：26 > CONTRADICTION: [古い主張] vs [新しい主張] from [ソース]2728## インデックスとログ29- wiki/index.md にはすべてのページがカテゴリ別に 1 行説明付きでリストされます30- wiki/log.md は追記専用の時系列記録です31- ログエントリ形式：## [YYYY-MM-DD] action | 説明32 (アクション: ingest、query、lint、update)3334## 取り込みワークフロー35新しいソースを処理するとき：361. ソースドキュメント全体を読む372. ユーザーと主要なポイントについて議論する383. wiki/ にサマリーページを作成または更新する394. wiki/index.md を更新する405. Wiki 全体の関連するすべてのエンティティページとコンセプトページを更新する416. 既存のページから新しいコンテンツへのバックリンクを追加する427. 既存の Wiki コンテンツとの矛盾をフラグする438. wiki/log.md にエントリを追加する449. 1 つのソースが 10 ～ 15 の Wiki ページに影響を与える必要があります4546## クエリワークフロー47質問に答えるとき：481. まず wiki/index.md を読んで関連ページを見つける492. 関連するすべての Wiki ページを読む503. [Source: page-name] の引用付きで回答を統合する514. 回答が新しい洞察を明らかにした場合は、それを wiki/ にフィードバックするよう提案する525. 価値のある回答は outputs/ に保存する5354## Lint ワークフロー (毎月)55以下をチェック：56- ページ間の矛盾57- 新しいソースによって取って代わられた古い主張58- インバウンドリンクのない孤立ページ59- 言及されているが説明されていない概念60- 欠落している相互参照61- ソース属性のない主張62出力：wiki/lint-report-[date].md (重要度レベル付き)6364## 焦点分野65[このナレッジベースがカバーする 3 ～ 5 のトピックをリスト]
これをコピーします。焦点分野をカスタマイズします。プロジェクトルートに CLAUDE.md として配置します。
ステップ 3: Raw フォルダにデータを入れる (ダンプに 10 分、整理ゼロ)
raw/ を開いて、すべてを放り込みます：
→ 記事を .md または .txt ファイルにコピペ
→ 現在使用しているアプリからメモをエクスポート
→ スクリーンショットや図を raw/assets/ に保存
→ 研究論文、PDF、競合分析を貼り付ける
→ 何ヶ月もため込んでいたブックマークをダンプ
整理しないでください。名前を変更しないでください。クリーンアップしないでください。それは AI の仕事です。
Karpathy からのプロのヒント：Obsidian Web Clipper ブラウザ拡張機能を使用すると、任意の Web 記事をワンクリックで Markdown に変換できます。
ホットキー (設定 → ホットキー → 「添付ファイルをダウンロード」) を設定して、すべての画像をローカルに取得し、AI が参照できるようにします。
Obsidian を使用しない場合は、ブラウザからのコピペで問題ありません。
目標は量です。完璧さではありません。
ステップ 4: 最初の取り込みを実行する
AI エージェントを開きます。プロジェクトフォルダを指定します。これを貼り付けます：
取り込みプロンプト：
1"CLAUDE.md のスキーマを読んでください。次に、raw/ から [ファイル名] を処理してください。完全に読んで、私と主要なポイントについて議論し、その後：wiki/ にサマリーページを作成し、wiki/index.md を更新し、関連するすべてのコンセプトページとエンティティページを更新し、バックリンクを追加し、矛盾をフラグし、wiki/log.md に追加してください。"
一度に 1 つのソースから始めます。Karpathy も同じことをしています。要約を読みます。更新を確認します。何を強調すべきか AI をガイドします。これにより、すべてを一括処理するよりもはるかに優れた結果が得られます。
5 ～ 10 のソースの後、wiki/ フォルダには、インデックス、ログ、および 15 ～ 30 の相互接続されたページが含まれます。
その時点で、システムが機能し始めます。
ステップ 5: ナレッジベースにクエリを実行し始める
10 以上の Wiki ページがあれば、システムは真に有用になります。これを貼り付けます：
クエリプロンプト：
1"wiki/index.md を読んでください。ナレッジベースの内容に基づいて、[あなたの質問] に答えてください。回答の根拠となった Wiki ページを引用してください。これが保存する価値のある新しい関連性を明らかにした場合は、wiki/ に新しいページを作成し、インデックスを更新してください。"
最も価値を引き出す質問：
→ 「このナレッジベースの最大のギャップは 3 つ何ですか？」
→ 「どのソースが互いに矛盾していて、何についてですか？」
→ 「ここにあるものに基づいて、次に何を研究すべきですか？」
→ 「Wiki コンテンツのみを使用して、[トピック] に関する 500 ワードのブリーフィングを書いてください」
→ 「[概念 A] と [概念 B] の間にはどのような関連性がありますか？」
クリティカルなループ：良い回答は Wiki にフィードバックされるべきです。
比較、分析、あなたが発見した関連性。
これらは、取り込まれたソースと同様にナレッジベースで複合的に成長します。
すべての質問が次の回答をより良くします。
ステップ 6: 毎月のヘルスチェックを実行する
これは誰もやらないステップです。システム全体がゆっくりと腐敗するのを防ぐステップです。これを貼り付けます：
Lint プロンプト：
1"CLAUDE.md の lint ワークフローに従って、wiki/ の完全なヘルスチェックを実行してください。wiki/lint-report-[date].md に重要度レベル (🔴 エラー、🟡 警告、🔵 情報) を付けて出力してください。最大の知識ギャップを埋めるための 3 つの記事を提案してください。"
これが重要な理由：AI が何か少し間違ったことを書き、それを保存すると、次の回答は間違ったことに基づいて構築されます。
2 か月後には、5 つのページが同じエラーを強化しています。ヘルスチェックは、これが雪だるま式に大きくなる前に捕捉します。
月に 1 回のチェック。あなたの時間は 10 分。システムの信頼性を維持したいなら、交渉の余地はありません。
ステップ 7: 複合的に成長させる
ここでシステムが真価を発揮します。
4 ～ 6 週間一貫して使用すると、メモを検索しているだけではありません。
あなたよりも情報源間の関連性を理解している、構造化された知識システムにクエリを実行しています。
複合的な成長を加速する 3 つの方法：
探索出力をフィードバックする：AI が生成した比較や分析が価値があると感じたら、wiki/ または outputs/ に保存します。
Karpathy は、自身の探索とクエリはナレッジベースに「常に蓄積される」と述べています。
ビジュアル出力を追加する：AI に回答を Markdown テーブル、チャート、またはスライドデッキ (Marp 形式) としてレンダリングさせます。
これらは、使い捨てのチャットメッセージではなく、再利用可能なアセットになります。
すべてをバージョン管理する：Wiki は単なる Markdown ファイルです。
Git リポジトリを初期化します。完全な履歴、ブランチ、および AI が台無しにしたものを元に戻す機能を取得します。
はい。これが構築手順です。さて、ここからは誰も教えてくれない部分です。
このシステムが機能しなくなる点 (正直なバージョン)
これは完成された製品ではなく、初期段階のパターンです。Karpathy 自身もこれを「ハック的なスクリプト集」と呼び、「実際の製品の余地がある」と述べています。
知識を任せる前に知っておくべきことは次のとおりです：
コンテキストウィンドウの上限。
Karpathy の Wiki は約 100 記事、約 40 万語で動作します。しかし、128K トークンのコンテキストウィンドウでも約 96,000 語しか保持できません。AI はインデックスを通じて選択的に読み取るため、見逃す可能性があります。研究によると、LLM は「途中で迷子」効果に悩まされ、長い入力の中央にある情報が優先順位を下げられます。クエリ結果には盲点があります。これを受け入れてください。
エラーの複合化。
AI が微妙な間違いのある Wiki ページを書きます。それをクエリします。間違いが回答に入ります。その回答をフィードバックします。これで 2 つのページが同じエラーを強化します。毎月の Lint は役立ちますが、Lint を実行する AI は、エラーを作った AI と同じ盲点を持っています。これは最大のリスクです。Karpathy の Gist のあるコメンテーターは見事に指摘しました：「出力がフィードバックされると、エラーも複合的に成長する。」
幻覚はなくならない。
Wiki アプローチは、AI が回答を情報源に基づかせるため、幻覚を減らします。しかし、なくしはしません。AI は情報源に存在しない関連性を統合することもあります。そして、Wiki は信頼できるように見える (きれいな Markdown、相互参照、引用) ため、誤った情報を信頼しやすくなります。信頼しないでください。
コストはゼロではない。
すべての取り込み、すべてのクエリ、すべての Lint チェックはトークンを消費します。10 ～ 15 ページに影響を与える 1 つのソースは、フロンティアモデルを使用した API 呼び出しで 2 ～ 5 ドルかかる可能性があります。50 のソースでは、取り込みだけで 100 ～ 250 ドルです。リサーチアシスタントよりは安い。無料ではありません。
エンタープライズ規模には対応しない。
Karpathy は、インデックスファイルアプローチは RAG なしで約 100 記事で動作すると述べています。10,000 以上のソースでは、このパターンは崩壊します。インデックスが大きくなりすぎます。何千ものページにわたる一貫性は不可能になります。このシステムが回避するために設計されたインフラストラクチャが必要になります。上限を認識してください。
単一モデルの盲点。
Wiki 全体は、情報源に対する 1 つのモデルの解釈です。そのモデルにはバイアスと傾向があります。重要性の高い決定については、ある Gist のコメンテーターは、4 つ以上のモデルで独立してクエリを実行し、一致を比較することを提案しました。より堅牢です。コストも 4 倍です。
どう対処すべきか
→ エラーの複合化：毎月の Lint チェック。重要な主張は手動でクロスチェック。重要な決定では Wiki を盲目的に信頼しない。
→ コンテキスト制限：各 Wiki を 1 つのドメインに集中させる。複数のドメイン？ 複数のナレッジベース。
→ コスト：取り込みと複雑なクエリにはフロンティアモデルを使用。単純な更新には安価なモデル。
→ 幻覚：上記のスキーマでは、すべての主張にソースの引用が必要。ページが [Source: filename] なしで主張を行った場合、Lint がフラグを立てます。
→ スケール：これは個人用ツールであり、エンタープライズインフラストラクチャではないことを理解する。使いこなせたら、それは良い問題です。
それでも重要な理由
上記すべてにもかかわらず、これは現在利用可能な最も実用的な個人知識システムです。
その理由は非常に単純です：人間は、メンテナンスが価値よりも速く成長するため、Wiki を放棄します。
整理を始めると、最初の 2 週間は素晴らしく感じますが、その後、維持の負担がやる気を殺ぎ、二度と触れなくなります。
LLM は飽きません。相互参照の更新を忘れません。1 回のパスで 15 のファイルに触れることを文句を言いません。
Lex Fridman は同様のセットアップを実行していることを確認しました。
彼はインタラクティブな HTML ビジュアライゼーションを生成し、7 ～ 10 マイルのランニング中に音声モードにロードする「ミニナレッジベース」を作成しています。
DAIR.AI の Elvis Saravia は、AI 研究キュレーションのための LLM ナレッジベースを構築してきました。
複数のオープンソース実装が、Karpathy の Gist から 48 時間以内に GitHub に登場しました。
これはもはや実験ではありません。
真剣なリサーチを行うすべての人にとって標準的な慣行になりつつあります。
完全なプロンプトライブラリ (すべてコピー)
この記事のすべてのプロンプトを 1 か所に集めました：
スキーマ：ステップ 2 の完全な CLAUDE.md テンプレートをコピーします。
取り込み (1 つのソース)：
1"CLAUDE.md のスキーマを読んでください。raw/ から [ファイル名] を処理してください。完全に読んで、私と主要なポイントについて議論し、その後：サマリーページを作成し、インデックスを更新し、関連するすべてのページを更新し、バックリンクを追加し、矛盾をフラグし、取り込みをログに記録してください。"
取り込み (バッチ、監視少なめ)：
1"CLAUDE.md を読んでください。raw/ 内の未処理のファイルをすべて順次処理してください。各ファイルについて：サマリーを作成し、インデックスを更新し、関連ページを更新し、取り込みをログに記録してください。自動的に進めてください。"
クエリ：
1"wiki/index.md を読んでください。[質問] に答えてください。Wiki ページを引用してください。この回答を保存する価値がある場合は、新しい Wiki ページとしてファイルすることを提案してください。"
Lint：
1"CLAUDE.md の lint ワークフローに従って、wiki/ の完全なヘルスチェックを実行してください。wiki/lint-report-[date].md に 🔴/🟡/🔵 の重要度を付けて出力してください。ギャップを埋めるための 3 つの記事を提案してください。"
探索：
1"wiki/index.md を読んで、既存のトピック間の最も興味深い未探索の関連性を 5 つ特定してください。それぞれについて、どのような洞察が明らかになる可能性があるか、それを確認するのに役立つ情報源は何かを説明してください。"
ブリーフィング：
1"wiki/ 内のすべてに基づいて、[トピック] に関する 500 ワードのエグゼクティブブリーフィングを書いてください。情報源を引用してください。構成は次のようにしてください：現状、重要な緊張関係、未解決の質問、推奨される次のステップ。"
さあ、構築しましょう
Karpathy の Gist をブックマークすることと、そこから恩恵を受けることの違いは、たった 1 回の午後です。
トピックを選びます。フォルダを作成します。スキーマをコピーします。
すでにあるものを入れます。最初の取り込みを実行します。
そして、明日別のソースでもう一度行います。
来週はさらに 5 つで。
Wiki は毎回賢くなります。それがすべてのポイントです。
3 つのフォルダ。1 つのスキーマ。
あなたが決してやらないであろう単純作業を AI が行います。
ブックマークを収集するのをやめましょう。知識を編纂し始めましょう。
Claude をマーケティングとビジネスのための 20 以上の専門家に変えましょう。
プロンプトだけでなく、実際の専門知識をインストールします。
私の Claude スキルバンドルを入手 👇
