mcpField
I
idea-quality

idea-quality

github.com/microsoft生産性3.4k55 回インストール5 週間前に更新
リポジトリ

idea-quality について

idea-qualityは、実験前の研究アイデアを評価するスキルです。アイデア文だけをもとに、問題の重要性、手法の質、両者の適合性を根拠付きで採点します。

主な機能

  1. 01文章から研究アイデアを評価
  2. 023つの軸を個別に採点
  3. 03引用した根拠で評価を説明
  4. 042つのアイデアを比較
  5. 05絶対評価と相対評価を区別

活用シーン

  1. 01実験前の研究案の検討
  2. 02問題と手法のずれの発見
  3. 032つの研究アイデアの比較

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/microsoft/researchstudio --skill idea-quality

インストール後、Claude Code で/idea-qualityを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

evals/
evals.json
evals/sample_ideas/
mismatch_gate.md
strong_grpo.md
weak_temperature.md

詳細

アイデアの質

実験を行う前のアイデア段階で、研究アイデアの強さを判断し、査読者が納得できる理由とともに質のスコアを返します。このスキルは自己完結しており、以下の3つの軸に基づいて第一原理から判断します。外部のコーパス、データセット、その他のスキルは参照しないため、アイデアの文章だけから再現可能な判断を行います。

入力:アイデアを記述した Markdown ファイル

アイデアは3つのセクションを含む .md ファイルです。ファイルを読み、各セクションが何に影響するかを対応付けます。

# Title
<≤ ~15 words: the idea's handle>

## Motivation
<the bottleneck / gap the idea attacks, why it matters, and why it is still open>

## Method
<the proposed contribution as concrete numbered steps>
  • Title → アイデアを識別するための名称です。
  • Motivation → Axis A(取り組む価値のある問題か)に影響し、Axis Cの「問題」側を担います。
  • Method → Axis B(手法は優れているか)に影響し、Axis Cの「手法」側を担います。

セクションが欠けている、または内容が乏しい場合は、残りの記述から最も妥当な解釈を推定し、その前提をレポートに記載します。確認を求めて処理を止めてはいけません。ユーザーが2つのファイル(または2つのアイデアを含む1つのファイル)を渡して比較を希望する場合は、ペアワイズトラックを実行します。

対象範囲:評価することと、意図的に評価しないこと

  • 実験は行われていません。 各軸はすべて、結果を見る前にアブストラクトから査読者が判断するような、推論レベルでの評価です。スコアを付けるために、実験結果を捏造したり、あると仮定したりしてはいけません。主張の真偽に実験が必要な場合、想定上の結果ではなく、主張の論拠のもっともらしさを評価します。
  • 先行研究の確認ではありません。 「すでに誰かが取り組んでいるか」は、文献との重複を調べる別のタスクです。アイデアが優れているか(実在する課題、深みのある手法、適切かつ目的に沿っているか)を評価し、ほぼ同一の研究が存在するかどうかは評価しません。文献検索に対する新規性ではなく、貢献そのものが持つ野心度を評価します。

高いスコアはアイデアが優れていることを示します。実行の成否にも左右されるため、このスキルでは評価できない採択の可能性を予測するものではありません。

3つの軸

必ず次の3つだけで採点してください。各軸は、(a)実験なしでアイデアだけから評価でき、(b)優れたものと弱いものを見分けられ、(c)文章の洗練度の代替指標にならないものです。

A — 問題設定の質。 動機づけで特定されているギャップは、実在し、重要で、自明ではなく、本当に未解決でしょうか。それとも、浅薄なもの、すでに解決済みのもの、都合よく取り組みやすい対象でしょうか。

  • 強い:重要なギャップであり、その分野ではまだ解消されていません。そのギャップを指摘すること自体に洞察があります。
  • 弱い:自明、またはすでに対処済みの問題、あるいは安価に「解決」できるよう選ばれた、容易な対象です。
  • この軸を設ける理由: 著者が自らボトルネックを選ぶ場合、成功しているように見せる最も簡単な方法は、容易な対象を選ぶことです。この軸は、容易なボトルネックと些細な解決策の組み合わせが高く評価されるのを防ぎます。

B — 手法の質。 提案された手法そのものの質を評価します。スコアは1つだけ付けますが、理由では、どの要素が弱いのかが1つの数字に隠れないよう、次の3つの観点に分けて明記してください。

  • 深さ — 真に新しいメカニズム、構成、または捉え直しがあるか、それとも漸進的な変更(新しいスケジュール、損失項の追加、ハイパーパラメーターの変更)にとどまるか。
  • 妥当性 — 「なぜ機能するはずか」という論拠は、内部的に整合していますか。前提は正当化されていますか。それとも、曖昧な説明、明示されていない条件、論理的な欠落がありますか。どの問題を対象としているかにかかわらず、手法自体の論理を評価してください。適合性は軸Cで評価します。
  • 実現可能性 — 原理上構築できますか。それとも、現実には存在しそうにないリソース、オラクル、データが必要ですか。これは「構築できるか」という意味であり、「良い数値結果が得られるか」ではありません。結果を捏造してはいけません。この観点の比重は最も低くし、深さをBの評価で重視してください。実現可能性は同点時の判断材料とし、他の2要素と同等には扱わないでください。
  • 注: Bで評価するのは、手法そのものの規模と健全性です。文献に重複例があるかどうかではありません(それは別の先行研究調査の課題です)。

C — 問題への適合性。 手法は、隣接する別の問題や、より簡単な問題、あるいは異なる問題ではなく、動機づけで示された具体的なギャップを実際に対象とし、もっともらしく解消するものですか。

  • 強い:手法のメカニズムが特定されたギャップに明確に関係しています。うまく機能すれば、そのギャップは解消されます。
  • 弱い:主張されている問題とは異なる問題を狙った手法、またはギャップとの関連性が示されず、主張されているだけの手法です。
  • Bの妥当性との境界: Bの妥当性では「手法自体の論理に一貫性があるか」を問い、Cでは「その論理がこの問題に結び付いているか」を問います。内部的には妥当な手法でも(Bが高い)、誤った問題を解決していることがあります(Cが低い)。一方、問題に適合していても(Cが高い)、論拠が曖昧なことがあります(Bが低い)。両者は分けて評価してください。

採点:二重トラック

必ず絶対評価を行ってください。2つのアイデアを比較する場合は、ペアワイズ評価も行ってください。そして、信頼できるシグナルとしてペアワイズ評価を扱ってください。相対的な判断は絶対値よりもはるかにばらつきが小さいためです(絶対評価の数字は3/5付近に集中します)。絶対評価の0~100点は、読みやすい副次的な指標であり、校正済みの真実ではありません。

各軸を1~5の整数で採点してください。各点数の固定された説明はあえて設けていません。その代わりに、すべての点数について、その根拠となるアイデア内の具体的な語句や要素を引用してください。 引用根拠のない点数は認められません。採点基準表ではなく、この根拠を必須とすることで、評価の誠実さを保ちます。長さや流暢さではなく、内容を評価してください。 短く明快なアイデアが5点を取ることも、長く洗練されたアイデアが2点を取ることもあります。

トラック 1 — 絶対評価(アイデアごと)

総合スコア(等重み、各軸 1→0、5→満点):

overall = round(100 * (A + B + C - 3) / 12)

判定バンド: strong ≥ 67 · borderline 34~66 · weak < 34。

A/C ゲート(バンドを上書きします)。 A と C はほぼ必須であり、B はそうではありません。したがって:

  • A ≤ 2 または C ≤ 2 の場合、数値に関係なく、判定を strong にすることはできません(最大でも borderline にとどまります)。理由: 些細な問題に対する優れた手法(A が低い)、またはその問題に対処しない手法を伴う優れた問題(C が低い)は、強いアイデアとは言えず、等重みの平均ではそうでなければ誤解を招くためです。上限とその理由を 1 行で述べてください。
  • B だけが低い場合は上限になりません: 重要な問題に真に取り組むシンプルな手法(反直感的なミニマリズム)は、なお強いアイデアになり得ます。
トラック 2 — ペアワイズ評価(2 つのアイデアの比較)

各軸について、どちらのアイデアがより強いか(アイデア 1 / アイデア 2 / 引き分け)とその理由を 1 行で述べてください。軸 B については、どの側が勝つかを下位判断(深さ / 健全性 / 実現可能性)ごとに記し、診断が失われないようにしてください。その後、ホリスティックに総合的な勝者を示します。ただし、問題適合性(C)はほぼ必須です: 決定的な C の敗北は、たとえそのアイデアが A と B で勝っていても、通常は総合的な勝敗を決定します。なぜなら、自分の問題に適合しない手法は、より優れたアイデアではないからです。各軸は独立に判断し、1 つの軸が他の軸を揺るがすことのないようにしてください。

出所を見ずに判定してください。 評価の一環として 2 つのアイデアを比較する場合、どちらのシステム/モデルがどちらを生成したかを含めてはいけません。出所は品質の証拠にはなりません。(これを公平にするには、2 つの入力が同じ Title/Motivation/Method 形式を共有している必要があります。共有していない場合は指摘してください。)

出力形式

単一のアイデアの場合:

## Idea Review — <title>

**Decomposition**
- Problem / gap (from Motivation): …
- Method (the proposed move): …
- Why it should work: …
(assumptions inferred, if any: …)

**Axis scores**
| Axis | Score (1–5) | Evidence (quoted from the idea) | Reason |
|------|-------------|----------------------------------|--------|
| A — Problem position | | | |
| B — Method quality | | | depth: … · soundness: … · feasibility: … |
| C — Problem-fit | | | |

**Overall: NN / 100  ·  Verdict: strong | borderline | weak**
<if the A/C gate fired: one line naming the cap and why>

**Strongest point:** <one sentence>
**Most fixable weakness:** <one sentence, phrased as what would raise the score>

比較の場合、各アイデアの絶対評価ブロックを出力し、その後に:

## Pairwise verdict (Idea 1 vs Idea 2)
| Axis | Stronger | Why (one line) |
|------|----------|----------------|
| A — Problem position | 1 / 2 / tie | |
| B — Method quality | 1 / 2 / tie | depth / soundness / feasibility: who wins each |
| C — Problem-fit | 1 / 2 / tie | |

**Overall winner: Idea 1 | Idea 2 | tie** — <one–two sentence rationale; if a decisive C loss drove it, say so>

バイアス防止ルール(なぜ重要か)

  • すべてのスコアに対して根拠を引用してください。 数字だけでは雰囲気であり、雰囲気は強いアイデアと弱いアイデアを区別できません。各スコアを具体的な主張に結びつけることで、判断が監査可能になり、比較が公平になります。
  • 長さ/流暢さ/整形ではなく内容を評価してください。 自信に満ちた、よく構造化された記述は、薄いアイデアを飾り立てることがあります。提示のうまさに報酬を与えることに抵抗してください。特に B の健全性では、流暢な文章が不健全なステップを最も容易に隠します。
  • アイデアの段階にとどまってください。 スコアを正当化するために実験結果を想像しないでください。ある主張を検証するのに実験が必要なら、その議論のもっともらしさをスコアリングし、幻覚的な結果をスコアリングしないでください。
  • 比較では、出所を見ずに判定してください。 どのモデルやシステムがアイデアを生成したかは、その品質に関する証拠ではありません。無視してください。

コメント