知識は「検索するもの」から「育てるもの」へ

AIによる文書検索といえばRAG（Retrieval-Augmented Generation）が定番だ。ファイルをアップロードしてクエリを投げれば、関連チャンクを拾って回答を生成する。NotebookLM、ChatGPTのファイルアップロード、多くのRAGシステムがこの方式をとっている。

OpenAIの元研究者でAI界の著名人であるAndrej Karpathyが先日公開したアイデアファイル「LLM Wiki」は、このパラダイムに正面から疑問を投げかけている。彼の主張はシンプルで力強い。「毎回ゼロから知識を再導出するのは非効率だ。LLMに知識を積み上げさせよ」。

RAGとLLM Wikiの本質的な違い

RAGの根本的な問題は「蓄積しない」ことだ。同じ資料を何度聞かれても、LLMは毎回フラグメントをかき集めて推論する。5つの文書を横断した微妙な問いに答えるには、毎回その5文書を探して文脈をつなぎ合わせなければならない。知識は積み重ならない。

LLM Wikiはこの問題を構造から解決する。アーキテクチャは3層だ。

第1層：生の情報源（Raw Sources） 論文、記事、画像、データファイルなど。これらは不変。LLMは読み取るだけで書き込まない。

第2層：LLMが維持するWiki 相互リンクされたMarkdownファイル群。新しい情報源を追加するたびに、LLMはそれを読み込み、既存のWikiに統合する——エンティティページを更新し、トピックサマリーを改訂し、矛盾する記述を明記し、合成知識を更新する。

第3層：人間とのインタラクション ユーザーは探索と「良い問いを立てること」だけに集中する。要約、相互参照、ファイリング、整合性の維持はLLMが担う。

Karpathyの表現は示唆に富む。「ObsidianがIDE、LLMがプログラマー、WikiがCodebaseだ」。彼は実際にLLMエージェントとObsidianを並べて使い、エージェントが編集したノートをグラフビューでリアルタイムに確認しながら作業しているという。

ユースケース：個人から企業まで

Karpathyが挙げるユースケースは多岐にわたる。

  • 個人のセルフマネジメント：目標、健康、自己分析——日記、記事、ポッドキャストのノートを蓄積して自分自身の構造化された像を作る
  • リサーチ：数週間・数ヶ月かけてトピックを深堀りし、進化する論文を持つ包括的なWikiを構築
  • 読書の深化：章ごとにファイリングしてキャラクター・テーマ・伏線ページを構築。ファンWikiのTolkien Gatewayのような richness を一人で作れる
  • ビジネス・チーム：Slackスレッド、議事録、プロジェクト文書、顧客との通話を継続的にWikiに統合。誰もやりたくないメンテナンスをLLMが担う

日本のIT現場への影響

日本企業のナレッジマネジメントは、長年「書く人がいない問題」に悩んできた。Confluenceを導入してもページが更新されない、Wikiを作っても陳腐化する——これは「書くコストが高すぎる」という構造問題だ。

LLM Wiki的アプローチはこの問題に直撃する。人間が「書く」のではなく「話す・質問する」だけでWikiが育つ設計であれば、メンテナンスコストは劇的に下がる。

特に注目すべきは会議・コミュニケーションとの統合だ。Teamsの議事録やSlack的なチャットログを継続的にLLMに流し込んで、チームの知識ベースを自動的に更新し続ける構成は、今すぐ実装可能な現実解として検討に値する。

明日から試せる実践ポイント：

  • まず個人で試す：Obsidian（またはMarkdownが扱えるツール）＋LLMエージェントで、自分の読んだ技術記事や調査メモを蓄積するWikiを作り始める。週1回インプット→Wiki更新のサイクルを回すだけでも効果は出る
  • 情報源の分離を徹底する：Raw Sourcesは絶対に上書きしない設計にする。これがWikiの信頼性の根幹
  • 矛盾の明示化を活用する：「この文書は既存のWikiのどこと矛盾するか」を明示させるプロンプトを入れる。知識のアップデートで最もコストが高い作業をLLMに委ねる
  • チームWikiの試験導入：まず特定プロジェクトの議事録だけを対象に試す。全社展開より小さく始めて効果を測る

筆者の見解

このアイデアが刺さる理由は、「情報を追いかける」から「知識を育てる」へのパラダイムシフトを、具体的なアーキテクチャとして提示している点にある。

私が最近強く感じているのは、AIエージェントの真価は「一回の応答の質」ではなく「継続的なループの中でどれだけ知識と成果を積み上げられるか」にある、ということだ。LLM WikiはそのアイデアをKnowledge Managementの文脈で具現化したものといえる。エージェントが自律的に動き、判断し、構造を更新し続ける——これは単なるチャットボットとは根本的に異なる。

RAGが「図書館に都度行って調べる」なら、LLM Wikiは「賢い秘書が常に百科事典を最新状態に保ち続ける」に近い。情報量が増えるほど、一回一回の再発見コストが下がり、洞察の質が上がっていく。コンパウンド（複利）効果だ。

日本のIT現場でこれを活かすとすれば、まずチームの暗黙知の構造化だと思う。「なぜこの設計にしたのか」「あのトラブルをどう解決したか」——こうした情報は会議や1on1に埋まったまま消えていく。それをLLMが拾い上げ、構造化し、検索可能にする仕組みは、技術移転と属人化解消に直結する。

Karpathyは「自分ではWikiをほとんど書かない」と言う。これは理想の分業だと思う。人間は「何を学ぶか」「何を問うか」「何を信頼するか」という判断に集中し、ファイリングと整合性維持はエージェントに任せる。その分、考えることに使える時間と脳のリソースが増える。

ツールとしてはObsidianとLLMエージェントの組み合わせが今すぐ現実解だが、重要なのは特定ツールへの依存より「3層構造の思想」そのものだ。Raw Sourcesを不変に保つ、Wikiを永続的コンパウンドアーティファクトとして扱う——この設計原則さえ守れば、手元のツールで始められる。

情報を追いかけ続けることに疲弊しているエンジニアにとって、「蓄積する仕組みを作る」という視点の転換は、働き方そのものを変えうる可能性を秘めている。

出典: この記事は LLM Wiki – example of an “idea file” の内容をもとに、筆者の見解を加えて独自に執筆したものです。