対象読者: SPReAD-1000（第2回公募: 2026年6月）への応募を検討している大学の研究者
キーワード: AI for Science, SPReAD-1000, 研究設計, AI駆動型科学, AIRA, Co-Scientist
はじめに
文部科学省が2026年度に立ち上げた 「AI for Scienceによる科学研究革新プログラム」 の中核事業 SPReAD-1000（Supporting Pioneering Research through AI for 1,000 Discovery challenges）の第1回公募が2026年5月に締め切られ、第2回公募が2026年6月上旬に開始予定です [6]。
本記事では、SPReAD-1000 への応募を検討する研究者が押さえるべきポイントを解説します。
- SPReAD-1000 とは何か — 制度の全体像と応募手続き
- AI for Science の2つの定義 — 文科省版とマイクロソフト版の違い
- 研究設計の落とし穴 — 「GPU サーバーを買う・LLM API を使う」だけでは不十分な理由
- 申請書の書き方 — 構造・プロセス・6審査観点による自己採点
- 分野別の応募例 — 人文学・生命科学・工学の具体例
- 100件の自動研究実験からの教訓 — AI Co-Scientist 実験が示す研究設計の要点
- 応募前の最終チェックリスト — 提出前の確認事項
AI に詳しくなくても大丈夫です。本記事では専門用語に 用語解説 を付けています。
この記事の読み方
| あなたの状況 | おすすめの読み方 |
|---|---|
| SPReAD-1000 を初めて知った | 最初から順番に読む（§1→§2→…） |
| 制度は知っているが申請書の書き方がわからない | §4（申請書の書き方）→ §5（応募例）→ §7（チェックリスト） |
| AI に詳しくない | §2（AI for Science とは）→ §3.6（4タイプ診断）→ §4.7（コード量の見積り） |
| もう応募書類を書き始めている | §4.5（申請書の構造）→ §4.6（6審査観点で自己採点）→ §7（チェックリスト） |
用語解説
本記事で使用する AI 関連の用語を先に整理します。AI の専門家でない研究者 を対象としているため、最低限の理解で読み進められるようにしています。
| 用語 | 意味 |
|---|---|
| LLM（大規模言語モデル） | ChatGPT 等の基盤となる AI モデル。大量のテキストから学習し、文章の生成・要約・翻訳などを行う |
| ファインチューニング | 汎用の AI モデルを、特定分野のデータで追加学習させて専門化すること |
| GPU | AI の計算を高速に処理する専用チップ。NVIDIA A100, H100 等が代表的 |
| DOE（実験計画法） | 効率的に実験条件を設定するための統計学的手法 |
| Foundation Model | 大規模データで学習した汎用 AI モデル。様々なタスクに転用できる |
| Agentic AI | 人間の指示を受けて自律的にタスクを実行する AI。検索・分析・コード生成を自律で行う |
| MCP（Model Context Protocol） | AI エージェントが外部ツール（データベース、計算サーバー等）と連携するための標準規格 |
| e-Rad | 府省共通研究開発管理システム。科研費等の研究費申請に使われるオンラインシステム |
1. SPReAD-1000 とは何か
1.1 SPReAD-1000 が目指すもの
SPReAD-1000 は、日本のあらゆる分野の研究者がAIを研究に取り入れる「最初の一歩」を踏み出す ための事業です [1]。
事業の目的（公募要領より）:
「我が国のあらゆる分野の研究者等がAIを利活用して科学研究の高度化・加速化を図ることで、AI for Scienceの波及・振興を促進し、我が国独自の競争優位性につながる革新的な研究の種や芽を生み出す」 [2]
つまり SPReAD-1000 は、次の3つを同時に達成しようとしています。
| 目標 | 意味 |
|---|---|
| 🌱 裾野の拡大 | AI を使ったことがない研究者にも門戸を開き、全分野でAI活用の文化を根付かせる |
| 🔬 萌芽的研究の創出 | 小規模でも独創的な「種」を1,000件規模で生み出し、次世代の大型研究（ARiSE等）につなげる |
| ⚡ 研究プロセスの革新 | 「計算を速くする」だけでなく、仮説生成・実験設計・解析・論文化を含む研究サイクル全体をAIで変える |
重要なメッセージ: SPReAD-1000 は「AIの専門家が最先端のAI研究をする」ための事業ではありません。あなたの専門分野にAIを持ち込み、これまでできなかった科学的問いに挑戦する ための事業です。
1.2 制度の概要
| 項目 | 内容 |
|---|---|
| 正式名称 | AI for Science萌芽的挑戦研究創出事業（SPReAD） |
| 英語名 | Supporting Pioneering Research through AI for 1,000 Discovery challenges |
| 実施主体 | 文部科学省 |
| 補助上限 | 1課題あたり 500万円以下（直接経費）+ 間接経費30% |
| 採択予定 | 2回の公募を通じて計 約1,000件 |
| 研究期間 | 約6ヶ月（第1回: 交付決定日〜2027年1月6日） |
| 対象分野 | 人文学・社会科学から自然科学まで 全分野 |
| 応募資格 | 日本国内の大学・研究機関に所属する研究者・学生（有給・無給問わず） |
1.3 3つの支援の柱
SPReAD-1000 は、単なる研究費の配分ではなく 3つの支援 を一体的に実施します。
| 柱 | 内容 | 具体的なサポート |
|---|---|---|
| ① 迅速な支援 | AI分野の急速な技術変化に対応した機動的な資金支援 | 従来の科研費より迅速な審査・交付プロセス |
| ② 伴走支援 | AI導入の知見を適時に提供 | 計算資源活用のアドバイス、データ整備支援、AI技術相談 |
| ③ 独創的研究の芽出し支援 | 小規模でも独創的な研究アイデアの試行を積極支援 | 失敗を許容する評価体制、分野を問わない採択方針 |
伴走支援を活用しよう: 採択後は、AI に詳しくない研究者にも計算資源の使い方やデータ整備の助言が提供されます。「AI は使ったことがないが、自分の分野でこう使えるかもしれない」という段階でも応募できます。
1.4 対象経費の例
- 計算資源（クラウドGPU、HPC利用料）
- データ取得・利用料
- API利用料（OpenAI API、科学データベースAPI等）
- 設備費（ロボットアーム等）
- データ整理・確認作業に係る謝金
人件費は対象外 です。ここでいう「人件費」とは、研究代表者本人や共同研究者（大学教員等）の 給与・報酬 のことです。つまり、自分の人件費をこの補助金から支出することはできません。一方、研究補助のためのアルバイト・学生への 謝金（データ入力作業、実験補助等に対する対価）は支出可能です。
1.5 審査の特徴 — 従来の科研費とここが違う
SPReAD-1000 では従来の科研費とは異なる 革新的な審査手法 が導入されています（詳細は必ず最新の公募要領をご確認ください）。
| 審査要素 | 従来の科研費 | SPReAD-1000 |
|---|---|---|
| 書面審査 | 複数の専門家による合議 | 分野別にランダム採番→採番順にピアレビュー |
| 面接 | 一部の種目のみ | AIを活用したインタビュー型審査 |
| 評価の重点 | 計画の実現可能性 | 挑戦の独創性 |
| 業績の重視 | 高い | 比較的低い（萌芽的研究を重視） |
ランダム選考とは、各分野ごとに応募課題をランダムに自動採番し、その採番順に人間の専門家によるピアレビューを行い、採択数が上限に達した時点で審査を終了する方式です。審査の順番が無作為化されることで、「計画書の巧みさ」や「提出タイミング」ではなく、研究内容そのものの独創性 が評価される仕組みになっています。
AIインタビュー審査では、AI が応募者に質問を行い、研究の着想や方法論について対話的に評価します。計画書の文章力よりも、研究者自身の理解と情熱 が問われます。
AIインタビューで想定される質問例:
| 質問のカテゴリ | 想定質問 |
|---|---|
| Why AI? | なぜこの研究にAIが必要なのか？従来手法では何ができないのか？ |
| 方法論 | 具体的にどのAI技術を、どのデータに適用するのか？ |
| 実現可能性 | 6ヶ月で何をどこまで実証するのか？ |
| 失敗への備え | 期待通りの結果が出なかった場合、何が分かるのか？ |
| 波及効果 | 成果を他分野にどう共有するのか？ |
対策: 応募書類に書いた内容を、専門外の人にも 口頭で説明できる レベルまで消化しておくことが重要です。「書いたが説明できない」は最悪のパターンです。
1.6 応募手続きの流れ
e-Rad の研究者登録がまだの方は、早めに登録を済ませてください（登録に数日かかる場合があります）。
1.7 第2回公募スケジュール（予定）
| フェーズ | 時期 |
|---|---|
| 公募開始 | 2026年6月上旬 |
| 公募締切 | 未定（第1回は約1ヶ月間） |
| 審査 | 公募後約1ヶ月 |
| 交付決定 | 審査後約1ヶ月 |
1.8 SPReAD と ARiSE の違い
文科省の「AI for Science」施策には SPReAD と ARiSE（AI to Redesign Scientific Exploration：AI for Science革新的研究推進事業）の2本柱があります [12]。両者は補完関係にあり、SPReAD で生まれた「種」が将来 ARiSE のような大型研究に発展することが期待されています。
| 項目 | SPReAD（萌芽的挑戦） | ARiSE（革新的研究） |
|---|---|---|
| 正式名称 | AI for Science萌芽的挑戦研究創出事業 | AI for Science革新的研究推進事業 |
| 英語名 | Supporting Pioneering Research through AI for 1,000 Discovery challenges | AI to Redesign Scientific Exploration |
| 実施機関 | 文部科学省 | JST（科学技術振興機構） |
| 予算規模 | 500万円/件 × 約1,000件 | 戦略ターゲット型: 10〜30億円/件、国際融合型: 最大2億円/件 |
| 研究期間 | 約6ヶ月 | 3〜6年程度 |
| 対象 | 全分野の研究者・学生 | AI for Science の先端研究チーム |
| AI経験 | 不問 | 高度な専門性を要求 |
| 性格 | ボトムアップ型・探索的 | トップダウン型・戦略的 |
| 公募時期（2026年度） | 第1回: 4〜5月、第2回: 6月上旬 | 2026/5/12〜6/30 |
ARiSE の2つの区分:
| 区分 | 戦略ターゲット型 | 国際融合型 |
|---|---|---|
| 目的 | 科学基盤AIモデル・AIエージェント・次世代AI駆動ラボの統合開発 | 国際連携による独創的AI研究・ツール開発 |
| 予算 | 10〜30億円（間接経費含む） | 最大2億円（間接経費含む） |
| 期間 | 3〜6年 | 3〜5年 |
| 特徴 | 日本の強みを活かすフラグシップ研究 | 海外研究者との共同提案（日本側のみ資金支援） |
迷ったら SPReAD: AI を研究に初めて導入する場合は SPReAD が適しています。ARiSE は既に AI for Science の実績がある研究グループ向けの大型競争的資金です。SPReAD での成果が ARiSE への足がかりになります。
2. AI for Science — 2つの定義を理解する
2.1 共通するビジョン
文科省もマイクロソフトも、「AIによって科学研究プロセスを加速する」 という目標は同じです [3]。仮説生成→実験設計→データ収集→解析→論文化という研究サイクルの各段階にAIを導入し、従来は数年かかった発見を数週間〜数日に短縮する——このビジョンは両者に共通しています。
では何が違うのか。それは 「研究者とAIの関係性」 です。
2.2 決定的な違い：AIの自律度
両者の違いは「人間がいるかいないか」ではありません。どちらも Human-in-the-Loop（人間の関与）を前提としています。違うのは AIの自律度 と 誰が研究サイクルを駆動するか です。
| 文科省版「AI for Science」 | MS版「AI-driven Science」 | |
|---|---|---|
| 一言で | 研究者がAIを道具として使う | AIエージェントが研究を駆動し、研究者が監督する |
| Human-in-the-Loop | ✅ 全工程で研究者が主体的に判断 | ✅ 研究者が目標設定・検証・意思決定を担う |
2.3 文科省版：研究者が主役、AIは「強力な道具」
文科省の定義は 「AIを研究の道具として組み込み、科学研究プロセス全体の高度化・加速化をはかる営み」 です。
ポイント: 各ステップの 主語は研究者。AIは研究者の判断を支援・加速する道具。
特徴:
- 🎯 裾野拡大重視: AI未経験の研究者も対象（「まず使ってみよう」）
- 🌐 全分野横断: 人文学・社会科学も含む
- 🌱 萌芽的・探索的: 小規模でも独創的であればOK
- 🤝 Human-in-the-Loop: 研究者が主体的に意思決定し、AIはその判断を支援
2.4 マイクロソフト版：AIエージェントが駆動し、研究者が監督する
マイクロソフトの定義は、専門AIエージェント群が研究サイクルを自律的に駆動 し、研究者が目標設定・検証・意思決定で関与する「第5の科学パラダイム」です [4] [5]。2025年に発表された Microsoft Discovery では、この思想が具体化されています。
ポイント: 研究サイクルの 駆動はAIエージェント。ただし研究者は常に監督者として関与し、目標設定、結果の検証、重要な意思決定を担う（Human-in-the-Loop）。
Microsoft Discovery の具体例:
- 💧 データセンター冷媒の発見: AIエージェントが新規冷媒候補を探索→シミュレーション→合成指示を自動実行し、従来数年かかるプロセスを 約200時間 で完了。研究者は候補の安全性評価と最終判断を担当 [9]
- 💊 GSKとの創薬連携: AIエージェントが分子設計→相互作用予測→候補絞込みを自律実行し、研究者が臨床的妥当性を評価
- 🧴 エスティローダーとの素材開発: AIが素材候補を生成、研究者が官能評価と安全性判定
特徴:
- 🤖 Agentic AI: 文献調査、分子シミュレーション、実験設計を行う専門AIエージェント群がCopilotの指揮下で協調動作
- 🔄 クローズドループ: 設計→実験→解析→再設計を自動反復（研究者は各イテレーションで検証・介入可能）
- 🧬 科学Foundation Model: 分子生成（MatterGen）・気象予測（Aurora）・タンパク質動態（BioEmu）等の専用大規模モデル
- 👩🔬 Human-in-the-Loop: 研究者が自然言語でエージェントに指示、結果を検証、方向修正を行う
2.5 比較表：同じ目標、異なるアプローチ
| 観点 | 文科省版 AI for Science | MS版 AI-driven Science |
|---|---|---|
| 共通目標 | 科学研究プロセスの加速 | 科学研究プロセスの加速 |
| Human-in-the-Loop | ✅ あり | ✅ あり |
| 核心の違い | 研究者がAIを道具として使う | AIエージェントが研究を駆動し研究者が監督 |
| AIの自律度 | 低〜中（個別タスクを支援） | 高（研究サイクル全体を自律駆動） |
| 研究サイクルの駆動者 | 人間 | AIエージェント群 |
| 人間の関与 | 全工程で主体的に判断 | 目標設定・検証・意思決定 |
| 技術レベル | 初心者〜上級者 | 上級者・専門チーム |
| 分野 | 全分野（人文含む） | 主に自然科学（化学・材料・創薬） |
| 規模 | 小規模・萌芽的 | 大規模・基盤的 |
| 代表例 | SPReAD-1000 | Microsoft Discovery, MatterGen, Aurora |
| SPReADとの親和性 | ⭐⭐⭐（高い） | ⭐（大規模すぎる） |
2.6 SPReAD-1000 応募者が取るべきスタンス
SPReAD-1000 は文科省版の「研究者がAIを道具として使う」哲学に基づいています。
両方とも Human-in-the-Loop ですが、AIの自律度が異なります。SPReAD では「私（研究者）がAIをこう使って、この科学的問いに挑む」という構図が求められます。Microsoft Discovery のように「AIエージェント群に研究サイクルを任せ、研究者は監督する」という設計は、JST管轄の ARiSE の方が適しています。
3. 研究設計の落とし穴 — GPU サーバー・LLM API の利用だけでは不十分な理由
3.1 よくある誤解
SPReAD-1000 の対象経費に「計算資源に係る経費」や「API利用料」が含まれているため、多くの研究者が以下のような計画を立てがちです。
よくある不十分な研究計画（パターンA: ハードウェア偏重型）
「500万円でGPUサーバー（NVIDIA A100 × 4）を購入し、大規模言語モデルをファインチューニングして〇〇分野のデータを分析する」
よくある不十分な研究計画（パターンB: LLM API依存型）
「OpenAI API（GPT-4等）に〇〇分野のデータを投入し、AIに分析・考察させて知見を得る」
どちらも不十分です。その理由は3つあります。
3.2 理由①: インフラもAPIも研究設計ではない
GPUサーバーは 計算インフラ、LLM APIは 汎用ツール であり、どちらも 研究設計 ではありません。計算機資源ベンダーが提供するテンプレート（「A100×4でLLMをファインチューニング」等）も、LLMベンダーのユースケース紹介（「GPT-4でデータを分析」等）も、科学的な問いに答えるための研究設計とは根本的に異なります。
研究設計に必要な要素（ベンダーテンプレートにないもの）
| # | 要素 | ベンダーテンプレートに含まれるか | なぜ必要か |
|---|---|---|---|
| 1 | 科学的な問い（仮説） | ❌ | 「何を明らかにしたいか」が研究の出発点 |
| 2 | 先行研究との差別化 | ❌ | 既にある研究との違いを示すため |
| 3 | 適切なベースライン比較 | ❌ | AI手法の有効性を客観的に評価するため |
| 4 | 評価指標の選定根拠 | ❌ | 成功/失敗の判断基準を事前に定めるため |
| 5 | データの品質管理戦略 | ❌ | 「ゴミを入れればゴミが出る」を防ぐため |
| 6 | 再現性の確保方針 | ❌ | 他の研究者が検証できるようにするため |
| 7 | 限界と将来展望の考察 | ❌ | 研究の位置づけと発展可能性を示すため |
3.2.1 Microsoft・パートナー企業の支援の限界を理解する
SPReAD-1000 では計算資源に Azure 等のクラウドを利用するケースが多いですが、Microsoft やそのパートナー企業が支援できる範囲には明確な限界がある ことを理解しておく必要があります。
| 支援できること | 支援できないこと |
|---|---|
| Azure 上の GPU サーバー・VM の構築 | 皆さんの研究に最適なシステム全体の設計 |
| ストレージ・ネットワーク等のインフラ設定 | 研究テーマに応じた AI パイプラインの設計 |
| Azure サービス（Azure ML 等）の利用方法の案内 | プログラミング開発支援・コード実装 |
| コスト最適化・リソースサイジングの助言 | 実験結果の解釈・科学的妥当性の判断 |
| 障害対応・技術的トラブルシューティング | 先行研究調査・新規性の検証 |
なぜ研究に最適なシステムを設計できないのか: Microsoft やパートナー企業はクラウドインフラの専門家ですが、皆さんの研究内容を理解することはできません。「古文書のくずし字をAIで解読したい」「タンパク質の結合親和性を予測したい」——こうした科学的な問いに対して、どのようなデータ前処理が必要で、どのモデルアーキテクチャが適切で、どの評価指標で検証すべきかは、その分野の研究者にしか判断できない ことです。Azure 上に VM を立てることと、その VM 上で走らせるべき研究パイプラインを設計することは、まったく別の専門性です。
つまり、インフラ構築と研究設計の間にギャップ があります。このギャップを埋めるのは研究者自身の仕事であり、SPReAD の応募書類で問われているのはまさにこの部分です。
3.3 理由②: AI for Science には統合的パイプラインが必要
真にインパクトのある AI for Science 研究には、以下のような 統合的パイプライン が必要です。
GPUサーバーは「計算実験」の 1ステップに過ぎない。研究全体のパイプラインの中で適切に位置づけることが重要です。
3.4 理由③: 審査基準を見据えた設計が必要
SPReAD-1000 の審査では以下が評価されます。
| 審査ポイント | GPU/APIだけの計画 | 統合的計画 |
|---|---|---|
| 独創性・新規性 | △ ありきたり | ◎ AIならではの着眼 |
| 研究計画の具体性 | △ 計算だけ詳細 | ◎ 全工程が明確 |
| AI導入の必要性 | △ 「速くなる」のみ | ◎ AI無しでは不可能 |
| 波及効果 | △ 単一分野 | ◎ 方法論の汎用性 |
| 予算の妥当性 | ✕ GPU/API偏重 | ◎ バランスのよい配分 |
3.5 第1回公募で実際に起きた問題
第1回公募の応募者からは、以下のような課題が報告されています [10]。
【システム構成の壁】
- 計算資源ベンダーの説明会を聞いたが、内容がよく分からなかった
- 自分の研究を実施するためのシステム構成を、自分で設計できなかった
- ベンダーが提示したシステム構成で、自分の実験ができるのかの判断ができなかった
- 計算資源ベンダーは「計算環境の専門家」であり、自分の研究分野を理解して適切なシステム設計をしてくれるわけではなかった
【AI活用設計の壁】
- 自分の研究の中で、AI をどこでどのように使えばよいのかを設計できなかった
- Copilot や ChatGPT に聞けば何かしら答えてくれるが、その回答が自分の研究に対して正しいかどうかを判断できなかった
つまり、「プログラミングの壁」だけでなく、「研究とシステムの間をつなぐ翻訳者がいない」 ことが第1回の隠れたボトルネックでした。GPU サーバーや LLM API を買っても、それを自分の研究に適切に組み込む設計ができなければ意味がありません。
3.6 研究テーマの4タイプ — あなたはどれ？
1,000件の仮想テーマ分析と100件の実験検証の結果、AI を使う上での「プログラミングの必要度」は4タイプに分かれることが分かっています [10]。
| タイプ | 一言で | 割合 | プログラミング | AI for Science エージェント活用時の完走率 |
|---|---|---|---|---|
| A | 既製品をそのまま使う | 22% | 不要 | 100%⚠️ |
| B | 既製品のパラメータを変える程度 | 26% | ほぼ不要 | 86% |
| C | 組み合わせてカスタマイズする | 38% | テーマによる | 68% |
| D | 新しいアルゴリズムを自分で作る | 14% | 必須 | 0%（コード生成は可能だが実験遂行は不可） |
タイプAでも、最初にクラウド環境（Azure等）に接続するとき一度だけセットアップ作業が必要です。
分野別のAI相性:
| 分野 | AI for Science エージェントで完走できる割合 | 傾向 |
|---|---|---|
| 農学・環境 | 84.6% | 観測データ+標準的な予測が多く好相性 |
| 理学 | 78.6% | 物理制約系（タイプD）以外は良好 |
| 人文学 | 76.9% | 画面操作（タイプA）が多く完走しやすい |
| 社会科学 | 69.2% | 因果推論テーマが壁 |
| 工学 | 64.3% | デジタルツイン系が難しい |
| 医学・薬学 | 64.3% | 複数データ統合+匿名化が壁 |
| 生命科学 | 64.3% | マルチオミクス統合が壁 |
人文学・社会科学の方: 「AI とは無縁の分野」と思われがちですが、実は 最も AI エージェントとの相性が良い 分野です。テキスト分析や分類は AI の得意分野そのものです。
3.7 「判断」と「実装」の分離が鍵
第1回の経験と100件実験から見えた最も重要な教訓は、「判断」と「実装」を分離する ことです。
| 役割 | 担当 | 具体例 |
|---|---|---|
| 判断（研究者） | 「何を」「なぜ」「どの条件で」を決める | データの選定、仮説の設定、結果の解釈 |
| 実装（AIエージェント） | 「どうやって」を実行する | コード生成、データ前処理、図表作成 |
応募書類への示唆: 「プログラミングができない」ことは応募の障壁ではありません。しかし「自分の研究でAIをどう使うか」の判断は研究者にしかできません。応募書類では、AIに何を判断させ、何を自分で判断するか を明確にしましょう。
4. 申請書の書き方 — 構造・プロセス・審査観点
SPReAD-1000 の申請書（様式1: 研究計画調書）を作成するプロセスを解説します。以下は、研究構想の整理から提出までの一般的な流れです。
本セクションでは、処理の流れの参考として筆者開発の OSS spread1000-builder [11] のパイプライン構成を引用しています。spread1000-builder は GitHub Copilot / Claude Code のスキルスイートであり、文部科学省の公式ツールではありません。利用は任意です。
4.1 全体パイプライン
研究の構想から申請書提出まで、以下の段階を踏みます。
4.2 Phase Pre: 研究構想を6要素で整理する
応募の第一歩は、漠然とした研究構想を 6つの要素 に分解して整理することです。
| 要素 | 意味 | 記載例 |
|---|---|---|
| PURPOSE | 何を達成したいか | 「崩し字の自動翻刻で翻刻速度を10倍にする」 |
| TARGET | 研究対象・分野 | 「近世日本の古文書（17〜19世紀）」 |
| SCOPE | 研究の範囲 | 「国立国会図書館所蔵の1,000点を対象」 |
| TIMELINE | 研究期間 | 「約180日間（交付決定〜2027年1月）」 |
| CONSTRAINTS | 制約条件 | 「予算500万円、プログラミング未経験、GPU環境なし」 |
| DELIVERABLES | 期待する成果物 | 「翻刻AIモデル、評価論文、コード公開」 |
この6要素が明確になっていない段階で「とりあえず ChatGPT に聞く」と、汎用的で的外れな回答しか得られません。まず自分の構想を言語化する ことが最も重要です。
4.3 Phase 0: 研究プラン策定 — AI活用方法を設計する
研究構想が整理できたら、具体的な AI 活用方法 を設計します。
このフェーズで決めること:
- 先行研究の調査 — 自分の分野で AI がどう使われているかを調べる
- AI 適用箇所の特定 — 研究プロセスのどの工程に AI を使うかを決める
- 使用する AI 技術の選定 — LLM、画像認識、最適化、シミュレーション等
- データの特定 — 何のデータを、どこから、どう取得するか
- 評価方法の設計 — AI の成果をどう評価するか、ベースラインは何か
ポイント: 「AI で〇〇を分析する」ではなく、「研究プロセスのこの工程で、この AI 技術を使って、このデータを処理し、この評価指標で従来手法と比較する」レベルまで具体化します。
4.4 Phase 1-2: システム構成とコスト設計
研究プランが固まったら、必要な計算基盤と費用を設計します。
| フェーズ | 決めること | 注意点 |
|---|---|---|
| Phase 1 | 必要なクラウドリソース（GPU種別、ストレージ、ネットワーク） | ベンダーのテンプレートをそのまま使わない。研究プランから逆算する |
| Phase 1b | システム構成図（申請書の図セクション用） | 申請書には最大1枚の図を添付可能 |
| Phase 2 | コスト見積もり（積算根拠付き） | API の実価格に基づく積算が必要。LLM の推定値は不可 |
4.5 Phase 3: 申請書の構造 — 何をどう書くか
SPReAD の申請書（様式1: 研究計画調書）は以下の構造です。各セクションに文字数制限があります。
| セクション | 内容 | 文字数 |
|---|---|---|
| I. 研究目的 | 何のためにどのような研究を行うか | 80〜400字 |
| II. 研究方法 | 工程ごとのAI適用、データ、評価指標 | 160〜800字 |
| III. AI利活用の妥当性・実現可能性 | 従来手法の限界とAI導入の意義 | 160〜800字 |
| IV. 達成目標 | 中間（3ヶ月）・最終（6ヶ月）のマイルストーン | 100〜500字 |
| V. ノウハウ抽出・共有計画 | AI活用知見の他分野への共有方法 | 60〜300字 |
| 参考）図 | 研究プロセスやAI適用箇所の図 | 最大1枚 |
| VI. 研究業績 | 関連する主要業績 | 最大5件 |
文字数制限は厳格です。上限の90%以上を使用するのが理想です。下限ギリギリは「内容が薄い」と判断されるリスクがあります。
4.6 Phase 3c: 6審査観点で自己採点する
提出前に、以下の 6つの審査観点 で自分の申請書を自己採点しましょう。
| # | 審査観点 | チェックポイント |
|---|---|---|
| 1 | AI利活用の妥当性・実現可能性 | 従来手法の限界が明確で、AI導入の必然性が説得力をもって記述されているか |
| 2 | 研究実績 | 申請テーマに関連する業績が示されているか（AI経験は必須ではない） |
| 3 | 実施計画・資金活用の妥当性 | 6ヶ月の計画が具体的で、予算配分が適切か |
| 4 | 研究課題の優位性・新規性 | 先行研究と明確に差別化されているか |
| 5 | ノウハウ抽出・共有の実現性 | 得られた知見を他分野にも展開できる計画があるか |
| 6 | 成果の波及可能性 | 研究成果が他の研究者・分野に影響を与える可能性があるか |
自己採点基準:
- ◎（3点）: 具体的かつ説得力のある記述
- ○（2点）: 概ね十分だが一部に具体性が不足
- △（1点）: 記載はあるが抽象的
- ×（0点）: 記載なしまたは大幅に不足
目標: 15点以上（18点満点） で提出推奨レベルです。10点未満の場合は根本的な見直しが必要です。
4.7 実験計画書で「書くべきコード量」を事前に把握する
多くの研究者が「プログラミングがどれだけ必要か分からない」ことを不安に感じています。spread1000-builder の experiment-guide（実験手順書生成）スキルは、研究プランから 具体的な実験手順書 を自動生成し、実際にどの程度のコードを書く必要があるかを明らかにします。
実験手順書が明らかにする「必要なコード」の内訳:
| 作業 | コード種別 | 具体例 | プログラミング難度 |
|---|---|---|---|
| 環境セットアップ | CLI コマンド | az ml workspace show ... |
⭐（コピペ） |
| データアップロード | CLI コマンド | az storage blob upload-batch ... |
⭐（コピペ） |
| 学習ジョブ定義 | YAML 設定ファイル |
job.yml（パラメータ指定のみ） |
⭐⭐（編集） |
| 前処理スクリプト | Python | データクリーニング・分割 | ⭐⭐⭐（要実装） |
| 学習スクリプト | Python |
train.py（モデル定義・学習ループ） |
⭐⭐⭐〜⭐⭐⭐⭐ |
| 推論・評価 | Python | 評価指標の計算・可視化 | ⭐⭐⭐ |
| インフラ構築 | Bicep / YAML | Azure リソース定義（自動生成） | ⭐（自動） |
重要な発見: 実験手順書を作ってみると、研究に必要な「コード」の大半は CLI コマンドと YAML 設定ファイル であり、実際にゼロから書く必要があるのは前処理・学習・評価の Python スクリプト3〜5本 程度であることが分かります。しかもそれらも AI エージェントの支援で生成可能です。
セクション 3.6 の研究テーマ4タイプとの対応:
| タイプ | 書くべきコード | 実験手順書の活用法 |
|---|---|---|
| A（GUI完結型） | ほぼゼロ | 手順書で API 呼び出しの手順だけ確認 |
| B（パラメータ変更型） | YAML 設定変更のみ | 手順書の job.yml テンプレートをそのまま利用 |
| C（カスタマイズ型） | Python 3〜5本 | 手順書のテンプレートを修正して利用 |
| D（新規アルゴリズム型） | 本格的な実装が必要 | 手順書で全体構成を把握し、実装に集中 |
つまり、応募前に実験計画書を作成することで、自分の研究テーマがどのタイプに該当し、どれだけのプログラミングが必要かを具体的に見積もれる のです。
4.8 spread1000-builder による自動化
上記のプロセスを AI エージェントで自動化するのが spread1000-builder [11] です。12のサブスキルと2つの専門エージェントが、研究構想から申請書完成までを一貫して支援します。
# インストール（GitHub Copilot / Claude Code 環境に配備）
npm install @nahisaho/spread1000-builder
| フェーズ | サブスキル | 自動化される作業 |
|---|---|---|
| Pre | context-collector |
1問1答で6要素を収集、メタプロンプト生成 |
| Phase 0 | research-planner |
Web調査、文献検索、AI活用研究プラン策定 |
| Phase 1 | azure-architect |
Azure アーキテクチャ設計 |
| Phase 1b | diagram-generator |
draw.io MCP によるシステム構成図生成 |
| Phase 2 | cost-estimator |
Azure 実価格APIに基づくコスト算出 |
| Phase 3 | proposal-writer |
公募要領準拠の申請書生成 |
| Phase 3c | final-reviewer |
6審査観点スコアリング・提出可否判定 |
| Phase 4 | submission-guide |
AIインタビュー準備・e-Rad手続きガイド |
| Phase 5c | experiment-guide |
実験手順書生成（必要コード量の可視化） |
spread1000-builder が生成する成果物はすべて 参考資料 です。公的機関への提出前に、応募者ご自身の責任 で内容を精査・修正してください。
5. 分野別の応募例 — こんな研究計画を書こう
以下は、SPReAD-1000 に適した研究計画の 具体例 です。自分の分野に近い例を参考に、独自のアイデアを膨らませてください。
予算配分はあくまで例示です。実際には公募要領・所属機関の経理ルール・見積根拠に基づいて調整してください。
5.1 例①: 人文学・社会科学分野
テーマ: 「LLMを活用した近世日本古文書の自動翻刻・内容分類システムの開発」
| 項目 | 内容 |
|---|---|
| 科学的な問い | LLMは崩し字の翻刻において専門家と同等の精度を達成できるか |
| AI活用の必要性 | 未翻刻の古文書は膨大（推定数百万点）。人手では数十年かかる |
| 新規性 | 既存OCRは印刷物向け。崩し字に特化したLLM活用は未開拓 |
| ベースライン | 既存OCR（Tesseract）+ 専門家による翻刻との精度比較 |
| データ | 国立国会図書館デジタルコレクション、大学所蔵古文書画像 |
| 予算 | API利用料150万、データ整備120万、謝金（専門家評価）100万、クラウドGPU80万、成果発表50万 |
5.2 例②: 生命科学分野
テーマ: 「AI駆動型ドラッグリポジショニング：既存薬のCOVID-19後遺症治療薬としての転用可能性予測」
| 項目 | 内容 |
|---|---|
| 科学的な問い | 既存の承認済み薬の中にCOVID-19後遺症の症状緩和に有効なものはあるか |
| AI活用の必要性 | 承認済み薬×後遺症症状の組合せは膨大。網羅的探索にAIが不可欠 |
| 新規性 | 分子構造＋臨床報告テキストの マルチモーダル学習 による予測 |
| ベースライン | 分子構造のみの既存手法（DeepPurpose等）との比較 |
| データ | ChEMBL、DrugBank、PubMed臨床報告 |
| 予算 | クラウドGPU200万、データベースAPI100万、データ整備80万、学生謝金80万、成果発表40万 |
5.3 例③: 工学分野
テーマ: 「生成AIによる建築構造設計の最適化：耐震性と省エネ性の同時満足解探索」
| 項目 | 内容 |
|---|---|
| 科学的な問い | 生成AIは従来の構造最適化では到達できない設計解を発見できるか |
| AI活用の必要性 | 耐震性と省エネ性のトレードオフ空間は非線形・高次元で人手探索が困難 |
| 新規性 | 生成AIによる設計候補の「発想」+ 物理シミュレーションによる検証の統合 |
| ベースライン | 遺伝的アルゴリズム（GA）による従来型多目的最適化との比較 |
| データ | 建築設計データベース、構造解析シミュレーション結果 |
| 予算 | クラウドGPU180万、シミュレーションソフト利用料80万、API利用80万、データ整備80万、成果発表80万 |
共通する良い計画のポイント:
- 科学的な問いが明確（Yes/No で答えられる）
- AI がなぜ必要かの理由がある（人手では困難な理由）
- ベースラインとの比較が計画されている
- 予算がGPU以外にも分散している
6. 100件の自動研究実験からの教訓 — AI Co-Scientist が示す研究設計の要点
6.1 実験の概要
筆者が開発する AIRA（AI Research Administrator）の Co-Scientist 機能を用いて、100件の科学研究テーマを全自動で実行 しました [8] [13]。各テーマについて「先行研究調査→実験設計→実装→図表生成→論文執筆」を Agentic AI が自律的に実行し、その過程と結果を分析しました。
| 指標 | 値 |
|---|---|
| 実験数 | 100件（生命科学・材料科学・社会科学等を網羅） |
| ワークフロー生成完了率 | 100%（初回91%、リトライ後100%） |
| 平均所要時間 | 12.5分/件（5並列で実経過約4時間39分） |
| 平均生成ファイル数 | 15.6 |
| paper.md 平均文字数 | 25,083 |
| DOI形式の参考文献 | 平均16.3件（97%の論文に存在） |
重要な前提: 生成された文書はすべて AIによるモックデータ を含みます。科学的成果として扱うことはできません。目的は「AIが科学的発見をしたか」ではなく、「研究ワークフローのどの部分をどこまで自動化できるか」 を観察することです。
6.2 最大の発見 — 100本すべてが「組み合わせ的新規性」を持っていた
100本の論文を「新規性マーカー」で分析した結果、驚くべきパターンが浮かび上がりました。
| 新規性タイプ | 件数 |
|---|---|
| 統合パイプライン（複数技術の統合） | 100 (100%) |
| 手法融合（CNN+Attention等） | 99 (99%) |
| ベンチマーク比較 | 50 (50%) |
| 解釈可能性の付与 | 37 (37%) |
100本中100本が「既存手法Aと既存手法Bを、ドメインCに適用する」 というアプローチを取っていました。一見「限界」に見えますが、冷静に考えると 科学研究の多くは「既存手法の新しい組み合わせ」で成り立っています（例: PCR法 = DNAポリメラーゼ + 温度サイクル + プライマー設計）。
組み合わせ的新規性（Combinatorial Novelty）: 既存の手法・技術・概念を新しいパターンで組み合わせることで、個々の要素にはない新しい価値を生み出すこと。AIはこの高速生成に長けている。
ただし、新規性にはレベルがあります:
| レベル | 内容 | 今回確認できたか |
|---|---|---|
| 形式的新規性 | 既存手法を新しい形で組み合わせている | ✅ 100本すべてで確認 |
| 文献上の新規性 | 実際に未報告の組み合わせである | ❓ 未検証 |
| 科学的妥当性 | ドメイン知識上、意味のある組み合わせである | ❓ 未検証（専門家評価が必要） |
| 実証的有効性 | 実データで性能が出る | ❌ 未検証（モックデータのみ） |
SPReAD応募への示唆: AIは「形式的新規性」を大量に高速生成できます。これを「文献上の新規性」「科学的妥当性」に引き上げるのが 研究者の仕事 であり、まさにSPReADが求める「人間の判断 × AIの探索」の分業です。
6.3 「問い」を立てたのは100本すべて人間だった
もう一つの重要な発見があります。
| 役割 | 誰がやったか |
|---|---|
| 研究テーマの設定（What to solve） | 🧑🔬 人間（100/100） |
| 研究意義の判断（Why it matters） | 🧑🔬 人間 |
| プロンプト設計の改善方針 | 🧑🔬 人間 |
| 文献調査の実行 | 🤖 AI |
| 実験コードの実装 | 🤖 AI |
| 論文形式の文書作成 | 🤖 AI |
AIは「どう解くか（How）」には極めて有能だが、「何を解くか（What）」は決めていません。
SPReAD応募への示唆: 応募書類で最も重要なのは 研究者自身が設定する「問い」の質 です。「AIで〇〇を分析する」ではなく、「〇〇という科学的問いに対し、AIを使ってこう迫る」という構成にしましょう。
6.4 プロンプト設計で出力品質が劇的に変わる
4回のイテレーション（v1.0〜v4.0）で、プロンプト設計の影響を観察しました。
| バージョン | 主な変更 | 観察された変化 |
|---|---|---|
| v1.0 → v2.0 | report.md/paper.md 生成指示を追加 | 完了率 95%→100%、出力長 +20.8% |
| v2.0 → v3.0 | 論文構成の詳細指定を追加 | 出力長 +24.9% |
| v3.0 → v4.0 | 先行研究調査ステップを前段に追加 | DOI引用 0→16.3件、所要時間 -14.7% |
特に v3.0→v4.0 の変化は印象的でした。「先行研究を調べてから実験を設計せよ」という指示を追加しただけで、DOI形式の参考文献が 0件→平均16.3件に増加し、しかも所要時間は14.7%短縮されました。
SPReAD応募への示唆: プロンプトは「指示」ではなく「実験の設計書」です。 AIにどう指示するかの設計こそが、SPReADの「AI利活用の妥当性」セクションで書くべき内容です。
6.5 品質の内訳 — 35%が研究のたたき台として有望
100本を著者が分類した主観的な評価:
| 品質カテゴリ | 件数 | 説明 |
|---|---|---|
| 🟢 研究たたき台として有望 | 約35件 | 手法の組み合わせが面白く、実データで検証する価値がある |
| 🟡 着想は面白いが検証困難 | 約40件 | データ入手や計算コストの面で実行が難しい |
| 🔴 既存研究の焼き直しに近い | 約25件 | 明らかに既知の手法の再記述 |
100本を約5時間で生成し、そのうち 35本が研究の起点になり得る とすれば、アイデア探索の効率としては高いと言えます。
6.6 実験の限界 — 正直に書く
| 限界 | 影響 |
|---|---|
| モックデータのみ | 全データ・図表・数値はAI生成。実験室での実測データは未使用 |
| コード未実行 | 生成されたPythonコードが正常に動作するかは未検証 |
| 引用未検証 | DOI形式の文献が実在するか、引用内容が正確かは未確認 |
| コントロール群なし | 人間が同じテーマで書いた論文との比較がない |
結論: AI for Science は「革命」ではなく 「共進化」 です。AIは研究者を置き換えるのではなく、研究者の「問い」を受けてその解法空間を高速に探索します。研究者は、AIが生成した組み合わせの中から科学的に意味のあるものを見極め、実データで検証する——この 「問い→探索→選別」のサイクル こそが、AI for Science の本当の姿です。
7. 応募前の最終チェックリスト
7.1 研究計画の必須要素
- 科学的な問い: AIを使って何を明らかにしたいか
- 先行研究: 関連する最新の研究を調査したか
- 新規性: 先行研究との差別化ポイントは明確か
- AI活用の必要性: AIなしでは困難な理由は説明できるか
- ベースライン: 比較対象の手法は設定したか
- 評価指標: 成功/失敗をどう判定するか
- データ戦略: どのデータを、どう取得・整備するか
- 再現性: コード・データの公開方針はあるか
- タイムライン: 6ヶ月で何をどこまでやるか
- 予算の妥当性: GPU/API偏重になっていないか
- 倫理・データガバナンス: 個人情報、生命倫理、機密データの取扱方針は明確か
7.2 ❌ 避けるべき計画パターン
| パターン | 問題点 | 改善案 |
|---|---|---|
| GPU購入型 | ハードが目的化 | クラウドGPU + データ整備に分散 |
| LLM API丸投げ型 | 科学的手法が不在 | APIは道具の一つ、仮説・評価設計が主体 |
| LLMファインチューニングのみ | 汎用手法の適用 | 分野固有の科学的問いを設定 |
| 計算資源の量で勝負 | 独創性の欠如 | 小規模でも新しい着眼点 |
| 成果物が「精度XX%」のみ | 科学的貢献が不明 | 発見・知見・方法論の提示 |
| AI の説明が曖昧 | 「AI で分析する」だけ | 具体的な手法・モデル・データを記載 |
7.3 ✅ 推奨する計画の流れ
7.4 伴走支援の活用方法
採択後に提供される 伴走支援 を最大限に活用しましょう。
| 支援内容 | こんな時に活用 |
|---|---|
| 計算資源アドバイス | クラウドGPUの選定、コスト最適化の相談 |
| データ整備支援 | データの前処理方法、品質管理の助言 |
| AI技術相談 | モデル選択、学習戦略、評価方法の相談 |
| ネットワーキング | 他の採択者との交流、分野間連携の機会 |
AI初心者こそ伴走支援を活用: 「GPU を契約したが使い方がわからない」「LLM の出力をどう評価すればよいか」等の悩みは伴走支援で解決できます。一人で抱え込まず、積極的に相談しましょう。
8. まとめ
| ポイント | 要点 |
|---|---|
| SPReAD-1000 | 500万円×1,000件、全分野対象、萌芽的研究を支援。AI初心者もOK |
| AI for Science | 文科省版は「裾野拡大」、MS版は「自律発見」。SPReADは前者 |
| 研究設計 | GPUサーバー購入やLLM API利用≠研究設計。統合的パイプラインを設計せよ |
| 100件の教訓 | 先行研究・ベースライン・再現性が品質の鍵 |
| 応募例 | 科学的な問い + AI の必然性 + ベースライン比較 = 良い計画 |
| 申請書作成 | 6要素整理→研究プラン→コスト設計→申請書→6審査観点で自己採点 |
| 第2回公募 | 2026年6月上旬開始予定。今から準備を |
SPReAD-1000 は、日本の研究者が AI for Science に踏み出す 有力な機会 です。GPU サーバーを買うことでも LLM API を使うことでもなく、あなたの研究分野における「AIならではの科学的問い」を設計することが、採択への近道です。
AI の経験がなくても、あなたの分野の知識がある。それこそが AI for Science の出発点です。
参考文献
[1] 文部科学省 SPReAD-1000 公式サイト — 文部科学省, 2026年4月
[2] AI for Science萌芽的挑戦研究創出事業(SPReAD)公募要領 — 文部科学省, 2026年4月
[3] AI for Science の推進に向けた基本的な戦略方針 — 内閣府CSTI, 2026年2月
[4] Microsoft Research AI for Science — Microsoft Research
[5] From AI for Science to Agentic Science: A Survey on Autonomous Scientific Discovery — arXiv, 2025
[6] SPReAD公募開始、文部科学省がAI for Scienceに500万円×1,000件を投入 — Innovatopia, 2026年4月
[8] AIRA Co-Scientist Round 9 評価レポート — co-scientist-optimization/round-9/evaluation-report.md, 2026年5月25日（未公開内部データ）
[9] Microsoft just launched an AI that discovered a new chemical in 200 hours instead of years — VentureBeat, 2025年5月
[10] SPReAD-1000 第2回に応募したいけど、プログラミングできません — 1,000テーマ×100実験で分かった「本当のハードル」 — Qiita @hisaho, 2026年
[11] spread1000-builder — SPReAD 研究計画策定から Azure デプロイまでの統合スキルスイート — GitHub @nahisaho, 2026年
[12] AI for Science 革新的研究推進事業（ARiSE）公募情報 — JST, 2026年5月
[13] AIに科学研究を100本やらせてみた — 100本の自動実験で見えた「AIの本当の強み」と「研究者にしかできないこと」 — Qiita @hisaho, 2026年5月
著者注: 本記事のリサーチおよび構成は、AIRA（AI Research Administrator）の SHIKIGAMI Deep Research ワークフローを用いて実施しました。Co-Scientist の実験データは、広島大学での AI for Science 説明会向けに整理したものです。