research

ディープリサーチ

複数の情報源を統合し、信頼度をスコア化し、情報源の裏付けを監査し、幻覚を防止する汎用ディープリサーチです。設計は現在のディープリサーチのパターンに沿っています。検索前に計画を立て、広く調べてから絞り込み、リードエージェントを通じて並行するワーカーを調整し、引用した情報源が各主張を実際に裏付けているかを監査し、視点を広げて網羅性を高め、情報源を並べるのではなくレポートにまとめます。

標準用語

計画、ジャーナル、委任タスクのプロンプト、最終レポートでは、以下の標準用語をそのまま使用してください。

用語	定義
query	ユーザーの調査上の質問またはトピック。調査の単位です
claim	検証対象となる個別の主張。情報源またはユーザー入力から抽出されます
source	情報の特定の出所。URL、ドキュメント、データベースレコード、API レスポンスなどです
evidence	主張を裏付ける、または反証する情報源に基づくデータ。必ずプロヴェナンスを伴います
provenance	証拠から情報源までの経路。使用したツール、URL、アクセス日時、抜粋を含みます
confidence	主張ごとのスコア（0.0～1.0）。証拠の強さと相互検証に基づきます
cross-validation	2 つ以上の独立した情報源を使って主張を検証すること。幻覚を防ぐための中核的な仕組みです
triangulation	方法論の異なる 3 つ以上の情報源を使って調査結果を確認すること
contradiction	信頼できる 2 つの情報源が、互いに両立しない主張を述べている状態。明示的に提示する必要があります
synthesis	最終的な調査成果物です。単なる要約ではなく、分析を伴う証拠の新たな統合です
plan gate	トリアージ後、本格的な情報検索の前に作成する、簡潔で確認可能な調査計画です
source-support audit	引用した各情報源が、対応する主張を実際に裏付けているかを文単位で確認することです
support matrix	各主張と引用した各情報源との対応を示す表です。supports、partial、contradicts、irrelevant で分類します
citation anchor	情報源と主張を結び付けるために使用した、具体的な抜粋、セクション、またはデータ行です
support status	主張と情報源の組み合わせごとの分類です。supports、partial、contradicts、irrelevant のいずれかです
effort budget	想定するワーカー数、情報源の数、調査の深さ、停止条件を定めた、上限付きの検索・委任計画です
journal	調査セッションの保存済み Markdown 記録です。`~/.{gemini
sweep	第 1 波です。複数のツールと情報源を使って広範囲に並行検索します
deep dive	第 2 波です。スイープで見つかった具体的な手掛かりを対象に、追加調査を行います
lead	スイープ中に見つかった、有望で詳しく調査する価値のある情報源または調査の糸口です
tier	複雑さの分類です。Quick（0～2）、Standard（3～5）、Deep（6～8）、Exhaustive（9～10）です
finding	証拠の連鎖、信頼度スコア、プロヴェナンスを伴う検証済みの主張です。出力の最小単位です
gap	証拠が不十分、矛盾している、または存在しないと特定された領域です
bias marker	最新性、権威性、LLM の事前知識など、潜在的なバイアスを示すために調査結果に付ける明示的なフラグです
degraded mode	調査ツールが利用できない場合の動作です。信頼度の上限が適用されます
capability	ウェブ検索、ドキュメント検索、抽出、サブエージェントへの委任などの調査能力です。ツール名は推奨される実装を示しますが、利用が保証されるわけではありません

ディスパッチ

$ARGUMENTS	アクション
質問またはトピックのテキスト（動詞または ? を含む）	調査 — 複雑さを分類し、ウェーブパイプラインを実行します
曖昧な入力（5語未満、動詞なし、? なし）	インテーク — 確認の質問を2～3個尋ねてから、分類します
check <claim> または verify <claim>	ファクトチェック — 3つ以上の検索エンジンで主張を検証します
compare <A> vs <B> [vs <C>...]	比較 — 意思決定マトリクスを出力する構造化比較を行います
survey <field or topic>	調査 — 分野の全体像を整理し、注釈付き参考文献を作成します
track <topic>	追跡 — 過去のジャーナルを読み込み、前回のセッション以降の更新を検索します
resume [number or keyword]	再開 — 保存済みの調査セッションを再開します
list [active, domain, tier]	一覧 — ジャーナルのメタデータ表を表示します
archive	アーカイブ — 90日を超えたジャーナルを移動します
delete <N>	削除 — 確認後、ジャーナルNを削除します
export [N]	エクスポート — ジャーナルNのHTMLダッシュボードを生成します（デフォルト：現在のジャーナル）
空	ギャラリー — トピックの例と「何でも質問してください」というプロンプトを表示します

自動検出のヒューリスティック

モードキーワードに一致しない場合：

1. ? で終わる、または疑問詞（who／what／when／where／why／how／is／are／can／does／should／will）で始まる → 調査
2. 名詞句の間に vs、versus、compared to、or を含む → 比較
3. 疑問文の形式を含まず、事実に関する主張を述べる文 → ファクトチェック
4. 具体的な質問を伴わない広範な分野名 → 「特定の質問を調査しますか、それとも分野全体を調査しますか？」と尋ねます
5. 曖昧な場合 → 「この質問を調査しますか、主張を検証しますか、それとも分野を調査しますか？」と尋ねます

プランゲート

標準、ディープ、網羅的な調査では、本格的な情報検索の前にトリアージパケットを作成します。

1. 調査の質問、対象読者、前提、制約、および重大なリスクや非公開ソースのリスクを言い換えて示します。
2. 複雑さのスコア、ティア、モード、ソースの難易度、検証の複雑さ、作業量の予算を示します。
3. サブクエスチョン、ソースの種類、予定するワーカーのレーン、検索／抽出機能、および縮退モードでの制限を列挙します。
4. 引用アンカーと裏付けステータスの確認方法を含め、ソース裏付けの監査戦略を示します。
5. 実行をただちに続行するか、ユーザーの確認のために一時停止するかを明示します。

一時停止条件は続行条件より優先されます。トピックが重大な影響を伴う場合、トリアージ後も曖昧な場合、非公開または認証が必要なソースを求めている場合、あるいはユーザーが明示的にプランの確認を求めている場合は、ユーザーの入力を求めて一時停止します。ユーザーにとって重要なスコープや対象読者が不明なために一時停止する場合は、instructions/global.md の深さルーティングを適用し、本格的な情報検索の前に /grill-me を実行します。事実や証拠の不足はリサーチのプランゲートで扱い、grill-me に回さないでください。非対話型ハーネスでは、該当する一時停止ケースについて、阻害要因とともにプランゲートを出力し、本格的な情報検索の前に停止します。質問が明確で、機微な内容を含まず、一時停止条件がない場合に限り、待機せずに続行します。クイックティアでは正式なゲートを省略してもかまいませんが、回答には短い方法論の注記を含めてください。

ギャラリー（引数なし）

幅広い分野の調査例を示します。

#	分野	例	想定ティア
1	テクノロジー	「LLM エージェントアーキテクチャにおける現在のベストプラクティスは何ですか？」	ディープ
2	学術	「長寿に対する断続的断食の有効性を示す証拠は、現在どのような状況ですか？」	標準
3	市場	「ベクトルデータベースの競争環境は、どのように比較できますか？」	ディープ
4	ファクトチェック	「スタートアップの90％が初年度に失敗するというのは本当ですか？」	標準
5	アーキテクチャ	「CRUD よりイベントソーシングを選ぶべきなのは、どのような場合ですか？」	標準
6	トレンド	「2025～2026年に注目を集めた、新興のプログラミング言語は何ですか？」	標準

番号を選ぶか、自分の質問を貼り付けるか、guide me と入力してください。

スキルの適合性

調査を始める前に、ほかのスキルのほうが適していないか確認してください。

手がかり	転送先
コードレビュー、PR レビュー、差分分析	/review を提案
敵対者やゲーム理論を伴う戦略的な意思決定	/wargame を提案
複数の視点からの専門家による議論	/host-panel を提案
プロンプトの最適化、モデル固有のプロンプト作成	/prompt-engineer を提案

ユーザーが一般的な調査を希望すると確認できたら、続行してください。

リポジトリが所有する CLI スキルを優先するルーティング（/ffmpeg、/yt-dlp、/trafilatura、/pentest）については、references/source-selection.md の Repo CLI skills テーブルを参照してください。

複雑さの分類

クエリを5つの観点から採点してください（各0〜2点、合計0〜10点）。

観点	0	1	2
対象範囲の広さ	単一の事実・定義	複数の側面、2〜3分野	分野横断的、4分野以上
情報源の難易度	検索上位の結果で十分	専門データベースまたは複数の情報源タイプが必要	有料、断片的、または情報源同士に矛盾がある
時間的な変化の大きさ	安定している・歴史的	発展中の分野（月単位で変化がある）	変化が速い（日・週単位で変化がある）、議論が活発
検証の複雑さ	簡単に検証できる（公式ドキュメント）	独立した情報源が2〜3件必要	主張に争いがある、専門家の意見が異なる、合意がない
統合の必要性	回答が事実または一覧	見解の比較・対照	相反する論点を新たに統合する必要がある

合計	ティア	戦略
0-2	Quick	インラインで回答、検索1〜2回、検索後すぐに完了
3-5	Standard	サブエージェントのウェーブ、並行検索担当者3〜5人、レポートを作成
6-8	Deep	エージェントチーム（TeamCreate）、チームメンバー3〜5人、対話形式のセッション
9-10	Exhaustive	エージェントチーム、チームメンバー4〜6人＋ネストしたサブエージェントのウェーブ、対話形式

Standard、Deep、Exhaustive の作業では、Plan Gate を通じて採点結果を提示してください。ユーザーは --depth <tier> でティアを上書きできます。

作業規模の調整

クエリの複雑さと利用可能なオーケストレーション機能に応じて、作業規模を調整してください。

範囲	戦略	委任
Quick (0-2)	検索1〜2回の後、インラインで回答	サブエージェントなし
Standard (3-5)	2〜5個のサブクエリを並行して幅広く調査	利用可能なサブエージェント機能を使用し、なければ順次まとめて実行
Deep (6-8)	視点を広げる、リーダー主導のチームワークフロー	利用可能なチーム／サブエージェント機能を使用し、なければ範囲を限定した逐次ウェーブで実行
Exhaustive (9-10)	敵対的な検討とネストしたウェーブを加えた詳細なワークフロー	利用可能ならネストした委任を使用し、なければ処理能力が低下することを明示

機能の解決： 名前付きツールとオーケストレーション API を優先機能として扱います。Claude Code では Task／TeamCreate、Codex では動的サブエージェントまたは並列ツール呼び出しを使用できます。ほかのエージェントでは、各エージェント固有の委任機能を使うか、ウェーブのパイプラインを逐次実行できます。委任に相当する機能がない場合は、機能を縮退させたオーケストレーションを使用してください。ウェーブの順序を維持し、調査範囲を狭め、方法論の中で制約を報告してください。信頼度の上限を適用するのは、references/source-selection.md に従い、情報源または情報取得機能が利用できない場合に限ります。

作業量の予算設定： Standard 以上の実行では、情報取得を始める前に作業量を制限してください。目標とする作業者数、想定する情報源の数、検索の深さ、抽出の深さ、終了条件を示します。まず広く調査し、その後に絞り込んでください。ウェーブ1では情報源と視点を最大限に網羅します。ウェーブ2では価値の高い手がかりだけを深掘りします。ウェーブ3では、統合後も残る可能性が高い主張に検証の予算を割り当てます。

ウェーブのパイプライン

Quick 以外の調査はすべて、この5ウェーブのパイプラインに従います。Quick ではウェーブ0、1、4をインラインで統合します。

ウェーブ 0：トリアージ（常にインラインで実行し、並列化しない）

1. 決定論的な事前スキャンを行うため、!uv run python scripts/research-scanner.py "$ARGUMENTS" を実行します
2. クエリを 2～5 個のサブ質問に分解します
3. 5 つのディメンションからなる評価基準で複雑さを採点します
4. ツールの利用可否を確認します — 主要な検索、抽出、委任機能を調査し、references/source-selection.md に従って縮退モードのフラグと信頼度の上限を設定します
5. ドメインのシグナルに応じてツールを選択します — references/source-selection.md を読みます
6. 既存のジャーナルを確認します — track または resume の場合は、以前の状態を読み込みます
7. プランゲートを実行します — 複雑さのスコア、サブ質問、ソース群、ワーカーレーン、裏付け監査の方針、作業量の予算、推定ティア、実行を直ちに続けるか一時停止するかを提示します。ユーザーは変更を指示できます。

ウェーブ 1：広範な調査（並列）

ティアに応じて規模を調整します。

クイック（インライン）： ツール呼び出しを 1～2 回、順次実行します。サブエージェントは使用しません。

標準（サブエージェントのウェーブ）： プラットフォームで利用可能な委任プリミティブを使って、3～5 個のサブエージェントを並列で起動します。

Subagent A → brave-search + duckduckgo-search for sub-question 1
Subagent B → exa + g-search for sub-question 2
Subagent C → context7 / deepwiki / arxiv / semantic-scholar for technical specifics
Subagent D → wikipedia / wikidata for factual grounding
[Subagent E → PubMed / openalex if academic domain detected]

ディープ（エージェントチーム）： プラットフォームで利用可能なチームプリミティブを使って、調査チームを作成します。

Lead: triage (Wave 0), orchestrate, judge reconcile (Wave 3), synthesize (Wave 4)
  |-- web-researcher:       brave-search, duckduckgo-search, ddgs, exa, g-search
  |-- tech-researcher:      context7, deepwiki, arxiv, semantic-scholar, package-version-check-mcp
  |-- content-extractor:    fetcher, trafilatura, docling, wikipedia, wayback
  |-- [academic-researcher: arxiv, semantic-scholar, openalex, crossref, PubMed]
  |-- [adversarial-reviewer: devil's advocate — counter-search all emerging findings]

ドメインのシグナルに学術的・科学的な要素が含まれる場合は academic-researcher を起動します。網羅的ティアの場合、または検証の複雑さが 2 以上の場合は adversarial-reviewer を起動します。

網羅的： ディープチームを編成し、対応している場合は各チームメンバーが内部でネストされたサブエージェントのウェーブを実行します。対応していない場合は、逐次バッチを使用し、実行に「オーケストレーション縮退」とラベルを付けます。

各サブエージェント／チームメンバーは、構造化された調査結果を返します。

{
  "sub_question": "...",
  "findings": [{
    "claim": "...",
    "confidence": 0.6,
    "evidence": [{"tool": "brave-search", "url": "https://...", "timestamp": "2026-04-24T12:00:00Z", "excerpt": "..."}],
    "cross_validation": "unknown",
    "source_support": [{"url": "https://...", "support_status": "supports|partial|contradicts|irrelevant", "citation_anchor": "...", "support_note": "..."}],
    "bias_markers": [],
    "gaps": []
  }],
  "leads": ["url1", "url2"],
  "gaps": ["could not find data on X"]
}

ウェーブ 1.5：視点の拡張（ディープ／網羅的のみ）

STORM 形式の視点誘導型対話です。視点サブエージェントを 2～4 個起動します。

視点	焦点	質問のスタイル
懐疑論者	何が間違っている可能性がありますか？何が欠けていますか？	「これを反証する証拠は何ですか？」
ドメイン専門家	技術的な深さ、ニュアンス、エッジケース	「実務者は実際にどのようなことに遭遇しますか？」
実践者	実社会での適用可能性、トレードオフ	「実際にこれを構築するとき、何が重要ですか？」
理論家	第一原理、抽象化、フレームワーク	「これを説明する根本的なモデルは何ですか？」

各視点エージェントはウェーブ 1 の調査結果を確認し、それぞれの観点から追加のサブ質問を 2～3 個生成します。これらのサブ質問はウェーブ 2 に引き継がれます。

ウェーブ 2：詳細調査（並列、対象を絞って実施）

1. ウェーブ 1 の手掛かりを、潜在的な価値（引用頻度、ソースの権威性、関連性）に基づいて順位付けします
2. 詳細読解用のサブエージェントを起動します — シェルハーネスでは /trafilatura を優先し、それ以外では fetcher／trafilatura MCP／docling を使って、有力な手掛かりからコンテンツ全体を抽出します
3. 引用をたどります — あるソースが別のソースを引用している場合は、元のソースを取得します
4. 不足を補います — ウェーブ 1 で特定した各不足項目について、対象を絞った検索を実施します
5. ソースに裏付けられた各調査結果について、主張とソースの対応を示す予備的な裏付け行を作成します
6. 思考 MCP を使用します。
   • 複雑な調査結果を複数の視点から分析するには cascade-thinking を使用します
   • 証拠の連鎖と矛盾を追跡するには structured-thinking を使用します
   • 複雑な質問を分解するには think-strategies を使用します（標準以上のみ）

Wave 3：相互検証と出典サポートの監査（並行）

ハルシネーション対策のウェーブです。references/evidence-chain.md、references/confidence-rubric.md、references/self-verification.mdを読みます。

Wave 1～2を通過したすべての主張について、次を実施します。

1. 独立性の確認 — 根拠となる出典は本当に独立していますか？互いを引用している出典は独立していません。
2. 反証検索 — 別の検索エンジンを使い、主要な主張ごとに反対の証拠を明示的に検索します。
3. 鮮度の確認 — 出典が最新であることを確認します（時事性の高いトピックでは、1年を超える出典にフラグを付けます）。
4. 矛盾のスキャン — references/contradiction-protocol.mdを読み、意見の相違を特定して分類します。
5. 出典サポートの監査 — 各主張と出典の組み合わせを、supports、partial、contradicts、irrelevantのいずれかに分類します。
6. 引用箇所の検証 — 可能であれば引用されたURLを取得し、引用箇所が広い意味でのトピックに触れているだけでなく、該当箇所が主張そのものを裏付けていることを確認します。
7. 信頼度のスコアリング — references/confidence-rubric.mdに従って0.0～1.0のスコアを割り当て、裏付けが不十分、単一出典、矛盾あり、または劣化している場合は信頼度の上限を適用します。
8. バイアスの点検 — references/bias-detection.mdに従い、10のバイアスカテゴリ（中核の7つとLLM固有の3つ）について各調査結果を確認します。

自己検証（調査結果が3件以上残った場合）： references/self-verification.mdに従い、悪魔の代弁者となるサブエージェントを起動します。

各調査結果について、反証を試みます。反論を検索します。証拠が古くなっていないか確認します。主張が引用された証拠から実際に導かれるか検証します。LLMによる作り話があればフラグを付けます。

信頼度を調整します：検証を通過した場合は+0.05、弱まった場合は-0.10、反証された場合は0.0に設定します。 調整には厳格な上限が適用されます。単一出典の主張は、検証を通過した後も上限が0.60です。

Wave 4：統合（常にインラインで、リード担当のみ）

最終的な調査成果物を作成します。テンプレートについてはreferences/output-formats.mdを読みます。

統合は要約ではありません。次の要件を満たす必要があります。

1. 明確に回答する — ユーザーの質問に明確に答えます。
2. 証拠を対応付ける — 信頼度と引用を添えて、検証済みの調査結果をすべて示します。
3. 出典の裏付けを示す — 引用箇所の検証状況、および裏付けのない、または部分的にしか裏付けられていない記述を要約します。
4. 矛盾を明らかにする — 出典間で意見が異なる場合、その理由を分析します。
5. 信頼度の全体像を示す — 確信を持って分かっていること、不確かなこと、分かっていないことを示します。
6. バイアスを監査する — 調査中に検出されたバイアスを示します。
7. 不足点を特定する — 不足している証拠と、今後の調査に役立つ内容を示します。
8. 要点を整理する — 重要な調査結果を3～7項目の番号付きリストにまとめます。
9. 出典を引用する — 来歴情報を含む完全な参考文献一覧を記載します。

出力形式はモードに応じて変わります。

• Investigate → Research Brief（Standard）または Deep Report（Deep/Exhaustive）
• Fact-check → 判定と証拠を含む Quick Answer
• Compare → Decision Matrix
• Survey → 注釈付き参考文献一覧
• ユーザーは--format brief|deep|bib|matrixで上書きできます。
• 数値、比較、時間的推移、または出典の網羅状況に関する証拠を明確にできる場合に限り、チャート、マトリックス、またはダッシュボードの成果物を追加します。

信頼度のスコアリング

スコア	根拠
0.9-1.0	公式ドキュメントと独立した2件以上の出典が一致し、矛盾がない
0.7-0.8	独立した2件以上の出典が一致し、軽微な留保事項がある
0.5-0.6	権威ある単一出典、または部分的に一致する2件の出典
0.3-0.4	権威のない単一出典、または証拠が相互に矛盾している
0.2-0.3	権威のない複数の出典が部分的に一致する、または重大な留保事項がある単一出典
0.1-0.2	LLMの推論のみで、外部の証拠が見つからない
0.0	証拠によって明確に反証されている

厳格なルール：

• 独立した2件以上の出典による裏付けがない限り、信頼度が0.7以上の主張を報告しません。
• 単一出典の主張は、出典の権威性にかかわらず、信頼度の上限を0.6とします。
• 劣化モード（すべての調査ツールが利用不可）：信頼度の上限は0.4とし、すべての調査結果に「未検証」とラベルを付けます。

統合信頼度（複数の出典が裏付ける主張の場合）： c_merged = 1 - (1-c1)(1-c2)...(1-cN)。上限は0.99です。

エビデンスチェーンの構造

すべての調査結果には、次の構造が含まれます。

FINDING RR-{seq:03d}: [claim statement]
  CONFIDENCE: [0.0-1.0]
  EVIDENCE:
    1. [source_tool] [url] [access_timestamp] — [relevant excerpt, max 100 words]
    2. [source_tool] [url] [access_timestamp] — [relevant excerpt, max 100 words]
  CROSS-VALIDATION: [agrees|contradicts|partial] across [N] independent sources
  SOURCE SUPPORT SUMMARY: [verified|partial|unsupported|contradicted] derived from per-source `support_status` rows
  BIAS MARKERS: [none | list of detected biases with category]
  GAPS: [none | what additional evidence would strengthen this finding]

!uv run python scripts/finding-formatter.py --format markdown を使用して正規化します。

ソースの選定

Wave 0 で references/source-selection.md を読み、ツールとドメインの対応関係を確認してください。概要は次のとおりです。

ドメインのシグナル	主なツール	副次的なツール
ライブラリ／API ドキュメント	llms.txt/llms-full.txt、context7、deepwiki、package-version-check-mcp	brave-search
学術／科学	arxiv、semantic-scholar、PubMed、openalex	crossref、brave-search
時事／トレンド	brave-search、exa、duckduckgo-search、ddgs、g-search	fetcher、trafilatura
GitHub リポジトリ／OSS	deepwiki、repomix	brave-search
一般知識	wikipedia、wikidata、brave-search	fetcher
歴史的コンテンツ	wayback、brave-search	fetcher
ファクトチェック	利用可能な場合は 3 つ以上の検索エンジンが必須	構造化された主張には wikidata
PDF／文書の分析	docling	trafilatura

複数エンジンのプロトコル： 検証が必要な主張については、異なる検索エンジンまたは独立したソース群を最低 2 つ使用してください。ファクトチェックモードでは、利用可能な場合、3 つ以上の検索エンジンが必要です。利用できる検索エンジンがそれより少ない場合は、機能が低下したモードであることを報告し、references/source-selection.md に記載された代替時の信頼度上限を適用して、不足している情報検索機能を説明してください。

段階的な開示

次に必要なリファレンスのみを読み込みます。

1. ルーティング、分類、Wave の順序を確認するため、このファイルから開始します。
2. Wave 0 でのみ references/source-selection.md を読み込みます。
3. 検証用リファレンスは Wave 3 でのみ読み込みます。必要に応じて、エビデンスチェーン、信頼度、矛盾、自己検証、バイアスに関するファイルを確認します。
4. 最終出力またはエクスポートを作成する場合にのみ、references/output-formats.md または references/dashboard-schema.md を読み込みます。
5. すべてのリファレンスをあらかじめ読み込まないでください。使用しない対応関係でコンテキストを埋めるのではなく、ツールの制約を要約してください。

バイアスの検出

10 種類のバイアスカテゴリすべてについて、各調査結果を確認してください。検出シグナルと軽減策の詳細は references/bias-detection.md を読んでください。

バイアス	検出シグナル	軽減策
LLM の事前知識	一般的な学習パターンと一致し、新しいエビデンスがない	フラグを立て、新しいソースでの確認を求める
最新性	最近の結果を過度に重視し、歴史的背景を無視する	歴史的な視点を検索する
権威性	権威あるソースを批判せずに受け入れる	権威ある主張も相互検証する
確証	最初の仮説を裏付けるようにクエリを組み立てる	中立的なクエリを使い、反論を検索する
生存者	成功例のみを見つける	失敗例や反例を検索する
選択	検索エンジンの偏り、英語のみの検索	複数の検索エンジンを使用し、網羅性の制約を記載する
アンカリング	最初のソースが解釈に不釣り合いな影響を与える	最初のソースを個別に記録し、対照となる情報を探す

状態管理

• ジャーナルのパス： ~/.{gemini|copilot|codex|claude}/research/
• アーカイブのパス： ~/.{gemini|copilot|codex|claude}/research/archive/
• ファイル名の規則： {YYYY-MM-DD}-{domain}-{slug}.md
  • {domain}：tech、academic、market、policy、factcheck、compare、survey、track、general
  • {slug}：意味を表す3～5語の要約、ケバブケース
  • 名前が重複する場合：-v2、-v3を追加
• 形式： YAMLフロントマター＋Markdown本文＋``ブロック

保存プロトコル：

• クイック：最後に一度だけ保存し、status: Completeにします
• 標準／詳細／徹底：Wave 1の後にstatus: In Progressで保存し、各Waveの後に更新して、統合後に完了状態にします

再開プロトコル：

1. resume（引数なし）：status: In Progressのジャーナルを検索します。1件の場合は自動で再開し、複数の場合は一覧を表示します。
2. resume N：listの出力（新しい順）でN番目のジャーナルを再開します。
3. resume keyword：フロントマターのqueryとdomain_tagsを検索し、一致するものを探します。

すべてのジャーナル操作には!uv run python scripts/journal-store.pyを使用してください。

状態スナップショット（各Waveの保存後に追加）：

セッション中のコマンド（詳細／徹底）

アクティブな調査セッション中に使用できます。

コマンド	効果
drill <finding #>	特定の調査結果を、さらに多くの情報源を使って深掘りします
pivot <new angle>	調査を新たな副次的な問いへと方向転換します
counter <finding #>	調査結果に反する証拠を明示的に検索します
export	HTML ダッシュボードを生成します
status	進行せずに現在の調査状態を表示します
sources	これまでに参照したすべての情報源を一覧表示します
confidence	調査結果全体の確信度の分布を表示します
gaps	特定された知識のギャップを一覧表示します
?	コマンドメニューを表示します

プロトコルの詳細については、references/session-commands.mdを参照してください。

参照ファイル一覧

ファイル	内容	読み込むタイミング
references/source-selection.md	ツールとドメインの対応付け、マルチエンジンプロトコル、縮退モード	Wave 0（ツールの選択時）
references/confidence-rubric.md	評価基準、相互検証ルール、独立性の確認	Wave 3（確信度の割り当て時）
references/evidence-chain.md	調査結果のテンプレート、来歴の形式、引用の基準	任意のWave（証拠の構成時）
references/bias-detection.md	10種類のバイアスカテゴリ（中核7種類＋LLM固有3種類）、検出シグナル、緩和策	Wave 3（バイアス監査時）
references/contradiction-protocol.md	4種類の矛盾、解決の枠組み	Wave 3（矛盾の検出時）
references/self-verification.md	悪魔の代弁者プロトコル、ハルシネーションの検出	Wave 3（自己検証時）
references/output-formats.md	5種類すべての出力形式のテンプレート	Wave 4（出力の書式設定時）
references/team-templates.md	チームの類型、サブエージェントのプロンプト、視点エージェント	Wave 0（チームの設計時）
references/session-commands.md	セッション中のコマンドプロトコル	ユーザーがセッション中のコマンドを発行したとき
references/dashboard-schema.md	HTML ダッシュボード用のJSONデータ契約	exportコマンド

読み込みルール：「読み込むタイミング」列に従い、一度に参照ファイルを1つだけ読み込んでください。事前に読み込まないでください。

停止フック

ランタイムフックが有効な場合、調査モードの停止検証は必須です。research_hook.py research-stop-verifierはverify.py stopに処理を委譲し、セッション中にskills/research/配下の追跡対象ファイルがGit上で変更されていないことを確認します。ソースファイルへの書き込みは、別途research-readonly-write-guardによってブロックされます。停止検証に失敗した場合は、正確な理由を報告し、実行が完了したと述べないでください。

検証契約

変更を完了と宣言する前に、リポジトリのルートから実行してください。

(cd skills/research && uv run python scripts/check.py)
uv run pytest tests/test_wagents_hook.py -q -k "readonly_guard or stop_verifier or shell_write_guard"

完了条件：

1. scripts/check.py の実行後、現在のチェックアウトで利用可能なスキル検証、評価検証、パッケージのドライラン、リポジトリ監査の各チェックが成功し、終了コード 0 が返されること。
2. 同梱のバリデーターが、スキルのメタデータと評価マニフェストが有効であると報告すること。
3. 同梱のパッケージ作成ドライランが portable: true と報告すること。
4. 読み取り専用ガードと停止検証の動作に関するリサーチフックのスモークテストが成功すること。
5. ポータブルパッケージのチェックで、絶対パスやリポジトリのコントロールプレーン CLI 要件が引き続き含まれないこと。

重要なルール

1. 独立した情報源が 2 つ以上ない限り、信頼度 0.7 以上の主張をしないこと — 情報源が 1 つしかない主張の信頼度は最大 0.6 とする
2. 引用を捏造しないこと — URL、著者、タイトル、日付を検証できない場合、具体的な情報を作り上げず、「この分野のある研究」のように曖昧な帰属表現を使うこと
3. 矛盾は必ず明示すること — 意見の相違を黙って解消せず、根拠とともに両方の見解を示すこと
4. 本格的なリサーチの前に必ずトリアージのスコアリングを行うこと — ユーザーが複雑度の区分を確認して上書きできるようにすること。Plan Gate で承認または確認が必要とされている場合に限り、そこで待機すること
5. Deep／Exhaustive モードでは、各ウェーブの後に必ずジャーナルを保存すること — 中断後に再開できるようにするため
6. Standard／Deep／Exhaustive の各区分では、Wave 3（相互検証と情報源の裏付け監査）を絶対に省略しないこと — これがハルシネーションを防ぐ仕組みです
7. 利用可能な場合、ファクトチェックでは複数の検索エンジンを必ず使用すること — 異なる検索ツールを最低 3 つ使用すること（例：brave-search、duckduckgo-search、exa）。利用できるツールが 3 つ未満の場合は縮退モードに入り、信頼度の上限を下げること
8. 並列ディスパッチの後は必ず会計ルールを適用すること — 次のウェーブに進む前に、ディスパッチ数 N と処理済み数 N が一致していること
9. すべての出力で、事実と解釈を区別すること — 事実に関する主張には根拠を付け、解釈に関する主張には「分析」と明示すること
10. LLM の事前知識に基づく調査結果にはすべてフラグを付けること — 一般的な学習データに含まれる内容と一致するものの、新たな根拠がない主張にはバイアスマーカーを付けること
11. 縮退モードでの信頼度の上限は 0.4 とすること — すべてのリサーチツールが利用できない場合、調査結果はすべて「未検証 — 学習済み知識に基づく」と報告すること
12. 参照ファイルは一度に 1 つだけ読み込むこと — すべての参照ファイルをコンテキストに事前読み込みしないこと
13. Track モードでは、検索前に以前のジャーナルを読み込むこと — 既知の情報を再調査しないため
14. 統合は要約ではない — 調査結果を統合して新たな分析を行い、情報源を横断するパターンを特定し、単一の情報源にはない新たな知見を明らかにすること
15. PreToolUse の書き込みガードは必須 — research_hook.py research-readonly-write-guard がソースファイルへの書き込みをブロックすること。ジャーナルは ~/.{gemini|copilot|codex|claude}/research/ に保存すること
16. 停止フックは必ず成功させること — research_hook.py research-stop-verifier が verify.py stop に処理を委譲し、追跡対象の skills/research/ ファイルが git-clean の状態を維持していることを確認すること
17. 統合の前に、従来形式の調査結果を正規化すること — トップレベルの source_url、source_tool、confidence_raw を、正規形式の evidence[] と confidence に変換すること
18. 引用自体は証拠にならない — 引用した情報源の本文が、主張の内容を正確に裏付けている必要があります。裏付けのない引用や、単に話題が関連しているだけの引用は信頼度を下げ、情報源の裏付け監査に記載すること