LLMにWikiを育てさせる：llm-wikiとArs Contextaを実運用視点で比較する

注意: 本記事は2026年6月3日時点の情報に基づいています。llm-wiki（Karpathy Gist: 2026-04-04公開）も Ars Contexta（v0.8.0）も登場して間もなく、急速に進化中です。最新の仕様は各一次ソースをご確認ください。

はじめに

LLMに何度同じことを聞いても、毎回ゼロから資料を読み直して答えを組み立て直している——RAG（Retrieval-Augmented Generation）を使っていると、こんな「もったいなさ」を感じることがあります。せっかく良い回答が出ても、それはチャット履歴に消えていき、次に同じ質問をすればまた検索からやり直しです。知識が蓄積されないのです。

この問題に対して、2026年4月にAndrej Karpathy氏が提示した一つの答えが「llm-wiki」、別名 Memexパターンでした。考え方はシンプルです。「LLMに、回答を生成させるだけでなく、Wikiそのものを書いて維持させる」。知識は一度コンパイルして蓄積し、質問のたびに育てていく。

そして同じ思想を、Claude Codeのプラグインとして「会話だけで第二の脳を自動生成する」形にまで作り込んだのが「Ars Contexta」です。

本記事では、この2つを 一次ソースの引用 と、筆者自身が llm-wiki パターンで7つのwikiを運用してきた 実体験 の両面から比較します。最後に「どちらを選ぶべきか」の判断軸も示します。

2つのアプローチの全体像

先に結論を示します。両者は「LLMがメンテナンスを担う知識管理」という同じゴールを、異なる方法で目指しています。

「仕様 vs プラグイン」「シンプル vs 作り込み」という対比で捉えると、以降の話が整理しやすくなります。

llm-wiki（Memexパターン）とは

提唱者と出典

llm-wiki は、OpenAI / Teslaでの仕事で知られる Andrej Karpathy 氏が2026年4月、自身のGitHub Gistで公開したアイデアファイル／仕様です。ソフトウェア製品ではなく、「自分のLLMエージェント（Claude Code、Codex、OpenCodeなど）に貼り付けて使うパターンの記述」という位置づけです。

名前の由来は、Vannevar Bush が1945年の論文「As We May Think」で構想した架空の知識装置「Memex」。個人の蔵書・記録を相互にリンクして辿れる装置という80年前のビジョンを、LLM時代に実装し直したのがこのパターンです。

核心：RAGの否定と「コンパイル」

Gistの中で Karpathy 氏は、RAGとの違いを明確に対比しています。

The knowledge is compiled once and then kept current, not re-derived on every query. （知識は一度コンパイルされ、その後は最新に保たれる。クエリのたびに再導出されるのではない）

RAGでは「LLMが質問のたびに知識をゼロから再発見している」のに対し、llm-wiki は知識を永続的・累積的なアーティファクトとして残します。Gistの比喩がこの設計を端的に表しています。

Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase. （Obsidianはエディタ、LLMはプログラマ、Wikiはコードベース）

役割分担とアーキテクチャ

人間とLLMの分担は明確です。Gistはこう言い切ります。

You never (or rarely) write the wiki yourself — the LLM writes and maintains all of it. （Wikiを自分で書くことは決して（あるいは滅多に）ない。LLMが全てを書き、維持する）

• 人間: ソースを集める、探索する、良い質問をする
• LLM: 要約・相互参照・ファイリング・索引維持といった雑務をすべて所有する

構造は3層です。

1. 生ソース層（immutable） — LLMは読むが、決して書き換えない元資料
2. Wiki層（LLM所有） — 要約・エンティティページ・概念ページ。[[wikilink]] で相互接続
3. スキーマ層 — CLAUDE.md 等に書かれた、そのWiki固有のルール

これに加えて、全ページの1行要約を集めた index.md（最初に読むカタログ）と、操作履歴を追記し続ける log.md が運用を支えます。実際のディレクトリ構成はこのようになります。

<wiki-root>/
├── CLAUDE.md      # このWiki固有のスキーマ（ドメイン・規約）
├── index.md       # 全ページの1行要約カタログ
├── log.md         # 操作履歴（追記専用）
├── raw/           # 生ソース（読むだけ・書き換えない）
└── wiki/          # LLMが書き維持する層
    ├── sources/   # ソースごとの要約ページ
    ├── concepts/  # 概念・用語・手法
    ├── entities/  # 人物・組織・プロダクト
    └── syntheses/ # 横断的な比較・分析

運用は3つの操作で回る

• Ingest: 新しいソースを読み、要約ページを作り、索引を更新する。1ソースの取り込みが既存の10〜15ページに波及するのが特徴
• Query: 質問に答え、良い回答は新ページとしてWikiに還元する。「質問するたびにシステムが育つ」
• Lint: 定期ヘルスチェック。矛盾・陳腐化した主張・孤立ページ（orphan）・リンク切れを検出する

ekadetov/llm-wiki や ar9av/obsidian-wiki など、このパターンをObsidian上で動かすClaude Code実装が複数公開されています。後者のREADMEは設計を一言で表しています——"Obsidian is the viewer and the LLM is the maintainer"（Obsidianは閲覧者、LLMは維持者）。

Ars Contextaとは

「テンプレートを配らない」プラグイン

Ars Contexta（v0.8.0、MITライセンス）は、llm-wiki と同じ「LLMが知識を維持する」思想を、Claude Codeプラグインとして製品化したものです。ただし最大の特徴は、固定テンプレートを一切配らない点にあります。

The key differentiator: derivation, not templating. （核心的な差別化要因は、テンプレート化ではなく「導出」である）

ユーザーは2〜4ターンの会話で「自分がどういう領域で、どう考え、どう働くか」を説明するだけ。するとプラグインが、その人専用のフォルダ構造・処理パイプライン・フック・ノートテンプレートをその場で導出生成します。READMEいわく「No templates. No configuration. Just conversation.（テンプレートも設定もない。あるのは会話だけ）」。

3つの空間と「6R」パイプライン

生成されるvaultは、名前こそドメインに合わせて変わるものの、3つの空間への分離は不変（invariant）です。

• self/ — エージェントの永続的な「精神」。アイデンティティ・方法論・目標
• notes/ — 知識グラフ本体。システムが存在する理由そのもの
• ops/ — 運用上の調整。キューの状態やセッション情報

<vault-root>/
├── self/    # エージェントの「精神」（アイデンティティ・方法論・目標）
├── notes/   # 知識グラフ本体
└── ops/     # 運用上の調整（キュー・セッション）

導入は、プラグインを入れて「自分はどんな領域で、どう考え、どう働くか」を数ターン話すだけ。その会話を元に、上記の空間構成や6Rのコマンド群がその人専用に生成されます。

そして処理は、コーネル式ノート術の「5R」（Record / Reduce / Recite / Reflect / Review）にメタ認知の層を足した独自の「6R」パイプラインで進みます。

The vault implements the 6 Rs, extending Cornell Note-Taking's 5 Rs with a meta-cognitive layer.

Record → Reduce → Reflect → Reweave → Verify → Rethink の6段階で、各フェーズは /reduce /reflect といったスラッシュコマンドとして提供されます。注目すべきは、各フェーズがサブエージェントとして別のコンテキストウィンドウで実行される点です。これにより、メインの会話を汚さず、各処理が「賢く動ける領域（smart zone）」を保てるよう設計されています。

根本的な違いはどこにあるか

ここまでを踏まえると、両者の違いは「機能の差」ではなく設計思想の差だと分かります。

ざっくり言えば、llm-wiki は「生ソースを主役にした知識のコンパイル」、Ars Contexta は「思考プロセスを主役にしたメタ認知の自動化」です。llm-wiki が「外から来た情報を整理する」のに対し、Ars Contexta は「自分の思考を捕まえて育てる」方に寄っています。

実際にllm-wikiで7つのwikiを運用してみて

ここからは、筆者が llm-wiki パターンを実運用してきた経験です。Ars Contexta は今回は調査ベースのため、実体験は llm-wiki 側に限られる点を先に断っておきます。

筆者のObsidian vaultには、現在 7つのwiki が共存しています。AIニュースの蓄積、技術ライブラリのリファレンス、個人の技術メモ、社内ナレッジなど、ドメインごとに raw / wiki / CLAUDE.md / index.md / log.md のセットを分けて運用しています。ドメインが変わってもパターンは同じなので、「新しいテーマができたら同じ型でwikiを足す」運用が自然に回ります。

自動取り込みと手動整理の分離

特に効いているのが、取り込みの自動化と整理の手動化を分けている点です。AIニュース用のwikiでは、毎朝RSSフィードを巡回して英語記事から「今日読むべき5本」を選び、日本語要約を生成して raw/rss/ に保存する仕組みを動かしています。Tier A（フロンティアAIラボや個人研究者）を優先し、新鮮さと多様性で5本を選ぶ、という選定ロジックです。これで生ソースは放っておいても貯まります。

ただし、生ソースを raw/ に貯めるところまでが自動、そこから wiki/ の概念ページへ統合する Ingest は意図的に手動にしています。Karpathy のパターンが言う「人間が curate し、LLMが bookkeep する」分担を、自動／手動の境界として実装した形です。

陳腐化対策も「検知までを自動化」する

陳腐化（stale）への対処も自動化していますが、ここでも線引きを設けています。macOSの定期実行の仕組み（launchd）で、毎朝2本のジョブを順に走らせています。1本目がRSSの取り込み（生ソースの供給）、2本目が全wikiのヘルスチェックです。2本目は Claude をヘッドレスで起動し、リンク切れ・孤立ページ・「重要なのに育っていないスタブ」・ページ間の矛盾・陳腐化したページを検出して、各wikiの log.md に結果を1ブロック追記します。

ポイントは、この2本目のジョブに「lint（検知）だけを行い、Ingest（統合）も新ページ作成も一切しない」という制約をかけていることです。「何が劣化しているか」は機械が毎朝教えてくれますが、「どれを直すか・どう成熟させるか」の判断は人間に残す——その線引きを、そのままジョブの権限として実装しています。RAGなら検索インデックスを更新すれば済むところを、llm-wiki では「育てる対象を毎朝棚卸しする」運用がついて回る、とも言えます。

蓄積の手応え——そして現実的な運用コスト

数ヶ月運用して、「知識が確かに蓄積される」手応えはあります。[[wikilink]] で繋がった概念ページが増えていくと、Obsidianのグラフビューで知識の地図が見えてくるのは素直に楽しい。一度書いた概念ページは、次に関連ソースが来ると更新されてさらに濃くなります。これは RAG の「毎回ゼロから」では得られない感覚です。

一方で、調査段階で指摘されていた弱点が、自分のvaultでそのまま現実になっているのも事実です。

• 未インジェストの滞留: AIニュースwikiでは、自動で貯まった生ソースが数十件、wiki/ への正式取り込みを待ったまま積み上がっています。「貯める」は自動化できても「溶かす」は手間がかかり、入口と出口の速度差がそのまま在庫になります。
• スタブの陳腐化: ある概念ページは10箇所から参照されているのに、中身は3行のスタブ（status: stub）のまま数日放置されていました。「重要なのに育っていないページ」は、自動lintが毎日警告を出してくれても、結局人間が腰を据えて元ソースを読み直さないと成熟しないのです。
• メンテナンスの常設コスト: 自動lintが毎日「リンク切れ・孤立ページ・成長すべきスタブ」をレポートしてくれるのは便利ですが、裏を返せばWikiは放置すると静かに劣化するということ。育てる対象が増えるほど、手入れの総量も増えます。

これらは llm-wiki の欠陥というより、「LLMにWikiを書かせても、何を重視し何を成熟させるかの判断はやはり人間が握り続ける」という、このパターンの本質的な性格だと感じています。Ingest を完全自動化しなかったのは正解でしたが、その分の手間は確実に残ります。

メリット・デメリットの整理

実体験と調査を合わせると、次のように整理できます。

llm-wiki

メリット

• 仕様がGist一枚。今すぐ・無料で・自分のエージェントに貼って試せる
• 構造がプレーンなMarkdownなので、Obsidianでそのまま読め、特定ツールへのロックインがない
• 改造前提なので、ドメインごとに型を流用しやすい

デメリット（一次ソースでも指摘）

• ハルシネーションの累積: 誤った事実が一度Wikiに書かれると、後続のIngestがそれを前提に積み上げてしまう
• トークンコスト: 1回のIngestが10〜15ページに波及するため、運用規模に比例してコストが膨らむ
• 鮮度ギャップ: 合成ページが元ソースより先に陳腐化することがあり、lintでも確実には検知できない
• スケーラビリティ: 数百ページを超えると、結局は検索・ランキングの仕組みが再び必要になる（Karpathy 氏自身もGistで「中規模（〜100ソース／数百ページ）」を想定スケールとして挙げています）

Ars Contexta

メリット

• セットアップが会話だけ。最初から作り込まれた構造・パイプライン・フックが手に入る
• 6Rの各フェーズが別コンテキストで動くため、メインの会話を汚さずに処理できる
• 出力はMarkdownなのでDBロックインがない

デメリット（留意点）

• 仕組みが作り込まれている分、全体像を把握して使いこなすまでの学習コストがある
• 登場が新しく、独立した第三者の批判的レビューがまだ少ない。長期運用での実測データ（コスト・スケーラビリティ）は今後の蓄積待ち

どちらを選ぶべきか

実運用視点での判断軸を示します。

llm-wiki が向いている人

• まず最小コストで試したい。Gistを貼って自分のエージェントで動かしてみたい
• Obsidianを既に使っていて、プレーンなMarkdownのまま自分で構造を握りたい
• ドメインごとに同じ型でwikiを増やしていく運用をしたい
• 「自動化と手動の境界を自分で設計したい」という作り込み欲がある

Ars Contexta が向いている人

• ゼロから構造を考えるより、出来合いの第二の脳をすぐ使い始めたい
• Claude Code を日常的に使っていて、プラグインとして統合したい
• ノートの捕捉と熟成のプロセス（自分の思考の整理）に重心を置きたい

筆者の実感としては、まず llm-wiki でパターンの感触を掴むのが入口として無理がありません。Gist一枚で始められ、合わなければ捨てるコストも小さい。その上で「毎回構造を組むのが面倒」「もっと作り込まれた処理が欲しい」と感じたら、Ars Contexta のような整備済みのフレームワークに移る、という順序が現実的だと考えています。

両者は排他的でもありません。「生ソースを溶かす llm-wiki の3層」と「思考を処理する Ars Contexta の6R」は重心が違うので、取り込みは llm-wiki 的に、熟成は Ars Contexta 的にという良いとこ取りも考えられます。筆者自身、現状の llm-wiki 運用で課題になっている「滞留したソースの熟成」に、Ars Contexta 的な処理パイプラインを組み合わせられないか、次のフェーズとして試したいと考えています。

まとめ

• llm-wiki は Karpathy が提唱した「LLMがWiki全体を維持する」パターン（仕様）。RAGの再導出を捨て、知識を一度コンパイルして蓄積する
• Ars Contexta は同じ思想を会話から自動生成する Claude Codeプラグイン。3空間と6Rパイプラインで思考の処理に重心を置く
• 筆者の7つのwiki運用では、蓄積の手応えと同時に未インジェストの滞留・スタブの陳腐化という現実的コストも体験した。「LLMに書かせても、何を成熟させるかの判断は人間が握り続ける」のがこのパターンの本質
• 手軽に試すなら llm-wiki、最初から作り込まれた第二の脳が欲しいなら Ars Contexta

「LLMに知識を蓄積させる」という発想は、RAGの次を考える上で重要なパラダイムです。どちらもまだ進化の途中なので、興味を持ったらまず一次ソース（Gist／各リポジトリのREADME）を自分の目で読み、小さく試してみるのが確実だと思います。

SuperPowers：Claude Codeの開発ワークフローを変えるプラグイン

Claude Code用プラグイン「SuperPowers」の導入方法と主要スキルを解説。brainstorming（設計）、TDD（テスト駆動開発）、サブエージェント並列開発など、AIコーディングの品質を体系的に引き上げる仕組みを、ソースコードに基づいて詳しく紹介します。

2026-02-21