effective-web-research

effective-web-research

外部ウェブでの調査をすべて効果的かつ信頼できるものにし、「深い調査」の依頼を、監査可能で情報源を評価したレポートにまとめます。確立された2つのフレームワーク、CRAAP（数十年にわたる情報リテラシー研究）とGoogle E-E-A-T（ウェブで広く採用されているコンテンツ品質基準）に基づいているため、ルールには根拠があり、独断的ではありません。

このスキルの対象は外部ウェブです。内部のコード検索ツールと競合するものではありません。

使用する場合／使用しない場合

エージェントが外部ウェブ（公式ドキュメントサイト、サードパーティライブラリのドキュメント、RFC、信頼できるブログ、論文、実世界のデータ）から情報を収集しようとしている場合、または収集を依頼された場合に使用します。

次の場合は使用しないでください。

• ワークスペース／リポジトリ内のファイルを読む（read、grep、ast-grep）
• ローカルのコードベースを調べる（LSP、goto_definition、explore エージェント）
• node_modules／venv／site-packages 内のインストール済み依存関係を読む
• ドキュメントを作成または編集する

これらは、異なるツールと品質基準を必要とする内部検索タスクです。

---

ステップ 0 — トリアージ：そもそも外部調査が必要か？

ウェブ検索の前に、外部調査が本当に適切かどうかを判断します。エージェントが反射的に Google 検索する多くの質問は、内部のコードベースからより速く、より確実に答えられます。答えがローカルにあるのに外部を調査すると、労力が無駄になるうえ、不確実性も生じます。

タスクの兆候	進め方	このスキルの役割
答えがリポジトリ内にありそう：コードのロジック、AGENTS.md の規約、既存のスキル、コードコメント、インストール済み依存関係のソース	まず内部を調査 — grep／read／LSP／explore を使用します。ウェブ検索は実行しません。	有効化しません（「まず内部を確認することを検討してください」という一言のヒントは問題ありません）
サードパーティライブラリ／フレームワーク／外部 API／ツールの動作／バージョン固有の癖について	外部 — ウェブ調査	デフォルトモード（4つの原則）を適用します
実世界の情報：ニュース、市場データ、人物、時事問題、論文	外部	デフォルトモードを適用します
ハイブリッド — 外部の概念と内部への適用（「使用中の X ライブラリは Y に対して脆弱か」「パターン X をコードに適用する」）	外部から内部へ — まず外部で概念を調査し、その後、内部で確認して適用します	外部の段階ではデフォルト／厳格モードを使用し、内部の段階では内部ツールを使用します
静的な手段ではコンテンツにアクセスできない（ログインが必要／JavaScript で描画される／小红书·公众号のようなスクレイピング対策プラットフォーム）	web-access スキルを使って CDP にエスカレーションします（実行時にチェックし、web-access がない場合はインストールを促すヒントを表示して中止します）。実際のブラウザーではログイン状態が維持されます	web-access が取得を処理します。取得した情報の信頼性を見極める際は、このスキルの規律も引き続き適用します

トリアージの兆候：

• 内部：「自分たちの／このプロジェクトの／このコードの／自分たちの規約」といった表現が質問に含まれる場合、または答えが明らかにリポジトリ内にある場合。
• 外部：バージョンを伴うサードパーティのライブラリ／フレームワーク／API／ツールが挙げられている場合、または外部の対象について「使い方／仕組み／ベストプラクティス／脆弱性の有無」を尋ねている場合。
• ハイブリッド：外部の概念と、「自分たちの／適用する／確認する」という表現、および内部の対象が組み合わさっている場合。

判断に迷う場合は、まず内部を調査してください。「自分たちの」ことについては、そのほうが速く、信頼できる情報源となります。内部検索で見つからなかった場合に限り、外部調査に進んでください。

---

エスカレーション — 静的レイヤーでコンテンツにアクセスできない場合（web-access 経由の CDP）

WebSearch／WebFetch／curl／Jina が、ページがブラウザー以外のクライアントを拒否している（ログイン画面、JavaScript で描画されるシェル、小红书・公众号 などのプラットフォームにおけるスクレイピング対策ブロック）ために目的の情報が含まれていないコンテンツを返した場合は、web-access スキルを読み込み、その CDP ガイダンスに従ってください。ユーザーが日常的に使うブラウザー（ログイン状態がそのまま利用可能）に接続し、curl HTTP API 経由でコンテンツにアクセスします。

これは実行時のローカル依存関係であり、frontmatter の dependencies エントリーではありません。中核となる調査の手法は web-access なしで機能し、上流のワークフロー（known-issue-research → solve-workflow ファミリー）にも外部プラグインの要件はありません。実際にエスカレーションする場合に限り、web-access の有無を確認してください。見つからない場合は処理を中止し、インストール方法をユーザーに伝えてください（暗黙のフォールバックは禁止です）。

取得方法と信頼性は別の問題です。4 つの原則／厳格モードでは、CDP が取得したコンテンツも引き続き評価します。エスカレーションの判断ツリーと curl API の早見表については、reference.md · CDP upgrade を参照してください。

---

デフォルトモード — 4 つの原則（アクティブなタスク内のすべてのウェブ検索に適用）

このスキルがタスクで有効な場合、そのタスク中に行うすべてのウェブ検索／webfetch に以下を適用してください。（スキルは説明が一致したタスクごとに有効になり、これらの原則はそのタスク内のすべての検索を対象とします。無関係なタスクでの検索には適用されません。）追加の成果物は作成しません。ウェブには古く、権威性が低く、転載されたコンテンツや AI 生成コンテンツがあふれているため、規律を欠くとエージェントがノイズを増幅してしまいます。

1. 権威性を優先する

情報源の優先順位：公式ドキュメント／サイト ＞ 権威ある二次情報（MDN、公式ブログ、RFC／仕様） ＞ 信頼できるコミュニティ（高評価の StackOverflow の回答、公式リポジトリの issue／PR） ＞ 一般的なウェブサイト。

適用方法：ウェブ検索結果が返されたら、まずドメインを確認します。公式サイト（react.dev、developer.mozilla.org、nodejs.org、<lib>.<org>）でしょうか。一般的なブログより先に公式サイトを読みます。 重要な理由：React Hooks に関する 2019 年のブログ記事よりも、react.dev の公式ドキュメントのほうが信頼できます。それでも、検索エンジンではブログ記事のほうが上位に表示される場合があります。

2. 最新性を確認する

変化の速いトピック（フレームワーク、API、ツール、セキュリティ）については、情報を信頼する前にページの公開日／更新日を確認してください。およそ 2 年以上前のコンテンツは「古い可能性がある」とみなし、公式の現行バージョンのドキュメントで主張を検証します。

適用方法：webfetch の後、「最終更新日」、記事の日付、<time> タグを探します。日付がまったくないページは疑わしいものとして、鮮度が確認されるまでは古い情報として扱ってください。例外：公式の継続的に更新されるリファレンスドキュメントサイト（react.dev/reference/*、developer.mozilla.org、フレームワークの公式ドキュメント）にはページごとの日付がない場合がありますが、ベンダーによって最新の状態に保たれています。現行バージョンの権威ある情報源として扱ってください。特定のマイナーバージョンに限定する必要がある場合は、ページのバージョンセレクターまたはプロジェクトの変更履歴を確認します。 重要な理由：2021 年の記事では Node.js v16 の挙動が説明されていますが、v22 では API が変更されている可能性があります。

3. 重要な主張を複数の情報源で検証する

自明ではない主張（挙動に関する断言、パフォーマンス数値、セキュリティに関する記述、互換性に関する主張、「ベストプラクティス」に関する意見）を事実として伝える前に、独立した情報源を 2 つ以上確認してください。

より厳格な基準：その主張が意思決定に影響する場合（どのライブラリをインストールするか、何かをどう設計するか、あるアプローチが安全かどうか）は、自明ではありません。複数の情報源で検証してください。自明な事実（構文、パラメーター名、型シグネチャ）であれば、権威ある情報源を 1 つ確認するだけで十分です。

適用方法：1 つの情報源だけが重要な主張をしている場合は、裏付けを得るために 2 回目の検索を行います。ほぼ同じ表現の 2 つのサイトは、独立した情報源とはみなしません（一方が他方を転載した可能性が高いためです）。独立した論拠または一次証拠を探してください。 重要な理由：1 つの誤ったブログ記事が複数のまとめサイトで繰り返されると、「誰もがそう言っている」という誤解が生まれます。

4. コンテンツファームを避ける

アグリゲーター／スクレイピングサイト、AI 生成の SEO ファーム、単なるコピーコンテンツ、広告だらけの低品質ページ、著者名も日付もない水増しコンテンツを見分け、優先度を下げます。

適用方法：検索上位が、知名度の低いドメインにある内容の薄い類似ページばかり10件の場合は、公式ソースか、信頼できる英語の権威ある情報源に切り替えます。 重要な理由：コンテンツファームは正確さではなく検索順位を高めるために最適化されており、検索結果をますます汚染しています。

系 — 引用の衛生管理

外部の調査結果を伝えるときは、ユーザーがワンクリックで確認できるよう、**ソースのリンク＋（日付）**を添えます。

「React 19 の use フックは条件分岐の中で呼び出せます（react.dev、2024-12）。」

これは4つの原則から自然に導かれる出力であり、5つ目のルールではありません。

---

厳格モード — 7次元のソース評価＋レポート

ユーザーが厳密な調査を明示的に求めている場合（「严格调研」「深度调研」「严格查证」「严谨调研」／「strict research」「deep research」「fact-check」）、かつ対象が外部情報である場合（ステップ0で確認）に適用します。結論が重要な場合（技術選定、セキュリティ上の判断、実際の行動につながる主張）に使用します。

ユーザーが厳格な調査を求めていても、対象が内部コード（例：「严格分析我们 auth 模块的实现」）の場合、このスキルは適用しません。内部の詳細分析は別のタスクです。代わりに、explore／debug-workflow／コードレビュー用ツールに引き継ぎます。

厳格モードにはデフォルトモードが含まれます（検索フェーズでは引き続き4つの原則に従います）。さらに、体系的な評価を追加します。

7つの次元（CRAAP と E-E-A-T を統合）

2つのフレームワークには重複する部分があり、統合すると、異なる7つの次元になります。E-E-A-T の**信頼性（Trust）**は統合的な評価であり、独立した評価軸ではありません。

#	次元	問い
1	権威性	誰が公開していますか。その立場や評判はどうですか。
2	専門性	著者にはどのような資格がありますか。
3	経験	実践に基づく一次的な証拠が示されていますか。
4	最新性	いつ公開／更新されましたか。現在のバージョンに合っていますか。
5	正確性	検証可能ですか。引用はありますか。相互確認されていますか。
6	目的／偏り	何のために作成されましたか。商業的／思想的な偏りはありますか。
7	関連性	質問に直接答えていますか。

各次元を具体的な基準に基づいて 高／中／低 で評価します。全評価基準は reference.md に記載されており、このファイルを簡潔な判断資料に保っています。総合評価は 信頼できる／注意が必要／信頼できない です。

ワークフロー

1. 分解 — 調査の問いを、検証可能な主張に分解します。
2. 検索 — デフォルトモードの4つの原則に従って検索します。十分な情報が集まったら検索を終了します。セキュリティ／安全性が重要な結論では、独立した一次情報源が2つ以上一致している必要があります。通常の主張では、明らかな抜けがなく、各主張を網羅できるだけの情報源を集めます。
3. 評価 — 各情報源を7つの次元で評価し、総合的な信頼性を付与します。
4. 主張ごとに統合 — 複数の情報源で評価が高い主張、単一の情報源による主張、相互に矛盾する主張を整理します。セキュリティ／安全性が重要な主張を「強い／信頼できる」と評価するには、権威性＋正確性が複数の情報源で高評価であることを必須とします（通常の主張より基準が厳しくなります）。
5. レポートを作成 — 以下のテンプレートを使用します。
6. 不足点を明示 — 追加確認が必要な点、情報源間で見解が異なる点を示します。

レポートのテンプレート

# Strict research report: <topic>

## Research question
<the specific question, including version/context>

## Source evaluation

### Source 1: <title> (<URL>, <date>)
- Authority: H/M/L — <basis>
- Expertise: ...
- Experience: ...
- Currency: ...
- Accuracy: ...
- Purpose/Bias: ...
- Relevance: ...
- **Verdict**: Trustworthy / Cautious / Unreliable

### Source 2: ...

## Claims & confidence
- <claim 1>: ✅ Strong (multi-source High) — Sources 1, 2
- <claim 2>: ⚠️ Moderate (single source or Med) — Source 3, suggest follow-up
- <claim 3>: ❌ Disputed (Low or sources conflict) — Source 4 vs 5 contradict

## Gaps & next steps
- Still needed: <what's missing>
- Unresolved conflicts: <where sources disagree>

実際の質問を想定した、詳細な記入例（厳格モードのレポート例）は reference.md にあります。

---

落とし穴（見落としやすいもの）

• 「公式」が必ずしもベンダーのサイトとは限りません。 オープンソースの場合、信頼できる一次情報は、マーケティング用の .com ではなく、GitHub リポジトリの README／docs フォルダーや RFC にあることがあります。「公式」が何を指すかは、プロジェクト自身が正確な情報を公開している場所に合わせてください。
• 1 つのページ内でバージョンが混在しています。 1 つのドキュメントページで複数のメジャーバージョンを扱っていることがあります。引用するスニペットが非推奨のセクションではなく、ユーザーが使用しているバージョンについて説明していることを確認してください。ページのバージョンセレクターやバナーを確認しましょう。
• 日付のないページが、常に最新とは限りません。 日付がなくても時代を問わないページ（仕様、アルゴリズム）はありますが、日付のないウェブコンテンツの多くは、単に更新が放置されているだけです。動きの速いトピックでは、日付のない情報は古いものとして扱ってください。
• StackOverflow の高評価の回答は、10 年前のものかもしれません。 投票数が示すのは過去の有用性であり、現在の正確さではありません。必ず日付を確認し、現行バージョンで検証してください。
• 2 つの情報源が、実は同じ出どころである場合があります。 ブログ B がブログ A を引用しているなら、両者は独立した情報源ではありません。独立していると言えるのは、別個の根拠や別個の一次資料に基づいている場合です。
• AI が生成した検索サマリーは、情報源ではなく複数情報の集約です。 Google AI Overviews、Perplexity、Bing Copilot などは、他のページの情報を統合しているため、便利な出発点にはなりますが、二次情報です。AI サマリーだけを根拠とする主張を伝える前に、サマリーが引用している根本の一次情報をたどってください。引用元がない場合は、単一の情報源として扱い、別の情報源で検証してください。
• 同じパッケージ名でも、エコシステムが異なることがあります。 エコシステム間でパッケージ名が重複することがあります。たとえば、jsonwebtoken（npm）と jsonwebtoken（Rust クレート、Keats/jsonwebtoken）、jwt-go と golang-jwt です。検索結果やセキュリティアドバイザリにパッケージが記載されている場合、対象と照合する前にエコシステムのフィールド（npm/cargo/go/pypi）を確認してください。Rust クレートの CVE は npm ユーザーには関係なく、その逆も同様です。
• デフォルトモードは、ユーザーに見せる事前チェックリストではありません。 これは、表に出さない行動上の規律です。「原則 2 を適用しています」などと説明せず、そのまま実行して、適切に出典を示してください。

---

参考資料

全資料（7 つのディメンションに関する High／Med／Low の完全な評価基準、拡張版の strict mode レポートテンプレート、具体例）は reference.md にあります。strict mode の評価基準が必要な場合や、ディメンションの判断が曖昧な場合に参照してください。