idea-evaluator

アイデア評価

概要

このスキルは、一流の学会やジャーナルの査読者と経験豊富なアドバイザーの両方の視点から、研究の初期アイデアを評価します。アイデア生成ガイドにある5つの改善軸（より高く、より速く、より強く、より安く、より広く）に照らしてアイデアを採点し、アイデアのライフサイクルをユーザーの実際の能力と週あたりの作業可能時間に照らし合わせ、パラダイムシフトにつながる可能性を探り、致命的な欠陥を指摘したうえで、次の3つの判定のいずれかを返します：Strong Accept、Accept with Revisions、Reject and Pivot。

目的は、学生が数か月を費やす前に弱いアイデアを見極め、将来性はあるものの未成熟なアイデアを、執筆を始める前により強い形へと練り上げることです。

このスキルを使う場面

• ユーザーがアイデアの草案を提示し、それを追求する価値があるか尋ねている。
• ユーザーが新規性の確認、実現可能性の評価、または採点を求めている。
• ユーザーが論文のスコープを確定する前、または実装を始める前。
• ユーザーが候補となる2つか3つのアイデアを比較しており、体系的なトレードオフ分析を必要としている。
• ユーザーがスコープの拡大を懸念し、第三者の確認を求めている。
• ユーザーが「このアイデアを評価して」「このアイデアを採点して」「実現可能性を評価して」「これは良い研究の方向性か」などと言っている。

このスキルを使わない場面

• ユーザーがすでにアイデアを実装し、論文を執筆している。 その場合は、代わりに intro-drafter、tech-paper-template、または benchmark-paper-template（別プラグイン）を使ってください。
• ユーザーが新しいアイデアをゼロからブレインストーミングしたいと明示している。 通常の会話で対応してください。破壊的イノベーションの手引きについては、ハンドブックの2.3を参照してください。
• ユーザーが既存の原稿のレビューを求めている。 pre-submission-reviewer を使ってください。
• ユーザーがベンチマークへの貢献を特に評価するよう求めている。 対象を絞ったモードで benchmark-paper-template（別プラグイン）を使ってください。

基本手順

ステップ1：第一印象と論文のタイプの位置づけ

ユーザーのアイデアの説明を読みます。1段落で、そのアイデアが「新しい問題」「新しい手法」「新しい設定」のどれに当たるかを述べます。ストーリーを1文で魅力的に表現できますか？その1文を書けない場合、アイデア自体が評価できるほど明確でない可能性が高いため、ユーザーに言い直してもらいます。

言い直す際は、部門名ではなく手法に基づいて研究パラダイムを分類します。実験、ベンチマーク、アブレーション、またはモデルアーキテクチャなら STEM（以下の5つの評価軸と致命的な欠陥の確認を続けます）。テキスト分析、アーカイブ資料、または概念的な議論なら人文学。アンケート、インタビュー、統計分析、またはフィールドワークなら実証的社会科学。回帰分析、IV、DID、RDD、またはパネルデータなら金融または経済学。法令、判例、または法理論なら法学です。

参照先：references/domain-evaluation-frameworks.md。STEM以外のパラダイムで使う、代替の5次元評価フレームワークと致命的な欠陥の代替項目が記載されています。パラダイムが明確でない場合は、「中核となる手法は、実験、アンケート、テキスト分析、理論的導出のどれですか？」と1つ質問します。

ステップ 2：致命的欠陥の監査（早期ゲート）

参照先：references/fatal-flaws.md には、検出ルールと防御戦略を含む、 10 個の標準的な致命的欠陥が記載されています。

致命的欠陥の監査は、スコアリングの手順の後ではなく、前に実施してください。致命的欠陥は最大 2 つまで特定します。それぞれについて、 欠陥を述べ、検出ルールを引用し、具体的な防御策を推奨してください。

環境に文献検索機能がある場合（学術検索ツール、学術インデックスを対象としたウェブ検索、または公開 API へのシェルアクセス）、新規性の欠陥（F1）は実際の検索結果に基づいてください。アイデアからキーワードのグループを 2～3 個（中核となる手法と領域、メカニズムとタスク、技術とベンチマークなど）抽出して検索し、最も関連性の高い既刊文献を 3～5 件、タイトル、著者、発表年とともに挙げてください。それぞれについて、実際に異なる軸を述べてください。軸は、作用対象、メカニズム、入力の粒度、または問題設定です。タイトルが似ているだけでは重複とは判断できません。異なる軸が 1 つも見つからない場合に限り、重複と判断します。検索結果から判断できるのはメタデータレベルの情報（誰が、何を、どこで行ったか）に限られます。検索スニペットから数値や手法の詳細を引用してはいけません。また、「見つからなかった」ことは新規性の証明にはなりません。「これらのキーワードでは直接重複する研究を取得できなかった」と報告してください。検索機能がない場合は、新規性の判断を「未検証。文献調査が必要」としてください。

データに反証された中核メカニズムは、自動的に CRITICAL とします。 ユーザー自身が報告したデータや添付ファイルによって、中核メカニズムがベースラインまたは単純な対照条件と同等か、それらに劣ることがすでに示されている場合、判定は Reject and Pivot に固定します。防御策は記述せず、楽観的な閾値をでっち上げないでください。「データに反証された」場合と「まだ検証されていないだけ」の場合を区別する正確な基準については、references/fatal-flaws.md のデータに反証された場合のセクションを参照してください。

ショートサーキットルール。 深刻度の分類で致命的欠陥が 1 つでも CRITICAL とされた場合（それだけで却下に至り、ライフサイクル内では修正不能）、ここで終了し、判定を直接出力してください。

• 判定：Reject and Pivot。
• 出力するのは、セクション 1（第一印象）、2（CRITICAL の欠陥を含む致命的欠陥）、7（欠陥に基づく理由を含む判定）のみです。
• 5 つの評価軸によるスコアリング、パラダイムシフトの検証、実現可能性の確認、誠実性ゲートは実施しないでください。これらは却下の理由を飾り立てるだけです。

CRITICAL な欠陥が見つからなかった場合は、ステップ 3 に進んでください。

ステップ 3：ライフサイクルと能力の適合

参照先：references/lifecycle-capability-matching.md には、6 分類のライフサイクルマトリクス、能力の自己評価基準、ミスマッチの回復戦略が記載されています。

アイデアを 6 つのカテゴリ（応用、基礎理論、学際、フロンティア探索、データ集約型、革新的技法）のいずれかに分類してください。ユーザーが申告した能力（週あたりの実働時間、スキルの深さ、理論面と応用面の強み）と照合してください。ライフサイクルがユーザーの現実的な実行期間より短い場合は、ミスマッチのフラグを出してください。

Step 4: 5つの観点によるスコアリング

各観点の記入方法、スコアリング基準、具体例については、references/five-dimensions.md を参照してください。

以下の各観点についてアイデアを評価します。

• 向上：有効性と精度の改善。
• 高速化：効率の向上とコスト削減。
• 強化：堅牢性、ノイズ耐性、汎化性能。
• 低コスト化：データ、アノテーション、またはソリューションのコスト削減。
• 拡大：分野横断的な転用、または統合。

ユーザーが明示した貢献を根拠として、それぞれ1〜10点で評価します。最も高いポテンシャルを持つ観点を2つか3つ特定し、論文ではそれらを強調するよう提案してください。

スコアリングの原則：すべての観点を5点から始め、点数を動かす根拠を説明します。スコアを上げる根拠は2種類あり、どちらも有効です。ユーザーが報告した測定結果（その数値を引用）と、妥当なメカニズムに基づく論拠です（スコアには「メカニズムに基づく。データでは未確認」と明記します）。確かなメカニズムがあれば、未検証でも、その旨を明記し、検証実験を具体的に挙げることで、8点や9点に達することがあります。未検証のアイデアを一律に低く評価しないでください。データもメカニズムもない観点は、「根拠なし」として5点にします。因果関係の帰属に注意してください。目覚ましい改善が、周辺的な要因（ルーティング、後処理、より強力なベースモデル、有利なサンプルなど）に由来する可能性がある場合、アブレーションで中核となるメカニズムを切り分けるまでは、その観点のスコアに上限を設けてください。評価基準の最後の2つのセクションで、両方のルールについて詳しく説明しています。

非 STEM のパラダイムについては、同じ原則に従い、代わりに references/domain-evaluation-frameworks.md の評価観点を使用してください。

Step 5: パラダイムシフトの検証

4つの検証原則（第一原理、部屋の中の象、技術サイクル、ハミングの法則）と、破壊的イノベーションをさらに深く探る場合に参照するハンドブックのセクション2.3への相互参照については、references/paradigm-shift-probe.md を参照してください。

以下の4つの問いに照らしてアイデアを検証します。

1. その分野で当然とされている暗黙の前提に異議を唱えていますか？
2. 誰もが認識しながら、あえて取り組もうとしない厄介な問題に対処していますか？
3. 技術サイクルの変化を捉えていますか（たとえば、LLMによって、それまで実用が困難だったアプローチが実現可能になるなど）？
4. この問題が自然に解決されたとしたら、その分野は大きく変わりますか？（ハミングの法則）

「はい」が2つ以上なら、アイデアには破壊的な可能性があります。その旨を記し、破壊的イノベーションの観点を深めるために、ハンドブックの2.3を読むよう提案してください。

Step 6: 実現可能性の確認

ユーザーが明示したリソース（ハードウェア、データへのアクセス、チームの規模、エンジニアリングスキル、期間）に照らして、以下を評価します。

• 計算リスク：実験は提示されたハードウェアで実施できますか？
• データリスク：必要なデータを入手できますか？それとも、高額なアノテーションや非公開ソースが必要ですか？
• エンジニアリングリスク：実装に必要なスキルは、ユーザーの技術スタックに合っていますか？
• 期間リスク：コーディング、実験、執筆、改訂を含む推定所要期間は、アイデアのライフサイクル内に収まりますか？

リスクが高い項目があれば、その旨を明記し、軽減策を提案してください。

Step 7: インテグリティゲート

判定を出す前に、以下の「インテグリティゲート」セクションに記載されたチェックを実行してください。

Step 8: 最終判定

以下の3つの判定のいずれかを出します。

• 強く採択：今すぐ実行します。2つ以上の観点が8点以上で、致命的な欠点がなく、能力との適合性が良好で、ライフサイクルにも適合しています。
• 修正のうえ採択：開始前に、提案に従ってスコープを見直します。一部の観点が弱い、修正可能な欠点がある、または短縮可能なライフサイクル上の不適合があります。
• 却下して方向転換：この案は進めません。既存のベンチマークや手法に劣る、能力との不適合を解消できない、または致命的な欠点が複数ある場合です。

高いスコアがデータではなくメカニズムに基づく場合は、判定に「検証実験を条件に、取り組む価値あり」と付記し、その実験を上位3つのアクションに挙げてください。

以下の出力形式で評価を出してください。

整合性ゲート

各箇条書きには、適用可能性のクラスが付与されています。[inspection] は、LLM が生成された出力だけから箇条書きの内容を検証できることを 意味します。[attestation] は、LLM が確認を実施したと述べるものの、 検証の責任はユーザーに残ることを意味します。[user-attest] は、 スキルでは確認できない、ユーザー側のルールであることを意味します。

判定を返す前に、次の項目を確認してください。

1. [inspection] 各評価軸のスコアは、ユーザーが述べた貢献に関する 具体的な根拠を挙げています。どのスコアも「勘」に基づくものではありません。
2. [inspection] 実現可能性に関する主張は、一般的な想定ではなく、 ユーザーが述べたリソースを参照しています。
3. [inspection] 新規性に関する主張は、具体的な先行研究を挙げるか、 「未検証。文献調査が必要」と記されています。
4. [inspection] 致命的な欠点は、具体的で対処可能です。「うまくいかない 可能性がある」は欠点の記述ではありません。
5. [inspection] 判定はスコアと一貫しています。「Strong Accept」には、 8 点以上の評価軸が 2 つ以上あり、CRITICAL の欠点が 0 件である必要があります。
6. [inspection] パラダイムシフトの主張は、肯定的に回答された探索的な 質問を示しています。
7. [attestation] ライフサイクルの予測は、その分野の近年の進展ペースに 基づいて論じられています。ユーザーは、それに基づいて行動する前に、 自身のサブフィールドに関する知識と照らし合わせて妥当性を確認してください。

[inspection] の確認項目に不備がある場合は、判定を引き下げ、該当する 出力セクションに「ユーザーによる確認が必要」と記してください。[attestation] の項目については、スキルが確認を実施した旨を述べ、ユーザーが結果を確認します。

ゲートは内部で実行してください。ゲートごとの合否レポートは出力しないでください。 不備があった場合は、該当する出力セクション内の具体的な指摘として示し、 提出する評価には内部チェックの手順を含めないでください。

出力形式

1. 第一印象

• 論文の種類：<新規の問題または新規の手法または新しい設定>
• 一文で表すストーリー：<...>

2. 致命的な欠点の監査（初期ゲート）

#	欠点	重大度	反論
1	...	CRITICAL または MAJOR	...

CRITICAL の欠点がある場合は、セクション 3～6 を省略し、 セクション 7 に進んで「Reject and Pivot」と判定してください。

3. ライフサイクルと能力の適合性

項目	ユーザーの入力	評価
アイデアのカテゴリ	...	...
ライフサイクル	... か月	...
週あたりの実質的な作業時間	...	...
適合性	...	Green または Yellow または Red

4. 5 つの評価軸レーダー

評価軸	スコア 1～10	根拠	スコア向上の提案
高める	...	...	...
速める	...	...	...
強化する	...	...	...
低コスト化する	...	...	...
広げる	...	...	...

5. パラダイムシフトの探索的評価

探索項目	はい または いいえ	根拠
第一原理	...	...
見て見ぬふりをされている問題	...	...
技術サイクル	...	...
ハミングの法則	...	...

破壊的な可能性：<なし、あり得る、高い>。

6. 実現可能性

リスク	レベル	軽減策
計算資源	...	...
データ	...	...
エンジニアリング	...	...
スケジュール	...	...

7. 判定

<Strong Accept または Accept with Revisions または Reject and Pivot> (メカニズムに基づくスコアが高い場合は、「検証実験を条件に、追求する価値あり」を追記してください)

最初に実施する 3 つのアクション：

1. ...
2. ...
3. ...