「AIを第二の脳にする」LLM-wikiという設計思想(ノートを取るのをやめて、一緒に編纂する)

「AIを第二の脳にする」LLM-wikiという設計思想(ノートを取るのをやめて、一緒に編纂する)

「AIを第二の脳にする」という言い方を、最近よく見かける。だが、その中身を具体的に説明できる記事は意外と少ない。

この記事では、比喩の一歩先にある具体的な設計図「LLM-wiki」というパターンを紹介します。

Obsidianのメモをまとめて読ませる、ChatGPTに日々の記録を渡す。そうした運用の紹介記事は増えている。ただ、その中身を覗くと、多くは「AIが思考のパートナーになる」という比喩の一歩先に進んでいない。

具体的に何を、どう保存すれば、AIは本当に第二の脳として機能するのか。この問いには、名前のついた設計図がすでにある。LLM-wikiと呼ばれるパターンだ。

この連載では、その設計を実際の研究業務でどう運用しているかを、これから数回に分けて書いていく。今回はまず、前提となる考え方を1つ紹介する。

目次

クエリのたびに探す方式の限界

生成AIに自分の持っている情報を参照させる仕組みとして広く知られているのが、RAG(検索拡張生成)だ。質問が来るたびに関連しそうな文書を検索し、それをもとに回答を生成する。

RAGは便利だが、構造上の弱点がある。質問のたびに生の断片を拾ってきて、その場でモデルに解釈させ直す必要があるからだ。同じような質問が繰り返されるたびに、同じような統合作業をゼロからやり直すことになる。情報量が増えるほど、検索でうまく拾えないものや、拾えても文脈が浅いものが増えていく。

取り込み時点で編纂してしまうという発想の転換

これに対し、AI研究者のAndrej Karpathy氏が提唱したとされる「LLM Wiki」というパターンは、発想がまったく逆だ。質問が来るたびに情報を探すのではない。情報が入ってきた時点でLLM自身がそれを編纂し、永続的なMarkdownとして残しておく(intelligentliving.co、VentureBeatの紹介記事による)。

具体的には3つの層に分けて考える。

LLM-wikiの3層構造:Raw層(書き込み専用の原資料)、Wiki層(LLMが整理し相互リンクしたMarkdownページ)、Schema層(編纂のルール)、そしてLintパスによる定期チェック

  • Raw層:書き込み専用の原資料。実験ログ、論文、メモなど、加工前の生データをそのまま置いておく
  • Wiki層:Raw層の情報をLLMが整理し、相互にリンクしたMarkdownページとして書き直したもの
  • Schema層:どんなメタデータを必須にするか、どうリンクを付けるか、といった編纂のルール

さらに、この構成には「Lintパス」という考え方が組み込まれている。矛盾した記述、古くなった数値、リンクされていない孤立ページがないかを定期的にチェックする、メンテナンス用の巡回だ。プログラムのユニットテストに近い。

計算の負荷を、質問が来た瞬間から情報を取り込む瞬間へ前倒しする。これがLLM-wikiの核心だ。一度きちんと整理しておけば、そのあと何度質問されても、AIは統合済みの情報をそのまま参照できる。

LLM-wikiにも向き不向きがある

もちろん、この方式が常に優れているわけではない。ソースの量が膨大で、かつ常に最新の情報が必要な場合はどうか。たとえばニュース速報や株価のような、リアルタイム性が命の情報である。こうした場面では、従来のRAGの方が向いている。大規模な文書に対する検索コストの方が、都度の編纂コストより安いこともある。

LLM-wikiが強いのは逆の場面だ。個人や小規模チームが持つ、比較的安定した知識(研究のノウハウ、過去の判断、蓄積されたルール)を長く使い続けるときに効いてくる。

3層をそのまま置いてみて詰まったところ

断っておくと、この設計は自分で考えついたものではない。Karpathyのパターンとして紹介された記事を読み、そこから借りてきた。それまでは実験ログも気づきも同じ場所に溜め込み、AIに読ませるたびに前提の説明をやり直していた。編纂を取り込みの時点へ前倒しするという順序の入れ替えは、そのまま手元の不満への答えに見えた。

ところが、3層をそのまま自分の研究業務に置いてみると、うまく回らなかった。Raw層に実験ログと拾ってきた論文を一緒に放り込むと、後から見たときにどれが自分の観測でどれが他人の主張なのか分からなくなる。Wiki層はもっと厄介だった。LLMが整理した事実と、自分がまだ迷っている解釈が、同じページに同居してしまう。あとで覆すかもしれない仮説を、確定した事実と同じ顔で参照されるのは困る。

そこで、借りた骨格に手を入れた。

  • Raw層はドメインではなく形式別(Web記事、PDF、メモ)に分ける。何の話題かの分類は、整理する側の仕事にする
  • Wiki層には事実だけを置く。裏の取れた記述と出典しか入れない
  • 自分の解釈や仮説は別の層に逃がす。記事や資料の下書きも、さらに別の層に分ける

そのうえで、層ごとにLLMの書き込み権限を変えた。Raw層は読むだけで書き換えさせない。事実の層は自由に書かせる。解釈と下書きの層は、自分が確認しない限り保存させない。

Karpathyの3層が示しているのは骨格であって、どこに線を引くかは扱う情報の性質で変わる。研究のノウハウを何年も使い続けるつもりなら、事実と解釈のあいだに線を引いておかないと、あとで困るのは自分だ。

あたま

設計図は借り物ですが、そのまま使える借り物ではありませんでした。手元で崩れたところを直しているうちに、層が2つ増えていた、というのが正直なところです。

では、実際にこの考え方をどう運用しているのか。研究データが「あるのに使えない」という状態に、なぜ陥っていたのか。次回は、その具体的な話から始める。

なお、この骨格を提唱したKarpathy自身は、2026年5月にAnthropicへ移籍し「AIにナレッジを編纂させる」から一歩進んだ「AIに研究プロセスそのものを担わせる」という再帰的自己改善に挑んでいる。その後の進捗と壁については「LLM Wiki」提唱者Karpathyが、Anthropicで「AIに自分自身を改善させる」に挑む理由で扱った。

関連記事

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!
個別のご相談を受け付けています

生成AI活用やナレッジ基盤づくりについて、実務経験をもとに個別のご相談を承っています。ご興味があれば覗いてみてください。

note.comでは、実際の構築事例をより詳しく書いた有料記事も公開しています。→ 有料記事のご紹介を見る

この記事を書いた人

本業で生成AIの活用法を研究し、実装・社内への導入推進を担当。属人化しがちなノウハウをどう言語化し、チームの資産にするかに関心があります。このラボでは、ナレッジ・生成AIツール・実践ワークフロー・データサイエンスの4領域で検証したことを記録しています。姉妹サイト「なないろ日和」では育児や暮らしについても書いています。

コメント

コメントする

目次