research-proposal

研究提案ループ

この成果物は研究提案です。フィードバックシグナルにはScholarEval（文献に基づく妥当性＋貢献度）を使用し、固定された rubric.md に照らしてJudgeが0〜100の評価点に変換します。各イテレーションでは評価→採点→改訂を行い、評価点が <pass_threshold> を超えるか、予算を使い切るまで続けます。

目指すべき方向。 閾値のクリアは停止条件であり、目標ではありません。目標は、この提案が誠実に到達できる、最も強く、最も独創的で、真に出版可能な形です。改訂のたびに、「欠点を修正できているか」だけでなく、「研究の意義と独創性を高められているか」を問いかけてください。これが根拠に基づく野心です。改善は、実際に取得したエビデンスに裏付けられた、より正当化された手法、より鋭く、かつ擁護可能な独創性の主張、そしてより強力なベースラインから生まれます。主張を誇張すると評価点は下がります（エビデンスのゲート＋貢献度の評価軸）。上がることはありません。

登場する役割（すべてこのフォルダー内）：

• roles/ScholarEval.md — 文献に基づいて評価する2つのモジュール。scholareval.json を出力します。
• roles/Judge.md — フィードバックを採点し、0〜100の評価点と優先順位付き修正項目を出力します。verdict.json を出力し、合格かどうかを判断します。
• roles/Reviser.md — 修正項目に対処するため提案を書き直します（研究の意図を守ります）。
• rubrics/rubric.md — 固定の採点基準（Judge が編集することはありません）。
• schemas/scholareval.schema.json、schemas/verdict.schema.json — 検証済みの2つの出力。

起動できない場合の代替。 Claude Code では、ScholarEval／Reviser を実際の Agent サブエージェントとして起動します。それ以外の場合は、各役割をインラインで担います。あなたはオーケストレーターであり、Judge です。

使用する場面

文章化された提案がすでにあり、ユーザーが文献に基づく批評を通じて品質基準を超える水準まで引き上げたい場合に使用します。デフォルトでは、以下の評価→採点→改訂のループを最後まで実行します。代替手段として、ユーザーが批評のみ（書き直しなし）を希望する場合は、ScholarEval と Judge によるパスを1回だけ実行して終了します。白紙の状態から提案を書く場合や、単独の文献調査には使用しません。

セットアップ

バインディングを対話形式で解決します。 作業ディレクトリに loop.run.yaml が存在する場合は、それを読み込んでループに進みます。それ以外の場合は、Claude Code（AskUserQuestion ツールを利用可能）では各バインディングのもっともらしい値を推測し、推奨オプションとして提示します。その他のホストでは、引用符付きのプレーンテキストの質問を使って各項目を尋ねます。その後、loop.run.yaml（形式：examples/run.example.yaml）を書き込み、他のファイルを作成する前に、すべての値、<intent>、および文献取得ティアがライブか縮退状態かを確認します。

バインディング	意味	デフォルト	推測方法
<proposal_path>	問題、方法論、計画中の実験を記載したファイル	—	.md／.txt／.pdf の候補を検索します。文章だけが貼り付けられている場合は、<sandbox_root>/iter1/proposal.md に保存します
<intent>	中核となる研究課題と主な貢献をまとめた2～3文 — 固定。Reviser はこれを変更できません	—	提案書を読み、内容を抽出して、ユーザーに確認してもらいます
<pass_threshold>	合格に必要な提案書の評価点（0～100）	75	完璧を求めず、堅実で十分な根拠のある提案書を基準にします
<budget>	最大反復回数	6	—
<patience>	改善がない状態が連続する場合に停止するまでの反復回数	2	—
<eval_scale>	1回の反復で ScholarEval が取得する文献量（low／medium／high、下記参照）	medium	—
grade_weights	soundness · contribution · evidence_quality（合計が1であること。実行中は固定）	0.45 · 0.35 · 0.20	rubric.md。デフォルトを推奨
<sandbox_root>	スナップショット、台帳、文献キャッシュの保存先	./sandbox	—

評価の深度調整（<eval_scale> は、1回の反復で調査する方法・観点・各検索クエリ数・全文を読む論文数に上限を設けます）：

プリセット	方法・観点	各検索クエリ数	全文を読む論文数	作業量
low	2 · 2	1	0（スニペット／要旨のみ）	低
medium (推奨)	4 · 3	2	2	中
high	6 · 5	3	5	高

文献ツールチェーン。 論文検索には、同階層の literature-search スキルを使用します。<lit_skill_dir> を解決し（同階層のスキルとして、例：~/.claude/skills/literature-search/ にインストールされます）、<lit_py> = python3、<lit> = <lit_skill_dir>/tools/lit_search.py とします。キャッシュを再利用するには、サブコマンドの後に --cache-dir <sandbox_root>/literature/.cache を追加します。セットアップ時に <lit> --help が動作することを確認してください。スキルが存在しない場合はユーザーに伝え、インストールする（リポジトリの loops/literature-search フォルダーを ~/.claude/skills/ にコピーする）か、すべての検索を WebSearch／WebFetch に縮退させます（ランキング付きスニペットや引用グラフの展開は利用できません）。キー不要の S2 + arXiv コア機能（search／snippet／cite／fulltext）にはセットアップが不要です。無料の S2_API_KEY があると、ScholarEval を特徴づける2つの処理である snippet と cite の信頼性が高まります。

API キー（任意。処理をブロックしません）。 キーの規約は literature-search スキルが管理します。<lit> keys --init を実行し、表示された keys.env はユーザー自身に記入してもらいます。シークレットをチャットに貼り付けないでください。<lit> keys を再実行して存在を確認し、ティアを loop.run.yaml に記録します（literature_tiers には存在の有無のみを記録します）。キーがない場合は、キー不要の検索対象に縮退し、それも利用できなければ WebSearch に移行します。

バインディングを確認したら、サンドボックスを初期化します：

<sandbox_root>/
├── loop.run.yaml        ← resolved bindings + <intent> + grade_weights + literature_tiers
├── ledger.tsv           ← header only (see Ledger)
├── literature/.cache/   ← lit_search on-disk cache
└── iter1/proposal.md    ← the input proposal (the baseline)

ループ

<N> は1から始まります。反復1では、変更されていない提案を評価します（ベースラインの評価。これより前に改訂は行いません）。毎回、必ず新たに評価してください。評価は、改訂後の提案を対象にした 新しい ScholarEval の実行結果からのみ取得し、前回の評価を引き継いではいけません。

このチェックリストをコピーして、完了した項目にチェックを入れてください。

• Evaluate（評価） — roles/ScholarEval.md（spawn-or-degrade）を、<eval_scale> の上限と <lit> を使って iter<N>/proposal.md に対して実行します。結果は iter<N>/scholareval.json に書き出されます（schemas/scholareval.schema.json に対して検証されます）。
• Grade（採点） — Judge（roles/Judge.md）として、rubrics/rubric.md を scholareval.json に適用します。証拠ゲート → 各評価軸を0～5で採点 → 加重 grade → ハードゲート → pass と優先順位付きの fixes の順に行います。結果は iter<N>/verdict.json に書き出されます（schemas/verdict.schema.json に対して検証されます）。
• Log（記録） — ledger.tsv に1行追記します（Ledgerを参照）。
• Stop check（停止判定） — verdict.pass == true、または N == <budget>、または <patience> 回の反復で評価が横ばいの場合は停止します（Stopsを参照）。
• Revise（改訂） — verdict.json、scholareval.json、<intent>、<lit>、および少量の改訂用検索予算（検索約<eval_scale>回と、読み込み数回）を使って roles/Reviser.md（spawn-or-degrade）を実行します。焦点を絞った修正を1回行い、iter<N+1>/proposal.md と iter<N+1>/revision_notes.md に書き出します。
• N = N + 1 として繰り返します。

引用するスニペットはすべて、その反復で実際に取得したものに限ります。{"error","fallback"} が返された場合は、WebSearch/WebFetch に切り替えてください。論文を捏造してはいけません。

Ledger

<sandbox_root>/ledger.tsv はタブ区切りです。自由記述にはカンマを使わないでください。

iter	grade	pass	soundness	contribution	evidence_quality	top_fix	revision_summary
1	58.0	no	3	2	4	add MM-GBSA re-scoring	baseline (no revision)
2	71.0	no	4	3	4	add head-to-head vs [C2] pipeline	added re-scoring + scoped affinity claim
3	82.0	yes	4	4	4	-	reframed contribution around integration + new benchmark

各反復に対応する scholareval.json と verdict.json は iter<N>/ にあります。予算または停滞によって停止する場合は、必ず最高評価の反復を報告してください。最終反復とは限りません。ledger.tsv、iter*/、literature/ は未追跡のままにしてください。

制約

• 引用やスニペットを捏造しないでください — 各 evidence 項目は、その反復で実際に取得した <lit>/WebFetch の結果からの原文抜粋でなければなりません。証拠ゲートは捏造を検出するためにあります。
• 評価基準は固定です — Judge は rubrics/rubric.md を編集しません。そのため、合格基準は反復を通じて一貫します。
• <intent> を守ってください — Reviser は強化することはできますが、中核となる研究課題や主要な貢献を置き換えてはいけません。また、評価を上げるためだけに中心的な手法を骨抜きにしてはいけません。
• 文章ではなく証拠に基づいて採点してください — 雄弁さは評価されません。根拠に裏付けられた主張と、維持された新規性が評価につながります。
• 反復ごとに焦点を絞った改訂を1回行ってください。これにより、各評価の変化を改訂に帰属できます。
• インストールは禁止です — 隣接する literature-search スキルは標準ライブラリのみを使用します。API キーを表示またはコミットしてはいけません（プロジェクトルートの keys.env は Git の追跡対象外のままにします）。サンドボックスは自己完結型です。../ で外に出てはいけません。

Stops

ループは、次のいずれかに最初に該当した時点で停止します。

• Pass（合格） — verdict.pass == true。最終提案（iter<N>/proposal.md）、その評価、および評価の推移を報告します。
• Budget（予算） — N == <budget>。最高評価の反復を成果物として報告します。
• Plateau（停滞） — <patience> 回連続で評価が改善しなかった場合。最高評価の反復と、未解決の優先度1の修正項目を報告します。

最後に必ず、成果物となる提案のパス、その評価と合否、ledger.tsv に記録された評価の推移を記載してください。不合格の場合は、この提案が合格基準に達するうえで残っている阻害要因も記載してください。