research

research

トピックをしっかり調査します。複数の独立した情報源から情報を集め、主張を検証し、事実と意見を分け、日付付きの出典を示して報告してください。調査と報告の「方法」を定める基準は references/methodology.md に記載されています。作業を始める前に読み、すべてのサブエージェントにも渡して、全員が同じ形式で作業を仕上げられるようにしてください。

このスキルには2つの深さがあります。深さを選び、それぞれのワークフローに従ってください。

深さの選択

ユーザーが「deep research」「deep dive」「go deep」「thorough/exhaustive research」と言った場合、または --deep を指定した場合は、Deep モードです。Deep モードでは複数のサブエージェントを並行して動かし、保存された Markdown レポートとインタラクティブな HTML ページの両方を必ず作成します。

それ以外はStandard モードです。チャットで回答する、焦点を絞った単独の調査を行います。これが「research X」「look into Y」「what's the latest on Z」のデフォルトです。

トピックが明らかに広大（「分散データベースの全史を調査する」など）で、ユーザーが「deep」と言っていない場合は、Standard モードで調査します。ただし、Deep モードがあることを伝えてください。「範囲が広いため、焦点を絞って調査しました。全体を並行調査してインタラクティブページも作成したい場合は、『deep research』と言ってください。」 と伝えます。黙ってモードを引き上げないでください。並行調査にはコストがかかるため、ユーザーが選択できるようにしてください。

---

Standard ワークフロー

1. 範囲を定める。 何を回答するのかを1文で言い直します。依頼が本当に曖昧で（2通りの解釈が可能で）、それによって回答が変わる場合は、簡潔な確認質問を1つしてください。それ以外はそのまま進め、簡単な調査の前にユーザーへあれこれ質問しないでください。
2. 調査する。 references/methodology.md に従って、的を絞った検索を行います。まず公式ドキュメントを確認し、重要な主張を独立した情報源と照合し、最新性が重要な場合は新しい情報源を優先し、矛盾する証拠も積極的に探してください。
3. チャットで報告する。 references/methodology.md の構成（エグゼクティブサマリー → 証拠と確信度を示す調査結果 → 矛盾点／不確実性 → 結論 → 出典）に従って、出典を明記したレポートを会話内に直接記載します。簡潔にまとめ、最初に答えを示してください。
4. 追加の選択肢を提示する。 最後に次の1行を添えます。「これを Markdown ファイルに保存しますか、それともインタラクティブページにしますか？ サブトピックを並行して調査する場合は『deep research』と言ってください。」 Standard モードでは、依頼がない限りファイルを保存したりページを作成したりしないでください。納品物はチャットでのレポートです。

---

Deep ワークフロー

4つのフェーズがあります。領域を整理するフェーズ（フェーズ1）と、実際に調査するフェーズ（フェーズ2）を分けることで、ただ検索回数を増やすよりも優れた結果が得られます。むやみに調査を分散するのではなく、実態があり、互いに異なると確認できた分野に並行調査のリソースを振り分けられます。

フェーズ1 — 予備調査

まず自分で広く調べ、トピックの全体像を把握し、主要な情報がどこにあるのかを見つけます。ここでは、まだ結論を出す必要はありません。目的は、トピックを全体的にカバーする、互いに重複しない4〜8個の調査可能なサブクエスチョン（「分野」）に分解することです。優れた分野はそれぞれ独立して調査でき、互いに重複しません（例：「CDC における論理レプリケーションと Debezium の比較」なら、運用オーバーヘッド、大規模環境でのスループット／レイテンシ、スキーマ変更への対応、障害モードと復旧、エコシステム／ツールの成熟度、コスト）。

並行調査を始める前に、分野のリストをユーザーに提示して確認を取ります。

並行して調査する分野：

1. ...
2. ...

次のステップ： このまま進めますか？ それとも、先に分野を調整しますか？

ユーザーがすでに「そのまま進めて」「質問しないで」「X を deep research してページを作って」と言っている場合に限り、確認のための待機を省略します。それ以外の場合は返答を待ってください。ここで調査範囲を見直すのは簡単ですが、5つのエージェントを再実行するのは簡単ではありません。

Phase 2 — 並列ファンアウト

ブランチごとにサブエージェントを1つずつ起動し、最大5つまでにします（調査でブランチが5つを超えた場合は、最も近いもの同士を先に統合します）。ハーネスが対応していれば、同時に起動してください。Claude Code の場合は、1つのメッセージで複数の Agent 呼び出しを行います。対応していない場合は、順番に実行します。調査の質は変わらず、時間がかかるだけです。

各サブエージェントには、ウェブ検索とウェブ取得を使えるようにする必要があります（Claude Code の場合は subagent_type: general-purpose）。各エージェントへのプロンプトには、次を含めてください。

• ブランチに関する質問と、1行の調査範囲の境界（「X のみを扱い、Y は別のエージェントが担当します」）。
• パスを解決したうえで、次の指示を記載します。 「このスキルのディレクトリにある references/methodology.md を読み、情報源の品質、検証、引用に関する基準に従ってください。定義されているレポート形式で、ブランチのミニレポートを返してください。」 送信前に実際の絶対パスに置き換えてください。サブエージェントには、渡されていないスキルの相対パスを解決する方法がありません。
• 全体の調査に関する質問。ブランチの調査がユーザーの本来の目的から外れないよう、背景として共有します。
• 返してほしいもの。最終メッセージとしてミニレポート（引用付きの調査結果、確信度、検証できなかった内容の明記）を返すよう伝えます。実装やファイル編集はせず、調査と報告のみを行うよう指示してください。

サブエージェントからレポートが返されますが、自動的にユーザーに表示されることはありません。必要な情報を引き継ぐのはあなたです。

Phase 3 — 統合

ブランチのレポートを統合し、ひとつの一貫した調査結果にまとめます。単に連結しないでください。

• 複数のブランチで見つかった内容を相互参照して重複を取り除き、最も強い情報源を残してまとめます。
• references/methodology.md の競合形式に従って、ブランチ間の矛盾を解決するか、明示します。ブランチ間の意見の相違は隠すべき問題ではなく、調査結果のひとつです。
• 調査結果ごとに全体的な確信度を付け、調査全体を通して確認できなかった点を明記します。
• 完全なレポート形式を使って、マスターレポートを ./research-<topic-slug>.md に Write します。このファイルが長期保存される成果物であり、ページの情報源になります。

Phase 4 — rich-page への引き継ぎ

保存したレポートを情報源として渡し、Skill ツール経由で rich-page スキルを呼び出します。

Build a rich visual HTML page from this research report: ./research-<topic-slug>.md
Audience: <whoever the user mentioned, else "the user / their team">. Language: <match the report>.
Output path: ./research-<topic-slug>.html
Just build it — don't ask for confirmation on the visual plan.

rich-page は調査バンドルを情報源として受け取れます。Phase 1 では Markdown レポート全体を読み、「視覚化候補のポイント」を特定します（定量的な主張にはグラフ、「X と Y の比較」のブランチには比較切り替え、言及されたアーキテクチャにはノード図など）。「そのまま作成して」と伝えると、Phase 2 の確認待ちを省略できるため、詳細調査の実行を別の承認待ちではなく、成果物が完成した状態で終えられます。完了したら、Markdown レポートと HTML ページの両方のパスを、短いメッセージでユーザーに伝えます。また、任意のブランチの再調査やページのスタイル変更を依頼できることも伝えてください。

---

調査はあなたが行い、判断は人間が行います

レポートが完成したら、そこで止まり、ユーザーに判断を委ねてください。 調査は、人間が何を作るか、どの選択肢を選ぶか、ある主張が妥当かを判断するためのものです。「調査結果はこちらです」と伝えた直後にコード、設定、依存関係の変更に進むと、調査が生み出すはずだった判断の機会が失われます。しかも、ユーザーがまだ読んでいない調査結果に基づいて実行することになります。

そのため、調査結果を提示した後（標準モード）、または成果物を引き渡した後（詳細モード）は、実装、リファクタリング、再設定、あるいは「最善の方法を適用しておきます」といった対応をしないでください。情報源や分析に関する追加の質問には答え、ユーザーから次の指示があるまで待ちます。唯一の例外は、詳細モードでの rich-page への引き継ぎです。これは調査成果物の作成に含まれるものであり、その後の作業に着手することではありません。

---

参考ファイル

• references/methodology.md — 情報源の品質の階層、検証方法、引用形式、注意すべき兆候、レポートの構成が記載されています。調査を始める前に読み、詳細モードでは各サブエージェントにも共有してください。

---

Originally derived from mattpocock/skills, MIT © 2026 Matt Pocock. このファイルをコピーする場合は、この行を残してください。