mcpField
D
deep-research

deep-research

github.com/rebyteai-template生産性1761 回インストール19 週間前に更新
リポジトリ

deep-research について

Deep Research は、段階的な調査とレビューを通じて、検証済みの出典付きレポートを作成するスキルです。複雑な分析向けに、短時間の探索から徹底調査までのモードと、情報源の確認やレポート作成の手順を備えています。

主な機能

  1. 01複数段階の調査パイプライン
  2. 02情報源の信頼性評価
  3. 03引用とレポートの検証
  4. 04Quick から UltraDeep までの調査モード
  5. 05Markdown、HTML、PDF レポートの作成手順

活用シーン

  1. 01複雑な技術的な質問を調査
  2. 02複数の裏付けある情報源で選択肢を比較
  3. 03出典を検証したレポートを作成

インストール

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

$npx skills add https://github.com/rebyteai-template/rebyte-skills --skill deep-research

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

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

.gitignore
ARCHITECTURE_REVIEW.md
AUTONOMY_VERIFICATION.md
COMPETITIVE_ANALYSIS.md
CONTEXT_OPTIMIZATION.md
QUICK_START.md
README.md
requirements.txt
WORD_PRECISION_AUDIT.md
reference/
methodology.md
scripts/
citation_manager.py
md_to_html.py
research_engine.py
source_evaluator.py
validate_report.py
verify_citations.py
verify_html.py
templates/
mckinsey_report_template.html
report_template.md
tests/fixtures/
invalid_report.md
valid_report.md

詳細

ディープリサーチ

コアシステム指示

目的: 出典の信頼性評価と段階的なコンテキスト管理を行いながら、8 段階のパイプライン(範囲設定 → 計画 → 情報収集 → 三角検証 → 統合 → 批評 → 改善 → 仕上げ)を通じて、出典付きで検証済みの調査レポートを提供します。

コンテキスト戦略: このスキルでは、2025 年のコンテキストエンジニアリングのベストプラクティスを採用します。

  • 静的な指示をキャッシュします(このセクション)。
  • 段階的に開示します(必要な場合にのみ参照情報を読み込みます)。
  • 「中間での情報損失」を避けます(重要な情報は埋もれさせず、冒頭と末尾に配置します)。
  • コンテキストをたどれるよう、セクションマーカーを明示します。

デシジョンツリー(最初に実行)

Request Analysis
├─ Simple lookup? → STOP: Use WebSearch, not this skill
├─ Debugging? → STOP: Use standard tools, not this skill
└─ 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)

Execution Loop (per phase)
├─ Load phase instructions from [methodology](./reference/methodology.md#phase-N)
├─ Execute phase tasks
├─ Spawn parallel agents if applicable
└─ Update progress

Validation Gate
├─ Run `python scripts/validate_report.py --report [path]`
├─ Pass? → Deliver
└─ Fail? → Fix (max 2 attempts) → Still fails? → Escalate

ワークフロー(明確化 → 計画 → 実行 → 検証 → 報告)

自律性の原則: このスキルは独立して動作します。クエリのコンテキストから前提を推測します。重大なエラーがある場合、またはクエリの意味が理解できない場合にのみ停止します。

1. 明確化(必要な場合のみ。自律的な対応を優先)

デフォルト:自律的に進めます。クエリの手がかりから前提を導き出します。

重大な曖昧さがある場合にのみ質問します。

  • クエリの意味が理解できない(例:「あのことを調べて」)
  • 要件が矛盾している(例:「すばやく、50 の情報源を使った徹底的な分析」)

迷った場合:標準モードで進めます。誤っていれば、ユーザーが軌道修正します。

デフォルトの前提:

  • 技術的なクエリ → 技術者向けと想定します
  • 比較クエリ → バランスの取れた視点が必要と想定します
  • トレンドに関するクエリ → 指定がなければ直近 1~2 年を対象と想定します
  • ほとんどのクエリでは標準モードをデフォルトとします

2. 計画

モードの選択基準:

  • クイック(2~5 分):探索、概要の把握、時間的制約がある場合
  • 標準(5~10 分):ほとんどの用途。深さと速度のバランスを重視します[デフォルト]
  • ディープ(10~20 分):重要な意思決定、徹底的な検証が必要な場合
  • ウルトラディープ(20~45 分):重要な分析、最大限の厳密さが必要な場合

計画を伝えて実行します。

  • 選択したモード、推定所要時間、情報源の数を簡潔に伝えます
  • 例:「標準モードで調査を開始します(5~10 分、情報源 15~30 件)」
  • 承認を待たずに進めます

3. 実行(フェーズの実施)

すべてのモードで実施:

  • フェーズ 1:SCOPE - 範囲を定義します(方法)
  • フェーズ 3:RETRIEVE - 並列検索を実行します(5~10 件の検索とエージェントを並行して実行)(方法)
  • フェーズ 8:PACKAGE - テンプレートを使用してレポートを生成します

Standard/Deep/UltraDeep で実施:

  • フェーズ 2:PLAN - 戦略を策定します
  • フェーズ 4:TRIANGULATE - 各主張を 3 件以上の情報源で検証します
  • フェーズ 4.5:アウトラインの改良 - 証拠に基づいて構成を調整します(WebWeaver 2025)(方法)
  • フェーズ 5:SYNTHESIZE - 新たな知見を導き出します

Deep/UltraDeep で実施:

  • フェーズ 6:CRITIQUE - レッドチーム分析を行います
  • フェーズ 7:REFINE - 不足点に対処します

重要:「Loss in the Middle」を避けてください

  • 重要な発見は、セクションの末尾に埋もれさせず、冒頭と末尾に配置します
  • 明示的な見出しとマーカーを使用します
  • 構成:要約 → 詳細 → 結論(詳細を挟み込む構成にはしません)

段階的なコンテキストの読み込み:

  • 方法論のセクションを必要に応じて読み込みます
  • テンプレートはフェーズ 8 のみで読み込みます
  • すべてをインライン化せず、外部ファイルを参照します

ハルシネーション防止プロトコル(重要):

  • 情報源に基づく記述:すべての事実に関する主張には、直後に特定の情報源を必ず引用します [N]
  • 明確な区別:事実(情報源に基づくもの)と統合・分析(自分の分析)を区別します
  • 明示的なマーカー:「[1] によると…」や「[1] は…と報告しています」のように、情報源に基づく記述を示します
  • 推測には必ずラベルを付ける:「研究によると…」ではなく、「これは…を示唆しています」と推論を明記します
  • 引用前に検証:情報源に X と実際に記載されているか不明な場合は、引用を捏造しないでください
  • 確信が持てない場合:参照を作り上げるのではなく、「X に関する情報源は見つかりませんでした」と記します

並列実行の要件(速度に関する重要事項):

フェーズ 3 RETRIEVE - 並列検索は必須:

  1. 検索を始める前に、クエリを 5~10 個の独立した検索観点に分解します
  2. 複数のツール呼び出しを使い、すべての検索を 1 つのメッセージで開始します(逐次実行はしません)
  3. FFS パターンの品質しきい値を監視します:
    • 情報源の数と平均信頼性スコアを追跡します
    • しきい値に達したら進みます(しきい値はモードごとに異なります。方法論を参照してください)
    • さらに深掘りするため、バックグラウンド検索を続けます
  4. Task ツールを使って、深掘り調査を行うエージェントを 3~5 個並列で起動します

正しい実行例:

[Single message with 8+ parallel tool calls]
WebSearch #1: Core topic semantic
WebSearch #2: Technical keywords
WebSearch #3: Recent 2024-2025 filtered
WebSearch #4: Academic domains
WebSearch #5: Critical analysis
WebSearch #6: Industry trends
Task agent #1: Academic paper analysis
Task agent #2: Technical documentation deep dive

❌ 誤り(逐次実行):

WebSearch #1 → wait for results → WebSearch #2 → wait → WebSearch #3...

✅ 正しい(並列実行):

All searches + agents launched simultaneously in one message

4. 検証(必ず実施)

ステップ 1:引用の検証(情報源の捏造を検出)

python scripts/verify_citations.py --report [path]

チェック項目:

  • DOI の解決(引用先が実際に存在することを確認)
  • タイトルと年の照合(一致しないメタデータを検出)
  • 不審な項目にフラグを付けます(DOI なし、URL なし、検証失敗の 2024 年以降の文献)

不審な引用が見つかった場合:

  • フラグが付いた項目を手動で確認します
  • 捏造された情報源を削除するか、別の情報源に置き換えます
  • 問題がなくなるまで再実行します

ステップ 2:構成と品質の検証

python scripts/validate_report.py --report [path]

自動チェック 8 項目:

  1. エグゼクティブサマリーの長さ(50~250 語)
  2. 必須セクションの有無(推奨項目:主張の表、反証)
  3. 引用の書式が [1]、[2]、[3] になっていること
  4. 参考文献一覧と引用が一致していること
  5. プレースホルダーテキスト(TBD、TODO)がないこと
  6. 適切な語数(500~10000 語)
  7. 情報源が最低 10 件あること
  8. 内部リンクにリンク切れがないこと

失敗した場合:

  • 1 回目:書式とリンクを自動修正します
  • 2 回目:手動で確認し、修正します
  • 2 回失敗したら:停止 → 問題を報告 → ユーザーに確認します

5. レポート

重要:包括的で詳細な Markdown レポートを生成します

ファイルの整理(重要 - アクセスしやすく整理): 1. /code に整理されたフォルダーを作成:

  • 必ず専用フォルダーを作成します:/code/[TopicName]_Research_[YYYYMMDD]/
  • 調査の質問から分かりやすいトピック名を抽出します(特殊文字を削除し、アンダースコアまたはキャメルケースを使用)
  • 例:
    • 「psilocybin research 2025」→ /code/Psilocybin_Research_20251104/
    • 「compare React vs Vue」→ /code/React_vs_Vue_Research_20251104/
    • 「AI safety trends」→ /code/AI_Safety_Trends_Research_20251104/
  • フォルダーが存在する場合はそれを使用し、存在しない場合は作成します
  • これにより、ファイルを整理し、簡単にアクセスできるようになります

2. すべての形式を同じフォルダーに保存:

Markdown(一次資料):

  • 保存先:[Documents folder]/research_report_[YYYYMMDD]_[topic_slug].md
  • /code/research_output/ にもコピーを保存します(内部トラッキング用)
  • すべての調査結果を含む、詳細なレポートを作成します

HTML(マッキンゼー風 — 必ず生成):

  • 保存先:[Documents folder]/research_report_[YYYYMMDD]_[topic_slug].html
  • マッキンゼーのテンプレートを使用します:mckinsey_template
  • デザイン原則:角は直角(border-radius は使用しません)、落ち着いた企業カラー(ネイビー #003d5c、グレー #f8f9fa)、非常にコンパクトなレイアウト、情報優先の構成
  • 重要な指標のダッシュボードを最上部に配置します(主要な定量的調査結果を3~4件抽出)
  • 情報量の多い内容の提示にはデータテーブルを使用します
  • 基本フォントサイズは14px、間隔はコンパクトにし、装飾的なグラデーションや色は使用しません
  • アトリビューション・グラデーション(2025): 各引用 [N] を、ソースの詳細を表示する入れ子のツールチップ div を含む <span class="citation"> で囲みます
  • 生成後、自動的にブラウザーで開きます

PDF(印刷用のプロ仕様 — 必ず生成):

  • 保存先:[Documents folder]/research_report_[YYYYMMDD]_[topic_slug].pdf
  • generating-pdf スキルを使用します(汎用エージェントと Task ツールを介して)
  • ヘッダーとページ番号を含む、プロ仕様の書式にします
  • 生成後、既定の PDF ビューアーで開きます

3. ファイル名の規則: 照合しやすいように、すべてのファイルで同じベース名を使用します:

  • research_report_20251104_psilocybin_2025.md
  • research_report_20251104_psilocybin_2025.html
  • research_report_20251104_psilocybin_2025.pdf

長さの要件(段階的な組み立てにより無制限):

  • クイックモード:2,000語以上(基本品質のしきい値)
  • 標準モード:4,000語以上(包括的な分析)
  • ディープモード:6,000語以上(徹底的な調査)
  • ウルトラディープモード:10,000~50,000語以上(上限なし — 証拠が正当化する範囲でできる限り包括的に)

長さを無制限にできる仕組み: 段階的なファイル組み立てにより、セクションごとに生成して、どのような長さのレポートでも作成できます。 各セクションはすぐにファイルへ書き込まれるため、出力トークン数の制限を回避できます。 調査結果が多い複雑なトピックでは、20件、30件、50件以上の調査結果を生成できます。制限はありません!

コンテンツの要件:

  • template を正確な構成として使用します
  • 各セクションは、証拠に応じた適切な深さで作成します(単語数の目標では決めません)
  • 曖昧な記述ではなく、具体的なデータ、統計、日付、数値を含めます
  • 各調査結果には、証拠を示す複数の段落を付けます(必要なだけ記述します)
  • 各セクションの生成に集中して取り組みます
  • 要約は書かず、完全な分析を記述します

執筆基準:

  • ナラティブ重視: 流れるような文章で記述します。各調査結果は、始まり(背景)、中盤(証拠)、終わり(示唆)のあるストーリーとして構成します
  • 精密さ: すべての言葉を意図をもって慎重に選びます
  • 簡潔さ: 冗長な表現を避け、凝った文法や不要な修飾語を排除します
  • 明瞭さ: 数値を箇条書きに単独で記載するのではなく、「この研究では、死亡率が23%低下したことが示されました」のように文章に組み込みます
  • 率直さ: 誇張せずに調査結果を述べます
  • 高い情報密度: 情報を凝縮し、読者の時間を尊重します 箇条書きポリシー(疲労防止の徹底):
  • 箇条書きは控えめに使用してください。明確に区別できるリスト(製品名、企業一覧、番号付き手順)に限ります。
  • 箇条書きを主要な情報伝達手段として使用しないでください。思考が断片化します。
  • 各調査結果セクションには、内容のある文章の段落を少なくとも3~5段落含めてください。
  • 例:「• 市場規模:24億ドル」とする代わりに、「世界市場は2023年に24億ドルに達しました。消費者需要の高まりと規制面の追い風がその要因です [1]。」と記述します。

疲労防止の品質チェック(すべてのセクションに適用): セクションを完成とする前に、次の点を確認してください。

  • 段落数:主要なセクション(## 見出し)は3段落以上
  • 文章優先:内容に占める箇条書きは20%未満(80%以上を流れるような文章にする)
  • プレースホルダーなし:「Content continues」、「Due to length」、「[Sections X-Y]」が一つもない
  • 根拠が豊富:具体的なデータ、統計、引用を含める(曖昧な記述を避ける)
  • 引用の密度:主要な主張には同じ文の中で出典を示す

いずれかのチェックに不合格の場合: 次のセクションに進む前に、そのセクションを再生成してください。

出典の記載基準(捏造防止のために重要):

  • 直後に引用を記載:事実に関する主張には、同じ文の中で必ず[N]の引用を付けてください。
  • 出典を直接示す:事実を述べる際は、「[1]によると…」または「[1]は…と報告しています」のように記述してください。
  • 事実と統合的な分析を区別する:
    • ✅ 良い例:「治療群では死亡率が23%低下しました(p<0.01)[1]。」
    • ❌ 悪い例:「研究によると、死亡率は大幅に改善しました。」
  • 曖昧な出典表示は禁止:
    • ❌ 絶対に使用しない:「研究によると…」、「調査では…」、「専門家は…と考えています」
    • ✅ 必ず使用する:「Smithら(2024)は…を発見しました」[1]、「FDAのデータによると…」[2]
  • 推測には明示的にラベルを付ける:
    • ✅ 良い例:「これは、潜在的なメカニズムを示唆しています…」(事実ではなく分析)
    • ❌ 悪い例:「そのメカニズムは…です」(引用なしで事実として提示)
  • 不確実性を認める:
    • ✅ 良い例:「Xを直接扱った出典は見つかりませんでした。」
    • ❌ 悪い例:不足を埋めるために引用を捏造する
  • テンプレートの形式:「[数値やデータを含む具体的な主張] [引用]。[分析/意味合い]。」

ユーザーへの納品内容:

  1. エグゼクティブサマリー(チャット内に記載)
  2. 整理済みのフォルダーパス(例:「すべてのファイルは次の場所に保存されています:/code/Psilocybin_Research_20251104/」)
  3. 次の3形式をすべて生成したことの確認:
    • Markdown(ソース)
    • HTML(McKinsey風、ブラウザーで開いた状態)
    • PDF(印刷に適した形式、ビューアーで開いた状態)
  4. 出典の品質評価の概要(出典数)
  5. 次のステップ(該当する場合)

生成ワークフロー:段階的なファイル作成(長さ無制限)

フェーズ8.1:セットアップ

# Extract topic slug from research question
# Create folder: /code/[TopicName]_Research_[YYYYMMDD]/
mkdir -p /code/[folder_name]

# Create initial markdown file with frontmatter
# File path: [folder]/research_report_[YYYYMMDD]_[slug].md

フェーズ8.2:セクションの段階的な生成

重要な戦略: Write/Editツールを使い、各セクションを個別に生成してファイルに書き込みます。 これにより、各回の生成量を管理しながら、長さ無制限のレポートを作成できます。

出力トークン上限の保護策(重要 — Claude Codeのデフォルト:32K):

Claude Codeのデフォルト上限:出力トークン32,000(1回のスキル実行あたり約24,000語) これは厳格な上限であり、スキル内で変更できません。

この上限の意味:

  • 合計出力(テキストとすべてのツール呼び出しの内容)は32,000トークン未満である必要があります。
  • 32,000トークンは約24,000語に相当し、これが上限です。
  • 安全余裕を設けてください。合計出力は20,000語以下を目標にします。

モードごとの現実的なレポートの長さ:

  • クイックモード:2,000~4,000語 ✅(上限を十分に下回ります)
  • 標準モード:4,000~8,000語 ✅(余裕をもって上限を下回ります)
  • ディープモード:8,000~15,000語 ✅(注意すれば達成可能です)
  • ウルトラディープモード:15,000~20,000語 ⚠️(上限に近いため、注意深く監視してください)

20,000語を超えるレポートの場合: ユーザーはスキルを複数回実行する必要があります。

  • 実行1:「パート1(セクション1~6)を生成」→ part1.mdに保存
  • 実行2:「パート2(セクション7~12)を生成」→ part2.mdに保存
  • ユーザーが手動で結合するか、Claudeにファイルの統合を依頼します

自動継続戦略(真の長さ無制限): 1 回の実行でレポートが 18,000 語を超える場合:

  1. セクション 1~10 を生成します(18K 語未満に収めます)
  2. コンテキストを保持した継続状態ファイルを保存します
  3. Task ツールで継続エージェントを起動します
  4. 継続エージェント:状態を読み込み → 次のバッチを生成 → 必要に応じて次のエージェントを起動します
  5. 完了するまで、この連鎖を再帰的に続けます

これにより、各エージェントの上限 32K を守りながら、長さを無制限にできます

引用の追跡を初期化:

citations_used = []  # Maintain this list in working memory throughout

セクション生成ループ:

パターン: セクションの内容を生成 → その内容で Write/Edit ツールを使用 → 次のセクションに進みます 各 Write/Edit 呼び出しには 1 つのセクションのみを含めます(呼び出しごとに ≤2,000 語)

  1. エグゼクティブサマリー(200~400 語)

    • セクションの内容を生成します
    • ツール:Write(file, content=frontmatter + エグゼクティブサマリー)
    • 使用した引用を追跡します
    • 進捗:「✓ エグゼクティブサマリー」
  2. はじめに(400~800 語)

    • セクションの内容を生成します
    • ツール:Edit(file, old=last_line, new=old + はじめにセクション)
    • 使用した引用を追跡します
    • 進捗:「✓ はじめに」
  3. 所見 1(600~2,000 語)

    • 所見の全体を生成します
    • ツール:Edit(file, append 所見 1)
    • 使用した引用を追跡します
    • 進捗:「✓ 所見 1」
  4. 所見 2(600~2,000 語)

    • 所見の全体を生成します
    • ツール:Edit(file, append 所見 2)
    • 使用した引用を追跡します
    • 進捗:「✓ 所見 2」

... すべての所見について続けます(各所見につき Edit ツール呼び出し 1 回、≤2,000 語)

重要: 所見が 10 件あり、それぞれ 1,500 語の場合、所見の合計は 15,000 語です これは問題ありません。各 Edit 呼び出しは 1,500 語のみであり、ツール呼び出しごとの上限 2,000 語未満だからです ファイルは 15,000 語になりますが、1 回のツール呼び出しが上限を超えることはありません

  1. 統合と洞察

    • 生成内容:情報源の記述を超える新たな洞察(統合に必要なだけ)
    • ツール:Edit(ファイルに追記)
    • 追跡:引用を抽出し、citations_used に追加します
    • 進捗:「統合を生成しました ✓」
  2. 制約と注意事項

    • 生成内容:反証、ギャップ、不確実性(適切な深さで)
    • ツール:Edit(ファイルに追記)
    • 追跡:引用を抽出し、citations_used に追加します
    • 進捗:「制約を生成しました ✓」
  3. 推奨事項

    • 生成内容:直ちに実行すべきこと、次のステップ、必要な調査(適切な深さで)
    • ツール:Edit(ファイルに追記)
    • 追跡:引用を抽出し、citations_used に追加します
    • 進捗:「推奨事項を生成しました ✓」
  4. 参考文献(重要:すべての引用)

    • 生成内容:citations_used リストにあるすべての引用を含む完全な参考文献
    • 形式:[1]、[2]、[3]... [N] - 各引用に完全な項目を付けます
    • 確認:citations_used リストを確認します。リストに [1] から [73] が含まれる場合、73 件すべてを生成します
    • 範囲表記([1-50])、プレースホルダー(「追加の引用」)、省略は禁止です
    • ツール:Edit(ファイルに追記)
    • 進捗:「参考文献を生成しました ✓(N 件の引用)」
  5. 方法論の付録

    • 生成内容:調査プロセス、検証方法(適切な深さで)
    • ツール:Edit(ファイルに追記)
    • 進捗:「方法論を生成しました ✓」

フェーズ 8.3:自動継続の判断ポイント

セクションを生成した後、語数を確認します:

出力の合計が 18,000 語以下の場合: 通常どおり完了します

  • 参考文献を生成します(すべての引用)
  • 方法論を生成します
  • レポート全体を確認します
  • コピーを /code/research_output/ に保存します
  • 完了! ✓

出力の合計が 18,000 語を超える場合: 自動継続プロトコル

ステップ 1:継続状態を保存 ファイルを作成:/code/research_output/continuation_state_[report_id].json

{
  "version": "2.1.1",
  "report_id": "[unique_id]",
  "file_path": "[absolute_path_to_report.md]",
  "mode": "[quick|standard|deep|ultradeep]",

  "progress": {
    "sections_completed": [list of section IDs done],
    "total_planned_sections": [total count],
    "word_count_so_far": [current word count],
    "continuation_count": [which continuation this is, starts at 1]
  },

  "citations": {
    "used": [1, 2, 3, ..., N],
    "next_number": [N+1],
    "bibliography_entries": [
      "[1] Full citation entry",
      "[2] Full citation entry",
      ...
    ]
  },

  "research_context": {
    "research_question": "[original question]",
    "key_themes": ["theme1", "theme2", "theme3"],
    "main_findings_summary": [
      "Finding 1: [100-word summary]",
      "Finding 2: [100-word summary]",
      ...
    ],
    "narrative_arc": "[Current position in story: beginning/middle/conclusion]"
  },

  "quality_metrics": {
    "avg_words_per_finding": [calculated average],
    "citation_density": [citations per 1000 words],
    "prose_vs_bullets_ratio": [e.g., "85% prose"],
    "writing_style": "technical-precise-data-driven"
  },

  "next_sections": [
    {"id": N, "type": "finding", "title": "Finding X", "target_words": 1500},
    {"id": N+1, "type": "synthesis", "title": "Synthesis", "target_words": 1000},
    ...
  ]
}

ステップ 2:継続エージェントを起動

汎用エージェントで Task ツールを使用します:

Task(
  subagent_type="general-purpose",
  description="Continue deep-research report generation",
  prompt="""
CONTINUATION TASK: You are continuing an existing deep-research report.

CRITICAL INSTRUCTIONS:
1. Read continuation state file: /code/research_output/continuation_state_[report_id].json
2. Read existing report to understand context: [file_path from state]
3. Read LAST 3 completed sections to understand flow and style
4. Load research context: themes, narrative arc, writing style from state
5. Continue citation numbering from state.citations.next_number
6. Maintain quality metrics from state (avg words, citation density, prose ratio)

CONTEXT PRESERVATION:
- Research question: [from state]
- Key themes established: [from state]
- Findings so far: [summaries from state]
- Narrative position: [from state]
- Writing style: [from state]

YOUR TASK:
Generate next batch of sections (stay under 18,000 words):
[List next_sections from state]

Use Write/Edit tools to append to existing file: [file_path]

QUALITY GATES (verify before each section):
- Words per section: Within ±20% of [avg_words_per_finding]
- Citation density: Match [citation_density] ±0.5 per 1K words
- Prose ratio: Maintain ≥80% prose (not bullets)
- Theme alignment: Section ties to key_themes
- Style consistency: Match [writing_style]

After generating sections:
- If more sections remain: Update state, spawn next continuation agent
- If final sections: Generate complete bibliography, verify report, cleanup state file

HANDOFF PROTOCOL (if spawning next agent):
1. Update continuation_state.json with new progress
2. Add new citations to state
3. Add summaries of new findings to state
4. Update quality metrics
5. Spawn next agent with same instructions
"""
)

ステップ 3:継続状況を報告 ユーザーに伝えます:

📊 Report Generation: Part 1 Complete (N sections, X words)
🔄 Auto-continuing via spawned agent...
   Next batch: [section list]
   Progress: [X%] complete

フェーズ 8.4:継続エージェントの品質プロトコル

継続エージェントの起動時: コンテキストの読み込み(重要):

  1. continuation_state.json を読み込む → すべてのコンテキストを読み込む
  2. 既存のレポートファイルを読み込む → 直近3つのセクションを確認する
  3. パターンを抽出する:
    • 文構造の複雑さ
    • 使用されている専門用語
    • 引用の配置パターン
    • 段落間のつなぎ方

生成前のチェックリスト:

  • 調査コンテキスト(テーマ、質問、ストーリー展開)を読み込んだ
  • 前のセクションを確認して流れを把握した
  • 引用番号を読み込んだ(N+1 から開始)
  • 品質目標(語数、密度、スタイル)を読み込んだ
  • ストーリー展開のどの位置(冒頭/中盤/結末)かを把握した

セクションごとの生成:

  1. セクションの内容を生成する
  2. 品質を確認する:
    • 語数:目標の ±20% 以内
    • 引用密度:設定済みの割合と一致している
    • 散文の比率:80%以上
    • テーマとのつながり:key_themes に結び付いている
    • スタイルの一致:quality_metrics.writing_style と一貫している
  3. いずれかの確認に失敗した場合:セクションを再生成する
  4. すべてに合格した場合:ファイルに書き込み、状態を更新する

引き継ぎの判断:

  • 計算する:現在の語数 + 残りのセクション数 × セクションあたりの平均語数
  • 合計が 18K 未満の場合:残りのセクションをすべて生成して完了する
  • 合計が 18K を超える場合:一部のバッチを生成し、状態を更新して、次のエージェントを起動する

最終エージェントの担当事項:

  • 最終コンテンツのセクションを生成する
  • state.citations.bibliography_entries のすべての引用を使って、完全な参考文献一覧を生成する
  • 組み立てたレポート全体を読む
  • 検証を実行する:python scripts/validate_report.py --report [path]
  • continuation_state.json を削除する(クリーンアップ)
  • 指標を添えて、完了をユーザーに報告する

疲労を抑える仕組み: 各エージェントは、品質を保ちながら、扱いやすい分量(18K 語以下)を生成します。 コンテキストを保持することで、継続時にも一貫性を維持できます。

HTML の生成(McKinsey スタイル)

  1. McKinsey テンプレートを ./templates/mckinsey_report_template.html から読み込む

  2. 調査結果から、ダッシュボード用の主要な定量指標を3~4個抽出する

  3. Python スクリプトで Markdown を HTML に変換する:

    cd ~/.claude/skills/deep-research
    python scripts/md_to_html.py [markdown_report_path]
    

    スクリプトは次の2つの部分を返します:

    • パートA({{CONTENT}}): 参考文献一覧以外のすべてのセクションを、適切に HTML に変換したもの
    • パートB({{BIBLIOGRAPHY}}): 参考文献一覧セクションのみを HTML 形式にしたもの

    重要: スクリプトは変換をすべて自動で処理します:

    • 見出し:## → <div class="section"><h2 class="section-title">、### → <h3 class="subsection-title">
    • リスト:Markdown の箇条書き → 適切な入れ子構造の <ul><li>
    • 表:Markdown の表 → thead/tbody を含む <table>
    • 段落:テキストを <p> タグで囲む
    • 太字/斜体:text → <strong>、text → <em>
    • 引用:[N] はステップ4のツールチップ変換用に保持
  4. 引用のツールチップを追加する(帰属のグラデーション): {{CONTENT}} 内の各引用 [N](参考文献一覧を除く)に、必要に応じてインタラクティブなツールチップを追加します:

    <span class="citation">[N]
      <span class="citation-tooltip">
        <div class="tooltip-title">[Source Title]</div>
        <div class="tooltip-source">[Author/Publisher]</div>
        <div class="tooltip-claim">
          <div class="tooltip-claim-label">Supports Claim:</div>
          [Extract sentence with this citation]
        </div>
      </span>
    </span>
    

    注:このステップは時間短縮のため省略できます。基本的な [N] 引用で十分です。

  5. テンプレート内のプレースホルダーを置き換える:

    • {{TITLE}} - レポートのタイトル(Markdown の最初の ## 見出しから抽出)
    • {{DATE}} - 生成日(YYYY-MM-DD 形式)
    • {{SOURCE_COUNT}} - 重複を除いたソース数
    • {{METRICS_DASHBOARD}} - ステップ2で作成した指標の HTML
    • {{CONTENT}} - パートAの HTML(スクリプトの出力)
    • {{BIBLIOGRAPHY}} - パートBの HTML(スクリプトの出力)
  6. 重要:絵文字は使用しない - 最終的な HTML から絵文字をすべて削除する

  7. 次の場所に保存する:[folder]/research_report_[YYYYMMDD]_[slug].html

  8. HTML を検証する(必須):

    python scripts/verify_html.py --html [html_path] --md [md_path]
    
    • 検証に合格:ステップ9に進む
    • 検証に失敗:エラーを修正し、検証を再実行する
  9. ブラウザーで開く:open [html_path]

PDF の生成

  1. 汎用エージェントで Task ツールを使用する
  2. Markdown を入力として、generating-pdf スキルを実行する
  3. 次の場所に保存する:[folder]/research_report_[YYYYMMDD]_[slug].pdf
  4. 完了すると PDF が自動的に開きます

出力要件

形式: テンプレートに厳密に従った包括的なMarkdownレポート

必須セクション(すべて詳細に記述すること):

  • エグゼクティブサマリー(簡潔な段落を2~3つ、50~250語)
  • はじめに(質問、範囲、方法論、前提条件を含む段落を2~3つ)
  • 主な分析(各300~500語の調査結果を4~8件、引用 [1]、[2]、[3] を付記)
  • 統合と考察(500~1000語:パターン、新たな知見、示唆)
  • 制約と注意事項(不足、前提条件、不確実性を含む段落を2~3つ)
  • 推奨事項(直ちに実施するアクションを3~5件、次のステップを3~5件、追加調査を3~5件)
  • 参考文献(重要:以下のルールを参照)
  • 方法論の付録(プロセス、情報源、検証を含む段落を2~3つ)

参考文献の要件(違反は一切認められません。完全な参考文献がなければレポートは使用できません):

  • ✅ レポート本文で使用したすべての引用 [N] を記載すること(レポートに [1]~[50] がある場合は、50件すべてを記載)
  • ✅ 形式:[N] 著者/組織(年)。「タイトル」。掲載誌・媒体。URL(取得日:日付)
  • ✅ 各項目は、すべてのメタデータを含めて1行ずつ記載すること
  • ❌ プレースホルダーは禁止:「[8-75] 追加の引用」、「...続く...」、「など」、「[情報源を続けて記載...]」は絶対に使用しないこと
  • ❌ 範囲表記は禁止:[3-50] ではなく、[3]、[4]、[5]…と個別に記載すること
  • ❌ 省略は禁止:30件の情報源を引用した場合は、30件すべての項目を完全に記載すること
  • ⚠️ 参考文献にプレースホルダーがある場合、または引用が不足している場合、検証は失敗します
  • ⚠️ 完全な参考文献がなければ、レポートは役に立ちません。主張を検証する方法がなくなります

厳禁事項:

  • プレースホルダーテキスト(TBD、TODO、[citation needed])
  • 引用のない主要な主張
  • リンク切れ
  • 必須セクションの欠落
  • 詳細な分析の代わりに短い要約を記載すること
  • 具体的な根拠のない曖昧な記述

執筆基準(重要):

  • ストーリー性: 理解が段階的に深まるよう、完全な文章で流れるように記述すること
  • 精密さ: 一語一語を意図的に選ぶこと。すべての語に意味を持たせること
  • 簡潔さ: 冗長な表現、不要な形容詞、凝った文法を排除すること
  • 明瞭さ: 正確な技術用語を使い、曖昧さを避けること。正確な数値は箇条書きではなく文章に含めること
  • 率直さ: 誇張せず、調査結果を明確に述べること
  • 情報密度: 情報密度を高め、読者の時間を尊重すること
  • 箇条書きの節度: 箇条書きは、製品、企業、手順など、明確に区別される項目の列挙に限ること。原則として段落形式で記述すること
  • 精密さの例:
    • 悪い例:「結果が大幅に改善した」→ 良い例:「死亡率が23%低下した(p<0.01)」
    • 悪い例:「複数の研究が示唆している」→ 良い例:「5件のRCT(n=1,847)が示している」
    • 悪い例:「有益である可能性がある」→ 良い例:「バイオマーカーXが15%増加した」
    • 悪い例:「• 市場:24億ドル」→ 良い例:「消費者需要を背景に、2023年の市場規模は24億ドルに達しました [1]。」

品質ゲート(バリデーターによる強制適用):

  • 最低2,000語(標準モード)
  • 信頼性スコアの平均が60/100を超えること
  • 主要な主張ごとに3件以上の情報源
  • 事実と分析の明確な区別
  • すべてのセクションが存在し、詳細に記述されていること

エラー処理と停止ルール

次の場合は直ちに停止すること:

  • 同じエラーで検証に2回失敗した場合 → 一時停止して状況を報告し、ユーザーに確認する
  • 徹底的に検索しても情報源が5件未満の場合 → 制約を報告し、指示を求める
  • ユーザーが中断、または範囲を変更した場合 → 新しい方針を確認する

適切な縮退対応:

  • 情報源が5~10件の場合 → 制約に記載し、追加の検証を行って続行する
  • 時間制約に達した場合 → 部分的な結果をまとめ、不足点を記録する
  • 優先度の高い批評上の問題がある場合 → 直ちに対処する

エラー形式:

⚠️ Issue: [Description]
📊 Context: [What was attempted]
🔍 Tried: [Resolution attempts]
💡 Options:
   1. [Option 1]
   2. [Option 2]
   3. [Option 3]

品質基準(常に適用)

すべてのレポートで以下を満たすこと:

  • 情報源を10件以上使用する(不足する場合はその旨を記録する)
  • 主要な主張ごとに情報源を3件以上使用する
  • エグゼクティブサマリーを250語未満にする
  • URLを含む完全な引用を記載する
  • 信頼性を評価する
  • 制約のセクションを設ける
  • 方法論を記録する
  • プレースホルダーを使用しない

優先事項: 速度より徹底性。速度より品質。


入力と前提

必須:

  • 調査の質問(文字列)

任意:

  • モード(quick/standard/deep/ultradeep)
  • 時間の制約
  • 必要な視点/情報源
  • 出力形式

前提:

  • ユーザーは、検証済みで引用に基づく情報を必要としています
  • トピックについて10~50件の情報源を利用できます
  • 所要時間:5~45分

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

次の場合に使用します:

  • 包括的な分析(10件以上の情報源が必要)
  • 技術/アプローチ/戦略の比較
  • 最先端技術のレビュー
  • 複数の視点からの調査
  • 技術的な意思決定
  • 市場/トレンド分析

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

  • 簡単な検索(WebSearch を使用)
  • デバッグ(標準ツールを使用)
  • 1~2件の検索結果で答えられる質問
  • 時間に制約のある簡単な回答

スクリプト(オフライン、Python 標準ライブラリのみ)

場所: ./scripts/

  • research_engine.py - オーケストレーションエンジン
  • validate_report.py - 品質検証(8項目のチェック)
  • citation_manager.py - 引用の追跡
  • source_evaluator.py - 信頼性のスコアリング(0~100)

外部依存関係は不要です。


段階的なリファレンス(必要に応じて読み込み)

これらを本文に含めず、参照のみ行ってください:

コンテキスト管理: 現在のフェーズに必要なファイルのみ、必要に応じて読み込んでください。すべてのコンテンツを事前に読み込まないでください。



動的実行ゾーン

ユーザークエリの処理: [実行中にユーザーの調査の質問が挿入されます]

取得した情報: [検索結果と情報源がここに蓄積されます]

生成された分析: [調査結果、統合内容、レポートのコンテンツがここで生成されます]

注: このセクションはスキル定義では空のままです。コンテンツは実行時にのみ入力されます。

コメント