LLM Wiki — Knowledge Distillation Pattern

永続的で累積的なナレッジベースを管理しています。wiki はチャットボットではなく、知識が一度蒸留され最新に保たれるコンパイル成果物です。クエリのたびに再導出されることはありません。

3層アーキテクチャ

Layer 1: Raw Sources（不変）

ユーザーの元の文書 — 記事、論文、ノート、PDF、会話ログ、ブックマーク、および画像（スクリーンショット、ホワイトボード写真、図、スライドキャプチャ）。これらはシステムによって変更されることはありません。ユーザーが保管している場所に存在します（.env の OBSIDIAN_SOURCES_DIR で設定）。画像はファーストクラスのソースです：取り込みスキルは Read ツールのビジョンサポートを経由して画像を読み取り、解釈された内容を逐語的に転記されたテキストでない限り推論されたものとして扱います。画像の取り込みにはビジョン対応のモデルが必要です — ビジョンサポートがないモデルは画像ソースをスキップし、どのファイルがスキップされたかを報告する必要があります。

raw sources は「ソースコード」と考えてください — 権威的ですが直接クエリするのは困難です。

Layer 2: The Wiki（LLM保守）

カテゴリ別に組織された相互接続されたObsidian互換マークダウンファイルの集合。これはコンパイルされた知識です — 統合され、相互参照でき、ナビゲート可能です。各ページには以下が含まれます：

• YAML frontmatter（title、category、tags、sources、timestamps）
• 関連概念を接続する Obsidian [[wikilinks]]
• 明確な出所 — すべての主張はソースにトレーサブル

wiki は .env の OBSIDIAN_VAULT_PATH で設定されたパスに存在します。

Layer 3: The Schema（このスキル + config）

wiki がどのように構造化されるかを支配するルール — カテゴリ、慣例、ページテンプレート、運用ワークフロー。スキーマは LLM に wiki をどのように保守するか指示します。

Wiki Organization

vault には2レベルの構造があります：categories（どのような知識か）と projects（知識がどこから来たか）。

Categories

ページをこれらのデフォルトカテゴリに整理します（.env で カスタマイズ可能）：

Category	Purpose	Example
concepts/	Ideas、theories、mental models	concepts/transformer-architecture.md
entities/	People、orgs、tools、projects	entities/andrej-karpathy.md
skills/	How-to knowledge、procedures	skills/fine-tuning-llms.md
references/	Summaries of specific sources	references/attention-is-all-you-need.md
synthesis/	Cross-cutting analysis across sources	synthesis/scaling-laws-debate.md
journal/	Timestamped observations、session logs	journal/2024-03-15.md

Projects

知識はしばしば特定のプロジェクトに属します。projects/ ディレクトリはこれを反映します：

$OBSIDIAN_VAULT_PATH/
├── projects/
│   ├── my-project/
│   │   ├── my-project.md      ← project overview (named after project)
│   │   ├── concepts/          ← project-scoped category pages
│   │   ├── skills/
│   │   └── ...
│   ├── another-project/
│   │   └── ...
│   └── side-project/
│       └── ...
├── concepts/                   ← global (cross-project) knowledge
├── entities/
├── skills/
└── ...

知識がプロジェクト固有の場合（特定のコードベースにのみ適用されるデバッグ技術、プロジェクト固有のアーキテクチャ決定）、projects/<project-name>/<category>/ の下に配置します。

知識が一般的な場合（「React Server Components」のような概念、「Andrej Karpathy」のような人物、広く適用可能なスキル）、グローバルカテゴリディレクトリに配置します。

相互参照： プロジェクトページはグローバルページに [[wikilink]] で接続し、その逆も同様です。プロジェクトの概要ページは、そのプロジェクトに関連する主要な概念、スキル、エンティティページにリンクする必要があります — プロジェクトの下に存在しようとグローバルに存在しようと。

命名ルール： プロジェクト概要ファイルは <project-name>.md という名前である必要があります。_project.md ではありません。Obsidian のグラフビューはファイル名をノードラベルとして使用します — _project.md はすべてのプロジェクトをグラフ内で _project として表示させ、読めなくなります。したがって projects/my-project/my-project.md、projects/another-project/another-project.md などです。

各プロジェクトディレクトリには次のように構造化された概要ページがあります：

---
title: My Project
category: project
tags: [ai, web, backend]
source_path: ~/.claude/projects/-Users-name-Documents-projects-my-project
created: 2026-03-01T00:00:00Z
updated: 2026-04-06T00:00:00Z
---

# My Project

このプロジェクトが何かについての1段落の要約。

## Key Concepts
- [[concepts/some-api]] — コア機能に使用
- [[projects/my-project/concepts/main-architecture]] — プロジェクト固有のアーキテクチャ

## Related
- [[entities/some-service]] — デプロイメントプラットフォーム

Special Files

すべての wiki には、ルートにこれらのファイルがあります：

index.md

カテゴリ別に整理されたコンテンツ指向カタログ。各エントリには1行の要約とタグがあります。すべての取り込み操作の後に再構築します。フォーマット：

# Wiki Index

## Concepts
- [[transformer-architecture]] — sequence modeling の支配的なアーキテクチャ ( #ml #architecture)
- [[attention-mechanism]] — transformers のコア構成要素 ( #ml #fundamentals)

## Entities
- [[andrej-karpathy]] — AI researcher、educator、former Tesla AI director ( #person #ml)

フォーマットルール：開き括弧 ( の後に空白を追加し、タグを追加します。 ❌ しないこと：description (#tag) — タグ解析が壊れる ✅ すること：description ( #tag) — 適切な間隔とタグ解析

log.md

すべての操作を追跡する時系列の追記専用レコード。各エントリは解析可能です：

## Log

- [2024-03-15T10:30:00Z] INGEST source="papers/attention.pdf" pages_updated=12 pages_created=3
- [2024-03-15T11:00:00Z] QUERY query="How do transformers handle long sequences?" result_pages=4
- [2024-03-16T09:00:00Z] LINT issues_found=2 orphans=1 contradictions=1
- [2024-03-17T10:00:00Z] ARCHIVE reason="rebuild" pages=87 destination="_archives/..."
- [2024-03-17T10:05:00Z] REBUILD archived_to="_archives/..." previous_pages=87

.manifest.json

取り込まれたすべてのソースファイルを追跡します — パス、タイムスタンプ、生成された wiki ページ。これはデルタシステムの基盤です。完全なスキーマについては wiki-status スキルを参照してください。

マニフェストは以下を有効にします：

• Delta computation — 前回の取り込み以降に新規または変更されたもの
• Append mode — デルタのみ処理、すべてではなく
• Audit — どのソースがどの wiki ページを生成したか
• Staleness detection — ソースが変更されたが wiki ページが更新されていない

Page Template

新しい wiki ページを作成する場合、この構造を使用します：

---
title: Page Title
category: concepts
tags: [ml, architecture]
aliases: [alternate name]
relationships:
  - target: "[[concepts/related-concept]]"
    type: extends
sources: [papers/attention.pdf]
summary: 1～2文、≤200 chars、読者（または別のスキル）がこのページを開かずにプレビューできるようにするもの。
provenance:
  extracted: 0.72
  inferred: 0.25
  ambiguous: 0.03
base_confidence: 0.65
lifecycle: draft
lifecycle_changed: 2024-03-15
created: 2024-03-15T10:30:00Z
updated: 2024-03-15T10:30:00Z
---

# Page Title

このページが何をカバーするかについての1段落の要約。

## Key Ideas

- ソースの中心的な主張、直接言い換え。
- ソースが言及しないが暗に意味する一般化。 ^[inferred]
- 2つのソースが異なる数字。 ^[ambiguous]

関連ページに接続するために [[wikilinks]] を使用します。

## Open Questions

未解決または追加のソースが必要なもの。

## Sources

- [[references/attention-is-all-you-need]] — Original paper

Provenance Markers

wiki ページ上のすべての主張は、3つの出所状態のいずれかを持ちます。インラインでマークして、読者（および将来の取り込みパス）がシグナルと統合を区別できるようにします。

State	Marker	Meaning
Extracted	(マーカーなし — デフォルト)	ソースが実際に言うことの言い換え。
Inferred	^[inferred] suffix	LLM 合成主張 — ソースが直接述べない接続、一般化、または含意。
Ambiguous	^[ambiguous] suffix	ソースが異なる、またはソースが曖昧である。

例：

- Transformers は RNN と異なり、位置全体で並列化します。
- これが最新のハードウェアでより良くスケールする理由です。 ^[inferred]
- GPT-4 はおおよそ 13T トークンで訓練されました。 ^[ambiguous]

なぜこの構文か：

• ^[...] は Obsidian ではフットノートに隣接しています — きれいにレンダリングされ、[[wikilinks]] と衝突することはありません。
• インライン（suffix）なので、単一の箇条書きは単一の箇条書きのままです。
• デフォルト = extracted は、マーカーなしの既存ページが有効なままであることを意味します。

Frontmatter summary： ページレベルで大まかな混合をオプションで表示して、ユーザーが読まずに推測が多いページをスキャンできるようにします：

provenance:
  extracted: 0.72   # マーカーなしの文/箇条書きの大まかな割合
  inferred: 0.25
  ambiguous: 0.03

これらは、作成/更新時に取り込みスキルによって書かれたベストエフォート番号です。wiki-lint はそれらを再計算し、ドリフトをフラグします。ブロックはオプションです — それなしのページは慣例により完全に抽出されたものとして扱われます。

Typed Relationships

ページ本体の単純な [[wikilinks]] はセマンティック重みを持ちません — 「関連している」を示しますが、どのように関連しているかは示しません。オプションの relationships: frontmatter ブロックは、ナレッジグラフに型付きの方向性のあるエッジを追加します。

relationships: ブロック

relationships:
  - target: "[[Transformer Architecture]]"
    type: extends
  - target: "[[LSTM]]"
    type: contradicts
  - target: "[[Attention Mechanism]]"
    type: implements

各エントリには2つの必須フィールドがあります：

• target — ウィキリンク（OBSIDIAN_LINK_FORMAT と同じフォーマットを使用）から関連ページへ
• type — 許可されたセマンティックタイプの1つ（下記参照）

Allowed relationship types

Type	Meaning	Example
extends	このページはターゲットの上に構築されるか、または一般化される	GPT は Transformer Architecture を拡張
implements	このページはターゲット概念の具体的な実現である	BERT は Masked Language Modelling を実装
contradicts	このページの主張はターゲットと矛盾するか、または反論する	Evidence A は Evidence B と矛盾
derived_from	このページはターゲットに基づくか、または適応されている	Fine-tuning は Transfer Learning から派生
uses	このページはターゲットに依存するか、またはターゲットに依存している	RAG は Vector Databases を使用
replaces	このページはターゲットに取って代わるか、または廃止する	GPT-4 は GPT-3 に取って代わる
related_to	キャッチオール：関連するが、より強い方向型がない	Concept A は Concept B に関連

Rules

• オプションフィールド — 型付き関連が不明な場合は、ブロック全体を省略します。タグなしのウィキリンクは有効なままで、wiki-export によって related_to として扱われます。
• 重複しない — [[foo]] が既にインラインウィキリンクとして表示されている場合、relationships: エントリはそれを型で充実させるだけです；2番目のリンクではありません。
• Direction matters — このページを宣言するのがソースです；target は宛先です。このページの観点からのみ関係を宣言します。
• 捏造しない — ソース資料が関係の方向と型を明確にする場合のみ、型付きエントリを追加します。不明な場合は、related_to を使用するか省略します。

relationships: を読むスキル：wiki-export（型付きエッジを発行）、cross-linker（リンクを推論する場合に型付きエントリを書き込み）、wiki-query（答えで型を表示する可能性あり）。

Confidence and Lifecycle

すべてのページは2つの直交する信頼シグナルとオプションの後継リンクを持ちます。

Required fields

base_confidence: 0.65          # [0.0, 1.0] — 時間に依存しない品質推定。1回保存、コンテンツ変更時に再計算。
lifecycle: draft               # draft | reviewed | verified | disputed | archived
lifecycle_changed: 2024-03-15  # ISO date of last state transition
# lifecycle_reason: "..."      # optional free-text — 状態が変更された理由；wiki-query で表示
# superseded_by: "[[new-page]]" # wikilink；lifecycle=archived の場合のみ

lifecycle_reason と superseded_by はオプションです。決して捏造しないでください。

Confidence formula

base_confidence = source_count_score * 0.5 + source_quality_score * 0.5

source_count_score   = min(distinct_source_ids / 3, 1.0)
source_quality_score = avg(quality score per distinct source_id)

Source-quality scores（最高にマッチするバケットを使用）：

Bucket	Score	Examples
paper	1.0	arXiv、conference proceedings
official	0.9	*.gov、vendor docs
documentation	0.85	well-maintained third-party docs
book	0.8	books、technical references
repository	0.75	GitHub READMEs、codebases
blog	0.55	personal blogs
session_transcript	0.5	conversation history
forum	0.4	Stack Overflow、HN、Reddit
unknown	0.4	catch-all
llm_generated	0.3	LLM self-reflections

source_id は安定した per-source identifier です — 同じブログの3つのコピーを3つの異なるソースとしてカウントされるのを防ぎます：

Source type	source_id rule
Academic paper	DOI > arXiv ID > <author>-<year>-<slug>
GitHub repo	github.com/<owner>/<repo>
Documentation site	<canonical-host>/<product>
Blog post	<host>/<author>
Session transcript	<agent>/<session-id>
Other	<canonical-url>

Per-skill defaults（取り込みスキルは自動的にこれを計算）：

Skill	base_confidence	lifecycle
ingest-url	0.17 + 0.5 × classify(url)	draft
wiki-ingest (single doc)	per-source classifier	draft
wiki-ingest (multi-doc)	min(N/3,1)×0.5 + avg_q×0.5	draft
wiki-research	varies、often 0.85+	draft
wiki-capture	0.42	draft
*-history-ingest	0.42	draft
wiki-update	0.59	draft
wiki-synthesize	min(input_pages.base_confidence)	draft
data-ingest	0.37	draft

Lifecycle state machine

5つの状態。stale は状態ではありません — これは計算されたオーバーレイです：is_stale = (today − updated) > 90 days。

State	Entered by	Notes
draft	初回書き込み時の任意の取り込みスキル	すべての新規ページのデフォルト
reviewed	人的編集のみ
verified	人的編集のみ	時間だけで verified ページが降格することはない
disputed	手動編集のみ	archived を除くすべての状態を表示でオーバーライド
archived	手動編集、または superseded_by を設定する取り込みスキル	Terminal

取り込みスキルだけが draft を設定します。他のすべての遷移には人的編集が必要です。状態が変更されるたびに lifecycle_changed を更新します。

Retrieval Primitives

vault を読むことは、すべての読み取り側スキルの支配的なコストです。質問に答えられる最も安いプリミティブを使用し、より安いものが不十分な場合のみ拡大してください。vault からコンテンツが必要なスキルは、全ページ読み取りに直接ジャンプするのではなく、このテーブルに従う必要があります。

Need	Primitive	Relative cost
ページが存在しますか？タイトル/カテゴリ/タグは？	index.md を読む；frontmatter ブロックを Grep（ファイルヘッドの ^--- ブロックをターゲットするパターンでスコープ）	最も安い
1～2文のページプレビュー	frontmatter の summary: フィールドを読む	安い
ページ内の特定の主張またはセクション	Grep -A <n> -B <n> "<term>" <file> — マッチング行とコンテキストのみを返す	中程度
Whole-page content	Read <file>	Expensive — 最後の手段
ページ間の関係	vault 全体で Grep "\[\[.*?\]\]"、または既知のページからウィキリンクを歩く	ケースバイケース

ルール： より安いプリミティブが質問に答えられない場合のみ拡大します。summary: フィールドだけで答えられる場合は、ページ本体を読まないでください。-A 10 -B 2 で grep されたセクションが主張を与える場合は、ページ全体を読まないでください。15行を読むために開かれた500行のページは、485行の無駄なトークンです。

なぜこれが重要か： 20ページの vault では全 vault スキャンで逃げられます。200ページの vault では逃げられません。上記のプリミティブは、スキルフレームワークが大規模な vault にスケーリングする方法です（データベースなし）。

このテーブルを使用するスキル：wiki-query、cross-linker、wiki-lint、wiki-status（insights mode）。vault を読む新しいスキルは、パターンを再発明するのではなく、このセクションを引用する必要があります。

Core Principles

1. Compile、don't retrieve. wiki は事前コンパイルされた知識です。ソースを取り込む場合、すべての関連ページを更新します — ソースの要約を作成するだけではありません。

2. Compound over time. 各取り込みは wiki をより大きくするのではなく、より賢くします。新しい情報を既存ページにマージし、矛盾を解決し、相互参照を強化します。

3. Provenance matters. すべての主張はソースにトレーサブルである必要があります。ページを更新する場合、どのソースが更新を促したかに注記してください。

4. Mark inferences. デフォルト文は抽出されます。合成された主張を ^[inferred] でマークし、争点となっている主張を ^[ambiguous] でマークします。推測を隠す wiki は静かに腐ります；それをマークする wiki は信頼できたままです。

5. Human curates、LLM maintains. 人間は、追加するソースと質問する内容を決定します。LLM は事務処理を処理します — 相互参照を更新し、一貫性を維持し、矛盾に注記します。

6. Obsidian is the IDE. ユーザーは Obsidian で wiki を参照して探索します。有効な Obsidian markdown と動作するウィキリンクが必要です。

Link Format

wiki ページを接続するすべての内部リンクは、解決済みconfig の OBSIDIAN_LINK_FORMAT によって制御されます（デフォルト：wikilink）。

Setting	Syntax	Example
wikilink (default)	[[path/to/page]] or [[path/to/page|display text]]	[[concepts/foo|foo]]
markdown	[display text](relative/path.md)	[foo](../concepts/foo.md)

Generating markdown-format links

OBSIDIAN_LINK_FORMAT=markdown の場合：

1. 現在のファイルのディレクトリからターゲット .md ファイルへのパスを計算します。必要に応じて .. を使用して上っていきます。
2. ページタイトルまたは自然なフレーズを表示テキストとして使用します。
3. .md 拡張子を常に含めます。

Current file	Target	Relative link
index.md	concepts/foo.md	[foo](concepts/foo.md)
concepts/foo.md	entities/bar.md	[bar](../entities/bar.md)
projects/my-project/my-project.md	concepts/foo.md	[foo](../../concepts/foo.md)
projects/my-project/concepts/arch.md	entities/bar.md	[bar](../../../entities/bar.md)

[[path\|display text]] ウィキリンク形式は Markdown モードで [display text](relative/path.md) にマップされます。

Scope： この設定は、新規に書き込まれた、またはアップデートされたリンクのみに影響します。既存の vault コンテンツは決して自動的に移行されません — 古いリンクを変換したいユーザーは cross-linker または wiki-lint スキルを実行できます。

すべての書き込みスキルは、リンクを生成する前に config から OBSIDIAN_LINK_FORMAT を読み込み、正しい形式を適用します。

Config Resolution Protocol

すべてのスキルは、このアルゴリズムを使用して config を解決する必要があります — .env または ~/.obsidian-wiki/config を直接ハードコードしないでください。 これにより、単一 vault、マルチ vault、プロジェクトローカル、および VPS セットアップがすべて正しく機能します。

Resolution order

1. Walk up from CWD — 現在のディレクトリ、次に各親から .env ファイルを検索します。$HOME まで。OBSIDIAN_VAULT_PATH を含む最初の .env で停止します。
2. Global config — ローカル .env が見つからない場合、~/.obsidian-wiki/config を読みます。
3. Prompt setup — どちらも存在しない場合、ユーザーに伝えます：「config が見つかりません。wiki-setup を実行して wiki を初期化してください。」

find_config() {
  dir="$PWD"
  while [[ "$dir" != "$HOME" && "$dir" != "/" ]]; do
    [[ -f "$dir/.env" ]] && grep -q "OBSIDIAN_VAULT_PATH" "$dir/.env" && { echo "$dir/.env"; return; }
    dir="$(dirname "$dir")"
  done
  [[ -f "$HOME/.obsidian-wiki/config" ]] && { echo "$HOME/.obsidian-wiki/config"; return; }
  echo ""
}

Vault-scoped state

ランタイム状態を書き込むスキル（例えば daily-update）は、その状態をグローバルパスではなく解決済み vault にスコープする必要があります。使用します：

VAULT_ID=$(echo "$OBSIDIAN_VAULT_PATH" | md5sum 2>/dev/null || md5 -q - <<< "$OBSIDIAN_VAULT_PATH" | cut -c1-8)
STATE_DIR="$HOME/.obsidian-wiki/state/$VAULT_ID"

Standard "Before You Start" block

すべてのスキルのセットアップセクションは以下を読む必要があります：

Resolve config — llm-wiki/SKILL.md の Config Resolution Protocol に従います。CWD から .env を上にウォークし、~/.obsidian-wiki/config にフォールバック、それ以外はセットアップを促します。これにより OBSIDIAN_VAULT_PATH とツール固有のパスオーバーライドが与えられます。

Environment Variables

wiki は環境変数（.env.example を参照）を通じて設定されます。必須な変数は vault パスだけです — それ以外はすべて合理的なデフォルトを持ちます。

• OBSIDIAN_VAULT_PATH — wiki が存在する場所 (必須)
• OBSIDIAN_SOURCES_DIR — raw source documents が存在する場所
• OBSIDIAN_CATEGORIES — カンマ区切りのカテゴリリスト
• CLAUDE_HISTORY_PATH — Claude conversation data を検索する場所
• CODEX_HISTORY_PATH — Codex session data を検索する場所
• HERMES_HOME — Hermes agent data を検索する場所
• OPENCLAW_HOME — OpenClaw data を検索する場所
• COPILOT_HISTORY_PATH — Copilot session data を検索する場所
• OBSIDIAN_LINK_FORMAT — Internal link syntax：wikilink（デフォルト）または markdown

API キーは必要ありません — これらのスキルを実行している agent には、組み込みの LLM アクセスが既にあります。

Modes of Operation

wiki は3つの取り込みモードをサポートしています：

Mode	When to use	What happens
Append	小規模なデルタ、段階的な更新	マニフェスト経由でデルタを計算、新規/変更されたソースのみ取り込み
Rebuild	大きなドリフト、新規スタートが必要	現在の wiki を _archives/ にアーカイブ、クリア、すべてのソースを再処理
Restore	以前に戻す必要があります	前のアーカイブを復元

wiki-status を使用してデルタを確認し、append vs rebuild の推奨を取得します。アーカイブ/再構築/復元操作には wiki-rebuild を使用します。

Reference

特定の操作の詳細については、関連スキルを参照してください：

• wiki-status — Audit what's ingested、compute delta、recommend append vs rebuild
• wiki-rebuild — Archive current wiki、rebuild from scratch、or restore from archive
• wiki-ingest — Distill source documents into wiki pages
• claude-history-ingest — Ingest Claude conversation history
• codex-history-ingest — Ingest Codex CLI session history
• data-ingest — Ingest any raw text data
• wiki-query — Answer questions against the wiki
• wiki-lint — Audit and maintain wiki health
• wiki-setup — Initialize a new vault