元ネタ:AI研究者アンドレイ・カルパシー氏が公開したアイデアメモ(GitHub Gist)。LLM(AIアシスタント)に自分専用の「育っていく百科事典」を作らせる方法について。
1. 核心のアイデア
- 多くの人がAIと資料を使う方法は「RAG」と呼ばれるやり方。例えるなら、宿題のたびに図書館へ行って、その場で関係ありそうな本を探して読み直すようなもの。毎回ゼロから探すので、知識が積み上がらない
- 5つの資料をまたぐ質問をすると、AIはその都度5つを探して組み合わせ直す。何も「蓄積」されない
- カルパシー氏の提案はこれと違う。AIに「まとめノート(Wiki)」を持たせ、資料を読むたびにそのノートを書き足し・書き直しさせるというやり方
- 新しい資料が来たら、AIはただ検索用に索引を作るだけでなく、内容を読み込んで重要な部分をまとめノートに統合する
- 人物・用語のページを更新し、全体の要約を書き直し、古い情報と矛盾する新情報が来たら「ここが食い違っています」と印をつける
- 一度まとめた知識は、質問のたびに再構築するのではなく、常に最新の状態で待っている
- **このノートはほぼ全部AIが書く。**人間が書くことはまずない
- 人間の役割:どの資料を読むか選ぶ・調べる・良い質問をする
- AIの役割:要約・相互リンク・整理・記録という面倒な作業を全部やる
- 実際の作業スタイルは「片方の画面にAI、もう片方にObsidian(ノートアプリ)」。Obsidian=作業机、AI=書記係、まとめノート=完成していく資料集、というイメージ
2. 使いみちの例(記事内で挙げられていたもの)
- 個人の記録:目標・体調・気持ちなどを記録し続け、日記や読んだ記事のメモから、自分自身の姿を少しずつ形にしていく
- 調べ物・研究:数週間〜数ヶ月かけて1つのテーマを深掘りし、論文や記事を読むたびにまとめノートを育てていく
- 読書:1章読むごとに、登場人物・テーマ・筋書きのページを作っていく。読み終わる頃には、**ファンが何年もかけて作るような解説Wiki(例:指輪物語の用語辞典サイト)**が自分専用にできあがる
- チーム・会社:Slackのやり取りや会議メモ、商談記録からAIが社内Wikiを更新し続ける。誰もやりたがらない「メンテナンス」をAIが肩代わりするので、Wikiが放置されない
- 競合調査、旅行計画、授業ノート、趣味の深掘りなど、「知識を貯めたいけど、散らからせたくない」場面全般
3. 仕組み(3つの層)
| 層 | 何か | 例えるなら |
|---|---|---|
| 生の資料 | 記事・論文・画像など。AIは読むだけで絶対に書き換えない | 図書館の原本 |
| Wiki | AIが作る要約・用語ページ・比較表など。AIが完全に管理 | AIがまとめる清書ノート |
| スキーマ | Wikiの作り方・ルールをAIに指示する設定ファイル(例:CLAUDE.md) |
AIへの「仕事のマニュアル」 |
💡 このMyBrain保管庫との対応関係 これはまさに今のこの仕組みと同じ発想です。
CLAUDE.md= スキーマ(AIへのマニュアル)20_Logs/30_Resources/= Wiki(AIがまとめて育てる場所)00_Inbox/= まだ処理していない生の資料の置き場 つまり今回の記事は、既にやっていることに「LLM Wiki」という名前と裏付けが付いた、という位置づけです。
4. 日々の運用
- 資料を入れる時:AIが資料を読み、要点を話し合い、Wikiに要約ページを作り、関連する他のページも更新し、記録(ログ)に残す。1つの資料が10〜15ページに影響することもある。1件ずつ確認しながら進めるやり方と、まとめて一気に処理させるやり方、どちらも可
- 質問する時:AIがWikiの中から関連ページを探して答える。良い回答は、消えてしまう会話履歴に埋もれさせず、新しいページとしてWikiに保存すべきという点がポイント(=調べた結果自体も資産にする)
- 定期点検:「矛盾している箇所」「古くなった情報」「どこともリンクしていない孤立ページ」「大事なのに専用ページが無い用語」がないか、AIに時々チェックさせる
5. 目印になる2つのファイル
index.md:Wiki全体の目次。各ページへのリンクと一行要約の一覧。質問されたらAIはまずここを見て、関係ありそうなページに絞ってから読みに行く(=規模がそこまで大きくなければ、これだけで十分機能する)log.md:時系列の作業日誌。「いつ・何をしたか」を記録し続ける。書式を揃えておけば、後から機械的に読み返せる
6. ちょっとしたコツ(記事より)
- Obsidian Web Clipper:Webページをそのままメモ形式で保存できるブラウザの拡張機能。資料集めに便利
- 画像はローカル保存推奨:リンク切れ対策。ただしAIは「文章+挿絵入りページ」を一度には読めないので、文章→画像の順に別々に見せる工夫が必要
- グラフビュー:Wiki内の「どれとどれが繋がっているか」を目で見て把握するのに最適
- Wiki自体はただのMarkdownファイルの集まりなので、バージョン管理(Git)の恩恵(履歴・巻き戻し等)がそのまま使える
7. なぜこれがうまくいくのか
- 知識を貯める作業で本当に面倒なのは「読んで考えること」ではなく「帳簿付け」(相互参照の更新・矛盾チェック・整合性維持)
- 人間がWikiを放置してしまうのは、この帳簿付けの手間が、得られる価値より早く膨らんでいくから
- AIは飽きない・更新を忘れない・何十ページも一気に処理できるので、維持コストがほぼゼロになり、Wikiが放置されない
- 人間の仕事は「資料を選び、分析の方向を決め、良い質問をし、意味を考えること」。それ以外は全部AIの仕事、という役割分担が肝
8. 反響で挙がっていた、似た発想のツール・意見(要点のみ)
パターンに触発されて作られた・元からあった類似システムが多数コメントされていました。技術者向けのツール紹介がほとんどのため、名前と特徴だけ簡潔に:
| 投稿者 | ツール/意見 | 特徴 |
|---|---|---|
| ZeroDot1 | LLMWikiNG | セルフホスト版。検索・Web画面・知識グラフ表示・週次レポート付き |
| podviaznikov | Wander | Obsidianの保管庫を開けるMac/iOS向けノートアプリ |
| bluntbrain | (自作MCPサーバー) | チャットの中で「これをWikiに保存して」だけで完結する設計 |
| menottim | obsidian-worklog | ほぼ同時期に似た発想で独自開発していた例 |
| vijay-athithyaa-GV | llm-wiki-init | このパターンをワンコマンドで導入できるプラグイン化 |
| drjoeshepherd | SIGN(仕様) | 「文章による指示(CLAUDE.md)はAIが従わないことがある」として、機械的に検証できる厳格なルール形式を提案 |
| TABARC-Code | Deweygraph | 図書館の「日本十進分類法」的な考え方でファイルにタグ付け |
| gowtham0992 | Link v2.2 | 複数のAIツール間でメモを共有・同期する仕組み。「使われなかった記憶」も検出 |
| sturlese | Stigmergy | チーム向け。人間の承認を必須にする箇所を設計(誤情報が「会社の常識」になるのを防ぐ) |
| 1wgrumph | BRAN | 埋め込み検索を使わず、frontmatterだけで知識グラフ的に検索できるようにするツール |
| frankchu91 | MindBase v2 | 無料のローカルAIモデルだけで動作。AIが勝手に書き換えず、必ず人が承認する設計 |
| SinghAbhinav04 | OmniMemory | プログラムのコード用。コードが変わったら記憶が古くなったと検知 |
| coder-jeffery | (懸念) | 資料が膨大になると、結局AIが一度に読める量を超えて破綻するのでは、という指摘 |
| AbleVarghese | Provenance-First-Wiki | 数ヶ月検証した結果、約1000ファイルを超えると破綻し始めると報告。原因と対策も提示 |
| ednawnika | Vigil | Wikiに「知識」だけでなく「決めたこととその根拠」も持たせ、根拠が崩れたら再検討を促す発展形 |
| One4Shell | llm-wiki-skill | このパターンをコマンド1つで導入できる「スキル」として配布 |
| JanYork | LWC | データベースを正本にしつつ、人が読めるWikiは自動生成される形式 |
| H179922 | (紹介のみ) | Obsidianの保管庫を知識グラフとして可視化するツール |
| lichuang | docq | ローカルで動く検索エンジン。今後Wiki生成にも対応予定とのこと |