Skip to content

Instantly share code, notes, and snippets.

@podhmo

podhmo/llm-wiki.md

Created May 14, 2026 04:24
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save podhmo/484426ce4d0cf75096e3bb5d3ff433c5 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save podhmo/484426ce4d0cf75096e3bb5d3ff433c5 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
llm-wiki.md

対話履歴

User: 読んで整理して。

AI: 提供された2つのドキュメント（エージェント実装用の定義ファイル SKILL.md と、概念を解説した llm-wiki.md）を読み込み、「LLM Wiki」の全体像、仕組み、および運用ルールについて分かりやすく整理しました。

📚 Karpathy's LLM Wiki パターン 整理とまとめ

1. コアコンセプト：従来のRAGとの違い

一般的なRAG（検索拡張生成）は、質問されるたびに生のドキュメントから情報を探し出し、毎回「ゼロから」知識を組み立てます。対して「LLM Wiki」は、LLMに情報を永続的・構造的なマークダウンのWikiとして構築・維持させるアプローチです。

  • 知識の複利化: 情報は一度統合されるとWiki内に定着し、相互リンクや矛盾のフラグ付けが行われます。質問のたびに再計算するのではなく、常に最新化された「知識体系」にアクセスします。
  • 明確な役割分担:
    • 人間: 情報源のキュレーション、探索の方向付け、問いかけ。
    • LLM (エージェント): 要約、相互リンクの作成、ファイリング、情報の更新、矛盾の管理といった「面倒な保守作業（簿記）」をすべて担当。

2. 3層のアーキテクチャ（ファイル構造）

Wikiはデータベースや特殊なツールを必要とせず、通常のディレクトリとMarkdownファイルで構成されます。

  1. Layer 1: 生データ (raw/)
    • 完全不変（Immutable）: Web記事、PDF、会議録など。LLMはここから情報を読むだけで、絶対に改変しません。ハッシュ値で差分を管理します。
  2. Layer 2: Wikiコンテンツ (entities/, concepts/, comparisons/, queries/)
    • LLMの領分: LLMが自動生成・更新・相互リンク（[[wikilinks]]）を行うページ群。人物、概念、比較分析などがまとめられます。
  3. Layer 3: スキーマ (SCHEMA.md)
    • ルールの定義: エージェントの行動を縛る最重要ファイル。対象ドメイン、ファイル命名規則、タグの分類法（Taxonomy）、ページの作成・分割のしきい値などが定義されています。

【重要なナビゲーション用ファイル】

  • index.md (目次): 全ページのリンクと1行要約が並ぶカタログ。エージェントは検索時にまずこれを読みます。
  • log.md (履歴): 取り込みや変更の履歴を時系列で追記するログ。Wikiがどう成長したかを示します。

3. 3つの基本オペレーション

LLMは以下の3つのサイクルを回してWikiを育てます。

① Ingest（情報の取り込み）

新しい情報源（URLやPDFなど）を与えられた時の動作。

  1. 生データを raw/ に保存。
  2. 既存のWikiページ (index.md や検索を使用) と照らし合わせる。（重複作成を防ぐための重要ステップ）
  3. 新しいエンティティ（概念・人物）があれば新ページを作成し、既存の関連ページを更新する。
  4. 最低2つの相互リンクを張り、情報源の引用元（Provenance）を明記する。
  5. index.md と log.md を更新してユーザーに報告。

② Query（情報の検索・抽出）

質問に対する回答の生成。

  1. index.md を読んで関連ページを特定し、内容を読み込む。
  2. Wikiの知識を統合して回答を生成（Wikiページを引用）。
  3. 【重要】 生成した回答が価値ある比較や深い分析だった場合、それを使い捨てにせず、新たなページとして queries/ や comparisons/ に保存して知識を還元します。

③ Lint（健全性チェック / 保守）

Wikiが劣化しないための自動メンテナンス機能。

  • 孤立したページ（どこからもリンクされていないページ）やリンク切れの検出。
  • 情報が古くなったページ、または**矛盾・対立する主張（Contradictions）**があるページの可視化。
  • タグの乱れの修正、ログファイルのローテーション。

4. エージェントの「鉄則」（運用上の注意点）

ドキュメントには、LLMエージェントがWikiを破壊せず、綺麗に保つための厳格なルールが設定されています。

  • セッション開始時のオリエンテーション必須: いかなる作業を始める前にも、必ず SCHEMA.md、index.md、最新の log.md を読み込み、現状のルールと全体構造を把握しなければならない。
  • タグの勝手な作成禁止: タグは SCHEMA.md に定義された分類（Taxonomy）からのみ使用する。新しいタグが必要な場合は、まずSCHEMAに追加してから使う。（タグのスパゲッティ化を防ぐため）
  • 矛盾は上書きせず明記する: 新しい情報源が古い情報と矛盾する場合、古いものを勝手に消すのではなく「両方の主張と日付・情報源」を併記し、メタデータに「矛盾あり（contested）」とマークして人間のレビューを促す。

5. ツール連携（Obsidian等の活用）

このWiki構造は、Obsidian などのマークダウンエディタと完璧に連携するように設計されています。

  • [[wikilinks]] によるページ間リンクやグラフビューでの視覚化。
  • フロントマター（YAML）を用いた Dataview プラグインでの高度な検索。
  • サーバー上でエージェントがWikiを書き換え、obsidian-headless等を使って手元のPC/スマホのObsidianとバックグラウンドでリアルタイム同期する、といった高度な運用も可能です。

💡 総括

この「LLM Wiki」は、**「LLMをチャットボットとしてではなく、自分のための専属ライブラリアン（司書）兼 ナレッジワーカーとして雇う」**というアイデアです。LLMが裏で地道な相互リンクの構築や要約・分類を続けてくれるため、人間は情報収集と思考に集中しながら、一生モノのパーソナル・ナレッジベースを育てることができます。

User: これって個人用？チーム用？ 全てのドキュメントをスキャンする？そうではない？

AI: 結論から言うと、**「個人・チーム両方で使える」設計であり、また「毎回すべてのドキュメントをスキャンするわけではない（ここが最大の特徴）」**というシステムです。

それぞれの詳細をドキュメントの記載に基づいて解説します。

1. これって個人用？チーム用？

👉 結論：どちらの用途でも使えます。

ドキュメント内（llm-wiki.md）では、具体的な応用例として両方が挙げられています。

  • 個人向け（Personal / Research）： 自分の目標、健康記録、日記、ポッドキャストのメモ、読んだ論文や本のまとめなどを一箇所に蓄積し、自身の思考の整理や研究の深化に使う用途。
  • チーム・ビジネス向け（Business/team）： Slackのスレッド、会議の書き起こし（トランスクリプト）、プロジェクト文書、顧客との通話記録などを継続的に取り込ませて、社内Wikiを自動保守する用途。

チーム利用時のポイント: チームで使う場合、「誰もやりたがらない社内Wikiの保守（リンクの更新や要約など）」をLLMが全自動でやってくれるため、情報が陳腐化しません。ただし、複数人の情報が混ざるため、「人間の管理者がLLMの更新内容を定期的にレビューする」運用が推奨されています。

2. 全てのドキュメントをスキャンする？

👉 結論：いいえ、毎回すべてをスキャンすることは「絶対にしません」。これが従来のRAG（検索システム）との最大の違いです。

従来のAI（RAGシステム）は、質問されるたびに大量の生データを検索（スキャン）し直していましたが、この「LLM Wiki」は最小限のファイルしか読み込みません。

具体的な動きは以下のようになっています。

A. 普段の質問時（Query）はどう動くのか？

  1. まず「目次（index.md）」だけを読む: エージェントは質問されると、全文書をスキャンするのではなく、まず1行要約が並んだカタログである index.md だけを読みます。
  2. 必要なページだけをピンポイントで開く: 目次を見て「この質問なら、[[プロジェクトA]] のページと、[[クライアントB]] のページを見れば分かりそうだ」と判断し、その2つのファイルだけを読み込んで回答を作成します。
  3. 生データ（raw/）は読まない: 一度Wikiページに要約・統合された生データ（長文の会議録や論文など）は、基本的に二度と読みに行きません。

B. 新しい情報を追加する時（Ingest）はどう動くのか？

  1. 新しいドキュメントが追加された時だけ、その「新しいドキュメント」を読みます。
  2. 目次（index.md）を見て、関連しそうな既存のWikiページだけを開きます。
  3. 既存のWikiページに情報を追記し、完了したら生データは不変のフォルダ（raw/）にしまい込んで終わります。

C. 例外（Wikiが巨大化した時）

Wikiが100ページを超えて大きくなった場合のみ、目次（index.md）を読むだけでは見落としが発生する可能性があるため、全マークダウンファイルを対象に**「キーワード検索」**（フルスキャンではなく、単語のヒット確認）を行うことが定義されています。

まとめ

このシステムが優れているのは、**「知識を一度Wikiの形にコンパイル（変換・整理）してしまうため、毎回全データをスキャンする計算コストや手間がかからない」**という点にあります。人間が本を読むとき、毎回辞書を最初から最後まで読まないのと同じように、目次と索引を使って賢く情報を引き出す設計になっています。

User: つまり初回でindex.mdをcontextに詰め込むという感じ？それともそこも質問されるたびにscan?

AI: 👉 結論から言うと、基本的には「セッション（会話）の初回でコンテキスト（LLMの記憶）に詰め込む」のがベースですが、システムが大きくなると検索（Scan）を組み合わせるアプローチに変化します。

ドキュメントの指示書（SKILL.md）には、エージェントの具体的な動作プロセスが明確に定義されています。順を追って解説します。

1. 基本動作：「会話の最初に読み込む（コンテキストに入れる）」

ドキュメントの "Resuming an Existing Wiki (CRITICAL — do this every session)" という項目に、エージェントへの絶対のルールが書かれています。

エージェントは、**ユーザーとのチャット（セッション）を開始した直後に、必ず以下の3つを自律的に読み込む（＝コンテキストにロードする）**ように指示されています。

  1. SCHEMA.md (ルールブック)
  2. index.md (全ページの目次)
  3. log.md (最近の変更履歴、直近30行)

つまり、チャットを始めた時点で index.md がLLMの頭の中（コンテキストウィンドウ）に入っている状態になります。そのため、その後の質問に対しては、頭の中にある目次情報を元に「あ、あのページを読めばいいな」と判断して対象ページだけを開きに行きます。

2. 質問のたびに再読み込みするケースもある

基本は初回読み込みですが、「Query（質問された時）」のルールとして、「① index.md を読んで関連ページを特定する」とも定義されています。

これは、エージェントの実装（LLMの種類やツールの仕組み）に依存しますが、

  • 会話が長くなって初回の index.md がコンテキストから押し出されてしまった場合
  • 単発で実行されるスクリプトのようなエージェントの場合 などは、質問のたびに read_file "$WIKI/index.md" というコマンドを実行して、目次を都度スキャン（読み込み）します。

3. 【超重要】ページが増えすぎてコンテキストに収まらなくなったら？

ここで一つの疑問が浮かびます。「Wikiが成長してページが1000件、2000件になったら、index.mdが巨大化してLLMのコンテキストを圧迫（またはトークン上限を突破）するのでは？」という点です。

ドキュメントでは、その場合の**「スケール（規模拡大）時のルール」**も明確に用意されています。

  • 分割ルール（Scaling rule）: 項目が200を超えたら、エージェントは自律的に _meta/topic-map.md という「テーマ別の親目次（メタインデックス）」を作成します。これにより、最初は親目次だけを読み、必要に応じて子目次を読むという階層構造になります。
  • 検索ツールの併用: 100ページを超えた大規模なWikiの場合、目次を読むだけでは限界があるため、search_files コマンドを使ってキーワード検索（grepのようなもの）を走らせるルールになっています。
  • 外部ツールの導入 (llm-wiki.mdに記載): さらに大規模になった場合は、qmd のようなローカルのマークダウン検索エンジン（ハイブリッド検索ツール）を導入し、エージェントにそれを使わせる（RAG的なアプローチを組み合わせる）ことが推奨されています。

まとめ

  • 初期（小〜中規模）： 毎回セッションの最初に index.md をコンテキストに丸ごと詰め込む。これでサクサク動く。
  • 成長後（大規模）： index.md を階層化し、部分的に読んだり、ローカル検索ツール（Scan）を組み合わせたりする構造に、LLM自身が自動的にシステムを変化させていく。

このように、人間の脳や一般的なファイルシステムと同じように、「まずは目次を覚え、大きくなったら検索に頼る」というスケーラブルな設計になっています。

User: 複数人でセッションを独立で立ち上げた時にwrite workerが一つではないのでindex.mdが最新にならなくない？そこの競合はどうしているの？

AI: 非常に鋭いご指摘です。まさにその通りで、複数のエージェント（Write Worker）が同時に動いた場合、index.md や log.md の競合（上書きによるデータの消失）が発生するリスクがあります。

提供されたドキュメント（SKILL.md と llm-wiki.md）を読み解くと、このシステムはリレーショナルデータベース（RDB）のような「トランザクション管理」や「排他制御（行ロック）」を持っていません。

では、チーム利用などの複数人環境において、この競合問題をどう想定し、どう回避する設計になっているのかを解説します。

1. ドキュメント上の解決策：Gitと同期ツールへの丸投げ

このパターンの根底にある思想は「単なるMarkdownファイルの集まりである」という点です。競合解決については、専用のシステムを組むのではなく、既存の強力なエコシステム（GitやObsidian Sync）に委ねるというアプローチを取っています。

  • Gitによる競合解決（llm-wiki.md より）:

    "The wiki is just a git repo of markdown files. You get version history, branching, and collaboration for free." （Wikiは単なるマークダウンのGitリポジトリです。バージョン履歴、ブランチ、コラボレーションが無料で手に入ります。） チームで運用する場合、Wiki全体をGitで管理することが前提となっています。エージェントAとエージェントBが同時に index.md を編集した場合、Gitのコミット時にマージコンフリクトが発生します。これを人間（もしくはコンフリクト解消専門のエージェント）が解消する、という力技が基本設計です。

  • Obsidian Syncによる同期（SKILL.md より）: サーバー上で obsidian-headless を使って同期する運用が紹介されています。Obsidian Syncの仕様上、同時に同じファイルが編集された場合は、片方を「同期競合ファイル（Sync conflict file）」として別名保存してデータを保護します。

2. ログファイルの工夫（Append-only）

履歴を残す log.md については、競合による破壊を最小限にするため、ドキュメント内で**「Append-only（追記のみ）」**と厳格に定義されています。 ファイルの末尾に追記するだけの処理であれば、OSレベルのファイルロックで一瞬待たされるだけで、データが完全に上書きされて消えるリスクは軽減されます。

3. 実際のチーム運用における「現実的な構成」

とはいえ、毎回Gitのコンフリクトが起きたり、index.md が先祖返りしたりしては実運用に耐えません。 ドキュメントの「チーム利用（Business/team）」の項目の意図を汲み取ると、実践的には以下のようなアーキテクチャの工夫が必要になります（※これはドキュメントの記載からの技術的な推測・応用です）。

解決案A：Write Workerを「1つ」に絞る（キューイング方式）

人間（ユーザー）は何人いても構いませんが、「Wikiに書き込む権限を持つエージェント」はシステム上に1つだけ（シングルトン）にしておきます。

  • メンバーAがSlackで「この議事録を追加して」と依頼。
  • メンバーBが別のタスクで「この資料をIngestして」と依頼。
  • これらは一旦「キュー（順番待ちリスト）」に入り、1つのバックグラウンドエージェントが順番に処理（Ingest）していく。
  • 各メンバーのチャット画面にいるエージェントは「Read専用（QueryとLintのみ実行可）」にしておく。

解決案B：書き込む「直前」に再読み込みさせる

SKILL.md のルール（SCHEMA.md）に、エージェントへの指示として以下を追記します。

「index.md や他のページを更新（Write）する際は、必ず書き込む直前に再度 read_file を実行し、最新の差分を確認してからマージして保存すること」

これだけでも、会話の最初に読み込んだ古い index.md を使って上書きしてしまう（ロストアップデート）事故は大幅に防げます。

まとめ

  • 競合は起きるのか？： はい、そのまま複数エージェントを立ち上げて同時書き込みさせると競合（先祖返り）が起きます。
  • どうしているのか？： システム自体に排他制御はなく、GitのマージコンフリクトやObsidianの競合ファイル機能に依存して「データが完全に消えること」を防ぐ設計です。
  • どうすべきか？： 本格的にチームで使うなら、Wikiを更新するバックグラウンドエージェントを1つに統合し、ユーザーからの依頼を順番に処理する「中央集権的な書き込み（キューイング）」のシステムを被せる必要があります。

User: 対象のコード(raw)が新しく書き変わった場合に都度更新をするの？どうやって管理しているの？

AI: ドキュメントの設計では、情報源（Web記事、社内ドキュメントなど）が書き換わった場合の変更検知と更新は、**「SHA-256（ハッシュ値）を使ったドリフト（乖離）検知」**によって厳格に管理されています。

具体的にどのように管理・更新しているのかを解説します。

1. 大前提：raw/ フォルダは「不変（Immutable）」である

まずルールとして、保存された生のファイル（raw/配下のマークダウンやPDFなど）を、エージェントや人間が直接編集（手直し）することは禁止されています。訂正や更新はすべてWikiページ（Layer 2）側で行うか、**「再取り込み（Re-ingest）」**によって元のファイルを最新版で上書きすることで行います。

2. 変更をどうやって検知するのか？（ハッシュ管理）

生データを raw/ に保存する際、エージェントはファイルの先頭に以下のようなメタデータ（YAMLフロントマター）を付与します。

---
source_url: https://example.com/article   # 元のURL
ingested: 2026-04-01                      # 取り込んだ日付
sha256: a1b2c3d4e5f6...                   # 本文のハッシュ値（重要）
---
（ここから下に実際のドキュメントの本文が続く）

一番重要なのが sha256 です。エージェントは本文の内容からハッシュ値（データの指紋のようなもの）を計算し、ここに記録しておきます。

3. いつ、どうやって更新（反映）されるのか？

システムが「ソースの書き換わり」を検知して更新するタイミングは、主に以下の2つです。

パターンA：同じURL（ファイル）を「再取り込み」した時

人間（または自動化された定期バッチ）が、「このURLの最新版をもう一度Ingestして」とエージェントに指示した場合です。

  1. エージェントは新しいデータを取得し、本文のハッシュ値を計算します。
  2. 保存されている sha256 と比較します。
  3. 完全に一致する場合： 「何も変わっていない」と判断し、処理を即座にスキップします（APIコストと時間の節約）。
  4. ハッシュが違う場合： 「情報源が更新された（Drift / ドリフトが発生した）」と判断し、生データを最新に上書きします。その後、新しい差分情報を元に、関連するWikiページを更新します。

パターンB：Wikiの「定期健診（Lint）」の時

ユーザーが「WikiをLint（チェック）して」と頼んだ際、エージェントは以下の作業をバックグラウンドで行います。

  1. raw/ 内のすべてのファイルを巡回し、現在の本文からハッシュ値を再計算します。
  2. もしフロントマターに書かれている sha256 と一致しないファイルがあった場合、**「記録されているハッシュと違う＝裏でこっそりソースファイルが書き換えられている（Source drift）」**として、人間に警告レポートを出します。

4. 更新時、Wikiの記述はどう書き換わるのか？（Update Policy）

情報源が新しくなり、Wikiのページを更新しなければならない場合、エージェントは以下の「更新ポリシー」に従います。

  • 日付の優先: 古い情報源よりも、新しい情報源（更新されたデータ）の記述を原則として優先します。
  • 【重要】矛盾（Contradictions）の管理: 元の記述と新しい情報が完全に食い違っている場合、エージェントは勝手に古い情報を消去（上書き）しません。 「2025年時点ではAと言っていたが、最新版ではBと言っている」というように両方を併記し、ページのメタデータに contested: true （議論・矛盾あり）とマークします。これにより、後で人間がレビューして判断できるようにしています。

まとめ

  • 管理方法: raw/ ファイルのメタデータに sha256 （ハッシュ値）を保存し、内容の一致・不一致で差分を管理する。
  • 更新の仕組み: 全ドキュメントを常に監視しているわけではなく、人間が再取り込み（Re-ingest）を指示した際や、定期健診（Lint）の際にハッシュを比較して、変更があれば関連Wikiページをアップデートする設計です。

User: あー、なるほど？プロジェクトのソースコードをraw/にするイメージではなくscrapの記事ページみたいなものをraw/にするイメージでいる？

AI: その通りです！完璧なご理解です。

この「LLM Wiki」における raw/（ソース＝情報源）は、プログラミングの「ソースコード（.py や .ts など）」のことではなく、まさに**「Web記事のスクラップ、論文、会議の議事録、チャットの履歴」などを放り込む場所**を指しています。

ドキュメント（SKILL.md）に定義されている raw/ の中身を見ると、その意図がはっきり分かります。

raw/
├── articles/       # Web記事、ブラウザからのスクラップ（クリッピング）
├── papers/         # PDFファイル、Arxivなどの論文
├── transcripts/    # 会議の書き起こし、インタビュー録、Slackのスレッド
└── assets/         # それらに付随する画像や図表

なぜソースコードではなく「記事やスクラップ」なのか？

このシステムは、プログラムを動かすためではなく、**「バラバラな情報（点）から、構造化された知識の辞書（線・面）を作り上げる」**ためのものだからです。

ユーザーがイメージされた「スクラップ」のアナロジーは非常に的確です。

  1. スクラップする (Ingest): ブラウザの拡張機能（Obsidian Web Clipperなど）を使って、気になった技術記事やニュースを raw/articles/ にポンと保存する。 （※これが、先ほどハッシュ値で差分管理すると言っていた対象です。元記事が更新されたら取り込み直します）
  2. LLMが咀嚼する: LLMがそのスクラップを読み、「この記事には『AIエージェント』という概念と、『Sam Altman』という人物が登場しているな」と理解する。
  3. Wiki（辞書）にコンパイルする: LLMが自律的に concepts/ai-agent.md や entities/sam-altman.md というページを更新・追記し、「この記事によれば〇〇である」と情報源（rawファイル）へのリンクを貼る。

開発プロジェクトで使うとしたら？

もしこれをソフトウェア開発のプロジェクトで使うとしたら、raw/ に入れるべきはリポジトリのコードそのものではありません。

  • ❌ 入れないもの：main.go, App.tsx
  • ⭕️ 入れるもの：「要件定義書」「顧客との打ち合わせの議事録（文字起こし）」「技術選定の際に参考にしたZenn/Qiitaの記事」「Slackでの仕様決定のやり取り」

これらを raw/ に放り込んでいくと、LLMがそれらを読み解いて「なぜその技術を選んだのか」「顧客の本当の要望は何か」「現在の未解決課題は何か」をまとめた**「完璧なプロジェクトの社内Wiki」**を自動で育ててくれる、というイメージです。

User: hermes agentもllm-wikiも知らない非開発者の友人に対話全体と添付ファイルを含めてこの機能についての説明の記事を書いてほしい。こういうものが存在してこういう感じで使えると便利だよみたいな説明で。

AI: プログラミングや難しいAIの専門用語（開発ツールやコードの話など）を極力省き、**「いまAIの世界でこんなに便利な使い方が生まれているよ！」**という読み物として、ご友人向けの記事風にまとめました。

そのままブログやnote、メッセージアプリに貼り付けて読んでもらえる構成にしています。

タイトル：AIを「使い捨てのチャット相手」から「専属の図書館員」へ。自分の知識が複利で増える『AI Wiki』の衝撃

ChatGPTのようなAIを使っていて、こんな不満を感じたことはありませんか？

  • 「この前AIに要約してもらった記事の内容、どこにいったっけ…」
  • 「複数の資料をまたいだ複雑な質問をすると、AIがうまく答えてくれない」
  • 「毎回毎回、AIにPDFや記事をアップロードして最初から読ませるのが面倒くさい」

今のAIはとても賢いですが、基本的には「その場限りの会話」しかできません。あなたが与えた情報を読んで答えてくれますが、ブラウザを閉じれば忘れてしまいます。

そんな弱点を克服し、**「あなたが読んだ記事やメモをすべて記憶し、勝手に整理・連携して、あなた専用のWikipedia（百科事典）を作り上げてくれる」**という全く新しいAIの使い方がいま注目されています。

それが**「LLM Wiki（AI Wiki）」**と呼ばれる仕組みです。

普通のAIと「AI Wiki」は何が違うの？

普通のAI（専門用語でRAGと呼ばれたりします）は、**「毎回ゼロから本を読み直す学生」**のようなものです。 あなたが「Aプロジェクトの進捗はどうなってる？」と聞くと、AIはあわてて議事録のフォルダを全部スキャンし、その場で答えを作ります。次に似た質問をしても、また同じように最初からスキャンし直します。これでは知識がまったく蓄積しません。

一方「AI Wiki」は、**「超優秀な専属の図書館員」**です。 あなたが面白かったWeb記事や議事録を「とりあえずこの箱に入れといて」と渡すだけで、AIの図書館員は裏でこんなことをしてくれます。

  1. 新しい記事を読む
  2. 記事の要約ページを作る
  3. 記事に出てきた「人物」「会社」「専門用語」の個別ページを作る（または更新する）
  4. 既存のページと「ここに関連しているよ」とリンク（相互参照）を繋ぐ
  5. 全体の「目次（インデックス）」を最新状態に更新する

あなたが次に質問するとき、AIは生の議事録を漁るのではなく、自分が綺麗に整理した「目次」と「まとめページ（Wiki）」だけを読んで答えてくれます。

人間が本を読むとき、全ページをパラパラめくるのではなく、まず「目次」を見て必要なページだけを開きますよね？ AI Wikiも同じことをするため、大量の情報をストックしても動作が軽く、めちゃくちゃ賢い答えが返ってくるんです。

どんな風に使えるの？（活用イメージ）

この仕組み、実はエンジニアだけでなく、いろんな人の日常や仕事で爆発的な威力を発揮します。

💡 1. めんどくさい「社内・チームの議事録まとめ」が全自動に

毎日のミーティングの音声書き起こしや、チャットのやり取り。これをAIに放り込むだけで、AIが勝手に「プロジェクト〇〇の現在地」「クライアントA社が抱えている課題」「未解決のタスクリスト」というWikiページを自動で更新し続けてくれます。新入社員が入ってきても「このWikiの『概要』ページを読んで」で済みます。

💡 2. 趣味や読書、調べ物の「ディープダイブ（深掘り）」に

例えば、登場人物が多すぎる長編ファンタジー小説や海外ドラマ。読んだ章（エピソード）のあらすじをAIに渡すと、AIが「登場人物辞典」「国や魔法の相関図」「未回収の伏線一覧」のWikiを裏で作ってくれます。旅行の計画や、特定テーマ（健康法、歴史など）のスクラップブックとしても最強です。

💡 3. 自分専用の「ライフログ・取扱説明書」として

毎日の日記、気になったニュース、受けた健康診断の結果。これらをただ放り込んでいくだけで、AIが「あなたの思考の傾向」「過去の体調不良のパターン」「いま関心を持っていること」を分析し、あなた自身のWikipediaを作り上げます。

人間は「考えること」だけに集中できる

今まで、EvernoteやNotionに情報をため込んでも、結局「整理」が面倒になってゴミ屋敷化してしまう人がほとんどでした。情報をリンクさせたり、古い情報を更新したりといった**「情報の簿記（メンテナンス作業）」は、人間がやるには退屈で面倒くさすぎる**からです。

AI Wikiの最大の革命は、その一番面倒なメンテナンス作業を、文句一つ言わないAIが全自動でやってくれる点にあります。

情報源が古い情報と矛盾していたら、AIは勝手に上書きせず、「過去の資料ではこう言っていますが、最新の資料ではこうなっています」とフラグを立てて人間に知らせてくれます。情報の鮮度まで管理してくれるのです。

「人間は、面白そうな記事を見つけてきたり、AIに鋭い質問を投げかけるだけ。面倒なファイリングと整理はすべてAIに任せる」

まだ一部のギーク（ITオタク）たちが使い始めたばかりの概念ですが、数年後には誰もが「自分専用のAI Wiki（AIが育てる脳の拡張ツール）」を持つ時代が来るかもしれません。情報を「使い捨て」にするのをやめて、「複利で育てる」感覚。ちょっと体験してみたくなりませんか？

(※補足：現在この機能は、「AIエージェント」と呼ばれる自律型AIに特定のルール（プロンプトや設定ファイル）を読み込ませることで、個人のパソコン内で実現できるようになっています。)

User: 今回の回答のなかで真面目に考えず類推やアナロジーで回答していた部分を箇条書きで明らかにしてください。

また表現のためにあるいはドキュメントとしてまとめるために触れられなかった今回の対話中での重要な要素も箇条書きで明らかにしてください。

AI: ご友人向けの記事では、親しみやすさと直感的な理解を優先したため、技術的な実態をあえて「比喩」に置き換えた部分や、システムの根幹に関わる重要な制約を削削ぎ落とした部分があります。

それぞれ、論理的な正確性の観点から明らかにします。

1. 類推やアナロジー（比喩）で回答した部分

技術的なプロセスを人間的な動作に置き換えた箇所です。

  • 「専属の図書館員」という表現
    • 実態: 実際には「自律型プログラム（エージェント）」が、あらかじめ決められた「指示書（SCHEMA.md）」のルールに従って、ファイルの読み書きコマンドを機械的に実行しているだけです。意志を持って整理しているわけではありません。
  • 「記事を箱に入れる」という表現
    • 実態: 特定のディレクトリ（raw/）へのファイル保存と、そのファイルに対するハッシュ値（SHA-256）の計算、およびメタデータの付与というデジタル処理です。
  • 「勝手に整理・連携して」という表現
    • 実態: 自然に整理されるわけではなく、エージェントが「既存の目次を読む」「関連キーワードで検索する」「差分を抽出してマージする」という一連の計算ステップを、指示された手順通りに踏んでいる結果です。
  • 「図書館員が裏でやってくれる」という表現
    • 実態: 常に裏で動いている（常駐している）わけではなく、ユーザーが「エージェントとの対話セッション」を立ち上げ、コマンドを実行した瞬間にのみ動く計算プロセスです（※自動化設定をしない限り）。
  • 「情報の簿記（メンテナンス）」という表現
    • 実態: テキストファイル内のリンク構造の整合性チェック、目次ファイルへの追記、および重複チェックという「文字列操作」と「ファイル操作」の連続です。

2. 表現や構成のために触れなかった重要な要素

この記事では「便利さ」を強調するためにあえて伏せましたが、システムを構築・運用する上で欠かせない技術的トピックです。

  • 「SHA-256ハッシュ」によるデータ整合性管理
    • 情報源が書き換わったことを検知する「指紋（ハッシュ）」の仕組みは、このシステムの信頼性の根幹ですが、非エンジニアには難解なため除外しました。
  • 「競合（コンフリクト）」と「書き込み制限」の問題
    • 対話の中で議論した「複数のエージェントが同時に目次を書き換えるとデータが壊れる」という重大な制約（Write Workerの競合問題）は、利便性の説明を優先して触れませんでした。
  • 「指示書（SCHEMA.md）」による厳格な制約
    • AIが好き勝手に整理するのではなく、人間が定義した「タグのルール」や「ページを分割する基準」に縛られて動く「プログラム的な性質」については詳しく説明しませんでした。
  • 「スケーラビリティ（規模の限界）」への対応
    • ページ数が数百を超えると「目次を全部読む」という手法が通用しなくなり、検索エンジンや高度なフォルダ階層化が必要になるという、成長に伴うシステムの複雑化については省略しました。
  • 「Git」や「Obsidian Sync」によるインフラ依存
    • このシステムが「ただのテキストファイルの集まり」として成立するためには、バージョン管理（Git）や同期ツール（Obsidian）という外部の強力なインフラを使いこなすことが前提であるという点は、導入のハードルになるため軽く触れるに留めました。
  • 「マークダウン（Markdown）」という形式への依存
    • すべての知識が特定の記法（マークダウン）で書かれ、ページ間リンクも [[リンク名]] という特殊な書き方に依存しているという、フォーマットの制約については触れませんでした。

自己評価

ご友人向けの記事は、「情報のストックが自動で知的な資産に変わる」という体験価値（ベネフィット）にフォーカスしています。そのため、その裏側にある「ファイル操作の競合制御」「ハッシュによる整合性」「指示書による計算コストの最適化」といった実装上の泥臭い苦労や制約は意図的に隠蔽されています。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment