本文へスキップ

AI活用

LLM Wikiとは、RAGやNotebookLMとの違いと3層構造

LLM Wikiとは、RAGやNotebookLMとの違いと3層構造

議事録も業務マニュアルも過去の提案書も、置き場所はバラバラのまま。ChatGPTは毎日使っているのに、社内の資料の整理にだけは手が出せていない、という方も多いはずです。

その整理をAIに任せてしまおう、という考え方が「LLM Wiki」です。覚えることは多くありません。資料を置く場所、AIが書いたページ、両者の決まりごとの3つを用意し、そこへ資料を足し、聞き、直すだけです。

LLM Wikiとは、Karpathyが公開した社内ナレッジの整理法

LLM Wikiを提唱したのは、元OpenAIの著名なAI研究者Andrej Karpathy氏です。2026年4月4日に、エンジニアが技術メモを公開する場であるGitHub Gist[3]へ投稿しました(Andrej Karpathy (GitHub Gist))。このメモにはお気に入り登録にあたるスターが5,000超付いており(2026年8月時点の表示)、公開から数か月で広く知られる存在になっています。

やることは、AIに社内資料を読ませて、人間の代わりにwikiページを書かせ、人間が点検して育てることです。手持ちのAIツールで動きます。

会議室でプロジェクトの資料を示しながら説明している場面

LLM Wikiの仕組み、3層構造でわかる人間とAIの分担

次に気になるのは「では具体的に、何を人間がやり、何をAIがやるのか」ではないでしょうか。Karpathy氏の設計では、全体が3つの層の重なりとして描かれています(Andrej Karpathy (GitHub Gist))。

人間が集める元資料の層

1層目は、議事録・マニュアル・過去提案書といった元資料をそのまま置く場所です。ここに触れるのは人間だけで、仕事は集めて置くことのみ。読みやすく整形する必要はありません。

「うちの議事録はフォーマットがバラバラだけど……」という状態でも、そのまま入れて大丈夫です。散らかった資料を並べ直す作業は、次の層でAIが引き受けます。

AIが書き続けるwikiページの層

2層目は、元資料を読んだAIがテーマごとに書くwikiページの集まり。資料が増えるたびにAIが関係するページを書き直すため、wikiは常に手持ちの資料を反映した状態に保たれます。

この層で人間がやるのは、書くことではなく点検です。AIが書いたページを読み、間違いがあれば直します。

人間とAIが一緒に育てるルールの層

3層目は、ページの書き方・名前の付け方・閲覧範囲といった決まりを書きためる層です。点検で気づいたことを人間が書き足し、AIは次からそのルールに従って書く。引き継ぎメモを、気づくたびに書き足して育てるイメージです。唯一、人間とAIの両方が触る層です。

LLM Wikiの仕組み、3層構造でわかる人間とAIの分担の図解

運用は取り込み・問い合わせ・点検の3つの操作だけ

3層の分担が整理できたところで、次は日々の運用です。「結局、担当者は毎日何をするのか」という工数の疑問に、Karpathy氏の設計は3つの操作の繰り返しという形で答えています。

取り込み、資料を足すとAIがページを書き直す

新しい議事録や資料を1層目に追加すると、AIが関係するwikiページを書き直します。原文によれば、資料1本の取り込みで10〜15ページが書き換わることもあります(Andrej Karpathy (GitHub Gist))。追加するのは人間ですが、書き直しはAIの仕事です。

問い合わせ、整理済みの知識に質問する

整理済みのwikiを前提知識にして、AIに質問します。「この取引先との過去の経緯は?」と聞けば、散らばった議事録の山ではなく、整理されたページをもとに答えが返ってくる形です。

点検、人間が直してルールに残す

人間の手間が最も集中するのが、この点検です。ページを読んで間違いを直し、直した理由を3層目のルールに書き足します。毎日張り付く必要はありません。タイミングは2つに絞れます。

  • 資料を取り込んだ直後: 書き換わったページをその場で確認する
  • 週次などの定期確認: 見落としをまとめて拾う

点検だけは省略できないので、担当者1人でも回る範囲から始めてください。直した理由がルールに積み上がると、AIは同じ間違いを繰り返しにくくなります。この積み上げこそ、次に説明するRAGとの最大の違いにつながります。

運用は取り込み・問い合わせ・点検の3つの操作だけの図解

LLM WikiとRAG・NotebookLMの違いは知識の持ち方

点検の手間をかけてまで知識を積み上げる意味は、RAGと並べると見えてきます。RAGは質問のたびに資料の山から探し直す方式、LLM Wikiは一度整理した知識を持ち続けて答える方式です。

RAGは質問のたびに探し直す

RAG(検索拡張生成)は、質問が来るたびに関連しそうな資料を検索し、その場で読んで答える仕組みです。質問されるたびに書棚から本を探して読み上げる、図書館の司書を思い浮かべてください。Karpathy氏はこの方式を「LLM[4]は毎回ゼロから知識を再発見しており、蓄積がない」と評しています(Andrej Karpathy (GitHub Gist))。

NotebookLM(現Gemini Notebook)もこの仲間です。Googleは、アップロードした資料だけを参照して回答する仕組みだと説明しています(Google)。なお同製品は2026年7月16日にGemini Notebookへ改称され、発表時点で3,000万人以上が使うと公表されています(Google)。

LLM Wikiは整理した知識を持ち続ける

一方のLLM Wikiは、AIが書いたwikiページという整理済みの知識を持ち続け、質問にはそれをもとに答えます。点検で直した結果もルールとして残るため、使うほど答えの質が積み上がる設計です。

LLM WikiとRAG・NotebookLMの違いは知識の持ち方の図解
観点 RAG・NotebookLM LLM Wiki
知識の持ち方 質問のたびに探し直す 整理した知識を持ち続ける
回答のもと その場で見つけた資料 育てたwikiページ
人間の関与 資料を置くだけ 点検して直す手間がかかる
直した結果 次の回答に残らない ルールとして積み上がる
向く場面 すぐ試したいとき 同じ質問が繰り返される業務

つまり、探し直す方式は始めるのが速く、知識を持ち続ける方式は点検の手間と引き換えに答えの一貫性が積み上がる、という関係です。「今あるやつと何が違うの?」と聞かれたら、この対比をそのまま話してください。

実運用で見えたLLM Wikiの課題、巻き戻りと重複とラベル漏れ

では、実際に業務で回すと何が起きるのか。Gistのコメント欄には、資料100本超・約200ページの規模で運用した報告が2026年8月に寄せられており、うまくいった話だけでなく問題も具体的に書かれています(Andrej Karpathy「llm-wiki」Gistコメント欄)。

人間の修正が再生成で巻き戻る

この報告でいちばん重いのが、人間が直した箇所が、次の資料を取り込んだ際の再生成で気づかれないまま元に戻る問題です。「せっかく直したのに……」が実際に起きるわけです。

備えは、直した意図を必ずルールの層に書き残すこと。この報告者も、修正の意図を記録しておき、再生成後に確認し直す運用で対処しています。

ページ名が衝突して重複ページが生まれる

約200ページ規模の報告では、一括取り込みの際にページの38%が意味的なほぼ重複になったとされています(Andrej Karpathy「llm-wiki」Gistコメント欄)。複数の資料を同時に取り込むと、同じ内容に別名のページが並行して作られてしまうためです。ページ名の付け方を最初にルール化しておくことが備えになります。

一括取り込み後のページのうち、意味的にほぼ重複していた割合を示す円グラフ

閲覧範囲ラベルの漏れは運用で防ぐ

同じ報告には、社内向け・社外向けを区別するラベルの付け誤りで、ページが見つからず重複コピーが作られた問題も書かれています。閲覧範囲の管理をAI任せにせず、見せる範囲を絞りたい機密資料は1層目に入れないという線引きを先に決めてください。

LLM Wikiは点検を省いて全自動にする道具ではなく、点検込みで回す仕組みとして工数を見積もる。課題を隠さずに書かれた実運用報告があること自体が、その判断を支えてくれます。

よくある質問(FAQ)

課題まで見えたところで、検討の場面でよく出る疑問に短く答えます。

Q. LLM Wikiを試すのに費用や専用ツールは必要ですか?

いま使っているChatGPTなどのAIツールと、資料を置くフォルダがあれば始められます。かかる費用は、AIの利用料と点検にあてる人件費だと見積もってください。

Q. 社内wikiをAIで自動生成するツールとは違うのですか?

違います。自動生成をうたうツールを使う場合でも、元資料・wikiページ・ルールの3層と、人間による点検の運用は変わらず必要になります。

Q. 機密資料をAIに読ませて大丈夫ですか?

条件付きで可能です。まず、入力データをAIの学習に使わない設定や契約(法人向けプラン)かを確認してください。そのうえで、閲覧範囲のルールづくりと、機密資料を1層目に入れない線引きが別途必要です。

自社でLLM Wikiを試すなら、どの資料から始めるべきか

ここまで読んで、全社導入の企画書より先に、まず自分の手元で試すのが近道だと感じた方も多いのではないでしょうか。その感覚のまま、小さく動き出すのが確実です。

  1. テーマを1つ選び、関連する議事録やマニュアルを手元に集める
  2. いま使っているAIツールにwikiページを書かせて、自分の目で点検する
  3. 直した内容をルールとして書き残し、点検の手間を体感してから広げるか判断する

先ほどの実運用報告も、最初からその規模で完成していたわけではありません。まず1つのテーマ分の資料を書かせ、点検の感触を掴むことから始めてください。その体験があれば、上司にも情シスにも自分の言葉で語れます。

用語の注釈

  1. RAG 質問を受けるたびに関連しそうな資料を検索し、その中身をAIに読ませて答えを作らせる仕組み。検索拡張生成の略で、ベンダーの提案書によく出てくる。
  2. NotebookLM Googleが提供する、アップロードした資料だけを参照して回答するサービス。2026年7月16日にGemini Notebookへ改称された。
  3. GitHub Gist エンジニアが短いコードやメモを公開するための場所。ファイル1枚から公開でき、閲覧に登録は要らない。
  4. LLM 大量の文章を学習して、人の言葉で受け答えするAIのこと。大規模言語モデルの略で、ChatGPTもこれにあたる。

← ブログ一覧へ