225 lines
16 KiB
YAML
225 lines
16 KiB
YAML
name: research
|
||
description: |
|
||
Web検索やファイル読み込みによる情報収集と、収集情報の分析・レポート作成。
|
||
複数ソースからの調査、比較分析、トレンド調査、文献サーベイに適する。
|
||
選ぶべき場合: タスクの主目的が「調べること」「情報を集めて整理すること」
|
||
選ぶべきでない場合: 既にデータがあり加工するだけ、Officeファイルの操作が主目的
|
||
triggers:
|
||
keywords: ["調べて", "調査", "リサーチ", "分析して", "比較して", "まとめて", "レポート"]
|
||
max_movements: 999
|
||
initial_movement: dig
|
||
|
||
movements:
|
||
- name: delegate_research
|
||
persona: orchestrator
|
||
instruction: |
|
||
dig で立てた並列調査計画に従い、各テーマを delegate で1件ずつ直列に深掘りさせ、
|
||
最後に統合レポートにまとめる。重い調査は各サブに任せ、自分の文脈は軽く保つ。
|
||
|
||
成果物の上書き防止: システムプロンプトの「現在日時」の日付 (YYYY-MM-DD) を {DATE} とし、
|
||
成果物は {DATE} 入りのパスに書く。**過去の実行が残したファイルは編集も削除もしない**。
|
||
{DATE} 入りの成果物（output/report-{DATE}.md や output/research/{DATE}/ 等、途中で
|
||
中断した実行の残骸も含む）が既にあり、それが別タスクのものなら、{DATE}-2, {DATE}-3 ...
|
||
を全ファイル共通で使う。
|
||
|
||
手順:
|
||
1. dig で立てた調査テーマを思い出す（2〜5 個程度）。各テーマに上から 1 始まりの
|
||
連番を振る（1, 2, 3 ...）。
|
||
2. 各テーマについて delegate を1回ずつ呼ぶ（1件ずつ順番に・直列）。
|
||
delegate の prompt には必ず次を自己完結で書く（サブは独立した文脈で動くため、
|
||
このタスク全体の背景・目的を要約して渡す）:
|
||
- 調べるテーマと目的・背景
|
||
- 「WebSearch / WebFetch / 一次情報で裏を取る。モデルの内部知識だけで書かない」指示
|
||
- 「概要・主要な特徴・数値や事例・まとめと考察 の構成で
|
||
output/research/{DATE}/theme-{連番}.md に Write せよ（{DATE} は展開済みの実日付で渡す）。
|
||
関連する画像・グラフは output/images/{DATE}/ に保存し Markdown で埋め込め」指示
|
||
- 「完了したら 3〜5 行の要約だけを返せ。深掘り本文は返さずファイルに書け」
|
||
- 「あなたは末端の調査担当。delegate / SpawnSubTask は呼ぶな」
|
||
各サブの戻り値（短い要約）だけが手元に残る。本文はファイルにある。
|
||
3. Glob で output/research/{DATE}/*.md の件数を確認する。
|
||
4. 各サブの要約とファイルを基に統合レポートを output/report-{DATE}.md に Write する:
|
||
- 各テーマの主要な知見を統合（矛盾・重複は整理）
|
||
- 比較・対照が必要なら表形式で整理
|
||
- 全体のまとめと考察を付ける
|
||
- 各テーマの詳細へ相対リンク [theme-{連番}](./research/{DATE}/theme-{連番}.md) で繋ぐ
|
||
5. output/report-{DATE}.md を書き終えたら verify へ遷移する
|
||
default_next: verify
|
||
rules:
|
||
- condition: output/report-{DATE}.md に統合レポートを作成した
|
||
next: verify
|
||
|
||
- name: dig
|
||
persona: researcher
|
||
instruction: |
|
||
## 最初のステップ: 入力把握と調査計画
|
||
|
||
情報収集に着手する前に、調査対象と目的を整理する:
|
||
1. Glob でワークスペース全体のファイル一覧を確認する（input/ だけでなくルート直下も含む）
|
||
2. 指示で言及されているファイルがあれば適切なツールで内容を把握する（カタログ参照、詳細は ReadToolDoc）
|
||
3. 調査対象と目的を整理し、どこから情報を集めるか、何を分析するかを明確にする
|
||
4. 「今日のニュース」「最新動向」「直近」など時刻依存の調査依頼では、必ず最初のアクションを WebSearch にする
|
||
|
||
## 分割調査の判断（delegate_research）
|
||
|
||
delegate_research を積極的に検討するケース:
|
||
- 複数の独立した調査対象がある（例: 3社の比較、複数技術の比較）
|
||
- 各調査が互いに依存せず、結果を最後に統合すればよい
|
||
- 全体を 1 回の dig → analyze で処理すると context が溢れるリスクがある
|
||
（delegate_research では各テーマを delegate に1件ずつ任せ、本文はファイルに書かせて
|
||
自分の文脈を軽く保つ。直列実行）
|
||
|
||
delegate_research を使わないケース:
|
||
- 単一テーマの調査
|
||
- 各ステップが前のステップの結果に依存する逐次的な調査
|
||
|
||
## 計画に従って情報を収集する
|
||
|
||
WebSearch、WebFetch、ファイル読み込み等で情報を集め、必ず Write で output/ にファイルとして書き出すこと。
|
||
テキストで回答するだけでは不十分。
|
||
|
||
上書き防止（実行キーの決定・以後の全 movement で共有）:
|
||
システムプロンプトの「現在日時」の日付 (YYYY-MM-DD) を実行キーとする。ただし
|
||
同じ日付入りの成果物（output/report-{日付}.md や作業ファイル・画像等）が既にあり
|
||
別タスクのものなら、空いている {日付}-2, {日付}-3 ... を実行キーにする。
|
||
作業ファイルはファイル名に実行キーを含め、画像は output/images/{実行キー}/ に保存する。
|
||
キーを決めたら最初の作業ファイルをすぐ書き出してキーを確保する（並行する別タスクとの
|
||
衝突の余地を減らす）。analyze・verify もこの実行キーを引き継いで使う。
|
||
**過去の実行が残したファイルは編集も削除もしない**（読むのは可。内容は鵜呑みにしない）。
|
||
|
||
## 検索の原則（必須）
|
||
|
||
- モデルの内部知識だけで情報を書かないこと。主張・事実・数値は必ず WebSearch/WebFetch で裏付けを取る
|
||
- output/ に既存ファイルがある場合でもその内容を鵜呑みにせず、検索で正確性を確認する
|
||
- ユーザーの追加質問への回答には必ず WebSearch で最新情報を改めて確認する。前回の調査結果に依存して検索を省略しない
|
||
|
||
## 一次情報へのアクセスと捏造禁止（厳守）
|
||
|
||
- YouTube 動画の内容を調査する場合は、必ず GetYouTubeTranscript で字幕を取得してから作業する
|
||
- 一次情報（動画字幕、論文本文、ページ本文等）に直接アクセスできなかった場合:
|
||
- Web 検索の断片的な情報から内容を推測・捏造してはならない
|
||
- アクセスできなかった旨を明記し、取得できた範囲の情報のみで成果物を作成する
|
||
- 推測部分は「推測」と明示する
|
||
- 二次情報（ブログ記事、要約サイト等）から得た情報は、一次情報ではないことを明記する
|
||
|
||
## 画像・ビジュアル素材の収集（必須）
|
||
|
||
調査中は画像・グラフ・図表を積極的に収集し、output/images/{実行キー}/ に保存すること。
|
||
テキストだけの調査で終わらせない。ビジュアル素材がレポートの品質を大きく左右する。
|
||
|
||
収集すべきもの:
|
||
- 記事・ページ内のグラフ・チャート・比較表の画像
|
||
- 製品・サービスのスクリーンショットや公式画像
|
||
- データの可視化（統計グラフ、トレンド図等）
|
||
- 関連する図解・インフォグラフィック
|
||
|
||
収集した画像はレポートの Markdown から相対パスで参照する: ``
|
||
|
||
## 終了 / 遷移方法
|
||
- **次の analyze へ**: `transition({next_step: "analyze"})`
|
||
- **分割調査 → delegate_research へ**: `transition({next_step: "delegate_research"})`
|
||
- **追加調査のため同じ dig を続行**: `transition({next_step: "dig"})`
|
||
- **対象が曖昧で確認が必要**: `complete({status: "needs_user_input", missing_info: "...", why_no_default: "..."})`
|
||
- **技術的失敗で打ち切り**: `complete({status: "aborted", abort_reason: "..."})`
|
||
default_next: analyze
|
||
rules:
|
||
- condition: 2つ以上の独立した調査テーマがあり、分割して delegate に任せるのが効率的と判断した
|
||
next: delegate_research
|
||
- condition: output/ に情報を書き出した
|
||
next: analyze
|
||
- condition: 追加調査が必要
|
||
next: dig
|
||
|
||
- name: analyze
|
||
persona: analyst
|
||
instruction: |
|
||
収集した情報を分析し、調査レポートを output/ に作成する。
|
||
重要なポイント、トレンド、結論をまとめる。
|
||
必ず Write ツールで output/ にレポートファイルを書き出すこと。
|
||
前のステップから指摘事項がある場合は、それに対応すること。
|
||
|
||
成果物の上書き防止: レポートのファイル名には dig で決めた実行キーを入れる
|
||
（例: output/report-2026-07-08.md、同日再実行なら output/report-2026-07-08-2.md）。
|
||
dig を経ていない等でキーが不明な場合のみ、同じルール（「現在日時」の日付、
|
||
別タスクの同日成果物があれば空いている -2, -3 ...）で決め直す。
|
||
**過去の実行が残したレポートは編集も削除もしない**。
|
||
このタスク内での verify 差し戻しでは同じファイルを修正してよい。
|
||
|
||
## 検索の原則（必須）
|
||
|
||
- レポートに記載する事実・数値・主張は、dig で収集した検索結果に基づくこと
|
||
- 情報が不足している場合は、ここでも追加の WebSearch/WebFetch を行い裏付けを取る。モデルの内部知識だけで補完しない
|
||
- ユーザーの追加質問への回答には必ず WebSearch で最新情報を改めて確認する。前回の調査結果に依存して検索を省略しない
|
||
- 「これまでのレビュー指摘」「現在の変更状況」「変更差分」の付録がある場合は、そこに書かれた不足点から優先的に解消する。指摘事項は「問題点」「期待する修正」「合格基準」まで含めて渡されるので、各項目を漏れなく解消すること
|
||
|
||
## 画像の活用（必須）
|
||
|
||
output/images/{実行キー}/ にこのタスクで収集した画像がある場合は、
|
||
必ずレポートの該当箇所に実際の保存パスで埋め込む:
|
||
``（例: `./images/2026-07-08/graph.png`）
|
||
画像があるのにテキストだけのレポートにしないこと。
|
||
レポート作成中に追加で必要な図・グラフを見つけた場合も DownloadFile で収集して埋め込む。
|
||
|
||
default_next: verify
|
||
rules:
|
||
- condition: output/ にレポートを書き出した
|
||
next: verify
|
||
- condition: 追加調査が必要
|
||
next: dig
|
||
|
||
- name: verify
|
||
persona: reviewer
|
||
instruction: |
|
||
output/ のレポートを確認する。
|
||
審査対象は**このタスクの実行で作られたレポート**。ここまでの会話で書き出したファイル
|
||
パスをそのまま使う。パスが会話から分からない場合のみ Glob output/report-*.md で列挙し、
|
||
GetFileProvenance で created_by_task_id がこのタスクのものを選ぶ。
|
||
それでも特定できなければ日付と連番を数値として解釈して最新を選ぶ
|
||
（-2 は無印より新しく -10 は -9 より新しい。拡張子込みの辞書順ソートは
|
||
無印が -2 より後に並ぶため使わない）。
|
||
過去の実行が残したレポートは審査対象外で、編集・削除もしない。
|
||
|
||
確認手順:
|
||
1. まず Glob で output/ 内のファイル一覧を確認する
|
||
2. output/ にファイルが1つもなければ「不足がある」と判断し analyze に差し戻す
|
||
3. ファイルがあれば Read で内容を確認し、網羅性・正確性・分かりやすさをチェックする
|
||
4. 不足があれば、`transition({next_step: "analyze", summary: ...})` で差し戻す。summary は次の形式で書く:
|
||
[判定] needs_fix
|
||
## 問題点
|
||
- [ファイル名:行番号または項目名] 何が問題か
|
||
## 期待する修正
|
||
- 何をどう直すべきか
|
||
## 合格基準
|
||
- 再レビューで何を確認するか
|
||
## 次にやること
|
||
- 差し戻し先で最初に着手すべき具体的な作業
|
||
5. summary は抽象論で終えず、変更ファイル・不足点・期待する修正内容を必ず含める
|
||
6. 技術的正確性の再確認が必要な場合は、まず自分で WebSearch / WebFetch で簡易チェックする。深い追加調査が必要な場合は、確認すべき URL・検索語・論点を summary に具体的に書いて analyze に差し戻す
|
||
|
||
追加チェック（追加質問への回答）:
|
||
- ユーザーの追加質問（前回タスクへの補足・深掘り）への回答が含まれる場合、その内容に WebSearch/WebFetch による検索の裏付けがあるか確認する。内部知識だけで回答している形跡がある場合は「追加質問への回答に検索根拠が不足」として analyze に差し戻す
|
||
|
||
追加チェック（画像）:
|
||
- このタスクの実行で収集した画像（output/images/{実行キー}/ 配下）があるのに
|
||
レポートに `![` が一つもない場合、画像埋め込み漏れとして analyze に差し戻す
|
||
（過去の実行が残した画像は対象外）
|
||
|
||
## 合格時のユーザーへの返答（complete ツール）
|
||
|
||
合格と判断したら、`complete({status: "success", result: ...})` を呼ぶ。
|
||
result はそのままユーザーに表示される最終回答。output/ のレポートを Read で読み、その内容をベースに整形する。
|
||
- 「output/xxx.md を確認してください」のようなファイル参照ではなく、内容そのものを回答として返すこと
|
||
- 【厳守】「✅ 完了」「レポートを作成しました」「確認しました」等のステータス表示・メタ説明・内部作業の報告は一切書かない。1行目からいきなり本題の内容を書き始めること
|
||
- 調査結果・発見・結論を会話調で分かりやすく伝える
|
||
- 表・リスト・見出しなど Markdown 書式を活用して読みやすくする
|
||
- 長大なレポートの場合は要点を構造化して提示し、詳細は省略してよい
|
||
- 補足や今後の検討事項があれば末尾に添える
|
||
|
||
## 終了方法のまとめ
|
||
- 合格: `complete({status: "success", result: "ユーザー向け最終回答"})`
|
||
- 修正必要: `transition({next_step: "analyze", summary: "差し戻し指摘"})` (上記形式で)
|
||
- 技術的失敗: `complete({status: "aborted", abort_reason: "..."})`
|
||
default_next: COMPLETE
|
||
rules:
|
||
- condition: output/ にファイルがない、または内容に不足がある（追加質問への回答に検索根拠が不足している場合も含む）
|
||
next: analyze
|