deep-research

ディープリサーチ

Gemini Deep Research 品質の成果物を作成します。スクリーンショット、mermaid 図、比較表、物語的な統合分析を埋め込んだ、充実した成果物です。フレームワークの選定、アーキテクチャパターン、依存関係の評価、競合分析など、開発者の意思決定に最適化されています。

このスキルを使う場面

• 「X の現在の状況を調査して」
• 「フレームワーク A とフレームワーク B を比較して」
• 「……に最適なアプローチは？」
• 「……を深く掘り下げて」
• 多くの情報源から情報を統合する必要があるあらゆる依頼

次の用途には使用しないでください：簡単な事実確認、単一の情報源に基づく回答、「CSS のボタンを探して」（代わりに design-lookup を使用してください）。

入力プロトコル — 検索を始める前に

1. トピックを 3～5 個の調査軸に分解します。
   • 例：「Next.js と Remix を比較」→ パフォーマンス、開発者体験、エコシステム、デプロイ、コミュニティ
2. 意思決定の背景を特定します。ユーザーが実際に決めようとしていることは何でしょうか？
   • フレームワークの選定？アーキテクチャパターン？内製か購入か？移行リスク？
3. 調査計画を作成します。予定している検索クエリとともに、3～5 個の調査軸を提示します。
   • 成果物として保存します（例：research_plan.md）。
   • 承認後に進めるか、ユーザーが範囲を変更した場合は調整します。

フェーズ 1：幅広い調査

目標：全体像を把握します。まずは何が存在するかを確認し、内容を読むのはその後です。

1. 異なる調査軸で、5～8 件の並列検索を実行します。少なくとも 2 つのツールを使用します。
   • search（Firecrawl）— トピック全般に関するクエリ
   • search_web（Google）— 異なる視点での検索
   • scrapeOptions を指定した search — 対象を絞った情報探索
2. 開発者向けの幅広い調査：
   • search_code または search_repositories — 関連する GitHub リポジトリを探します
   • パッケージを評価する際は、npm のトレンド、バンドルサイズ、ダウンロード数を検索します
   • 移行事例を検索します：「migrating from X to Y」の体験レポート
3. 候補 URL を 5 件ではなく15～25 件集めます。それぞれの信頼性を評価します（references/research-heuristics.md を参照）。
4. **検索結果のスニペットだけで判断しないでください。**スニペットは候補選定にのみ使用します。

出力：信頼性評価を付けた候補情報源の一覧。対話形式の場合はユーザーに提示し、自律的に進める場合はそのまま続行します。

フェーズ 2：詳細な読み込み

目標：実装の詳細、コード例、ベンチマーク、データなど、実際の内容を抽出します。

1. フェーズ 1 から上位 8～12 件の情報源を選びます（信頼性の高い S および A 評価を優先）。
2. 全内容を抽出して、ページ全体のコンテンツを取得します。
   • テキスト中心のページには scrape（Firecrawl）または read_url_content を使用します
   • ドキュメントが複数ページにわたる場合は、crawl（Firecrawl）で関連ページをたどります
   • 重要なページ（UI、ダッシュボード、アーキテクチャ図）は browser_subagent でスクリーンショットを撮影します
   • リポジトリの実際のソースコードを読むには get_file_contents（GitHub MCP）を使用します
3. 各情報源を分析します。
   • 具体的な主張、数値、パターン、コード例を抽出します
   • 信頼性の評価と、偏りがないかを記録します（フレームワーク自身による宣伝ではありませんか？）
   • 調査軸ごとに調査結果を分類します
4. 自己修正：情報源の内容が薄い場合（宣伝のみ、情報の乏しいチュートリアル、SEO 対策の水増し記事など）：
   • その情報源を破棄します
   • より具体的な語句を使って、条件を調整した追加検索を実行します
   • 「benchmark」「technical deep dive」「lessons learned」「postmortem」などを追加して検索してみます

出力：調査軸ごとに整理した、注釈付き情報源メモ。

フェーズ 3：統合

目標：調査ブリーフィング資料を作成します。これが主な成果物です。

1. references/report-templates.md からレポートテンプレートを選択します。
   • 包括的ブリーフ — 分野の全体像や最先端の調査向け
   • 比較ブリーフ — 直接比較による評価向け
2. 内容の充実した Markdown 資料としてレポートを作成します。
   • エグゼクティブサマリーは説明的な文章にします。箇条書きやリストではなく、技術リードに説明するように書きます。
   • ソースから抽出した実際のデータを用いた比較表
   • アーキテクチャ、意思決定ツリー、エコシステムマップを示すMermaid 図
   • フェーズ 2 で browser_subagent を使って取得したスクリーンショットの埋め込み
   • 実際のリポジトリやドキュメントから引用したコード例
   • スクリーンショットで概念を捉えられない場合は、カスタムの視覚化に generate_image を使用します。
3. すべての主張に出典を付けます。ソース URL へのリンクを本文中に記載します。形式は [Source Name](URL) を使用します。
4. ギャップ分析では、以下を明確に指摘します。
   • 判断できなかった内容とその理由
   • ソース間で情報が食い違っている点
   • 低ティアのソースしか見つからなかった領域

出力：調査資料（例：research_report.md）。

フェーズ 4：反復

目標：フェーズ 3 で特定したギャップを埋めます。

1. レポートのギャップ分析セクションを確認します。
2. 埋められるギャップごとに、以下を行います。
   • 改良した検索クエリで、対象を絞った検索を 1～2 回実行します。
   • 結果を抽出して読みます。
   • レポート資料をその場で更新します。
3. 反復は最大 3 回までです（フェーズ 1～3 が 1 回目となり、その後、対象を絞ったラウンドを最大 2 回追加できます）。
4. 最終反復後も残るギャップには、説明を添えて「未解決」と記載します。

エージェント型ワークフローとバイブコーディング

• 反復的な統合： 初稿から完璧で包括的なレポートができるとは限りません。最初の統合を作成し、抽出したデータと書式を確認して、具体的なギャップや壊れた図を特定します。セクションを 1 つずつ調整し、資料がブリーフィングの基準を満たすまで再生成します。
• バイブコーディング： 追加の詳細調査ループを開始する前に、作業中の Markdown レポートとローカルのスクリーンショットやアセットをコミットします。検索が脱線しても、構成の基盤を失わないようにします。

ツール戦略

用途	主なツール	代替ツール
トピックの発見	search（Firecrawl）	search_web
委任する詳細調査	search + scrape	手動で複数回検索
ページ全体の抽出	scrape（Firecrawl）	read_url_content
複数ページのドキュメント	crawl（Firecrawl）	search + 手動
視覚的な証拠	browser_subagent（スクリーンショット）	generate_image
GitHub の分析	search_code、get_file_contents	GitHub の raw コンテンツに対する read_url_content
アーキテクチャ図	Markdown 内の Mermaid	generate_image
データの視覚化	Markdown の表	グラフには generate_image

品質ゲート

レポートを提出する前に、以下を確認します。

• ソースの多様性 — S ティアのソースを 1 件以上、A ティアのソースを 2 件以上引用している（見つからない場合は、その旨を明記している）
• 視覚的な充実度 — スクリーンショットまたは画像を 1 点以上、図または表を 1 点以上埋め込んでいる
• 文章の品質 — エグゼクティブサマリーが箇条書きではなく、説明的な文章になっている
• 引用の完全性 — 事実に関する主張すべてにソースへのリンクがある
• ギャップの透明性 — ギャップや矛盾を明確に記録している
• 実行可能な成果物 — 順位付けした具体的な助言を含む推奨事項のセクションがある

アンチパターン

• スニペットだけの調査 — 検索結果の説明文だけで判断し、内容を十分に抽出しないこと
• 文章ばかりのレポート — ビジュアルも表も図もありません。重要なのは情報の豊かさです。
• 情報源ごとの構成 — 調査結果は URL ごとではなく、調査軸ごとにテーマ別にまとめる必要があります
• 単一ツールへの依存 — 情報源に多様性を持たせるため、異なる検索・抽出ツールを少なくとも 2 つ使用してください
• 出典のない主張 — 重要な調査結果にはすべて、その情報源へのリンクが必要です
• マーケティング文句の反復 — フレームワーク自身の宣伝文句を、独自の検証なしに繰り返すこと
• 早すぎる終了 — 15 件以上の情報源が必要なテーマなのに、3〜5 件で調査結果を提示すること

エージェント型 OS との統合

現在のプロジェクトルートに .agent/ ディレクトリがある場合、このスキルは Agentic OS の共有メモリモデルに必ず参加してください。

実行の最後に、.agent/state/last-run.json があるか確認してください。存在する場合は、必須スキーマに従ってファイルを追記または更新し、実行内容を記録してください。agent_runtime、skill_executed、簡潔な summary、decisions、next_steps を必ず記録してください。

参考資料

• 情報源の信頼性評価とクエリパターン：references/research-heuristics.md
• レポート構成テンプレート：references/report-templates.md