novelty-check

新規性チェックのスキル

レビュー担当者の各スロットの前に、レビュー担当者の選択に従ってください： 呼び出し元の解決 → .aris/reviewer.json → Claude Code のデフォルト（Codex MCP） reviewer_route.py を正規のヘルパーリゾルバー経由で使用し、この スロットのティア、新しいコンテキスト、ソース／画像入力、決定論的なゲートを維持します。 以下の Codex の例／固定設定は backend=codex の場合にのみ適用されます。他のルートでは、それぞれの初回呼び出し／返信契約を使用します。ルートと実際に返された ID を保存してください； 利用できない選択肢は REVIEW_UNAVAILABLE とします。採否は実際の 系統／完了状況／範囲に基づいて分類します。呼び出し元からのレビュー担当者／モデル／推論負荷のオーバーライドは、レビュー担当者を含む子プロセスに渡してください。生成ワーカーに変更はありません。

提案された手法／アイデアが文献ですでに発表されているか確認します：$ARGUMENTS

定数

• REVIEWER_MODEL = gpt-6-astra — Codex MCP 経由で使用するモデル。backend=codex の場合は、OpenAI のモデル（例：gpt-6-astra、gpt-6.1-sol）を使用します

手順

手法の説明をもとに、その新規性を体系的に検証します：

フェーズ A：主要な主張の抽出

1. ユーザーの手法の説明を読みます
2. 主張されている差分を担う、技術的な主要主張を 3～5 個特定します：
   • 手法は何か？
   • どのような問題を解決するか？
   • 仕組みは何か？
   • 自明なベースラインと何が異なるか？

フェーズ B：複数ソースによる文献検索

主要な主張ごとに、利用可能なすべてのソースを使って検索します：

1. ウェブ検索（WebSearch 経由）：

   • arXiv、Google Scholar、Semantic Scholar を検索します
   • 主張に含まれる具体的な専門用語を使います
   • 主張ごとに、少なくとも 3 種類の異なる検索クエリを試します
   • 2024～2026 年の年指定フィルターを含めます

2. 既知の論文データベース：次を確認します：

   • ICLR 2025/2026、NeurIPS 2025、ICML 2025/2026
   • 最近の arXiv プレプリント（2025～2026 年）

3. 要旨を読む：重複の可能性がある論文について、WebFetch で要旨と関連研究のセクションを取得します

フェーズ C：モデル間の検証

Codex MCP（mcp__codex__codex）経由で REVIEWER_MODEL を呼び出し、xhigh 推論を使用します。 手法の説明とフェーズ B の論文リストが短いメモを超える場合は、 MCP プロンプトに直接貼り付けないでください。NOVELTY_DOSSIER.md（または プロジェクト内の同等のファイル）などのドシエファイルを作成し、そこに手法の説明、主要な主張、候補論文、以下の質問を正確に記載してから、 ファイルパスだけを送信します：

このレビュー担当者スロットを最初に解決してください。以下は backend=codex の例です。

mcp__codex__codex:
  model: gpt-6-astra
  config: {"model_reasoning_effort": "xhigh"}
  prompt: |
    Read the novelty dossier at <absolute path to NOVELTY_DOSSIER.md> and
    follow all instructions in it.

ドシエの内容には、以下を含めます：

• 提案手法の説明
• フェーズ B で見つかったすべての論文
• 次の質問："Is this method novel? What is the closest prior work? What is the delta?"
• 以下の NOVELTY VERDICT LIMITS ブロック（そのまま）。レビュー担当者はこれに基づいて判定します

判定の制限

このブロックをそのままレビュー担当者への説明にコピーしてください。フェーズ D のレポートもこれに基づいて判定されます。

=== NOVELTY VERDICT LIMITS (these bound how you judge, never how widely you search) ===
Search exhaustively; judge calibrated. Two failures waste months equally:
passing an idea a published paper already contains, and killing a viable idea
because the territory has neighbors.
1. Proximity is information, not a verdict. Someone working nearby goes in the
   report; it is not by itself a reason to reject.
2. ABANDON has exactly one qualification: a specific published paper already
   contains this result — name that paper. No named paper, no ABANDON.
3. Crowded-but-deltaed is PROCEED: state the delta in one sentence a reviewer
   could verify. Thin or contested delta is PROCEED WITH CAUTION — say what
   would make it carry, not why it should die. CAUTION is not a safe middle:
   if you cannot name the specific thing that makes the delta thin, the
   verdict is PROCEED.
4. Concurrent or competing work is not a veto. That is a race — report it and
   let the user decide whether to run it.
5. A direct attack on a central problem is legitimate novelty when nobody has
   executed it well. "This area is hot" does not mean "this area is taken."
6. This check is an early gate, never the last one — more triage, pilots, or
   external review still stand between any idea and a paper, whatever order
   this run uses. A wrongly passed idea dies cheaply at one of them; a wrongly
   killed idea is never seen again. When torn between two verdicts, choose the
   more permissive one.
Say plainly when an idea clears the check. Do not manufacture overlap.

フェーズ D：新規性レポート

構造化レポートを出力します：

## Novelty Check Report

### Proposed Method
[1-2 sentence description]

### Core Claims
1. [Claim 1] — Closest: [paper] — What stays unknown or different: [delta]
2. [Claim 2] — Closest: [paper] — What stays unknown or different: [delta]
...

### Closest Prior Work
| Paper | Year | Venue | Overlap | Key Difference |
|-------|------|-------|---------|----------------|

### Overall Novelty Assessment
- Score: X/10 (anchor: 5/10 = has clear neighbors but a defensible delta worth
  a pilot; reserve 1-3 for results a named published paper already contains)
- Recommendation: PROCEED / PROCEED WITH CAUTION / ABANDON (per the verdict
  limits: crowded-but-deltaed ground is PROCEED; ABANDON must name the paper)
- Key differentiator: [what makes this unique, if anything]
- Risk: [what a reviewer would cite as prior work]

### Suggested Positioning
[State the delta honestly in one sentence a reviewer could verify]

重要なルール

• 誤った新規性の主張と、関連領域に近い研究があるという理由で実現可能なアイデアを断念すること。この2つの失敗は、どちらも同じように何か月もの時間を無駄にします。どちらの方向にも徹底的に正直になり、アイデアが確認を通過した場合は、はっきりそう伝えてください。
• 個々の主張がすべて LOW と評価されても、組み合わせや発見に新規性がある場合があります。個々の主張を切り離して評価するのではなく、アイデア全体を評価してください。既知の要素を組み合わせて未知のことを明らかにするなら、それには新規性があります。
• 「X を Y に適用する」ことの新規性は、その適用によって明らかになることにあります。自明でない相互作用、失敗モード、洞察などが該当します。テンプレートではなく、明らかになったことを評価してください。
• 手法と実験設定の両方について、新規性を確認してください。
• 手法に新規性はないものの、発見には新規性がある場合は、その旨を明示してください。
• arXiv の直近6か月分を必ず確認してください。分野の進展は速いためです。
• 最も近い先行研究に関するハルシネーションの防止。 先行研究の表に記載する各論文について、verify_papers.py による検索前検証を必ず実施してください（正規名は shared-references/integration-contract.md §2 に従って解決します。arXiv／CrossRef／Semantic Scholar の3層フォールバックはヘルパー自体に組み込まれています）。ポリシー D1（一次対応＋劣化出力時のフォールバック）：ヘルパーを解決できない、または呼び出しに失敗した場合は、候補項目に [UNVERIFIED] を付け、削除するのではなく不確実性を明示してください。arXiv ID、DOI、タイトルを記憶から捏造してはいけません。詳しい手順は shared-references/citation-discipline.md § Pre-Search Verification Protocol を参照してください。

レビューの追跡

mcp__codex__codex または mcp__codex__codex-reply によるレビュー担当者の呼び出しごとに、shared-references/review-tracing.md（ポリシー C — フォレンジック）に従ってトレースを保存してください。黙って省略してはいけません。save_trace.sh（shared-references/integration-contract.md §2 の手順に従って解決）を使うか、.aris/traces/<skill>/<date>_run<NN>/ にファイルを直接書き込んでください。--- trace: パラメーターを守ってください（デフォルト：full）。