wiki-research

Wiki Research — 自律型マルチラウンド調査

トピックについて自律的な調査ループを実行し、見つけた情報を統合して、恒久的な知識として Obsidian wiki に記録します。

始める前に

執筆プロファイル： 自然言語の Markdown を新たに作成または書き換える前に、llm-wiki/SKILL.md の Writing Profile Resolution セクションを読み、適用してください。フレームワークのスキーマ、出典情報、安全性、および操作固有の要件が優先されます。 WRITING.md の設定は、新たに作成または書き換える自然言語の Markdown にのみ適用されます。ソースコンテンツと構造化レコードはそのまま保持してください。

1. 設定を解決する — llm-wiki/SKILL.md の Config Resolution Protocol（インラインの @name 上書き → CWD から上位ディレクトリへ .env を検索 → グローバル設定 → プロンプトでのセットアップ）に従います。これにより、OBSIDIAN_VAULT_PATH と OBSIDIAN_LINK_FORMAT（デフォルト：wikilink）が得られます。
2. $OBSIDIAN_VAULT_PATH/index.md を読み、wiki にすでにある情報を把握します。wiki で十分に扱われている内容を再調査しないでください。
3. $OBSIDIAN_VAULT_PATH/hot.md が存在する場合は読みます。最近のコンテキストが記載されています。
4. $OBSIDIAN_VAULT_PATH/references/research-config.md が存在する場合は確認します。この Vault の情報源の優先設定、除外するドメイン、確信度のルールなどが定義されている場合があります。
5. $OBSIDIAN_VAULT_PATH/references/research-backends.md が存在する場合は確認します。任意の CLI 検索バックエンド（ソーシャルメディア、動画の文字起こし、有料 API など）が登録されています。利用可能なバックエンドを作業状態に読み込み、このセッションで使用します。

生成したページに内部リンクを書くときは、llm-wiki/SKILL.md の Link Format セクションに従い、OBSIDIAN_LINK_FORMAT の値を使用します。

調査トピックが曖昧な場合は、ユーザーに確認してから進めます。

調査設定（任意）

Vault に references/research-config.md が存在する場合は、読み込んで定義されているルールを適用します。

• 情報源の優先設定（例：学術情報源を優先する、特定のドメインを避ける）
• 除外するドメイン
• 確信度スコアの調整
• トピック固有の制約

ファイルが存在しない場合は、デフォルト設定で進めます。

調査バックエンド（任意）

Vault に references/research-backends.md が存在する場合は、調査を始める前に読み込みます。このファイルでは、CLI 検索バックエンドを YAML リストで 0 個以上定義します。

backends:
  - name: yt-dlp-transcript      # friendly label
    binary: yt-dlp                # CLI binary (checked with `command -v`)
    invoke: "yt-dlp --skip-download --write-auto-sub --sub-lang en --sub-format json3 -o /tmp/ytvid '{url}'"
    when_to_use: YouTube video URLs, video transcripts
    cost_tier: free               # free | paid
    env_key: ""                   # required env var for paid tiers (empty = always enabled)
    output: text                  # json | text | markdown

  - name: perplexity-sonar
    binary: perplexity
    invoke: "perplexity search '{query}'"
    when_to_use: deep synthesis queries needing multi-source aggregation
    cost_tier: paid
    env_key: PERPLEXITY_API_KEY   # skipped if unset
    output: text

バックエンドの利用可否を確認する（セッション開始時に 1 回実行）：

• 各バックエンドについて、command -v <binary> 2>/dev/null を実行します。見つからない場合は利用不可とし、実行概要に記載します。
• paid バックエンドについては、$env_key が空でないことも確認します。未設定の場合は利用不可とし、その旨を記載します。
• Round 1～2 で使用する、利用可能なバックエンド（利用可能で、キーの確認も通過したもの）のリストを作成します。

呼び出しルール（調査中、観点または URL ごと）：

• invoke テンプレート内の {url} または {query} を、現在の URL または検索クエリに置き換えます。
• 標準出力を取得します。終了コードが 0 以外の場合は、その観点でこのバックエンドをスキップし、簡潔なエラーを記録して続行します。
• バックエンドの出力を、同じ主張・概念・エンティティ・矛盾の抽出に取り込みます。バックエンドが返す情報源 URL（またはクエリモードのバックエンドでは検索クエリ文字列）を引用します。
• バックエンドの障害によって調査を中断してはいけません。必ず WebSearch／WebFetch にフォールバックします。

無料のものを優先する順序： 観点ごとに、有料バックエンドより先に無料バックエンドを評価します。無料バックエンドで十分な情報が得られた場合は、同じ観点に対する有料バックエンドをスキップできます。

research-backends.md がない場合 → このセクション全体をスキップします。動作はこれまでと同じです。

スターターレジストリのテンプレート

ユーザーがレジストリの例を求めた場合は、$VAULT/references/research-backends.md にこのファイルを提示します。

# Optional CLI backends for wiki-research. Delete rows you don't need.
# Skill docs: .skills/wiki-research/SKILL.md — Research Backends section
backends:
  # --- free / local ---
  - name: defuddle-fetch
    binary: defuddle
    invoke: "defuddle '{url}'"
    when_to_use: any URL — cleaner extraction than WebFetch alone
    cost_tier: free
    env_key: ""
    output: markdown

  - name: yt-dlp-transcript
    binary: yt-dlp
    invoke: "yt-dlp --skip-download --write-auto-sub --sub-lang en --sub-format json3 -o /tmp/ytvid '{url}'"
    when_to_use: YouTube video URLs for transcript extraction
    cost_tier: free
    env_key: ""
    output: text

  # --- paid / gated (skipped when env key is unset) ---
  - name: perplexity-sonar
    binary: perplexity
    invoke: "perplexity search '{query}'"
    when_to_use: deep synthesis queries needing multi-source aggregation
    cost_tier: paid
    env_key: PERPLEXITY_API_KEY
    output: text

第 1 ラウンド — 幅広い調査

目標： トピックの全体像を幅広く把握します。

1. トピックを3〜5 個の異なる切り口に分解します（例：「ベクトルデータベース」の場合、その概要、利用すべき場面、主要な実装、トレードオフ、本番環境での注意点）
2. 各切り口について、表現を変えながら WebSearch で 2〜3 件のクエリを実行します
3. 各切り口の上位 2〜3 件の検索結果について、WebFetch（利用可能な場合は defuddle <url> — よりすっきり抽出できます）で内容を取得します。各 URL について、when_to_use が一致するアクティブなバックエンドも呼び出します（例：YouTube の URL なら yt-dlp-transcript を呼び出します）。その出力を WebFetch の結果とともに抽出内容にまとめ、バックエンドが返すソース URL を引用します。
4. 取得した各ページから、以下を抽出します。
   • 主な主張 — ソースが明示的に述べていること
   • 概念 — 紹介されているアイデア、用語、フレームワーク
   • エンティティ — 言及されているツール、人々、組織
   • 矛盾 — ソース間で見解が食い違う箇所

調査を進めながら、何を網羅し、何が不足しているかを記録します。

第 2 ラウンド — 不足部分の補完

目標： 第 1 ラウンドで残った不足を解消します。

第 1 ラウンドの成果を確認します。

• ソースが提起したものの、回答していない疑問は何ですか？
• ソース間で矛盾している箇所はどこですか？
• 調査が十分でない切り口はどれですか？

これらの不足に特化した検索を最大 5 件実行します。リンク集約サイトよりも、一次ソース、公式ドキュメント、信頼性の高い分析を優先します。不足を補うためのクエリでは、{query} を invoke テンプレートに代入して、アクティブなクエリモードのバックエンド（例：perplexity-sonar）も呼び出します。バックエンド名を引用元の文脈として添え、結果を抽出内容にまとめます。

調査結果を作業用の資料に加えます。矛盾の一覧も更新します。

第 3 ラウンド — 統合内容の確認

目標： 矛盾を解消し、深さが十分か確認します。

重大な矛盾が解消されずに残っている場合：

• 最後に、信頼できる解決策を探すための対象を絞った調査を 1 回（検索 2〜3 件）実施します
• 解決できない場合は、統合ページでその矛盾を明記します

矛盾が軽微である場合、または第 2 ラウンド後にトピックを十分に網羅できていると感じた場合は、追加検索を行わず、ファイルへの整理に進みます。

停止条件： 十分な深さに達するか、3 ラウンドが完了した時点で停止します。無期限に繰り返してはいけません。

ファイルへの整理 — Wiki ページの作成

調査結果を 4 つの出力領域に分けて Wiki ページに整理します。

1. sources/ — 主要な参考資料ごとに 1 ページ

重要なソースごとに作成します（通常、合計 4〜8 ページ）。

---
title: >-
  <Source title>
category: references
tags: [<2-4 domain tags>]
sources:
  - "<URL>"
source_url: "<URL>"
created: <ISO-8601 timestamp>
updated: <obsidian-wiki memory now>
summary: >-
  <1-2 sentences describing what this source covers, ≤200 chars>
provenance:
  extracted: 0.X
  inferred: 0.X
  ambiguous: 0.X
base_confidence: <0.17 + 0.5 × classify(url) for a single source>
lifecycle: draft
lifecycle_changed: <obsidian-wiki memory now --date>
---

本文：タイトル、URL、扱っている内容、主な主張（出典を示すマーカー付き）、制限事項。

2. concepts/ — 実質的な概念ごとに 1 ページ

ソース全体から見つかった重要な概念ごとに作成します。

標準的な概念のフロントマターと本文を使用します。概念同士、およびソースページへのリンクを追加します。

3. entities/ — ツール、組織、人々

重要なエンティティ（ツール、ライブラリ、企業、主要な著者）ごとに作成します。

標準的なエンティティのフロントマターを使用します。そのエンティティを活用する概念、およびそのエンティティが登場するソースへのリンクを追加します。

4. synthesis/Research: [Topic].md — 統合のマスターページ

主要な成果物として、判明した内容をすべて構造化して統合します。

---
title: >-
  Research: <Topic>
category: synthesis
tags: [<3-5 domain tags>, research]
sources: [<list of source URLs or page paths>]
created: <ISO-8601 timestamp>
updated: <obsidian-wiki memory now>
summary: >-
  Synthesis of <N>-round research on <topic>. Covers <core findings in ≤200 chars>.
provenance:
  extracted: 0.X
  inferred: 0.X
  ambiguous: 0.X
base_confidence: <min(N_unique_sources/3,1.0)×0.5 + avg_source_quality×0.5>
lifecycle: draft
lifecycle_changed: <obsidian-wiki memory now --date>
---

# Research: <Topic>

## Overview
<2-4 sentence executive summary of what the research found>

## Key Findings
<Bulleted list of the most important claims, each with a [[source page]] citation>

## Core Concepts
<Links to concept pages created, with one-line descriptions>

## Entities & Tools
<Links to entity pages, with one-line descriptions>

## Contradictions & Open Questions
<Where sources disagree or where the research hit limits>

## Sources Consulted
<Linked list of all source pages>

相互リンク

すべてのページを整理した後：

• 各概念ページから、少なくとも 2 つのソースページにリンクする必要があります
• 各ソースページから、その作成に寄与した概念ページにリンクする必要があります
• 統合ページから、作成したすべての概念、エンティティ、ソースの各ページにリンクする必要があります

index.md で同じトピックに関する既存のページを確認し、重複ページを作成するのではなく、既存のページに統合します。

更新追跡ファイル

.manifest.json — research エントリーを追加します：

{
  "type": "research",
  "topic": "<topic>",
  "researched_at": "TIMESTAMP",
  "rounds_completed": 3,
  "sources_fetched": N,
  "pages_created": ["..."],
  "pages_updated": ["..."]
}

1 回のロックされた呼び出しで、インデックス、ログ、ホットキャッシュを更新します：

obsidian-wiki memory sync WIKI_RESEARCH \
  topic="<topic>" rounds=<N> sources_fetched=<N> \
  pages_created=<M> backends_used="<name,...|none>" \
  --takeaways "<the research topic and its core finding, in one line>"

ログフィールドに作成したページをすべて列挙しないでください。memory sync はディスクからインデックスを調整します。巨大なフィールドはホットキャッシュを圧迫するだけです。調査が継続中の場合は、次のように記録します：obsidian-wiki memory todo add "<open question>" --origin synthesis/<page>.md。

index.md、log.md、hot.md は手動で編集しないでください。このコマンドは、並行して書き込む処理によって更新内容が失われないよう、ロックを取得します。

手順の全容については、.skills/llm-wiki/references/MEMORY.md を参照してください。

品質チェックリスト

• 3 ラウンドを完了（または十分な深さに達した時点で終了）
• synthesis/Research: [Topic].md に統合ページが存在する
• 主要な参照先についてソースページを作成済み
• 重要な項目について概念ページとエンティティページを作成済み
• 矛盾点を統合ページで明示済み
• すべてのページを相互リンク済み
• index.md、log.md、hot.md、.manifest.json を更新済み
• バックエンドの概要を報告済み：有効だったバックエンド、スキップしたバックエンド（バイナリが利用できない／キーが未設定／エラー）とその理由

Vault への書き込み後の QMD 更新

QMD は検索インデックスであり、信頼できる情報源ではありません。$QMD_WIKI_COLLECTION が空、または未設定の場合は、この手順をスキップしてください。このスキルによって Vault の Markdown が書き込まれたか、書き換えられた場合にのみ実行してください。QMD の更新に失敗しても、Vault の変更をロールバックしないでください。QMD の状態は別途報告してください。

$QMD_CLI が設定されていればそれを使用し、そうでなければ qmd を使用します。

${QMD_CLI:-qmd} update

出力にベクトルが必要である、または埋め込みが古い可能性があると示された場合は、次を実行します：

${QMD_CLI:-qmd} embed

次のいずれかを使ってコレクションを検証します：

${QMD_CLI:-qmd} ls "$QMD_WIKI_COLLECTION"

または、特定のページパスが分かっている場合：

${QMD_CLI:-qmd} get "qmd://$QMD_WIKI_COLLECTION/<page>.md" -l 5

次のいずれかを記録します：

• QMD refreshed: update + embed + verified
• QMD refreshed: update only + verified
• QMD skipped: QMD_WIKI_COLLECTION unset
• QMD skipped: qmd CLI unavailable
• QMD failed: <short error summary>