LLM Wiki：新しいAIナレッジアーキテクチャを理解する

LLM Wikiは、取り込み時にソースを永続的で相互リンクされたナレッジベースに編成し、そのベースから回答します。毎回生のチャンクを再取得するのではありません。これにより、質問のたびにゼロから組み立て直すのではなく、ソースを追加するたびに知識が蓄積されていきます。

ここでは、LLM Wikiという発想がどこから生まれたのか、RAG（Retrieval-Augmented Generation）とどう違うのか、そしてAIシステムの知識管理のあり方を本当に転換するのかを解説します。

LLM Wiki 概念の起源

LLM Wikiのアイデアは2026年にAndrej Karpathyによって提示され、いくつかのオープンソースプロジェクトが実行可能な形に落とし込みました。

発想はシンプルです。2026年のAIシステムは、同じ文書を何度も読み返すことに多くの時間を費やしています。PDFをアップロードすると、モデルがチャンクを取得して質問に答え、そこで終わり。翌週、同じテーマの別のPDFをアップロードすると、モデルはまったく同じことを繰り返します。何も引き継がれません。

最大の転換点は、「検索」と「編纂」が別の仕事だということです。

例えば：

• 検索優先のシステムは、クエリ時に関連するテキスト断片を見つけてモデルにコンテキストとして渡します。モデルは、検索器が引っ張ってきたものだけで対応します。
• 編纂優先のシステムは、取り込み時に各ソースを一度だけ読み、重要事項を抽出して構造化されたナレッジベースに書き込みます。モデルはそのベースから回答します。

LLM Wikiは後者に属します。新しいソースを追加すると、モデルがそれを読み、既存ページを更新し、必要に応じて新規ページを作成し、既存の内容と矛盾する箇所にフラグを立てます。ソースを加えるたびにナレッジベースが成長し、モデルはより良い土台から回答できるようになります。

これは、標準となったRAGが支配してきた検索優先パラダイムからの最初の具体的な決別です。RAGは各クエリを、生の文書に対する新規の照会として扱います。LLM Wikiは取り込み時を作業の本番と捉え、クエリ時は既に吟味されたベースを読むだけにします。

LLM Wikiとは？

LLM Wikiは、ソース文書からの情報を継続的に統合し、構造化され相互接続されたページとして蓄える、AIが維持する永続的なナレッジベースです。

フォルダに入ったファイルやベクトルストアと異なる点が3つあります。

• 永続性： ページは一度作成され、新しいソース到着に応じて更新されます。合成はすでに書き留められているため、クエリ時に再導出する必要はありません。
• 継続的更新： 取り込むたびにウィキ全体で編集が走ります。新しい実体のページ作成、既存要約の改訂、新データが古い主張と矛盾する箇所への注記など。
• 二重の読者： 人間が読める一方で、AIエージェントが推論できるだけの構造も備えます。Markdown、相互リンク、統一レイアウトが両方に効きます。

要は、ウィキが一次の知識レイヤーになるという転換です。元文書は監査用の生データとして保管されますが、直接問い合わせることはありません。チャット、エージェント、リサーチアシスタントは、編纂済みで相互参照可能な知識が置かれているウィキを読みます。

LLM Wikiのアーキテクチャ

このアーキテクチャは3段階のパイプラインに近いものです。ソースが入り、モデルがウィキページに編纂し、AIアプリケーションがそれを読みます。

LLM Wikiのアーキテクチャ

各段階を順に説明します。

ソース文書

テキストベースなら何でも取り込めます。例えば：

• ドキュメントやPDF
• 個人メモや会議の文字起こし
• コードリポジトリ
• 記事からのクリップやサイトからのスクレイプなどのWebコンテンツ

生のソースは不変ストレージに置かれます。一度取り込まれたら、モデルはそれを読みますが決して変更しません。これにより、ウィキ上のあらゆる主張を元ソースに遡れる明確な監査経路が得られます。

知識の編纂

ここでウィキが作られます。新規ソースが到着すると、モデルは以下の処理を行います。

• 概念の抽出： 実体、トピック、定義、主張をソーステキストから抽出します。
• 既存ページの更新： 既にページがある実体や概念は、新情報で改訂し、矛盾をフラグ付けします。
• 新規ページの作成： 既存ページに収まらないものは独立ページにします。
• 関連トピックのリンク付け： 相互参照を双方向に追加し、ウィキの成長に合わせてページ同士をつなぎます。

1つのソースを取り込むだけで、10〜15ページが「更新」されることもあります。これが狙いです。新規素材と既存知識の接続作業を、RAGのように毎回のクエリでなく、取り込み時に一度だけ行うのです。

AIアプリケーション

ウィキは複数の読み手を想定して設計されています。例えば：

• チャットシステム：生文書ではなく編纂済みの知識に対して質問に答えます。
• リサーチアシスタント：相互参照を辿ってトピックの全体像を構築します。
• ソフトウェアエージェント：長期タスクにわたる耐久メモリとしてウィキを使います。
• エンタープライズ知識システム：社内ツールやダッシュボード、または MCPサーバー にウィキを公開します。

ウィキは中核に位置します。片側からソースが流入し、反対側からアプリケーションが読み取り、編纂レイヤーが両端の同期を保ちます。

LLM Wiki と従来型RAGの比較

従来のRAGとLLM Wikiの主な違いは、作業が行われるタイミングです。

従来型RAG

RAGはクエリ時に文書チャンクを取得します。質問を投げると、ベクトルストアから埋め込み検索で上位k件の関連チャンクが引かれ、質問と共にモデルのコンテキストに追加されます。モデルはその一時的なコンテキストから回答を生成し、返答が終わるとすべてを忘れます。

コンテキストは使い捨てです。

直前の質問に答えたチャンクは、モデルの返信が終わった瞬間にコンテキストから消えます。翌日関連質問をすれば、検索器がまた走り、チャンクをまた引いて、モデルがまた合成します。クエリ間で積み上がるものはありません。

LLM Wiki

LLM Wikiは取り込み時に情報を編纂します。ソースを追加すると、モデルは一度だけ読み、重要事項を構造化ページに書き込み、相互参照を更新し、その結果を耐久的なMarkdownとして保存します。クエリ時は、生のチャンクから再合成するのではなく、編纂済みベースを読むだけになります。

知識は永続し、進化します。

新しいソースが来るたびにウィキ全体で編集が走るため、矛盾にフラグが立ち、古い要約は改訂され、トピック間の結びつきは時間とともに密になります。

トレードオフ

どちらが常に優れているというものではありません。重視するものが異なります。

留意点をいくつか挙げます：

• 鮮度： RAGはクエリ時にソース文書を直接読むため有利です。基となる文書を更新すれば、次のクエリですぐ反映されます。LLM Wikiはページ更新に再取り込みが必要なため、生の事実と編纂済み知識の間に遅延が生じます。
• 正確性： 多数ソースの統合が要る質問では、合成が既に行われレビューされているLLM Wikiが有利です。RAGは、関連断片がコンテキストウィンドウに収まりきらない場合に見落としが起きやすく、全体像を一度に把握できません。
• 保守： ベクトルストアの構築後はインデキシングが機械的なのでRAGはほぼ保守不要です。LLM Wikiは、陳腐化検知、矛盾チェック、孤立ページの剪定など積極的な手入れが必要です。その代わり、手入れされたウィキは時間とともに豊かになり、RAGのインデックスは平坦なままです。
• スケーラビリティ： RAGは検索問題なので文書数に対して予測可能にスケールします。LLM Wikiは、成長に伴って編纂知識の一貫性を保てるモデル能力に依存します。一定規模を超えると、ウィキ自体にも索引ファイルや検索ツール、埋め込みレイヤーが必要になります。

並列表はこちら：

LLM Wiki と RAG の比較

実務ではRAGとLLM Wikiは相補的でもあります。インデックスファイルでは捌ききれない規模に育ったウィキに対して、RAGをそのまま走らせる実装もあります。

AIエージェントがLLM Wikiから得る利益

AIエージェントは、チャットシステム以上に無記憶問題に苦しみます。単発の会話なら再取得も許容されますが、エージェントは何時間も何日も動作し、数十のタスクにまたがって同じ事実を再発見しがちです。LLM Wikiは、学んだことを保管する場所を与え、繰り返し学習し直さなくて済むようにします。

永続知識が最も威力を発揮する領域をいくつか挙げます：

• ソフトウェア開発： 数週間にわたりコードベースに取り組むコーディングエージェントは、モジュール、慣習、過去のバグ、設計判断に関する知識を蓄積します。ウィキがなければ、その文脈は毎回のセッションで再構築されます。ウィキがあれば、編纂ページを読み、前回の続きから再開できます。
• 長期の調査研究： 何百本もの論文にまたがってトピックを追うエージェントは、すべてをコンテキストに保持できません。ウィキは要約を格納する場所を提供し、コーパス全体を読み直すことなく進化する全体像を再訪できます。
• エンタープライズアシスタント： 社内に配備されたアシスタントは、毎日、異なる従業員から同じ質問を受けます。ウィキがあれば、毎回同じページ群を検索するのではなく、編纂済みの社内知識から回答できます。
• 組織的記憶： 人の退職や会議の終了で、チームは文脈を失います。文字起こし、チケット、文書で給電されるLLM Wikiは、その文脈を紐づけたまま保ちます。

適切に実装されると、LLM Wikiの効果は次の3点で現れます。

1. 重複検索の減少： 編纂ページを読むエージェントは、昨日と同じWeb検索やベクトル検索を繰り返す必要がありません。
2. より豊かなコンテキスト： ウィキページにはすでに合成情報が含まれているため、生チャンクよりも濃密で結び付きの強い土台から各タスクを開始できます。
3. 累積的学習： すべてのセッションがウィキに寄与し、次のセッションは前回の成果の恩恵を受けます。これこそ、毎回プロンプトでリセットされるのではなく、時間とともに本当に仕事が上達するエージェントの作り方です。

LLM Wikiの構築

ウィキ構築のワークフローはループです。ソースが入り、ページが書かれ書き直され、コーパスが成長するにつれ全体が洗練されます。

LLM Wiki 構築ループ

• 文書を取り込む。 最初のステップは、生ストレージにソースを入れることです。文書は一度読まれ、不変のまま保持されます。これにより、下流のあらゆる主張を特定のソースに遡れます。取り込みは単一ファイル、バッチ、フォルダ監視からのストリームのいずれでも構いません。
• 実体と概念を特定する。 各新規ソースについて、モデルは固有表現、主要概念、主張、定義、関係など重要事項を抽出します。ここが、非構造テキストがウィキにファイル可能なものへと変わる瞬間です。抽出パスでは、既存ウィキの網羅状況も確認し、新規か既存かを見極めます。
• ページを生成・更新する。 新しい実体には新規ページを、既存ページは新情報で改訂します。新ソースが既存の主張と矛盾する場合は、上書きせずページ上でフラグを立てます。1つのソースが10〜15ページを変更することはよくあります。ソースは通常、複数の事柄に触れるためです。
• リンクを維持する。 相互参照は双方向に追加して、ページ間のつながりを保ちます。もし新しいRAGページがベクトルデータベースに言及し、既にvector databasesページがあるなら、双方にリンクが張られます。
• 知識を継続的に整える。 定期的なリンティングにより、時間とともに蓄積する問題を捕捉します。例えば、ページ間の矛盾、新しいソースに置き換えられた古い主張、誰からもリンクされない孤立ページ、重要だが独立ページを欠く概念の言及など。拡大に伴いウィキを健全に保ちます。

具体はスタックに依存しますが、形はどの実装でも同じです。取り込む、抽出する、書く、リンクする、整える——そして巡回します。

LLM Wikiシステムに共通する機能

多くのLLM Wiki実装は同じ機能セットを持ちます。細部は異なりますが、ビルディングブロックは共通です。

自動ナレッジ編纂

ウィキは自らを書きます。ソースが取り込まれると、モデルは重要事項を抽出し、人手を介さずページにファイルします。手作業の保守は伝統的なウィキを衰えさせます。人間は相互参照や要約の更新に飽きてしまうからです。モデルは飽きません。これこそ、このパターン全体を成立させる機能です。

リンクされたページ

各ページは相互参照で関連ページに接続されます。transformersのページがattention mechanismsに言及したら、双方にリンクが張られます。結果として、参照を辿って歩けるナビゲーション可能なグラフができ、思いもよらないつながりを発見できます。

ソースの帰属表示

すべてのページ内のすべての主張は特定のソースへ遡れます。生文書は不変のままなので、情報の出所を常に検証できます。これは2つの理由で重要です。正確性を確認したいときの監査経路を提供すること、そしてソースが削除された際にモデルが主張をきれいに撤回できることです。

ナレッジグラフ

ウィキのリンク構造自体がナレッジグラフです。ノードはページ、エッジは相互参照で、グラフの形がコーパスの実像を物語ります。重要概念の周りにハブページが現れ、孤立ページはギャップを示し、密なクラスターはウィキが最も詳しい領域を示します。

永続メモリ

ウィキはセッションをまたいで利用可能です。チャットのコンテキストは会話が終わると消えますが、ウィキページはMarkdownとしてディスクに残ります。これにより、チャットモデルは日々・プロジェクト・エージェント実行をまたいで知識を持ち越せるようになります。

継続的更新

新しいソースは、単なる追記ではなく既存ページの改訂を引き起こします。先月発表の論文が6か月前の記述と矛盾すれば、ウィキはそれにフラグを立て、該当ページを更新します。ナレッジベースは古い主張を蓄積するのではなく、時間とともに正しさに近づいていきます。

これらの機能は独立ではありません。つまり、出所表示のないウィキは信頼できません。同様に、継続更新のないウィキは陳腐化し、リンクのないウィキは単なる要約のフォルダです。価値は、すべてが連動して機能するところに生まれます。

LLM Wikiの実用例

ここまでのパターンは一般的なものです。ここからは、RAG以上にLLM Wikiが有用になり得る実例をいくつか紹介します。

研究文献

数十〜数百本の論文にわたってトピックを追う人は誰でも同じ問題に直面します——論文が処理能力より早く積み上がるのです。LLM Wikiは、到着した各論文を読み、主張を抽出し、関連概念の下にファイルし、既読内容との矛盾にフラグを立てます。結果は、読み返されないPDFの山ではなく、分野の最新動向と歩調を合わせる継続的な統合となります。

エンジニアリング文書

コードベースは各スプリントでドキュメント負債が増えがちです。設計判断はSlackスレッドで行われ、アーキテクチャノートは誰かのNotionにあります。最新が保証される唯一のソースは実際のコードです。コードベース、コメント、プルリク、社内ドキュメントで給電されるウィキは、コードに結びついたシステム像を編纂できます。エンジニアは3年前にそのモジュールを書いた人に聞くのではなく、ウィキに質問できます。

エンタープライズナレッジベース

企業はチケット、会議の文字起こし、製品仕様、社内ウィキに知識を蓄積します。LLM Wikiはそれらすべてから取り込み、単一の最新ナレッジレイヤーに編纂できます。従業員は4つのツールを横断検索する代わりに、一度のクエリで済ませられます。

個人知識管理

メモアプリは保存の問題は解決しましたが、統合の問題は未解決です。膨大なメモ、記事、ハイライトがあり、大半は再訪しません。例えばObsidianのボールトから給電するウィキなら、そのノートの山を、実際にクエリ可能な編纂知識体系へと変換できます。

AIエージェントのメモリ

何時間も何日も動作するエージェントには、学んだことを保存する場所が必要です。ウィキは、セッションをまたいで使える耐久メモリ（うまくいったこと、うまくいかなかったこと、既読ファイル、試行経路）を提供します。特に、 Claude Code などのtoolsの上に構築されたエージェントでは、同じコードベースに複数セッションで取り組むため、過去のコンテキストが現在の効率を左右します。

現在のLLM Wiki実装

2026年時点のLLM Wiki領域は黎明期です。存在するものの多くはオープンソースで、個人や小規模チームにより作られています。RAGの成熟度には遠く及びません。

Karpathyのオリジナルのgistは、多くの実装者の出発点になりました。パターンが十分に詳細に記述されており、Claude Codeなどのツールにドキュメントを貼り付ければ自作のバージョンを構築できます。現行のウィキの多くは、共通のアイデアの上に構築された個人プロジェクトとして始まります。

オープンソースの取り組みこそが、アイデアが練られている場です。例えば llm-wiki.net のようなプロジェクトは、寛容なライセンスでコードを公開し、他者がフォーク・拡張・自分のワークフローに適合させられるようにしています。利点は、ウィキが何をしているかを正確に把握でき、デフォルトと合わないニーズがあれば変更できることです。

ローカルファーストのアプローチは、すべてを自分のマシン上で完結させます。ソースはディスクに保存され、ウィキはMarkdownファイルのフォルダで、モデルはローカルエージェント経由で読み書きします。フロントエンドにはObsidianが最も一般的で、Markdownと相互参照に対応しているからです。ソースがマシン外に出ず、モデルが書いたページをすべて精査できるため、最もコントロールしやすい方法です。

ホステッド実装も出始めていますが、まだ少数です。このパターンはRAGほどSaaSモデルに適合しません。ウィキは本来自分のもの（自分のソース、自分のページ、何をファイルするかの自分の判断）だからです。ホステッド版は、チームウィキのように、共有知識の価値が他社インフラにソースを置くコストを上回る場合に最も機能します。

ただし2026年7月時点では、いずれも未完成です。まだ模索中で、現存プロジェクトの大半はプロトタイプに過ぎません。

利点と限界

LLM Wikiパターンには長所とコストがあります。構築を決める前に双方を把握しておく価値があります。

利点

• 永続的な知識： 単一セッションの終了後もウィキは残ります。先月モデルが導いた内容は今日もページにあり、新しい作業はゼロからではなく、その上に積み上がります。
• 再利用可能な合成： ソース同士の接続作業は取り込み時に一度だけ行います。その後のすべてのクエリは、生テキストから再合成するのではなく、編纂結果を読みます。計算資源を節約し、思考プロセスを済ませた上で回答するため、精度も向上します。
• 重複取得の減少： 既にトピックのページがあるウィキは、トピックが出るたびに生コーパスを検索する必要がありません。何時間も動くエージェントにとって、同じ検索の繰り返しを防ぐことは重要です。
• 構造化された整理： ページと相互参照により、特にPDFの束と比べて、閲覧・推論可能な形になります。

限界

• 最新性の維持： ソースが変わったら再取り込みが必要です。文書が更新されても取り込みを再実行しない限り、ウィキは旧版を参照し続けます。RAGはクエリ時にライブソースを読むため、この問題はありません。
• 検証の難しさ： ウィキページ上のあらゆる主張はモデルが書いたものです。出所表示は助けになりますが、モデルが正しく要約したという信頼は依然として必要です。
• 保守： 矛盾チェックや再取り込みは無料ではありません。手入れされないウィキは陳腐化し、モデルが作業するとしても、保守には時間と計算資源がかかります。
• 知識ドリフトの可能性： 取り込みのたびに、モデルが小さな誤りを持ち込む可能性があります。何百回もの取り込みを経ると、これらが累積し、当初は正確だったページが微妙に誤った内容へと変質することがあります。

LLM Wikiに関する誤解

新しい概念であるにもかかわらず、すでにいくつかの誤解があります。どこが誤りかを示します。

LLM WikiはRAGを置き換える

置き換えません。両者は異なる問題を解決します。RAGは頻繁に変化するコーパスへの高速なルックアップ向け。LLM Wikiは時間をかけて知識体系を築くためのものです。実システムの多くは両方を使います——生ソースに対する鮮度はRAG、上に重ねる編纂的合成はウィキ、という具合です。

これは単なる別のベクトルデータベースだ

ベクトルデータベースは検索のためにテキストを索引化します。LLM Wikiは、モデルが読み取り・理解・再構成したテキストを書き出します。ベクトルデータベースは投入したチャンクを返します。ウィキは、取り込む前には存在しなかったページを返します。出力はまったく異なります。

ナレッジベースは更新不要だ

誤りです。ソースは変化し、新たなソースが到着し、モデルの誤りも修正が必要です。保守されないウィキは、他のドキュメントと同様に陳腐化します。違いは、保守の大半をモデルが担うことであって、保守が不要になることではありません。

AIエージェントにしか利点がない

エージェントは長時間動作し耐久メモリの恩恵が最も大きいので最も分かりやすい事例ですが、人間にとっても価値があります。トピックを追う研究者や、コードベースで作業するエンジニアを考えてみてください。あるいは、個人的な知識ベースを築いている誰にとっても、同じく複利的な合成の恩恵があります。

LLM Wikiは新たなAIアーキテクチャになるのか？

まだ判断は早計ですが、進むべき道筋は見えています。永続知識は検索優先システムを置き換えるのではなく、並存します。ライブなルックアップはRAGが、編纂された長期コンテキストはウィキが担います。より大きな未解決点は検証とスケールで、ウィキページに書き込まれたモデルの誤りをどう検出するか、非常に大規模なウィキでこのパターンをストレステストした例がまだないことです。MCPはウィキをエージェントに公開する手段として自然に適合していそうですが、信頼要件が増すためエンタープライズでの採用は先になりそうです。

パターンはまだ確立されていません。前進するかどうかは、保守と検証の課題が解決されるかにかかっています。これに関する追加の疑問には、以下のFAQで答えています。

結論

LLM Wikiは、ソースをモデルに渡したときにAIシステムが何をするかを変えるという点で、2026年に登場した中でも特に興味深いアイデアです。毎回同じ文書を読むのではなく、一度読んでナレッジベースにファイルし、時間とともに良くなっていきます。

この概念はまだ萌芽段階で、現行実装も初期的ですが、将来性があり、より大きな流れを示しています。AIシステムは使い捨てのコンテキストから永続的な知識へと移行しており、LLM Wikiはその実際の姿を示す最初の本格的な試みの一つです。

新しい動向を追いたいが混乱してしまう場合は、AI Fundamentals トラックに登録してください。用語を学び、仕事でAIを効果的に使えるようになります。