deep-research

深掘り調査 · Deep Research

主な目的

エビデンスの永続化、情報源の識別情報の管理、主張単位の検証、段階的なコンテキスト管理を備えた構造化パイプラインを通じて、引用元を追跡できる調査レポートを作成します。

自律性の原則： 独立して動作します。コンテキストから前提を推測します。重大なエラーや理解できないクエリがある場合にのみ停止します。重要度の高い前提は、暗黙のうちに既定値として扱わず、序論と方法論で明示します。

起動条件

起動する場合

• ユーザーが、引用追跡、エビデンスの永続化、構造化レポートの生成を伴う複数ソースの調査を必要としている場合：「深掘り調査」、「包括的な分析」、「調査レポート」。
• ユーザーが「X と Y を比較」、「トレンドを分析」、または「最先端の状況を調査」と依頼した場合。技術比較、市場分析、複数の視点からの調査を含みます。
• ユーザーが、GitHub やその他のオープンソース・フォージを含む実装状況の調査を必要としている場合：「オープンソースソリューション」または「开源方案」。

起動しない場合

• 1～2 回の検索で回答できる単純な調査や質問の場合。ウェブ検索を直接使用します。
• デバッグの場合。標準ツールを使用します。
• 時間が重要な簡単なクエリの場合。

依存関係

• lov-dev-blog は Skill Publisher のウェブサイトにおけるブログ公開契約を管理します。 deep-research は調査の生成と検証を担当します。最終的な blog_posts への公開には、dev-blog の自動化セマンティクスを使用する必要があります。

---

判断フロー

Request Analysis
+-- Simple lookup? --> STOP: Use WebSearch
+-- Debugging? --> STOP: Use standard tools
+-- Complex analysis needed? --> CONTINUE

Mode Selection
+-- Initial exploration --> quick (3 phases, 2-5 min)
+-- Standard research --> standard (6 phases, 5-10 min) [DEFAULT]
+-- Critical decision --> deep (8 phases, 10-20 min)
+-- Comprehensive review --> ultradeep (8+ phases, 20-45 min)

既定の前提： 技術的なクエリは技術者向けです。比較ではバランスの取れた視点を採用します。トレンドは直近 1～2 年を対象とします。

---

ワークフローの概要

フェーズ	名前	クイック	標準	詳細	超詳細
1	範囲設定	Y	Y	Y	Y
2	計画	-	Y	Y	Y
3	情報収集	Y	Y	Y	Y
4	多角的検証	-	Y	Y	Y
4.5	概要の調整	-	Y	Y	Y
5	統合	-	Y	Y	Y
6	批評	-	-	Y	Y
7	推敲	-	-	Y	Y
8	パッケージ化	Y	Y	Y	Y

注： フェーズ 3～5 は厳密な逐次ゲートではなく、セクションごとのエビデンスループ（情報収集 → エビデンスの保存 → 概要の調整 → 草稿作成 → 主張の検証 → 必要に応じて追加情報を収集）として動作します。

---

実行

呼び出し時に、関連するリファレンスファイルを読み込みます：

1. フェーズ 1～7： 詳細なフェーズ手順については、methodology.md を読み込みます
2. フェーズ 8（レポート）： 段階的な生成については、report-assembly.md を読み込みます
3. HTML/PDF 出力： html-generation.md を読み込みます
4. 品質チェック： quality-gates.md を読み込みます
5. 実装／ツールに関する調査： open-source-solutions.md を読み込みます
6. 比較／選定／導入に関する調査： decision-guides.md を読み込みます
7. 長文レポート（18K ワード超）： continuation.md を読み込みます
8. 図、写真、地図、図表（すべての標準以上のレポート）： フェーズ 8 の前に rich-media.md を読み込み、アウトラインとあわせて図のリストを作成します

テンプレート：

• レポート構成：report_template.md
• HTML スタイル設定：mckinsey_report_template.html

スクリプト：

• python scripts/validate_report.py --report [path]
• python scripts/verify_citations.py --report [path]
• python scripts/md_to_html.py [markdown_path] --embed-images
• python scripts/validate_open_source_solutions.py --artifact [open_source_solutions.jsonl] --report [report.md] --strict
• python scripts/validate_decision_guide.py --report [report.md] --strict

レポート作成後の公開（Skill Publisher）：

• これは必須の完了条件であり、任意のフォローアップではありません。同期コマンドが成功するか、具体的な同期エラーが報告されるまでは、公開可能なレポートの最終回答を送信しないでください。
• フェーズ 8 で Markdown レポートの生成に成功したら、ユーザーが明示的に「private」「do not publish」「不要发布」または同等の表現を指定していない限り、自動的に Skill Publisher のブログシステムに公開します。
• この条件は lov-dev-blog に依存します。以下のウェブサイト同期コマンドは、調査成果物向けの dev-blog 公開仕様です。
• 生成した Markdown ファイルのパスを正として使用します： cd ${SKILL_WORKSPACE_ROOT}/coding/web && pnpm run sync:research -- [markdown_path]
• Markdown レポートが複数生成された場合、または Markdown の正確なパスが不明な場合は、次を実行します： cd ${SKILL_WORKSPACE_ROOT}/coding/web && pnpm run sync:research -- --limit 5
• 公開の仕様は lov-dev-blog が定め、ウェブサイト同期スクリプトが実行します：
  • 新しいレポートは一般公開の詳細ページとして公開されます（is_visible=true）。
  • 新しいレポートは既定で /blog インデックスに表示されます（show_in_index=true）。
  • 既存のレポートを再同期すると、明示的に非表示にされていない限り、インデックスにも表示されます。
  • 公開するレポートにはカバー画像が必要です。Markdown 成果物にカバー URL が指定されていない場合、ウェブサイト同期スクリプトが自動で生成してアップロードすることがあります。
• 最終的な公開 URL を次の形式でユーザーに伝えます： https://lovstudio.ai/blog/[slug]
• 最終回答には、公開状況を示す 1 行を含めます：Published to Skill Publisher: yes/no。公開済みの場合は公開 URL も記載します。
• ウェブサイトのパス、環境、またはデータベーススキーマが利用できず同期コマンドが失敗した場合は、完成した調査成果物を保持し、正確な同期エラーと再実行するコマンドを提示します。

出力契約

必須セクション：

• エグゼクティブサマリー（200～400語）
• はじめに（対象範囲、方法論、前提条件）
• 主な分析（4～8件の調査結果、各600～2,000語、出典を引用）
• 意思決定ガイド（比較、選定、調達、アーキテクチャ選択、または導入に関するレポートでは必須。詳細な調査結果の前に配置）
• オープンソースソリューションの状況（ソフトウェア、ツール、オートメーション、実装、またはデプロイ可能なソリューションを扱う場合は必須）
• 図表（standard+ モードで必須。quick は1点以上、standard は3点以上、deep は5点以上、ultradeep は8点以上）：一次資料の写真、引用した数値に基づくグラフ、構造・プロセス・タイムラインの図や地図を含め、それぞれに代替テキストと、番号および出典付きのキャプションを付けてください。rich-media.md を参照してください。
• 統合と洞察（パターン、示唆）
• 制約と留意事項
• 推奨事項
• 参考文献（完全版 — すべての引用を含め、プレースホルダーは使用しない）
• 方法論の付録

出力ファイル（すべて ~/Documents/[Topic]_Research_[YYYYMMDD]/ に保存）：

• Markdown（一次情報源）
• sources.jsonl — 正規 ID を含む、安定した出典レジストリ
• evidence.jsonl — 引用文と位置情報を含む、追記専用のエビデンスストア
• claims.jsonl — 裏付け状況を記録した、個別の主張の台帳
• run_manifest.json — クエリ、モード、前提条件、プロバイダー設定
• figures/ — Markdown レポートからの相対パスで参照する図表ファイル（写真は EXIF 情報を削除）
• open_source_solutions.jsonl — 該当する実装・ツール調査用の正規リポジトリレジストリ。検証済みリポジトリを1行に1件記録
• HTML（McKinsey スタイル、自己完結型、図表を埋め込み、自動的に開く）
• PDF（プロフェッショナルな印刷品質、自動的に開く）

品質基準：

• 出典は10件以上。主要な主張ごとに3件以上（単なる件数ではなく、相互に独立したクラスターから）
• 事実に関するすべての主張に、直後に [N] 形式で引用を付け、evidence.jsonl のエビデンスで裏付ける
• 主張の裏付け検証は必須。裏付けのない事実に関する主張を、納品物に含めてはいけません
• 該当する比較・選定レポートでは、決定的な制約を、終端の推奨を明示した分岐型の意思決定フローに落とし込み、文章による代替説明も用意してください。スコア表だけでは不十分です
• 該当する実装・ツール関連レポートでは、GitHub とその他の関連フォージを検索し、README の記述だけでなくリポジトリのエビデンスも調査し、リンク付きの比較表を掲載して、open_source_solutions.jsonl を保存してください。該当リポジトリがない場合は、結果がないことを明示した記録が必要です
• リッチメディア：エビデンスを示すビジュアルを、エビデンスが許す限り多く含めてください。一次資料のビジュアルや引用した数値に基づくグラフを優先してください。ライセンスのない第三者の画像をホットリンクしたり埋め込んだりしないでください。AI 生成画像を実物として提示しないでください
• プレースホルダーや捏造した引用は使用しないでください
• 文章を中心に構成する（80％以上）。箇条書きは控えめに使用してください

---

ランタイムコンテキスト（共通）

実行前にこの Skill パッケージの skill.yaml を読み込み、ホストから提供される skill-runtime/v1 コンテキストを使用してください。フィールドの解決順序は、現在のリクエスト、プロジェクトコンテキスト、個人の Preferences、ブランド Profile、一般的なデフォルト値です。Profile は共有の user-profile/v1 から取得し、この Skill の長期記録は skills.deep-research.records にのみ書き込みます。

• Manifest で宣言されたフィールドのみを使用してください。公開されているブランド情報は Profile に、個人の作業上の好みは Preferences に保存します。
• required: true のフィールドが欠けている場合は、Manifest に定められた質問設定に従って、ユーザーに焦点を絞った質問を1つしてください。ユーザーが明示的に同意した後で回答を保存します。
• エラーの報告には、コピー可能な context_id、フィールドパス、情報源を含めてください。診断内容に秘密情報、個人用の完全なパス、または生の設定情報を含めないでください。

共通フィードバックループ

ユーザーが Skill 主導のタスクで修正を依頼した場合、現在の成果物の作業を続ける前に、次の手順を実行してください。

1. まず、依頼が task-specific（今回のみ）か reusable（他のタスクでも再利用可能）かを判断します。
2. task-specific の場合は現在のタスクのみを修正し、Skill は変更しません。
3. reusable の場合は適用範囲を特定します。分野固有のルールは該当する canonical Skill を先に更新し、すべての Skill に適用されるルールは共有規範を先に更新します。
4. ルールの更新、バージョン確認、lint、配布状況の検証を完了してから、修正を現在のタスクに適用します。
5. reusable の修正が入ると、それ以前の「確認」「続けて」「送って」などの指示は無効になります。現在の成果物の修正と読み返しが完了したら、そこで停止し、ユーザーの次の指示を待ってください。公開、コミット、その他の外部書き込みへ自動的に進んではいけません。