Wiki Query — ナレッジ検索

生のソースドキュメントではなく、コンパイルされた Obsidian wiki に対して質問に答えています。wiki には事前に統合され、相互参照されたナレッジが含まれています。

開始する前に

1. Config を解決 — llm-wiki/SKILL.md の Config Resolution Protocol に従います（CWD をたどって .env → ~/.obsidian-wiki/config → プロンプトセットアップ）。クロスプロジェクトクエリがある場合、.env への symlink であっても、~/.obsidian-wiki/config が存在する場合はそれを優先します。これにより OBSIDIAN_VAULT_PATH と任意の QMD 変数が得られます。任意のプロジェクトディレクトリから動作します。
2. 取得戦略を決定する前に、解決された config から QMD 設定をロード します。QMD_WIKI_COLLECTION が設定されている場合、QMD を利用可能な主体として扱い、以下のトランスポート/ツール チェック対象にします。空または未設定の場合、grep/ページ読み込みを使用する前に QMD がスキップされる理由を簡潔に述べます。
3. $OBSIDIAN_VAULT_PATH/hot.md が存在する場合、まずそれを読みます — 最近のアクティビティについて即座のコンテキストが提供されます。ユーザーの質問が最近取り込まれたものについてである場合、index.md を開く前に hot.md が答えられるかもしれません。
4. $OBSIDIAN_VAULT_PATH/index.md を読んで wiki のスコープと構造を理解します。

可視性フィルタ（オプション）

デフォルトでは、すべてのページは可視性タグに関係なく返されます。これは既存の動作を保持します — ユーザーが要求しない限り何も変わりません。

ユーザーのクエリに 「public only」、「user-facing」、「no internal content」、「as a user would see it」、「exclude internal」 などの句が含まれている場合、フィルター済みモード をアクティブにします：

• ブロック済みタグセットを構築: {visibility/internal, visibility/pii}
• インデックスパス（ステップ 2）では、フロントマッターのタグがブロック済みタグを含むすべての候補をスキップします
• セクション/フル読み込みパス（ステップ 3-4）では、ブロック済みページを読んだり引用したりしません
• 許可されたページからのみ 回答を統合します — 除外されたページが存在することについては言及しません

visibility/ タグを持たないページ、または visibility/public とタグ付けされたページは常に含まれます。

フィルター済みモードでは、ステップ 6 のログエントリにフィルタを記載します：mode=filtered。

取得プロトコル

llm-wiki/SKILL.md の取得プリミティブテーブルに従います。 読み込みはこのスキルの主要なコストです — 質問に答える最も安価なプリミティブを使用し、できない場合にのみエスカレートします。フルページ読み込みに直接ジャンプしないでください。

ステップ 1: 質問を理解する

クエリタイプを分類します：

• ファクト検索 — 「What is X?」→ 関連するページを見つけます
• 関係クエリ — 「How does X relate to Y?」/「What contradicts X?」→ 両方のページ、相互参照、relationships: フロントマッターブロックを見つけます
• 統合クエリ — 「What's the current thinking on X?」→ X に関連するすべてのページを見つけて、統合します
• ギャップクエリ — 「What don't I know about X?」→ 何が不足しているか見つけ、未解決の質問セクションをチェックします

またモードを決定します：

• インデックスのみモード — 「quick answer」、「just scan」、「don't read the pages」、「fast lookup」でトリガーされます。ステップ 3 で停止します。フロントマッター + index.md のみから回答します。
• 通常モード — 以下の完全な階層化されたパイプライン。

ステップ 2: インデックスパス（低コスト）

ページ本文を開かずに候補セットを構築します：

• 上記で既に index.md を読んでいます — 最初のフィルタとして使用します。すべてのページが 1 行の説明とタグ付きでリストされています。
• Grep を使用してページのフロントマッターのみ をタイトル、タグ、エイリアス、サマリーマッチでスキャンします。^(title|tags|aliases|summary): パターンを vault .md ファイルにスコープすることは、コンテンツ grep より はるかに低コストです。
• ランク付けされた上位 5-10 の候補ページパスを収集します：
  1. 完全なタイトルまたはエイリアスマッチ
  2. タグマッチ
  3. サマリーフィールドがクエリ用語を含む
  4. index.md エントリがクエリ用語を含む

インデックスのみモード である場合、ここで停止します。summary: フィールド、タイトル、index.md 説明のみから回答します。回答に明確にラベルを付けます：「(index-only answer — page bodies not read; facts below are from page summaries and may miss nuance)」。その後ステップ 5 にスキップします。

ステップ 2b: QMD セマンティックパス（オプション — 解決された config の QMD_WIKI_COLLECTION が必須）

ガード: config 解決後に $QMD_WIKI_COLLECTION が空または未設定の場合、このステップ全体をスキップしてステップ 3 に進みます。動作中の更新で欠落している変数について言及します。

QMD がない場合： ステップ 3 にスキップして、vault に直接 Grep を使用します。QMD はより高速で概念を認識しますが、grep パスは完全に機能します。セットアップについては .env.example を参照してください。

QMD_WIKI_COLLECTION が設定されている場合、hot.md または index.md メタデータで質問が既に完全に答えられていない限り、Grep に手を伸ばす前に QMD を実行します。質問がセマンティック、プロジェクト固有、関連コンテキストを求めている、またはタイトル/フロントマッターに逐語的に表示されないかもしれない用語を使用している場合、QMD が特に推奨されます。

$QMD_TRANSPORT から QMD トランスポートを選択します：

• mcp（デフォルト）: エージェントで設定されている QMD MCP ツールを使用します。
• cli: ローカル qmd CLI を実行します。設定されている場合 $QMD_CLI を使用し、そうでなければ qmd を使用します。

詳細な CLI コマンド選択、メンテナンス、VM の注意については、インストールされている場合はローカル $qmd-cli スキルを使用します。

選択されたトランスポートが利用不可の場合（MCP ツールがない、qmd が PATH にない、またはコマンドがエラーの場合）、QMD をスキップしてステップ 3 を続行します。

MCP トランスポートの場合：

mcp__qmd__query:
  collection: <QMD_WIKI_COLLECTION>   # 例："knowledge-base-wiki"
  intent: <ユーザーの質問>
  searches:
    - type: lex    # キーワードマッチ — 正確な名前、ファイルパス、エラーメッセージに適しています
      query: <重要な用語>
    - type: vec    # セマンティックマッチ — 概念、パターン、「what is X like」に適しています
      query: <説明として言い換えられた質問>

CLI トランスポートの場合、$QMD_CLI_SEARCH_MODE からコマンドを選択します：

no-sudo、ansible_become=false、~/.local/bin などのオペレータのような句読点が多いトークンを lex: 行に保持します。vec: 行をハイフンで区切られた -term 単語のない平文の自然言語として書き直します。QMD は -term を否定として扱い、vec/hyde クエリでは否定がサポートされていません。

• quality（デフォルト）: 最高の関連性。CPU では遅い。

  ${QMD_CLI:-qmd} query $'lex: <重要な用語>\nvec: <説明として言い換えられた質問>' -c "$QMD_WIKI_COLLECTION" -n 8 --files
  

• balanced: LLM リランクなしのハイブリッド検索。quality が遅すぎる場合に使用します。

  ${QMD_CLI:-qmd} query $'lex: <重要な用語>\nvec: <説明として言い換えられた質問>' -c "$QMD_WIKI_COLLECTION" -n 8 --no-rerank --files
  

• fast: セマンティックのみのリコール、または正確な名前、ファイルパス、またはエラーメッセージが重要な場合は search を使用します。

  ${QMD_CLI:-qmd} vsearch "<説明として言い換えられた質問>" -c "$QMD_WIKI_COLLECTION" -n 8 --files
  

CLI 出力が docid を提供する場合、${QMD_CLI:-qmd} get "#docid" を使用してランク付けされたドキュメントを docid で取得します。

返されたスニペットまたはランク付けされたファイルは事前読み込みセクションサマリーとして機能します。それらが質問に完全に答える場合、ステップ 3 をスキップしてステップ 4 に直接進みます（QMD がランク付けした最高のページのみを読む）。そうでない場合、ランク付けされたファイルリストを使用して、ステップ 3 でどのファイルを grep または読むかをガイドします。

質問が _raw/ にソースマテリアルを持つかもしれない場合、papers も検索します：

QMD_PAPERS_COLLECTION が設定されており、ユーザーが取り込まれた論文で対象とされる可能性のあるトピック（研究、理論、背景）について質問している場合、papers コレクションに対して並列検索を実行します。コンパイルされた wiki ページとは別に、回答では生のソースを引用します。

ステップ 3: セクションパス（中程度のコスト — ステップ 2/2b が結論に至らない場合のみ）

上位の候補それぞれについて、ページ全体を読まずに 関連セクションを取得します：

• Grep -A 10 -B 2 "<クエリ用語>" <候補ファイル> を使用してマッチの周囲の行のみを取得します。
• これは通常、ヒットごとに 15-30 行を返します。100-500 行ではなく。
• セクション grep が明確な答えを与える場合、ステップ 5 に直接進みます。

ステップ 4: フル読み込み（高コスト — 最後の手段）

ステップ 2 と 3 が質問に答えない場合のみ：

• 上位 3 候補を全体で Read します。
• 答えが相互参照を必要とする場合、これらのページから [[wikilinks]] の最大 1 ホップをたどります。
• 関係クエリの場合 （「How does X relate to Y?」/「What contradicts X?」）: 候補ページの relationships: フロントマッターブロックも読みます。各エントリは型付けされた方向エッジを与えます（extends、implements、contradicts、derived_from、uses、replaces、related_to）。これらを回答に明示的に表示します — 「Page A contradicts Page B (typed edge)」は「Page A links to Page B」より有用です。
• 「Open Questions」セクションで既知のギャップを確認します。
• それでも不足している場合、その後 vault 全体への広範なコンテンツ grep にフォールバックします。ユーザーにエスカレートしたことを伝えます — これは高コストパスであり、ユーザーは知るべきです。

ステップ 5: 回答を統合する

wiki コンテンツから回答を構成します：

• [[ページ名]] 表記を使用して特定の wiki ページを引用します
• 回答がどのステップから来たか（「found in summary」対「grepped section」対「full page read」）を注記します — ユーザーが信頼性を理解するのに役立ちます
• wiki に矛盾がある場合、両方の側面を提示します
• wiki がカバーしていないものについては、明示的に述べます
• ギャップを埋めるかもしれないソースを提案します

ページ信頼アノテーション： 回答で引用するすべてのページについて、その lifecycle フロントマッターをチェックし、is_stale = (today − updated) > 90 days を計算します。リスクのあるページにインラインでアノテーションを付けて、ユーザーがどの引用を検証すべきかを知るようにします：

条件	アノテーション
lifecycle: archived	(ARCHIVED: superseded by [[target]]) — 代わりに後継を使用します
lifecycle: disputed	(DISPUTED, marked <lifecycle_changed>: <lifecycle_reason or "reason unspecified">)
is_stale + lifecycle: verified	(VERIFIED but stale: last updated <updated>) — 依頼する前に読者が再検証すべき
is_stale（他の lifecycle）	(stale: last updated <updated>)

統合された回答の例：

[[concept-page]] (stale: last updated 2026-01-15) — 元の主張は X でした。
[[verified-page]] (VERIFIED but stale: last updated 2025-09-10) — 依頼する前に読者が再検証すべき。
[[disputed-page]] (DISPUTED, marked 2026-04-30: contradicted by [[new-source]]) — 以前は Y と述べられ、現在は不確実です。
[[old-page]] (ARCHIVED: superseded by [[new-page]]) — 後継を使用します。

lifecycle フィールドを持たないページ（スキーマより前の従来のページ）は draft と同じとして扱われます — 古い場合はアノテートを付け、そうでない場合はスキップします。lifecycle_reason を捏造しないでください。フィールドが存在しない場合、アノテーションから理由を省略します。

ステップ 6: クエリをログする

log.md に追加します：

- [TIMESTAMP] QUERY query="ユーザーの質問" result_pages=N mode=normal|index_only|filtered escalated=true|false

回答形式

このように回答を構成します：

Wiki に基づいて：

[[[wikilinks]] でソースページに対応した統合回答]

参照ページ： [[page-a]], [[page-b]], [[page-c]]

ギャップ： [wiki がカバーしていないが関連するかもしれないもの]