deep-research

詳細調査

概要

多くの情報源を横断してトピックを調査し、引用付きの体系的な統合結果を会話内で提示します。検索結果の抜粋との違いは、視点の幅、相互参照の深さ、引用の徹底です。出力はチャット内にとどめ、依頼された場合にのみファイルを書き出します。

5つの検索観点

実行ごとに、少なくとも3つを扱います。計画で観点を示し、各検索にタグを付けてください。

観点	調査対象
公式	一次資料、仕様、ベンダーの情報、査読付き論文
比較	「X vs Y」、代替案、直接比較分析
批判	制限事項、既知の問題、失敗事例
最新情報	最近の動向、変更履歴、トレンド記事（クエリに年を含める）
コミュニティ	HN、Reddit、ブログ、Stack Overflow — 手掛かりであり、権威ではありません

モード

モード	トリガー	検索数	出力
quick	「Xについて手早く知りたい」、影響が小さい場合	3-5	1段落 + 3-5件の情報源。基準は緩やか
default	標準的な単一分野のトピック	5-10+	完全版の統合テンプレート
comparison	「XとYを比較して」「メリットとデメリット」	10-15	レポート冒頭に必ず比較表を掲載
landscape	「Xの全体像を調査して」、幅広い領域	10+	並行してサブエージェントを実行 → 合意点を整理（PLAYBOOK）

意見を求める質問（「Xを使うべきですか？」など）で、すでに根拠のある見解がある場合は、まず直接回答してから、調査の拡張を提案してください。確信を持った意見を求める依頼に対して、10回も検索するのはユーザーの手間を無駄にします。

ワークフロー — 各ステップを完了してから次へ進む

1. まずローカルを確認 — Web検索の前に rg "<topic>" . を実行し、明らかな該当箇所を読みます。ローカル資料で十分にカバーされている場合は、CREATE ではなく UPDATE を基本とします。見つかった内容を伝えてください。「ローカルで該当なし」でも問題ありません。
2. 計画 — 解釈、使用する観点、モードを投稿してから検索を開始します。投稿した計画が、ステップ5での評価基準となります。
3. 曖昧さを解消（必要な場合）— 固有名詞や頭字語が曖昧なら、幅広い検索を1回実行して対象を特定し、その旨を伝えます。それでも不明な場合はユーザーに確認してください。急速に変化する分野（AIモデル、開発者向けツール、数か月で状況が変わるものなど）で、認識のある名称がクエリの中心となる場合は、その名称自体を検証してください。回答する前に検索し、少なくとも1つのクエリではユーザーが書いた名称をそのまま含めます。背景知識が部分的にあると、古い回答を権威あるもののように見せてしまいます。したがって、知っていることを理由に検索を省略してはいけません。
4. 検索 — 最低5回検索します。広く → 具体的に → 対立点（「X criticism」「X vs alternatives」）→ 最新情報の順に進めます。内容を実質的に引用する情報源はすべて WebFetch で取得してください — 検索結果の抜粋は、内容を読んだことにはなりません。一次情報 > 二次情報 > 三次情報の順で優先します。情報源同士の見解が異なる場合は、一方を黙って選ぶのではなく、その食い違いをレポートに反映してください。
5. 十分性の確認 — 次の1行を投稿します：searches: N | angles: <list> | full reads: M | gaps: <list>。予定していたセクションに裏付けとなる資料がない場合は、追加で検索するか、そのセクションを削除してください。水増ししてはいけません。
6. 統合 — 以下のテンプレートを使い、トピックに合わせてセクション名を調整します。最後の検索で得た内容をステップ2の計画と照合してください。食い違いがある場合は、矛盾を後半に埋もれさせず、Tl;dr を修正します。
7. 引用の検証 — 引用する URL はすべて、今回取得したページにたどれる必要があります。重要な主張はそれぞれ情報源まで確認し、ユーザーの元の質問を再度述べてから、回答に不要なセクションを削除します。

統合テンプレート

# [Topic] — Research Summary
> Interpreted as: [if ambiguity was present]

## Tl;dr
[2-3 sentences answering the original question.] *Confidence: high/med/low — why.*

## Overview / Core Information
Definition, how it works, key concepts. *Confidence: ...*

## Comparison Matrix  [REQUIRED when comparing 3+ items, place right after Tl;dr]
| Item | Dimension 1 | Dimension 2 | Notes |
|------|-------------|-------------|-------|

## Trade-offs and Criticism
Limitations, valid criticisms, when not to use this. *Confidence: ...*

## Current Landscape
Recent developments, adoption signal, direction. Note disagreements. *Confidence: ...*

## What we still don't know  [when gaps are non-trivial]
- Open question

## Sources  [group under sub-headers when >5]
- [Title (YYYY-MM-DD)](url) — what this contributed

情報源に関するルール： 実質的なトピックでは8-15件以上を使用します。すべての主張を情報源までたどれるようにし、各情報源が何に寄与したかを記載します。公開日を含め、公式、業界、コミュニティの情報源を組み合わせてください。

長さ： 質問に応じた長さにします。default モードでは、文章はおよそ1画面分に情報源一覧を加えた量が目安です。情報源が裏付けないテンプレートのセクションは、水増しせず削除し、推測で書くのではなく、セクションの拡充を提案してください。

例

✅ 良い例（quick モード、省略版 — ステップ番号は上記のワークフローに対応しています）：

user: quick read on whether Bun is stable enough for a CLI tool
assistant:
[1] No local material. [2] Mode: quick. Angles: Official, Criticism, Currency.
[5] searches: 4 | angles: 3 | full reads: 3 | gaps: Windows support thin

Bun 1.x is stable for single-binary CLIs on macOS and Linux; Windows still
trails on a few Node APIs, so check your dependency list against the compat
table. *Confidence: med — official compat table + two 2026 issue threads; no
Windows production reports found.*
Sources: [bun.sh compat table (2026-06)](url) — API coverage · [GitHub issue (2026-05)](url) — Windows gaps · [HN thread (2026-04)](url) — field reports

❌ 悪い例：「htmx」を検索しただけで → 「軽量な JS ライブラリで、React の代替です。気に入っている人もいます。出典：htmx.org」— ローカルでの確認も、計画も、相互参照も、確信度ラベルもなく、出典は 1 件だけです。

✅ 良い例（意見の相違を解決）： 「情報源 A（公式ドキュメント、2026 年）ではフラグのデフォルト値はオンとされていますが、情報源 B（広く引用されているブログ、2024 年）ではオフとされています。デフォルト値は v3 で変更されており、B はその前の情報です。」両方を引用し、日付を根拠に食い違いを解決しています。

デフォルトモード（htmx）と比較モードの詳しい手順については、references/EXAMPLES.md をご覧ください。

注意点

• 捏造した引用が、最もよくある失敗です。 URL を引用するのは、この実行中に取得した場合だけにしてください。取得に失敗した場合は、アクセス可能な代替情報源を探すか、その主張を削除してください。もっともらしい URL を決してでっち上げないでください。
• WebFetch は、ペイウォールのあるページや JavaScript で描画されるページでは、定型文しか返さない、または何も返さないことがあります。 その場合、読んだことにはなりません。その旨を伝えるか、アクセス可能なミラーを探してください。検索結果のスニペットを補足情報として使い、full reads に数えることは避けてください。
• 検索上位の情報源が権威ある情報源とは限りません。 多くの技術的な検索では、SEO 目的のコンテンツファームや AI 生成のまとめ記事が一次資料より上位に表示されます。技術的な主張には、公式ドキュメント、.gov／.edu、査読済みの情報源を優先し、公開日は検索結果ではなくページ自体から確認してください。検索結果の日付は、再インデックスされた日であることがよくあります。
• 反論は証拠ではありません。 ユーザーが情報源付きの主張に異議を唱えた場合は、ただ意見を覆すのではなく、もう一度検索してください。「新しい情報源も元の主張を支持している」場合も含め、新しい情報源が示す内容を報告してください。
• マルチエージェントでの全体調査は、最も方向がずれやすい工程です。 各サブエージェントはそれぞれの観点を優先するため、元の質問を読み直すのは最後ではなく、ステップ 6 の合意確認です。
• quick モードでも、3 件以上を比較する場合はマトリクスが必要です。 3 つ以上の選択肢を文章だけで比較すると読みにくくなります。5 行のマトリクスなら、置き換える段落よりも場所を取りません。
• クエリに古い年を指定すると、情報の鮮度が気づかないうちに損なわれます。 情報の鮮度を調べるクエリには現在の年を含めてください。日付を指定しない検索結果は、数年前の情報に偏ります。
• 要約では、情報源の文章がそのまま使われていても明示されないことがあります。 情報源の表現をそのまま使う場合は引用し、出典を明記してください。それ以外の場合は、間接話法で自分の言葉に言い換えてください。各情報源につき、短い引用表現を 1 つ付けるのが基本です。references/EXAMPLES.md の作成例をご覧ください。

統合

• track-session — 長期的な調査プロジェクトでは、計画と情報源の一覧を SESSION_PROGRESS.md に保存すると、作業を中断しても再開できます。
• track-roadmap — 調査結果はロードマップの意思決定に役立ちます。項目には要約を引用してください。
• 調査は意思決定に役立ちますが、意思決定を行うものではありません。ステップ 1 はコードベースを読むこと、ユーザーの好みは AskUserQuestion で確認すること、そして設計上の判断はユーザーに委ねることです。

マルチエージェントによる全体調査モード、メモとして保存するための引き継ぎ、トラブルシューティングについては、references/PLAYBOOK.md をご覧ください。