「動いた」のに、研究になっていない――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で本当に守るべきものは、「速く書けること」ではなく、間違った仮説を、できるだけ早く棄却できることなのだと思います。