体系的文献レビュースキル

概要

このスキルは、研究トピックに関する複数の学術論文にわたる構造化された体系的文献レビュー (SLR) を生成します。トピッククエリが与えられると、arXivを検索し、各論文から並列で構造化されたメタデータ（研究質問、方法論、主要な知見、制限事項）を抽出し、全体のテーマを統合し、一貫した引用を含む最終レポートを出力します。

academic-paper-review と異なる点: そのスキルは単一論文の詳細なピアレビューを行います。このスキルは複数の論文にわたって幅広く統合します。ユーザーが1つの論文URLを提示して「この論文をレビューしてください」と言う場合は、代わりに academic-paper-review にルーティングしてください。

このスキルを使用する場合

ユーザーが以下のいずれかを望む場合、このスキルを使用してください:

• トピックに関する文献サーベイ（「トランスフォーマーアテンション変種のサーベイ」、「拡散モデルに関する文献をレビュー」）
• 複数の論文にわたる統合（「Xに関する最近の論文は何を言っているか」、「Y上の論文間で方法論を比較」）
• 一貫した引用形式での体系的レビュー（「Z上のSLRをAPA形式で実施」）
• トピックに関する注釈付き参考文献リスト
• 時間枠での分野における研究トレンドの概要

このスキルを使用しない場合:

• ユーザーが正確に1つの論文を提示してレビューを求める場合（academic-paper-review を使用）
• ユーザーが複数のソースを統合することを必要としない事実的な質問をしている場合（直接回答）
• ユーザーが学術的厳密性のない一般的なウェブリサーチを望む場合（標準的なウェブ検索を使用）

ワークフロー

ワークフローは5つのフェーズで構成されます。順序通りに進めてください。

フェーズ1: 計画

検索を行う前に、ユーザーと以下の事項を確認してください。これらのいずれかが不明な場合は、不足しているピースをカバーする1つの明確化質問を尋ねてください。1度に1つの質問は尋ねないでください。

• トピック: 平易な英語での研究分野（例：「トランスフォーマーアテンション変種」）。
• スコープ: 論文数（デフォルト20、最大上限50）、オプションの時間枠（例：「過去2年間」）、オプションのarXivカテゴリ（例：cs.CL、cs.CV）。
• 引用形式: APA、IEEE、またはBibTeX（ユーザーが指定せず、特定の venue に執筆していないように見える場合はデフォルトAPA）。
• 出力場所: 最終レポートを保存する場所（デフォルト /mnt/user-data/outputs/）。

ユーザーが「50以上の論文」と言う場合は、丁寧に50に制限し、50を超えると統合品質が急速に低下することを説明してください。より大規模なサーベイの場合は、サブトピックに分割するべきです。

フェーズ2: arXivを検索

バンドルされた検索スクリプトを呼び出してください。他の方法でarXivをスクレイピングしようとしたり、独自のHTTPクライアントを書いたりしないでください。このスクリプトはURLエンコード、Atom XMLパース、IDの正規化を正しく処理します。

python /mnt/skills/public/systematic-literature-review/scripts/arxiv_search.py \
  "<topic>" \
  --max-results <N> \
  [--category <cat>] \
  [--sort-by relevance] \
  [--start-date YYYY-MM-DD] \
  [--end-date YYYY-MM-DD]

重要 — 検索する前に2〜3個のコアキーワードを抽出してください。 ユーザーの完全なトピック説明をクエリとして渡さないでください。スクリプトを呼び出す前に、トピックを最も本質的な2〜3の用語に精神的に削減してください。「コンピュータビジョン内」「NLP向け」「変種」「最近」などの修飾子は削除してください。これらは--categoryまたは--start-dateに属し、クエリ文字列には属しません。

クエリの表現 — 短く保つ。 スクリプトはマルチワードクエリをダブルクォートで囲み、arXiv上のフレーズマッチングを行います。これはつまり:

• "diffusion models" → 正確なフレーズを検索 → 良好、関連論文を返します。
• "diffusion models in computer vision" → その正確な5ワードフレーズを検索 → 具体的すぎます、おそらく0件の結果を返します 。その正確な文字列を含む論文はほとんどないため。

クエリとして2〜3個のコアキーワードを使用し、--categoryを使用してフィールドを狭めてください。フィールド名をクエリに詰め込まないでください。例:

ユーザーが言う	良いクエリ	悪いクエリ
"コンピュータビジョンにおける拡散モデル"	"diffusion models" --category cs.CV	"diffusion models in computer vision"
"トランスフォーマーアテンション変種"	"transformer attention"	"transformer attention variants in NLP"
"分子向けグラフニューラルネットワーク"	"graph neural networks" --category cs.LG	"graph neural networks for molecular property prediction"

スクリプトはstdoutにJSON配列を出力します。各論文には: id、title、authors、abstract、published、updated、categories、pdf_url、abs_urlが含まれます。

ソート戦略:

• 常に relevance ソートを使用してください — arXivのBM25スタイルのスコアリングにより、結果は実際にユーザーのトピックについてのものになります。submittedDate ソートはトピック関連性に関係なくカテゴリ内で最も最近提出された論文を返し、ほとんどが外れたトピックの結果を生成します。
• ユーザーが「最近の」論文を求めるか、時間枠を与える場合は、--sort-by relevance を--start-dateと組み合わせて使用し、時間範囲を制約しながら結果をトピックに関連させます。例：「最近の拡散モデル論文」→ --sort-by relevance --start-date 2024-01-01、--sort-by submittedDate ではありません。
• submittedDate ソートは、ユーザーが明示的に時系列順序を求める場合にのみ適切です（例：「公開された順序でしめされた論文を見せて」）。これはまれです。
• lastUpdatedDate はまれに有用です。ユーザーが尋ねない限り無視してください。

検索を正確に1回実行してください。 結果が不完全なように見える場合、修正されたクエリで再試行しないでください。arXivの関連性ランキングはそのようなものです。異なるクエリの表現で再試行すると、ツール呼び出しを浪費し、再帰制限に達するリスクがあります。結果が本当に空である場合（0論文）、ユーザーに伝えてトピックを広げるか、カテゴリフィルタを削除することを提案してください。

スクリプトが要求より少ない論文を返す場合、それはクエリのarXiv結果セットの実際のサイズです。リストをパディングしないでください。実際の数をユーザーに報告して先に進んでください。

スクリプトが失敗する場合（ネットワークエラー、arXivからの非200）、ユーザーにどのエラーかを伝えて停止してください。論文メタデータをでっち上げようとしないでください。

検索結果をファイルに保存しないでください — JSON はフェーズ3のためにコンテキスト内に留まります。ワークフロー全体を通じて保存される唯一のファイルはフェーズ5の最終レポートです。

フェーズ3: メタデータを並列で抽出

task ツールを経由してサブエージェントに抽出を委任する必要があります。メタデータを自分で抽出しないでください。 これは譲歩できません。具体的には、以下の いずれも を行わないでください:

• ❌ python -c "papers = [...]" またはペーパー処理の任意のPython/bashスクリプトを書く
• ❌ インライン抽出をコンテキスト内の抽象を1つずつ読むことで実行
• ❌ task 以外のいかなるツールもこのフェーズで使用

代わりに、task ツールを呼び出してサブエージェントを生成する 必要があります 。理由: 10〜50の論文を独自のコンテキストで抽出すると、多くのトークンを消費し、フェーズ4の統合品質を低下させます。各サブエージェントは論文のバッチのみで独立したコンテキストで実行され、よりクリーンな抽出を生成します。

論文を約5つのバッチに分割し、各バッチについて、subagent_type: "general-purpose" で task ツールを呼び出します。各サブエージェントはテキストとして論文の抽象を受け取り、構造化JSON を返します。

同時実行制限: ターンあたり最大3つのサブエージェント。 DeerFlowランタイムは MAX_CONCURRENT_SUBAGENTS = 3 を実装し、同じターンでそれ以上の発行は黙って削除されます。LLMはこれが起こったことは伝えられないため、以下のラウンド戦略に厳密に従ってください。

ラウンド戦略 — この決定表を使用し、分割を自分で計算しないでください:

論文数	約5論文のバッチ	ラウンド	ラウンドあたりのサブエージェント数
1–5	1バッチ	1ラウンド	1サブエージェント
6–10	2バッチ	1ラウンド	2サブエージェント
11–15	3バッチ	1ラウンド	3サブエージェント
16–20	4バッチ	2ラウンド	3 + 1
21–25	5バッチ	2ラウンド	3 + 2
26–30	6バッチ	2ラウンド	3 + 3
31–35	7バッチ	3ラウンド	3 + 3 + 1
36–40	8バッチ	3ラウンド	3 + 3 + 2
41–45	9バッチ	3ラウンド	3 + 3 + 3
46–50	10バッチ	4ラウンド	3 + 3 + 3 + 1

同じターンで3つを超えるサブエージェントを発行しないでください。 行が「2ラウンド (3 + 1)」と言う場合、それは以下を意味します：最初のターンは3つのサブエージェントを並列で発行し、3つすべてが完了するのを待ってから、2番目のターンは1つのサブエージェントを発行します。ラウンドはメインエージェントレベルで厳密に順序付けられます。

論文数が行と行の間に落ちる場合（例えば23論文）、次の行のレイアウトに切り上げますが、実際に必要なバッチ数だけ発行してください。決定表はあなたに形状を与え、厳密な処方箋ではありません。

メインエージェントレベルでバッチ処理を行う: フェーズ2からすでにすべての論文の抽象を持っているため、各サブエージェントはピュアなテキスト入力を受け取ります。サブエージェントはネットワークやサンドボックスにアクセスする必要がないはずです。その唯一の仕事はテキストを読んでJSONを返すことです。サブエージェントに arxiv_search.py を再実行するよう求めないでください。トークンを浪費し、レート制限のリスクがあります。

各サブエージェントが受け取るもの、構造化プロンプトとして:

このタスクを実行してください: 以下の arXiv 論文から構造化されたメタデータと主要な知見を抽出してください。

論文:
[論文1]
arxiv_id: 1706.03762
title: Attention Is All You Need
authors: Ashish Vaswani, Noam Shazeer, ...
published: 2017-06-12
abstract: <完全な抽象テキスト>

[論文2]
arxiv_id: ...
...

各論文について、これらのフィールドを含むJSONオブジェクトを返してください:
- arxiv_id (文字列)
- title (文字列)
- authors (文字列のリスト)
- published_date (文字列、YYYY-MM-DD)
- research_question (1文、論文が取り組む問題は何か)
- methodology (1〜2文、どのようにそれに取り組むか)
- key_findings (3〜5のバレット、彼らが実際に見つけたもの)
- limitations (1〜2文、彼らが認識しているもの、または明らかに欠けているもの)

結果をJSON配列として返してください。入力と同じ順序で1つの論文ごとに1つのオブジェクト。JSON以外のテキストを含めないでください — 前置きなし、markdownフェンスなし、配列だけ。

サブエージェント結果の解析: taskツールは Task Succeeded. Result: [...JSON...] のような固定プレフィックスを持つ文字列を返します。JSON解析を試みる前に Task Succeeded. Result: プレフィックス（または Task failed. / Task timed out. プレフィックス）を削除してください。バッチが失敗するか、解析不可能なJSONを返す場合、ログに記録し、影響を受けた論文に注記し、残りのバッチで続行してください。1つの悪いバッチで全体の統合を失敗させないでください。

すべてのラウンドが完了した後、バッチごとの配列を1つの論文メタデータオブジェクトのリストにフラット化し、順序を保持してください。

フェーズ4: 統合とフォーマット

最終的なSLRレポートを生成します。ここで2つのことが起こります: 論文間の統合（テーマ分析）と引用フォーマット。

論文間の統合: レポートは論文をリストするだけ以上のことを行う必要があります。最低限、以下を特定してください:

• テーマ: セット全体にわたって繰り返される研究方向、アプローチ、または問題の枠組みの3〜6個。
• 収束: 複数の論文が同意している知見。
• 不一致: 論文が異なる結論に達したり、互換性のない方法論を使用したりするところ。
• ギャップ: 集合的な文献がまだ対処していないもの（「制限事項」フィールドで明示的に述べられていることが多い）。

論文セットが小さすぎるか、テーマ統合をサポートするには不均質すぎる場合（例：劇的に異なるサブトピック上の5つの論文）、レポートで明示的にそれを述べてください。存在しないテーマを強制しないでください。

引用フォーマット: 正確な形式はユーザーの設定によります。ユーザーの要求されたフォーマットに対応するテンプレートファイル のみ を読んでください。3つ全て ではなく:

• templates/apa.md — APA第7版。社会科学とほとんどのCS雑誌のデフォルト。ユーザーがAPAをリクエストするか形式を指定しない場合に使用してください。
• templates/ieee.md — IEEE数値引用。ユーザーがIEEEカンファレンスまたはジャーナルをターゲットにするか、明示的にIEEEを求める場合に使用してください。
• templates/bibtex.md — BibTeX エントリ。ユーザーがBibTeX、LaTeX、または機械可読参考文献を求める場合に使用してください。重要: arXiv論文は@articleではなく@miscとして引用されます。BiBTeXテンプレートはこれを明示的にカバーしています。

各テンプレートには、引用ルールと完全なレポート構造（エグゼクティブサマリー、テーマ、論文ごとの注釈、参考文献、方法論セクション）の両方が含まれます。テンプレートの構造に従ってレポート本文を逐語的に処理し、フェーズ3メタデータからコンテンツを入力してください。

フェーズ5: 保存して提示

完全なレポートを /mnt/user-data/outputs/slr-<topic-slug>-<YYYYMMDD>.md に保存してください。ここで <topic-slug> はトピックの小文字のハイフン区切りバージョンです（例：transformer-attention）。その後、present_files ツールをそのパスで呼び出して、ユーザーがダウンロードできるようにしてください。

チャットメッセージで、短いプレビューを表示して、ユーザーがファイルを開かずにすぐに価値を見てください:

1. エグゼクティブサマリー — レポートの上部からの3〜5文の段落、逐語的。
2. テーマリスト — フェーズ4統合で特定したテーマのバレットリスト（フルテーマセクションではなく、テーマ名+1行の説明だけ）。
3. 論文数+ファイルへのポインタ — 例：「20論文、論文ごとの注釈、フォーマット済み参考文献を含む完全なレポートは slr-transformer-attention-20260409.md に保存されました。」

完全な2000ワード以上のレポートをインラインにダンプしないでください。論文ごとの注釈、参考文献、方法論はファイルに属します。プレビューはユーザーがレポートをさっと判断し、それを開くかどうかを決定できるようにするためのものです。

例

例1: 典型的なSLRリクエスト

ユーザー: 「最近のトランスフォーマーアテンション変種の体系的文献レビューを実施してください。20論文、APA形式。」

あなたのフロー:

1. フェーズ1: トピック（トランスフォーマーアテンション変種）、スコープ（20論文、デフォルト時間枠）、形式（APA）を確認。何か不足している場合のみ 1つ の明確化を尋ねてください（例：「特定の時間枠、または過去3年間がデフォルトですか？」）。
2. フェーズ2: arxiv_search.py "transformer attention" --max-results 20 --sort-by relevance --start-date 2023-01-01。
3. フェーズ3: 20論文 → ラウンド1 = 3サブエージェント × 5論文 = 15カバー、ラウンド2 = 1サブエージェント × 5論文 = 5カバー。集約。
4. フェーズ4: templates/apa.md を読む、その構造を使用してレポートを書く、フェーズ3メタデータからテーマと論文ごとの注釈を入力。
5. フェーズ5: slr-transformer-attention-20260409.md に保存、present_files を呼び出す。

例2: あいまいさを伴う小さいセットリクエスト

ユーザー: 「拡散モデルに関するいくつかの論文をサーベイしてください。」

あなたのフロー:

1. フェーズ1: 「いくつか」はあいまいです。1つの質問を尋ねてください: 「何論文が必要ですか — 10、20、または30？引用形式の設定はありますか（APAがデフォルト）？」
2. ユーザー応答「10、BibTeX」。
3. フェーズ2: arxiv_search.py "diffusion models" --max-results 10 --category cs.CV。
4. フェーズ3: 10論文 → 1つのラウンド、2サブエージェント × 5論文。
5. フェーズ4: templates/bibtex.md を読む、@misc エントリ（@article ではない）でフォーマット。
6. フェーズ5: 保存して提示。

例3: スコープ外のリクエスト

ユーザー: 「ここに1つの論文があります（https://arxiv.org/abs/1706.03762）。これをレビューできますか？」

これは単一論文のピアレビューです。文献サーベイではありません。このスキルを使用しないでください。代わりに academic-paper-review にルーティングしてください。

注記

• 前提条件: subagent_enabled は true である必要があります。フェーズ3は並列メタデータ抽出のために task ツールが必要です。このツールは、ランタイム設定（config.configurable.subagent_enabled）で subagent_enabled が true に設定されている場合にのみロードされます。これがないと、task ツールは利用可能なツールに表示されず、フェーズ3は設計通りに実行できません。
• arXivのみ、仕様によって。このスキルは Semantic Scholar、PubMed、Google Scholar をクエリしません。arXivはCS/ML/物理/数学プレプリントの大部分をカバーしており、DeerFlowユーザーは最も頻繁にサーベイしたいものです。マルチソース学術検索は、このスキル内ではなく、専用MCPサーバーに属します。
• 硬い上限50論文。これはフェーズ3同時実行戦略に関連しています（ラウンドあたり最大3サブエージェント、それぞれ約5論文、最大約3ラウンド）。50を超える論文のサーベイはフェーズ4の統合品質が低下し、サブトピックに分割することでより良く行われます。
• フェーズ3はサブエージェントが有効になっている必要があります。このスキルの並列抽出ステップは task ツールをハード必須とします。このツールは、ランタイムで subagent_enabled=true の場合にのみ利用可能です。サブエージェントが利用不可能な場合、フェーズ3並列計画を実行すると主張しないでください。代わりに、完全なワークフローのためにサブエージェントを有効にする必要があることをユーザーに告げるか、リクエストを縮小/分割してより小さな手動レビューを提供することを提案してください。
• サブエージェント結果は文字列です。オブジェクトではありません。 JSONペイロードを解析する前に、常に Task Succeeded. Result: / Task failed. / Task timed out. プレフィックスを削除してください。
• id フィールドはベアarXiv id です（例：1706.03762）。URLではなく、バージョンサフィックスもありません。abs_url / pdf_url は、必要な場合は完全なURLを保持します。
• 統合、リストではなく。最終レポートは、論文全体にわたるテーマを特定し、知見を比較する必要があります。論文を1つずつリストするだけのレポートは失敗モードです。テーマを見つけることができない場合は、テーマを偽造するのではなく、明示的にそれを述べてください。