# LLM Wiki

LLMを用いたパーソナルナレッジベースの構築パターン

これはアイデアファイルであり、あなたのLLMエージェント（OpenAI Codex、Claude Code、OpenCode / Piなど）にコピー＆ペーストして使用することを目的としている。このファイルの目標は高水準のアイデアを伝えることだが、具体的な実装はあなたとエージェントが協力して構築する。

## コアアイデア

LLMとドキュメントのほとんどの人の経験はRAG（Retrieval-Augmented Generation）のような形をしている：ファイルのコレクションをアップロードし、LLMがクエリ時に関連するチャンクを取得し、回答を生成する。これは機能するが、LLMは毎回の質問で知識をゼロから再発見している。蓄積がない。5つのドキュメントを統合する必要がある微妙な質問をすると、LLMは関連する断片を毎回見つけて組み合わさなければならない。何も構築されません。NotebookLM、ChatGPTのファイルアップロード、ほとんどのRAGシステムはこのように動作する。

ここで提案されているアイデアは異なる。クエリ時に生のドキュメントから取得するだけでなく、LLMが**永続的なwikiを漸進的に構築・維持する** — あなたと生のソースの間に位置する、構造化され相互リンクされたマークダウンファイルのコレクションである。新しいソースを追加すると、LLMは単にそれを後で取得するためにインデックス化するのではなく、それを読み、主要な情報を抽出し、既存のwikiに統合する — エンティティページを更新し、トピックの要約を書き直し、新しいデータが古い主張と矛盾する場所に注目し、進化している統合を強化または挑戦する。知識は一度コンパイルされ、その後*最新に保たれ*、毎回のクエリで再派生されることはない。

これが鍵となる違いである：**wikiは永続的で複利効果を持つ成果物である。** クロス参照はすでに存在する。矛盾はすでにフラグが立てられている。統合はすでにあなたが読んだすべてのものを反映している。wikiは追加するソースごとに、質問するごとに、ますます豊かになっていく。

あなたはwikiを自分で書くことはありません（またはほとんど書きません） — LLMがすべてを書き、維持する。あなたはソースの選定、探索、適切な質問することに責任を持つ。LLMはすべての地味な作業 — 要約、クロス参照、ファイル整理、保守 — を行い、これにより知識ベースは時間とともに実際に有用になる。実際には、LLMエージェントを画面の片側に開き、Obsidianをもう片側で開いている。LLMは会話に基づいて編集を行い、私はリアルタイムで結果を閲覧する — リンクを追跡し、グラフビューをチェックし、更新されたページを読む。ObsidianがIDE、LLMがプログラマー、wikiがコードベースである。

これは多くの異なるコンテキストに適用できる。いくつかの例：

- **パーソナル**: 目標、健康、心理学、自己改善を追跡 — 日記、記事、ポッドキャストのノートをファイル整理し、時間とともに構造化された自己像を構築する
- **リサーチ**: 数週間や数ヶ月にわたってトピックを深く掘り下げる — 論文、記事、レポートを読み、進化している主張を含む包括的なwikiを漸進的に構築する
- **本の読書**: 章ごとにファイルを整理し、キャラクター、テーマ、プロットの糸、それらがどのように接続するかのためのページを構築する。終わりの頃には豊かな補完wikiができている。[Tolkien Gateway](https://tolkiengateway.net/wiki/Main_Page)のようなファンwikiを想像してください — 何年もの間ボランティアのコミュニティによって構築された、キャラクター、場所、イベント、言語をカバーする数千の相互リンクページ。LLMがすべてのクロス参照とメンテナンスを行いながら、あなたが読む際に個人でそのようなものを構築できる
- **ビジネス/チーム**: LLMによって維持される内部wiki、Slackスレッド、会議の書き起こし、プロジェクトドキュメント、顧客との通話によってフィードされる。人間のレビューをループに含む可能性あり。チームの誰もやりたくないメンテナンスをLLMが行うため、wikiは最新に保たれる
- **競合分析、実証調査、旅行計画、コースノート、趣味の掘り下げ** — 時間とともに知識を蓄積させ、それらを散在させるのではなく整理したいあらゆるもの

## アーキテクチャ

3つのレイヤーがある：

**生のソース** — 選別されたソースドキュメントのコレクション。記事、論文、画像、データファイル。これらは不変であり、LLMはこれらから読み取るが、決して変更しない。これが真実の源である。

**wiki** — LLM生成のマークダウンファイルのディレクトリ。要約、エンティティページ、コンセプトページ、比較、概要、統合。LLMがこのレイヤーを完全に所有している。ページを作成し、新しいソースが届いたときに更新し、クロス参照を維持し、すべてを一貫性に保つ。あなたが読む、LLMが書く。

**スキーマ** — wikiがどのように構造化されているか、規約は何であるか、ソースを取り込む際、質問に答える際、wikiを維持する際に従うべきワークフローをLLMに指示するドキュメント（例：Claude CodeならCLAUDE.md、CodexならAGENTS.md）。これが主要な設定ファイルであり、LLMを一般的なチャットボットではなく規律あるwikiメンテナーにするもの。あなたがあなたのドメインで何が機能するかを理解するにつれて、あなたとLLMはこれを時間とともに共進化させる。

## 操作

**取り込み（Ingest）**。新しいソースを生のコレクションにドロップし、LLMに処理するよう指示する。例えば、LLMがソースを読み、主要な発見についてあなたと議論し、wikiに要約ページを書き、インデックスを更新し、wiki全体の関連するエンティティとコンセプトページを更新し、ログにエントリーを追加する。1つのソースで10〜15のwikiページに影響する可能性がある。個人的には、ソースを1つずつ取り込み、関与し続けることを好む — 要約を読み、更新をチェックし、何を強調するかをLLMに指示する。しかし、より少ない監督で複数のソースを一括取り込みすることもできる。あなたのスタイルに合ったワークフローを開発し、将来のセッションのためにスキーマに文書化するのはあなた次第である。

**クエリ（Query）**。wikiに対して質問する。LLMが関連するページを検索し、読み、引用付きで回答を統合する。回答は質問に応じて異なる形式を取り得る — マークダウンページ、比較表、スライドデッキ（Marp）、チャート（matplotlib）、キャンバス。重要な洞察：**良質な回答は新しいページとしてwikiにファイル戻しできること。** あなたが求めた比較、分析、発見した接続 — これらは価値があり、チャット履歴に消えてしまうべきではない。このようにして、あなたの探求は取り込まれたソースと同様に知識ベースで複利効果を持つ。

**リンティング（Lint）**。定期的にLLMにwikiのヘルスチェックを依頼する。探すもの：ページ間の矛盾、新しいソースに置き換えられた古い主張、インバウンドリンクがない孤立ページ、独自のページが欠けている重要なコンセプト、欠落したクロス参照、ウェブ検索で埋められる可能性のあるデータのギャップ。LLMは調査するための新しい質問や探すべき新しいソースを提案するのが得意である。これにより、wikiは成長しながら健全に保たれる。

## インデックスとログ

wikiが成長するにつれてLLM（およびあなた）がナビゲーションするのに役立つ2つの特殊ファイルがある。これらは異なる目的を果たす：

**index.md** はコンテンツ指向である。wikiのすべてのもののカタログ — 各ページがリンク、1行の要約、オプションで日付やソース数などのメタデータとともにリストされている。カテゴリ別に整理されている（エンティティ、コンセプト、ソースなど）。LLMは取り込みのたびにこれを更新する。クエリに答える際、LLMはまずインデックスを読んで関連するページを見つけ、その後それらに掘り下げる。中規模（~100ソース、~数百ページ）では驚くほどよく機能し、埋め込みベースのRAGインフラストラクチャの必要性を回避する。

**log.md** は時系列指向である。何がいつ起こったかの追記限定の記録 — 取り込み、クエリ、リンティングパス。有用なヒント：各エントリーが一貫したプレフィックス（例：`## [2026-04-02] ingest | Article Title`）で始まる場合、ログはシンプルなUnixツールで解析可能になる — `grep "^## \[" log.md | tail -5` で最後の5エントリーが得られる。ログはwikiの進化の時系列を提供し、LLMが最近何がなされたかを理解するのに役立つ。

## オプション：CLIツール

ある時点で、LLMがwikiをより効率的に操作するのを助ける小さなツールを構築したくなるかもしれない。wikiページ上の検索エンジンが最も明白なもの — 小規模ではindexファイルで十分だが、wikiが成長するにつれて適切な検索が必要になる。[qmd](https://github.com/tobi/qmd) は良いオプションである：マークダウンファイルのローカル検索エンジンで、ハイブリッドBM25/ベクトル検索とLLM再ランク付けをすべてオンデバイスで実行する。CLI（LLMがシェルアウトできる）とMCPサーバー（LLMがネイティブツールとして使用できる）の両方を持つ。よりシンプルなものを自分で構築することもできる — 必要に応じてLLMが単純な検索スクリプトをバイブコーディングするのを助ける。

## ヒントとコツ

- **Obsidian Web Clipper** はウェブ記事をマークダウンに変換するブラウザ拡張機能。ソースを素早くrawコレクションに取得するのに非常に有用
- **画像をローカルにダウンロード**。Obsidianの設定 → ファイルとリンクで、「添付ファイルフォルダパス」を固定ディレクトリ（例：`raw/assets/`）に設定する。その後、設定 → ショートカットで「Download」を検索し、「現在のファイルの添付ファイルをダウンロード」を見つけてホットキーに割り当てる（例：Ctrl+Shift+D）。記事をクリップした後、ホットキーを押すと、すべての画像がローカルディスクにダウンロードされる。オプションだが有用 — LLMがURLに依存するのではなく、画像を直接表示および参照できる。LLMはネイティブで1回のパスでインライン画像付きマークダウンを読み取れないことに注意 — ワラウンドは、まずテキストを読み、その後参照された画像の一部またはすべてを別々に表示して追加の文脈を得ることである。少しぎこちないが、十分に機能する
- **Obsidianのグラフビュー** はwikiの形状を見る最良の方法である — 何が何に接続されているか、どのページがハブか、どのページが孤立しているか
- **Marp** はマークダウンベースのスライドデッキフォーマット。Obsidianにはプラグインがある。wikiコンテンツから直接プレゼンテーションを生成するのに有用
- **Dataview** はページフロントマターにわたってクエリを実行するObsidianプラグイン。LLMがwikiページにYAMLフロントmatter（タグ、日付、ソース数）を追加する場合、Dataviewは動的なテーブルとリストを生成できる
- wikiはマークダウンファイルのgitリポジトリに過ぎない。バージョン履歴、ブランチ、コラボレーションが無料で得られる

## なぜこれが機能するか

知識ベースを維持する退屈な部分は、読むことでも考えることでもなく、保守である。クロス参照の更新、要約を最新に保つ、新しいデータが古い主張と矛盾する際に記録する、数十のページに一貫性を保つ。人間はwikiを放棄する — なぜならメンテナンスの負担が価値よりも速く成長するから。LLMは飽きず、クロス参照を更新することを忘れず、1回のパスで15ファイルにタッチできる。wikiはメンテナンスのコストがほぼゼロであるために維持される。

人間の役割はソースをキュレートし、分析を指示し、良質な質問をし、それがすべてを意味することについて考えることである。LLMの役割はそれ以外すべてである。

このアイデアは、Vannevar BushのMemex（1945年） — ドキュメント間の連想トラジェクトを持つ個人的なキュレートされた知識ストア — の精神と関連している。Bushのビジョンは、ウェブの現状よりも、これに近かった：プライベートで、積極的にキュレートされた、ドキュメント間の接続がドキュメント自体と同様に価値があるもの。彼が解決できなかった部分は、誰がメンテナンスを行うかであった。LLMがそれを行う。


## 注意

このドキュメントは意図的に抽象的である。これは特定の実装ではなくアイデアを記述している。正確なディレクトリ構造、スキーマの規約、ページフォーマット、ツールリング — それらすべてはあなたのドメイン、あなたの好み、選択したLLMに依存する。上記で言及されたものはすべてオプションでモジュール式である — 有用なものをピックアップし、そうでないものは無視する。例：ソースがテキストのみの場合、画像処理は全く不要である。wikiが十分に小さく、indexファイルだけで十分なら、検索エンジンは不要である。スライドデッキに興味がなく、マークダウンページだけ望むかもしれない。全く異なる出力フォーマットのセットを望むかもしれない。これを使用する正しい方法は、あなたのLLMエージェントと共有し、あなたのニーズに合うバージョンを一緒に構築することである。ドキュメントの唯一の役割はパターンを伝えることである。あなたのLLMが残りを見つけ出すことができる。