「動いた」のに、研究になっていない――R1〜R47で突きつけられたこと
深夜、生成された論文ドラフトは完璧に見えました。先行研究を踏まえ、Jupyter のセルは最後まで通り、図も結論も整っている。
それなのに、一文ずつ追っていくと足元が崩れていきます。その主張は、どのセルの、どの計算で支えられているのか ――答えられない。
47回の実験を重ねて、私たちが繰り返しぶつかったのはこの感触でした。
そして最後に残った観察は、当初の期待とは逆向きのものです。AI for Science で本当に重要だったのは、どれだけ賢いモデルを選ぶかより、間違いを早く見つけて直せる研究フローを設計できるかでした。
この記事は、その結論にたどり着くまでの失敗と転換点の記録です。先に要点だけ言うと、次の3つはどれも単体では足りませんでした。
- 科学者の能力をSkill化する
- 先行研究を大量に読み込ませる
- 計算（Jupyter実行）を自動化する
3つとも「効きそう」に見えて、単独では品質を安定させられない。検証と反証のループに接続して初めて、数値が落ち着きはじめました。なぜそう言えるのか、旅の順に追っていきます。
第1の壁：「できる」が増えるほど、「信頼できる」から遠ざかった
フェーズA（R1〜R25）: できることは増えた。それで安心したのが間違いだった
最初の25ラウンドは、ほとんど高揚感の時期でした。先行研究調査、コード生成、論文ドラフト生成まで、ひととおり自動化できてしまう。手は確実に速くなる。
ところが出力を真剣にレビューすると、もっともらしさと信頼性がまるで別物だと気づかされます。読みやすい文章ほど、検証を素通りさせてしまう。ここで得た教訓が、その後ずっと効いてきました。
初期ラウンドで得た最大の教訓は、
「生成できる」=「研究として成立する」ではない こと。
「ならばパイプラインを工夫すればいい」――次のフェーズは、その素直な仮説から始まりました。そして、その仮説は半分外れます。
フェーズB（R26〜R40）: 「工程を分ければ良くなる」という思い込みが砕けた
工程を細かく分割すれば品質は上がるはず。そう信じて多段化を進めましたが、結果はむしろ逆方向に振れました。docs/prompt-engineering-guidebook.md の定量結果が、その失敗を冷たく記録しています。
| 方式 | VM avg | FO avg | UC avg | Balance |
|---|---|---|---|---|
| 1-shot（R26） | 19.4 | 4.0 | 0.1 | 1.55 |
| 4-step初期（R38） | 53.7 | 3.2 | 2.7 | 5.16 |
| 4-step修正版（R39） | 8.1 | 2.4 | 2.2 | 2.96 |
| 5-step+検証（R40） | 13.2 | 3.8 | 0.0 | 1.21 |
R26の1-shotからR38で4段化したとき、Balanceは1.55から5.16へ悪化しました。分割しただけでは改善しない――それどころか壊れることがある。観測できた範囲では、これが転換点でした。
効いたのは段数ではなく、R39で修正を入れ、R40で検証を組み込んだ「Generate → Validate → Fix」のループの方です。Balanceは5.16 → 2.96 → 1.21と下がっていきました。分けることではなく、生成物を疑い、直す経路を閉じることに意味があった、と読めます。
フェーズC（R41〜R44）: 同じ工程を入れても、置く場所で結果が裏返った
検証を入れれば安泰、とはいきませんでした。同じステップでも、置く順序で品質が反転したのです。docs/r44-paper-quality-report.md の記録を見てください。
| Round | 最終品質ステップ | Balance |
|---|---|---|
| R40 | Step 5: 引用監査 | 1.21 |
| R41 | Step 6: 敵対的検証（順序不整合） | 3.86 |
| R42 | Step 6: 引用監査を末尾に復帰 | 1.88 |
| R44 | Step 6: UC+FO統合監査 | 0.67 |
R40で1.21まで来ていたのに、R41で敵対的検証を順序不整合な位置に差し込んだ瞬間、3.86へ跳ね上がりました。よかれと思った工程が、置き場所を誤ると害になる。R42で引用監査を末尾に戻し、R44でUC+FO統合監査を末尾に据えると、0.67まで下がりました。
この区間で見えたのは、何をやるかより、どの順序でやるかという、地味だが効く論点でした。
フェーズD（R45〜R47）: 最後の希望「外部モデル統合」も、強制した瞬間に壊れた
それでも私たちは、もう一枚の切り札に期待していました。NatureLM/GALACTICAのような外部モデルをMCPで統合すれば、一段上に行けるはずだ、と。同一30実験での比較がこちらです（round*.md と results/round*/... 集計）。
| Round | NatureLM/GALACTICA利用 | VM avg | UC avg | FO avg |
|---|---|---|---|---|
| R44 | 0/30 | 4.0 | 0.0 | 2.5 |
| R45 | 0/30 | 23.3 | 0.3 | 2.4 |
| R46 | 0/30 | 7.1 | 0.4 | 5.6 |
| R47 | 30/30 | 4.7 | 0.13 | 2.77 |
ここでも一筋縄ではいきません。利用ゼロのR45ではVM avgが23.3まで荒れ、R47で30/30すべてに利用を強制してようやくVM avg 4.7・UC avg 0.13に落ち着きました。ただし、この限られた比較から読み取れるのは控えめな示唆です。
MCP導入そのものは魔法ではない。強制の仕方を誤れば荒れ、統合の置き方を設計したときに初めて噛み合う――少なくとも観測範囲では、そう振る舞いました。
失敗の正体を解剖する：3つの「単体では足りない」
旅の終盤、私たちはようやく失敗を分類できるようになりました。期待した3つの打ち手が、なぜ単独では崩れるのか。
なぜ「Skill化だけ」では足りなかったのか
R34〜R37で表面化したのは、skill invoke = 0 という問題でした（ガイドブック時系列）。能力を丁寧に定義しても、ワークフローから呼ばれなければ、存在しないのと変わらない。
Skill化は必要です。ただ要点はSkillの有無ではなく、その周りの設計にありました。
- どのステップで呼ぶか
- 呼ばれた結果をどこに反映するか
- 反映後に何で検証するか
なぜ「先行研究を読ませるだけ」では足りなかったのか
先行研究を読ませると、文章は確かに自然になります。けれど自然さは、科学的妥当性の証拠にはなりません。むしろ滑らかさが、検証の手を緩めさせる。
私たちが「計算したふり」と呼んだのは、次のような状態でした。
- 主張と計算セルが一意に追えない
- 反証条件が書かれていない
- 再実行しても判定規則が曖昧
レビューとして上手い文章と、研究として反証可能な主張は、重なっているようで別物でした。
なぜ「計算できるだけ」でも足りなかったのか
Jupyter MCPで最後までセルが回るようになると、人は一気に安心します。けれど、その安心の裏で循環設計が忍び込みました。
- 仮説に都合のよい特徴量
- その特徴量に都合のよい指標
- その指標に都合のよい分割
構造としては、機械学習でいうリーク/過適合に近い。「動いた」は「正しい」の証拠にならない――この一線を踏み越えないことが、最も重要でした。
蒸留された原則：守るべきは生成能力ではなく、反証可能性
R1〜R47を振り返って、私たちが暫定的に置いている結論はこれです。
AI for Science の本質は、おそらく生成能力ではなく、反証可能性を維持するプロセス設計にある。
観測の範囲では、次の4層がつながったときに出力が安定しました。
- 生成（仮説・実装案を出す）
- 実行（再計算可能にする）
- 敵対的検証（外部モデルで崩しにいく）
- 機械的監査（VM/UC/FOを末尾で修正）
この4層が一本につながると、出力は「それっぽい論文」から
「壊れにくい研究記録」 に近づいていきます。
明日から使えるチェックリスト：AI for Scienceを始める研究者へ
長い遠回りの末に残ったのは、難しい理論ではなく、1枚のテンプレートでした。新しい仮説に取りかかるとき、まずこれを埋めてから生成を回すことをおすすめします。
仮説:
この仮説が破綻する条件:
主要評価指標（事前固定）:
分割戦略（事前固定）:
前処理/特徴量の変更ログ:
外部モデル（NatureLM/GALACTICA等）からの反論:
反論に対する追加実験:
最終判断（採択/保留/棄却）:
そして、3つの「単体では足りない」を忘れないでください。
- Skill化だけでは足りない
- 先行研究読み込みだけでも足りない
- 計算自動化だけでも足りない
必要なのは、生成→実行→敵対的検証→機械的監査を一体化した設計です。
冒頭の深夜に戻ります。完璧に見えたあのドラフトに足りなかったのは、賢さではなく、自分を疑う経路でした。
AI for Scienceで本当に守るべきものは、「速く書けること」ではなく、間違った仮説を、できるだけ早く棄却できることなのだと思います。