deep-research

ディープリサーチ — 反復型リサーチエンジン

網羅的な情報収集と統合を実行する、自律型のマルチステップリサーチエンジンです。単一の web_search とは異なり、エージェントが計画、検索、抽出、統合を繰り返し、いつ停止するかを判断する反復ループを実装しています。構造化された根拠、ソースの品質階層、明示的な不足点／矛盾点のセクションを含む、出典付きレポートを作成します。

根拠の evidence.json レイヤーについては references/structured-evidence-format.md を、適応型の深度に関する概念マッピングについては references/docsgpt-concepts.md を参照してください。

使用する場合

• ユーザーが「ディープリサーチ」「調査レポート」「包括的な分析」を求めている
• ユーザーが、トピックに関する簡単な回答ではなく、文章形式のレポートを求めている
• 質問への回答に、引用を伴う複数のソースの統合が必要である
• ユーザーが「X を詳しく調べて」または「X に関するレポートを書いて」と言っている

使用しない場合

• エンティティの審査／詳細調査 → entity-research を使用します（制裁対象のスクリーニングと、構造化された視点を備えています）
• 定期的なニュースダイジェスト → news-monitoring を使用します（cron、重複排除、多言語に対応しています）
• 収集したソースに基づく質疑応答 → notebooklm-mode を使用します（ボルトと RAG を備えています）
• 簡単な事実確認の質問 → web_search を直接使用します
• 単一ソースからの抽出 → web_search と web_extract を使用します

アーキテクチャ

User question
  → Step 0: Clarification (optional — assess if question is too vague)
  → Step 1: Plan (sub-questions, key topics, success criteria, category, language, complexity)
  → Step 2: Date grounding + language anchor
  → Step 3: Iterative loop (max rounds = complexity cap: simple=2, moderate=3, complex=5)
      ├─ 3a: Generate gap-driven queries (incl. refute queries from round 2+, empty-search refinement)
      ├─ 3b: Search (web_search) + fetch (web_extract)
      ├─ 3c: Quality filter + extraction + source quality classification + numbered citations
      ├─ 3d: Synthesize into cumulative research state (with token budget check)
      ├─ 3e: Structured evidence (optional: evidence.json for 5+ sources)
      └─ 3f: Stopping check (LLM evaluates coverage + token budget)
  → Step 4: Final report (overview-first structure, see template)
  → Step 5: Stats summary

レポートの出力順（概要を先に提示）： エグゼクティブサマリー → 比較／概要表 → サブクエスチョンごとの詳細分析 → 矛盾点 → 不足点 → 結論 → ソース表。読者は詳細な論拠を読む前に、回答と一目でわかる比較を確認できます。

ステップ 0 — 明確化（任意）

計画を立てる前に、質問が有意義な調査を進めるのに十分具体的かどうかを判断します。このステップにより、曖昧すぎる質問に調査ラウンドを費やすことを防げます。

明確化する場合：

• 質問が 1～5 語で、範囲が指定されていない（「AI を調査して」「量子コンピューティングについて教えて」）
• 意図によって大きく異なる意味になり得る（「X は良いですか？」―何にとって良いのか？誰にとって良いのか？）
• 質問に明確な切り口がない（「気候変動について調べて」―科学的な観点か、政策か、経済か？）

明確化しない場合：

• 質問にすでにサブクエスチョンや具体的な条件が含まれている
• ユーザーが「そのまま調べて」または「質問せずに進めて」と明示している
• すぐに有意義な検索クエリを作れるほど質問が具体的である
• 質問が単純な事実確認である（「X の最新バージョンは？」「Y はいつ起きた？」）―短くても意図が明確なら、そのまま進めます
• ユーザーが前の明確化への回答をしている（確認を繰り返さない）

方法： 範囲を絞り込める短い質問を 1～3 個、ユーザーに提示します。簡潔にしてください。これは範囲の確認であり、面接ではありません。

「調査を始める前に、確認させてください。

1. [範囲を絞り込む質問 1]
2. [範囲を絞り込む質問 2]

詳細を教えていただければ、調査を始めます。」

質問がすでに具体的であれば、このステップを完全に省略し、ステップ 1 に進みます。

ステップ 1 — 調査計画

検索を始める前に、質問を調査計画に分解します。次を出力してください。

## Research Plan
Question: [user's question]
Date: [current date]
Language: [BCP 47 tag — e.g. en, zh-Hans, ja. Detect from query; user's explicit language preference overrides. Use consistently throughout the report.]

Sub-questions:
1. [specific sub-question 1]
2. [specific sub-question 2]
3. [specific sub-question 3]
4. [up to 6 total]

Key topics:
- [topic 1]
- [topic 2]

Success criteria:
- [what would comprehensive coverage look like?]
- [minimum: each sub-question has ≥1 source]

Report category: [factual | comparison | product | how-to | fact-check | explainer]

Complexity: [simple | moderate | complex]

複雑さの評価と適応型の深さ： 調査ラウンドの最大数を決めるため、質問の複雑さを分類します。これにより、単純な質問で検索しすぎたり、複雑な質問で検索が足りなくなったりするのを防ぎます。

複雑さ	最大ラウンド数	1 ラウンドあたりの範囲	用途
simple	2	2	事実を 1 つ尋ねる質問、対象範囲が狭く、サブクエスチョンが 1～2 個のもの。例：「Python の最新バージョンは何ですか？」
moderate	3	3	複数の側面を含む質問、サブクエスチョンが 3～4 個あるもの、比較や手順を尋ねる質問。例：「RAG では Qdrant と pgvector のどちらがよいですか？」
complex	5	4	対象範囲が広く、サブクエスチョンが 5～6 個あるもの、分野をまたいだ深い統合が必要なもの。例：「AI インフラにおけるセルフホストとマネージド API のトレードオフを包括的に分析してください」

複雑さによる上限は最大値であり、目標ではありません。停止判定（ステップ 3f）に従って、早期終了することもできます。単純な質問で 1 ラウンドの検索で包括的な回答が見つかった場合は、1 ラウンドで終了してください。上限の 2 は、必要なら 2 ラウンドまで進められるという意味であり、必ず 2 ラウンド実施するという意味ではありません。

検索予算（上流の research-input.ts のプリセットと estimateMaxSearches を基に調整）：計画に予算を明記します。「検索予算：≤N クエリ」とし、N = 1 ラウンドあたりの範囲 × 最大ラウンド数です（スクリプト：estimate-budget --breadth B --rounds R）。2 ラウンド目以降に深掘りチェーン（§3a）を実行する場合、上限はツリーモードです：estimate-budget --breadth B --rounds R --halving。これは、上流の範囲を段階的に半減させる再帰処理です。予算はループが超えてはならない上限です。§3f の停止判定に従い、適切な回答が得られる最も低コストのラウンドを優先してください。

**言語の固定：**クエリから出力言語を検出し、BCP 47 タグ（例：en、zh-Hans、zh-Hant、ja）に正規化します。エグゼクティブサマリー、分析、矛盾点、情報の不足、結論を含む全体で、一貫してこの言語を使用してください。出典のタイトル、URL、固有名詞、コードは元の言語のままでもかまいません。証拠の収集に役立つ場合は、検索クエリに任意の言語を使用できます。ユーザーが調査の途中で明示的に言語を切り替えた場合は、言語の固定先を更新し、その後の出力すべてに新しい言語を使用してください。

レポートカテゴリの判定：

• 「vs」「compare」「better than」→ 比較
• 「best」「top」「recommend」「buy」→ 製品
• 「how to」「guide」「steps」→ 手順
• 「is it true」「verify」「fact check」→ ファクトチェック
• 「what is」「explain」「overview」→ 解説
• 該当なし → 事実

ステップ 2 — 日付の基準設定

検索を始める前に、現在の日付を設定します。これは必須です。LLM は学習データのカットオフ年を既定で参照するため、古いクエリが生成されることがあります。

今日の日付は {DD Month YYYY 形式の現在の日付} です。検索クエリに年が必要な場合や、「最新」「現在」「今年」に言及する場合は、{現在の年} または相対的な表現を使用し、学習データから推測した年は使用しないでください。

ステップ 3 — 反復ループ

ラウンドの構成

各ラウンドは、クエリ → 検索 → 抽出 → 統合 → 停止判定の順に進みます。

最大 N ラウンドまで実行します。N はステップ 1 の複雑さの上限です（単純＝2、中程度＝3、複雑＝5）。ほとんどのトピックは 2～3 ラウンドで収束します。上限は目標ではなく、超えてはならない上限です。

クエリのルール、取得の予算、引用のアンカー付け、統合のテンプレート、エビデンスストア、停止条件については、references/step3-iterative-loop.md を参照してください。

該当する項目	参照先
クエリの生成、検索と取得、抽出、アンカー付け、統合、停止判定	references/step3-iterative-loop.md
エビデンスストアのコマンドと 3 つの提出ゲート	references/validation-gates.md
中間ファイルの evidence.json	references/structured-evidence-format.md

1. 3a — クエリの生成（ギャップ主導） — 調査範囲はステップ 1 のプリセットに従います（単純＝2、中程度＝3、複雑＝4）。第 1 ラウンドでは計画の小項目を対象とし、以降のラウンドではギャップと記録済みの追加調査項目を対象とします。
2. 3b — 検索と取得 — ユーザーが donsetch MCP の検索／取得ツールを指定した場合はそれらを使用し、そうでない場合は web_search ／ web_extract を使用します。プロバイダーの指定を理由に処理を中断してはいけません。
3. 3b.1 — エビデンスの保存（5 件以上のソースを含むレポートでは必須） — 第 1 ラウンドから scripts/research_validation.py の init-run、register-source、add-claim、add-evidence、check-quote を使って保存します。
4. 3c — 品質フィルターと抽出 — 抽出する前に、品質の低い検索結果を除外します。
5. 逐語的な抜粋のアンカー付け（保存する主張では必須） — 保存する主張にはすべて、そのソースのページ本文からの連続した逐語的な抜粋を添えます。
6. エビデンスの根拠 — 4 種類のラベルを使い分ける — 重要な事実にはすべて、主張の根拠を示すラベルを付けます。
7. 3d — 統合 — このラウンドで抽出した情報を、累積的な調査状況に取り込みます。
8. 3e — 構造化エビデンス（5 件以上のソースを含むレポートでは推奨） — 最終レポートの前に、中間ファイルの evidence.json を作成します。形式については references/structured-evidence-format.md を参照してください。
9. 3f — 停止判定 — 統合後、レポートが十分に網羅的かどうかを判断します。十分でない場合は、上限まで次のラウンドに進みます。

ステップ 4 — 最終レポート

最終レポートを作成します。最低 800 語とし、トピックの複雑さに応じて分量を調整します。

出力は概要を先に示します。読者が詳細な説明を読む前に、回答と一目で分かる比較を提示します。比較表を各トピックの分析の後ろに置いてはいけません。

重要な事実にはすべてエビデンス根拠のラベルを本文中に付け（§3c）、[VERIFIED] ／ [SOURCED] の主張を先に示します。[REASONED] ／ [ESTIMATED] の主張は参考情報として提示し、タグの意味が分かるよう、「ソース」表の下にエビデンスキーの凡例を記載します。

統合プロンプトの構成： 最終レポートを作成する際は、（1）元の質問、（2）調査計画（小項目、成功基準）、（3）全ラウンドを通じた累積的な調査状況、（4）作成している場合は evidence.json、（5）番号付きのソース一覧を明示的に確認します。複数のラウンドを経て累積的な調査状況が圧縮されている場合、それだけに頼ってはいけません。重要な主張を検証するため、各ラウンドの調査結果を再確認してください。これにより、トークン予算の制約で調査状況が大幅に要約されていた場合にも、詳細が失われるのを防げます。

構成

# [Report Title]

> **Research date:** [date] · **Rounds:** [N] · **Sources:** [N] · **Category:** [type]

## Executive Summary
[2-3 paragraph overview of key findings — the answer up front. If using structured evidence, note claim count and refute count here so the reader knows the evidence base.]

## [Comparison Table | Overview | Key Findings at a Glance]
[For comparison reports: a markdown table comparing options/entities across criteria. For factual/explainer reports: a numbered list of key findings with claim references. This section gives the reader the complete picture in one screen — the detailed analysis below is the supporting reasoning, not the main event. If using structured evidence, cite claim IDs like [c1], [c3] in table cells or list items.]

## [## Section per sub-question]
[Detailed analysis with inline citations — this is the supporting reasoning for the overview above. Each section traces back to the overview claims.]

### [### Subsections as needed]
[...]

## Contradictions
[If sources disagree, present both sides with attribution. Do not silently arbitrate. If no contradictions found, state "No direct contradictions between sources." This section is REQUIRED — its absence is a quality signal that counter-evidence wasn't searched.]

## Gaps
[What couldn't be determined from available sources. Each gap should note: what's unknown, why it matters, and whether it could be resolved with more research. If using structured evidence, reference the writing_context items. If no gaps, state "No significant gaps identified." **Source-set bias check (mandatory):** the first gap line must state the bias your whole source set shares — one dominant language, era, school, jurisdiction, or industry — adapted from Munger inversion. A homogeneous source set is itself a gap, even when every individual source is primary-tier.]

## Conclusion
[Synthesis of findings, implications, remaining uncertainties — ties back to the executive summary and overview. The conclusion confirms or qualifies the overview, it doesn't introduce new analysis.]

---
## Sources

**Quality distribution:** [N] primary · [N] secondary · [N] tertiary — [healthy/acceptable/weak]

| # | Title | URL | Quality | Accessed |
|---|-------|-----|---------|----------|
| 1 | [title] | [url] | primary/secondary/tertiary | [date] |

**Citation format:** Inline citations use `[N]` matching the source table above. On first mention of a source, include `[N]` — subsequent mentions may use `[N]` alone. For claims from the same source, cite the number once per paragraph unless the source is paginated.

**Evidence key** — `[VERIFIED]` corroborated across ≥2 independent, cited, dated sources · `[SOURCED]` from one named source, not independently corroborated · `[REASONED]` analytical judgement / inference · `[ESTIMATED]` calculation or stated assumption.

カテゴリー別の概要セクション

カテゴリー	概要セクションの形式
comparison	基準ごとに選択肢を比較する Markdown テーブルと、判定を示す行または列を含めます。以下の詳細セクションでは、各選択肢の根拠を説明します。
product	長所と短所、価格帯、「おすすめ」の呼び出しを含むランキング形式のリストです。詳細セクションでは各製品を取り上げます。
how-to	手順の番号付き概要です。詳細セクションでは、各手順の前提条件、実行方法、トラブルシューティングを説明します。
fact-check	主張を支持する証拠と反証する証拠を、暫定的な判定とともに2列のテーブルにまとめます。詳細セクションでは、情報源の信頼性と論拠を評価します。
explainer	重要な調査結果を番号付きで示すか、「段階的に深める」概要（簡単な説明 → 詳細な説明）を提示します。詳細セクションでは、各概念を掘り下げます。技術的な内容の場合は用語集を付けます。
factual	主張への参照を含む、重要な調査結果の番号付きリストです。詳細セクションでは、各調査結果を裏付ける証拠を提示します。

フォールバックレポート

LLM による統合に失敗した場合（タイムアウト、エラー、文字化けした出力）、生の調査結果をまとめて基本的なレポートを作成します。

• すべての調査結果をサブクエスチョンごとにまとめて列挙します
• 情報源の URL を含め、各調査結果の証拠根拠タグを維持します
• 次の注記を追加します：「これは生の調査結果をまとめたものであり、統合は完了していません。」
• 情報源が1件でも取得されている場合、「情報を収集できませんでした」と出力してはいけません。常に取得できた内容をまとめます。

ステップ 5 — 調査統計

レポートの後に、簡潔な統計ブロックを出力します。

---
📊 Research stats: [duration] · [N] rounds · [N] queries · [N] page fetches · [N] sources cited · provider: [donsetch/built-in]

ステップ 5.5 — 検証ゲート（提出前に必須）

決定論的ゲート — scripts/research_validation.py は標準ライブラリのみを使用し、判断ではなく構造をチェックします。情報源が5件以上あるすべてのレポートは、提出前に3つのゲートを通過する必要があります：validate-report（構造）、verify-citations（本文中の [N] と Sources の行の照合）、および verify-claims --strict（保存された証拠が各事実主張を裏付けていること。basis: verified として保存された主張には、異なるサイトからの情報源が2件以上必要です。また、polarity: refute の主張が少なくとも1件必要です。該当する主張がない場合は --refute-none "<what you searched>" を指定します）。ループ： 検証 → 修正 → 3つすべてを再実行し、最大3サイクルまで行います。それでも失敗する場合は停止し、残っている問題をユーザーに正直に報告します。ゲートを省略してはいけません。ゲートが赤のまま提出してはいけません。情報源が2～3件の簡易レポート（ストアなし）の場合、verify-claims は失敗ではなく警告を出します。そのことを統計ブロックに記録します。仕様、フラグ、失敗時のループの全容は references/validation-gates.md を参照してください。

Jev による事前スクリーニング（任意）。 TypeSafe Jev が設定されている環境では、verify-claims に --jev-prescreen を追加して、決定論的な実行の前にゲートの誤った赤判定／緑判定を通知する、参考用の意味的な事前チェックを実施します。Jev が設定されていない場合は、エラーのない SKIPPED の行を出力して処理を続行します。ブロックすることはなく、ゲートの終了コードも変更しません。仕様については references/validation-gates.md を参照してください。

スニペットのアンカリングに関する前提条件。 verify-claims が評価するのは、保存されたスニペットです。適切にコピーされた引用と、適切に言い換えられた文章を見分けることはできません。それを確認するのが check-quote（§3c）です。スニペットが check-quote を通過していないのにゲートが赤になる場合、アンカリングが省略されており、それ自体が問題です。まずアンカリングし、次に保存し、その後にゲートを実行してください。

ステップ 6 — フォローアップレポートの改訂（任意）

提出済みレポートに対して「先ほどのレポートの X を確認して」「価格のセクションを更新して」といった依頼があった場合に使用します。上流のエビデンスパネルと report-revision.ts を参考にしたものです。フォローアップでは対象を絞って調査し、該当する調査結果を引用している箇所のみを修正します。レポートの残りの部分はバイト単位で変更されません。

1. 特定する。 python3 <skill_dir>/scripts/research_validation.py map-citations --report <report.md> [--citation N] を実行すると、各 [N] を引用しているトップレベルのブロックが返されます（コードフェンスは除外されます。N を引用するブロックがない場合は終了コード 1）。これにより、フォローアップで変更できる箇所が厳密に定まり、それ以外は変更できません。
2. 範囲を限定してフォローアップ調査を行う。 対象の調査結果とユーザーの指示から導いた検索の方向性は、1 ラウンドにつき最大 2 つです。§3b／§3c と同じ、スニペットを優先するトリアージと品質フィルターを適用します。新しいページのテキストは既存の実行ディレクトリに追加し、引用する前に新しい情報源を登録します。
3. 引用箇所のみを修正する。 ステップ 1 のブロックを改訂します（表とリストはブロック全体を更新します）。無関係な段落には手を加えません。エビデンスが既存の主張と矛盾する場合は訂正を明記します。不十分な場合は、修正内容をでっち上げず、その旨を伝えます。
4. 情報源。 新しい項目は次に使える番号を付けて Sources テーブルに追加します。既存の引用番号は付け直しません。既存のインライン [N] から引き続き情報源を参照できる状態にします。
5. 履歴。 改訂版は元のファイルと同じ場所に <name>-rev.md として保存します（さらに改訂する場合は -rev2、-rev3、…を使用します）。元のファイルには手を加えません。失敗またはキャンセルの場合、何も保存されません。
6. 改訂版に対し、3 つのゲートすべてを再実行する（ステップ 5.5）。改訂後にゲートが赤になった場合、改訂が正しく反映されていません。修正してから提出してください。

追加の投資分析（任意）

レポートが投資に関する質問を扱い、ユーザーが取引条件を提示した場合は、execute_code を使って定量的なプロフォーマを作成します。現状の用途を必ずベースラインとしてモデル化してください。テンプレートについては references/real-estate-investment-analysis.md を参照してください。

evidence.json のスキーマ、および執筆コンテキストと主張の違いについては、references/structured-evidence-format.md を参照してください。

Vault 連携（任意）

大規模な調査タスク（情報源が 10 件以上）や、ユーザーが根拠に基づく質疑応答を続けたい場合は、次の手順を実行します。

1. <project_folder>/research-<topic>/ に、notebooklm-mode の指示に従って Vault を作成します。
2. 各情報源の抜粋を原文のまま sources/ に番号付きファイルとして保存します。
3. ingest_source.py を使って、書き込みとインデックス作成をアトミックに実行します。
4. レポートの作成後、ユーザーに「情報源を [path] の Vault に保存しました。これらの情報源を根拠にしたフォローアップの質問ができます。Vault に問い合わせるには『notebooklm mode』と言ってください。」と伝えます。

これは任意です。単発のレポートであれば、Vault がなくてもスキルをすべて利用できます。

サブエージェントモード（任意）

異なるサブトピックについて実際に並行して調査する場合（例：互いに無関係な 3 社を調査する場合）：

delegate_task(
  goal="Research [sub-topic] as part of a deep-research project. Run web searches, extract content, and return findings with source URLs and titles.",
  context="You are a research subagent. Topic: [sub-topic]. Sub-questions: [list]. Use web_search and web_extract. Return structured findings with citations.",
  toolsets=["web"]
)

ルール：

• サブトピックが実際に独立している場合のみ、サブエージェントを使用します。
• すべてのサブエージェントから結果を集めた後、自分で統合します。
• 統合の工程は決して委任しません。オーケストレーターがすべての調査結果を確認する必要があります。
• サブエージェントの要約は自己申告です。引用する前に、情報源の URL が存在することを確認します。

同時実行とレート制限

• 全ページの取得は必要に応じて行い、§3b の予算内に収めます。1 ラウンドにつき最大 2 件、実行全体の上限は複雑さに応じて設定します。トリアージにはスニペットを活用します。
• web_extract が URL の処理に失敗した場合は、その旨を記録して次に進みます。延々と再試行しないでください。
• web_search の検索結果がない場合は、同一の書き換えで停止する条件を含む §3a の絞り込み手順を適用します。

注意点

• 根拠の過大評価 — 2 つのラベルで迷ったら、弱いほうを選びます。情報源の「約半分」は ~50% [SOURCED] のままにします。
• 主張とコンテキストの混同 — 対象に関する事実は主張です。範囲、方法論、利用可能性の制限は writing_context です。
• サブエージェントの自己申告 — 引用する前に、情報源の URL が存在することを確認します。オーケストレーターが統合します。
• 確認は 1 回 — 返答がまだ曖昧な場合は、意図を最もよく表す解釈で進めます。
• 複雑さの誤分類 — 複雑さとは、統合の幅であり、トピックがどれほど印象的に聞こえるかではありません。6 つの小問がある狭い事実トピックは中程度です。
• 上限前にトークン予算を使い切る — 長い抽出では、ラウンド上限を待たず、コンテキストが逼迫した時点で積極的に要約します。
• 単語境界の照合 — "port" が "transport" や "support" に一致するのは誤検出です。部分文字列の重複ではなく、トピックとの関連性で絞り込みます。
• ストア内の主張は引用に即した形にする — 決定論的なスコアラーが主張を裏付けと認めるのは、保存された 1 つの抜粋に、主張文が含むすべての数値、年、エンティティが含まれる場合だけです。それ以外は partial−0.01 が上限になります（事実に関する主張では厳格に赤判定）。この規則は、1 回のセッションで 3 回ライブ検証済みです。複数の事実を含む主張は抜粋ごとに分割し、主張文は引用とバイト単位で一致させ、文章による言い換えはレポート本文に残します。同じ規則の適用例：CJK の主張ではトークンが抽出されないため、抜粋と完全に同一でもスコアは約 0.33 です。そのため、主張文をバイト単位で一致させる（エンティティ軸 1.0）か、check-quote でアンカーします（トークン化不要）。大文字で連結された語句（「Scrape URL FIRECRAWL」→ エンティティ scrape url 1 つ）は、「Firecrawl」のみを記した主張とのセット照合に一致しません。英数字のブランド接頭辞（「x402」→ 数値 402）は、抜粋にブランド名が含まれない限り上限が適用されます。書き換える前に、スクリプトの _figures／_entities／_tokens ヘルパーで診断します。
• 誤った基盤へのアンカー — check-quote --source-id は pages/<source_id>.txt を読み込みます。文の出典と実際に一致する URL に ID が解決されることを確認してから、不一致を捏造と判断します。別ページのファイルに同じ文があれば、誤った赤判定になります。
• アンカーされていない抜粋 — check-quote を通過していない抜粋（またはエビデンス）を保存すると、滑らかな言い換えが「エビデンス」になってしまいます。スコアラーは見覚えのあるトークンを見て、裏付けありと評価するためです。保存したページ本文（<run_dir>/pages/<source_id>.txt）と照合済みの逐語的な抜粋を使い、不一致があれば 1 回だけ修正します。主張に近づけるために抜粋を手直ししたり、段落をまたいでつなぎ合わせたりしてはいけません。連続した抜粋が存在しない場合、その主張にはエビデンスの裏付けがありません。正直に保存し、ゲートに検出させます。
• ストア CLI の順序とフィールドの組み合わせ — サブコマンドは --dir より前に指定する必要があります（research_validation.py add-claim --dir <d> ...。--dir <d> add-claim は不可）。add-claim は claim+kind+polarity+basis+snippet+source_id を受け取り、add-evidence は evidence_snippet+source_id を受け取ります。組み合わせを入れ替えると、抜粋が source_id に保存され、後から未登録の source_id 警告として表面化します。basis が受け付けるのは 4 つのラベルのみです。情報源の TIER 名（primary／secondary）は拒否されます（rc 2）。また、kind は refute を値として受け付けません。refute は polarity です。スクリプトでストア呼び出しをループする場合は、各応答の JSON を確認します。拒否された呼び出しはループの「stored」メッセージが偽りを伝える一方で、終了コード 2 を出しても何も表示しません。
• 本文の引用密度 — Sources の各行は少なくとも 1 回引用する必要があります（引用されていない行があると verify-citations は失敗します）。必須セクション（## Executive Summary、## Contradictions、## Gaps、## Conclusion）は ## レベルにする必要があり、# にしてはいけません。
• 統合に失敗した場合のフォールバック — 生の調査結果を引用とタグ付きでまとめます。出力が空であることが失敗の状態です。
• エビデンスキー — Sources テーブルの下に 4 ラベルの凡例を貼り付け、[VERIFIED]／[SOURCED]／[REASONED]／[ESTIMATED] の意味がわかるようにします。

関連する取り組み

Odysseus — PewDiePie のセルフホスト可能な AI ワークスペース — には、複数ステップのウェブ調査と情報源の読み込みを行う「Deep Research」機能があります。この機能は、概念的にこのスキルの Think → Search → Extract → Synthesize → Stop ループに似ています。このスキルは、あらゆるエージェントのツールループ内で実行できるよう設計された、純粋なプロンプトベースのワークフローです（UI もサーバーもありません）。

AnotiaWang/deep-research-web-ui（MIT）— 強化されたエンジンを備えた、dzhng/deep-research をラップする Nuxt UI です。このスキルの主要なベンダーソースです。**取り込み済み：**逐語引用による証拠のアンカリング、v1.8.2（shared/utils/search-learning.ts → check-quote、§3c）；固定された制約、計画の規律、プロバイダーのガイダンスを含む構造化された検索ミニプラン、v1.9.0（shared/utils/search-plan.ts → §3a）；検索予算プリセット＋幅を半減する見積もり、v1.9.0（shared/utils/research-input.ts → Step 1 ＋ estimate-budget）；後続の調査方向に対する範囲を限定した深掘りの継続、v1.9.0（lib/core/deep-research.ts → §3a）；理由ごとの範囲を限定した再試行を含む6種類のラウンド結果分類、v1.9.1（shared/utils/search-assessment.ts → §3a）；スニペット優先のオンデマンド読み込みと取得予算、v1.9.0（lib/core/read-source.ts → §3b）；用語スコアに基づく逐語的な抜粋の選択、v1.9.0（lib/core/source-context.ts → §3d）；引用からブロックへのマッピングを用いた、ピンポイントなレポート改訂、v1.9.0（shared/utils/report-revision.ts → Step 6 ＋ map-citations）。**評価済み、未取り込み：**完全なツリー再帰、ストリーミング JSON の構造化出力修復、UI／デプロイ層、および dzhng の「情報源は無関係」というプロンプト（このスキルの出典管理の規律に反します）。両者の対応関係をまとめた完全版：references/anotiawang-deep-research-concepts.md。

Anjos2/recursive-research（MIT）— 長期サイクルの再帰的な調査を行う Claude Code のプロンプトスキルです。**取り込み済み（v1.9.2、ガイダンスレベル）：**飽和度に基づく停止シグナル（§3f）、計画内のサブ質問間での網羅性のバランス調整（§3a）、Gaps セクションでの情報源セットの偏りの必須チェック（Step 4）。**未取り込み：**サイクルの仕組み、WDM による情報源の重み付けスコアリング、ドメインごとのシード情報源リスト、コンテキスト中断の予防的なしきい値、ローカルコーパスモード。≤5% というしきい値は上流で検証されていません（リポジトリの最終プッシュは 2026-04-22 で、実環境での強化はありません）。これはルールではなくシグナルとして含まれています。対応関係：references/recursive-research-concepts.md。

DocsGPT（arc53、MIT）— 適応型の深さ、確認、トークン予算の追跡、検索結果が空の場合の絞り込みを備えた ResearchAgent の Plan → Research → Synthesize です。対応関係：references/docsgpt-concepts.md。

references/skills-monetization.md — 2026-07-01 の調査資料に基づく、AI スキルの収益化に関する知識ベースの要約（マーケットプレイス、売れるもの、価格設定）。

評価

evals/routing-fixtures.json には、軽量な契約フィクスチャが含まれています。サンプルリクエストから、想定されるルーティング、必須の出力フィールド、禁止される出力パターンを定めます。これらは仕様であり、実稼働中のモデルに対して実行されるものではありません。リポジトリルートの tests/test_routing_fixtures.py で、フィクスチャの形式が正しく保たれ、実在するスキルにルーティングされることを検証します。