research-online

GG → Research Online → Web Research

信頼度の高い回答をする前に、リリースに左右される内容をライブソースで検証してください。

クイックスタート

このスキルで使うツール名： web_search と web_fetch は、現在のハーネスで公開されている検索ツールとページ取得ツール（組み込み、MCP、CLI など）の名称を指します。名称はさまざまです（web_search／web_fetch、WebSearch／WebFetch、open_page、ブラウザーによる取得など）。今利用できるものを使ってください。Firecrawl やその他の特定ベンダーを必須にしないでください。

**検索を始める前に、Research Planning にある3つの計画に関する質問に答えてください。**その後、次の5つの手順に従います。

1. 発見する — ホストの web_search で、具体的かつ曖昧さのないクエリを検索します。まずはタイトルとスニペットを確認し、すべての検索結果を読む必要はありません。検索結果からさらに具体的な疑問が見つかった場合は、追加検索を行います（Research Methodology → Research Chaining を参照）。
2. 詳しく読む — ホストの web_fetch で、最も関連性の高いURLを1～2件だけ取得します。コンテンツのクリーニングはデフォルトで有効です。
3. 評価する — 5つのシグナルに基づくヒューリスティックを使って、各ソースを評価します（公式ドキュメント > GitHub リポジトリ > フォーラム／ブログ）。references/source-evaluation.md を参照してください。
4. 統合する — 調査結果を最初に示し、すべての主張に出典を明記します。優先順位（公式 > コミュニティ、最新 > 古い、一次 > 二次、合意 > 異論、検証可能 > 検証不可能）に従って矛盾を解消し、ギャップは明示してください。回答を提示する前に、Research Quality Checklist に照らして確認します。
5. 保存する — 成果物には save-web-research.ts を、重複を整理した要約には consolidate-research.ts --auto-session を使います。コンテンツのクリーニングはデフォルトで有効です。

2～3回クエリを言い換えても検索結果が不十分な場合は、Research Dead End Protocol に従ってください（失敗を分類し、ツールではなく戦略を切り替え、ギャップを記録し、推測で補うのではなくエスカレーションします）。

調査を終了するのに十分な証拠がそろったかどうかは、Research Methodology > Research Sufficiency を参照してください。

ホストの検索／取得ツールを使うのがデフォルトの方法です。ホストの取得ツールでは対応できない場合に限り、専用バックエンド（Firecrawl CLI の map／crawl／schema／browser、または利用可能な同等ツール）を任意で使えます。以下の Hybrid Two-Phase Research Pattern を参照してください。

Research Planning

最初の検索を始める前に、次の3点を明確にしてください。計画に30秒かけるだけで、30分の的外れな検索を防げます。

1. 何が必要か。 調査の質問を1文で書きます。書けない場合はクエリが広すぎるため、書けるまで範囲を絞ってください。
2. すでに分かっていること。 確信のある事実と、それを把握したバージョンまたは日付を列挙します。これにより、すでに得ている情報を再調査せずに済みます。
3. 十分と判断する基準。 Research Sufficiency のどの終了基準が当てはまりますか？（権威あるソース1件？内容の一致するソース2件？バージョンを明示した回答？）検索を始める前に目標を定め、いつ終了すべきか分かるようにします。

#1に答えられない場合は、Research Dead End Protocol に従ってください。クエリを言い換え、戦略を切り替え、ギャップを記録します。役立つ情報が見つかることを期待して、曖昧な検索を始めないでください。

概要

このスキルを使ってオンライン調査を行い、出典に裏付けられた回答を再現可能な成果物とともに提示します。

**ツールの選択ではベンダーの優先度ではなく、実用性に基づく判断フローを使います。**今すぐ実行できるホストの検索ツールと取得ツールを使ってください。専用バックエンド（Firecrawl CLI または同等ツール）は任意の追加手段であり、必須ではありません。

ツール選択の判断フロー

1. Is a host web search or page-fetch tool available?
   → YES: Use it (default path). Continue only if the task still needs more.
   → NO: Stop and report that no web search/fetch is available. Do not wait for a specialized backend.

2. Does the task need site mapping, multi-page crawl, schema extraction, or JS browser automation that host fetch cannot do?
   → NO: Stay on host search/fetch. Save artifacts. Done.
   → YES: continue

3. Is a specialized backend (Firecrawl CLI or equivalent) already available?
   → YES: Use it for those advanced steps only.
   → NO: Complete with host tools; note the capability gap in the synthesis. Do not install or authenticate a backend mid-research.

4. Need reproducible artifacts?
   → Always save via save-web-research.ts / session scripts. Firecrawl output dirs are only for Firecrawl runs.

**重要な原則：**最適なツールとは、利用可能で、目的に十分なツールです。ホストの検索／取得ツールで質問に答えられる場合、Firecrawl（またはその他のバックエンド）の利用を待って調査を止めないでください。

ハイブリッドな二段階リサーチパターン

幅と深さの両方が重要なマルチソースリサーチでは、ツールを2つの段階で組み合わせます。

フェーズ 1 — 発見（デフォルトのホスト検索／取得）：

1. ホストの web_search を使い、リサーチクエリで関連する URL を見つけます。
2. 検索結果のタイトルとスニペットを確認し、特に有望なソースを2～5件特定します。
3. すぐに詳しく読むため、ホストの web_fetch は最も有望な URL のうち1～2件だけに使います。すべての検索結果を取得しないでください。選択して取得すると、コンテキストのノイズが減り、統合の質が高まります。
4. 回答に十分な情報があれば、統合した内容を提示します。専用のバックエンドは不要です。

フェーズ 2 — 詳細な抽出（任意の専用バックエンド）： 5. ホストの取得機能ではクリーンな抽出、構造化 JSON、サイトマップ、またはクロールを実行できず、かつ Firecrawl CLI などのバックエンドがすでに利用可能な場合に限ります。

firecrawl scrape "<url>" --only-main-content --format markdown

6. マッピングが必要な複数ページのサイトの場合（ホストの取得機能には同等の機能がありません）：

   firecrawl map "<site-root>" --search "<topic>"
   

7. フェーズ 2 の出力はすべて .researches/<timestamp>/ セッションフォルダーに保存します。

フェーズ 2 を省略する場合：

• フェーズ 1 で十分な回答が得られた場合。
• 専用のバックエンドがインストールされていない、または認証されていない場合。
• マッピング、クロール、スキーマ抽出、または二重表現でのアーカイブが不要な場合。

フェーズ 2 が役立つ場合（バックエンドがすでに利用可能な場合に限ります）：

• 構造化 JSON の抽出が必要な場合（firecrawl agent --schema または同等の機能）。
• サイト全体のマッピングまたはクロールが必要な場合。
• ホストの取得機能では作成できない、二重表現でのアーカイブが必要な場合。

このパターンでは、常に利用可能なホストツールを発見に使い、専用バックエンドの利用は、そのバックエンドでしか実行できない抽出タスクに限ります。

検索してから選択的に取得する（重要な効率化パターン）

web_search は、各結果のページ全文を含む5件の検索結果を返すため、テキストが数千トークンに及ぶことがあります。すべての結果を全文処理すると、コンテキストを無駄にし、無関係なページのノイズが増えます。

効率的なワークフロー：

1. 全文を読むのではなく、ざっと確認します。 web_search が検索結果を返したら、レスポンスに含まれるタイトル、URL、スニペットのテキストだけを読みます。全文をコンテキストに読み込まないでください。
2. 最も関連性の高い結果を1～2件選びます。 タイトルの関連性、ドメインの信頼性、スニペットの質に基づいて、質問への回答につながる可能性が最も高い URL を選びます。
3. 選択した結果だけを詳しく読みます。 その1～2件だけに web_fetch を使います。最初の結果で質問に答えられる場合は、そこで終了します。追加の取得は不要です。
4. 発見した検索結果を保存します。 詳しく読むのが一部の結果だけの場合でも、再現性を確保するために save-web-research.ts を使って検索結果全体を保存します。

アンチパターン：

❌ web_search → read all 5 full results → try to synthesize from 5 noisy pages
✅ web_search → scan titles + snippets → select 1-2 best → web_fetch → synthesize

さらに取得する場合： 上位2件で質問に答えられない場合は、検索結果の3～5件目まで対象を広げます。どの結果でも回答が得られない場合は、検索クエリを調整します。ホストの取得機能だけでは不十分で、かつ専用のバックエンドがすでに利用可能な場合に限り、フェーズ 2 に進みます。幅広い質問への回答は得られても、さらに具体的な質問が見つかった場合は、後続の検索を連鎖させます（リサーチ方法論 → リサーチの連鎖を参照）。クエリの種類に応じた終了基準については、リサーチ方法論 → リサーチの十分性を参照してください。

コマンドを直接調べる場合は、以下のクイックコマンドを参照してください。

専用バックエンドとの関係

research-online/SKILL.md は、ワークフローとアーカイブのレイヤーです。Firecrawl には依存しません。

• タイムスタンプ付きの .researches/<timestamp>/ ディレクトリを初期化し、利用可能なあらゆる検索／取得手段で複数ソースの根拠を収集し、調査結果を整理して、再現可能な成果物一式を公開するという、エンドツーエンドのリサーチセッションを実施するタスクでは、このスキルを使います。
• 同階層の firecrawl スキル（または別のマップ／クロール／スキーマ／ブラウザの入門ガイド）がインストールされており、かつバックエンドがすでに利用可能な場合は、コマンドレベルの構文を確認するために必要に応じて読み込みます。
• Firecrawl がなくても支障はありません。ホストの検索／取得機能で、デフォルトの手順を完結できます。

このスキルを使用するタイミング

次の場合に使用します：

• ユーザーが最新のウェブ情報、複数ソースの探索、またはサイトマッピングを求めている場合。
• ウェブページからの構造化された情報抽出や、自律的な調査が必要な場合。
• 複数のサイトにまたがるドキュメントの比較を伴う調査の場合。
• 最新のウェブソースに基づいて主張を検証する必要がある場合。
• 忠実なアーカイブが必要な GitHub リポジトリのドキュメントを扱う場合。

次の場合は使用しません：

• ローカルのコードベースまたはコミット済みのドキュメントから質問に回答できる場合。
• ユーザーが、事実に基づかない意見や創作を明示的に求めている場合。
• 特定のツール領域を単独で扱う関連の専門スキル（たとえば Firecrawl CLI の構文）がすでにある場合。このスキルは引き続き調査セッションを担当します。

よくある誤解

#	誤解	訂正	重要な概念
1	このスキルには Firecrawl（または他の特定ベンダー）が必要です	ホストの検索／取得機能がデフォルトです。専用バックエンドは、すでに利用可能な場合に限り、追加で使用できます。セットアップを待って調査を止めてはいけません。	実用的なツール選択
2	ドキュメント形式は1種類で十分です	ドキュメントの対象には、Markdown と HTML の両方を維持してください	2つの表現形式の契約
3	firecrawl browser の省略形は信頼できます	バージョンによって動作が異なり、不安定です。明示的なコマンドを優先してください	ブラウザーへのフォールバックの不安定さ
4	GitHub の blob ページの Markdown は整ったソーステキストです	GitHub のページ要素が含まれています。raw.githubusercontent.com またはローカルクローンを使用してください	ハイブリッドなアーカイブパターン
5	調査セッションを公開する必要はありません	ユーザーから指示がない限り、完了したセッションはデフォルトで公開してください	範囲を限定した成果物の公開
6	ホストのウェブツールは Firecrawl より劣っています	ホストの検索／取得機能がデフォルトの方法です。追加のセットアップは不要で、検索または取得機能を提供するあらゆるハーネスで動作します。専用バックエンドで追加されるのは、マッピング／クロール／スキーマ／ブラウザー機能のみです。	ツールの相補性
7	web_search の結果はすべて全文を読むべきです	まずタイトルとスニペットを確認し、最も関連性の高い URL を1～2件だけ web_fetch してください。すべての結果を全文読むと、コンテキストを無駄にし、ノイズが増えます。再現性を確保するため、すべての結果を保存するには save-web-research.ts を使用してください。	選択的な取得
8	検索クエリの質は重要ではありません。ツールが最良の結果を返すからです	クエリの作成は、調査において最も効果の高いスキルです。具体的で曖昧さのないクエリは、曖昧なクエリよりもはるかに関連性の高い結果を返します。取得を追加する前に、クエリを練り直してください。	クエリの作成
9	トピックに合致する情報源なら、どれも同じように優れています	情報源の評価によって、信頼できる回答とノイズを見分けられます。フォーラムや SEO ブログより、公式ドキュメント、GitHub リポジトリ、バージョンが明記された情報源を優先してください。	情報源の評価
10	検索に失敗したら、別の検索ツールを試してください	ホスト検索の結果が悪い場合、同じクエリを別の検索バックエンドで使っても、結果は同様に悪くなります。まずクエリを練り直し、その後でツールの切り替えを検討してください。	クエリの練り直し
11	検索回数が多いほど、常に良い結果が得られます	クエリを2～3回練り直しても失敗する場合、検索を続けるとコンテキストとクレジットを無駄にします。「調査の行き詰まりプロトコル」に従い、失敗を分類し、戦略を切り替え、情報の不足を記録してください。	行き詰まりプロトコル
12	情報源が多いほど、常に統合結果が良くなります	ほとんどの質問では、互いに独立した2つの情報源が一致すれば十分です。3つ以上の情報源が同じ回答を裏付けている場合、それは確認であって改善ではありません。証拠が一致した場合、公式情報源が見つかった場合、またはバージョンが明記された回答が得られた場合は、そこで終了してください。「調査方法」→「調査の十分性」を参照してください。	調査の十分性
13	調査は検索から始めるべきです	調査は計画から始めるべきです。一文で表した調査上の問い、すでに分かっていることの把握、終了条件がなければ、検索の焦点が定まらず、結果にノイズが増えます。「調査の計画」を参照してください。	調査の計画
14	検索は常に1回で十分です	複雑な質問では、最初の結果からより具体的な質問が分かるため、連続した追加検索が必要になることがよくあります（「X はどのように動作しますか？」→「X は Y をどのように処理しますか？」）。最初の結果に含まれるバージョン番号と重要な用語を、追加クエリにも引き継いでください。「調査方法」→「調査の連鎖」を参照してください。	調査の連鎖

クイックコマンド

ハイブリッド調査パターン（ほとんどの調査に推奨）：

1. ホストの web_search で発見し、次にホストの web_fetch で詳しく読み込みます：

web_search: "What changed in Next.js 15?"
→ scan titles + snippets (don't read all results in full)
→ select 1-2 most relevant URLs
web_fetch: top URL for deep content
→ optional, only if host fetch is insufficient AND a specialized backend is already available:
   firecrawl scrape "<url>" --only-main-content --format markdown

調査セッションを初期化します：

npm run research:session:init -- --query "What changed in Next.js 15?"

Firecrawl 検索は任意です（その CLI がすでに利用可能で、ホスト検索だけでは不十分な場合に限ります）：

export FIRECRAWL_OUTPUT_DIR=".researches/<timestamp>/firecrawl/raw"
firecrawl search "site:nextjs.org Next.js 15" --scrape --limit 10 --json \
  -o "$FIRECRAWL_OUTPUT_DIR/search.json"

二重表現のスクレイプは任意です（同じ条件の場合）：

firecrawl scrape "https://docs.nextjs.org/14" --format markdown \
  -o ".researches/<timestamp>/documentation/markdown/nextjs-14.md"
firecrawl scrape "https://docs.nextjs.org/14" --format html \
  -o ".researches/<timestamp>/documentation/html/nextjs-14.html"

セッションの自動検出で統合します（存在する場合、web-search、web-fetch、web-research、firecrawl の各ディレクトリを取得します）：

# Runner alternatives: bunx tsx / pnpm dlx tsx / deno run -A npm:tsx / node --import tsx / yarn dlx tsx
npx tsx .agents/skills/research-online/scripts/consolidate-research.ts \
  --session-dir .researches/<timestamp> \
  --query "What changed in Next.js 15?" \
  --format thematic

# Content cleaning is enabled by default during consolidation.
# Use --no-clean to disable it when raw content is needed:
npx tsx .agents/skills/research-online/scripts/consolidate-research.ts \
  --session-dir .researches/<timestamp> \
  --query "What changed in Next.js 15?" \
  --format thematic \
  --no-clean

# Or consolidate the latest session automatically:
npx tsx .agents/skills/research-online/scripts/consolidate-research.ts \
  --auto-session \
  --query "What changed in Next.js 15?" \
  --format thematic

特定のディレクトリから統合します（旧方式、単一の入力ディレクトリ）：

# Runner alternatives: bunx tsx / pnpm dlx tsx / deno run -A npm:tsx / node --import tsx / yarn dlx tsx
npx tsx .agents/skills/research-online/scripts/consolidate-research.ts \
  --input-dir .researches/<timestamp>/firecrawl/reports \
  --query "What changed in Next.js 15?" \
  --format thematic

ホストの Web ツールの結果をセッションに保存します：

# Save web_search results
# Runner alternatives: bunx tsx / pnpm dlx tsx / deno run -A npm:tsx / node --import tsx / yarn dlx tsx
npx tsx .agents/skills/research-online/scripts/save-web-research.ts \
  --query "Drizzle ORM connection pooling" \
  --source search \
  --content '{"results": [...]}'

# Save web_fetch content (content cleaning enabled by default for fetch sources)
npx tsx .agents/skills/research-online/scripts/save-web-research.ts \
  --query "Drizzle ORM connection pooling" \
  --source fetch \
  --content "$(cat page.md)" \
  --url "https://orm.drizzle.team/docs/connect-overview"

# Save web_fetch content with raw content preserved (--no-clean)
npx tsx .agents/skills/research-online/scripts/save-web-research.ts \
  --query "Drizzle ORM connection pooling" \
  --source fetch \
  --content "$(cat page.md)" \
  --url "https://orm.drizzle.team/docs/connect-overview" \
  --no-clean

コマンドの全容については、references/tool-selection.md を参照してください。

コマンド選択ガイド

シナリオ	最適なツール	理由
簡単な事実確認や情報の発見	ホストの web_search	デフォルトの方法。利用可能な検索機能を使用します
読みたい URL が分かっている	ホストの web_fetch	デフォルトの方法。利用可能な取得機能を使用します
正確な URL が分からず、対象を絞った検索が必要	ホストの web_search、続けて web_fetch	スニペットを確認してから、選択したページを詳しく読み込みます
サイト構造の把握が必要	専用バックエンドの map（Firecrawl など）がすでに利用可能な場合	ホストツールに相当する機能がありません
ドキュメントのセクションを詳しく調べる	一覧にある URL に対するホストの web_fetch。専用の crawl は任意	バックエンドが存在する場合に限りクロールします
構造化フィールドの抽出	専用の agent --schema がすでに利用可能な場合	それ以外の場合は、取得して手動で解析します
複雑な自律的探索	専用の agent --wait がすでに利用可能な場合	それ以外の場合は、ホスト検索を連鎖させます
JavaScript が多いページやインタラクティブなページ	専用の browser がすでに利用可能な場合	それ以外の場合は、対応できない点を記録します
リポジトリのドキュメントを複数のソースからアーカイブ	archive-github-repo-docs.ts	Markdown と HTML を組み合わせて取得します
再現可能な調査セッション	セッションスクリプトと .researches/	使用した検索・取得手段に左右されません
専用バックエンドがインストールされていない	ホストの web_search / web_fetch	フォールバックではなく、完全なデフォルトの方法です

経験則： 利用可能なツールのうち、目的を満たす最もシンプルなものを使います。発見と読み込みにはホストの検索・取得機能を使います。専用バックエンドは、サイトマッピング、クロール、スキーマ抽出、ブラウザー操作など、固有の用途に限って使用し、すでに利用可能な場合に限ります。

クイック判断ガイド

シナリオ	推奨する方法	トレードオフ
Web から最新情報を取得したい	ホストの web_search	デフォルト。追加インストールは不要です
ドキュメントを詳しく抽出したい	単一ページにはホストの web_fetch。複数ページのサイトには専用の map / scrape を任意で使用	ホストツールは高速です。バックエンドはすでに利用可能な場合に限ります
既知のページから構造化データを取得したい	専用の agent --schema がすでに利用可能な場合はそれを使用し、そうでなければ取得して解析	スキーマ抽出は任意です
JavaScript が多いページやインタラクティブなページ	専用の browser がすでに利用可能な場合はそれを使用し、そうでなければ対応できない点を記録	最も遅い方法です。ホストの取得機能が失敗した場合に限ります
GitHub リポジトリのドキュメント	archive-github-repo-docs.ts	blob ページ由来の Markdown のノイズを避けられます
セッションが不要な簡単な質問	ホストの web_search	回答を得る最速の方法です
複数のソースを対象とする体系的な調査	ホストの検索・取得機能と .researches/ セッション	再現性のために Firecrawl は不要です
発見と詳しい抽出を組み合わせる	フェーズ 1：ホストの web_search → フェーズ 2：必要な場合に限り、バックエンドが存在すれば使用	デフォルトではホスト機能のみを使います

調査方法

調査の質は、ツールの選択以外に、クエリの作成、情報源の評価、統合時の規律という 3 つの要素に左右されます。このセクションでは、それぞれについて具体的なヒューリスティックを紹介します。

クエリの作成

検索結果の品質は、クエリの作成方法に直接左右されます。次の原則に従ってください。

言い換えのテクニック、ドメイン固有のパターン、アンチパターンの例を含むクイックリファレンスカードの全文は、references/query-formulation.md を読み込んでください。

1. 具体的に始め、必要に応じて範囲を広げます。 正確な技術概念、API、またはエラーメッセージを軸にクエリを作成します。検索結果が少ない場合は、用語を1つずつ一般化します。

   ❌ "how to use drizzle"          → too broad, returns marketing pages
   ❌ "drizzle orm"                → returns overview, not specifics
   ✅ "drizzle ORM connection pooling postgres"  → targets the exact topic
   ✅ "drizzle pgPool2 connection config"          → uses the specific API name
   

2. 曖昧さをなくす文脈キーワードを含めます。 「Auth」は多くの意味を持ちますが、「Better Auth Next.js session cookie」とすれば意味を特定できます。

   ❌ "authentication setup"
   ✅ "Better Auth Next.js App Router session configuration"
   

3. 時期によって変わるトピックには、バージョンと年を含めます。 フレームワークやAPIは変化するため、バージョンを指定したクエリで最新の回答を見つけやすくなります。

   ❌ "Next.js App Router changes"
   ✅ "Next.js 15 App Router changes 2025"
   

4. 正確なエラーメッセージを引用符で囲みます。 デバッグ時には、エラー文字列そのもの（または最も特徴的な部分）をクエリとして使います。

5. テクノロジー名を含めます。 「connection pooling」のような一般的な用語では無関係な結果が返されますが、「pg-pool connection pooling Node.js」とすれば対象を絞り込めます。

6. 疑問詞は避けます。 「how to」「what is」「why does」で始まるクエリは、検索の精度を下げます。技術的な名詞句から始めてください。

7. 繰り返し試します。検索結果を増やすだけでなく、クエリを言い換えます。 最初のクエリで質の低い結果しか得られない場合は、ページを追加で取得する前に別の用語で言い換えてください。

情報源の評価

すべての検索結果が同等とは限りません。web_search の結果を確認したり、web_fetch の URL を選んだりする際は、次の基準を適用してください。

ドメインの権威性に関する早見表、危険信号、言い換えの指針を含むクイックリファレンスカードの全文は、references/source-evaluation.md を読み込んでください。

シグナル	信頼性の高い情報源	信頼性の低い情報源
ドメイン	公式ドキュメント、GitHub リポジトリ、.dev サイト	フォーラム、SEO重視のブログ、コンテンツファーム
新しさ	過去12か月以内の日付がある、またはバージョンが明記されている	日付がない、バージョンへの言及がない
詳しさ	コード例、APIシグネチャ、移行ガイド	概要レベルの説明、マーケティング文
権威性	一次情報（作成者がメンテナーまたは公式チーム）	公式情報源への参照がないサードパーティのチュートリアル
正規性	RFC、仕様書、公式の変更履歴への参照	出典リンクのない言い換え要約

優先順位のルール： 強いシグナルが3つ以上一致する結果は、最初に詳しく読み込みます。強いシグナルが2つ以上一致する結果がない場合は、クエリを言い換えてください。

統合の品質

調査結果の統合は、断片をつなぎ合わせたものではなく、構造化された回答にしてください。

1. 最初に直接回答します。 最初の文で調査結果を述べ、その後に根拠を示します。
2. すべての主張に出典を付けます。 各事実の記述に、出典 URL と日付を含めます。
3. 食い違いを明示します。 2つの情報源の見解が異なる場合は、両方を示し、矛盾の解決に関する優先順位（公式 > コミュニティ、新しい情報 > 古い情報、一次情報 > 二次情報、合意 > 少数意見、検証可能 > 検証不可能）に従って判断します。
4. 不足している点を明示します。 どの情報源も質問に十分に答えていない場合は、その旨を述べ、推測で補わないでください。
5. 事実と意見を区別します。 利用できる根拠がフォーラムの投稿やブログの意見だけの場合は、そのように明示します。
6. バージョンの文脈を示します。 変化の速いライブラリやAPIを調査した場合は、調査結果がどのバージョンに該当するかを記載します。

矛盾の解決

2 つ以上の情報源の内容が食い違う場合は、次の優先順位で判断します。

1. 公式ドキュメント > コミュニティコンテンツ。 公式ドキュメントに X とあり、Stack Overflow の回答に Y とある場合は、公式ドキュメントが古くなっていない限り（公開日を確認してください）、公式ドキュメントを優先します。
2. 新しい情報 > 古い情報。 変化の速いライブラリについて、2025 年の記事と 2023 年の記事の内容が矛盾する場合は、2025 年の記事を優先します。必ずバージョンまたは日付を明記してください。
3. 一次情報 > 二次情報。 元の情報源（RFC、仕様書、公式ドキュメント）に X とあり、サードパーティのチュートリアルに Y とある場合は、一次情報を優先します。
4. 多数意見 > 少数意見。 4 つの情報源が X と述べ、1 つが Y と述べている場合は、少数意見にも触れたうえで、多数意見に従います。ただし、少数意見が公式情報源によるものである場合を除きます。
5. 検証可能な情報 > 検証不可能な情報。 ある情報源にコード例、再現可能な手順、または一次情報源へのリンクがあり、別の情報源に裏付けのない主張がある場合は、検証可能な情報を優先します。

これらのルールを適用しても矛盾が解決しない場合は、統合結果の「矛盾する根拠」セクションに両方の見解を提示し、どちらも明確に優先できない理由を説明します。

反復的な改善パターン

最初のクエリで有用な結果が得られない場合：

Step 1: Classify the failure
  - No results → query too specific or uses uncommon terminology
  - Irrelevant results → query too broad or ambiguous
  - Outdated results → add version/year qualifiers
  - Low-authority results → add technology name or scope qualifier

Step 2: Reformulate using one tactic at a time
  - Generalize: remove the most specific term
  - Rephrase: swap in synonyms or alternate terminology
  - Scope: add technology/framework name as context
  - Version: add year or version number
  - Error-quote: use exact error message

Step 3: Stop after 2-3 reformulations
  - If still unsuccessful, note the gap in the synthesis
  - Consider whether the information exists online at all
  - Suggest alternative research angles if appropriate

調査の連鎖

最初の検索で結果は得られたものの、より具体的な疑問が明らかになった場合は、最初からやり直すのではなく、追加の検索を連鎖させます。

1. 具体的な疑問を抽出します。 最初の結果で大まかな疑問には答えられたものの、より範囲が狭く、掘り下げた疑問（「X はどのように動作するか？」→「X は Y を具体的にどのように処理するか？」）が明らかになった場合は、追加調査の質問を新たな 1 文のリサーチクエリとして記述します。
2. すでに得た情報を引き継ぎます。 最初の結果に含まれていたバージョン番号、フレームワーク名、重要な用語を追加調査のクエリに含めます。これにより、追加のクエリがより具体的になり、関連性の高い結果が得られやすくなります。
3. 十分性の基準をより厳しくします。 2 回目または 3 回目の検索では、追加調査の質問に直接答える信頼できる情報源が 1 つあれば十分です。大まかな背景を改めて調べ直す必要はありません。

Chain example:
  Search 1: "Next.js App Router" → reveals Server Components are the key concept
  Search 2: "Next.js 15 Server Components data fetching" → reveals caching behavior
  Search 3: "Next.js fetch cache revalidation" → targeted answer found, stop

連鎖を続ける場合と終了する場合： 最初の回答が不完全な場合、または想定していなかった依存関係が明らかになった場合は、追加検索を続けます。元の質問に対する、バージョンが明記された直接的な回答が得られたら終了します。

連鎖のしすぎに注意： 3 回以上検索を連鎖させても直接的な回答にたどり着けない場合は、元の質問の範囲が広すぎるか、オンラインに情報が存在しない可能性があります。それ以上検索を連鎖させず、行き詰まり時のプロトコルに従ってください。

調査が行き詰まった場合の手順

検索クエリを2～3回言い換えても結果が乏しい場合は、検索を続けるのではなく、代わりに次の手順に従ってください。

1. 行き詰まりの種類を分類します。

   • トピックがニッチすぎる： 情報が公開されていない可能性があります。一次情報源（公式ドキュメント、GitHub リポジトリ、RFC）に切り替えてください。
   • トピックが新しすぎる： 情報がまだ公開されていない可能性があります。プレリリース版のドキュメント、GitHub のイシュー、ディスカッションフォーラムを検索してください。
   • トピックが曖昧すぎる： 質問の範囲を広げてその分野を調査し、その後、具体的な質問に絞り込んでください。
   • 言語の壁： 情報が別の言語でしか入手できない可能性があります。翻訳したキーワードを使って web_search を試してください。

2. ツールではなく、戦略を切り替えます。

   • ホストの web_search で結果が乏しい場合、同じクエリのまま別の検索バックエンドに切り替えないでください。問題はツールではなく、クエリです。
   • まずサイトを指定した検索を試してください。site:docs.example.com <topic> で公式ドキュメントを直接検索できます。
   • バージョンを指定した検索を試してください。"<library> <version>" <feature> で特定のリリースに関する情報を検索できます。
   • エラー文を引用した検索を試してください。エラーメッセージ全体、または最も特徴的な部分を貼り付けてください。

3. 行き詰まりの経緯を統合結果に記載します。

   • 何を検索し、何がうまくいかなかったかを記載してください。
   • 結果が乏しかったクエリを記録してください。
   • 「[トピック] に関する信頼できる情報源は見つかりませんでした」と、情報の不足を明示してください。
   • 「[URL] の公式ドキュメントを直接確認してください」や「GitHub のイシューでメンテナーに問い合わせてください」など、次の行動を提案してください。

4. 推測で補わず、エスカレーションします。

   • 信頼性の低い根拠から回答を捏造しないでください。
   • 部分的な情報がある場合は、適切な確信度を示して提示してください。
   • 情報がない場合は、その旨を伝えてください。自信ありげな誤答より、正直に「わかりません」と答えるほうが適切です。

調査の十分性

調査の止めどきを見極めることは、調査方法を知ることと同じくらい重要です。調べすぎるとコンテキストとクレジットを無駄に消費し、調査不足は信頼性の低い統合結果につながります。

次の条件を満たしたら、調査を終了します。

1. 複数の情報源が一致している。 2つ以上の独立した情報源が同じ回答を示しています。1つは手がかり、2つは有力な兆候、3つで確証です。
2. 公式の情報源がある。 公式ドキュメントが質問に直接回答している場合は、調査を終了してください。公式ドキュメントが古くなっている場合を除き、二次情報で確認する必要はありません。
3. バージョンを明記した回答が得られている。 回答にバージョン番号と日付（例：「Next.js 15、2025年」）が含まれていれば、根拠に時点が明示されており、後から見つかった検索結果によって覆される可能性は低くなります。
4. すべての小問を網羅している。 元の調査の質問に3つの側面があり、そのすべてに回答できている場合は、側面1についてさらに情報源を見つけられるとしても、調査を終了してください。

次の場合は、調査を続けてください。

• 情報源同士が矛盾している場合（「矛盾の解決」に従ってください）。
• 情報源がフォーラム、ブログ記事、または AI 生成コンテンツだけの場合（公式または一次情報源を探してください）。
• 回答がバージョンに依存するのに、バージョンが記載されていない場合（クエリにバージョンを指定してください）。
• 間接的な根拠しか見つかっていない場合（質問に直接回答する情報源がない）。

クエリの種類ごとの実践的な終了基準：

クエリの種類	次の条件を満たしたら終了	必ず満たすべき条件
簡単な事実確認	信頼できる情報源1つで確認できた	情報源1つで確認できる
バージョンを指定した質問	バージョンを明記した公式情報源1つがある	バージョンが記載されている
方法／設定	公式ドキュメント1つと動作する例1つがある	ドキュメントと例の両方が、指定されたバージョンに一致する
比較／トレードオフ	2つ以上の異なる視点を持つ情報源がある	すべての視点が網羅されている
エラー診断	バージョンを確認済みの修正方法が1つある	修正方法が該当バージョンに合致している

譲れないポリシー

1. ホストの検索／取得機能をデフォルトで使用します。 ハーネスが提供する web_search／web_fetch（または同等の機能）を使用してください。マッピング、クロール、スキーマ、ブラウザー関連の作業でしか対応できない場合に限り、Firecrawl CLI などの専用バックエンドを任意で使用できます。
2. バックエンドのセットアップで作業を止めないでください。 通常の調査の事前確認として firecrawl --status を実行しないでください。専用の手順が必要でもバックエンドが利用できない場合は、ホストのツールを使って完了し、不足している点を記載してください。調査中にインストールや認証を行わないでください。
3. 専用バックエンドがすでに利用可能で、コマンドの構文が必要な場合に限り、references/tool-selection.md を参照してください。CLI フラグを記憶を頼りに再現しないでください。
4. 最もコストの低いワークフローから始めてください（ホスト検索、対象を絞った取得の順に行い、バックエンドがある場合は、専用の agent／browser より先に search／scrape を使用してください）。
5. タスクに必要な references/ の一部だけを読み込んでください。デフォルトですべてのファイルを読み込まないでください。
6. 調査セッションは .researches/<timestamp>/ に保存してください。ドキュメントを対象とする場合は、Markdown 形式と HTML 形式の両方を保持してください。
7. すべての統合結果に出典を明記し、公開前に scripts/consolidate-research.ts を実行してまとめてください。
8. 専用バックエンドの料金、モデル、または現行バージョンについて回答する場合は、同梱データが古い可能性が高いとみなし、具体的な情報を高い確度で述べる前に、そのツールの --help で確認してください。
9. ホストのツールでマッピング、クロール、スキーマ、または JS ブラウザー関連の作業に対応できない場合は、 統合結果に制限事項を記載してください。ホストのツールだけで行った調査を不完全なものとして扱わないでください。

ワークフロー

0. 検索する前に計画します。 リサーチ計画に関する3つの質問に答えてください：（1）一文で表すと、リサーチの問いは何ですか？（2）すでに把握していることは何ですか？（3）どのリサーチ十分性の停止ルールを適用しますか？ 明確な問いを設定せずにステップ1へ進まないでください。

1. リサーチの複雑さを分類します。

   • シンプル（簡単な調査、単一の事実、比較）：ホストの web_search／web_fetch を直接使用します。ステップ7へ進んでください。
   • 高度（複数ソース、構造化抽出、サイトマッピング、再現可能なアーカイブ）：ホストツールを先に使用して、ステップ2へ進んでください。

2. ホストの検索／取得ツールを使用します。 専用バックエンドは任意です。ホストツールではマッピング／クロール／スキーマ／ブラウザーに対応できず、かつバックエンドがすでに利用可能な場合に限って使用してください。通常のリサーチでは、事前確認のために firecrawl --status を実行しないでください。

3. リサーチセッションを初期化します：

   npm run research:session:init -- --query "<research question>"
   

4. タスクを分類し、必要最小限の有用な参考資料を読み込みます（下表を参照）。

5. 選択したツールで、アクティブなセッションフォルダーを対象にデータを収集します。

   • クエリを慎重に作成します（「リサーチ手法」＞「クエリの作成」を参照）。具体的な内容から始め、必要な場合にのみ範囲を広げます。結果が不十分なときは、さらに取得するのではなく、クエリを作り直してください。
   • 深く読み込む前にソースを評価します（「リサーチ手法」＞「ソースの評価」を参照）。強いシグナル（公式ドキュメント、新しさ、コード例、権威性、正本性）のうち、3つ以上に合致する結果を優先してください。
   • ホストのウェブツール：save-web-research.ts を使って .researches/<timestamp>/ に結果を保存します（web-search/、web-fetch/、documentation/markdown/、html/）。
   • 専用バックエンド（任意）： Firecrawl CLI を使用する場合は、FIRECRAWL_OUTPUT_DIR=".researches/<timestamp>/firecrawl/raw" を設定してください。
   • ドキュメントページについては、Markdown と HTML の両方の形式を保持してください。
   • GitHub リポジトリのファイルについては、scripts/archive-github-repo-docs.ts を使用してください（references/github-repository-doc-archival.md を参照）。

6. 専用バックエンドのコマンドの詳細が不明な場合は、範囲を広げる前に、対応する別個のガイドを参照してください。ガイドが見つからないことをリサーチの妨げにしないでください。

7. コンテキストが多い場合や対象が多岐にわたる場合は、ハーネスワーカーを使って独立したソースを並行処理します（references/harness-patterns.md を参照）。

8. scripts/consolidate-research.ts を使って調査結果を統合します。

   • コンテンツのクリーニングはデフォルトで有効です。生のコンテンツを保持するには --no-clean を使用してください。
   • --auto-session を使用すると、セッションを自動検出できます。
   • 統合後の出力にあるクリーニング統計を確認し、不要なページ要素が削除されていることを検証してください。

9. 明示的な不足点と確信度に関する注記を添えて、簡潔に統合した結果を提示します。

   • 統合の原則を適用します（「リサーチ手法」＞「統合の品質」を参照）：直接的な回答を最初に示し、すべての主張に出典を付け、矛盾点を指摘し、不足点を明示し、事実と意見を区別し、バージョンに関する背景を示してください。
   • 提示する前に、「完了時の出力要件」＞「リサーチ品質チェックリスト」を参照し、内容を照合してください。
   • クエリを2～3回作り直しても失敗した場合は、検索を続けるのではなく、「リサーチ手法」＞「リサーチの行き詰まりへの対応」に従ってください。

タスクの種類ごとの参照ファイルの読み込み

タスクに必要なファイルだけを読み込んでください。通常の調査の前に、専用バックエンドのステータス確認を実行しないでください。

タスクの種類	これらのファイルを読み込む	スキップ
専用バックエンドのコマンドを選択する（そのバックエンドがすでに利用可能な場合のみ）	tool-selection.md	consolidation-patterns.md
複数の情報源にまたがる調査を並列化する	harness-patterns.md	github-repository-doc-archival.md
GitHub リポジトリのドキュメントをアーカイブする	github-repository-doc-archival.md	harness-patterns.md
サブエージェントの結果を統合する	consolidation-patterns.md	tool-selection.md
情報源の信頼性を評価する	source-evaluation.md	consolidation-patterns.md
効果的なクエリを作成する	query-formulation.md + source-evaluation.md	github-repository-doc-archival.md
検索結果の質が低い場合に改善する	query-formulation.md（再構成の手法）	source-evaluation.md
簡易調査（ホストツール）	query-formulation.md + source-evaluation.md	tool-selection.md、harness-patterns.md、github-repository-doc-archival.md
成果物を保存して統合する	consolidation-patterns.md（セッションの検出）	source-evaluation.md

完了時の出力規約

統合形式

調査結果は、次の形式で提示してください。

## [Topic]

**Answer:** [Direct answer to the research question — 1–3 sentences]

### Key Findings
1. [Finding 1 with attribution — `source URL (date)`]
2. [Finding 2 with attribution]

### Conflicting Evidence
- [Conflict: Source A says X, Source B says Y. Resolved: prefer A because (official docs > community / recent > outdated / primary > secondary)]

### Gaps
- [Explicitly state what could not be determined]

### Sources
- [Source 1: URL — version/date — signal score]
- [Source 2: URL — version/date — signal score]

内容のないセクション（例：矛盾する証拠がない場合は、そのセクション）は省略してください。

調査セッションの完了後、chooseable-options/SKILL.md に従った CHOOSEABLE_OPTIONS として Next steps: を提示してください（選択可能なトークンを表示し、利用可能な場合はハーネスの Ask User ピッカーにも表示します）。

• ACTION_NAME_IN_SCREAMING_SNAKE_CASE：選択された場合に実行する内容の説明。

必須の基本オプション：

• CREATE_RESEARCH_DERIVED_EXPERT_SKILL：この調査トピックから再利用可能なエキスパートスキルを作成します。正確な .researches/<timestamp>/ ペイロード（consolidated.md、consolidated.json、web-search/、web-fetch/、metadata.json、および専用バックエンドを使用した場合は firecrawl/ ディレクトリも含む）を使用してください。

スキル間のルーティングオプション（表面化したシグナルに応じて動的に生成します）：

• PREPARE_IMPLEMENTATION_PLAN：調査結果が実装に移せる段階にある場合は、plan/SKILL.md にルーティングします。
• DEEPEN_RESEARCH_WITH_ONLINE_STUDY：未解決の疑問が残る場合は、study/SKILL.md にルーティングします。
• RESOLVE_COMPETING_APPROACHES：トレードオフが未解決の場合は、decisions/SKILL.md にルーティングします。
• SYNC_GUIDANCE_DOCUMENTATION：ポリシーまたはドキュメントの更新が必要な場合は、documentation-sync ワークフローにルーティングします。
• REFINE_SPECIALIZED_BACKEND：そのバックエンドを使用しており、コマンドに不足が残る場合に限り、兄弟プライマー（firecrawl または同等のもの）にルーティングします。
• VALIDATE_RESEARCH_CLAIMS_IN_UI：調査結果がユーザー向けの動作に影響する場合は、playwright-cli ワークフローにルーティングします。
• TARGET_PRIMARY_DOC_RESEARCH：情報源の矛盾または信頼度の低さが残る場合は、対象範囲を絞って research-online/SKILL.md で調査を続けます。

調査品質チェックリスト

調査の統合結果を確定する前に、すべての項目を確認してください。

#	確認項目	重要な理由
1	結論を最初に示す — 統合結果は情報源ではなく、調査結果から始まっていますか？	読者が根拠より先に回答を確認できるようにします
2	すべての主張に出典を付ける — 各事実の記述に、出典 URL と日付が添えられていますか？	出典のない主張は検証できず、誤っている可能性もあります
3	矛盾を解決する — 複数の情報源で見解が異なる場合、矛盾の優先順位（公式 > コミュニティ、新しい情報 > 古い情報、一次情報 > 二次情報、総意 > 例外的見解、検証可能 > 検証不可能）に基づく解決方法とともに、両方の見解を記載していますか？	矛盾を無視すると、誤った確信につながります
4	不足している情報を明示する — 回答のない質問は、推測で補わず、不足情報として示されていますか？	不足情報を明示するほうが、回答を捏造するより誠実です
5	事実と意見を区別する — フォーラムの投稿やブログの意見は、そのように明記されていますか？	すべての情報源が同じ信頼性を持つわけではありません
6	バージョン情報を記載する — 変更の速いライブラリについて、バージョン番号と日付が含まれていますか？	バージョン情報のない回答は、すぐに古くなります
7	情報源を評価する — 引用した情報源は、5 つのシグナルに基づく評価基準で 3 以上を獲得していますか？	質の低い情報源は、統合結果全体の信頼性を損ないます
8	クエリを見直す — 最初の検索結果が不十分だった場合、追加で情報を取得する前にクエリを改善しましたか？	ツールの選択にかかわらず、質の低いクエリからは質の低い調査結果が得られます
9	コンテンツを整理する — 取得したページからナビゲーション要素が削除されていますか（save-web-research と consolidate ではデフォルトで削除されます）？	ノイズの多いコンテンツは、統合結果の質を低下させます
10	成果物を保存する — 再現性を確保するため、すべての結果が .researches/<timestamp>/ に保存されていますか？	保存されていない結果は、検証や再分析ができません

セッションの保存場所

.researches/ の下に、タイムスタンプ付きのセッションフォルダーを使用します。

.researches/
└── 2026-02-11T134626Z/
    ├── documentation/
    │   ├── html/
    │   ├── markdown/
    │   └── screenshots/
    │       └── full-page/
    ├── firecrawl/           ← only if a Firecrawl backend was used
    │   ├── raw/
    │   └── reports/
    ├── web-search/          ← host search artifacts (JSON)
    ├── web-fetch/           ← host fetch artifacts (markdown, HTML)
    ├── web-research/        ← hybrid search+fetch artifacts
    ├── metadata.json
    ├── subagent-reports/
    ├── consolidated.md
    └── consolidated.json

.researches/.gitkeep をコミットした状態に保ち、生成済みのセッションフォルダーを公開してください。

よくある落とし穴

1. Firecrawl（または他の特化型バックエンド）の応答を待って調査を止めてしまう。 ホスト検索／取得がデフォルトです。CLI をインストールして認証するために調査を中断しないでください。
2. 簡単な検索に特化型バックエンドを必須にする。 ちょっとした事実確認や情報の発見には、ホストの web_search がデフォルトです。
3. HTML のバックアップを用意せず、Markdown のドキュメントだけを残す。 ドキュメントを対象にする場合、ソースへの忠実性を保つには両方の形式が必要です。
4. GitHub の blob ページから取得した内容を正規のソーステキストとして信頼する。 blob ページの Markdown には GitHub の UI が含まれます。正規のテキストには raw.githubusercontent.com またはローカルクローンを使用してください。
5. Firecrawl のバッチコマンドを実行する前に FIRECRAWL_OUTPUT_DIR を設定し忘れる。 この CLI を実際に使用する場合に限り関係します。セッションごとに一度設定してください。
6. 簡単な検索に firecrawl agent を使う。 Firecrawl を使う場合、既知の対象には search と scrape のほうが低コストで高速です。ホスト検索ならさらに低コストです。
7. --limit と --max-depth でクロールの範囲を絞らない。 範囲を指定しないクロールはコストがかかり、レート制限に達する可能性があります。
8. ホストのウェブツールを予備の手段として扱う。 情報の発見、単一ページの読み取り、調査セッション全体でのデフォルトです。特化型バックエンドは追加の選択肢です。
9. 曖昧すぎる、または範囲が広すぎる検索クエリを使う。 「X の使い方」ではマーケティングページが返されますが、「X v2 API configuration」なら対象を絞ったドキュメントが返されます。クエリの組み立ては、調査で最も効果の高いスキルです。
10. すべての情報源を同等に信頼する。 公式ドキュメントや GitHub リポジトリは、無作為なブログ記事よりも信頼できます。詳しく読み込む前に、情報源の信頼性を評価してください。
11. 2～3 回クエリを言い換えて失敗した後も検索を続ける。 言い換えても複数回にわたり結果が芳しくない場合は、行き詰まりの原因（ニッチすぎる、新しすぎる、曖昧すぎる、言語の壁）を分類し、戦略を切り替えるか、調査できなかった点を記録してください。うまくいかない方法にクレジットやコンテキストを無駄に使わないでください。
12. クエリを言い換えずにツールを切り替える。 ホスト検索の結果が芳しくない場合、同じクエリを別の検索バックエンドに使っても、結果は芳しくありません。問題はツールではなくクエリです。まずクエリを言い換え、その後でツールを切り替えてください。
13. 証拠が収束した後も調査を続けすぎる。 ほとんどの質問では、独立した情報源 2 件が一致すれば十分です。同じ点について 5 件以上の情報源を探し続けると、コンテキストとクレジットを無駄にします。終了基準については「Research Methodology → Research Sufficiency」を参照してください。
14. 調査の計画を立てずに検索を始める。 一文でまとめた調査の問い、すでに把握している内容の整理、終了基準がなければ、最初の検索は広すぎる可能性が高くなります。検索前に確認すべき 3 つの質問については「Research Planning」を参照してください。
15. 追加の検索で最初からやり直す。 最初の結果から、より具体的な問いが明らかになったら、バージョン番号や重要な用語を引き継いで追加検索につなげてください。すでに把握していることを捨てないでください。「Research Methodology → Research Chaining」を参照してください。

トラブルシューティング

症状	考えられる原因と対処法
ホストの検索ツールまたはフェッチツールが利用できない	不足している機能を報告してください。Firecrawl やその他のバックエンドのインストールを待つ必要はありません。
firecrawl コマンドが見つからない（使用するつもりだった場合のみ該当）	専用の手順は省略してください。ホストの検索／フェッチを続けてください。
firecrawl scrape の Markdown に UI のノイズが含まれる	--only-main-content を追加してください。GitHub のリポジトリでは、raw URL またはアーカイブ用ヘルパーに切り替えてください。
firecrawl browser の省略構文が失敗する	省略構文ではなく、明示的に firecrawl browser execute --node ... を使用してください。
スクリーンショットのキャプチャで URL が返されない	インストール済み CLI が --format screenshot をサポートしていることを確認してください。必要に応じてブラウザモードに切り替えてください。
統合処理の出力が空になる	入力ディレクトリに .json または .md ファイルがあり、--query が指定されていることを確認してください。
セッションフォルダーが自動公開されない	出力先は、有効な metadata.json がある .researches/ 内である必要があります。意図的にスキップする場合は --no-publish を使用してください。
ホストの web_search または web_fetch で結果が返されない	別のクエリ語を試してください。同じクエリのまま検索バックエンドを切り替えないでください。
ホストの web_search で無関係な結果が返される	クエリを練り直してください。テクノロジー名やバージョン／年の絞り込み条件を追加するか、エラーメッセージをそのまま使用してください。「調査方法」>「クエリの作成」を参照してください。
情報源の信頼性を評価する必要がある	公式ドキュメント、GitHub リポジトリ、バージョンが明記された情報源を優先してください。5 つのシグナルによるヒューリスティックについては、「調査方法」>「情報源の評価」を参照してください。
クエリを何度練り直しても結果が乏しい	行き詰まりの原因（ニッチすぎる、新しすぎる、曖昧すぎる）を分類し、「調査の行き詰まりへの対処手順」に従ってください。同じ戦略で検索を続けないでください。
2 つの異なる検索バックエンドで結果がどちらも乏しい	問題はツールではなくクエリにあります。ツールを切り替える前に、サイト、バージョン、またはエラー文を指定した検索でクエリを練り直してください。
専用バックエンドがない状態で構造化抽出が必要	ホストの web_fetch でページ内容を取得し、手動で解析してください。統合結果に不足している機能を記載してください。

信頼性とコストに関するガードレール

1. 質問に答えられる、利用可能な最もシンプルなツールから始めてください。 情報の探索にはホストの web_search、既知の URL にはホストの web_fetch を使用します。
2. 専用のクロール／スクレイピングバックエンドを使用する場合は、反復的なデバッグ中にキャッシュを利用できるよう、--max-age を優先してください。
3. クロールバックエンドを使用する場合は、--limit、--include-paths、--exclude-paths でクロール範囲を厳密に絞ってください。
4. 構造化された出力が必要で、そのバックエンドがすでに利用可能な場合に限り、スキーマ抽出エージェントを使用してください。
5. 自律型のブラウザー／エージェントモードは最後の手段とし、タイムアウト時のフォールバック処理を含めてください。
6. 再現性を確保するため、ホストの検索／フェッチ結果は .researches/<timestamp>/ に保存してください。Firecrawl のディレクトリは任意です。
7. 専用機能が必要でも利用できない場合は、その不足を記録し、ホストツールで完了してください。
8. 検索を開始する前にクエリを作成してください。 具体的で曖昧さのないクエリは、漠然としたクエリよりも良い結果を返します。結果が乏しい場合は、さらにページを取得するのではなく、クエリを練り直してください。
9. 詳細を読み込む前に情報源を評価してください。 公式ドキュメント、GitHub リポジトリ、バージョンが明記された最新の情報源を優先してください。より良い情報源がない場合を除き、フォーラムや SEO ブログは無視してください。
10. クエリを 2〜3 回練り直しても失敗したら検索を止めてください。 「調査の行き詰まりへの対処手順」に従い、失敗を分類して戦略を切り替え（サイト指定検索、エラー文検索、バージョン指定検索など）、不足を記録して推測するのではなくエスカレーションしてください。失敗している手法を続けないでください。
11. ツールを切り替える前にクエリを練り直してください。 ホストの検索で結果が乏しい場合、同じクエリを別の検索バックエンドに渡しても結果は乏しいままです。問題はツールではなくクエリにあります。

スクリプト一覧

スクリプト	目的	主なフラグ
scripts/init-research-session.ts	タイムスタンプ付きの調査セッションディレクトリを初期化します	--query、--metadata
scripts/save-research.ts	特化型バックエンドの成果物（使用した場合は Firecrawl のダンプ）をセッションにインポートします	--query、--results、--results-dir、--session-dir、--list
scripts/save-web-research.ts	ホストの検索／取得結果をセッションにインポートします。取得／ハイブリッドの場合、コンテンツのクリーニングはデフォルトで有効です（--no-clean で無効化）	--query、--source、--results、--content、--url、--clean、--no-clean、--session-dir、--metadata
scripts/clean-web-content.ts	ウェブコンテンツからナビゲーション要素、Cookie バナー、フッター、編集リンク、フィードバックのプロンプト、コピーボタン、ページネーション、インライン目次、ページ上部に戻るリンク、スポンサーセクション、ソーシャルメディアへの誘導、ニュースレターの CTA を除去します	--content、--file、--output、--source、--no-cookie、--no-nav、--no-footer、--no-social、--no-newsletter、--no-edit-links、--no-feedback、--no-related、--no-copy-buttons、--no-pagination、--no-toc、--no-back-to-top、--no-sponsors、--no-whitespace
scripts/clean-web-content.test.ts	コンテンツクリーニングのリグレッションテスト：除去テスト 10 件と誤検出防止テスト 8 件	実行：npx tsx .agents/skills/research-online/scripts/clean-web-content.test.ts1
scripts/consolidate-research.ts	レポートの重複を除去して統合し、consolidated.md と consolidated.json を作成します。コンテンツのクリーニングはデフォルトで有効です。未加工の出力には --no-clean を使用します。--session-dir または --auto-session を指定すると、すべての成果物ディレクトリを自動検出します	--session-dir、--auto-session、--input-dir、--input-file、--query、--format、--no-clean、--no-dedupe、--no-publish、--output
scripts/finalize-research-session.ts	スコープを限定したコミット／プッシュで、完了したセッションを公開します	--session-dir、--latest、--dry-run
scripts/archive-github-repo-docs.ts	正規の Markdown、HTML、および任意のスクリーンショットを使って GitHub リポジトリのドキュメントをアーカイブします	--session-dir、--github-repo、--branch、--repo-dir、--screenshot-mode、--file、--files-from
scripts/research-session.ts	ライブラリ：セッションディレクトリのレイアウト構築関数とヘルパー	他のスクリプトからインポート

ローカルコーパスの構成

references/ ディレクトリには、手作業で作成した統合ファイルが 6 つ含まれています。サブフォルダーはありません。ベンダー提供の上流ドキュメントページもありません。

ファイル	目的
consolidation-patterns.md	サブエージェントの調査結果を統合する 6 つの戦略に加え、重複除去と検証のチェックリスト
github-repository-doc-archival.md	GitHub リポジトリのドキュメント向けハイブリッドアーカイブパターン：正規の Markdown、レンダリング済み HTML、任意のスクリーンショット
harness-patterns.md	ハーネスワーカーのパターン：ホスト検索／取得の並列化（デフォルト）、任意の特化型バックエンドのパターン、セッションディレクトリのリファレンス
query-formulation.md	クエリ作成のクイックリファレンス：再構成の手法、ドメイン固有のパターン、クエリの構成、アンチパターン、フェーズごとのガイダンス
source-evaluation.md	ソース評価のクイックリファレンス：5 つのシグナルによるヒューリスティック、ドメインの権威性に関する早見表、バージョンを明示したクエリパターン、鮮度のシグナル、危険信号、再構成のガイダンス
tool-selection.md	ホスト優先のツール選択決定木。バックエンドが利用可能な場合に使用する、任意の Firecrawl CLI コマンドパターンとコスト管理のガードレール

ガイダンスとの整合性

• リポジトリのガイダンスを AGENTS.md に従って一貫して適用します。
• このスキルファイルを更新した場合は、npm run skills:sync を実行して IDE に新しいバージョンをすぐに反映させます。
• 新たにリリースされたバージョンのコマンド構文を使用する前に、そのツールの --help で特化型バックエンドの CLI の動作を確認します。バックエンドがすでに利用可能な場合にのみ、その手順を読み込みます。

一時ファイル

このスキルで一時ファイルを作成する必要がある場合は、.tmp/research-online/YYYY-MM-DD-{subject} の下に配置してください。ルートの .tmp/ ディレクトリはすでに gitignore されています。トップレベルにドットファイル用の一時ディレクトリを作成しないでください。

Footnotes

1. npx tsx は、標準的なランナーであればどれでも使用できます。たとえば、bunx tsx、pnpm dlx tsx、deno run -A npm:tsx、node --import tsx、yarn dlx tsx です。最初の5つは必要に応じて tsx を自動取得します。node --import tsx のみ、事前に tsx をローカルにインストールする必要があります（npm i -D tsx、または npm レジストリにアクセスできない場合は npm i -g tsx）。Bun ユーザーは tsx を使わず、bun <script> で TypeScript を直接実行することもできます。プロジェクトに含まれているものを選んでください。標準的なランタイムの選択表は、skills-manager スキルの Runtime Selection にあります（完全な gg-skills モノレポで作業している場合にのみ利用できます）。 ↩