はじめに
日々、我々はたくさんのメモを取っています。取っていますよね？
開発をしていると、エラーの原因、ライブラリの調査結果、設計上の判断、試したけどうまくいかなかった方法など、いろいろなメモが増えていきます。
でも、メモを取ったあとに整理するのは面倒です。
あとで同じ問題に遭遇したときに「あのメモどこだっけ？」と探したり、結局もう一度同じことを調べたりするのは避けたいところです。
ならば、とりあえずメモを取って保存しておき、あとからLLMに整理してもらえばいいのでは？？と思いました。
そこで気になったのが「LLM Wiki」です。この記事ではLLM Wikiについて話をしていこうと思います。
また、この記事では雑なメモをLLMが既存の情報と照合し、関連付けながら整理・更新していくナレッジベースをLLM Wikiと呼びます。
LLM Wikiそのものの考え方や背景については、以下の解説も参考にしてください。
Andrej Karpathy氏によるLLM Wikiの解説
LLM Wikiには、すでに以下のような実装があります。
これを使えばいいじゃんという話ではあるのですが、LLM Wikiの仕組みを知りたかったのと、まずはミニマムな構成で試したかったので、個人の検証用としてCodex + WSL2で小さなLLM Wikiを作ってみようと思います。
実際に作ってみる
では、raw/に置いたメモをLLMで整理するシンプルなWikiを作っていきます。
ディレクトリ構成は次のようにします。
LLMWiki/
├── AGENTS.md
├── wiki-purpose.md
├── wiki-schema.md
├── raw/
└── wiki/
├── index.md
├── overview.md
├── log.md
├── sources/
├── entities/
├── concepts/
└── syntheses/
前提環境
今回は以下の環境を使います。
- Windows
- WSL2
- Codex
- VS Code
- Git
必ずしも同じ環境である必要はありません。
Markdownファイルを扱える環境、Git、ローカルファイルを読み書きできるLLM / AIエージェントがあれば試せます。
業務上の資料、顧客情報、個人情報、機密情報などを扱う場合は、所属組織のセキュリティポリシーや、利用するLLM / AIサービスのデータ取り扱い条件を確認してください。
以下の構成やルールは、記事用に一般化したサンプルです。
1. プロジェクトを作る
まず、必要なディレクトリとファイルをまとめて作ります。
mkdir -p ~/work/LLMWiki
cd ~/work/LLMWiki
git init
git branch -m main
mkdir -p raw
mkdir -p wiki/{sources,entities,concepts,syntheses}
touch AGENTS.md wiki-purpose.md wiki-schema.md .gitignore
touch wiki/index.md wiki/overview.md wiki/log.md
touch raw/.gitkeep
この記事のサンプルでは、raw/ を未整理の原典置き場として扱い、Git管理の対象外にします。
.gitignore には以下を記載します。
raw/*
!raw/.gitkeep
PDFやWebページの保存などが増えると、リポジトリが大きくなりやすいためです。
原典もバックアップしたい場合は、別の保存先を用意するか、raw/ もGit管理する運用を検討してください。
実運用では、所属組織のルールに合わせてください。
2. LLMに整理ルールを渡す
今回の構成で重要なのは、以下の3ファイルです。
-
wiki-purpose.md: Wikiの目的 -
wiki-schema.md: ページの分類と保存形式 -
AGENTS.md: LLMが守る運用ルール
wiki-schema.md では、Wikiページを次の4種類に分けます。
| 種類 | 内容 |
|---|---|
| source | 1つの原典について整理したページ |
| entity | 人物、企業、製品、ツールなど |
| concept | 技術、概念、方法論など |
| synthesis | 複数の情報を横断して整理したページ |
最初から分類を増やしすぎず、必要になったら追加する方針です。
AGENTS.md には、特に次のルールを書いておきます。
## Core principles
- rawの既存ファイルは変更・削除しない
- rawの内容を単純にコピーするだけのWikiを作らない
- 新しい情報は既存Wikiとの関係を確認してから整理する
- 同じ内容のページを重複して作らない
- 可能な限り既存ページへ知識を統合する
- 関連するページ同士をMarkdownリンクで接続する
- 原典にない情報を事実として追加しない
- 原典を追跡できる状態にする
また、ingest、query、lint という3つの運用を定義します。
-
ingest: rawのメモをWikiへ整理・統合する -
query: Wikiから必要な知識を取り出す -
lint: リンク切れや重複ページなどを点検する
各ファイルの全文は長いため、この記事では要点だけ掲載します。
3. Wikiの初期ページを作る
wiki/index.md は、各ページへの入口として使います。
# Wiki Index
## Overview
- [Overview](overview.md)
## Sources
まだありません。
## Concepts
まだありません。
wiki/overview.md にはWiki全体の概要を、wiki/log.md には主要な変更履歴を残します。
ここまでできたら、一度コミットしておきます。
git add .
git commit -m "Initialize LLM Wiki"
4. 開発メモを取り込む
では、動作確認用のダミーメモを入れてみます。
raw/memo_1234567890.md を作り、次のように書きます。
# CIエラーの調査メモ
ライブラリAを更新したあと、CIだけビルドに失敗した。
ローカルでは通っている。
確認したら、ローカル環境は実行環境のバージョン2、
CIはバージョン1を使っていた。
CI側をバージョン2に変更したらビルドが通った。
次からは依存関係を更新するときに、
ローカルとCIの実行環境も確認したほうがよさそう。
調査中のメモなので、きれいな文章にする必要はありません。
続いて、Codexへ次のように依頼します。
ingest raw/memo_1234567890.md
ingest はLinuxのコマンドではなく、AGENTS.md に定義した自然言語上の運用コマンドです。
LLMは元のメモと既存Wikiを確認し、必要なページを作成・更新します。
今回の例では、次のような形になります。
wiki/
├── sources/
│ └── ci-build-error.md
├── concepts/
│ └── execution-environment-version-differences.md
├── index.md
├── overview.md
└── log.md
wiki/concepts/execution-environment-version-differences.md には、例えば次のような知識が整理されます。
# 実行環境のバージョン差異
ローカル環境とCI環境で実行環境のバージョンが異なると、
依存関係の更新後に、一方の環境だけビルドが失敗することがある。
## 確認すること
- ローカル環境とCI環境のバージョン
- ライブラリが要求するバージョン
- CIで指定している実行環境
単なるエラー記録が、別のプロジェクトでも参照できる確認項目になりました。
5. Gitの差分を確認する
LLMが処理を終えたら、すぐにコミットせず差分を確認します。
git status
git diff
特に確認したいのは以下です。
-
raw/の原典が変更されていないか - ページが細かく分割されすぎていないか
- 原典にない内容が追加されていないか
-
index.mdとlog.mdが更新されているか
問題がなければコミットします。
git add .
git commit -m "Ingest initial memo"
6. 過去の知識を再利用する
別の開発でCIだけビルドに失敗したとします。
その場合は、LLMへ次のように質問します。
query: CIだけビルドに失敗するとき、確認したほうがよいことは？
すると、Wikiに保存された情報をもとに、次のような確認項目を取り出せます。
- ローカル環境とCI環境のバージョン
- ライブラリが要求するバージョン
- CIで指定している実行環境
先ほどの雑なメモを、別のタイミングで再利用する流れを確認できました。
この設計で重視したこと
今回重視したのは、「とりあえずメモを書く」と「知識を整理する」を分けることです。
人間側では、raw/ にとりあえず書くだけでよい状態を目指しています。
ただし、LLMに完全に自由に整理させると、次のような問題が起きやすくなります。
- ページを細かく作りすぎる
- 同じ概念のページが増える
- 要約だけが大量に蓄積される
- 情報源が分からなくなる
そのため、AGENTS.md で「既存ページを確認する」「重複を作らない」「原典を追跡できる状態にする」といったルールを決めています。
LLM Wikiの品質は、モデルそのものだけでなく、こうした運用ルールにも大きく左右されると思います。
また、この記事でいう「自動整理」は、raw/ を常時監視して勝手に処理するという意味ではありません。
人間が ingest を依頼したあと、読み取り、分類、既存ページとの統合をLLMに任せる構成です。
今後やりたいこと
この記事では、ダミーメモを1件取り込むところまで試しました。
今後は、実際にメモを増やしながら以下を確認したいと思います。
- 複数メモを既存ページへ正しく統合できるか
- conceptページが増えすぎないか
- Wikiが大きくなっても必要な情報を見つけられるか
- WebページやPDFも取り込めるようにする
- lintやGitコミットを自動化する
最初から仕組みを複雑にしすぎず、必要になったものだけ追加していく予定です。
おわりに
今回は、Markdown、Git、Codexを使って、小さなLLM Wikiを作ってみました。
まずはこの構成で試しながら、必要に応じて整理ルールやページ構成を調整していこうと思います。
LLM Wikiに興味がある方は、ぜひ試してみてください！