scoop-check

スクープチェック

提案された研究の新規性が既存文献と重複していないか、体系的に検証します。目的は、（a）主張をすでに扱っている先行研究を明らかにするか、（b）提案された貢献を区別する、明快で根拠のある「差分」の記述を作成することです。

入力

このスキルでユーザーから受け取る入力は、厳密に2つです。

1. 研究課題 — 取り組む対象となる、具体的な問題、課題、または知識のギャップ。
2. 新規性 — 先行研究と区別される、具体的に主張する貢献（新しい手法、定理、データセット、枠組み、または知見）。

いずれかの入力が欠けている、曖昧である、または混同されている（例：「新規性」が単に問題を言い換えただけである）場合は、最も妥当な解釈を推定し、ただちに作業を進めてください。どの時点でもAskUserQuestionを使用したり、確認のために作業を中断したりしないでください。常にすべてのステップを順に実行してください。

手順

以下のステップを順番に実行してください。手順の開始時に、TaskCreateを使って7つのステップすべてをタスクとしてあらかじめ登録し、各ステップの開始時にin_progress、完了時にcompletedにしてください。この手順は、進捗を記録する手間に十分見合う長さです。進捗を追跡しないと、ステップを飛ばしやすくなり（特に「重要な注意事項」にある各ステップのログ記録）、詳細に調査すべき候補を見失うおそれがあります。

ステップ1 — 新規性を分解する

主張する新規性を4つの独立した軸に分解し、ラベル付きのリストとして提示してください。

• 問題の枠組み — タスクの定義、入力、出力、評価方法。
• 中核となる仕組み — アーキテクチャ、アルゴリズム、証明手法、データ構築など、技術的な貢献。
• 主要な着想 — 何が機能する理由か。先行する最先端の手法に何が欠けていたか。
• 適用領域 — どこに適用されるか、またその適用範囲はどれほど広いか。

Step 2 — 検索と重複排除

Research problemを読み、相互に補完する検索クエリを3つ作成します。

• **Query 1 — Original-Problem：**元の研究課題を言い換えます。 例： score-based generative model fast inference
• **Query 2 — Broad-Domain：**上位レベルの分野を、約3～5語で表します。 例： diffusion model sampling efficiency
• **Query 3 — Method-Signature：**具体的な技術的アプローチを、約5～8語で表します。 例： consistency model knowledge distillation

3つすべてのクエリを、.claude/skills/にある**paper-search**スキルに送信します。paper-searchは複数のソースに対して統合クエリを実行し、タイトル、要旨、メタデータを含む構造化JSONを返します。

3つのクエリはそれぞれ別のプロセス呼び出しとしてarXivに送信されるため、レート制限（HTTP 429）を引き起こしてコネクタの出力がひそかにゼロになるのを避けるために、隣接するarXivリクエストの間隔を4秒以上空けてください。paper-searchのarXivモジュールは、プロセス間で共有されるファイルロック（tempディレクトリ内のarxiv_search_throttle.lock）によってこれを自動的に適用します。そのため、同時または連続して実行されたクエリは順番に処理され、各リクエストは前回から4秒以上経過してから送信されます。手動でスリープを追加する必要はありませんが、arXivを直接呼び出してこのモジュールを迂回しないでください。間隔を変更する必要がある場合は、ARXIV_MIN_INTERVAL env varのみを使用してください。

次に、3つのクエリの検索結果を統合し、タイトルで重複を排除します（比較の前に、大文字と小文字の違いと空白を正規化してください）。

検索結果を統合した後、検索結果に現れなかったものの、Research problemまたはNoveltyに直接関連する、学習時の知識から想起した追加論文を候補に加えます。この手順が必要な理由は、paper-searchがインデックス済みのソースとのキーワード一致に依存しており、画期的な先行研究や異なる表現で説明された先行研究を見落とすことがよくあるためです。こうした先行研究を把握していても、代表的な文献の記載漏れは、新規性の確認が失敗する最も一般的な原因です。想起した論文には、検索結果と同じフィールド（Title、Date、判明している場合はSource）を付け、パイプラインの残りの処理で同様に扱えるようにします。

想起した論文には、以下の制約を適用します。

• **重複させない。**想起した論文を追加する前に、正規化したタイトル（および利用可能な場合はarXiv ID / DOI）を使い、重複排除済みの検索結果と照合します。すでに含まれている論文は追加しないでください。
• **出典を明記する。**各想起項目にSource: model-recallを付与します（提供できるURL/IDがあれば、それも併記します）。これにより、後続のステップで、その項目がライブ検索から取得されたものではなく、Step 5で追加確認が必要な場合があるとわかります。
• **関連性を保ち、件数を控えめにする。**実在に確信があり、直接関連する論文のみを追加します。通常は0～5件です。確信を持って想起できる論文がなければ、何も追加しないでください。引用を捏造することは、候補を少なくするよりはるかに悪い結果につながります。
• **不確実な情報には印を付ける。**想起した論文の正確な日付、掲載先、著者一覧が不確かな場合は、推測せずに該当フィールドを空欄にします。Step 5の詳細調査で実際のPDFを確認し、情報を補います。

統合したセット（検索結果＋重複しない想起論文）を次のステップに渡します。

Step 3 — 抽象レベルでのトリアージ

重複を除いた各論文について、タイトルと要旨を読み、次の項目を含む一次記録を作成します。

• Title — 論文の正式なタイトル。
• Date — 発表日またはプレプリント公開日（YYYY-MM）。
• Problem framing — 論文が対象とするタスク、入力、出力、評価の設定。
• Core mechanism — 主な技術的貢献（アーキテクチャ、アルゴリズム、証明手法、データ構築手法）。
• Key insight — 貢献を可能にする中心的なアイデア。先行研究に欠けていた点。
• Application domain — 手法を適用または評価する分野、モダリティ、設定。
• Overlap score (0–4) — 4つの軸（problem framing、core mechanism、key insight、application domain）のうち、提案する新規性と一致する可能性がある軸の数。要旨のみを基に判断します。この数は、Step 6 の5段階の判定に level = 5 − (axes matching) として反映されます（軸の一致が0個 → Level 5／最も新規性が高い、軸の一致が4個 → Level 1／完全に先行研究に含まれる）。
• Source — 全文を取得するために必要なURL、arXiv ID、DOI、その他の識別子。トリアージでは通常、ホスト名から会場を十分に推測できます（例：arxiv.org → プレプリント、openreview.net → 会議投稿、出版社のドメイン → 査読済み）。正式な会場は、実際に必要になった Step 5 で記録します。

要旨は短く、論文が実際に貢献を先取りしているかどうかを判断する詳細が隠れていることがよくあります。手法上の前提、実験の範囲、制限事項は、本文にしか記載されていないことが少なくありません。そのため、重複スコアはトリアージの目安であり、最終判定ではありません。

Step 4 — 有望度の高い候補を特定する

新規性の主張を脅かす、または裏付ける可能性が最も高い論文を選びます。ここでの入力は、Step 3 の統合済みの論文一式です。paper-search の検索結果と、Step 2 の記憶拡張パスで想起され、重複していない論文の両方が含まれます。以下の基準をすべての論文に一律に適用してください。追加したという理由だけで、想起された論文を自動的に優先してはならず、Source が model-recall だからという理由だけで自動的に優先度を下げてもいけません。他の論文と同じ基準で候補に選ばれる必要があります。

以下のいずれかに該当する場合、その論文は有望度の高い候補です。

• 要旨の段階で重複スコアが2以上。
• 応用分野や問題設定が異なっていても、要旨がcore mechanismで一致している（手法の重複が最も危険な重複です）。
• 同じ狭いサブ分野の論文で、重複スコアが低くても過去24か月以内に発表されている。近年の近接領域の研究は、貢献を先取りしている可能性が最も高いためです。
• 手法について要旨が曖昧で、一致を裏付ける可能性も否定する可能性もある。つまり、要旨だけでは安全に除外できない論文です。

トリアージ後の候補数は、上位の3～7件に制限します。この上限が適用されるのはフィルター後の選定結果であり、Step 3 の入力数ではありません。そのため、検索結果と想起結果を合わせた候補群が大きくても、ここで絞り込めば問題ありません。基準を満たす論文が7件を超える場合は、重複スコアが最も高い7件を残します（同点の場合は、手法の一致と新しさを優先します）。基準を満たす論文が3件未満の場合は、基準を下げて類似度が次に高い論文を加え、Step 5 の詳細調査で十分な範囲を確保してください。選んだ候補と、それぞれを選んだ理由を明示してください。

Step 5 — 候補論文の全文を詳細に調査する

有望度の高い候補ごとに、以下の手順で全文を取得して読みます。PDF の URL をそのまま WebFetch に渡すような近道は避けてください。モデルが作成した要約が返され、このステップで確認すべき手法上の詳細が抜け落ちるためです。 論文ごとの予算。 最初から最後まで読むのではなく、ざっと目を通してください。深掘りの目的は、論文本文に照らして4つの軸を検証することであり、研究全体を要約することではありません。実用的な目安として、問題設定、中心的なメカニズム、適用範囲／前提を合わせて特定できる具体的な箇所を3つ引用または参照したら、検証済みの記録を埋めるには十分です。そこで読むのをやめてください。抽出した .txt が極端に大きい場合（長い学位論文、サーベイ論文、付録が非常に多い論文など）は、序論、手法、結論／限界の各セクションだけに目を通し、候補の記録に部分的な確認であることを記してください。fetch_paper.sh が失敗するか、出力が文字化けしている場合は、再試行に予算を費やさず、早めに中断して、以下のサブステップ4の代替手順を使ってください。

1. PDF の URL を特定します。 ステップ3に記録されたソースリンク／IDから始めます。arXiv の項目では、https://arxiv.org/abs/<id> を https://arxiv.org/pdf/<id>.pdf に変換します。OpenReview／ACL Anthology／出版社のページでは、「PDF」リンクをたどります。PDF の URL が明らかでない場合に限り、まず WebFetch を使って URL を特定します（例：「このページにある PDF への直接リンクは何ですか？」と尋ねます）。
2. 同梱スクリプトで取得し、テキストを抽出します。 複数の候補が互いに上書きしないよう、論文を識別できる <pdf_name>（タイトルをスラッグ化したもの、または 2310_12345 のような arXiv ID など）を選び、次を実行します。

   scripts/fetch_paper.sh "<PDF_URL>" "<pdf_name>"
   

   スクリプトは ${CLAUDE_PROJECT_DIR}/papers/<pdf_name>.pdf にダウンロードし、実際の PDF であることを確認します（.pdf として保存された HTML エラーページは、よくある失敗例です）。pdftotext -layout でテキストを抽出し、必要に応じて pdftotext（通常モード）→ pdfplumber → pymupdf の順にフォールバックします。成功すると ok: … と最終行に .txt のパスが表示されます。失敗すると FAILED: <reason> が表示され、ゼロ以外の終了コードで終了します。
3. 抽出したテキストを読みます。 表示された .txt のパスに対して Read ツールを使います。序論（主張されている貢献）、手法セクション（実際のメカニズム）、実験セクション（適用範囲と前提）、結論／限界に注目してください。著者自身がどのような先行研究を位置付けているかを確認するため、関連研究にもざっと目を通してください。優先的に精査すべき追加論文が見つかることもよくあります。
4. 適切にフォールバックします。 fetch_paper.sh がゼロ以外の終了コードで終了した場合（ペイウォール、403、リンク切れ、どの抽出ツールでも処理できないスキャン画像の PDF など）は、要点を絞った質問を添えて、要旨／HTML 版に対して WebFetch を試し、制限事項を明記してください。論文全文を読んでいないのに、読んだかのように装ってはいけません。深掘りの価値は、論文本文に基づいて判断することにあります。

論文全文から、要旨レベルの記録に代わる、より詳細な記録を抽出します。

項目	何を記録するか（全文から）
問題設定（検証済み）	実際に用いられたタスク設定、入力／出力、データセット、評価指標
中心的なメカニズム（検証済み）	実際のアルゴリズム／アーキテクチャ／証明。見出しにある手法名だけでなく、具体的な技術的工夫も含めます
主な着想（検証済み）	メカニズムが機能する理由について著者が示す論理、および先行研究に欠けていたと著者が主張する点
応用領域（検証済み）	評価対象となった具体的な領域、モダリティ、規模
発表先（検証済み）	論文が掲載されている発表先またはリポジトリ（例：NeurIPS 2024、ICLR 2023、ACL Findings、TMLR、arXiv preprint、OpenReview submission）。査読付きの発表先でまだ発表されていない場合は「arXiv preprint」とし、PDF に本当に記載がない場合に限り「unknown」とします。
前提と適用範囲	明記された前提、限界、および手法が適用できる／できない条件
最も関連する箇所の根拠	重複の判断を裏付ける、短い逐語引用または正確なセクションの参照
重複の再評価	論文本文に基づき、提案された新規性との各軸での一致度（match / partial / differ）を更新したもの
詳細調査の結果、当初は重複度が高いと判定した論文が、実際には異なる設定を対象としている、または大きく異なる仕組みを用いていることが判明した場合は、評価を下げ、その理由を記載してください。逆に、本文から、要旨が示唆していたよりも近い一致が明らかになった場合は、評価を上げてください。ステップ 5 の目的は、最終比較の前に、要旨レベルのトリアージで避けられないノイズを修正することです。

ステップ 6 — 提案された新規性との比較

提案された研究から始め、各先行研究を続けるリスト形式で比較を作成します。比較を構造化し、直接読み比べられるように、各項目に同じフィールド一式を含めてください。

以下のレイアウトを厳密に使用してください。各 Field: value の組み合わせは、必ずそれぞれ独立したインデント行に記載してください。

• 提案された研究
  • Title: —
  • Date: —
  • Source: —
  • Problem framing: …
  • Core mechanism: …
  • Key insight: …
  • Application domain: …
• 先行研究 A
  • Title: …
  • Date: …
  • Source: …
  • Problem framing: …
  • Core mechanism: …
  • Key insight: …
  • Application domain: …
• 先行研究 B
  • Title: …
  • Date: …
  • Source: …
  • Problem framing: …
  • Core mechanism: …
  • Key insight: …
  • Application domain: …

検討対象となるすべての先行研究について、リストを続けてください。各先行研究について、提案された研究と一致する軸の数を 0～4 で数え、その数を5 段階の新規性レベルに当てはめてください。レベル 5 が最も新規性が高く（軸の重複なし）、レベル 1 が最も新規性が低い（4 軸すべてが一致／完全に先取りされています）。4 つの軸から一致数は 5 通りとなるため、各一致数はレベルに 1 対 1 で対応します：level = 5 − (axes matching)。

一致する軸の数	レベル	ラベル
0	5	重複なし — 最も新規性が高い
1	4	重複が少ない
2	3	中程度の重複
3	2	重複が多い
4	1	完全な重複 — 完全に先取りされており、最も新規性が低い

レベルが高いほど、新規性が高い（先行研究との重複が少ない）ことを意味します。レベル 5 = 重複する先行研究なし、レベル 1 = 先行研究と 4 軸すべてで一致。

総合判定は、最も強い（一致度が最も高い）項目によって決まります。最悪のケースとして、すべての先行研究のレベルのうち最小値を採用してください。最も近い先行研究 1 件によって新規性の上限が決まるためです。先行研究がまったくない場合、判定はレベル 5（重複なし）です。この明示的な対応付けが、レポートの判定セクションで使用されます。そこで別のルールを導入しないでください。

ステップ 7 — 差分を明確にする

次の形式で、差分を1文で記述します。

[最も近い先行研究] は [前提 Y のもとで X を行う] のに対し、提案する研究は [X′ を行う／Y を取り除く／Z に拡張する] ことで、[具体的かつ測定可能なメリット] を実現します。

査読者が実際に重視する成果物はこの文です。最も近い先行研究、その研究から提案する研究が異なる具体的な軸、そしてその結果として得られるメリットを明示します。この3つの要素を具体的にしてください。「先行研究を新しい状況に拡張する」といった一般的な表現では、読者には何も伝わりません。最も近い先行研究がステップ5の検証済み記録に含まれている場合は、その記録にある前提やメカニズムの表現を直接使い、論文の要旨ではなく本文に基づいた比較にしてください。

明確な差分を1文で書けない場合、独自性は既存研究と重複している可能性が高いため、ユーザーに切り口を見直すよう伝えてください。その際は、成り立たない文を無理に作るのではなく、どの先行研究が差分を阻んでいるのかを明示してください。

差分を示したら、ステップ6の論文ごとのレベルを集計し、全体の 判定 を出します（最悪のケース、つまりすべての先行研究の中で 最小のレベル を採用してください）。次の5段階のいずれかを1つだけ選びます。

• Level 5 — 重複なし（最も独自性が高い） — ステップ6のすべての項目で すべての軸が異なる 場合、または先行研究が一切ない場合です。差分の記述だけで独立して成立します。
• Level 4 — 重複が少ない — 最も近い項目で一致する軸がちょうど1つ（3つの軸が異なる）の場合です。接点のある先行研究は存在しますが、差分には十分な余地があります。
• Level 3 — 中程度の重複 — 最も近い項目で一致する軸が2つ（2つの軸が異なる）の場合です。関連研究が存在します。差分は説明できますが、今後の執筆では明示する必要があります。
• Level 2 — 重複が多い — 最も近い項目で一致する軸が3つ（1つの軸だけが異なる）の場合です。きわめて競合する研究が存在し、差分は唯一の識別軸に依存するため脆弱です。差分を明確にするか、切り口を見直してください。
• Level 1 — 完全に重複（最も独自性が低い） — 少なくとも1つの項目で4つの軸すべてが一致（すべての軸が一致）する場合です。すべての軸で一致する先行研究が存在するため、貢献の見直しを推奨します。

選んだ判定ラベルを レベル番号とともに 示し（例：「Level 3 — 中程度の重複」）、判定の根拠として、判断を左右した具体的な論文をタイトルで挙げた1段落を続けてください。

注：差分の種類（新しい領域、測定可能な改善、あるいは方向性の異なるトレードオフ）は、文そのものと判定ですでに示されています。そのため、別のカテゴリラベルは不要です。追加すると、別の軸で判定を重複させるだけでなく、矛盾（たとえば「中程度の重複」という判定と「まったく新しい」というラベル）が生じるおそれがあります。

レポート

最終レポートは、会話内に自己完結型の単一の Markdown ドキュメントとしてインラインで表示してください。以下のすべてのセクションを、抜けや要約なく、指定された順序どおりに含めてください。

1. 判定 — Step 7 の5段階から1つだけ選び、レベル番号とラベルを明記してください：Level 5 — 重複なし（最も新規性が高い）、Level 4 — 重複が少ない、Level 3 — 重複が中程度、Level 2 — 重複が多い、または Level 1 — 完全に重複（最も新規性が低い）。
2. 差分 — Step 7 の差分を示す1文。明確な差分を簡潔に記述できない場合は、その旨を述べ、それを妨げている先行研究の要素を特定してください。
3. 分解した主張 — Step 1 の4つの軸を、ラベル付きリスト（問題の枠組み、コアメカニズム、主要な洞察、応用領域）として示してください。
4. 構造化された論文 — Step 3 で重複を除いたすべての論文を Markdown のリストとして記載してください。各論文について、Step 3 で定義されたフィールド一覧に沿って、各フィールド（タイトル、日付、問題の枠組み、コアメカニズム、主要な洞察、応用領域、重複スコア、出典）をそれぞれ1つの箇条書きで含めてください。読みやすいよう、論文ごとに空行または水平線で区切ってください。リストを途中で打ち切らないでください。論文が見つからなかった場合は、その旨を明記し、結果がなかった検索クエリを列挙してください。
5. 比較結果 — Step 6 の比較リスト全体を記載してください（提案する研究を最初に置き、その後に先行研究を続けます）。各項目は、フィールドをネストした箇条書きで記載し、その後に Step 6 の5段階評価表に基づく論文ごとのレベルとラベルを示してください。つまり、軸の一致数、レベル（1～5。5が最も新規性が高い）、およびラベル（すべての軸が異なる／3つの軸が異なる／2つの軸が異なる／1つの軸が異なる／すべての軸が一致する）を含めてください。

重要な注意事項

• 否定的な結果にも価値があります。 検索を徹底した結果、何も見つからなかったこと自体が新規性の証拠となります。使用した検索クエリを記録してください。
• 各ステップを記録してください。 各ステップの完了後、${CLAUDE_PROJECT_DIR}/step{step_number}.md に、そのステップの番号、名前、タイムスタンプ、および構造化された結果全体を含む Markdown ファイルを書き込んでください。これにより、後続のツールが中間結果を確認できるよう、ステップごとに1つのファイルが作成されます。
• レポート全体を表示してください。 要約だけでなく、すべての検索結果、分析、推論を含む詳細なレポート全体を提示してください。