Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

LLM Wiki

LLMを活用して個人向けのナレッジベース（知識ベース）を構築するためのパターン。

これはアイデアを示すファイルです。自身のLLMエージェント（OpenAI Codex、Claude Code、OpenCode/Piなど）にコピペして使用されることを想定しています。その目的はハイレベルなアイデアを伝えることにあり、具体的な仕様はエージェントがあなたと協力しながら構築していきます。

核心となるアイデア

多くの人が経験しているLLMとドキュメントの関わり方は、RAG（検索拡張生成）のようなものです。ファイルをまとめてアップロードし、LLMが質問の際に該当するチャンク（断片）を取得して回答を生成します。これは機能しますが、LLMは質問されるたびにゼロから知識を再発見していることになります。知識の蓄積はありません。5つのドキュメントを統合しなければならないような微妙な質問をすると、LLMは毎回該当する断片を探し出して組み合わせる必要があります。何も構築されません。NotebookLMやChatGPTのファイルアップロード、そしてほとんどのRAGシステムはこのように動作します。

ここでのアイデアは異なります。クエリの実行時に生のドキュメントから検索するだけではなく、LLMが永続的なWikiを段階的に構築・維持します。これはあなたと生のソースの間に位置する、構造化され相互にリンクされたMarkdownファイルのコレクションです。新しいソースを追加したとき、LLMは単にそれを後で検索できるようにインデックス化するだけではありません。それを読み込み、重要な情報を抽出し、既存のWikiに統合します。エンティティのページを更新し、トピックの要約を改訂し、新しいデータが古い主張と矛盾する箇所を指摘し、進化する統合（シナジー）を強化または検証します。知識は一度コンパイルされ、その後常に最新の状態に保たれます。クエリごとに再導出されることはありません。

これが決定的な違いです。Wikiは永続的で、複利的に価値を高めていく成果物（アーティファクト）です。 相互参照はすでに存在しています。矛盾点はすでにフラグが立てられています。要約には、これまでに読んだすべての内容がすでに反映されています。Wikiは、ソースを追加するたびに、また質問をするたびに、より豊かになっていきます。

あなた自身がWikiを書くことは（ほとんど）ありません。LLMがすべてを記述し、維持します。あなたの役割は、ソースの選定、探索、と適切な質問をすることです。LLMはすべての雑用を担当します。要約、相互参照、ファイルの分類、帳簿付けなど、ナレッジベースを長期にわたって実際に役立つものにするための作業です。実際、私は片側にLLMエージェントを開き、もう片側にObsidianを開いています。会話に基づいてLLMが編集を行い、私はその結果をリアルタイムで閲覧します。リンクをたどり、グラフビューを確認し、更新されたページを読みます。ObsidianがIDEであり、LLMがプログラマーであり、Wikiがコードベースです。

これはさまざまな文脈に適用できます。いくつかの例を挙げます：

  • 個人用途: 自身の目標、健康、心理、自己改善の追跡。日記のエントリ、記事、ポッドキャストのメモなどを整理し、長期にわたって自分自身の構造化された像を構築します。
  • 研究: 数週間から数ヶ月にわたって特定のテーマを深く掘り下げる。論文、記事、レポートを読み、進化する仮説とともに包括的なWikiを段階的に構築します。
  • 読書: 読み進めながら各章を整理し、登場人物、テーマ、プロットのつながり、そしてそれらがどう関連しているかのページを構築します。読み終わる頃には、豊かな読書コンパニオンWikiができあがっています。例えば、Tolkien Gateway のようなファンWikiを想像してください。有志のコミュニティが何年もかけて構築した、キャラクター、場所、出来事、言語などを網羅する数千の相互リンクされたページです。読書をしながら、LLMにすべての相互参照とメンテナンスを任せることで、これに類するものを個人用に構築できます。
  • ビジネス／チーム: LLMによって維持される社内Wiki。Slackのスレッド、会議の書き起こし、プロジェクト文書、顧客との通話などをインプットとします。人間が更新内容を確認するプロセスを挟むことも可能です。チームの誰もがやりたがらないメンテナンス作業をLLMが代行するため、Wikiは常に最新の状態に保たれます。
  • 競合分析、デューデリジェンス、旅行計画、講義ノート、趣味の深掘りなど、長期にわたって知識を蓄積し、バラバラにするのではなく整理しておきたいあらゆる状況に適用できます。

アーキテクチャ

3つのレイヤーで構成されます：

生のソース（Raw sources） — 厳選されたソースドキュメントのコレクション。記事、論文、画像、データファイルなど。これらは不変（イミュータブル）であり、LLMはここから読み込みますが、決して変更しません。これがあなたの信頼できる唯一の情報源（Source of truth）です。

Wiki — LLMが生成したMarkdownファイルのディレクトリ。要約、エンティティのページ、コンセプトのページ、比較、概要、統合など。LLMがこのレイヤーを完全に管理します。ページの作成、新しいソース到着時の更新、相互参照の維持、すべての整合性の維持を行います。あなたが読み、LLMが書きます。

スキーマ（Schema） — Wikiがどのように構造化され、どのような規約があり、ソースの取り込み、質問への回答、またはWikiのメンテナンスを行う際にどのようなワークフローに従うべきかをLLMに伝えるドキュメント（例えば、Claude Codeの場合は CLAUDE.md、Codexの場合は AGENTS.md）。これは重要な設定ファイルであり、LLMを一般的なチャットボットではなく、規律あるWikiの管理者にするためのものです。あなたとLLMは、対象の領域で何が効果的かを見極めながら、これを長期にわたって共同で進化させていきます。

オペレーション（操作）

インジェスト（取り込み）。 生のコレクションに新しいソースを投入し、LLMに処理を指示します。ワークフローの例：LLMがソースを読み、あなたと重要な要点を議論し、Wikiに要約ページを作成し、インデックスを更新し、Wiki全体の関連するエンティティやコンセプトのページを更新し、ログにエントリを追加します。1つのソースが10〜15のWikiページに影響を与えることもあります。個人的には、ソースを1つずつ取り込んで自身も関与し続けることを好みます。要約を読み、更新を確認し、どこを強調すべきかをLLMに指示します。しかし、あまり監視せずに多くのソースを一度にバッチ処理で取り込むことも可能です。あなたのスタイルに合ったワークフローを開発し、今後のセッションのためにスキーマに文書化しておくのはあなた次第です。

クエリ（質問）。 Wikiに対して質問を行います。LLMは関連するページを検索し、それらを読み、引用付きの回答を統合します。回答は、質問に応じて、Markdownページ、比較表、スライドデック（Marp）、チャート（matplotlib）、キャンバスなど、さまざまな形式を取ることができます。重要な洞察として、優れた回答は新しいページとしてWikiに書き戻すことができるという点があります。あなたが求めた比較、分析、発見したつながりなどは価値があるものであり、チャット履歴の中に消え去るべきではありません。これにより、取り込んだソースと同様に、あなたの探索結果もナレッジベースに蓄積されていきます。

リント（検証）。 定期的に、LLMにWikiの健全性チェック（リント）を依頼します。チェック内容：ページ間の矛盾、新しいソースによって古くなった主張、リンクされていない孤立したページ、言及されているが個別のページがない重要な概念、不足している相互参照、ウェブ検索で補完できるデータのギャップなど。LLMは、調査すべき新しい質問や、探すべき新しいソースを提案するのが得意です。これにより、Wikiが成長しても健全な状態が維持されます。

インデックスとロギング

Wikiが成長するにつれて、LLM（およびあなた）がWiki内を探索しやすくするための2つの特別なファイルがあります。これらは異なる目的を持ちます：

index.md はコンテンツ指向です。Wiki内のすべてのカタログであり、各ページがリンク、1行の要約、そしてオプションで日付やソース数などのメタデータとともにリストされています。カテゴリ（エンティティ、コンセプト、ソースなど）ごとに整理されています。LLMはインジェストのたびにこれを更新します。クエリに回答する際、LLMはまずインデックスを読み込んで関連するページを見つけ、そこから詳細にドリルダウンします。これは中規模（ソース約100個、ページ数百枚程度）では驚くほど効果的に機能し、埋め込みベースのRAGインフラを不要にします。

log.md は時系列指向です。いつ、何が起きたか（インジェスト、クエリ、リントの実行など）を記録する追加専用（アペンドオンリー）のレコードです。役立つヒントとして、各エントリを一貫したプレフィックス（例：## [2026-04-02] ingest | 記事のタイトル）で始めると、シンプルなUnixツールでログを解析できるようになります。例えば grep "^## \[" log.md | tail -5 とすれば、最新の5つのエントリを取得できます。ログはWikiの進化のタイムラインを提供し、LLMが最近何が行われたかを理解するのに役立ちます。

オプション：CLIツール

ある時点で、LLMがWikiをより効率的に操作できるようにするための小さなツールを構築したくなるかもしれません。Wikiページに対する検索エンジンが最も明白な例です。小規模であればインデックスファイルで十分ですが、Wikiが成長するにつれて適切な検索が必要になります。qmd は良い選択肢です。これは、ローカルのMarkdownファイル用の検索エンジンで、BM25とベクトル検索のハイブリッド検索およびLLMによる再ランク付けをすべてデバイス上で行います。CLI（LLMがシェルから呼び出せる）とMCPサーバー（LLMがネイティブツールとして使用できる）の両方を備えています。必要に応じて、LLMの助けを借りてシンプルな検索スクリプトをその場しのぎで作成することも可能です。

ヒントとコツ

  • Obsidian Web Clipper は、Web記事をMarkdownに変換するブラウザ拡張機能です。ソースを素早く生のコレクションに取り込むのに非常に便利です。
  • 画像をローカルにダウンロードする。 Obsidianの設定 → 「ファイルとリンク」で、「添付ファイルのフォルダパス」を固定のディレクトリ（例：raw/assets/）に設定します。次に、設定 → 「ホットキー」で「Download」を検索し、「現在のファイルの添付ファイルをダウンロード」を見つけてホットキー（例：Ctrl+Shift+D）に割り当てます。記事をクリップした後、ホットキーを押すと、すべての画像がローカルディスクにダウンロードされます。これはオプションですが便利です。壊れる可能性のあるURLに依存する代わりに、LLMが画像を直接表示および参照できるようになります。LLMはインライン画像を含むMarkdownを一度にネイティブに読み込むことはできないため、回避策として、LLMにまずテキストを読み込ませ、その後、参照されている画像の一部またはすべてを個別に表示させてコンテキストを追加します。少し不格好ですが、十分に機能します。
  • Obsidianのグラフビュー は、Wikiの形状（何が何と接続されているか、どのページがハブで、どれが孤立しているか）を確認するのに最適な方法です。
  • Marp は、Markdownベースのスライドデック形式です。Obsidianにはそのためのプラグインがあります。Wikiのコンテンツから直接プレゼンテーションを生成するのに便利です。
  • Dataview は、ページのフロントマターに対してクエリを実行するObsidianプラグインです。LLMがWikiページにYAMLフロントマター（タグ、日付、ソース数など）を追加すると、Dataviewは動的なテーブルやリストを生成できます。
  • Wikiは単なるMarkdownファイルのGitリポジトリです。バージョンの履歴、ブランチ、コラボレーションの機能を無料で利用できます。

なぜこれが機能するのか

ナレッジベースの維持において退屈な部分は、読むことや考えることではなく、帳簿付けです。相互参照の更新、要約の最新維持、新しいデータが古い主張と矛盾する場合の指摘、何十ものページにわたる一貫性の維持。人間がWikiを放棄するのは、メンテナンスの負担が価値よりも速く増大するためです。LLMは飽きることがなく、相互参照の更新を忘れることもなく、一度の処理で15個のファイルを修正できます。メンテナンスコストがほぼゼロであるため、Wikiは常に維持されます。

人間の仕事は、ソースを厳選し、分析を指示し、良い質問をし、それが何を意味するのかを考えることです。LLMの仕事はそれ以外のすべてです。

このアイデアは、本質的にヴァネヴァー・ブッシュのMemex（1945年）に関連しています。Memexは、ドキュメント間の連想の道（トレイル）を備えた、個人向けに厳選された知識の保管庫です。ブッシュのビジョンは、現在のWebのあり方よりもこのアイデアに近かったと言えます。プライベートで、積極的に厳選され、ドキュメント間のつながりがドキュメントそのものと同じくらい価値を持つものです。彼が解決できなかったのは、「誰がメンテナンスを行うか」という点でした。LLMがそれを処理します。

注意

このドキュメントは意図的に抽象的です。特定のインプリメンテーション（実装）ではなく、アイデアを説明しています。正確なディレクトリ構造、スキーマの規約、ページのフォーマット、ツールなどは、すべて対象のドメイン、あなたの好み、そして選択するLLMに依存します。上記で言及されたものはすべてオプションでありモジュール式です。役立つものを選択し、そうでないものは無視してください。例えば、ソースがテキストのみであれば、画像の取り扱いはまったく不要です。Wikiが十分に小さければインデックスファイルだけで事足り、検索エンジンは不要です。スライドデックに関心がなければ、単にMarkdownページだけで構いません。まったく異なる出力フォーマットが必要な場合もあるでしょう。これを使用する正しい方法は、あなたのLLMエージェントと共有し、ニーズに合ったバージョンを協力してインスタンス化することです。このドキュメントの唯一の役割は、パターンを伝えることです。残りの部分はあなたのLLMが解決できます。