mcpField
H
hypothesis-gen

hypothesis-gen

github.com/gaasher生産性17840 回インストール17 週間前に更新
リポジトリ

hypothesis-gen について

hypothesis-genは、文献検索に基づいて仮説を生成し、評価と重複排除を行うマルチエージェントスキルです。研究課題について検証可能な候補仮説を作成し、選別する用途に向いています。

主な機能

  1. 01研究上の空白に沿った仮説生成
  2. 02文献に基づく新規性と根拠の確認
  3. 03固定基準による候補の採点と選別
  4. 04仮説プールの重複排除と管理
  5. 05飽和またはラウンド上限で停止

活用シーン

  1. 01研究分野の候補仮説の生成
  2. 02先行研究で確立済みの主張の除外
  3. 03仮説、根拠、検証計画の整理

インストール

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

$npx skills add https://github.com/gaasher/agent-loop-skills --skill hypothesis-gen

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

同梱ファイル

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

examples/
run.example.yaml
roles/
Generator.md
Judge.md
LiteratureScout.md
schemas/
litscout.schema.json
verdict.schema.json

詳細

仮説生成ループ

複数のエージェントが参加し、文献に基づく生成ループです。成果物は増え続ける仮説プールです。フィードバック信号は、基準を満たす有力で互いに異なる仮説の数です。「有力」かどうかは、主張ではなく、実際に検索された文献に基づいて判断します。各ラウンドでは、生成 → 根拠付け → 判定 → 採用 → 見落としに向けた変異を行い、プールの増加が止まる(飽和する)まで続けます。

規律として、仮説がプールに入るのは、文献によってすでに確立されていないこと(新規性)が示され、先行研究によって妥当性が裏付けられ(根拠付け)、実行可能な検証方法がある場合に限ります。生成は確認ではありません。出力は、検証方法がそれぞれ明記された、有力な検証候補の順位付きリストです。

役割(すべて roles/ 内):

  • roles/Generator.md — 未解決の見落としを狙った仮説候補をまとめて提案します。
  • roles/LiteratureScout.md — 各候補を実際の文献に基づいて根拠付けます(新規性・裏付け・見落とし)。litscout.json を出力します(schemas/litscout.schema.json に照らして検証します)。
  • roles/Judge.md — 固定の評価基準に基づいて各候補を採点し、採用・却下・重複除去を決定します。verdict.json を出力します(schemas/verdict.schema.json に照らして検証します)。

起動するか、品質を下げて進めるか。 Claude Code では、各ラウンドで Generator/LiteratureScout/Judge を実際の Agent サブエージェントとして起動します。それ以外の場合は、このコンテキスト内で各役割を担います。あなたはオーケストレーターです。

使用する場面

ユーザーが、ある問いや分野について仮説候補の生成と審査を求めている場合に使用します。デフォルトでは、飽和するまで以下の完全な生成→根拠付け→判定ループを実行します。例外として、ユーザーが単一の候補群だけを求めている場合(ループなし)は、1ラウンド実行し、採用した仮説を報告します。問いの明確化や分解、既存の執筆済み提案の評価には使用しません。

セットアップ

バインディングを対話形式で解決します。 作業ディレクトリに loop.run.yaml がある場合は読み込み、値を1行で確認してループに進みます。ない場合は、Claude Code(AskUserQuestion ツールが利用可能)の場合、各バインディングのもっとも妥当と思われる値を推測し、推奨オプションとして提示します。それ以外のホストでは、引用符付きのプレーンテキストプロンプトでそれぞれ質問します。その後、ほかのファイルを作成する前に loop.run.yaml(形式:examples/run.example.yaml)を書き込み、すべての値とライブ/縮退状態の文献ティアを確認します。

バインディング意味デフォルト推測方法
<question>研究上の問い/分野と、範囲(領域、対象集団、制約など)—ユーザーに尋ねる
<gen_n>Generator が1ラウンドごとに提案する仮説候補数6—
<keep_threshold>仮説が候補プールに入るために超える必要があるルーブリックスコア(0~100)65—
<eval_scale>LiteratureScout の根拠付けの深さ(low/medium/high。以下を参照)medium—
<sandbox_root>ラウンド、台帳、文献キャッシュの保存場所./sandbox—
<budget>最大ラウンド数6—
<patience>新たに採用された仮説がない状態で、この回数のラウンドが続いたら停止2—
<report>最終的に順位付けされた仮説セット<sandbox_root>/hypotheses.md—

根拠付けの深さの設定(<eval_scale> によるラウンドごとの上限:詳細に検討する候補数・各候補のクエリ数・全文を読む論文数):

プリセット詳細に検討する候補数各候補のクエリ数全文を読む論文数
low210(スニペット/要旨のみ)
medium (推奨)すべて21
highすべて33

文献ツールチェーン。 論文検索には、兄弟ディレクトリにある literature-search スキルを使用します。<lit_skill_dir>(兄弟ディレクトリとしてインストールされます。例:~/.claude/skills/literature-search/)、<lit_py> = python3、<lit> = <lit_skill_dir>/tools/lit_search.py(tools/ セグメントに注意)を解決します。キャッシュを再利用するには、サブコマンドの後に --cache-dir <sandbox_root>/literature/.cache を追加します。セットアップ時に <lit> --help が動作することを確認してください。スキルがない場合はユーザーに伝え、インストールする(リポジトリの loops/literature-search フォルダーを ~/.claude/skills/ にコピーする)か、すべての検索を WebSearch/WebFetch に切り替えてください(その根拠には source:"web" のタグを付けます)。キー不要の S2 と arXiv のコア機能にはセットアップは不要です。無料の S2_API_KEY があれば、snippet/cite の信頼性が高まります。

API キー(任意。処理を止めないでください)。 literature-search スキルがキーの規約を管理します。<lit> keys --init を実行し、表示された keys.env はユーザー自身に記入してもらいます。チャットに秘密情報を貼り付けるよう求めてはいけません。<lit> keys を再実行し、ティアを loop.run.yaml に記録します(存在の有無のみ)。キーがない場合は、キー不要のプールから WebSearch に切り替えるだけです。

バインディングの確認後にサンドボックスを初期化します。

<sandbox_root>/
├── loop.run.yaml        ← resolved bindings + literature_tiers
├── ledger.tsv           ← header only (see Ledger)
└── literature/.cache/   ← lit_search on-disk cache

空の pool から始め、<question> をもとに gaps を設定します。ループの実行が始まるまでは、ラウンドファイルを作成しないでください。

ループ

pool = 採用した仮説(初期値は空)。gaps = LiteratureScout が明らかにした未解決の問い (初期値は空。<question>から設定します)。dry = 新たに採用された仮説がない連続ラウンド数(初期値は0)。<N> は1から開始します。

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

  • 生成 — <question>、現在のpool、gaps、<gen_n>を指定してroles/Generator.mdを実行します(spawn-or-degrade)。round<N>/candidates.jsonに、<gen_n>個の具体的で検証可能かつ新規性がありそうな候補を出力します。候補はギャップを対象とし、pool内の仮説と重複しません。
  • 根拠付け — candidates.jsonに対してroles/LiteratureScout.mdを実行し(spawn-or-degrade)、<lit>と<eval_scale>の上限を適用します。round<N>/litscout.jsonに出力され(schemas/litscout.schema.jsonで検証)、候補ごとに新規性と最も近い先行研究、裏付け、ギャップ、検証可能性を記載します。それぞれに実在する根拠を引用します。
  • 判定 — roles/Judge.mdとして、固定の評価基準と根拠ゲートをlitscout.jsonに適用し、各候補をpoolと照合して重複を確認します。round<N>/verdict.jsonに出力します(schemas/verdict.schema.jsonで検証)。スコア、total、keep、duplicate_ofを記載します。
  • 更新 — keep:trueで重複していないものをすべて、スコア、根拠付け、検証方法とともにpoolに追加します。このラウンドのgap項目をgapsに追加します。新たな採用が1件以上あればdry = 0、なければdry += 1とします。
  • 記録 — 台帳に1行記録します(「台帳」を参照)。N = N + 1とします。
  • 停止判定 — dry == <patience>(飽和)またはN > <budget>なら停止します(「停止条件」を参照)。

毎ラウンド、根拠を再確認します — 新規性は毎回の新たな文献調査に基づいて判断し、前のラウンドから引き継ぎません。そのため、「文献ですでに扱われている」という結果が、競合の多いアイデアを確実に退けます。引用する抜粋はすべて、そのラウンドに実際に検索して得られたものです。{"error","fallback"}の場合はWebSearch/WebFetchに切り替え、論文を捏造してはいけません。

schemas/litscout.schema.jsonでLiteratureScoutの出力を検証します。汎用的なインスタンスの例:

{"round": 2,
 "evaluations": [{"hid": "r2h1", "novelty_assessment": "novel",
   "closest_prior_work": [{"claim": "X tested for facts, not skills", "cites": ["E1"]}],
   "support": [{"claim": "spacing aids motor consolidation", "cites": ["E2"]}],
   "gap": [{"claim": "long-term procedural retention untested at scale", "cites": ["E1"]}],
   "testability_note": "RCT: spaced vs massed schedule, 1-month retention."}],
 "evidence": [{"key": "E1", "title": "...", "source": "s2", "id": "a1b2", "snippet": "...verbatim..."}]}

schemas/verdict.schema.jsonでJudgeの出力を検証します。汎用的なインスタンスの例:

{"round": 2,
 "verdicts": [{"hid": "r2h1",
   "scores": {"novelty": 4, "grounding": 4, "testability": 5, "specificity": 4, "significance": 4},
   "total": 82.0, "keep": true, "gate_failures": [], "duplicate_of": null,
   "rationale": "Closest work shows X untested for skills -> novel; supported; clean RCT named."}]}

台帳

<sandbox_root>/ledger.tsvはタブ区切りで、自由記述にカンマは使用しません。ヘッダー:

round	generated	kept_new	pool_size	top_kept

例:

round	generated	kept_new	pool_size	top_kept
1	6	3	3	spaced practice aids procedural (not just declarative) retention [82]
2	6	2	5	sleep-timed review beats time-of-day-matched review [78]
3	6	0	5	-

各ラウンドのcandidates.json/litscout.json/verdict.jsonはround<N>/に格納されます。停止時には直近のラウンドだけでなく、poolの最良の状態を報告してください。ledger.tsv、round*/、literature/は未追跡のままにしてください。

制約

  • 引用や抜粋を決して捏造しないでください — すべての根拠項目は、そのラウンドで<lit>/WebFetchから実際に取得した内容をそのまま記載します。根拠ゲートは捏造を検出するためにあります。
  • 新規性は主張ではなく文献に基づいて判断します — 検索の結果、すでに確立されていると分かった仮説は、どれほど魅力的でも退けます。最も近い先行研究を検索せずに「新規だと思う」と主張する場合、新規性の上限を適用します。
  • 生成は確認ではありません — 採用された仮説は、検証方法を明記した、検証に値する有力な候補です。確立された知見として報告してはいけません。
  • 評価基準は固定し、採用基準はラウンドを通じて一貫させます。そのため、飽和は有意義な停止条件になります。
  • 量ではなく、独立した仮説を評価します — 重複や言い換えは除外します。
  • インストールは禁止です — 兄弟スキルのliterature-searchは標準ライブラリのみで動作します。APIキーを表示またはコミットしてはいけません(keys.envはプロジェクトルートでGitの追跡対象外にします)。サンドボックスは自己完結しており、../で外部にアクセスしてはいけません。
  • 続行するか尋ねるためにループを中断しないでください。飽和または予算到達まで実行します。

停止条件

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

  • 飽和 — 新たに採用された仮説がないラウンドが<patience>回連続する(dry == <patience>)。
  • 予算 — <budget>回のラウンドに到達する。

最後に、順位付けした仮説セット(<report>のパス)を提示します。各仮説について、主張、新規性の評価と最も近い先行研究(引用付き)、裏付けとなる根拠(引用付き)、埋めるギャップ、検証方法を記載してください。さらに、ledger.tsvに記録されたpoolサイズの推移と、未探索のギャップのうち有望なものを示し、精査済みの仮説と、さらに深く調査する場合に次に注目すべき領域の両方が分かるようにしてください。

コメント