ask

今すぐ実行

質問：$ARGUMENTS

質問が入力されていない場合は、知りたいことをユーザーに尋ねてください。

以下の手順を実行してください：

1. 質問を分類する — 参照するナレッジベースの階層を判定します（下記の「質問の分類」を参照）
2. ナレッジベースを検索する — 分類に応じて適切な階層を検索します
3. 関連する主張とドキュメントを読む — 最も関連性の高いソースを3～7件すべて読み込みます（複数の ID を読む場合は mcp__qmd__multi_get を使用します）
4. ユーザーのコンテキストを確認する — 質問がユーザー固有のシステムに関係する場合は、ops/derivation.md を読みます
5. 回答をまとめる — 主張をつなぎ合わせ、一貫性のある、明確な立場を示す議論を構成します
6. ソースを引用する — ユーザーがさらに詳しく確認できるよう、具体的な主張やドキュメントを参照します

今すぐ開始してください。 検索先の振り分けと統合方法については、以下を参照してください。

---

3 階層のナレッジベース

このプラグインのナレッジベースは、それぞれ異なる役割を担う3つの要素で構成されています。効果的な回答では、複数の階層を参照することがよくあります。

階層1：リサーチグラフ（WHY）

場所： ${CLAUDE_PLUGIN_ROOT}/methodology/ — kind: research で絞り込みます 内容： 認知科学、知識システム理論、エージェント認知の研究に基づく、相互につながった213件の研究上の主張です。 用途： 原則、トレードオフ、機能する理由、理論的基盤に関する質問に使用します。

含まれる内容：

• 知識システム（人間とエージェント）の仕組みに関する主張
• 認知科学の基礎（作業記憶、注意、検索）
• 方法論の比較（Zettelkasten と PARA、アトミック型と複合型）
• 設計上の次元（両極と判断要因を含むトレードオフのスペクトラム）
• 失敗モードとアンチパターン
• エージェント固有の制約（コンテキストウィンドウ、セッションの境界）

検索方法： 概念に関する質問には mcp__qmd__deep_search（品質が最も高く、LLM による再ランキングあり）を使用します。意味的な探索には mcp__qmd__vector_search を使用します。既知の用語を検索するには mcp__qmd__search を使用します。すべての検索で methodology コレクションを使用します。

階層2：ガイダンスドキュメント（HOW）

場所： ${CLAUDE_PLUGIN_ROOT}/methodology/ — kind: guidance で絞り込みます 内容： 手順、ワークフロー、実装の根拠を扱う9件の運用ドキュメントです。 用途： 作業の進め方、運用上のベストプラクティス、ワークフローの仕組みに関する質問に使用します。

ドキュメントの内容：

• スキーマ適用の根拠と手順
• パイプラインの理念と処理ワークフロー
• MOC の方法論とナビゲーションパターン
• 保守パターンと条件に基づくトリガー
• メモリーアーキテクチャとセッション管理
• 語彙変換の手順
• 失敗モードの予防パターン
• 複数ドメインの構成ルール
• オンボーディングと発展に関する判断

検索方法： 質問に含まれるキーワードを使い、methodology コレクションで mcp__qmd__search を実行します。ガイダンスドキュメントに絞るには、検索結果に対する grep フィルターに kind:guidance を追加します。

階層3：ドメインの例（WHAT IT LOOKS LIKE）

場所： ${CLAUDE_PLUGIN_ROOT}/methodology/ — kind: example で絞り込みます 内容： 生成された Vault の実例を示す、12件のドメイン固有の構成です。 用途： 方法論を特定のドメインに適用する方法に関する質問や、新しいドメインへのマッピングのヒントに使用します。

例に含まれるドメイン：

• リサーチ Vault（学術文献レビュー、主張の抽出）
• パーソナルアシスタント Vault（生活管理、セラピー、健康とウェルネス）
• プロジェクト管理 Vault（意思決定の追跡、ステークホルダーのコンテキスト）
• クリエイティブ Vault（世界観の構築、登場人物の追跡）
• エンジニアリング、法律、トレーディング、学生の学習、人間関係

検索方法： methodology コレクション全体から意味的に一致するドメインを探すには、mcp__qmd__vector_search を使用します。すべての例を一覧表示するには、rg '^kind: example' ${CLAUDE_PLUGIN_ROOT}/methodology/ を実行します。

参考ドキュメント（構造化された導出コンテキスト）

場所： ${CLAUDE_PLUGIN_ROOT}/reference/ 内容： 導出とシステムアーキテクチャを支える構造化された参考ドキュメントです。 用途： 特定のアーキテクチャ上のトピックを深掘りする場合、各次元の位置を相互参照する場合、また相互作用の制約を理解する場合に使用します。

コアアーキテクチャ：

• methodology.md — 普遍的な原則と処理パイプライン
• components.md — コンポーネントの設計図と機能ブロック
• kernel.yaml — 譲れない12の基本要素
• three-spaces.md — self／notes／opsのアーキテクチャと境界ルール

設定と導出：

• dimension-claim-map.md — どの研究上の主張がどの次元に反映されるか
• interaction-constraints.md — 次元の選択が他の次元にどのような影響を与えるか
• tradition-presets.md — 設定空間における名前付きの構成
• vocabulary-transforms.md — 普遍的な用語からドメイン固有の用語への対応付け
• derivation-validation.md — 導出されたシステムの検証テスト

振る舞いと品質：

• personality-layer.md — パーソナリティの導出とエンコード
• conversation-patterns.md — 導出パス全体の実例
• failure-modes.md — ナレッジシステムが機能しなくなる原因と、その予防パターン

ライフサイクルと運用：

• use-case-presets.md — 一般的なドメイン向けのプリセット設定
• session-lifecycle.md — セッションのリズム、コンテキスト予算、orient-work-persist
• evolution-lifecycle.md — seed-evolve-reseed、条件に基づくメンテナンス
• self-space.md — エージェントのアイデンティティ生成、self/アーキテクチャ
• semantic-vs-keyword.md — 検索方式の選択に関するガイダンス
• open-questions.md — 未解決の研究上の問いと保留項目

こちらも参照： claim-map.md — 各主張がどのトピックに対応するかを示すルーティングインデックスです。関連する主張をすばやく探す必要がある場合は、ここから始めてください。

---

クエリの分類

検索する前に、ユーザーの質問を分類し、参照する階層を特定してください。

分類ルール

質問の種類	手がかり	主要な階層	副次的な階層
WHY	「なぜ……なのか」「理由は何か」「背景にある理論は何か」「単に……ではだめなのか」	Research Graph	Guidance Docs
HOW	「どのように……すればよいか」「ワークフローは何か」「どのように進めるべきか」「手順は何か」	Guidance Docs	Research Graph
WHAT	「Xはどのようなものか」「例を見せて」「これを……に適用するとどうなるか」「Yのボルトはどのようなものか」	Domain Examples	Guidance Docs
COMPARE	「XとYの比較」「……との違いは何か」「XとYのどちらを使うべきか」「両者のトレードオフ」	Research Graph	Examples
DIAGNOSE	「何かおかしい」「なぜ動作しないのか」「本来は……となるはずなのに、システムがXをしている」	Guidance Docs + Reference（failure-modes.md）	Research Graph
CONFIGURE	「どの次元か」「どのように設定すべきか」「どの設定がよいか」「どのプリセットか」	Reference（dimensions、constraints）	Research Graph
EVOLVE	「変更すべきか」「システムが成長してきた」「もう合わなくなった」	Reference（evolution-lifecycle.md）	Guidance Docs

複数ティアにまたがる質問

複数のティアを参照する必要がある質問は数多くあります。上記の分類では、主要なティアと副次的なティアを示しています。必ず、別のティアの根拠を加えることで回答がより確かなものになるかを確認してください。

複数ティアにまたがるルーティングの例：

質問：「私のシステムが長いドキュメントではなく、アトミックなノートを使うのはなぜですか？」

1. WHY ティア — リサーチグラフを検索し、アトミック性、粒度、合成可能性に関する主張を探す
2. リファレンス — dimension-claim-map.md で、粒度の次元を裏付ける主張を確認する
3. ユーザーのコンテキスト — ops/derivation.md で、ユーザー固有の粒度に関する立場と理由を確認する
4. WHAT ティア — 必要に応じて、類似分野におけるアトミックなノートの例を取得する

質問：「非常に長いセラピーセッションのノートを、どのように扱えばよいですか？」

1. HOW ティア — 処理のワークフローやチャンク化の戦略に関するガイダンスを検索する
2. WHAT ティア — 同様の課題があるセラピー分野または個人分野の例を確認する
3. WHY ティア — コンテキストの劣化、チャンク化の利点、大量のソースの扱いに関する主張を検索する

---

検索戦略

ステップ 1：クレームマップにルーティングする

まず ${CLAUDE_PLUGIN_ROOT}/reference/claim-map.md を読みます。これはルーティングインデックスです。ユーザーの質問に関連するトピック領域と、最初に確認すべき主張が示されています。このステップを省略して、やみくもに検索してはいけません。

ステップ 2：適切なティアを検索する

WHY の質問（リサーチグラフ）の場合：

mcp__qmd__deep_search  query="[user's question rephrased as a search]"  collection="methodology"  limit=10

概念に関する質問には mcp__qmd__deep_search（ハイブリッド検索＋LLM による再ランキング）を使います。最適な関連情報では、質問とは異なる語彙が使われていることがよくあるためです。検索結果にはさまざまな種類が含まれます。kind: research の結果を優先してください。

HOW の質問（ガイダンスドキュメント）の場合：

mcp__qmd__search  query="[key terms from question]"  collection="methodology"  limit=5

ガイダンスドキュメントでは用語が一貫しているため、まずキーワード検索を使います。キーワード検索で見つからない場合は、セマンティック検索に切り替えます。kind: guidance の結果を優先してください。

WHAT の質問（分野別の例）の場合：

mcp__qmd__vector_search  query="[domain + what the user wants to see]"  collection="methodology"  limit=5

正確な分野名が異なる場合でも、最も関連性の高い分野別の例を見つけるために、セマンティック検索を使います。kind: example の結果を優先してください。

qmd 検索のフォールバック順：

• MCP ツール（mcp__qmd__deep_search、mcp__qmd__vector_search、mcp__qmd__search）
• qmd CLI（qmd query、qmd vsearch、qmd search）
• ${CLAUDE_PLUGIN_ROOT}/methodology/ と ${CLAUDE_PLUGIN_ROOT}/reference/ を直接読み取る、または grep で検索する

リファレンスドキュメントの場合： トピックに基づいて、個別のリファレンスドキュメントを読みます。関連するリファレンスドキュメントはクレームマップに示されています。すべてではなく、最も関連性の高い 2～4 件を読み込みます。

ステップ 3：深く読み込む

検索結果を流し読みしてはいけません。上位 3～7 件について、次の手順を実行します。

1. クレームノートまたはドキュメントの全文を読む
2. Wiki リンクをたどり、関連する主張を確認する（1 ホップ）
3. 回答をより確かなものにする、主張間のつながりを記録する

深さの原則： 10 件の主張を引用する浅い回答より、4 件の主張を深く読み込み、筋の通った論旨にまとめた回答のほうが優れています。情報源を絞り、より深く読み込んでください。

ステップ 4：ユーザーのコンテキストを確認する

質問がユーザー固有のシステムに関わる場合：

1. derivation を読む — ops/derivation.md には、ユーザーの各次元における立場、語彙、制約、そして設定を選んだ理由がすべて記載されています
2. 語彙を適用する — ${CLAUDE_PLUGIN_ROOT}/reference/vocabulary-transforms.md を使って、汎用的な用語をユーザーの分野の言葉に置き換えます。セラピーシステムを使っている場合は、「claims」ではなく「reflections」について回答します
3. 制約を確認する — ${CLAUDE_PLUGIN_ROOT}/reference/interaction-constraints.md を参照し、ユーザーの設定が質問に関係する特定の圧力を生み出していないか確認します
4. 次元固有のリサーチを引用する — ${CLAUDE_PLUGIN_ROOT}/reference/dimension-claim-map.md を使い、ユーザーの設定を裏付ける具体的な主張に基づいて回答します

ステップ 5：ローカルの方法論を確認する

ops/methodology/ を読み、システム固有の自己知識を確認します。方法論のメモは、導出ドキュメントより新しい場合があります。元の導出では予想されていなかった、継続的な運用上の学びが記録されているためです。

# Load all methodology notes
for f in ops/methodology/*.md; do
  echo "=== $f ==="
  cat "$f"
  echo ""
done

方法論のメモがユーザーの質問に関係する場合：

• 調査上の主張と併せて引用します：「システムの方法論のメモには [X] とあり、これは調査上の主張 [[Y]] と一致しています」
• 方法論のメモが調査上の主張と矛盾する場合は、その食い違いを示します：「方法論のメモには [X] とありますが、調査では [Y] が示唆されています。/{DOMAIN:rethink} を使って調査する価値があるかもしれません」
• システムの動作に関する質問では、一般的な調査グラフよりも、方法論のメモのほうが「自分のシステムはどのように動くのか」という問いに対する信頼性が高くなります

調査より方法論を優先する場合：

• 「自分のシステムはなぜ X をするのか」という質問 — 方法論のメモには固有の理由が記録されています
• 動作パターンに関する質問 — 方法論のメモにはシステム固有の学びが記録されています
• 設定に関する質問 — 方法論のメモには、derivation.md にない初期化後の変更が記録されている場合があります

方法論より調査を優先する場合：

• 「一般に、なぜ X はよい考えなのか」という質問 — 調査上の主張が理論的な基礎となります
• 代替アプローチに関する質問 — 調査グラフには、システムが採用しなかった選択肢も含まれています
• 方法論の比較に関する質問 — 調査上の主張では、各流派が体系的に比較されています

---

回答の統合

構成

すべての回答は、次の構成に従います。

1. 直接的な回答 — 検索の過程ではなく、回答を最初に示します。「X を検索して Y が見つかりました」とは言わず、答えそのものを伝えます。

2. 調査による裏付け — 回答を裏付ける具体的な主張を示します。タイトルを引用します：「[[主張のタイトル]] によると……」

3. 実践的な意味合い — これがユーザー固有の状況にとって何を意味するのかを説明します。導出から確認できる場合は、ユーザーの領域の用語を使用します。

4. 矛盾点や注意事項 — 未解決の対立、限界、または回答が当てはまらない可能性のある状況を示します。調査には実際に矛盾する点があるため、率直に伝えます。

5. さらなる調査 — ユーザーが調べてみたい関連する主張やトピックを示します。課題ではなく、次の出発点として提示します。

6. 参照した情報源 — 使用した知識レイヤーを簡潔に示します：「調査：参照した主張 [N] 件。ローカルの方法論：参照したメモ [M] 件。」ローカルの方法論が関係する場合は、具体的なメモを挙げます：「方法論のメモ [[タイトル]] が、この回答の [具体的な部分] の参考になりました。」

品質基準

一般知識ではなく、具体的な主張に基づいて回答してください。 ナレッジベースは、根拠に基づく回答を提供するためにあります。グラフを確認せずに一般知識から回答するのは、ツールを使わずに済ませていることになります。

不足がある場合は、正直に伝えてください。 調査で扱われていない内容については、その旨を伝えてください。「現在の調査グラフには、X に関する主張がありません」は正当な回答です。扱われていない内容をでっち上げないでください。

確実性のレベルを区別してください。 複数の裏付けとなる主張がある、確立された主張もあれば、予備的な観察や研究の方向性を示すものもあります。クレームのフロントマターにある confidence フィールドは、次のように示しています。

• confidence フィールドなし — 標準的な確立済みの主張
• confidence: speculative — 初期段階の観察で、十分に評価されていません
• confidence: emerging — 有望ですが、さらなる裏付けが必要です
• confidence: supported — 十分な証拠に裏付けられた主張
• confidence: established — 基盤となる、広く支持された主張
• status: archived — 置き換えられた、または解消された主張

明確な見解を示してください。 この研究には立場があります。それを共有してください。「研究は X を強く示唆しています。なぜなら……」は、「X と言う情報源もあれば、Y と言う情報源もあります」より適切です。実際に意見の相違がある場合は、見せかけの中立性ではなく、対立点として提示してください。

ユーザーの状況に合わせて説明してください。 ユーザーに導出結果がある場合は、知見をそのシステムに適用してください。一般的な助言より、具体的な適用のほうが役に立ちます。「一般に、これは……を意味します」より、「あなたのセラピー用 Vault では、これは……を意味します」のほうが適切です。

回答例

例 1：WHY に関する質問

質問：「私のシステムは、なぜ長い文書ではなくアトミックノートを使うのですか？」

分類： WHY -> 主：研究グラフ。副：リファレンス（dimension-claim-map）。

検索：

1. mcp__qmd__deep_search query="atomic notes vs compound documents granularity" collection="methodology" limit=8
2. reference/dimension-claim-map.md を読み、粒度の次元に関連する主張を探します
3. ops/derivation.md を読み、ユーザーの粒度に関する立場を確認します

回答：

あなたの会話では「論文から正確な主張を抽出する」という意図が示されていたため、あなたのシステムはアトミックな粒度を採用しています。研究によると、アトミックノートは独立したリンクと再構成を可能にします。[[atomic notes maximize recombinable surface area]] によれば、各ノートは無関係な内容を引きずることなく、どのコンテキストからでもリンクできます。あなたの処理パイプライン（extract -> reflect -> reweave -> verify）は、リンクのつながりを維持するために、特にアトミックな粒度を必要とします。[[verify phase checks link density per note]] にあるように、複合文書ではリンク数が人為的に膨らんでしまうためです。

トレードオフとして、アトミックノートはファイル数が増え、より密なナビゲーション構造が必要になります。[[flat organization requires semantic search at scale]] では、フラットな構成のアトミックノートが約 50 件を超えると、セマンティック検索がなければノートを見つけることが実用的でなくなる理由が説明されています。

緊張関係： [[composability and context compete at the note level]] — ノートをすっきりリンクできるほど小さくすると、そのノートだけでは独自の論拠を伝えきれないほど小さくなることがあります。あなたのシステムでは、説明フィールドとトピックマップのコンテキスト句でこれに対処しています。

例 2：HOW に関する質問

質問：「大規模な研究論文を処理するにはどうすればよいですか？」

分類： HOW → 主：ガイダンスドキュメント。副：Research Graph。

検索：

1. mcp__qmd__search query="large source processing chunking" collection="methodology" limit=5
2. mcp__qmd__deep_search query="context degradation large documents extraction" collection="methodology" limit=5

回答：

2500 行を超えるソースは、350～1200 行のセグメントに分割し、各セグメントを新しいコンテキストで処理してください。[ガイダンス：パイプライン処理のワークフロー] では、分割方法を詳しく説明しています。

その理由は、[[会話が長くなるにつれてコンテキストの品質が低下する]]ためです。3000 行のドキュメントの後半部分では、前半部分よりも抽出品質が明らかに低下します。セグメントごとに新しいコンテキストを使うことで、各セクションに最善の注意を払えます。

実践的な手順：

1. /seed を実行して抽出タスクを作成します
2. /reduce がソースのサイズを自動検出し、セグメントを計画します
3. 各セグメントを個別に抽出し、セグメント間で重複項目のリストを引き継ぎます
4. 最終的な抽出レポートには、すべてのセグメントをまとめた結果が含まれます

設定では processing.depth: standard になっているため、現在のセッション内でセグメントが順次処理されます。deep に切り替えると、各セグメントに独立したコンテキストが割り当てられます（品質は最高になりますが、処理は遅くなります）。

例 3：WHAT に関する質問

質問：「料理レシピの保管庫はどのようなものになりますか？」

分類： WHAT → 主：ドメインの例。副：ガイダンスドキュメント。

検索：

1. mcp__qmd__vector_search query="cooking recipes culinary knowledge system" collection="methodology" limit=5
2. 構成の参考として、最も近いドメインの例を読む

回答：

[具体的なフォルダー構成、ノートの例、トピックマップの例、料理分野に特有の語彙の選択を示す、例からまとめた回答。構成パターンの参考として、既存の最も近いドメインの例を紹介します。]

---

アンチパターン

避けるべきこと

アンチパターン	失敗する理由	代わりに行うこと
検索せずに回答する	ナレッジベースを完全に迂回してしまいます	「明らか」な質問でも、必ず検索します
主張をまとめずに列挙する	検索結果をそのまま並べるだけで、ユーザーに関連付けを強います	主張を筋の通った論拠にまとめます
1 つの階層だけを検索する	WHY への回答で HOW を見落としたり、その逆が起きたりします	副次的な階層が回答を補強するか確認します
ユーザーの導出情報を無視する	具体的な情報があるのに、一般的な助言をしてしまいます	ops/derivation.md を読み、ユーザーの背景を把握します
一般的な語彙を使う	ユーザーのシステムでは「リフレクション」と呼ぶものを「ノート」と呼んでしまいます	語彙の変換を適用します
主張の引用を捏造する	グラフに存在しない主張を引用してしまいます	実際に読んだ主張だけを引用します
claim-map を省略する	経路を定めずに検索してしまいます	まず claim-map を読み、トピックの概要を把握します
見せかけの両論併記をする	研究で明確な結論があるのに「X と言う人もいれば、Y と言う人もいます」と述べてしまいます	明確な見解を示し、研究の結論を伝えます

誠実さの基準

ナレッジベースでトピックが実際に扱われていない場合：

1. その旨を明確に伝えます：「現在の研究グラフには、X に関する主張がありません。」
2. 利用できる情報を提示します：「最も関連性の高い研究は Y に関するもので、次のことが示唆されています……」
3. 未調査の領域として示します：「研究の方向性として、調査する価値があるかもしれません。」

関連が薄い主張から、大きく飛躍した推論をしてはいけません。「わかりませんが、関連する情報はこちらです」と正直に伝えるほうが、回答を捏造するより有益です。

---

ドメインを考慮した回答

ユーザーの質問が、抽象的な方法論ではなく、ユーザー固有のシステムに関するものである場合：

ステップ 1: その人の導出を読む

ops/derivation.md を確認して、以下を理解します：

• その人の次元の位置（粒度、組織化、処理の深さなど）
• その人の語彙の選択（その人の領域では「ノート」は何と呼ばれているか？）
• その人の伝統のマッピング（どの方法論プリセットか、あるいは none か？）
• その人のパーソナリティ設定（フォーマル/温かい、臨床的/会話的）
• その人の制約プロファイル（どのインタラクション制約が有効か？）

ステップ 2: 領域の語彙を適用する

${CLAUDE_PLUGIN_ROOT}/reference/vocabulary-transforms.md を使用して、普遍的な用語をその人の領域の言葉に翻訳します。これは見た目上のことではなく、答えをその人のシステムにとってネイティブなものにすることが目的です。

普遍的な用語	セラピー領域	PM 領域	研究領域
notes	reflections	decisions	claims
topic map	theme map	project map	MOC
reduce	surface	extract	reduce
reflect	connect	link	reflect
inbox	journal	intake	inbox

ステップ 3: インタラクション制約を確認する

${CLAUDE_PLUGIN_ROOT}/reference/interaction-constraints.md を参照して、その人の設定が質問に関連する特定のプレッシャーを生み出すかどうかを理解します。次元の組み合わせによっては、答えに影響を与える緊張関係が生じます：

• 高い粒度 + フラットな組織化 = 強力なセマンティック検索が必要
• 許容的な選択性 + 深い処理 = 大量で、スループットが遅い
• 自己空間が有効 + 温かいパーソナリティ = 豊かなアイデンティティ層

ステップ 4: 次元固有の研究を引用する

${CLAUDE_PLUGIN_ROOT}/reference/dimension-claim-map.md を使用して、その人の設定の選択に情報を与える具体的な主張に答えを根拠づけます。これにより、答えが追跡可能になります：「あなたのシステムが X を行うのは、主張 Y があなたの設定に対してそれを支持しているからです。」