deep-research

deep-research スキルの概要

deep-research スキルは、あるテーマを調査し、複数の情報源を比較し、出典付きで統合的な答えを返すための、構造化されたリサーチワークフローです。単なる素早い要約では足りず、根拠の確認や論点の抜け漏れを避けたいユーザーに向いています。たとえば、アナリスト、ライター、起業家、学生、オペレーション担当者など、ソースの質や視点の広さが重要な Web リサーチを行う人に特に適しています。

deep-research は実際に何のためのスキルか

deep-research を使うべきなのは、依頼内容が単に「この質問に答えて」ではなく、「この質問をきちんと調べてほしい」というケースです。このスキルは、エージェントに次の流れを踏ませます。

• 調査目的を明確にする
• テーマをサブクエスチョンに分解する
• 複数の視点から情報を集める
• 情報源の信頼性と新しさを評価する
• リンクを並べるだけでなく内容を統合して整理する
• 出典付きの分析としてまとめる

そのため、出力にトレーサビリティ、バランスの取れたカバレッジ、意思決定に使える要約が求められる場合は、通常のプロンプトより適しています。

向いているユーザーとタスク

deep-research skill が特に力を発揮するのは、次のような用途です。

• 市場調査や競合比較
• 政策・規制の概観整理
• 技術領域の動向調査
• 文献レビュー的なトピック要約
• 創業者向けのデューデリジェンスやベンダー評価
• 出典の明示が重要なあらゆる Web リサーチ

一方で、単純な事実確認、創造的なブレインストーミング、あるいは要約すべき情報源が最初から完全に決まっているタスクには、そこまで向いていません。

deep-research が汎用プロンプトと違う点

最大の違いは、プロセスに規律があることです。モデルに「X を調べて」と投げるのではなく、deep-research は「範囲を明確にする → 観点を定義する → 情報源を集める → 品質を見極める → 統合する」という再現可能な手順を与えます。これにより、通常は次の点が改善しやすくなります。

• 情報源の多様性
• 対立する見解まで含めたカバレッジ
• 引用の質
• 回答全体の構成

実運用では、ユーザーが気にするのは「そのエージェントのレポートを信頼して再利用できるかどうか」です。deep-research は、その結果を得やすくするために設計されています。

インストール前に確認したいこと

このリポジトリ配下の実装は軽量です。コアロジックは SKILL.md にまとまっており、ツリープレビュー上では追加のスクリプト、ルール、参照ファイルは見当たりません。すぐ導入しやすい反面、得られるのは主にプロンプトとワークフローの指針であって、専用ツール、ソースパック、自動化ヘルパーではないと考えてください。

もし必要なのが、そのまま使えるクローラー、データセットのパイプライン、独自ランキング機構なら、deep-research 単体ではかなりミニマルです。

deep-research スキルの使い方

Skills 対応環境に deep-research をインストールする

エージェント実行環境が Skills に対応しているなら、リポジトリから deep-research をインストールできます。

npx skills add Shubhamsaboo/awesome-llm-apps --skill deep-research

インストール後は、対応するエージェント環境からこのスキルをアタッチまたは呼び出してください。リポジトリ上の構成を見る限り、単一ファイルのスキルなので、追加設定はほとんどありません。基本的には追加したうえで、エージェントに Web アクセスまたは調査対象の資料を渡せれば動かしやすいです。

最初に読むべきファイル

まず確認すべきなのは次です。

• awesome_agent_skills/deep-research/SKILL.md

追加の補助ファイルが見えていないため、SKILL.md が次の点に関する事実上の一次情報になります。

• どんな場面でこのスキルを使うべきか
• 調査の進め方
• 出力に何が求められているか
• どんな推論順序を想定しているか

deep-research に最低限必要な入力を把握する

deep-research usage は、最初に次の4点を渡すだけでかなり精度が上がります。

1. 調査したい問い
2. 調査の目的
3. 求める深さ
4. 優先したい観点や制約

弱い入力例:

• “Research AI chips.”

より良い入力例:

• “Research the AI chip market for enterprise inference in 2024–2025. Compare NVIDIA, AMD, Intel, and custom cloud accelerators. Focus on pricing signals, software ecosystem maturity, deployment constraints, and buyer switching costs. Deliver a cited executive summary for a CTO deciding whether to stay standardized on CUDA.”

後者は、調査範囲、比較フレーム、意思決定の文脈が明確なので、スキル側も狙いを外しにくくなります。

ざっくりした目的を使える調査ブリーフに変える

良い deep-research guide は、曖昧な意図を調査軸に落とし込むところから始まります。実行前に、少なくとも以下を明確にしておくと有効です。

• テーマまたは判断したい意思決定
• 対象期間
• 地理的範囲
• 誰の視点で見るか
• 必ず扱うべきサブトピック
• 欲しい出力形式
• 許容できる情報源
• 除外したい論点

簡潔なテンプレートにすると、次のように整理できます。

• Objective: 何を判断・理解したいのか？
• Scope: 何を含み、何を除外するのか？
• Time range: ソースはどこまで新しい必要があるのか？
• Perspectives: 誰の視点を比較するのか？
• Deliverable: summary, memo, table, or recommendation?
• Citation expectation: inline citations, source list, or both?

これは重要です。deep-research は明示的に、調査質問を明確にし、重要な観点を特定するところから始まるためです。

deep-research は単なる要約ではなく Web リサーチに使う

deep-research for Web Research は、1本の記事を言い換えるよりも、複数の生きた情報源やユーザー提供資料を横断して確認できるときに真価を発揮します。このスキルの価値は、複数ソース・複数視点をまたいだ統合にあります。

実務で使いやすい流れは次のとおりです。

1. 問いを定義する
2. 候補となる情報源を集める
3. エージェントに信頼性と新しさを評価させる
4. パターン・対立点・抜けを統合させる
5. 最後に引用付きのレポートを出させる

ソース収集と統合作業を省くと、せっかくの deep-research が普通の要約プロンプトに近づいてしまいます。

発見事項だけでなくソース評価も求める

deep-research の特に有用な点のひとつは、信頼性チェックがワークフローに明示的に組み込まれていることです。プロンプトでは、エージェントに次の点も書かせると効果的です。

• どのソースが一次情報で、どれが二次情報か
• どれだけ新しい情報か
• 利害相反がありそうか
• 根拠が薄い部分、見解が割れている部分はどこか

これは、変化の速いテーマ、ベンダー主張、医療情報、政策解釈、市場規模の推計などでは特に重要です。

deep-research の結果を安定させる出力構成

deep-research usage の再現性を高めたいなら、あらかじめ次のような出力構成を指定すると有効です。

1. research question
2. scope and assumptions
3. key findings
4. source-backed evidence by subtopic
5. areas of agreement and disagreement
6. confidence or evidence-quality notes
7. open questions
8. cited conclusion

この形はスキルが想定する統合ワークフローと噛み合っており、浅いリンク集で終わるリスクを下げられます。

deep-research をうまく呼び出す実践的なプロンプトパターン

有効な呼び出しパターンの例です。

“Use deep-research to investigate [topic]. Clarify the research question first, break it into subtopics, gather information from multiple perspectives, evaluate source credibility and publication date, then synthesize findings with citations. Prioritize [angles]. Exclude [out-of-scope items]. End with key conclusions, uncertainties, and recommended next questions.”

このパターンが機能しやすいのは、スキル内部の手順に逆らわず、その順序を補強しているからです。

deep-research 実行前にスコープを絞るべきタイミング

実務で最も詰まりやすいのは、スコープが広すぎるケースです。最初の依頼があまりに多くの市場、年次、ステークホルダーをまたぐと、出力品質はほぼ確実に落ちます。まずは次のいずれかで絞り込みましょう。

• 1つの地域
• 1つの購買担当者像
• 1つの期間
• 1つの意思決定テーマ
• 1つの比較対象セット

例:

“Research remote work software” とする代わりに、次のようにします。

• “Compare Notion, Confluence, and Coda for 500-person engineering organizations in 2025, focusing on governance, search quality, AI features, and migration risk.”

このリポジトリが提供しないもの

この deep-research install はシンプルですが、次のようなものが最初から入っているとは期待しないでください。

• 組み込みの検索・取得スクリプト
• 独自ランキングや引用管理のツール
• 情報源ライブラリ
• ドメイン特化ルール
• コアガイダンス以外の完成済み出力テンプレート

つまり、導入自体は簡単ですが、結果の良し悪しは自分のプロンプト設計と実行環境の能力に強く左右されます。

deep-research スキル FAQ

deep-research は普通の調査プロンプトより優れているか？

多くの場合は yes です。特に、構造化、情報源比較、引用が必要なタスクでは差が出やすくなります。単純なプロンプトでも素早く答えは返せますが、deep-research のほうが次を実現しやすい傾向があります。

• サブトピックを分けて扱う
• 複数の視点をカバーする
• 情報源の質を確認する
• 再利用しやすい調査サマリーにまとめる

ただし、単純な事実確認だけなら、この追加構造は過剰です。

deep-research は初心者にも向いているか？

はい。スキル自体は読みやすく軽量で、中心となるワークフローは1つの SKILL.md にまとまっています。そのため、追加ツールなしで再現可能な調査手順を使いたい初心者にも入りやすい構成です。

一方で、トレードオフもあります。初心者であっても、最低限まともな調査ブリーフは書く必要があります。deep-research はプロセスを整えてくれますが、曖昧な目的を勝手に正解へ変換してくれるわけではありません。

deep-research スキルを使わないほうがいいのはどんなときか？

次のような場合は deep-research を使わないほうがよいです。

• とにかく素早い答えだけが欲しい
• すでに固定のソースセットがあり、要約だけでよい
• タスクの性質が分析より創作寄りである
• エージェントにソースへのアクセスがなく、根拠評価がしにくい

また、専門データベースや正式な法務・医療レビューが必要な、強く規制された領域の業務にもあまり向きません。

deep-research に Web アクセスは必須か？

必須ではありませんが、特に最新性が重要なテーマでは、複数ソースにアクセスできる環境のほうが明らかに強いです。Web アクセスがなくても、ユーザー提供のコーパスに対して deep-research skill を使うことはできます。ただし、ソースの広さや鮮度は、与えた資料次第になります。

deep-research は食い違うソースをどう扱うか？

このワークフローでは、発見事項を統合しつつ、合意点と不一致点を明示することが前提になっています。実際には、エージェントに次のように指示するとよいです。

• 競合する主張を併記する
• より強い根拠がどちらにあるかを示す
• なぜ見解のズレが生じているかを説明する

無理に単一の結論へ押し込むより、そのほうが実務では役に立ちます。

deep-research を社内調査に使えるか？

使えます。必要な資料を渡せば、同じプロセスを社内文書、顧客インタビュー記録、戦略メモ、競合メモにも適用できます。どのソースを信頼すべきか、外部 Web 調査も含めるかを明示してください。

deep-research スキルを改善する方法

deep-research に意思決定の文脈を与える

出力を最も手早く改善する方法は、「この調査結果を何に使うのか」を明示することです。“Research this topic” より、次のように言うほうが強いです。

• “I need to choose a vendor,”
• “I need an investor memo,”
• “I need a balanced brief for executives,”
• or “I need a literature-style overview.”

意思決定の文脈があると、deep-research は情報量の多さよりも関連性の高い整理を優先しやすくなります。

比較軸を最初に指定する

弱い調査出力の多くは、モデルが勝手に比較軸を決めてしまうことから始まります。より良い deep-research の結果を得たいなら、軸は自分で与えてください。

例:

“Compare by total cost, integration difficulty, compliance support, switching risk, and evidence strength.”

このように指示すると、ありがちな一般論の pros/cons リストより、意思決定に使える比較に近づきます。

ソース品質の期待値を明示する

引用の質が重要なら、その条件をはっきり伝えてください。エージェントには、次を優先するよう求めるとよいです。

• 可能な限り一次情報
• 変化の速いテーマでは新しい資料
• 一次情報がない場合は、出所が明示された二次的コメント

加えて、根拠の薄い部分は取り繕わず、弱いと明示するように求めてください。

全体統合の前にサブトピックの地図を作らせる

実務で効く改善策として、次の手順があります。

1. まずエージェントにサブトピック案を出させる
2. それを確認して修正する
3. その後にフルリサーチを走らせる

これにより、重要な論点の取りこぼしが減り、最終レポートも本来の問いに沿いやすくなります。

よくある失敗パターンを修正する

deep-research usage でよくある失敗は次のとおりです。

• スコープが広すぎる
• 情報源の多様性が足りない
• 引用はあるが質が弱い
• 発見事項が列挙にとどまり、統合されていない
• 見解の対立が無視されている
• 結論が確実性を言い過ぎている

これを直すには、次を求めると効果的です。

• より狭いスコープ
• ソース種別の多様性を明示
• 根拠の質に関する注記
• 合意点と不一致点のセクション
• 短い limitations セクション

不確実性と次の調査課題を必ず出させる

強い調査アウトプットは、何もかも確定しているようには見せません。deep-research を改善したいなら、次を必須項目にしてください。

• 未解決の問い
• データの欠落
• 置いた前提
• 次に何を調べるべきか

これは、最初の調査が探索的で、2回目以降の深掘り方針を決める役割も持つ場合に特に有効です。

最初の出力を捨てず、そこから反復する

最初の結果が部分的にしか合っていなくても、最初からやり直す必要はありません。改善ループとして最も効果的なのは次です。

• 足りない観点を特定する
• 1つのサブトピックをより深く掘るよう依頼する
• ソース基準を厳しくする
• 統合結果の改訂版を出させる

フォローアップ例:

“Expand the disagreement section on open-source vs. proprietary models. Add newer sources, separate vendor claims from independent analysis, and revise the conclusion to reflect evidence strength.”

多くの場合、ゼロから再実行するよりこちらのほうがうまくいきます。

重要度の高い案件では自分のソースリストと組み合わせる

ハイステークスな業務では、最初から次のような資料を渡しておくと信頼性が上がります。

• 必読ソース
• 押さえておくべき一次文書
• 信頼できる専門家の出版物
• すでに社内で信用している資料

deep-research は統合に役立ちますが、入力をこちらでキュレーションしておくことで、もっともらしい誤権威づけや弱いソースへの流れを抑えやすくなります。

最終的な依頼内容は具体的にする

deep-research skill は、最終成果物が具体的に定義されているときに最も安定します。依頼するなら、たとえば次のいずれかに落とし込んでください。

• executive memo
• comparative table
• source-backed brief
• literature-style summary
• recommendation with caveats

“tell me everything about this topic” のような曖昧な依頼より、具体的な成果物を指定したほうが、整理された実用的な調査結果になりやすいです。