websearch-deep

Name: websearch-deep
Author: thomasholknielsen

github.com/thomasholknielsen生産性128 回インストール

リポジトリ

websearch-deep について

websearch-deepは、複数分野の情報を統合する複雑な調査向けのスキルです。問いの分解、複数クエリの計画、根拠の評価と統合、反復的な改善を行います。

主な機能

01調査課題の分解
02複数検索クエリの計画
03根拠の評価と統合
04調査結果の反復的な改善
05引用の透明性を重視

活用シーン

01アーキテクチャやアルゴリズムの比較
02市場やベンダーの分析
03政策や技術動向の調査

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/thomasholknielsen/claude-code-config --skill websearch-deep

インストール後、Claude Code で/websearch-deepを入力して読み込まれたか確認します。

詳細

ディープウェブ調査戦略

⚠️ 検証に関する指示（デバッグ用の暫定措置）：

このスキルを使用する際は、実行を証明するための検証ファイルを必ず作成してください。

ファイル：deep-research-skill-was-executed.md（リポジトリのルート）

内容：

# Deep Research Skill Execution Verification

**Skill**: websearch-deep
**Executed**: {timestamp}
**Research Question**: {the question you researched}
**Mode**: Deep (6-phase methodology)

This file was created by the deep-researcher agent to verify that the websearch-deep Skill was successfully loaded and executed.

**Phases Applied**:
1. ✓ Problem Decomposition (3-5 sub-questions)
2. ✓ Multi-Query Generation (3-5 variations per sub-question)
3. ✓ Evidence Synthesis with Source Ranking (credibility/freshness/relevance)
4. ✓ Citation Transparency (numbered [1][2][3])
5. ✓ Structured Output (token-efficient template)
6. ✓ Iterative Refinement (max 5 iterations)

**Sub-Questions Generated**: {count}
**Queries Executed**: {count}
**Sources Consulted**: {count} ({authoritative_count} authoritative, {recent_count} recent)
**Iterations Performed**: {count}

**Output Format**: Token-efficient template (Executive Summary + Research Overview + Findings + Synthesis + Recommendations + Sources with URLs)

このスキルを読み込んだ直後に、Write ツールを使ってこのファイルを作成してください。

このスキルでできること

複数の領域にまたがる統合を必要とする、複雑で多面的な質問に対し、包括的なディープリサーチの方法論を提供します。問題の分解、複数クエリ戦略、エビデンスの統合、引用の透明性、反復的な改善を用いて、ChatGPT 形式の詳細な調査を実施します。

このスキルを使用する場面

幅広い用途：技術、ビジネス、教育、戦略、調査のいずれであっても、複数の情報源を用いた包括的な分析とエビデンスの統合が必要なあらゆる質問にこのスキルを使用してください。

対応する質問の種類：

✅ 技術：アーキテクチャの決定、アルゴリズム、ベストプラクティス、テクノロジーの選定
✅ ビジネス：市場分析、競合調査、ベンダー比較、トレンド
✅ 教育：学習リソース、概念の説明、方法論ガイド
✅ 戦略：テクノロジーロードマップ、ポリシー分析、意思決定フレームワーク
✅ 調査：根本原因分析、インシデント調査、パターンの特定
✅ 非技術：リモートワークの方針、組織構造、プロセスの改善

質問の例：

「X と Y を統合するのに最適なアーキテクチャは何ですか？」（技術）
「マイクロサービスとモノリスのどちらを使うべきですか？」（戦略）
「リモートワークの方針にはどのようなメリットがありますか？」（ビジネス／非技術）
「素数生成アルゴリズムにはどのような違いがありますか？」（教育／技術）
「クラウドベンダーの選定にあたって、どのような要因を考慮すべきですか？」（ビジネス／戦略）

トリガー：「architecture」、「integration」、「best」、「strategy」、「recommendations」、「compare」、「evaluate」、「migrate」、「benefits」、「how」、「why」、「should we」などのキーワード

重要な判断基準：複数の情報源を用いた包括的な分析とエビデンスの統合が質問に必要な場合は、このスキルを使用してください。

手順

フェーズ 1：問題の分解

目的：複雑な質問を、焦点の明確な 3～5 個の小さな質問に分解します。

🔴 重要 — 調査範囲：

ディープリサーチで調べられるのは外部の知識のみであり、コードベースにはアクセスできません。

調査できる内容：

✅ 公式ドキュメント：ベンダーのウェブサイト（anthropic.com、docs.microsoft.com など）
✅ ブログ記事と記事：技術ブログ、Medium、Dev.to、エンジニアリングブログ
✅ コミュニティリソース：Stack Overflow、GitHub のディスカッション、Reddit、フォーラム
✅ 業界のベストプラクティス：デザインパターン、アーキテクチャパターン、標準的なアプローチ
✅ 学術論文：研究論文、ホワイトペーパー、学会の議事録
✅ ライブラリのドキュメント：Context7 MCP 経由（ライブラリを解決 → ドキュメントを取得）
✅ ウェブコンテンツ：Fetch MCP 経由で HTML コンテンツを取得

調査できない内容：

❌ プロジェクト内部のファイル：Read／Grep／Glob ツールは利用できません
❌ コードベースのパターン：代わりに /explain:architecture または research-codebase-analyst を使用してください
❌ プロジェクト固有の実装：外部調査の範囲外です

質問が「自分のプロジェクト」または「このコードベース」について尋ねている場合：エージェントファイルのスコープ検証セクションからエラーを返し、処理を停止してください。

手順：

主な調査質問を特定します
質問の構造と意図を分析します
質問全体に答えられるよう、論理的な小項目に分解します

小項目の基準：

具体的：それぞれの範囲が明確で、焦点が定まっている
網羅的：すべて合わせて質問全体をカバーする
独立している：個別に調査できる
実行可能：具体的な調査結果につながる

分解の例：

Primary: "What's the best architecture for integrating Salesforce with SQL Server in 2025?"

Sub-Questions:
1. What are Salesforce's current integration capabilities and APIs (2025)?
2. What are SQL Server's integration patterns and best practices?
3. What middleware or integration platforms are commonly used?
4. What security and compliance considerations matter?
5. What scalability and performance factors should influence choice?

フェーズ 2：複数クエリの生成

目的：サブ質問ごとに3～5種類のクエリを生成し、網羅性を最大限に高めます（検索合計15～25件）。

クエリのバリエーション戦略：

バリエーション 1 - 広範／一般的：「Salesforce integration APIs 2025」
バリエーション 2 - 具体的／技術的：「Salesforce REST API bulk data operations」
バリエーション 3 - 比較／代替案：「Salesforce API vs MuleSoft vs Dell Boomi」
バリエーション 4 - ベストプラクティス：「Salesforce SQL Server integration patterns」
バリエーション 5 - 最新情報：「Salesforce API updates 2025」

高度な検索演算子：

site:domain.com - 特定のドメインを検索
filetype:pdf - PDF ドキュメントを検索
intitle:"keyword" - ページタイトルを検索
inurl:keyword - URL を検索
after:2024 - 最近のコンテンツのみ
"exact phrase" - 完全一致

複数クエリセットの例：

Sub-Q1: Salesforce Integration Capabilities
  - site:salesforce.com "API" "integration" "2025"
  - "Salesforce REST API" "rate limits" after:2024
  - "Salesforce Bulk API 2.0" "best practices"
  - filetype:pdf "Salesforce integration guide" 2025
  - "Salesforce API" "breaking changes" after:2024

一般的な調査タイプ向けのクエリテンプレート

次のテンプレートを使って、調査タイプに応じた質の高いクエリを作成してください：

1. 技術アーキテクチャの調査

Official Docs: site:docs.{vendor}.com "{topic}" "architecture patterns" OR "design patterns"
Best Practices: "{topic}" "best practices" "production" after:2024
Comparisons: "{topic}" vs "{alternative}" "comparison" "pros cons"
Limitations: "{topic}" "limitations" OR "drawbacks" OR "challenges"
Recent Updates: site:{vendor}.com "{topic}" "updates" OR "changes" after:2024

2. フレームワーク／ライブラリの調査

Official Docs: site:docs.{framework}.com "{feature}" "guide" OR "documentation"
Community: site:stackoverflow.com "{framework}" "{feature}" "how to"
Real-World: "{framework}" "{feature}" "production" OR "case study" after:2024
Performance: "{framework}" "performance" OR "benchmarks" OR "optimization"
Ecosystem: "{framework}" "ecosystem" OR "plugins" OR "extensions" 2025

3. ビジネス／戦略の調査

Industry Analysis: "{topic}" "market analysis" OR "industry trends" 2024 2025
Vendor Comparison: "{vendor A}" vs "{vendor B}" "comparison" "review"
ROI/Benefits: "{solution}" "ROI" OR "benefits" OR "value proposition"
Implementation: "{solution}" "implementation guide" OR "getting started"
Case Studies: "{solution}" "case study" OR "customer success" after:2024

4. 教育／学習に関する調査

Fundamentals: "{topic}" "introduction" OR "beginner guide" OR "explained"
Advanced: "{topic}" "advanced" OR "deep dive" OR "internals"
Tutorials: "{topic}" "tutorial" OR "step by step" after:2024
Common Mistakes: "{topic}" "common mistakes" OR "anti-patterns" OR "pitfalls"
Resources: "{topic}" "learning resources" OR "courses" OR "books" 2025

5. コンプライアンス／セキュリティの調査

Standards: "{topic}" "{standard}" "compliance" (e.g., "GDPR", "SOC2", "HIPAA")
Security: "{topic}" "security" "best practices" OR "vulnerabilities" after:2024
Official Guidance: site:{regulator}.gov "{topic}" "guidance" OR "requirements"
Audit: "{topic}" "audit" OR "checklist" OR "certification"
Tools: "{topic}" "{compliance}" "tools" OR "automation" 2025

6. パフォーマンス／最適化の調査

Benchmarks: "{topic}" "benchmark" OR "performance" "comparison" after:2024
Bottlenecks: "{topic}" "bottleneck" OR "slow" OR "performance issues"
Optimization: "{topic}" "optimization" OR "tuning" OR "best practices"
Monitoring: "{topic}" "monitoring" OR "observability" OR "metrics"
Scaling: "{topic}" "scalability" OR "high traffic" OR "production scale"

優先事項：まず公式ソースを確認する

常に site:anthropic.com または site:docs.{vendor}.com のクエリを最初に実行します
公式ドキュメントの検索結果を使って、コミュニティやブログ向けのクエリを改善します
公式のガイダンスを実際の利用経験と照合します

🔴 重要：クエリを並列バッチで実行する

実行パターン（パフォーマンス向上のため必須）：

クエリを順番に（1件ずつ）実行しないでください。代わりに、5～10件のグループに分け、1つのメッセージ内で並列実行してください。

バッチ処理の戦略：

すべてのサブ質問について、最初に15～25件のクエリをすべて生成します
クエリを5～10件ずつのバッチにまとめます
各バッチを、複数の WebSearch ツール呼び出しを含む1つのメッセージで実行します
バッチが完了するまで待ってから、次のバッチに進みます

実装パターン：

# Step 1: Generate all queries first
all_queries = []
for sub_question in sub_questions:
    queries = generate_query_variations(sub_question)  # 3-5 queries per sub-Q
    all_queries.extend(queries)
# Total: 15-25 queries across all sub-questions

# Step 2: Execute in parallel batches
batch_size = 5  # Adjust 5-10 based on query complexity
for i in range(0, len(all_queries), batch_size):
    batch = all_queries[i:i+batch_size]

    # Step 3: Execute ALL queries in batch SIMULTANEOUSLY in single message
    # Example: If batch = [q1, q2, q3, q4, q5], call:
    #   WebSearch(q1)
    #   WebSearch(q2)
    #   WebSearch(q3)
    #   WebSearch(q4)
    #   WebSearch(q5)
    # ALL FIVE in the SAME message as parallel tool uses

    results = execute_parallel_batch(batch)
    process_batch_results(results)  # Collect sources immediately

これが重要な理由：

逐次実行：25件のクエリ × 各1秒 = 合計25秒
バッチ実行（1バッチ5件）：5バッチ × 1秒 = 合計5秒
速度向上：フェーズ 2 で3～5倍高速

バッチサイズの目安：

単純なクエリ（キーワードのみ）：batch_size=10 を使用
複雑なクエリ（高度な演算子、複数の site: フィルター）：batch_size=5 を使用
2回目以降の反復での再検索：batch_size=3-5 を使用

バッチ実行の例：

Generated 25 queries across 5 sub-questions

Batch 1 (5 queries - executed in parallel):
  WebSearch("site:salesforce.com 'API' 'integration' '2025'")
  WebSearch("'Salesforce REST API' 'rate limits' after:2024")
  WebSearch("'Salesforce Bulk API 2.0' 'best practices'")
  WebSearch("filetype:pdf 'Salesforce integration guide' 2025")
  WebSearch("'Salesforce API' 'breaking changes' after:2024")
→ Batch completes in ~1s, 5 results returned

Batch 2 (5 queries - executed in parallel):
  WebSearch("'SQL Server ETL' 'best practices' 'real-time'")
  WebSearch("site:docs.microsoft.com 'SQL Server' 'integration'")
  ...
→ Batch completes in ~1s, 5 results returned

Total: 5 batches × 1s each = ~5s (vs 25s sequential)

フェーズ 3：エビデンスの統合

目的：複数のソースからエビデンスを収集し、順位付け、重複排除、統合します。

バッチ処理した結果の処理：

フェーズ 2 ではクエリを並列バッチで実行したため、結果はバッチごとにまとめられています。すべてのバッチの結果をまとめて処理します。

結果をフラット化：バッチ 1 + バッチ 2 + バッチ 3 + ... → 1つの統合された結果リスト
重複排除：すべてのバッチにわたって重複する URL を削除します（同じソースが複数のクエリに現れることがあります）
すべてのソースを順位付け：バッチごとではなく、フラット化した完全なリストに0～10のスコアを適用します
統合に進む：エビデンスの統合には、統一され、重複排除され、順位付けされたソースリストを使用します

例：

# Collect results from all batches
all_results = []
all_results.extend(batch1_results)  # 5 results from batch 1
all_results.extend(batch2_results)  # 5 results from batch 2
all_results.extend(batch3_results)  # 5 results from batch 3
all_results.extend(batch4_results)  # 5 results from batch 4
all_results.extend(batch5_results)  # 5 results from batch 5
# Total: ~25 results (before deduplication)

# Deduplicate by URL
unique_sources = deduplicate_by_url(all_results)
# After dedup: ~15-20 unique sources (duplicates removed)

# Rank all unique sources
ranked_sources = rank_sources(unique_sources)  # Apply scoring below

3a. ソースの評価（0～10 段階）

各ソースを次の3つの観点で評価します。

信頼性スコア（0～10）：

10：公式ドキュメント、査読済み論文
7～9：定評のある技術系メディア（TechCrunch、Ars Technica）、信頼できるベンダー
4～6：技術ブログ、Stack Overflow、コミュニティフォーラム
1～3：未検証のソース、マーケティングコンテンツ、個人ブログ

鮮度スコア（0～10）：

10：過去3か月以内に公開
7～9：過去6～12か月以内に公開
4～6：過去1～2年以内に公開
1～3：2年以上前に公開

関連性スコア（0～10）：

10：具体例を挙げてサブクエスチョンに直接回答している
7～9：一部詳細を含め、サブクエスチョンに回答している
4～6：間接的に関連しており、解釈が必要
1～3：トピックに簡単に触れているだけで、有用性は最小限

ソースの総合品質 ＝（信頼性 × 0.5）＋（鮮度 × 0.2）＋（関連性 × 0.3）

3b. 重複の排除

ソース間で重複する調査結果を特定します
重複がある場合は、より品質の高いソース（総合スコア）を優先します
コンセンサスに注目します：3つ以上のソースが一致すれば、強い裏付けとなります
例外的な主張にフラグを付けます：単一のソースだけが独自の主張をしている場合

3c. 矛盾の解決

ソース間で矛盾がある場合：

日付を確認する：新しいソースには最近の変更が反映されている場合があります
権威性を評価する：公式ドキュメントはブログ記事より優先します
両方の見解を示す：「Source A [1] は X を推奨していますが、Source B [2] は……を理由に Y を提案しています」
背景を説明する：「適切な方法は規模によって異なります。レコード数が100k未満の場合は X [1]、1Mを超える場合は Y [2] を使用します」

Phase 4: 引用の透明性（クリック可能な形式）

目的：事実に関するすべての主張に、番号付きのクリック可能な引用を付けます。

🔴 重要 — 説明的なインラインリンクを使用する：

インライン引用の形式（説明的な名前 — 自然な言葉）：

Text with claim from [OpenAI: GPT-4](https://url "GPT-4 Technical Report (OpenAI, 2023-03-14)") and [Anthropic: Claude](https://url2 "Introducing Claude (Anthropic, 2023-03-14)"). Multiple sources: [Google DeepMind: Gemini](https://url3 "Gemini Model (Google DeepMind, 2023-12-06)"), [Meta: LLaMA](https://url4 "LLaMA Paper (Meta AI, 2023-02-24)").

説明的な名前を使う理由

✅ インラインでも読みやすく、自然な文章の流れを保てます
✅ 自己説明的です（参考文献を確認しなくても、読者がソースを把握できます）
✅ ツールチップ付きで引き続きクリックできます
✅ すべてのMarkdownビューア（GitHub、VS Code、Obsidian、GitLab、ターミナル）で動作します

形式：

[Organization: Topic](full-URL "Full Title (Publisher, YYYY-MM-DD)")

説明的な名前の作成方法（URLの分析に基づく）：

組織名を抽出する：ドメインから抽出します（openai.com → OpenAI、anthropic.com → Anthropic）
トピックを抽出する：URLのパスまたはタイトルから抽出します（gpt-4 → GPT-4、claude → Claude）
形式を使う：[Org: Topic]
重複する場合：説明的な接尾辞を追加します — [OpenAI: GPT-4]、[OpenAI: DALL-E]、[OpenAI: Whisper]
一般的なページの場合：ページの種類を使います — [Stack Overflow: OAuth Implementation]、[Medium: React Patterns]

参考文献セクションの形式（調査の最後 — カテゴリ別に分類）：

## References

### Official Documentation
- **OpenAI: GPT-4** (2023-03-14). "GPT-4 Technical Report". https://openai.com/research/gpt-4
- **Anthropic: Claude** (2023-03-14). "Introducing Claude". https://www.anthropic.com/claude

### Blog Posts & Articles
- **Google DeepMind: Gemini** (2023-12-06). "Gemini: A Family of Highly Capable Models". https://deepmind.google/technologies/gemini
- **Meta: LLaMA** (2023-02-24). "Introducing LLaMA". https://ai.meta.com/blog/llama

### Academic Papers
- **Attention Is All You Need** (2017-06-12). Vaswani et al. https://arxiv.org/abs/1706.03762

### Community Resources
- **Stack Overflow: OAuth Implementation** (2024-08-15). https://stackoverflow.com/questions/12345

参考文献セクションを分類する理由

ソースの種類ごとに整理された一覧を提示します
権威あるソースとコミュニティソースを簡単に見分けられます
根拠の多様性をひと目で把握できます
コピーして、さらに調査できます

カテゴリの指針：

公式ドキュメント：ベンダーのドキュメント、APIリファレンス、公式ガイド
ブログ記事・記事：企業のエンジニアリングブログ、Medium、Dev.to、技術記事
学術論文：arXiv、研究論文、学会論文、ホワイトペーパー
コミュニティリソース：Stack Overflow、GitHubのディスカッション、Reddit、フォーラム

引用符内のタイトル形式：

"Full Title (Publisher, YYYY-MM-DD)"
簡潔ながら説明的なタイトルにします（可能であれば80文字未満）
信頼性を担保するため、必ず発行元と日付を含めます

ホバー時の動作：ほとんどのMarkdownビューア（GitHub、VS Code、Obsidian、GitLab）では、引用にカーソルを合わせるとタイトルがツールチップとして表示されます。

クリック時の動作：説明的な名前をクリックすると、ブラウザーでURLが直接開きます。

インラインでの使用例：

Salesforce provides three primary API types according to [Salesforce: API Docs](https://developer.salesforce.com/docs/apis "Salesforce API Documentation (Salesforce, 2025-01-15)"): REST API for standard operations, [Salesforce: Bulk API 2.0](https://developer.salesforce.com/docs/atlas.en-us.api_asynch.meta/api_asynch/ "Bulk API 2.0 Guide (Salesforce, 2024-11-20)") for large data volumes (>10k records), and [Salesforce: Streaming API](https://developer.salesforce.com/docs/atlas.en-us.api_streaming.meta/api_streaming/ "Streaming API Guide (Salesforce, 2024-10-05)") for real-time updates. Recent 2025 updates introduced enhanced rate limiting (100k requests/24hrs for Enterprise) and improved error handling as noted in [Salesforce Blog: API Updates](https://developer.salesforce.com/blogs/2025/01/api-updates "API Error Handling Improvements (Salesforce Blog, 2025-01-10)").

## References

### Official Documentation
- **Salesforce: API Docs** (2025-01-15). "Salesforce API Documentation". https://developer.salesforce.com/docs/apis
- **Salesforce: Bulk API 2.0** (2024-11-20). "Bulk API 2.0 Developer Guide". https://developer.salesforce.com/docs/atlas.en-us.api_asynch.meta/api_asynch/
- **Salesforce: Streaming API** (2024-10-05). "Streaming API Developer Guide". https://developer.salesforce.com/docs/atlas.en-us.api_streaming.meta/api_streaming/

### Blog Posts & Articles
- **Salesforce Blog: API Updates** (2025-01-10). "API Error Handling Improvements". https://developer.salesforce.com/blogs/2025/01/api-updates

互換性：GitHub、VS Code（プレビュー）、Obsidian、GitLab、およびすべてのMarkdownビューアで動作します

フェーズ 5：構造化された出力（バランス型 - 目標 250〜350 行）

目的：ナラティブに深みを持たせ、包括的で実装にすぐ活用できる調査結果を提供します。

設計原則：

✅ 深さのバランスを取る（250〜350 行）—冗長すぎず、過度に簡潔でもない
✅ リポジトリに依存しない（特定のリポジトリの詳細を含めない）
✅ 実装にすぐ活用できる（エグゼクティブサマリーと推奨事項で次のステップを案内）
✅ 完全な URL を含む出典（必須）
✅ 汎用的（技術、ビジネス、教育、戦略など、あらゆる質問に対応）

出力テンプレート：

# Deep Research: {Question}

## Executive Summary

{2-3 paragraph synthesis covering:
- What was researched and why it matters
- Key findings with citations [Org: Topic]
- Strategic recommendation with rationale}

Example length: ~150-200 words total across 2-3 paragraphs.

## Research Overview

- **Sub-Questions Analyzed**: {count}
- **Queries Executed**: {count} queries
- **Sources**: {count} total ({authoritative_count} authoritative / {auth_pct}%, {recent_count} recent / {recent_pct}%)
- **Iterations**: {count}

## Findings

### 1. {Sub-Question 1}

{Opening paragraph: What this sub-question addresses and why it's important}

{2-4 paragraphs of synthesized narrative with inline citations [1][2][3]. Each paragraph covers a specific aspect or theme. Include:
- Core concepts and definitions with citations
- How different sources approach the topic
- Practical implications and examples
- Performance characteristics or trade-offs where relevant}

**Key Insights**:
- {Insight 1: Specific, actionable statement} - {Why it matters and implications} [Org: Topic], [Org: Topic]
- {Insight 2: Specific, actionable statement} - {Why it matters and implications} [Org: Topic]
- {Insight 3: Specific, actionable statement} - {Why it matters and implications} [Org: Topic]

{Optional: **Common Patterns** or **Best Practices** subsection if relevant with 2-3 bullet points}

### 2. {Sub-Question 2}

{Repeat the same structure: Opening paragraph + 2-4 narrative paragraphs + 3-5 Key Insights}

{...continue for all sub-questions...}

## Synthesis

{2-3 paragraphs integrating findings across sub-questions. Show how the pieces fit together and what the big picture reveals.}

**Consensus** (3+ sources agree):
- {Consensus point 1 with source count} [Org: Topic], [Org: Topic], [Org: Topic]
- {Consensus point 2 with source count} [Org: Topic], [Org: Topic], [Org: Topic], [Org: Topic]

**Contradictions** *(if present)*:
- **{Topic}**: {Source A perspective [Org: Topic]} vs {Source B perspective [Org: Topic]}. {Resolution or context explaining difference}

**Research Gaps** *(if any)*:
- {Gap 1}: {What wasn't found and why it matters}

## Recommendations

### Critical (Do First)
1. **{Action}** - {Detailed rationale explaining why this is critical, what happens if not done, and expected impact} [Org: Topic], [Org: Topic]

2. **{Action}** - {Detailed rationale} [Org: Topic]

3. **{Action}** - {Detailed rationale} [Org: Topic]

### Important (Do Next)
4. **{Action}** - {Rationale with evidence and expected benefit} [Org: Topic]

5. **{Action}** - {Rationale with evidence} [Org: Topic]

6. **{Action}** - {Rationale with evidence} [Org: Topic]

### Optional (Consider)
7. **{Action}** - {Rationale and when/why you might skip this} [Org: Topic]

8. **{Action}** - {Rationale} [Org: Topic]

## References

### Official Documentation
- **{Org: Topic}** ({YYYY-MM-DD}). "{Full Title}". {Full URL}
- **{Org: Topic}** ({YYYY-MM-DD}). "{Full Title}". {Full URL}

### Blog Posts & Articles
- **{Org: Topic}** ({YYYY-MM-DD}). "{Full Title}". {Full URL}

### Academic Papers
- **{Paper Title}** ({YYYY-MM-DD}). {Authors}. {Full URL}

### Community Resources
- **{Platform: Topic}** ({YYYY-MM-DD}). {Full URL}

長さの目安：

エグゼクティブサマリー：150〜200 語
各調査結果セクション：300〜400 語（導入＋ナラティブ＋洞察）
統合：200〜250 語
推奨事項：詳細な根拠を添えた重要度「Critical」3 件＋「Important」3〜4 件＋「Optional」2〜3 件
合計目標：250〜350 行

要件：

エグゼクティブサマリー：30 秒未満で把握でき、全体像が伝わること
調査結果：各セクションにナラティブ形式の段落を 2〜4 個含め、さらに「主な洞察」の箇条書きを 3〜5 個含めること
ナラティブ形式の段落では、概念を説明し、根拠を示し、関連性を明らかにすること
主な洞察は、実行可能な要点を抽出すること
統合：全体像を示し、合意点（出典数を含む）に触れ、矛盾点を検討すること
推奨事項：箇条書きと引用だけで済ませず、それぞれに詳細な根拠を示すこと
出典：タイトル、著者／組織、日付とともに、完全な URL を必ず記載すること

含めないもの（トークンの無駄遣い）：

❌ 数値スコア（0〜10 評価）付きの根拠表
❌ リポジトリ固有の詳細（「Main Thread Log」、「CARE quality score」など）
❌ 独立した長所／短所セクション（推奨事項に組み込む）
❌ 冗長な反復ログや、詳細すぎる方法論の手順

フェーズ 6：反復的な改善

目的：完全性を検証し、不足部分を再検索します（最大 5 回の反復）。

完全性検証チェックリスト：

すべてのサブクエスチョンについて、3 件以上の出典を引用した調査結果があるか？
矛盾点を特定して説明しているか？（ない場合は、「矛盾は見つかりませんでした」と明記）
新しい出典（過去 6〜12 か月以内）が含まれているか？
権威ある出典（公式ドキュメント）を優先しているか？
実践的な推奨事項（重要度「Critical」3 件＋「Important」3〜4 件＋「Optional」2〜3 件）を提示しているか？
調査の不足点を明記しているか？

不足の自動検出ロジック：

gaps = []
completeness_score = 100

# Check citation coverage
for sub_q in sub_questions:
    citation_count = count_citations(sub_q)
    if citation_count < 3:
        gaps.append(f"Sub-Q{i}: Only {citation_count} citations (need 3+)")
        completeness_score -= 10

# Check for contradictions exploration
if contradictions_section_empty():
    gaps.append("No contradictions explored - search for '{topic} criticisms' OR '{topic} limitations'")
    completeness_score -= 10

# Check authoritative source coverage
auth_sources = count_authoritative_sources()  # credibility >= 8
if auth_sources < total_sources * 0.5:
    gaps.append(f"Only {auth_sources} authoritative sources ({round(auth_sources/total_sources*100)}%) - need 50%+")
    completeness_score -= 10

# Check recency
recent_sources = count_recent_sources()  # within 6 months
if recent_sources < total_sources * 0.3:
    gaps.append(f"Only {recent_sources} recent sources ({round(recent_sources/total_sources*100)}%) - need 30%+")
    completeness_score -= 5

# Check recommendation depth
if critical_recommendations < 3:
    gaps.append(f"Only {critical_recommendations} Critical recommendations (need 3)")
    completeness_score -= 10

# Check for research gaps section
if research_gaps_section_missing():
    gaps.append("Research Gaps section missing - document what wasn't found")
    completeness_score -= 5

return completeness_score, gaps

再検索の判断ロジック：

iteration_count = 1
completeness_score, gaps = validate_completeness()

# 🔴 MANDATORY: Always perform minimum 2 iterations
# Even if iteration 1 achieves 85%+, iteration 2 improves depth
if iteration_count < 2 or (completeness_score < 85% and iteration_count <= 5):
    # Generate targeted re-queries for each gap
    requery_list = []

    for gap in gaps:
        if "citations" in gap:
            # Need more sources for specific sub-question
            requery_list.append(f"'{sub_question_topic}' 'detailed guide' OR 'comprehensive overview'")

        elif "contradictions" in gap:
            # Need to explore downsides/criticisms
            requery_list.append(f"'{topic}' 'criticism' OR 'limitations' OR 'downsides'")
            requery_list.append(f"'{topic}' 'vs' 'alternative' 'when not to use'")

        elif "authoritative" in gap:
            # Need more official sources
            requery_list.append(f"site:docs.{vendor}.com '{topic}' 'official'")
            requery_list.append(f"site:{vendor}.com '{topic}' 'documentation'")

        elif "recent" in gap:
            # Need more recent sources
            requery_list.append(f"'{topic}' 'updates' OR 'changes' after:2024")
            requery_list.append(f"'{topic}' '2025' OR '2024' 'latest'")

    # Execute re-queries in parallel batch (1-5 queries)
    # Use smaller batch size for re-queries since they're targeted
    requery_batch = requery_list[:5]  # Up to 5 re-queries

    # Execute ALL re-queries in batch SIMULTANEOUSLY in single message
    # Example: If requery_batch = [rq1, rq2, rq3], call:
    #   WebSearch(rq1)
    #   WebSearch(rq2)
    #   WebSearch(rq3)
    # ALL THREE in the SAME message as parallel tool uses
    execute_parallel_batch(requery_batch)
    iteration_count += 1

    # Update findings incrementally
    append_iteration_findings()
    completeness_score, gaps = validate_completeness()

else:
    # Either complete (≥85%) or max iterations reached
    if completeness_score < 85%:
        note_limitations_in_research_gaps_section(gaps)
    finalize_output()

反復時の更新パターン：後の反復で調査結果を追加する場合は、既存のセクションに追記します。

### 1. {Sub-Question}

{Original findings from iteration 1}

**Iteration 2 Additions**:
{New findings from re-queries, with citations [Org: Topic], [Org: Topic], [Org: Topic]}

**Key Insights**:
- {Original insight 1} [Org: Topic]
- {Original insight 2} [Org: Topic]
- {NEW insight from iteration 2} [Org: Topic], [Org: Topic]

反復を停止するタイミング：

🔴 必須：最低 2 回の反復（iteration_count >= 2）
✅ 完全性スコアが 85% 以上
✅ すべてのサブクエスチョンに 3 件以上の引用がある
✅ 矛盾点セクションが記入されている（または「特定なし」と明記されている）
✅ 権威ある出典が 50% 以上、新しい出典が 30% 以上
✅ 重要度「Critical」の推奨事項が 3 件以上
⏱️ または iteration_count > 5（反復回数の上限に到達）

次の場合にのみ停止します： (iteration_count >= 2 AND completeness >= 85%) OR iteration_count > 5

完全性が 85% に満たないまま反復回数の上限に達した場合：「調査の不足点」セクションを明示的に追加します。

## Research Gaps

Due to iteration limit, the following gaps remain:
- {Gap 1}: {What's missing and why it matters}
- {Gap 2}: {What's missing and suggested follow-up approach}

例

例 1：アーキテクチャ決定の調査

シナリオ：ユーザーが「2025 年に Salesforce を SQL Server と統合するには、どのアーキテクチャが最適ですか？」と質問します。

プロセス：

フェーズ 1 - 分解：

Sub-Q1: Salesforce integration capabilities (2025)?
Sub-Q2: SQL Server integration patterns?
Sub-Q3: Middleware options?
Sub-Q4: Security considerations?
Sub-Q5: Scalability factors?

フェーズ 2 - 複数クエリの生成と一括実行：

Generated 25 queries across 5 sub-questions

Batch 1 (5 queries - executed in parallel):
  WebSearch("site:salesforce.com 'API' 'integration' '2025'")
  WebSearch("'Salesforce REST API' 'rate limits' after:2024")
  WebSearch("'Salesforce Bulk API 2.0' 'best practices'")
  WebSearch("filetype:pdf 'Salesforce integration guide' 2025")
  WebSearch("'Salesforce API' 'breaking changes' after:2024")
→ Batch completes in ~1s, 5 results returned

Batch 2 (5 queries - executed in parallel):
  WebSearch("'SQL Server ETL' 'best practices' 'real-time'")
  WebSearch("site:docs.microsoft.com 'SQL Server' 'integration'")
  WebSearch("'SQL Server Always On' 'high availability'")
  WebSearch("'SQL Server CDC' 'change data capture'")
  WebSearch("'SQL Server linked servers' 'performance'")
→ Batch completes in ~1s, 5 results returned

Batch 3-5 (15 more queries across 3 batches):
  ... (middleware, security, scalability queries)
→ Each batch completes in ~1s

Execution Time:
- 5 batches × ~1s each = ~5s total
- Sequential would be: 25 queries × 1s = 25s
- Speedup: 5x faster

フェーズ 3 - 根拠：

18 sources identified
12 ranked as authoritative (credibility ≥ 8)
3 contradictions (real-time vs batch approaches)

フェーズ 4 - 引用：

[1] Salesforce API Guide (Cred: 10, Fresh: 10, Rel: 10, Overall: 10.0)
[2] MuleSoft Patterns (Cred: 9, Fresh: 8, Rel: 9, Overall: 8.9)

フェーズ 5 - 出力：

Executive Summary: 2 paragraphs
Findings: 5 sub-sections with 28 citations
Recommendations: 3 critical, 4 important, 2 enhancements

フェーズ 6 - 改善：

Iteration 1: Identified gap in disaster recovery
Iteration 2: Re-queried "Salesforce SQL backup strategies"
Iteration 3: Completeness 92% → finalized

出力：エグゼクティブサマリー、5 つのサブクエスチョンの分析、根拠の表、統合、長所／短所、28 件の引用を含む Deep Mode Context File

例 2：テクノロジー選定の調査

シナリオ：「E コマースプラットフォームには、マイクロサービスアーキテクチャとモノリシックアーキテクチャのどちらを採用すべきですか？」

プロセス：

分解：

1. Scalability characteristics for e-commerce?
2. Team size and DevOps implications?
3. Transaction patterns differences?
4. Deployment complexity trade-offs?
5. Real-world e-commerce case studies?

複数クエリ（サンプル）：

"microservices e-commerce" "scalability" after:2024
"monolith vs microservices" "team size" "best practices"
site:aws.amazon.com "e-commerce architecture" "patterns"

根拠の統合：

15 sources (10 authoritative)
Consensus: Team size <20 → monolith, >50 → microservices
Contradiction: Database approach (shared vs distributed)

出力：両方のアプローチの長所／短所、チーム規模に応じた推奨事項、移行時の考慮事項、引用付きの事例研究を含む構造化分析

ベストプラクティス

広く始めてから絞り込む：一般的なクエリから始め、最初の調査結果に基づいて詳細を掘り下げます
複数の情報源で検証する：単一の情報源に頼らず、重要な主張は3つ以上の情報源と照合します
新しさを優先する：テクノロジーに関するトピックでは、1年未満の情報源を優先します
公式ドキュメントを最初に確認する：まず公式ドキュメントを確認し、その後、コミュニティの知見で補足します
矛盾を記録する：相反する情報を隠さず、背景を添えて提示します
必要に応じて反復する：無理に網羅しようとせず、5回反復しても不足が残る場合は制約を記載します
引用を徹底する：すべての事実に関する主張に番号付きの引用を付けます

よくあるパターン

パターン1：アーキテクチャ決定の調査

次の項目に分解します：現状、要件、選択肢、トレードオフ、ケーススタディ
複数のクエリを実行します：公式ドキュメント、ベンダーの比較、実際の導入事例
統合します：引用付きのメリット・デメリット表

パターン2：テクノロジー移行の調査

次の項目に分解します：現行テクノロジーの評価、移行先テクノロジーの機能、移行経路、リスク分析、期間の見積もり
複数のクエリを実行します：移行ガイド、成功・失敗事例、ツールの比較
統合します：リスク軽減策を含む段階的な移行計画

パターン3：ベストプラクティスの調査

次の項目に分解します：業界標準、一般的なパターン、アンチパターン、ツール、ケーススタディ
複数のクエリを実行します：公式ガイドライン、専門家のブログ、カンファレンストーク、GitHub リポジトリ
統合します：根拠を添えた、統合済みのベストプラクティス一覧

トラブルシューティング

問題1：情報源が多すぎて統合できない

上位にランクされた情報源（総合スコア ≥ 7.0）に絞ります
情報源ごとではなく、テーマごとに調査結果を分類します
まず共通認識を特定し、その後、異なる見解を記載します

問題2：情報が矛盾している

公開日を確認します（新しい情報は最近の変更を反映している場合があります）
情報源の権威性を評価します（公式 > ブログ）
背景を確認します（矛盾はシナリオによって異なる可能性があります）
引用を付けて両方の見解を提示します

問題3：最近の情報源が不十分

対象期間を過去2年まで広げます
テクノロジーの名称変更を確認します（旧用語と新用語）
最近の情報源と、古くても権威のある情報源を組み合わせます
出力に次のように記載します：「2023年の情報源に基づいています。2025年の更新は未検証です」

問題4：網羅性スコアが85%未満

具体的な不足点を特定します（どのサブクエスチョンの深掘りが足りないか？）
対象を絞った再クエリを1～3件作成します
3回反復しても85%未満の場合は、制約を明記します

統合ポイント

WebSearch Tool：すべての検索クエリを WebSearch 経由で実行します
Context7 MCP：該当する場合、公式のフレームワーク／ライブラリのドキュメントで補足します
エビデンステーブル：品質評価のため、すべての情報源を構造化された形式で記録します
コンテキストファイル：調査結果を .agent/Session-{name}/context/research-web-analyst.md に保存します

主要用語

サブクエスチョン：主要な調査質問を構成する、焦点を絞った要素
クエリのバリエーション：同じ情報ニーズを異なる表現や切り口で尋ねること
情報源品質スコア：信頼性、新しさ、関連性を組み合わせた指標
コンセンサスビュー：独立した権威ある情報源3つ以上が裏付ける調査結果
矛盾：複数の情報源から示され、背景の確認が必要な相反する主張
網羅性スコア：十分なエビデンスをもって達成した調査目標の割合
反復：調査サイクル（クエリ → 収集 → 統合 → 検証）

追加リソース

Google 検索の高度な検索演算子：https://ahrefs.com/blog/google-advanced-search-operators/
情報源の評価基準：https://guides.library.cornell.edu/evaluate
引用のベストプラクティス：https://apastyle.apa.org/
調査結果の統合方法：https://methods.sagepub.com/book/systematic-approaches-to-a-successful-literature-review

Markdown 対応

ログインしてコメント

基本情報

作者: thomasholknielsen
リポジトリ: thomasholknielsen/claude-code-config
カテゴリ: 生産性
インストール数: 128

問題を報告