LLMを使用して個人の知識基盤を構築するためのパターン。
これはアイデアファイルであり、自分のLLMエージェントにコピーペーストするように設計されています(例: OpenAI Codex、Claude Code、OpenCode/Pi、など)。その目的は高レベルのアイデアを伝えることですが、エージェントはあなたと協力して詳細を構築します。
LLMやドキュメントに関するほとんどの人の経験はRAGのように見えます。ファイルのコレクションをアップロードし、LLMはクエリ時に関連するチャンクを取得し、回答を生成します。これは効果があるが、LLMはあらゆる質問に対して一から知識を再発見している。蓄積はない。5つの文書を合成する必要があるさりげない質問をすれば、LLMは毎回関連する断片を見つけ、つなぎ合わせなければならない。何も積み重ならない。NotebookLM、ChatGPTファイルのアップロード、およびほとんどのRAGシステムはこの方法で動作します。
ここでの考えは異なる。クエリ時に生の文書から単に取得するのではなく、LLMは永続型のWikiを組み込みおよび維持します。これは、あなたと生のソースの間にある、体系的で相互に連動したマークダウンファイルの集合体です。新しいソースを追加すると、LLMは後で検索するためにインデックスを作成するだけではありません。読み取り、主要な情報を抽出し、既存のWikiに統合します。つまり、エンティティページの更新、トピックの要約の修正、新しいデータが従来の主張と矛盾する点、進化する統合の強化または挑戦の点に言及します。知識は一度コンパイルされると、クエリごとに再取得されるのではなく、常に最新の状態に保たれます。
これが主な違いです。Wikiは永続的で複利的なアーティファクトです。 クロスリファレンスはすでに存在します。矛盾はすでに指摘されている。合成はすでにあなたが読んだすべてのものを反映しています。Wikiは、追加するソースや質問のすべてを通じて、ますます豊かになります。
Wikiを自分で書くことは(あるいはめったにしない)ことは一度もない。LLMはそのすべてを書き、維持している。調達、探索、適切な質問を担当しています。LLMは、要約、相互参照、届出、および簿記といったあらゆる作業を行い、知識基盤を長期的に実際に役立つものにしている。実際には、私はLLMのエージェントを一方の側に、オブシディアンをもう一方の側に開いてもらう。LLMは会話をもとに編集を行い、結果をリアルタイムで閲覧します。リンクをたどり、グラフの表示を確認し、更新されたページを読みます。ObsidianはIDEであり、LLMはプログラマーであり、Wikiはコードベースである。
これはさまざまな文脈に当てはまる可能性があります。いくつかの例:
- 個人向け: 自身の目標、健康、心理学、自己啓発――日記の掲載、記事、ポッドキャストのメモを提出し、時間とともに自分自身の体系的なイメージを築くこと。
- リサーチ: 数週間から数か月にわたり、論文や記事、レポートを読み、進化する論文とともに包括的なWikiを段階的に構築するというテーマを深く取り上げています。
- 本を読む: 各章を書きながら、文字、テーマ、プロットスレッド、および接続方法のページを作成する。最終的には、豊かなコンパニオンWikiを手に入れます。ファンWikiトールキン・ゲートウェイを思い浮かべてください。何年にもわたって、ボランティアのコミュニティによって構築された、文字、場所、イベント、言語を網羅した数千のリンクが付いたページです。読むたびに、LLMがクロスリファレンスとメンテナンスを行うことで、そのようなものを個人的に構築できます。
- ビジネス/チーム: LLMが管理する内部Wiki。Slackスレッド、会議用の成績表、プロジェクト文書、顧客からの電話がフィードされます。人間が最新情報をレビューしている可能性がある。Wikiは、チームの誰もやりたくないメンテナンスをLLMが行っているため、現在も最新の状態が保たれています。
- 能動的な分析、デューデリジェンス、旅行計画、コースノート、趣味の深遠なアドバイスなど: 時間とともに知識を蓄積し、分散させるのではなく整理されたいもの。
3つのレイヤから構成されています:
Raw sources — 厳選された資料のコレクション。記事、論文、画像、データファイル。これらは不変である――LLMはそれらから読み取るが、決して変更しない。これがあなたの真実の源です。
The wiki - LLMが生成したマークダウンファイルのディレクトリ。要約、エンティティページ、コンセプトページ、比較、概要、合成。LLMはこの層を完全に所有している。ページを作成し、新しいソースが到着したときに更新し、クロスリファレンスを維持し、すべてを一貫性に保ちます。読んだり、LLMが書いたり。
The schema — ドキュメント(例: CLAUDE.md for Claude Code または AGENTS.md for Codex) は、LLM にWikiの構造、規約の内容、およびソースの取り込み、質問への回答、またはWikiの保守時にどのようなワークフローを実行すべきかを指示します。これは重要な設定ファイルであり、LLMを一般的なチャットボットではなく、規律正しいWikiのメンテナーにしている。あなたとLLMは、ドメインに何が有効かを判断する際に、時間の経過とともにこれを共同で進めていきます。
Ingest. 新しいRawソースをコレクションに追加し、LLMに処理するように指示します。フローの例としては、LLMがソースを読み込み、重要なポイントについてあなたと話し合い、Wikiに要約ページを作成し、インデックスを更新し、Wiki全体で関連するエンティティと概念のページを更新し、ログにエントリを追加します。1つのソースが10～15のWikiページに影響を与える可能性があります。個人的には、ソースを1つずつ取り込み、関与し続けることを好みます。要約を読み、更新を確認し、LLMに強調すべき点を指示します。しかし、監視を少なくして、一度に多くのソースをバッチで取り込むこともできます。自分のスタイルに合ったワークフローを開発し、今後のセッションのためにスキーマに文書化するのはあなた次第です。
Query. Wikiに対して質問を投げかけます。LLMは関連ページを検索し、読み込み、引用を含む回答を生成します。回答は質問に応じて、マークダウンページ、比較表、スライドデッキ（Marp）、グラフ（matplotlib）、キャンバスなど、さまざまな形式をとることができます。重要な点は、優れた回答は新しいページとしてWikiに保存できるということです。あなたが求めた比較、分析、発見した関連性などは貴重な情報であり、チャット履歴に埋もれてしまうべきではありません。このようにして、あなたの探求は、取り込まれた情報源と同様に、知識ベースの中で蓄積されていきます。
Lint. 定期的に、LLMにWikiの健全性チェックを依頼してください。チェック項目は、ページ間の矛盾、新しい情報源によって置き換えられた古い主張、リンクのない孤立ページ、言及されているにもかかわらず専用ページがない重要な概念、欠落している相互参照、ウェブ検索で埋められるデータギャップなどです。LLMは、調査すべき新たな疑問や探すべき新たな情報源を提案するのが得意です。これにより、Wikiは成長しながらも健全な状態を保つことができます。
2つの特別なファイルが、LLM(およびあなた)がWikiの成長に合わせてナビゲートするのに役立ちます。それらは異なる目的を果たします:
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が最近行ったことを理解するのに役立ちます。
いつかは、LLMがWiki上でより効率的に動作するよう支援する小さなツールを開発したいかもしれません。Wikiページ上の検索エンジンが最も目立つものであり、規模が小さいほどインデックスファイルは十分ですが、Wikiが成長するにつれて適切な検索が求められます。qmdは優れた選択肢です。これは、BM25/vector検索とLLMの再ランキングを組み合わせたローカル検索エンジンで、すべてデバイス上で表示されます。CLI(LLMが処理できるように)とMCPサーバーの両方を備えています(そのため、LLMはネイティブツールとして使用できます)。自分でもっとシンプルなものを作ることもできます。LLMは、必要に応じて、不気味な検索スクリプトを視覚化するのに役立ちます。
- Obsidian Web Clipper Webの記事をmarkdownに変換するブラウザ拡張機能です。原材料をすぐに収集するのに非常に便利です。
- 画像をローカルにダウンロード Obsidianの「設定」 → 「ファイルとリンク」で、「Attachment フォルダーパス」を固定ディレクトリ(例:
raw/assets/)に設定します。次に、「設定」 → 「ホットキー」で「ダウンロード」を検索して「現在のファイルの添付ファイルをダウンロード」を見つけ、ホットキーにバインドします(例:Ctrl+Shift+D)。記事をクリップした後、ホットキーを押すと、すべての画像がローカルディスクにダウンロードされます。これは任意ですが便利です。LLMがURLに依存するのではなく、画像を直接表示および参照できます。LLMは1回のパスでインライン画像でマークダウンをネイティブに読み取ることはできません。回避策として、LLMにまずテキストを読み取り、その後、参照している画像の一部またはすべてを個別に表示して、追加のコンテキストを取得することです。少し不器用だけど、十分にうまく機能している。 - Obsidian graph view Wikiの形、つまり何と何がつながっているか、どのページがハブで、どのページが孤児であるかを確認する最良の方法です。
- Marp マークダウンベースのスライドデッキフォーマットです。Obsidianにはプラグインがあります。Wikiのコンテンツから直接プレゼンテーションを生成するのに便利です。
- Dataview ページのfrontmatter上でクエリを実行するObsidianプラグインです。LLMがWikiページ(タグ、日付、ソース数)にYAMLのフロントマターを追加した場合、Dataviewは動的テーブルとリストを生成できます。
- Wikiは単なるマークダウンファイルのGitリポジトリです。バージョン履歴、ブランチング、コラボレーションを無料で利用できます。
知識基盤を維持する上で退屈な部分は、読書や思考ではなく、帳簿記にすぎない。クロスリファレンスの更新、要約の最新性、新しいデータが古い主張と矛盾する場合の注意点、数十ページにわたる一貫性の維持。人間がWikiを放棄するのは、メンテナンス負担が価値よりも速く増大するからである。LLMは飽きず、クロスリファレンスを更新するのも忘れずに、1回のパスで15個のファイルをアタッチできます。Wikiはメンテナンスコストがほぼゼロに近いため、引き続き維持されています。
人間の仕事は、情報源をキュレーションし、分析を指示し、良い質問をし、それが何を意味するのかを考えることである。LLMの仕事はその他すべてです。
この考え方は、文書の間隔を挟んだアソシティブ・トレイルを備えた、個人向けでキュレーションされた知識ストアであるヴァンネヴァー・ブッシュの『メメックス』(1945年)と精神的に関係している。ブッシュのビジョンは、ウェブがどのようなものになったかよりも、文書間のつながりが文書そのものと同じくらい貴重なものを持つ、プライベートで積極的にキュレーションされたものとは、これに近いものだった。彼が解決できなかったのは、誰がメンテナンスを行うかだった。LLMがそれを処理します。
この文書は意図的に抽象的な書き方をしています。特定の実装ではなく、そのアイデアを記述します。正確なディレクトリ構造、スキーマ規約、ページ形式、ツール作成など、これらすべては、ドメイン、好み、および選択したLLMによって異なります。上記のすべては任意でモジュール式です。便利なものを選び、そうでないものを無視してください。たとえば、ソースはテキストのみである可能性があるため、画像処理はまったく必要ありません。Wikiが十分に小さいため、必要なだけインデックスファイルが必要なだけの可能性があります。検索エンジンは必要ありません。スライドデッキのことは気にせず、ただマークダウンページが欲しいだけかもしれません。まったく異なる出力フォーマットのセットが必要になるかもしれません。これを適切な方法で活用するには、LLMエージェントと共有し、自分のニーズに合ったバージョンをインスタンス化するために連携する方法があります。文書の唯一の仕事は、パターンを伝えることである。LLMは残りを把握できます。