llm-wiki

LLM Wiki — ナレッジ蒸留パターン

永続的に蓄積され、価値が高まっていくナレッジベースを維持します。この Wiki はチャットボットではなく、コンパイルされた成果物です。ナレッジは一度蒸留され、クエリのたびに再導出されるのではなく、最新の状態に保たれます。

3 層アーキテクチャ

レイヤー 1：生ソース（不変）

ユーザーの元のドキュメントです。記事、論文、メモ、PDF、会話ログ、ブックマーク、画像（スクリーンショット、ホワイトボードの写真、図、スライドのキャプチャ）が含まれます。これらはシステムによって変更されることはありません。ユーザーが保管している場所に置かれています（.env の OBSIDIAN_SOURCES_DIR で設定）。画像も第一級のソースです。取り込みスキルは Read ツールの視覚機能を使って画像を読み取り、逐語的に書き起こされたテキストでない限り、解釈した内容を推定情報として扱います。画像の取り込みには視覚機能に対応したモデルが必要です。視覚機能に対応していないモデルは画像ソースをスキップし、スキップしたファイルを報告してください。

生ソースは「ソースコード」のようなものです。信頼できる一方で、直接クエリするのは困難です。

これを、保管庫内の _raw/ ステージングフォルダーと混同しないでください。これは別のもので、すばやく取り込んだメモや、昇格を待つ下書き用の一時的な受信フォルダーです（wiki-capture と wiki-ingest を参照）。このフォルダー内のファイルはレイヤー 1 のソースではありませんが、コピーがほかにないものもあるため、wiki-ingest は昇格時にファイルを削除するのではなく移動します。

レイヤー 2：Wiki（LLM によって保守）

カテゴリ別に整理された、相互に関連する Obsidian 互換の Markdown ファイルの集まりです。これはコンパイルされたナレッジであり、統合され、相互参照が追加され、たどりやすくなっています。各ページには以下が含まれます。

• YAML フロントマター（タイトル、カテゴリ、タグ、ソース、タイムスタンプ）
• 関連する概念をつなぐ Obsidian の [[wikilinks]]
• 明確な出典情報 — すべての主張をソースまでたどれます

Wiki は .env の OBSIDIAN_VAULT_PATH で設定されたパスにあります。

レイヤー 3：スキーマ（このスキル + 設定）

Wiki の構成方法を定めるルールです。カテゴリ、規約、ページテンプレート、運用ワークフローが含まれます。スキーマは、LLM に Wiki の保守方法を指示します。

Wiki の構成

保管庫は 2 つの階層で構成されます。カテゴリ（ナレッジの種類）とプロジェクト（ナレッジの出所）です。

カテゴリ

ページは、次のデフォルトカテゴリに整理します（.env でカスタマイズできます）。

カテゴリ	目的	例
concepts/	アイデア、理論、メンタルモデル	concepts/transformer-architecture.md
entities/	人、組織、ツール、プロジェクト	entities/andrej-karpathy.md
skills/	方法に関するナレッジ、手順	skills/fine-tuning-llms.md
references/	特定のソースの要約。学術論文には下記の「論文詳細分析テンプレート」を使用	references/attention-is-all-you-need.md
synthesis/	複数のソースにまたがる横断的な分析	synthesis/scaling-laws-debate.md
journal/	タイムスタンプ付きの観察記録、セッションログ	journal/2024-03-15.md

プロジェクト

ナレッジは特定のプロジェクトに属することがよくあります。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.md ではなく、<project-name>.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

One-paragraph summary of what this project is.

## Key Concepts
- [[concepts/some-api]] — used for core functionality
- [[projects/my-project/concepts/main-architecture]] — project-specific architecture

## Related
- [[entities/some-service]] — deployment platform

特別なファイル

すべての wiki のルートには、次のファイルがあります。

obsidian-wiki memory を使って作成し、手作業では編集しないでください。 index.md、 log.md、hot.md、および _meta/ のテーブルは、共通のアドバイザリロックを使用して アトミックに書き込まれます。並行実行中に手作業で編集すると、後から書き込まれた内容が 失われます。obsidian-wiki memory sync <VERB> key=value を使うと、3つの処理を 1回の呼び出しで実行できます。動詞、「Key Takeaways」スロットの扱い、所有者プロフィール、 todo インデックスを含む手順全体については、 references/MEMORY.md を参照してください。

index.md

カテゴリ別に整理された、コンテンツ中心のカタログです。各項目には1行の概要とタグがあります。取り込み処理のたびに再構築します。形式：

# Wiki Index

## Concepts
- [[transformer-architecture]] — The dominant architecture for sequence modeling ( #ml #architecture)
- [[attention-mechanism]] — Core building block of 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 スキルを参照してください。

マニフェストによって次のことが可能になります:

• デルタ計算 — 前回の取り込み以降に何が新規または変更されたか
• 追記モード — すべてではなく、デルタのみを処理する
• 監査 — どのソースがどの wiki ページを生成したか
• 陳腐化の検出 — ソースは変更されたが、wiki ページが更新されていない

ソースキー契約 (v2)。 ソースキー — .manifest.json 内の sources キー、ページ上の sources: frontmatter の値、およびプロジェクトの source_repo — はマシン間でポータブルでなければなりません (MUST)。Vault はマシン間で同期されるため、裸の絶対パス (/Users/...、/home/...) は決して有効な保存キーにはなりません。これが唯一の正規の定義であり、他のスキルはこれを再掲するのではなく参照します。

ソースの場所	正規のキー形式	例
Vault 内	Vault 相対パス — POSIX 区切り文字、先頭の ./ なし、.. なし	Raw/database/postgres.pdf、Clippings/article.md
$HOME 配下	ホーム相対パス — ~ で始まる	~/.claude/projects/-Users-name-my-app/abc.jsonl
ファイルでないもの	疑似キー — 任意の scheme:/:// 識別子。不透明として扱う	url:https://example.com/article、agent:claude/<session-id>

ルール:

1. 裸の絶対パスを決して保存しない。 書き込んだ後ではなく、書き込む前に変換してください。
2. 比較する前に正規化する。 ~ と環境変数を展開し、Vault 相対キーは Vault ルートを基準に解決し、scheme:/:// 疑似キーは不透明な識別子として扱ってください。正規化せずに生の文字列を比較しないでください。
3. 同一性はパスの変更をまたいで維持される。 同じ論理ソースはマシン間で同じキーを保ちます。
4. 疑似キーはオープンな名前空間である。 キーを疑似キーたらしめるのはその形状 (scheme: または :// であり、ファイルパスと誤認されることがない) であり、固定の名前リストではありません。推奨名: git プロジェクトには repo:<host/owner/name>、Web ページには url:<canonical-url>、エージェントセッションには agent:<agent>/<id>。Vault 内にも $HOME 配下にもないソースにも、やはりキーが必要です — 絶対パスにフォールバックさせないでください。
5. プロジェクトの同一性はリポジトリであり、チェックアウトではない。 projects ブロックでは、プロジェクトをマシンパスではなく source_repo (host/owner/name) で識別してください。マシン固有のチェックアウト場所は、役立つとしても、任意の source_cwd_hint (~ 相対) に属するものであり、同一性には決して含めないでください。

読み取りは後方互換です: 絶対キーで満たされた既存のマニフェストは引き続き動作し、scripts/manifest.py migrate <vault> --dry-run がそれを契約 v2 に変換します (衝突をマージし、最新の ingested_at を保持)。Vault がマシン間で移動した場合、その絶対キーは古い Vault パスをルートとしており、新しい Vault とも $HOME とも一致しません — その古いルートを migrate <vault> --from-root <old-vault-root> で明示的に渡してください (Vault が複数の場所に存在した場合はフラグを繰り返します)。するとコマンドは成功を主張する代わりに nothing portable to write — N key(s) kept non-portable を報告します。新しい書き込みも同じ正規化を通るため、スキルが obsidian-wiki cache-update に絶対パスを渡しても、ポータブルなキーがマニフェストに記録されます。

来歴の記録。 マニフェストエントリを書き込むときは、pages_created と pages_updated に、そのソースが寄与した Vault 相対のページパスを設定してください。これにより、(ソースが変更されたときの) 再取り込みが、推測するのではなく、再訪すべきページを見つけられるようになります。

ページテンプレート

新しい Wiki ページを作成するときは、次の構成を使用してください。

---
title: >-
    Page Title
category: concepts
tags: [ml, architecture]
aliases: [alternate name]
relationships:
  - target: "[[concepts/related-concept]]"
    type: extends
sources: [papers/attention.pdf]
summary: >-
    One or two sentences, ≤200 chars, so a reader (or another skill) can preview this page without opening it.
provenance:
  extracted: 0.72
  inferred: 0.25
  ambiguous: 0.03
base_confidence: 0.65
lifecycle: draft
lifecycle_changed: 2024-03-15
tier: supporting
created: 2024-03-15T10:30:00Z   # both from `obsidian-wiki memory now`, which honors the vault's timezone: key
updated: 2024-03-15T10:30:00Z
# Optional. Written only by `obsidian-wiki snapshots set` / `apply` — do not hand-author.
# Quoted wikilinks with |title: Obsidian Properties does not treat Markdown [text](path) as links.
snapshots:
  - "[[_raw/_archived/example-clip|example-clip]]"
---

# Page Title

One-paragraph summary of what this page covers.

## Key Ideas

- The source's central claim, paraphrased directly.
- A generalization the source implies but doesn't state outright. ^[inferred]
- A figure two sources disagree on. ^[ambiguous]

Use [[wikilinks]] to connect to related pages.

## Open Questions

Things that are unresolved or need more sources.

## Sources

- [[_raw/_archived/example-clip.md]] — snapshot this page was distilled from

Sources セクション（必須、本文の最後のセクション）。 すべての Wiki ページは ## Sources で終わります。項目は Obsidian でクリックできる形式にしてください。

• ローカルスナップショット（未加工の取り込み、保存した PDF／画像、Web Clipper ファイル、_raw/ に取り込まれてアーカイブされたもの）：本文の Sources セクションに [[_raw/_archived/<filename>]] を記述します（本文中の Wiki リンクには .md を含めてもかまいません）。YAML の sources: には元のソースのキー（url:、agent:、リポジトリのパスなど）を保持し、アーカイブのパスは記述しないでください。YAML の snapshots: は別項目です。ファイルを _raw/_archived/ に移動した後、obsidian-wiki snapshots set <page> --archive _raw/_archived/<filename> を実行してから、そのアーカイブ済みパスに対して obsidian-wiki cache-update を実行します。CLI は表示テキスト付きの引用符で囲まれた Wiki リンクの リストを出力します。例："[[_raw/_archived/clip|clip]]"（リンク先に .md は含まれず、|clip がプロパティに表示されます）。snapshots: に Markdown の [title](path) を記述しないでください。プロパティではクリックできないテキストのままになります。snapshots CLI は本文には触れません。クリッピングのフロントマターに記録されたウェブページにはリンクしないでください。この URL は変更される可能性のある元のメタデータです。
• 取得した URL（保存済みスナップショットなしでの /ingest-url）：正規 URL への Markdown リンクを記述し、YAML の sources: は url:<canonical-url> とします。
• この 2 つを混同しないでください。ページのクリップは、URL からの取り込みではありません。

関連する Wiki ページは Sources ではなく、Related／relationships: に記述します。

パーサーに安全なスカラー値。 フロントマターの自由記述値は、少なくとも title と summary を、上記のように折りたたみスカラー構文（>-）で記述してください。コロンとスペースの組み合わせ（: ）、#、または引用符を含む裸のスカラー値は YAML の解析に失敗し、Obsidian は「Invalid properties」と表示してフロントマターを非表示にします。title: >-／summary: >- の次の行に値をインデントして記述してください。

論文の詳細解説テンプレート

汎用テンプレートは、ほとんどのソースに適しています。学術論文は例外です。 references/ に保存する ML／AI／LLM／VLM などの論文では、重要な内容はアーキテクチャ、数式、結果の表にあります。これらは、簡潔な「Key Ideas」のリストでは本来の意味が失われてしまいます。そのため、以下の詳細なテンプレートを使用してください。ここでは「取得するのではなく、まとめる」という原則よりも、論文の代わりに読者が学習できる、徹底した自己完結型の解説を優先します。

Obsidian は必要な要素を標準でレンダリングするため、追加のツールは不要です。Mermaid のフェンス付き図、$$…$$ の LaTeX（MathJax）、Markdown の表、![[image]]／![[paper.pdf#page=N]] の埋め込みを使用できます。

このテンプレートは、元のソースが、重要な図や数式を含む学術論文（arXiv／学会論文）の場合にのみ使用してください。それ以外はすべて、上記の汎用ページテンプレートを使用します。フロントマター、出典マーカー、確信度、ライフサイクル、relationships: は変更せず、本文のセクションのみを変更します。

---
# ...required frontmatter, same as the generic template; category: references...
---

# Paper Title

> [!tldr] One sentence: what's new, plus the headline result.

## Problem & Motivation

What's broken or missing that this paper addresses.

## Method / Architecture

Prose walkthrough. Embed the paper's real architecture figure as the primary
visual (see *Academic papers* in `wiki-ingest` for the PyMuPDF extraction recipe).
Fall back to a Mermaid flowchart only when no figure can be extracted.

![[attachments/<slug>-fig1.png]]
*Figure N (Author Year): one-line caption.*

## Key Equations

The 1–3 core equations as display math, not backtick code:

$$ \mathcal{L} = \mathbb{E}_{x}\!\left[-\log p_\theta(y \mid z)\right] $$

## Results

Headline numbers as a table, not a comma-separated blob — and embed a key
results/motivating figure (scaling plot, benchmark chart, capability collage)
when the paper has one:

| Method | Benchmark | Metric | Cost |
|---|---|---|---|
| Baseline | … | … | … |
| **This paper** | … | … | … |

![[attachments/<slug>-resultsN.png]]
*Figure N (Author Year): one-line caption.*

## Limitations

What the paper concedes or sidesteps. Mark reading-between-the-lines as ^[inferred].

## Related

Typed `[[wikilinks]]` to neighbouring work.

## Sources

- [[_raw/_archived/paper.pdf]] — snapshot distilled (if a local PDF/clip was ingested)
- <https://arxiv.org/abs/XXXX.XXXXX> — only if this ingest fetched the URL and there is no local snapshot

論文の文章から再構成した Mermaid 図は、書き起こしではなく統合したものです。解釈に無視できない余地がある場合は、^[inferred] として扱ってください。

出典マーカー

Wikiページ上のすべての主張には、3つの出典状態のいずれかがあります。読者（および今後の取り込み処理）が事実と統合を見分けられるよう、インラインでマークしてください。

これらはフレームワークのデフォルト設定です。Vault の AGENTS.md でマーカーやワークフローフラグを追加できます。所有者による拡張は保持し、抽出済み／推論済み／曖昧という真偽状態の軸とは別に、独立したワークフローフラグとして扱ってください。

状態	マーカー	意味
抽出済み	(マーカーなし — デフォルト)	出典に実際に記載されている内容の言い換えです。
推論済み	^[inferred] 接尾辞	LLM が合成した主張です。出典に直接記載されていない関連付け、一般化、または示唆を指します。
曖昧	^[ambiguous] 接尾辞	出典同士が食い違っている、または出典が不明瞭です。

例：

- Transformers parallelize across positions, unlike RNNs.
- This is why they scale better on modern hardware. ^[inferred]
- GPT-4 was trained on roughly 13T tokens. ^[ambiguous]

この構文を採用する理由：

• ^[...] は Obsidian では脚注に近い形式で、きれいに表示され、[[wikilinks]] と衝突しません。
• インライン（接尾辞）形式なので、箇条書きの項目が1つのまま保たれます。
• デフォルトが抽出済みであるため、マーカーのない既存ページも引き続き有効です。

フロントマターの要約： 任意で、ページ単位のおおまかな構成比を表示できます。これにより、ユーザーはページを読まずに、推測の多いページを見つけられます。

provenance:
  extracted: 0.72   # rough fraction of sentences/bullets with no marker
  inferred: 0.25
  ambiguous: 0.03

これらは取り込みスキルが作成・更新時に記録する、ベストエフォートの数値です。wiki-lint は数値を再計算し、差異があれば警告します。このブロックは任意です。ブロックのないページは、慣例上、すべて抽出済みとして扱われます。

変化する情報には日付を付けてください。 件数や数量は古くなります。スター数、ユーザー数、顧客数、ダウンロード数、取引数、MRR などです。291★ (as of 2026-06-30) のように日付を添えるか、日付付きの見出しの下に記載するか、数値をコピーする代わりに最新の数値が掲載されている場所にリンクしてください。単に「スター数は23」とだけ書くと、いつまでも正しい情報のように読めます。obsidian-wiki lint は日付のない項目を undated_claims として報告します。

型付き関係

ページ本文にある通常の [[wikilinks]] には、意味的な重みはありません。「関連している」ことは示しますが、どのように関連しているかは示しません。任意の relationships: フロントマターブロックを追加すると、ナレッジグラフに型付きの方向性を持つエッジを加えられます。

relationships: ブロック

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

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

• target — 関連ページを指すウィキリンク（OBSIDIAN_LINK_FORMAT と同じ形式）
• type — 以下の許可された意味タイプのいずれか

許可される関係タイプ

以下の表は、フレームワークのデフォルトの許可リストです。Vault の AGENTS.md で拡張できます。利用側は有効な許可リストを使用し、変換を加えずに所有者のセマンティクスを保持する必要があります。

タイプ	意味	例
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 と関連しています

ルール

• 任意フィールド — 型付きの関係がわかっていない場合は、ブロック全体を省略します。タグのないウィキリンクも引き続き有効で、wiki-export によって related_to として扱われます。
• 重複させない — [[foo]] がインラインのウィキリンクとしてすでに記載されている場合、relationships: のエントリは型を付与するだけで、2つ目のリンクにはなりません。
• 方向が重要 — エントリを宣言するページがソースであり、target が宛先です。このページの視点からのみ関係を宣言します。
• 作り上げない — 関係の方向と種類がソース資料から明確にわかる場合にのみ、型付きエントリを追加します。判断に迷う場合は、related_to を使用するか、省略します。

relationships: を読み取るスキル：wiki-export（型付きエッジを出力）、cross-linker（リンクを推測する際に型付きエントリを記述）、wiki-query（回答で型を示し、複数ホップの「X は Y とどのようにつながっているか」という経路クエリでは、型付きエッジのグラフをたどります。relationships: の隣接関係に対する、フロントマターのみを対象とした範囲制限付き BFS です）。

信頼度とライフサイクル

各ページには、互いに独立した2つの信頼性シグナルと、任意の置き換えリンクが設定されます。

以下の必須項目とライフサイクルの値は、フレームワークのデフォルトです。Vault の AGENTS.md では、ライフサイクルの値を追加したり、信頼性フィールドを任意にしたりできます。バリデーターは、信頼性の値が存在する場合も引き続き検証しながら、実効的なオーナースキーマを適用する必要があります。

決定的な lint／信頼性コンシューマーは、OBSIDIAN_ALLOWED_LIFECYCLES、OBSIDIAN_ALLOWED_RELATIONSHIP_TYPES、OBSIDIAN_REQUIRED_TRUST_FIELDS、OBSIDIAN_SCHEMA_SOURCE を通じてオーナースキーマを受け取ります。解決の優先順位は、CLI > 環境変数／設定 > これらのフレームワークのデフォルト（ライフサイクルと関係の拡張は追加方式）です。明示的に空または空白のみが指定された値は、フェイルクローズとして処理されます。デフォルトを選択するには、変数を省略してください。運用時の呼び出し仕様は wiki-lint/SKILL.md が定めます。

必須フィールド

base_confidence: 0.65          # [0.0, 1.0] — time-independent quality estimate. Stored once, recomputed on content change.
lifecycle: draft               # draft | reviewed | verified | disputed | archived
lifecycle_changed: 2024-03-15  # ISO date of last state transition
# lifecycle_reason: "..."      # optional free-text — why the state changed; surfaced by wiki-query
# superseded_by: "[[new-page]]" # wikilink; only when lifecycle=archived

lifecycle_reason と superseded_by は任意です。決して作り上げないでください。

信頼度の計算式

この計算式は手動で設定する基本スコアであり、決定論的な URL 分類器ではありません。

base_confidence = lineage_count_score * 0.5 + source_quality_score * 0.5

lineage_count_score  = min(independent_evidence_lineages / 3, 1.0)
source_quality_score = avg(reviewed quality score per independent lineage)

生スコアを計算した後、根拠がページの重要な主張を網羅しているかを評価します。網羅が不完全な場合は、スコアを維持または引き下げることが妥当な場合があります。重要な主張に根拠がない場合は、信頼度を変更する前に情報源または主張を修正する必要があります。認識上の実質的な変化がない限り、わずかなスコアの変更は避けてください。

情報源品質スコア（最も該当する区分を使用）：

区分	スコア	例
paper	1.0	arXiv、学会の論文集
official	0.9	*.gov、ベンダーのドキュメント
documentation	0.85	適切に保守されているサードパーティーのドキュメント
book	0.8	書籍、技術資料
repository	0.75	コンテンツアドレス指定されたリポジトリ／コードの証拠
blog	0.55	個人ブログ
session_transcript	0.5	会話履歴または完了した操作
forum	0.4	Stack Overflow、HN、Reddit、issue レベルの報告
unknown	0.4	その他／現在の設定
llm_generated	0.3	LLM による統合、または未検証のメモリシード

独立した証拠の系統とは、主張を独立して裏付けられる起点のことです。正規の情報源 ID は識別に役立ちますが、識別情報だけでは独立性の証明にはなりません。数える前に、依存関係のある証拠をまとめてください。

• 1 つのリポジトリに属するファイル、リリース、コミット → 1 つのリポジトリ系統
• 1 つの作業ストリームに属する再試行／レビュー／修正タスク → 1 つのタスク系統
• 親子関係にあるカンバンレコード → 1 つのタスク系統
• プロファイル間でバイト単位で同一のメモリ → 1 つのメモリ系統
• スナップショットと、そのスナップショットが取得した変更可能な情報源 → 1 つの系統
• 1 つの起点に解決される別名またはメタデータ参照 → 1 つの系統

決定論的な wiki-lint パスは _meta/trust-ledger.json を検証しますが、情報源の文字列から信頼度を再計算することはありません。新規ページまたは大幅に変更されたページには、手動レビューのマークが付けられます。台帳を更新するのは、人による明示的な承認後に限ってください。

スキルごとのデフォルト値（取り込みスキルでは自動的に計算されます）：

スキル	base_confidence	ライフサイクル
wiki-ingest（URL）	0.17 + 0.5 × classify(url)	draft
wiki-ingest（単一ドキュメント）	情報源ごとの分類器	draft
wiki-ingest（複数ドキュメント）	min(N/3,1)×0.5 + avg_q×0.5	draft
wiki-research	変動。多くの場合 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

ライフサイクル状態機械

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

状態	遷移のきっかけ	備考
draft	初回書き込み時に任意の取り込みスキルが設定	すべての新規ページのデフォルト
reviewed	人による編集のみ
verified	人による編集のみ	時間の経過だけで検証済みページが降格することはありません
disputed	手動編集のみ	表示上、archived 以外のすべての状態に優先します
archived	手動編集、または取り込みスキルが superseded_by を設定	終端状態

draft を設定するのは取り込みスキルのみです。それ以外の状態遷移には、人による編集が必要です。状態が変わるたびに lifecycle_changed を更新してください。

したがって、次の 2 種類の遷移は不正であり、obsidian-wiki lint によって illegal_lifecycle_transitions として報告されます。draft への後戻り（reviewed|verified|disputed → draft）と、archived からのあらゆる遷移（終端状態です。ページを復元する場合は遷移ではなく、意図的に削除して再作成します）。このチェックでは、ページの最終レビュー時に _meta/trust-ledger.json に記録されたライフサイクルと比較するため、少なくとも一度レビューされたページのみが対象になります。

重要度の階層化

tier: フィールドは、各取り込み処理で更新するページと、検索時の優先度を制御します。Wiki の成長に伴い、取り込みのたびにすべてのページを読み直すとトークンを無駄に消費します。階層化によって、取り込みスキルとクエリスキルは重要な箇所に作業を集中できます。

3 つの階層

階層	意味	取り込み時の動作	クエリの優先度
core	基盤となるページ — 多くの他のページが依存しています（被リンク数が多い、または橋渡しの位置にあるページ）。常に更新する価値があります。	ソースにわずかでも関連性があれば、常に更新します	インデックスおよび全体読み込みのパスで最初に表示
supporting (デフォルト)	接続性が中程度の標準的な Wiki ページ	ソースにこのページに関する明確な新しい主張がある場合に更新します	標準の優先度
peripheral	接続性の低いページ — リンクされることがまれで、範囲が限定的です	ソースの主な内容がこのトピックでない限り、スキップします	最後の手段。コンテキストの予算に合わせて削減する場合はスキップ

割り当てルール

• 新しいページ： デフォルトで tier: supporting にします
• core に昇格： ページへの被リンクが 5 件以上になった場合、または wiki-status のインサイトモードで橋渡しページとしてフラグが付けられた場合
• peripheral に降格： ページへの被リンクが 1 件以下で、90 日以上更新されていない場合
• 人間による上書きが常に優先されます — tier: を手動で編集して、任意の階層に固定します
• tier: のない既存ページは supporting として扱われます（後方互換性あり — 移行は不要です）

階層を管理するもの

• wiki-ingest は tier: を読み取り、現在のパスでページを更新するかどうかを判断します
• wiki-query は tier: を使用して、インデックスパスで候補の順序を決め、コンテキストの予算に合わせて絞り込みます
• wiki-status のインサイトモードはグラフの指標を計算し、階層の割り当てを提案します — 自動で書き込むことはありません
• wiki-lint は新規作成ページに tier: がない場合に警告します（Phase 2 で適用。base_confidence と同じスケジュールです）

検索プリミティブ

ボルトの読み取りは、読み取り側のすべてのスキルで最も大きなコストを占めます。質問に答えられる最も低コストのプリミティブを使い、低コストの方法では不十分な場合にのみ段階を上げてください。ボルトの内容を必要とするスキルは、ページ全体の読み取りにいきなり進まず、次の表に従ってください。

必要な情報	プリミティブ	相対コスト
ページは存在するか？タイトル／カテゴリ／タグは何か？	index.md を読み取る。Grep でフロントマターのブロックを検索する（ファイル先頭の ^--- ブロックを対象とするパターンで範囲を指定）	最も低コスト
ページの 1～2 文のプレビュー	フロントマターの summary: フィールドを読み取る	低コスト
ページ内の特定の主張またはセクション	Grep -A <n> -B <n> "<term>" <file> — 一致した行とその前後のコンテキストのみを返します	中程度
ページ全体の内容	Read <file>	高コスト — 最後の手段
ページ間の関係	ボルト全体を対象に Grep "\[\[.*?\]\]" を実行するか、既知のページから Wiki リンクをたどる	ケースバイケース

検索コマンドの優先順位： シェル／ファイル検索では、利用できる場合は ripgrep（rg、rg --files）を使います。利用できない場合は、grep／find に切り替えます。これらのスキルに記載されている大文字表記の Grep／Glob は、これらのツールを公開するエージェント向けの、ツールに依存しないプリミティブ名です。

ルール： 低コストのプリミティブでは質問に答えられない場合にのみ、段階を上げてください。summary: フィールドだけで答えられるなら、ページ本文を読まないでください。-A 10 -B 2 を指定して検索したセクションで主張を確認できるなら、ページ全体を読まないでください。15 行を読むために 500 行のページを開くのは、485 行分のトークンの無駄です。

重要な理由： 20 ページのボルトなら、ボルト全体のスキャンでも対応できます。200 ページではそうはいきません。上記のプリミティブを使うことで、データベースなしでもスキルのフレームワークを大規模なボルトに対応させられます。

この表を使用するスキル：wiki-query、cross-linker、wiki-lint、wiki-status（インサイトモード）。ボルトを読み取る新しいスキルは、独自のパターンを作るのではなく、このセクションを参照してください。

QMD インデックスの鮮度

QMD は、Vault の上に重ねて使用するオプションの検索インデックスです。Markdown Vault が信頼できる唯一の情報源です。Wiki の Markdown を書き込むスキルは、Vault への書き込みが完了した後に QMD を更新する必要があります。ただし、QMD_WIKI_COLLECTION が設定されており、ローカルの QMD トランスポートが利用可能な場合に限ります。QMD の更新に失敗した場合は、Vault の変更を保持し、QMD の状態は別途報告してください。

新しいコンテンツが表示されることを確認できる、最も低コストな検証方法を使用してください。qmd update を実行し、ベクトルが古い、または存在しない場合にのみ qmd embed を実行してから、書き込んだページ 1 件またはコレクションのルートに対して、対象を絞った qmd get または qmd ls の確認を行います。読み取り専用のスキルでは QMD を更新しないでください。

基本原則

1. 取得するのではなく、編纂する。 Wiki は事前に編纂されたナレッジです。ソースを取り込むときは、ソースの要約を作成するだけでなく、関連するすべてのページを更新してください。

2. 時間とともに積み重ねる。 取り込みのたびに、Wiki を大きくするだけでなく、より賢くしてください。新しい情報を既存のページに統合し、矛盾を解消して、相互参照を強化します。

3. 出典を明確にする。 すべての主張は出典までたどれる必要があります。ページを更新するときは、どの出典を受けて更新したのかを記録してください。

4. 推論には印を付ける。 既定では、文は情報源から抽出されたものです。統合して導いた主張には ^[inferred]、見解が分かれる主張には ^[ambiguous] を付けてください。推測を隠す Wiki は気付かれないまま劣化します。明示する Wiki は信頼性を保てます。

5. 人間がキュレーションし、LLM が維持する。 追加するソースと尋ねる質問は人間が決めます。相互参照の更新、一貫性の維持、矛盾の記録といった管理作業は LLM が担います。

6. Obsidian は IDE です。 ユーザーは Obsidian で Wiki を閲覧し、探索します。すべて Obsidian で有効な Markdown であり、機能する Wiki リンクを含んでいる必要があります。

リンク形式

Wiki ページ間をつなぐすべての内部リンクは、解決済み設定の OBSIDIAN_LINK_FORMAT によって制御されます（既定値：wikilink）。

設定	構文	例
wikilink (既定)	[[path/to/page]] または [[path/to/page|display text]]	[[concepts/foo|foo]]
markdown	[display text](relative/path.md)	[foo](../concepts/foo.md)

Markdown 形式のリンクの生成

OBSIDIAN_LINK_FORMAT=markdown の場合：

1. .. を使って必要な分だけ上の階層に移動し、現在のファイルのディレクトリから対象の .md ファイルまでのパスを計算します。
2. 表示テキストには、ページタイトルまたは自然な表現を使用します。
3. .md 拡張子を必ず含めます。

現在のファイル	対象	相対リンク
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]] 形式の Wiki リンクは、Markdown モードでは [display text](relative/path.md) に対応します。

適用範囲： この設定が影響するのは、新しく書き込むリンクまたは更新するリンクのみです。既存の Vault のコンテンツは自動的に移行されません。古いリンクを変換する場合は、cross-linker または wiki-lint スキルを実行してください。

リンクを生成する前に、書き込みを行うすべてのスキルは設定から OBSIDIAN_LINK_FORMAT を読み込み、適切な形式を適用します。

設定解決プロトコル

すべてのスキルは、このアルゴリズムを使用して設定を解決する必要があります。.env やグローバル設定パスを直接ハードコードしないでください。 これにより、単一 Vault、複数 Vault、プロジェクトローカル、VPS の各環境が正しく動作します。

グローバル設定ディレクトリ

グローバル設定ディレクトリは XDG 形式です。$XDG_CONFIG_HOME/obsidian-wiki（既定値は ~/.config/obsidian-wiki）です。すでに ~/.obsidian-wiki ディレクトリがあるインストールでは、引き続きそのディレクトリを使用するため、既存の設定が壊れることはありません。ただし、新規インストールは XDG パスに配置されます。次のように解決します。

obsidian_wiki_config_dir() {
  local xdg_dir="${XDG_CONFIG_HOME:-$HOME/.config}/obsidian-wiki"
  local legacy_dir="$HOME/.obsidian-wiki"
  if [[ -d "$legacy_dir" && ! -e "$xdg_dir" ]]; then
    echo "$legacy_dir"
  else
    echo "$xdg_dir"
  fi
}

以下では、「グローバル設定ディレクトリ」は $(obsidian_wiki_config_dir) を、「グローバル設定」は $(obsidian_wiki_config_dir)/config を意味します。

解決順序

0. インラインの vault 上書き（@name） — ユーザーのリクエストに @<name> トークン（例：@work save this、query @personal about X）が含まれている場合は、<global config dir>/config.<name> を直接読み込み、その OBSIDIAN_VAULT_PATH を使用します。これは CWD からの .env の遡り検索とアクティブなシンボリックリンクの両方より優先され、その呼び出しに限って適用されます。@name を含むリクエストでは、ln -sf を実行したり、その他の方法でアクティブな vault を変更したりしないでください。<global config dir>/config.<name> が存在しない場合は、存在しないことをユーザーに伝え、利用可能な vault を（wiki-switch の List ロジックで）一覧表示してから停止します。デフォルトへ黙ってフォールバックしないでください。@name はルーティング指示であり、コンテンツではありません。残りのリクエストを実際の指示やページテキストとして扱う前に、@name を取り除いてください。
1. CWD から上位へ検索 — 現在のディレクトリから始めて、各親ディレクトリを $HOME まで遡り、.env ファイルを探します。OBSIDIAN_VAULT_PATH を含む最初の .env で検索を停止します。その値が空の場合もそこで停止します。グローバル設定にフォールバックするのではなく、解決を妨げている .env をユーザーに伝えてください（.env.example の空行をコピーすると、この状態になります）。
2. グローバル設定 — ローカルの .env が見つからない場合は、グローバル設定（$(obsidian_wiki_config_dir)/config）を読み込みます。
3. セットアップを案内 — どちらも存在しない場合は、ユーザーに「設定が見つかりません。wiki-setup を実行して wiki を初期化してください。」と伝えます。

@name は呼び出しごとの上書きで、1 回のリクエストに対して 1 つの vault を指定します。/wiki-switch <name> は永続的なデフォルトで、今後のすべてのリクエストに適用されるよう、アクティブなシンボリックリンクの向き先を変更します。デフォルトの「brain」vault に影響を与えず、どこからでも別の vault を利用するには @name を使います。

find_config() {
  # $1 = parsed @name from the request, if any (else empty)
  local config_dir
  config_dir="$(obsidian_wiki_config_dir)"
  if [[ -n "$1" ]]; then
    [[ -f "$config_dir/config.$1" ]] && { echo "$config_dir/config.$1"; return; }
    echo ""; return   # named vault missing → caller reports + lists, no fallback
  fi
  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 "$config_dir/config" ]] && { echo "$config_dir/config"; return; }
  echo ""
}

Vault ごとの状態

daily-update など、実行時の状態を書き込むスキルでは、その状態をグローバルパスではなく、解決された vault の範囲に限定する必要があります。次のようにします。

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

標準の「開始前」ブロック

すべてのスキルのセットアップセクションは、次のように記述してください。

設定の解決 — llm-wiki/SKILL.md の設定解決プロトコルに従ってください。まずインラインの @name による上書きを適用し、次に CWD から上位へ .env を検索して、見つからなければグローバル設定にフォールバックし、それもなければセットアップを案内します。これにより、OBSIDIAN_VAULT_PATH と、ツール固有のパス上書きを取得します。

執筆プロファイルの解決

自然言語の Markdown を新規作成または書き換える前に、上記の XDG／レガシー方式でグローバル設定ディレクトリを解決し、<global config dir>/WRITING.md が存在する場合は読み込んでください。WRITING.md が存在しないか空の場合、カスタムの執筆設定はありません。この任意の読み込みに失敗した場合は、警告を出してデフォルトのフレームワークのガイダンスに従って続行してください。

有効な優先順位は、フレームワークの不変条件 > 現在のタスク／スキルの要件 > 現在のプロジェクトの AGENTS.md > vault の AGENTS.md > グローバルな WRITING.md です。フレームワークの不変条件には、スキーマ、来歴、安全性が含まれます。操作固有の要件は、現在のタスクにおいて引き続き優先されます。プロジェクトおよび vault で明示されていないルールは、より具体性の低いレイヤーから継承され、同じトピックについては、より具体的なルールが優先されます。

執筆設定は、新たに作成または書き換える自然言語のフィールドと本文にのみ適用されます。これには YAML フロントマターの自然言語のタイトル値と概要値も含まれますが、設定によって YAML の構文、必須キー、構造、型、機械生成フィールドを変更することはできません。JSON、構造化ログ、パススルーコンテンツは変更せず、必須の形式とソースへの忠実性を維持してください。

環境変数

wiki は環境変数で設定します（.env.exampleを参照）。必須の変数は保管庫のパスのみで、それ以外には適切なデフォルト値が設定されています。

• OBSIDIAN_VAULT_PATH — wiki の保存場所 （必須）
• OBSIDIAN_SOURCES_DIR — 未加工のソース文書の保存場所
• OBSIDIAN_CATEGORIES — カテゴリのカンマ区切りリスト
• WIKI_SKIP_PROJECTS — カンマ区切りの部分文字列。名前にいずれかの文字列を含むプロジェクトディレクトリは、履歴の取り込み（スキャン＋差分＋マニフェスト）から除外されます。履歴取り込みスキルの「Project Scoping」ステップを参照してください。
• CLAUDE_HISTORY_PATH — Claude の会話データの保存場所
• CODEX_HISTORY_PATH — Codex のセッションデータの保存場所
• HERMES_HOME — Hermes エージェントデータの保存場所
• OPENCLAW_HOME — OpenClaw データの保存場所
• COPILOT_HISTORY_PATH — Copilot のセッションデータの保存場所
• OBSIDIAN_LINK_FORMAT — 内部リンクの構文：wikilink（デフォルト）またはmarkdown
• WIKI_TOKEN_WARN_THRESHOLD — wiki 全体のトークン推定値がこの値を超えた場合に、wiki-statusで警告を出します（デフォルト：100000）。無効にするには0を設定します。トークン使用量レポートについてはwiki-statusを参照してください。
• WIKI_STAGED_WRITES — trueの場合、LLM が書き込むすべてのページは、人によるレビューを経て公開されるまで_staging/<category>/に保存されます。詳細はwiki-setupとwiki-stage-commitを参照してください。
• CODE_UNDERSTANDING_BACKEND — wiki-update が内容を整理する前にプロジェクトを理解する方法：auto（利用可能であれば CodeGraph、そうでなければ組み込みの ast-extract ＋ rg。デフォルト）、builtin、またはcodegraph（明示的に必須とします。利用できない場合は警告またはエラーになります）。
• CODE_UNDERSTANDING_CODEGRAPH_BIN — codegraph バイナリが PATH にない場合に指定する任意のパス。 どちらもOBSIDIAN_VAULT_PATHと同じ方法で解決されます。実際の環境変数が優先され（空の場合は未設定として扱われます）、次にプロジェクトディレクトリから上にたどって最も近い.env、その次にグローバル設定（$(obsidian_wiki_config_dir)/config）、最後にデフォルト値が使われます。
• OBSIDIAN_MAX_PAGES_PER_INGEST — wiki-ingestの1回の実行で作成または更新するページ数の上限（デフォルト：15）。wiki-ingestのステップ 4 を参照してください。
• LINT_SCHEDULE — daily-updateでwiki-lintも実行する頻度：daily | weekly（デフォルト）| manual。daily-updateのステップ 4a を参照してください。

API キーは不要です。これらのスキルを実行するエージェントには、すでにLLMへのアクセス機能が組み込まれています。

動作モード

wiki は3つの取り込みモードに対応しています。

モード	使用するタイミング	動作
追加	小さな差分、段階的な更新	マニフェストを使って差分を計算し、新規または変更されたソースのみを取り込みます
再構築	大幅な乖離がある場合、または新規作成が必要な場合	現在のwikiを_archives/にアーカイブしてクリアし、すべてのソースを再処理します
復元	元に戻す必要がある場合	以前のアーカイブを復元します

wiki-statusを使うと、差分を確認して推奨事項を取得できます。アーカイブ、再構築、復元の操作にはwiki-rebuildを使います。

リファレンス

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

• wiki-status — 取り込み済みの内容を監査し、差分を計算して、追加または再構築を推奨します
• wiki-rebuild — 現在のwikiをアーカイブし、最初から再構築するか、アーカイブから復元します
• wiki-ingest — ソース文書をwikiページに、未加工のテキスト／チャット／ログデータをwikiページと未加工データに整理します
• claude-history-ingest — Claude の会話履歴を取り込みます
• codex-history-ingest — Codex CLI のセッション履歴を取り込みます
• wiki-query — wiki に基づいて質問に回答します
• wiki-lint — wiki の状態を監査し、維持します
• wiki-setup — 新しい保管庫を初期化します