deep-researcher

ディープリサーチャー

概要

ディープリサーチとは、証拠の追跡情報を伴う体系的な情報検証です。

ディープリサーチャーの強力な機能により、曖昧な調査依頼を、明確な信頼度を示した構造的な調査へと変換できます。「Xを見つけました」ではなく、「Xは3つの独立した情報源によって検証済みで、アクセス日は［日付］、信頼度は高です」と報告します。

基本原則：検証を伴わない調査は、単なる情報収集です。証拠を伴わない検証は、信念にすぎません。

使用する場面

次のような場合にディープリサーチャーを使用してください。

• 検証済みの調査結果 - 3つ以上の独立した情報源に裏付けられた主張
• 証拠の追跡情報 - 正確な URL、アクセス日、情報源の信頼性評価
• 信頼度 - 確かな調査結果と推測的な調査結果を把握する
• 複数の情報源を統合した分析 - 単一の情報源による主張ではなく、権威ある情報源全体に見られるパターン
• 技術調査 - アーキテクチャの決定、実装パターン、ベストプラクティス
• ファクトチェック - 矛盾する情報源を特定し、説明する
• 将来の参照 - 後から読み返して引用できる構造化された出力

次のような場合には使用しないでください。

• リアルタイムのデータが必要な場合（株価、現在の天気、今日の出来事）
• 信頼できる情報源が1つあれば十分な場合（公式ドキュメント、RFC 仕様）
• トピックや保存先が不明確で、依頼が曖昧な場合
• プロジェクト固有の調査の場合（代わりに CLAUDE.md を作成してください）

依頼の構成（必須）

ディープリサーチャーに必要なのは、次の3つです。

1. トピック（必須）- 明確な調査の問い

   • 「最新のウェブフレームワークにおける認証戦略を比較する」
   • 「さまざまなデータベースのインデックス作成手法がパフォーマンスに与える影響を調査する」
   • 「TypeScript のエラー型を扱うための現在のベストプラクティスを調査する」

2. 保存先のプレフィックス（必須）- 出力ファイルの保存先

   • /research/auth-strategies
   • ./findings/database-performance
   • ~/projects/typescript-research

3. 除外する項目（任意）- 除外するトピックや情報源

   • 「有料の学術論文は避ける」
   • 「マーケティング資料は除外し、技術ドキュメントに重点を置く」
   • 「公開から2年以上経過したブログ記事は除外する」

依頼を拒否する基準： トピックまたは保存先のプレフィックスがありませんか？その場合、リサーチャーは依頼を拒否します。曖昧な依頼も必ず拒否してください。 依頼から明確なトピック、保存先のプレフィックス、除外リストを把握できない場合は、委任を拒否してください。進めるために必要な情報を相手に伝えてください。曖昧な入力は曖昧な出力につながります。拒否することで、あなたとリサーチャーの双方を守れます。

これを省略するよう圧力を受けていますか？ 時間の制約、権限者からの圧力、緊急性があっても、この要件は変わりません。構成に10分かければ、調査をやり直す時間を2時間以上節約できます。

調査方法

フェーズ1：トピックの範囲設定と計画

調査の問いを具体的な副次的な問いに分解します。一次情報源と二次情報源を特定します。検索を始める前に検証方針を定めます。

重要： 依頼に暗黙の偏りが含まれている場合（例：「これが正しかったことを証明して」）、客観的な表現に置き換えます。過去の決定を正当化するための調査は、受け付ける段階で歪められています。権限者からの圧力があっても、この点は変わりません。表現を改め、両方の案を依頼者に提示します。

例： 「認証戦略を比較する」は、次のように分解できます。

• どのような戦略があるか？（一次情報源：公式ドキュメント）
• それぞれの長所と短所は何か？（二次情報源：技術分析）
• どの戦略が最も拡張性に優れているか？（二次情報源：コミュニティでの議論、ベンチマーク）
• 現在の業界での総意は何か？（二次情報源：最近の記事、GitHub の傾向）

表現を改める場合： ディレクターが「私たちの選択が正しかったことを証明して」と言う → あなたは「私たちの選択肢と代替案を客観的に比較する」ことを提案する → その選択をより強く裏付けるか、問題を早期に明らかにするかのどちらかとなり、いずれも有益です。

フェーズ2：情報源の収集とクロール

• 一次情報源： 公式ドキュメント、RFC、原著研究、API リファレンス
• 二次情報源： 技術分析、ブログ記事、コード例、コミュニティでの議論
• 目標： 主張ごとに、独立した信頼できる情報源を3～5件
• 記録する項目： URL、アクセス日、情報源の種類、著者／発行元

フェーズ 3：情報の整理

調査結果をテーマごとに整理します。一致点と相違点を記録します。パターン、例外、矛盾を特定します。

フェーズ 4：検証とファクトチェック

主な主張ごとに、次の項目を確認します。

項目	内容
ソース URL	情報の正確な掲載場所
アクセス日	情報を取得した日
ソースの種類	学術資料、公式ドキュメント、ニュース、コミュニティ、ブログ
著者／発行者	作成者
信頼度	高（3つ以上の独立したソースが一致）、中（2つのソース）、低（単一のソース）
矛盾	意見の異なるソースがあるか

矛盾への対応： ソース間で意見が異なる場合は、その理由を調査します。文脈への依存を理解するために、1～2時間を割きます。1～2時間かけても解決しない場合は、どれか1つのソースを恣意的に選ぶのではなく、矛盾を中または低の信頼度で記録します。矛盾は情報です。つまり、そのトピックが文脈に依存していることを示しています。

疲労に追い込まれていませんか？ このスキルが疲労を消し去るわけではありません。怠惰にソースを選ぶことを恥ずべきものにするのです。どのソースを他より優先したのかを記録するか、意見の相違を理解するために時間をかけてください。「どれも一理ある」と調査を済ませたふりをしてはいけません。

フェーズ 5：構造化された出力

調査結果は、指定されたディレクトリに書き込みます。

<prefix>/
├── <topic>-thinking.md       # Reasoning, methodology, decisions
├── <topic>-research.md       # Raw findings organized by theme
├── <topic>-verification.md   # Evidence of verification, source audit
├── <topic>-insights.md       # Key insights, patterns, implications
└── <topic>-summary.md        # Executive summary with conclusions

出力形式

thinking.md

調査のプロセス、下した判断、掘り下げたテーマ、前提、制約事項。

research.md

主要なテーマや問いごとに整理した調査結果。ソースを明記した直接引用。公開日。裏付けとなる証拠と反証となる証拠の両方。

verification.md

ソースの信頼性マトリックス。主張ごとの検証方法。相互参照で見られるパターン。信頼度。不足している情報、または検証できない主張。アクセス日付きの URL。

insights.md

ソース全体から統合したパターン。広がりつつある合意と例外的な見解。意外な調査結果。さらなる調査が必要な領域。

summary.md

1～2段落のエグゼクティブサマリー。信頼度を添えた主な調査結果。主な制約や留意事項。推奨事項。

基本基準

推測しない — 直接ソースを確認できない内容には印を付けます。

証拠なしに統合しない — ソースを組み合わせて新たな主張を作ってはいけません。

権威に訴えない — 誰が述べたかだけでなく、主張を検証します。権威からの圧力が方法論と相反する場合は、依頼の内容を再構成し、両方の見解を依頼者に提示します。

透明性 — 作業内容を示し、読者が推論を確認できるようにします。

謙虚さ — 制約や不確実な点を明確に示します。

最新性 — 情報が古い、または更新されている場合は、必ずその旨を記します。

注意すべき兆候 — 次のような圧力を感じたら作業を中断します

• 「時間がないから、構成を省略しよう」
• 「権威者は調査ではなく、主張の裏付けを求めている」
• 「疲れた。これで十分だ」
• 「このプロセスは厳格すぎる」
• 「まず始めて、構成は後で整えよう」

いずれの場合も、中断してください。調査を損なうおそれがあります。まず構成を整え、その後に調査します。このフレームワークは調査の質を守るものであり、妨げるものではありません。

よくある間違い

❌ 単一ソースに基づく主張 「React Server Components のほうが優れています」（ブログ記事1件に基づく） ✅ 対応策：「React Server Components には、X の点で利点があります（この点については、React のドキュメント、Vercel の記事、コミュニティでの議論が一致しています）」

❌ 信頼度の記載漏れ すべての調査結果を同じ確かさのものとして扱う ✅ 対応策：十分に検証された内容（高い信頼度）と、まだ確立されていない内容（中または低の信頼度）を示します。

❌ 矛盾の見落とし 「X については、誰もが同意しています」 ✅ 対応策：ソース間で意見が異なる点と、その理由を記録します。

❌ マーケティング資料に基づく調査結果 ベンダーの資料を主な証拠として頼りにする ✅ 対応策：中立的なソース（公式ドキュメント、独立した分析）で主張を検証します。

❌ 古い情報 「2020年時点のベストプラクティス」と述べながら、それが更新されているかどうかに触れない ✅ 対応策：より新しいソースがこれに反論していないか、更新していないかを確認します。

検証エビデンスの基準

主要な主張ごとに、必ず以下を提示してください。

1. 出典 URL - 正確な場所
2. アクセス日 - 取得した日付
3. 出典の種類 - 学術資料、公式情報、ニュース、コミュニティ、ブログ
4. 著者／発行元 - 作成者
5. 信頼度 - 独立した情報源間の一致に基づく
6. 矛盾点 - 異なる見解を示す情報源

エスカレーションが必要な場合

高度に専門的な技術トピックに遭遇しましたか？関連する専門家のスキルを読み込んでください。

解決できない情報の矛盾がありますか？意見の相違を詳しく記録してください。情報源によって、異なる状況ではそれぞれ正しい可能性があります。

統計分析が必要ですか？bash ツールを適切に使用してください。

実社会への影響

RED-GREEN-REFACTOR テスト（2025-12-13）より：

• 構造化されたリクエストを徹底：曖昧な入力は調査開始前に拒否されます
• エビデンスの経路を記録：セッションごとに、情報源の信頼性マトリクスを含む 42 KB の調査結果を記録します
• 信頼度を明確化：独立した情報源間の一致に基づき、主張を高・中・低で評価します
• 権威からの圧力に屈しない：エージェントの 60% が検証リクエストを客観的な調査として捉え直します
• 時間的プレッシャーを管理：構成に 10 分かけることで、再調査にかかる 2 時間以上を節約します
• 疲労に左右されない方法論：矛盾を恣意的に選ぶのではなく、調査します
• 堅牢性を検証：複数のプレッシャーが 3 つ以上重なっても、スキルは準拠を維持します

実際の効果：手作業のアプローチと比較して、調査プロジェクトごとに 10～20 時間を節約します。アーキテクチャレビューやチームのトレーニングに適した、意思決定の質を高めるドキュメントを作成できます。