Shuichiro Ogawa

Notes ・ updated 2026-07-01

LLM 時代のナレッジ管理手法（2026年中間地点）

LLM にどう知識を渡すか。この問いへの答えが、2024年末から2026年中間にかけて急速に構造化された。プロンプトの書き方（prompt engineering）から始まった実践は、コンテキストの設計（context engineering）を経て、知識の事前コンパイルと永続管理へ到達した。本ノートは、調査時点で収束しつつある手法群を、系譜と構造の両面から整理する。

系譜

2024-11  MCP 発表 (Anthropic)
2025-04  Karpathy LLM Wiki gist 公開
2025-06  Tobi Lütke "context engineering" 提唱
2025-07  LangChain 4操作分類 (Write/Select/Compress/Isolate)
2025-08  Addy Osmani / O'Reilly Radar 体系化
2025-08  OpenAI AGENTS.md 公開
2025-09  Anthropic context engineering 公式ブログ
2025-09  Claude Memory 導入 (Pro)
2025-12  MCP + AGENTS.md → Linux Foundation AAIF 寄贈
2026-01  MCP Apps リリース
2026-02  ETH Zurich AGENTbench (人間キュレーション > LLM 自動生成)
2026-03  Claude Memory 全アカウント展開
2026-06  Google OKF v0.1 発表 (LLM Wiki の仕様化)
2026-06  NotebookLM agentic research 更新

1. 知識の事前コンパイル: Karpathy LLM Wiki → Google OKF

Karpathy LLM Wiki パターン

2025年4月、Andrej Karpathy が GitHub Gist（5000+ stars）で提示した設計は3層構造を取る。

  • Raw 層（raw/）: 不変の一次ソース（論文、記事、画像）。LLM は読むだけで書かない。
  • Wiki 層（wiki/）: LLM が所有する Markdown ページ群。要約、相互リンク、整合性保守を LLM が行う。index.md（カテゴリ別カタログ）と log.md（append-only の操作履歴）を予約する。
  • Schema 層（CLAUDE.md 等）: wiki の構造、命名規約、ワークフローを符号化する設定。LLM を「汎用チャットボット」から「規律ある wiki メンテナ」に変える。

操作は3つ。Ingest（新しい raw を読み wiki ページを更新）、Query（wiki を検索し回答、価値ある回答は wiki に書き戻す）、Lint（矛盾、孤立ページ、リンク切れを検出）。

設計思想の核心は、知識ベースの維持で面倒なのは読むことや考えることではなく帳簿管理（bookkeeping）であり、LLM がその帳簿管理コストをほぼゼロにするという洞察にある。RAG が毎回生チャンクから知識を再導出するのに対し、LLM Wiki は知識を事前にコンパイルして蓄積させる。

Google OKF (Open Knowledge Format)

2026年6月13日、Google Cloud が OKF v0.1 を公開した。Karpathy パターンをベンダー中立の仕様として標準化したものである。

  • bundle = ディレクトリツリー（git リポジトリ、tarball、zip で配布可能）
  • 各概念 = 1つの .md ファイル（ファイルパスが ID）
  • 予約ファイル名: index.md（目次）、log.md（変更履歴）
  • frontmatter 必須フィールド: type のみ。推奨: title, description, resource（外部 URI）, tags, timestamp
  • 拡張フィールド自由、consumer は未知キーを保持し拒否しない
  • リンク: bundle-relative 絶対パス /tables/orders.md を推奨。相手先不在でも valid

OKF は producer（人間、パイプライン、LLM）と consumer（エージェント、ビューア、別の LLM）を分離する。参照実装として BigQuery を歩いて OKF を自動生成する Enrichment Agent、グラフビュー生成の Static HTML Visualizer、GA4 / StackOverflow / Bitcoin のサンプルバンドルが同梱されている。

2. Context Engineering: コンテキストの設計

概念の成立

2025年6月、Shopify CEO の Tobi Lütke が X で context engineering を提唱した。「タスクを LLM が解決可能にするための全コンテキストを提供する技芸」。Karpathy が賛同し、「次のステップに適切な情報でコンテキストウィンドウを満たす繊細な技芸と科学」と表現した。

2025年9月、Anthropic が公式ブログ “Effective context engineering for AI agents” で定式化した。「LLM 推論時に最適なトークン集合をキュレーション・維持する一連の戦略」。50万 PV を超えた。

Anthropic の4要素フレームワーク

  1. System Prompts: 「right altitude」で書く。具体的だが柔軟なヒューリスティクス。
  2. Tools: トークン効率の高い情報を返す設計。機能の重複を避ける。
  3. Examples (Few-shot): 網羅的なエッジケースより多様な canonical examples。
  4. Message History & Runtime Retrieval: just-in-time context。軽量 ID で動的ロード。

長期タスクには3つの技法がある。Compaction（要約圧縮）、Structured Note-taking（NOTES.md 等の外部メモリ）、Sub-agent Architecture（サブエージェントでコンテキスト隔離）。

LangChain の4操作分類

LangChain は context engineering を OS のメモリ管理に類比して4操作に分けた。

操作意味OS のアナロジー
Writeコンテキスト外に情報を保存save to disk
Select関連情報をコンテキストに読み込むpage in
Compressトークンを削減（要約、trimming）swap
Isolateコンテキストを分割（multi-agent）process isolation

人間キュレーション vs LLM 自動生成

ETH Zurich の AGENTbench 研究（2026年2月）は、LLM が自動生成したコンテキストファイルがタスク成功率を約3%下げコスト20%以上増加させたのに対し、人間が書いたファイルは約4%改善させたことを報告した。人間による手動キュレーションと短さの維持が、少なくとも現時点では有効である。

3. コード内知識ファイルの収束

2026年中間時点で、5つの規格がほぼ同一のパターン（リポジトリルートの Markdown ファイル）に収束している。

ファイル提供元スコープ制御特徴
AGENTS.mdOpenAI → AAIFディレクトリ階層オープン標準。60,000+ repos 採用。6+ ツールが読む
CLAUDE.mdAnthropic4層(Managed/User/Project/Local)Auto Memory。@path import(4ホップ再帰)。/init で自動生成
.cursor/rules/*.mdcCursorYAML glob + 4モードAlways/Intelligent/Specific Files/Manual の4適用モード
.github/copilot-instructions.mdGitHubglob + ディレクトリPersonal > Repository > Organization の優先順位
.gemini/Google—Gemini CLI 用

Cline は独自の Memory Bank パターン（memory-bank/ に6つの固定 Markdown ファイル）を採用し、毎タスク開始時に全ファイルを読む規約を持つ。Windsurf（現 Devin Desktop）は Rules（明示的指示、4トリガーモード）と Memories（自動学習、ローカル保存）を分離する。

共通する設計判断は3つある。(1) Markdown がフォーマット。(2) ファイルパスでスコープを制御する。(3) 人間が書く指示と LLM が書く学習メモを分離する。

4. Memory システム

Claude Memory

2025年9月に Pro ユーザー向けに導入され、2026年3月に全アカウントに展開された。ベクトル DB ではなく Markdown ファイルベースの透明なアプローチを取る。memory と context editing の組み合わせで社内 agentic search 評価において39%のリフトが報告されている [要方法論確認]。

Claude Code の Memory は CLAUDE.md（人間 → Claude）と Auto Memory（Claude → Claude）の2系統で構成される。Auto Memory は ~/.claude/projects/<project>/memory/ に保存され、MEMORY.md の先頭200行がセッション開始時にロードされる。

ChatGPT Memory

OpenAI は Projects（トピック別にチャット、ファイル、カスタム指示をグループ化するワークスペース）を提供する。2026年には Dreaming Memory（過去の会話から有用なコンテキストを合成する新アーキテクチャ）を Plus/Pro 向けに US 展開を開始した。

共通の設計原則

Memory システムに共通するのは、(1) 明示的なメモリ（人間が書くルール）と暗黙的なメモリ（LLM が自動で書く学習結果）の分離、(2) ファイルベースの透明性（ユーザーが読み書きでき、git で管理できる）、(3) セッション開始時の自動ロードと、必要時のオンデマンド参照の組み合わせ、である。

5. MCP: ツール接続のプロトコル層

2024年11月に Anthropic が発表し、2025年12月に Linux Foundation 傘下の Agentic AI Foundation（AAIF）に寄贈された。OpenAI、Google DeepMind、Microsoft が採用し、Python + TypeScript SDK で月間約9700万ダウンロードに達している。

2026年1月の MCP Apps により、ツールが HTML UI を返してサンドボックス iframe で描画する機能が加わった。Claude、ChatGPT、Goose、VS Code で動作する。

ナレッジ管理の文脈では、MCP は PKM ツール（Obsidian、Notion、Logseq 等）と LLM エージェントを接続するプロトコル層として機能する。詳細は次節で扱う。

6. PKM ツールと LLM の統合

接続アーキテクチャの3類型

パターン例特徴
プラグイン内蔵 MCPObsidian Vault as MCPアプリ内でサーバー起動。アプリ起動中のみ利用可
スタンドアロン MCPmcp-logseq, reflect-mcpアプリの HTTP API に接続する外部プロセス
ホスト型 (SaaS)Notion MCP (mcp.notion.com/mcp)ベンダーがサーバーを運用。OAuth で認証。セットアップ最小

Obsidian

Obsidian はファーストパーティ AI 機能を持たない。これは意図的な製品判断であり、AI はすべてコミュニティプラグインとユーザー自身の API キーで実現する方針を取る。

主要プラグインは2つ。Copilot for Obsidian（150万DL超、vault 全体への RAG チャット、OpenAI/Anthropic/Google/Ollama 対応）と Smart Connections（ローカルベクトル埋め込みによるセマンティック関連ノート表示、クラウド不要）。

MCP 接続は Vault as MCP（プラグイン型、13操作、port 8765）と MCPVault（スタンドアロン型、Claude Desktop/Code/ChatGPT 対応）がある。データはローカルに留まる。

Notion

Notion は AI 機能を製品に深く統合している。Q&A（ワークスペース全体の自然言語検索）、AI Connectors（Slack/Drive/GitHub 等の横断検索）、Agents（Notion 3.0 で導入、Custom Agent は2026年5月 GA）、モデル選択（GPT-5.2/Claude Opus 4.5/Gemini 33）を提供する。

Notion MCP Server は公式ホスト型（mcp.notion.com/mcp）を提供しており、claude mcp add --transport http notion https://mcp.notion.com/mcp の1コマンドで接続できる。22ツール、Notion-Flavored Markdown でのやりとり（トークン効率向上）を特徴とする。OAuth 必須のため完全自動化ワークフローには制約がある。

Logseq

コミュニティ主導で複数の MCP サーバーが活発に開発されている。mcp-logseq（v1.8.0、16コアツール、セマンティックベクトル検索、300 stars）が最も成熟している。

Tana

2026年初頭に API と MCP サーバーを公開した。Supertag（ノードに型付きスキーマを付与する機能）により PKM ツール中で最も構造化されたキャプチャが可能。AI 会議エージェント（60言語の文字起こしとアクションアイテム抽出）を備える。

Apple

Notes に Writing Tools、録音要約、Image Wand を提供する。WWDC 2026 で Foundation Models フレームワークを OSS 化し、サードパーティが Notes 連携 AI アプリを構築する道を開いた。Notes MCP はコミュニティ実装（AppleScript 経由）のみ。

Google NotebookLM

ユーザーが提供したソースのみに閉じた closed RAG でハルシネーションを抑制する。2026年6月の更新で Gemini 3.5、コード実行ノートブック、agentic research 機能が追加され、ノートテイキングから research execution layer へ進化しつつある。ただし長期的なナレッジベース構築には向かない位置づけである。

7. GraphRAG: 知識グラフと LLM の融合

Microsoft Research の GraphRAG がリファレンスアーキテクチャとなっている。パイプラインは、(1) テキストからエンティティと関係を抽出、(2) Leiden クラスタリングでコミュニティ階層を構築、(3) 各コミュニティの LLM 要約を生成、(4) クエリ時に Global Search（コーパス全体推論）/ Local Search（エンティティ近傍探索）/ DRIFT Search を使い分ける。LazyGraphRAG はインデキシングコストを10-90%削減する。

2026年の研究最前線は、グラフベースのエージェントメモリ（受動的なログからトポロジカルな経験モデルへ移行する）にある。Zep / Mem0 のグラフ拡張が LLM エージェントのメモリ層として時間的知識グラフを保持する。

Karpathy Wiki との関係は補完的である。GraphRAG は「非構造テキストから構造を自動抽出する」、Karpathy Wiki は「LLM が構造化 Markdown を直接保守する」。前者は大規模コーパスの自動索引に、後者は人間と LLM の協働知識管理に適する。

8. Fabric: パターンベースの AI パイプライン

Daniel Miessler の Fabric（v1.4.378、2026-01-14）は、AI のユースケースを再利用可能な Pattern（構造化システムプロンプト）に分解し、CLI パイプラインで合成するフレームワークである。300以上のコミュニティ寄贈パターン（summarize、extract_wisdom、explain_code 等）を持ち、OpenAI / Anthropic / Ollama 等の任意プロバイダに対応する。

Miessler の Personal AI Infrastructure（PAI）は、Skills ディレクトリ（SKILL.md + ワークフロー + ツール）でエージェントにドメイン知識を与え、Fabric Patterns と MCP を UNIX 哲学で組み合わせる。永続的な知識蓄積よりも、入力→変換→出力のパイプライン処理に重心がある。

9. RAG vs Long Context: 2026年の実態

「RAG is dead」という言説は SNS 上で繰り返されるが、エンタープライズ RAG 導入は2025年に280%成長したとの報告がある [要出典確認]。

実態の勝ちパターンは、ベクトル検索で evidence set を絞り込み、ロングコンテキストモデルで推論するハイブリッド構成である。コーパスが小さく安定している場合（100K tokens 未満）はロングコンテキスト単体が有利であり、大規模で頻繁に更新される場合は RAG が必須となる。「死んでいるのは RAG ではなく、naive な top-k vector search（lazy retrieval）」という見方が妥当である。

横断比較: パターン分類

パターン知識の所有者永続性構造化度主な用途
Karpathy LLM Wiki / OKFLLM が wiki を所有Markdown ファイル (git)高（index + wikilink + schema）個人/チームの知識蓄積
CLAUDE.md / AGENTS.md人間（+ LLM auto memory）ファイル (git)中（フリーフォーム MD）コーディング指示と学習
Cursor Rules人間.mdc ファイル中（frontmatter + glob）コーディング規約
Cline Memory Bank人間が定義、LLM が保守6 MD ファイル高（固定スキーマ）プロジェクト文脈の持続
Fabric PatternsコミュニティPattern ファイル中（テンプレート）AI 操作の再利用
GraphRAG自動抽出グラフ DB高（エンティティ+関係）大規模コーパスの推論
PKM + MCP人間（既存ノート）PKM ツール内ツール依存既存知識のLLM公開
NotebookLM人間（提供ソース）クラウド中（closed RAG）ドキュメント理解と合成

構造的な観察

3つの構造が浮かぶ。

(1) 知識管理の主語が移った。従来のナレッジ管理は「人間がどう情報を整理するか」が主語だった。LLM Wiki / OKF / Context Engineering は「LLM にどう知識を渡すか」を主語にする。所有と保守の主体が人間から LLM に移ったのではなく、LLM が消費者（consumer）として加わり、知識の表現形式がその消費者に最適化され始めた。

(2) Markdown + ファイルシステム + git への収束。コード内知識ファイル（CLAUDE.md / AGENTS.md / Cursor Rules）、Karpathy Wiki、OKF、Cline Memory Bank のすべてが Markdown + ファイルシステム + git を基盤とする。ベクトル DB やグラフ DB は補助的な位置に留まる。ETH Zurich の研究が示す「人間キュレーション > LLM 自動生成」の知見とも整合する。透明性（人間が読み書きできる）、バージョン管理、diff 可能性が、構造化 DB のクエリ性能よりも重視されている。

(3) MCP が PKM ツールの価値を再定義しつつある。Obsidian や Notion は従来「人間のための知識管理ツール」だった。MCP 接続により、これらは「LLM エージェントのコンテキストソース」としても機能し始めた。ただし接続の成熟度には差がある。Notion は公式ホスト型 MCP で最も進んでおり、Obsidian はコミュニティプラグイン依存、Logseq / Tana は発展途上にある。

参考文献

← Notes 一覧 ・ ホーム