Upgrade to Pro — share decks privately, control downloads, hide ads and more …

LLM wikiの現在地 2026

Sponsored · Ship Features Fearlessly Turn features on and off without deploys. Used by thousands of Ruby developers.

LLM wikiの現在地 2026

1. 「記憶の代謝(Memory as Metabolism)」とライフサイクル設計
従来のLLM Wikiはすべての情報を等価に扱いがちでしたが
、Stefan Miteski(2026年4月)の論文『Memory as Metabolism』や『LLM Wiki v2』により、**記憶を「代謝するシステム」**として設計することが定石となっています

3層から「多層ストレージ」への進化: 一時的なバッファ(Raw Buffer:観測データ)、アクティブなWiki(動的に変化する知識)、コールドメモリ(一次ソース・アーカイブ)に厳密に分離します

動的な文脈圧縮(CONTEXTUALIZE): 外部ソースをそのまま取り込むとコンテキストが肥大化するため、ユーザーの現在の「関与の深さ(作業文脈の深さ)」に合わせてLLMが動的に要約・圧縮します
。ただし、将来的なコンテキストシフトに対応できるよう、一次情報へのリンクアウトは必須保証とされます

忘却(Decay) vs 履歴管理(Supersession)の対立議論:
減衰・忘却派(Metabolism/v2): エビングハウスの忘却曲線に基づき、直近の参照頻度や有用性がない情報は徐々に「Vitality(活性度)」を下げ、要約へと退化(Decay)させます

履歴・明示派(Mattia83itら実務家): 生物学的な忘却をシステムに適用するのは false precision(偽りの精度)であり、古いバグや「過去に破棄された決定(ADR)」ほど再発防止に高い価値を持つため、情報を風化させるべきではないと反論します
。Gitのように明示的な「上書き(Supersession)」とバージョン履歴のみで管理し、システムは完全に決定論的(Deterministic)であるべきという実務的な批判が展開されています

2. 100ページの壁を超える「ハイブリッド検索」のスケーリング
Karpathy氏の初期構想では、すべてのページを1つの index.md にリスト化してLLMに読ませていましたが、ページ数が100〜200を超えるとコンテキストが破綻する「スケール天井(Scale Ceiling)」に直面しました

トリプル・リトリーバル(Triple Retrieval)の定着:
BM25(キーワードの正確な一致)
ベクトル検索(概念的な意味の類似度)
グラフ探索(Graph Traversal)(エンティティ間の構造的関係の追跡)
これら3つを組み合わせ、RRF(Reciprocal Rank Fusion)で融合してLLMに食わせることで、1000ページ規模でも100%に近いRecall(再現率)を達成する実装が進んでいます

型付きの関係性(Typed Relationships): 単なる「リンク」ではなく、ノード間に uses(使用), depends_on(依存), contradicts(矛盾) などのセマンティックな関係性を明示的に持たせることで、エージェントが因果関係のチェーンを多ホップ(Multi-Hop)で正確に辿れるようになります

3. ハルシネーションの焼き付き(Baked-in)と「矛盾(Lint)」の解決策
LLM Wiki最大の実務的リスクは、**「不正確な情報が一度事実としてWikiに書き込まれると、それ以降の要約や推論がその誤った情報を前提としてループし、汚染が累積・伝播していくこと(Epistemic Drift:認識論的漂流)」**です

バッファを介した「パラダイムシフト」の実装: 新しい情報が既存の「確立された知識(Memory Gravity:重力の高いノード)」と矛盾する場合、即座にWikiを上書きしません
。まずは「クアランティン(隔離)」または「マイノリティ・ブランチ(少数派仮説)」としてバッファに蓄積します
。複数の独立したソースから矛盾する証拠が蓄積し、バッファの「圧力(Buffer Pressure)」が閾値を超えた段階で初めて、Wikiのパラダイムを書き換えます(Kuhnの科学革命の構造のメタモルフォーゼ)

Stanford大の「CLAIRE」と「WikiCollide」: Wikipedia内のコーパスレベルの自己矛盾を検出するエージェント研究
。ReActフレームワークを利用し、同名異人の曖昧さを解消する clarify(曖昧さ回避)や専門用語を説明する explain ツールを反復的に適用することで、システムがコンテキスト依存の誤検出を劇的に減らし、エディターの矛盾発見効率を64.7%向上させています

4. 2026年現在の主要な構築ツールとアプローチ
現在、以下のようなアプローチでLLM Wikiの実装・実用化が進んでいます。
Nimbalyst(オールインワン型): AIエージェント、マークダウンエディタ、ファイルツリーを1つのウィンドウに統合
。毎日18時に自動コンパイル、毎週金曜16時に「Wikiの矛盾、陳腐化した主張、リンク切れ」を検出するセルフヒーリング(自己修復)を実行します

MindStudio / Remy(人物・日報統合型): Wiki(知識)だけでなく、CRM(人物関係・連絡先)やJournal(日報)のレイヤーを統合
。日報に記述した個人の悩みに応じて、Wikiに蓄積された過去の意思決定や関連人物の情報を自動でグラウンディング(根拠付け)します

Codeex / Git自動運用(完全自動型): バックグラウンドで1時間ごとに /raw フォルダ内の新しいファイルをコンパイルし、完了後に自動的にGitにコミットしてプライベートリポジトリにプッシュする、ユーザーが「メンテナンスを意識しない」パイプラインです

Avatar for 長津孝輔

長津孝輔

July 04, 2026

More Decks by 長津孝輔

Other Decks in Technology

Transcript