research-question

Research Question Loop

研究の「問いの枠組み」を定める段階での、絞り込み → 採点 → 修正のループです。成果物は少数の研究課題で、フィードバックの指標は、いくつの課題が基準をクリアするかです。各課題は、固定された5つの軸（具体性、回答可能性、新規性、実現可能性、重要性）で0〜5点の採点を受けます。曖昧なテーマから始め、候補を作成し、ルーブリックに照らしてそれぞれを採点し（文献を対象に簡単な新規性チェックも行います）、有望な候補のうち最も弱い軸を書き直して、十分な数の課題が強くなるまで繰り返します。

優れた研究課題を立てることは、研究における難題です。範囲が広すぎると回答できず、狭すぎると重要性がなく、すでに決着しているなら取り組む意味がありません。目標は、平凡な課題をたくさん立てることではなく、優れた課題を少数立てることです。このループを通じて、回答可能で、新規性があり、答える価値のある課題が成立する狭い範囲へと進めます。

対象範囲と制限事項

このループで作成・改善するのは研究課題です。新規性の確認は簡単な検索を数回行う程度で、網羅的な調査ではありません。包括的な全体像を把握するには文献調査ループを使い、課題を検証可能な予測に変換するには仮説生成ループを使ってください。新規性チェックにはウェブまたは文献へのアクセスが必要です。利用できない場合（novelty_check: none）、新規性はこのループによる最善の判断となり、未検証であることを明記する必要があります。

使用するタイミング

ユーザーがテーマ、分野、または大まかな関心を持っており、それを追求する価値のある具体的な課題にしたい場合に使用します。デフォルトでは、以下のドラフト→採点→修正ループを最後まで実行します。例外として、ユーザーが候補の評価のみ（書き直しなし）を希望する場合は、候補一式を1回採点し、ルーブリックの内訳を報告します。完成済みの提案書の評価や、仮説・実験計画の生成には使用しません。

セットアップ

バインディングを対話形式で確定します。作業ディレクトリに loop.run.yaml がある場合は読み込み、値を1行で確認してからループに進みます。ない場合は、Claude Code（AskUserQuestion ツールを使用できます）では各バインディングの妥当と思われる値を推測し、推奨オプションとして提示します。それ以外のホストでは、引用符で囲んだプレーンテキストのプロンプトで各項目を尋ねます。その後、loop.run.yaml（形式：examples/run.example.yaml）を書き込み、他のファイルを作成する前に値を確認します。

binding	意味	デフォルト	推測方法
<topic>	関心のある領域（分野、対象集団、範囲、ユーザーがすでに関心を寄せている事柄）	—	ユーザーに尋ねる
<n_questions>	提示する、十分に優れた課題の数	3	—
<pass_threshold>	優れた課題として数えるために必要なルーブリックスコア（0〜100）	75	完璧を求めず、しっかりした課題となる水準
<novelty_check>	課題がすでに回答されているかを確認する方法：lit | web | none	同系列のスキルがインストールされていれば lit、そうでなければ web	文献検索スキルを確認する（下記）
<report>	出力する課題一式	<sandbox_root>/questions.md	—
<sandbox_root>	台帳とレポートの保存場所	./sandbox	—
<budget>	最大反復回数	8	—

新規性チェックのツールチェーン（novelty_check: lit の場合のみ）。 論文検索には同系列の literature-search スキルを使います（<lit> = <lit_skill_dir>/tools/lit_search.py、<lit_py> = python3、<lit_skill_dir> はインストール先。例：~/.claude/skills/literature-search/）。該当する操作は <lit> search "<q>"（直接的な回答がすでに発表されているかを確認）と <lit> snippet "<q>"（回答箇所を特定）です。セットアップ時に <lit> --help が動作することを確認してください。スキルがない場合はユーザーに伝え、インストールする（リポジトリの loops/literature-search フォルダーを ~/.claude/skills/ にコピーする）か、web（ホストのWebSearch/WebFetch）または none に切り替えてください。再実行時に対話が発生しないよう、確定した選択肢を <novelty_check> に記録します。

ループ

ルーブリック（新たに採点する評価者が、以下の採点基準に従って各課題を軸ごとに0〜5点で採点します）：

軸	5	3	1
具体性	明確な構成概念／関係が1つあり、範囲が適切に定められている	方向性は明確だが、範囲が曖昧	幅広く／曖昧なトピックで、質問になっていない
回答可能性	具体的な研究／分析で解決でき、回答の形が明確	原理的には解決可能だが、アプローチが不明確	実証的／分析的に判断できない
新規性	新規性チェックで未解決と確認済みで、最も近い研究を引用している	一部は扱われているが、明確な新しい切り口が残っている	すでに回答されている（チェックで直接的な回答が見つかった）
実現可能性	データ／手法／アクセスが現実的に確保できる	努力すれば実現可能	入手できないデータや、不可能な測定が必要
重要性	回答によって理解や実践が変わる	有用な進展となる	回答されても重要性はわずか

採点 — イテレーションごとに新しい採点者を起動します（起動できなければ代替）。 各イテレーションで、質問の草案作成者や改訂者とは別の、新たにインスタンス化した採点者サブエージェントを起動します。これにより採点の独立性を保ち、自己採点を防ぎます。各候補とその新規性を示す根拠を渡してください。採点者は、重み付けなしで各軸の0〜5点の素点を返します。Claude Code では実際の Agent として起動します。それ以外の場合は、クリーンなパスでインラインで採点者の役割を担います。オーケストレーターは素点を合計して25点満点の素点を算出し、その後、あらゆる箇所で使う0〜100点のスコアに換算します。

total = 100 × raw / 25 （例：素点20/25 → total 80）。

質問は、total ≥ <pass_threshold> かつ、どの軸も1点ではない場合に有望とみなされます（致命的な軸が1つでもあれば、total に関係なく不合格です）。

このチェックリストをコピーして、項目にチェックを付けてください：

• イテレーション0 — <topic> と、そのトピックの興味深い点を言い換え、異なる切り口（メカニズム、比較、条件／境界、応用）を含む候補質問を3〜5個作成します。まだ有望と記録するものはありません。
• 各候補について、<novelty_check>（<lit> の search／snippet、WebSearch、または省略）で新規性を示す根拠を集めます。
• 採点 — 各候補とその根拠を新しい採点者に渡して起動します。採点者は各軸の素点0〜5を返します。raw/25 → total/100 に換算します。
• 有望な質問ごとに、最も低い軸、つまり有望とみなすうえで妨げとなっている点を特定します。
• その軸を改訂します（質問ごとに焦点を絞った修正を1つ）。致命的な欠陥があり、改訂では救えない質問は除外し、候補が不足していれば新しい候補を追加します。
• 台帳に1行追加します。<n_questions> 個が基準を満たすまで、または <budget> に達するまで続けます。

イテレーション0 — 枠組み作成と草案。 <topic> と、そのトピックの興味深い点を言い換え、異なる切り口を含む候補質問を3〜5個作成します。まだ有望と記録するものはありません。

停止条件（有望な質問が<n_questions> 個に達するか、<budget> に達するまで）に達するまで、以下を繰り返します：

1. 新規性を示す根拠を集めます。 各候補の中核について <novelty_check> を実行します。<lit> search／snippet（またはWebSearch）を使います。直接的な回答がある場合は、最も近い回答済みの研究を記録します。関連研究しかない場合は、未解決の部分を記録します。各 <lit> 呼び出しはJSONを出力します。失敗すると {"error","fallback"} を出力して0以外で終了するため、その場合はWebSearch／WebFetchに切り替えます。
2. 採点します。 新しい採点者を起動（起動できなければ代替）し、各候補とその根拠を渡します。採点者は各軸の素点を返します。raw/25 → total/100 に換算します。
3. 診断して改訂します。 有望な質問ごとに最も低い軸を特定し、その軸に焦点を絞った修正を1つ行います。範囲が広すぎる質問は、具体的な対象集団／条件に絞ります。回答できない質問は、測定可能な比較として操作的に定義します。すでに回答されている質問は、チェックで未解決と判明した部分に向けて方向転換します。意思決定や議論のある主張と結び付け、重要性を高めます。改訂では救えない致命的な軸がある質問は除外し、候補が不足していれば新しい候補を追加します。
4. 記録して台帳に1行追加し、有望な質問が<n_questions> 個に達するまで続けます。

停止時に <report> を作成します。有望な質問それぞれについて、ルーブリックのスコア、新規性に関する注記（最も近い回答済みの研究／未解決の部分）、回答可能である理由（解決につながる研究の形）、重要である理由を記載します。加えて、次点の候補と、それらの妨げとなった軸も記載します。

台帳

<sandbox_root>/ledger.tsv。タブ区切りで、テキスト内にカンマは使用しません。ヘッダー：

iter	question	total	weakest_axis	revision

例：

iter	question	total	weakest_axis	revision
0	how does sleep affect learning	35	specific	drafted; far too broad
1	does sleep timing affect retention	62	answerable	operationalized: spaced-review vs sleep-matched review, 1-week retention
2	does post-learning sleep within 3h beat delayed sleep for procedural retention	86	-	strong (novel per check: tested for declarative not procedural)

最後の反復のセットとは限りません。最も良い結果、つまり優れた質問とそのスコアを報告してください。

制約

• 弱い質問を数多く並べるより、優れた質問を少数に絞る方がよいです — 基準を満たさない質問で<report>を水増ししないでください。報告には含めず、阻害要因となっている評価軸とともに次点として示してください。
• 新規性は確認するものであり、前提とするものではありません — <novelty_check>がlit／webの場合は、実際に検索し、最も近い既回答の研究を引用してください。また、確認結果に反する新規性を主張しないでください。noneの場合は、新規性が未検証であると明記してください。
• 新しい採点者を使って採点してください。各評価軸を未加工の0～5点で採点し（重み付けなし）、オーケストレーターがraw/25 → 100に換算します。作成者／改訂者が自分の質問を採点することは決してないため、スコアの公正さが保たれます。
• 各質問につき、各反復で焦点を絞った改訂を1回行い、最も弱い評価軸を改善してください。これにより改善の効果を特定でき、質問を迷走させずに収束させられます。
• 評価基準としきい値は固定してください。「優れている」の基準が常に同じになります。
• サンドボックス内で完結させてください — ../による外部へのアクセスは禁止です。続行するかどうかを尋ねるためにループを中断せず、<n_questions>個の質問が基準を満たすか、<budget>に達するまで実行してください。