LLM Wiki 完全ガイド：Claude Code で育つ AI ナレッジベースを作る

このドキュメントについて

よく ChatGPT や NotebookLM に記事、論文、会議メモを入れて使っていると、同じことに気づくはずです。同じ資料でも、数日後にもう一度質問すると、AI は最初から読み直します。以前した質問や、AI がまとめた結論は、次の会話では残っていません。

Andrej Karpathy は GitHub で LLM Wiki というタイトルの gist を公開し、別のやり方を提案しました。LLM に、集めた資料を継続的に更新される markdown の Wiki にまとめてもらい、あなたは資料を探して質問することに集中し、整理、相互参照、記録といった雑務はすべて LLM に任せる、という方法です。

本ガイドでは、その gist を実際に手を動かせるステップに分解し、Claude Code を使って示します。

本ドキュメントの読み方

初めて読むなら、「15分で最初のWikiを作る」まで順に読むことをおすすめします。そこまで終えれば、すぐ使い始められます。後の章は、使いながら必要に応じて戻って確認できます。

原文のアイデアと本ガイドの設計の違い

Karpathy の gist は自ら idea file であると説明しており、概念だけを記述しています。具体的なディレクトリ構成、ページ形式、ツールは、あなたと自分の LLM Agent が一緒に決めることになっています。

そのため、本ガイドの内容は次の2種類に分かれます。

• 原文の概念：3層アーキテクチャ、Ingest、Query、Lint の3つの操作、index.md と log.md という2つの特別なファイル。各章で gist 由来であることを明記しています。
• 実装上の設計：フォルダの命名、Schema のテンプレート、プロンプト。これらは私が整理したやり方の一例です。そのまま使ってもよいですし、自分の分野に合わせて調整しても構いません。

デモ用の環境

• LLM Agent として Claude Code を使い、wiki フォルダ内で実行します。
• 閲覧側として Obsidian を使い、LLM がどのページを変更したかを開いて確認します。
• Wiki 自体が markdown を置いた git リポジトリです。

私自身は Obsidian と Notion を併用しています。本ガイドの手順は特定のソフトウェアに依存しません。LLM がそれらの markdown ファイルを読み書きできれば動作します。

次のステップ

まだ何もインストールする必要はありません。しばらく集めてきたものの、あちこちに散らばっているテーマを1つ用意してください。たとえば、あるフレームワークの記事、読んでいる途中の本、ある顧客の会議メモなどです。次の章では、そのテーマを使って RAG と LLM Wiki の違いを比べます。

出典：Andrej Karpathy の LLM Wiki gist（2026-11-05 確認）。

なぜ RAG では知識が蓄積されないのか

NotebookLM や ChatGPT のファイルアップロードに文書を10件入れて、5件の文書を総合しないと答えられない質問をしたとします。AI はファイルから関連する断片を探し出し、それをつなぎ合わせて回答します。

翌日に似た別の質問をすると、AI は最初からまた探し、最初からまたつなぎ合わせます。前回つなぎ合わせて得た結論は、どこにも残っていません。

RAG のしくみ

RAG（Retrieval-Augmented Generation、検索拡張生成）の流れは次のとおりです。

1. 文書を断片に分割し、インデックスを作成する。
2. 質問されると、システムが最も関連性の高い断片をいくつか見つける。
3. 断片と質問をあわせて LLM に渡し、回答を生成する。

Karpathy の gist は、NotebookLM、ChatGPT のファイルアップロード、そして多くの RAG システムがこの方式で動いていると指摘しています。質問のたびに、LLM は元の文書から知識を改めて発見し直しており、何も蓄積されていません。

LLM Wiki のしくみ

LLM Wiki は、処理のタイミングを前倒しします。新しい資料を1件加えるたびに、LLM がまず読んで要点を抽出し、そのうえで 既存の wiki に統合 します。関連するページを更新し、要約を修正し、新しい資料が古い説と矛盾する箇所に印を付けます。

知識は一度だけ整理され、その後も最新の状態が保たれます。質問のたびに推論し直す必要はありません。gist はこの違いを一文で説明しています。wiki は継続的に蓄積された成果物であり、相互参照はすでに構築され、矛盾はすでに明示され、統合された結論にはあなたが読んだすべての資料が反映されている、というものです。

対照表

それでも RAG を使うべき場面

LLM Wiki は RAG を置き換えるものではありません。次の2つの場合は、RAG のほうが適しています。

• 資料量が非常に多く、特定の断片を探すだけでよい場合：たとえば、カスタマーサポートのボットが数千件の文書から特定の規定を1つ探し出す場合です。文書を全体の理解として統合する必要はありません。
• 資料を自分で蓄積しているわけではない場合：たとえば公開されている文書ライブラリで、検索するだけでよく、整理済みのバージョンを自分で維持する必要がない場合です。

gist では、index.md のような目次型の方式は、約100件のソース、数百ページの規模であれば十分うまく機能し、embedding 検索を別途構築する必要はないと述べられています。この規模を超える場合は検索ツールを加えます。それについては後の章で説明します。

以前、n8n、Google Drive、Pinecone を使ってカスタマーサポートのボットを作る記事を書いたことがあります。典型的な RAG の場面なので、本ガイドと対比しながら読んでいただけます：n8n と Google Drive + RAG で企業向け LINE カスタマーサポート AI ボットを作る方法（繁體中文）。

次のステップ

前の章で選んだテーマに戻り、LLM に繰り返し質問している3つの問いを書き出してください。3つの答えがいずれも複数の資料の総合を必要とするなら、そのテーマは LLM Wiki にするのに向いています。

出典：Andrej Karpathy の LLM Wiki gist の The core idea と Indexing and logging の2節（2026-11-05 確認）。対照表の「あなたがすること」の行は本ガイドによる整理です。

3層アーキテクチャ

LLM に wiki を長期にわたって維持させるには、最初に「誰が何を変更できるか」を明確に分けることが必要です。生の資料と整理後のページが同じフォルダに混在していると、LLM は整理しながら原文まで書き換えてしまいやすく、数週間もすると、どれが原文でどれが LLM の解釈なのか区別がつかなくなります。

gist は、このシステム全体を3つの層に分けています。

3つの層それぞれの役割

Raw sources：変更不可の原資料

この層があなたの source of truth です。LLM はここから読みますが、変更はしません。こうすることには2つの利点があります。wiki のどのページの記述も、原資料に戻って照合できること。また、LLM が誤って整理しても原文が残っているので、やり直せることです。

Wiki：LLM が担当する層

wiki は markdown ファイルでいっぱいのフォルダです。LLM はページの作成、新しい資料が入ったときのページ更新、ページ間リンクの維持、内容の一貫性の保持を担当します。あなたは読む役割を担います。

gist はソフトウェア開発にたとえています。Obsidian は IDE、LLM はエンジニア、wiki はコードベース です。あなたは Obsidian を開いて閲覧し、LLM が会話に基づいてファイルを変更すると、その結果をリアルタイムで確認できます。

Schema：LLM を規律ある維持管理者にする

Schema は、この wiki の構造、命名規則、そして新しい資料を受け取ったとき、質問に答えるとき、健全性チェックを行うときに従うべき手順を LLM に伝える文書です。Claude Code は CLAUDE.md を読み、Codex は AGENTS.md を読みます。

Schema がなければ、LLM は一般的なチャットボットにすぎず、会話のたびに異なる方法で整理してしまいます。Schema があれば、新しいセッションごとに同じルールから始まります。gist はまた、この文書は使いながら少しずつ調整し、あなたの分野に合ったやり方を見つけていくことが重要だと強調しています。

フォルダの構成

本ガイドで示す構成は次のとおりです。

my-wiki/
├── CLAUDE.md          # schema
├── raw/               # sources, read-only
│   └── assets/        # downloaded images
└── wiki/              # owned by the LLM
    ├── index.md       # catalog of all pages
    ├── log.md         # append-only timeline
    ├── sources/       # one summary page per source
    ├── entities/      # people, products, organizations
    └── concepts/      # ideas and topics

sources、entities、concepts の3つのサブフォルダは本ガイドの設計です。gist では、wiki に要約、エンティティページ、概念ページ、比較、概要が含まれることだけが述べられており、フォルダについては規定されていません。あなたの分野がこの分け方に合わない場合は、適した分け方に置き換えてください。その場合も Schema に書くことを忘れないでください。

次のステップ

お使いのパソコンに空のフォルダを作成し、名前を my-wiki にしてください。まだ何もファイルは入れないでください。次の章では、この空のフォルダから始めて、Claude Code で全体の構成を作ります。

出典：Andrej Karpathy の LLM Wiki gist の Architecture と The core idea の2節（2026-11-05 確認）。フォルダ構成は本ガイドの設計です。

15分で最初のWikiを作る

LLM Wiki を実際に使うとどんな感じか知りたいだけなら、順番に進めてください。終えると、動作する wiki ができていて、最初の資料も入っています。

1. フォルダを作成する

mkdir -p my-wiki/raw/assets my-wiki/wiki/{sources,entities,concepts}  # 1. Folders
cd my-wiki
touch CLAUDE.md wiki/index.md wiki/log.md                             # 2. Empty files
git init                                                              # 3. Version history

git init は意図的に行っています。wiki は markdown を置いた repository なので、LLM が変更するたびに git diff で、どのページが変わったかを確認でき、気に入らなければ元に戻せます。

2. 最小限の Schema を書く

CLAUDE.md を開き、まずこの短い部分を貼り付けてください。完全なテンプレートは次の章にあります。ここでは、LLM に最も基本的なルールを伝えられれば十分です。

# My Wiki

これは LLM が維持する個人の知識ベースで、テーマは：<あなたのテーマ>

## ディレクトリ

- `raw/`：元資料。読み取りのみで、変更してはいけない
- `wiki/`：あなたが維持するページ
- `wiki/index.md`：すべてのページの目次。ingest のたびに更新する
- `wiki/log.md`：実行した作業を時系列で記録。末尾への追記のみ可能

## ルール

- すべての wiki ページは日本語で書く
- ページ間は `[[ページ名]]` でリンクする
- ページを新規作成または変更したら、必ず `wiki/index.md` を更新し、`wiki/log.md` に1件追記する

3. 最初の資料を入れる

整理したい記事を1本選び、markdown として保存して raw/ に入れてください。記事が Web 上にある場合は、ブラウザ拡張機能（例：Obsidian Web Clipper）で markdown に変換してもよいですし、そのままコピー＆ペーストしても構いません。

cat > raw/first-article.md   # Paste the article, then Ctrl+D

4. Claude Code を起動し、最初の Ingest を実行する

claude   # Start in the my-wiki folder

次に、以下を入力します。

raw/first-article.md を読み、CLAUDE.md のルールに従って wiki に整理してください。
まず読み取った3つの要点を私に伝えてから、ページの作成を始めてください。

Claude Code はまず要点についてあなたと話し合い、確認を得てから、要約ページと関連する概念ページを作成し、index.md を更新して、log.md に1件追記します。

5. 結果を確認する

git status --short   # Which files changed
git diff             # What exactly changed
cat wiki/log.md      # The new log entry

確認すべき点は3つです。wiki/sources/ 配下に新しい要約ページがあるか、wiki/index.md に対応する項目が追加されているか、log.md の最終行が ## [日付] ingest | 記事タイトル の形式になっているかどうかです。

問題なければ git add -A && git commit -m "ingest: first-article" を実行してください。気に入らなければ、Claude Code に修正箇所を伝え、修正後に diff をもう一度確認してください。

よくある状況

次のステップ

1つだけ行うことをおすすめします。同じテーマの資料をもう1件入れ、第4ステップを繰り返してください。1回目と2回目の git diff を比べてください。2回目では、LLM が新規追加だけでなく、既存のページも修正しているはずです。ここが LLM Wiki と単純な要約ツールの違いです。

出典：Andrej Karpathy の LLM Wiki gist の Operations と Indexing and logging の2節（2026-11-05 確認）。コマンドと Schema の内容は本ガイドの設計です。

Schema を書く

Schema はシステム全体の中で最も重要なファイルです。LLM 自体には記憶がなく、新しいセッションはすべてゼロから始まります。この wiki がどのような構成で、今回はどの手順に従うべきかは、CLAUDE.md を頼りに知ることになります。

gist は Schema を重要な設定ファイルと呼んでいます。これにより LLM は、一般的なチャットボットではなく、規律ある wiki の維持管理者になります。同時に、この文書は、あなたと LLM が使用の過程で一緒に調整して作り上げるものであることも強調されています。

Schema に書く内容

完全なテンプレート

以下はそのまま CLAUDE.md にコピーできます。「テーマ」と「ページの種類」は、あなた自身の分野に置き換えてください。

# My Wiki

これは LLM が維持する知識ベースで、テーマは：<あなたのテーマ>。
あなたは wiki の整理と維持を担当し、私は資料の選定と質問を担当します。

## ディレクトリ構成

- `raw/`：元資料。読み取り専用で、絶対に変更・削除してはいけない。
- `raw/assets/`：元資料内の画像。
- `wiki/`：あなたが管理するページ。整理後の内容はすべてここに置く。
- `wiki/index.md`：すべてのページの目次。
- `wiki/log.md`：時系列の記録。末尾への追記のみ可能。
- `wiki/sources/`：元資料1件につき1ページの要約。
- `wiki/entities/`：人物、製品、組織。1対象につき1ページ。
- `wiki/concepts/`：概念とトピック。1概念につき1ページ。

## ページ形式

すべてのページに frontmatter を付けること：

```yaml
---
type: source | entity | concept
tags: []
sources: [] # このページの根拠となる raw/ 内のファイル
updated: YYYY-MM-DD
---
```

- ファイル名は小文字の英字とハイフンを使う。例：`retrieval-augmented-generation.md`。
- ページ間は `[[ファイル名]]` でリンクする。拡張子は付けない。
- 各論点には、どの `sources/` ページに由来するかを明記する。
- 要約ページの末尾には必ず「既存の内容との関係」の節を置き、この資料がどのページを補足・修正・反論したかを明記する。

## Ingest：新しい資料を受け取ったとき

1. `raw/` 内で指定されたファイルを読む。
2. まず重要なポイントを3〜5個伝え、私の返答を待ってから続ける。
3. `wiki/sources/` に要約ページを作成する。
4. 関連する entities と concepts のページを更新する。対応するページがない重要な概念は、新規ページを作成する。
5. 新しい資料が既存の説と矛盾する場合は、両方を残し、ページ内で矛盾を明示する。
6. `wiki/index.md` を更新する。
7. `wiki/log.md` に1件追記する。

## Query：質問に答える

1. まず `wiki/index.md` を読み、関連するページを見つけてから、それらのページを読む。
2. 回答では、根拠となるページを明記する。
3. 回答が新しい統合・比較・結論である場合は、wiki のページとして保存するかどうかを私に尋ねる。

## Lint：健全性チェック

チェックして報告し、修正する前に私に確認すること：

- ページ間で互いに矛盾する説
- 新しい資料によって置き換えられた古い説
- どのページからもリンクされていない孤立ページ
- 何度も言及されているのに独立したページがない概念
- 不足している相互リンク
- ウェブ検索で補えるデータの欠落

## log.md 形式

各エントリは固定のプレフィックスで始める：

```text
## [YYYY-MM-DD] ingest | 資料タイトル
## [YYYY-MM-DD] query | 質問の要約
## [YYYY-MM-DD] lint | チェック範囲
```

この下に、変更したページを1〜3行で説明する。

Schema を調整するタイミング

このテンプレートは出発点です。実際に使う中で、次のような状況が見られたら Schema の見直しのサインです。

• 同じことを何度も LLM に口頭で訂正している場合は、それを Schema に書き加える。
• ある種類のページに固定のフィールドが必要だと分かった場合（例：本の著者と出版年）は、ページ形式に加える。
• ある資料は簡単な処理で済むことが多い場合は、「軽量 ingest」の手順を別に書き加える。

gist は、資料を1件ずつ処理して全工程に関わるか、多くの資料をまとめて処理して関与を減らすかを、あなた自身が決めるよう勧めています。そのうえで、選んだ手順を Schema に書き込めば、次のセッションからその手順に従うようになります。

次のステップ

上のテンプレートをコピーし、変更するのは2か所だけです：テーマとページの種類。その後、Claude Code で /memory と入力し、CLAUDE.md が読み込まれていることを確認してください。読み込み方法とパスのルールは、Claude Code ガイドの CLAUDE.md とメモリシステム を参照できます。

出典：Andrej Karpathy の LLM Wiki gist の The schema と Operations の2節（2026-11-05 確認）。テンプレートの内容は本ガイドの設計です。

Ingest：資料を1件取り込む

Ingest は LLM Wiki で毎日行う操作です。新しい資料1件を LLM に渡し、wiki に統合させます。この工程がうまくできるかどうかで、wiki が使うほど価値を増していくかどうかが決まります。

Ingest で実際に行われること

gist が説明している流れは次のとおりです。

1. LLM がソースを読み、あなたと要点について話し合う。
2. wiki に要約ページを1枚書く。
3. index.md を更新する。
4. wiki 全体にまたがる関連するエンティティページと概念ページを更新する。
5. log.md に記録を1件追記する。

1件のソースで、10〜15ページが同時に変わることがあります。人間が wiki を長期的に維持するのが難しい理由もここにあります。読み切れないからではなく、毎回それだけ多くの箇所を更新しなければならないからです。

1件ずつにするか、まとめて処理するか

gist の著者自身は、1件ずつ全工程に関わるやり方を好んでいます。始めたばかりの頃もそうすることをおすすめします。Schema が安定してから、まとめて処理する方法で大量の過去の資料を取り込んでください。

プロンプトの例

1件ずつ処理する場合：

raw/rag-survey.md を読み、CLAUDE.md の Ingest 手順に従って wiki に整理してください。
まず読み取った要点を私に伝え、私が確認してからページの変更を始めてください。
この資料では特に強調したいことがあります：検索戦略の比較です。

まとめて処理する場合：

raw/inbox/ の下に新しい資料が12件あります。
CLAUDE.md の Ingest 手順に従って1件ずつ処理し、各資料の処理が終わるごとに log.md に1件追記してください。
すべて完了したら、変更したページと矛盾している箇所を一覧にしてください。

LLM の作業が正しいかどうかの確認方法

「完了しました」という言葉だけで判断せず、git で実際の変更を確認してください。

git diff --stat      # Files touched and line counts
git diff wiki/       # Full content of the changes
git log --oneline -5 # Recent commits

確認すべき点は4つです。

• raw/ を変更していないか：git diff --stat raw/ の出力が何もないはずです。
• 要約ページに「既存の内容との関係」が書かれているか：これは、既存のページと照合したかどうかを確認するポイントです。
• index.md に対応する新しい項目があるか。
• log.md 最後のエントリの形式：例：## [2026-11-05] ingest | RAG 研究の総説

矛盾は残す。こっそり上書きさせない

新しい資料と古いページで説明が食い違うとき、最も危険なのは、LLM が古い記述を直接新しい記述に書き換えてしまうことです。どちらが正しいか分からなくなり、「この見解は覆されたことがある」という記録も失われます。

Schema のテンプレートにはすでに、両方を残し、矛盾を明示することが書かれています。Ingest のあとに diff を確認するときは、この種のマーキングを特に探し、どちらを採用するか決めてください。

次のステップ

手元にある最も長い資料を1つ選び、「1件ずつ」の方法で Ingest を1回実行してください。終わったら git diff --stat で、いくつのページが変わったかを数えてください。要約ページ1枚だけが変わっていた場合は、CLAUDE.md の Ingest 手順の第4ステップが明確に書かれているか見直してください。

出典：Andrej Karpathy の LLM Wiki gist の Operations 節の Ingest 段落（2026-11-05 確認）。プロンプトと確認項目は本ガイドの設計です。

Query：質問して回答を保存する

wiki ができあがったら、そのまま質問できます。通常のチャットとの最も大きな違いは、良い回答を会話履歴に残すだけにせず、wiki に保存して、次回すぐに引用できる1ページにすることです。

LLM が回答を探す方法

gist の方法に従うと、LLM は質問に答えるとき次のように進めます。

1. まず index.md を読み、関連しそうなページを見つける。
2. 次にそれらのページを開いて内容を読む。
3. 統合したうえで回答し、引用したページを明記する。

この方法は、約100件のソース、数百ページの規模であれば十分うまく機能し、embedding 検索を別途構築する必要はありません。index.md はいわばその地図なので、Ingest のときに必ず適切に維持してください。

回答は必ずしもテキストではない

gist では、質問に応じて回答の形式を選べるとされています。

プロンプトの例

wiki に出てくる3つの検索戦略を比較し、表で示してください。
各セルには出典のページを明記してください。

wiki の内容に基づくと、社内で RAG を導入する場合、
最大のリスクは何ですか？回答には根拠となるページを明記し、
wiki の現在のデータでは不足している箇所も指摘してください。

2つ目のプロンプトで最後に書いている一文が重要です。資料が不足している箇所を指摘させることで、LLM が自分の知識で、もっともらしく見えるけれど wiki には存在しない内容を補ってしまうことを防げます。

どの回答を wiki に保存すべきか

すべての回答が保存に値するわけではありません。次の3つの場合は、新しいページとして保存することをおすすめします。

• 複数のページを統合した結論：次回つなぎ直す必要がなくなります。
• あなたが時間をかけて追問し、修正した回答：そのプロセス自体に価値があります。
• 後で再び引用する比較や分析。

単に事実を1つ調べただけの、一度きりの質問は保存する必要はありません。

保存するときの指示：

先ほどの比較を wiki/concepts/retrieval-strategies.md として保存してください。
ページ形式に従って frontmatter を追加し、index.md を更新し、log.md に query の記録を追記してください。

保存したあとは、このページは Ingest で生成されたページと同じ扱いになります。リンクがあり、Lint でチェックされ、次回の Query で引用できます。あなたの質問も、こうして wiki に蓄積されていきます。

次のステップ

wiki の既存の内容を使い、少なくとも3ページを統合する必要がある質問を1つしてください。回答が得られたら、出典のページが明記されているかを確認します。回答が残す価値のあるものなら、上の指示で新しいページとして保存し、もう一度 git diff を確認してください。

出典：Andrej Karpathy の LLM Wiki gist の Operations 節の Query 段落と Indexing and logging 節（2026-11-05 確認）。プロンプトと保存の判断基準は本ガイドの整理です。

Lint：定期的な健全性チェック

wiki を数週間使うと、いくつかの状況に出会うようになります。同じ概念が2つのページで違う説明になっている、ある結論が実は新しい資料によって覆されているのに、ページは古いままになっている、書き終えたあとに誰からもリンクされなくなったページがいくつかある、などです。

Lint とは、定期的に LLM に wiki 全体をチェックさせ、これらの問題を見つけ出すことです。

チェックする内容

gist が挙げているチェック項目は次のとおりです。

LLM は、次に調べるとよい新しい問いや、探すとよい新しいソースを提案することも得意です。

プロンプトの例

CLAUDE.md の Lint 手順に従って、wiki 全体をチェックしてください。
まず問題をすべて一覧にし、深刻度の順に並べ、各項目に関連するページを明記してください。
まだ何もファイルは変更しないでください。どれを対処するかは私が決めます。

Schema のテンプレートには「チェックして報告し、修正する前に私に確認する」と書かれています。Lint は修正の範囲が通常大きいため、まず一覧を確認してから、どれを変更するかを決める必要があるからです。

コマンドで先にざっと確認する

LLM を使わなくても、簡単なコマンドで見つけられる項目があります。以下は孤立ページを探す方法です（ページ間を [[ファイル名]] でリンクしている場合）。

for f in $(find wiki -name '*.md' ! -name index.md ! -name log.md); do
  n=$(basename "$f" .md)
  grep -rlF "[[$n]]" wiki >/dev/null || echo "$f"   # No inbound link
done

出力の各行が、どのページからもリンクされていないファイルです。

log.md は各エントリに固定のプレフィックスが付いているため、直接コマンドで最近の記録を確認することもできます。

grep "^## \[" wiki/log.md | tail -5   # Last 5 entries

実行の頻度

gist には「定期的に」とだけ書かれています。まずは次のペースで始め、その後は自分の状況に応じて調整してください。

• Ingest を5〜10回行うごとに、Lint を1回完全に実行する。
• あるページの内容があなたの認識と違うと気づいたら、そのテーマに絞って部分的な Lint を行う。

定期的に自動実行したい場合は、Claude Code のヘッドレスモードで実現できます。詳細は Claude Code ガイドの自動化の章 を参照してください。スケジュール実行の場合は、「報告のみ、修正はしない」の状態を保つことをおすすめします。修正するかどうかは、一覧を確認したうえで、引き続きあなたが決めてください。

次のステップ

今すぐ上のプロンプトを使って Lint を1回実行してください。結果を見るときは、1種類の問題だけを対処してください。最初に矛盾を対処することをおすすめします。wiki が最も誤った内容を信じさせやすい箇所だからです。対処が終わったら、log.md に lint の記録を1件追記してください。

出典：Andrej Karpathy の LLM Wiki gist の Operations 節の Lint 段落と Indexing and logging 節（2026-11-05 確認）。プロンプト、コマンド、頻度の提案は本ガイドの整理です。