grants

助成金 — NIH 資金調達インテリジェンス

移植性： bash_tool（curl による RePORTER POST 用）、docx パッケージを含む Node.js、Consensus MCP への接続が必要です。Claude Code CLI ではネイティブに動作します。Code Execution + Consensus MCP を使用する Claude.ai でもワークフローはサポートされていますが、処理は遅くなります。

対象範囲：NIH のみ。 NIH 以外の資金提供機関（PCORI、DOD CDMRP、VA、財団）は対象外であり、受付時にその旨が示されます。

研究アイデアを持つ臨床研究者向けに、編集可能な .docx 形式で、戦略的な NIH 資金調達の概要を作成します。出力には、研究の位置づけ分析、研究所のマッピング、対象を絞った助成金の検索、戦略的な提言が含まれ、研究者は内容を編集、引用、指導教員との共有に利用できます。

エージェントの誠実性に関するルール（Research-Pack 規約）

継承したルールです。PR #657 の監査に基づき、原文のまま固定されています。

• 実行規律。 結果が返されたことを確認するまでは、ステップは完了していません。Consensus の呼び出しは順次実行し、1 秒以上間隔を空けます。RePORTER の呼び出しも順次実行します。
• データソース。 このセッション中のツール呼び出しで返された数のみを集計します。学習データの知識で補完してはいけません。学習データの知識には [Not from Consensus/RePORTER — reference information] とラベルを付け、集計から除外します。
• 件数と帰属。 送信したクエリ数／表示された結果数／引用した結果数は、それぞれ別の数として扱い、決して混同してはいけません。引用する各論文には、このセッション中に取得可能な URL が必要です。
• エラー処理。 失敗した場合は、3 秒待ってから 1 回だけ再試行し、記録します。ツール全体で 3 回連続して失敗した場合は、処理を停止して研究者に知らせ、不足している内容を説明します。黙ってスキップしてはいけません。
• 透明性。 DOCX に監査ログのセクションを設けます。チャットの要約にも、文書と同じ基準を適用します。

RePORTER POST の標準パターンとプランの種類の判定については、references/reporter_post_patterns.md を参照してください。

フェーズ 1：掘り下げる受付（回答を迫る質問 6 つを、一度に 1 つずつ）

Q1（起点）— 研究アイデア

研究アイデアを 2～3 文で説明してください。どのような問いで、何が新しく、臨床的にどのような意義がありますか？（「医療のための AI」「疾患 X のバイオマーカー」のような）曖昧な回答は受け付けません。具体的に説明してもらいます。

質問の理由： Consensus で行う 5 つの検索（確立状況／重要性／現在のアプローチ／隣接する手法／ギャップ）には、明確な研究アイデアが必要です。曖昧なアイデアでは、ギャップについての引用も曖昧になり、研究の位置づけを説明する文章も役に立たないものになります。

曖昧な回答は受け付けません。ユーザーの説明が広すぎる場合は、例を示してもう一度質問します。

Q2（Q1 に依存）— キャリア段階

キャリア段階を 1 つ選んでください：

1. 博士課程前（PhD 学生、T32 研修生）
2. ポスドク研究員（F32、K99 の候補者）
3. キャリア初期（K 賞の候補者、初回の R01）
4. 独立研究者（複数の R01 を持つ、研究室を確立済み）
5. シニア PI（R35、P シリーズ、U01 のリーダーシップ）

質問の理由： キャリア段階によって、推奨する助成金制度を絞り込みます。研修生には F シリーズ、キャリア初期には K シリーズ、独立研究者には R シリーズを推奨します。段階を誤って選ぶと、助成対象にならない制度を提案してしまいます。

必ず選択してもらいます。

Q3（Q2 に依存）— 予備データの状況

予備データについて、1 つ選んでください：

1. なし（新規プロジェクトで、予備データはまだない）
2. パイロットデータ（初期の知見、単一施設）
3. 十分な予備データ（複数の実験があり、R01 規模に対応可能）
4. 検証済みで準備完了（複数施設で実施済み、論文発表の準備が整っている）

質問の理由： 予備データの状況は、助成金制度と予算規模を左右します。データがない場合は、R03／R21 のパイロット規模が適しています。十分な予備データがある場合は、R01／U01 の複数施設規模が適しています。状況との不一致は、競争力のない申請につながります。

Q4（Q2 に依存）— 研究環境

研究環境を 1 つ選んでください：

1. R01 の応募資格あり（NIH 基礎資金を持つ、研究集約型の機関）
2. 中規模（地域の学術医療センターで、NIH 資金ポートフォリオは小規模）
3. リソースが限られている（小規模な機関で、NIH 基礎資金は最小限）
4. 産業界との連携あり（大学と産業界のパートナーシップ）

質問の理由： 研究環境は、研究規模の現実性（複数施設の U01 には R01 の応募資格が必要です）と、どの助成金制度が競争力を持つか（R15 はリソースが限られた機関を特に対象とします）に影響します。

Q5（Q1 に依存）— 提出状況

提出状況 — 1 つ選んでください：

1. 新規申請（初回提出、過去の審査なし）
2. 再提出（A1、審査員への回答が必要）
3. 検討中（提出するかどうか未決定）

質問の理由： 再提出では、DOCX（セクション 7）に審査員への回答に関するガイダンスが必要です。新規申請では不要です。検討中の場合は、戦略よりも分野の全体像に重点を置きます。

Q6（Q1 に依存）— 検討中の研究所

すでに特定の NIH 研究所を検討していますか？名称（NCI / NHLBI / NIMH / NINDS / NIDDK / など）を列挙するか、「希望なし — 適切なものを探してください」とお答えください。

質問の理由： 研究所について仮説がある場合は、RePORTER のデータに照らして検証します。ない場合は、研究所別の集計から、関連研究に資金を提供している上位 3 つの研究所を提示します。

一般的な回答として、「希望なし」を受け入れてください。

停止条件： Q6 の後、確定して Phase 2A を開始します。Phase 2A の開始後に、インテークを再開してはいけません。

Phase 2A：研究の位置付け（Consensus 検索 5 件）

1 秒あたり 1 件のペースで順番に実行します。各検索は、位置付けの 1 つの側面に対応します。

1. 確立事項 — "<research idea>" established evidence — 既知の内容
2. 重要性 — "<topic>" mortality OR burden OR cost OR prevalence — なぜ重要なのか
3. 現在のアプローチ — "<topic>" current treatment OR standard of care OR approach — 最先端の状況
4. 関連手法 — "<related technique>" applied to <topic> — 方法論上の可能性
5. ギャップ — "<topic>" limitations OR unanswered OR future directions OR challenge — ギャップの兆候

各検索で scripts/citation_tracker.py --action record_consensus_search を使用します。最初の応答からプランのティアを判定します。

統合： 各側面について、引用可能な知見を 2〜3 件抽出します（セクション 2 のギャップに関する引用になります）。Significance/Innovation の文案は、「この分野では X が確立されている（参考文献）が、Y は未解明のままである（参考文献）」というパターンで作成します。

Phase 2B：研究所のマッピング + 助成金の検索（RePORTER POST）

RePORTER は POST のみです。bash_tool と curl を使用し、web_fetch は決して使用しないでください。

動的な会計年度の範囲

scripts/fiscal_year_calculator.py を使用して実行時に計算します。既定値：現在の会計年度 + 過去 3 年。連邦政府の会計年度は 10 月 1 日に始まります。

python scripts/fiscal_year_calculator.py --output json
# Returns: {"current_fy": 2026, "window": [2023, 2024, 2025, 2026]}

絞り込み検索（AND）— 直接重複する研究を検索

curl -X POST 'https://api.reporter.nih.gov/v2/projects/search' \
  -H 'Content-Type: application/json' \
  -d '{
    "criteria": {
      "fiscal_years": [2023, 2024, 2025, 2026],
      "include_active_projects": true,
      "advanced_text_search": {
        "operator": "AND",
        "search_field": "all",
        "search_text": "<key term 1> <key term 2>"
      }
    },
    "limit": 50,
    "include_fields": ["project_num", "project_title", "agency_ic_admin", "study_section", "fiscal_year", "principal_investigators", "abstract_text"]
  }'

広範検索（OR）— 関連する研究を検索

curl -X POST 'https://api.reporter.nih.gov/v2/projects/search' \
  -H 'Content-Type: application/json' \
  -d '{
    "criteria": {
      "fiscal_years": [2023, 2024, 2025, 2026],
      "advanced_text_search": {
        "operator": "OR",
        "search_field": "all",
        "search_text": "<term> <synonym> <related concept>"
      }
    },
    "limit": 50
  }'

研究所の集計 + 研究セクションのランキング

RePORTER の応答後：

• agency_ic_admin（研究所コード：NCI、NHLBI、NIMH など）を集計 → 資金提供上位 3 研究所
• study_section を集計 → 上位 2 つの研究セクション（申請が審査に回される先）

NOSI の検索

RePORTER の応答から NOT-* の機会番号を解析します。それぞれについて：

# NOSIs live at predictable URLs:
# https://grants.nih.gov/grants/guide/notice-files/NOT-<INSTITUTE>-<YEAR>-<NUMBER>.html
web_fetch <url>

取得に失敗した場合は、[NOSI {number} — fetch failed, not included] を記録して続行します。

メカニズムのマッチング（範囲を考慮）

キャリアステージだけで判断してはいけません。キャリアステージ + プロジェクトの範囲 + 予備データをもとに推奨します。

scripts/mechanism_matcher.py を使用します。

python scripts/mechanism_matcher.py \
  --career-stage "early_career" \
  --prelim-data "pilot" \
  --environment "r01_eligible" \
  --scope "single_site" \
  --output json
# Returns mechanism shortlist with rationale

全体のマトリックスは references/nih_mechanism_matching.md を参照してください。

フェーズ 3：DOCX の生成

Node.js と docx ライブラリを使用して9つのセクションを作成します。完全な仕様については、references/docx_9_sections.md を参照してください。

1. エグゼクティブサマリー — タイトル + キャリア段階 + 環境 + 主な知見を3～4項目の箇条書きで記載
2. 研究の位置づけ — ギャップを示す引用を3～5件（斜体、Consensus の引用をインラインで記載）+ 位置づけを説明する2～3段落 + 根拠となる証拠の表
3. 対象機関 — 順位表（機関、対象期間内のプロジェクト数、アイデアとの一致率）+ 2～3文の解釈
4. 助成金の機会 — 該当する場合は、NOSI のコールアウトを太字で記載。上位3件の助成金を表にまとめ、FOA へのハイパーリンクを設定 + 助成金ごとに、研究範囲と予算の適合性を説明する段落
5. 重複する助成済み研究 — 上位5件のプロジェクトを表にまとめる（PI、project_num、IC、年、RePORTER へのハイパーリンク）+ 差別化に関する段落
6. 研究セクション — 順位表 + 最適な適合先の解釈
7. 戦略的な推奨事項と次のステップ — 3～4件の番号付き推奨事項 + 必須のプログラムオフィサー推奨 + 申請スケジュールに関する注記 +（再申請で Q5=2 の場合）審査員への回答に関するガイダンス + 締めくくりの段落
8. 参考文献 — Consensus へのハイパーリンクを設定した番号付き参考文献一覧
9. 監査ログ — Consensus 検索の表、プランの階層に関する注記、RePORTER 検索の表、NOSI 取得の表、概要統計、ツールの制約に関する注記、失敗した手順

スタイル

本文は Arial 12pt、見出しはネイビー（#1a3a5c）、表のヘッダーはライトブルー（#e8f0f8）、NOSI のコールアウトはアンバーを使用します。ExternalHyperlink のパターン：

• 論文の引用：https://consensus.app/papers/...
• FOA リンク：https://grants.nih.gov/grants/guide/...
• RePORTER プロジェクト：https://reporter.nih.gov/project-details/<id>

必須のプログラムオフィサー推奨

セクション7には、必ず次の内容を含めてください。

推奨する次のステップ：{最上位の機関} のプログラムオフィサーに連絡してください。 スタッフのページは、https://www.nih.gov/institutes-nih/list-nih-institutes-centers-offices → {institute} → Program Officers から確認できます。準備するもの：1ページの具体的な研究目的 + CV + 適合性に関する具体的な質問を3つ。メールの件名：「事前申請に関するお問い合わせ：」。

これは、あらゆる申請者にとって最も価値のあるアドバイスです。絶対に省略しないでください。

申請スケジュール（DOCX のセクション7に記載）

助成制度	通常の受付日
R01, R21, R03	2月5日、6月5日、10月5日
K awards (K01, K08, K23, K99)	2月12日、6月12日、10月12日
R34, R61/R33	2月16日、6月16日、10月16日
F31, F32	4月8日、8月8日、12月8日

フェーズ 4：成果物の提出

• DOCX を <output-dir>/grants_<topic-slug>_<YYYY-MM-DD>.docx に保存します
• チャットの要約：ファイルパス + 監査件数 + プランの階層 + 対象機関に関する評価
• 検証：python3 -c "import zipfile,sys; zipfile.ZipFile(sys.argv[1]).testzip()" <docx> で ZIP の整合性を確認します（出力がなければ正常）。続いて、必須のセクションが揃っていることを確認します

ツール

スクリプト	役割
scripts/citation_tracker.py	3種類の件数を監査（Consensus の送信数／表示数／引用数 + RePORTER のプロジェクト数／引用数）。~/.grants_sessions/<session>.json に記録
scripts/fiscal_year_calculator.py	現在の会計年度 + 過去3会計年度の対象期間。実行時に計算し、ハードコードしません。
scripts/mechanism_matcher.py	キャリア段階 × 研究範囲 × 予備データ → 助成制度の推奨候補一覧

参考資料

• references/nih_mechanism_matching.md — キャリア段階 × 研究範囲 × 予備データに基づく助成制度の基準（7件以上の情報源）
• references/reporter_post_patterns.md — RePORTER の curl POST テンプレート + プラン階層の判定（7件以上の情報源）
• references/docx_9_sections.md — 9セクションの .docx 仕様 + 技術要件（7件以上の情報源）

エラー処理

失敗	動作
Consensus のレート制限に達した	3 秒待って 1 回再試行し、ログに記録します。それでも失敗する場合は研究者に通知します
Consensus があるファセットで 0 を返す	明示的に提示し、トレーニング知識で補完しません
Consensus のプラン階層上限を検出した	階層をログに記録し、監査ログに記載して、研究者に提示します
RePORTER の POST がエラーを返す	3 秒後に 1 回再試行します。それでも失敗する場合はログに記録して続行します
RePORTER が絞り込み検索で 5 件未満を返す	記録します。広範な OR 検索で補完し、件数が少ないことを提示します
NOSI の取得に失敗した	[NOSI {n} — fetch failed] をログに記録して続行します
ツールで 3 回連続して失敗した	停止し、不足しているものを研究者に通知します
DOCX の生成に失敗した	研究者の作業が失われないよう、生データを JSON の代替形式で保存します

避けるべきアンチパターン

• Consensus の呼び出しを並列化する（レート制限に達します）
• RePORTER に web_fetch を使用する（POST 専用です。web_fetch は GET です）
• 会計年度の値をハードコードする
• キャリア段階だけに基づいてメカニズムを推奨する（スコープも考慮する必要があります）
• ファセットの結果が少ない場合に、トレーニング知識で黙って補完する
• 監査ログを省略する
• プログラムオフィサーの推薦を省略する
• 「見つかった論文」「表示された論文」「引用された論文」を混同する
• 取得に失敗した場合に NOSI の詳細を捏造する

---

バージョン： 1.0.0 ソース仕様： megaprompts/08-grants-megaprompt.md（メンテナーのローカル草案仕様 — gitignore 対象のため、公開リポジトリにはありません） ビルドパターン： Path B（直接変換）。pulse + litreview の兄弟にあたる research-pack。