同じ CRISPR off-target 予測テーマで、AI Research Assistant に実験レポートを書かせました。
- Jupyter なし: AUROC = 0.9499 ± 0.0054
- Jupyter あり: AUROC = 0.8316
この差は性能の劣化ではありません。Jupyter なしの AI（AIRA-α / AIRA-β）は「CNN + Attention ならこのくらい出るだろう」と推論して数値を書いていました——つまりフィクションです。Jupyter ありの AIRA-γ では、実際に scikit-learn でモデルを構築・評価した実行結果を報告しています。
この SCI-001 のような大幅な低下は全体傾向ではありません。全100テーマでは平均性能値に大きな変化はなく、Jupyter 導入の本質は「性能値を下げること」ではなく、数値の出自を実行ログに接続することでした。
AIRA-α は AI 単体の推論、AIRA-β は NatureLM・GALACTICA から得た情報を元にした AI の推論——いずれも数値の根拠は「AIの推論」であり、フィクションでした。AIRA-γ で初めて「実際に計算する」AI Research Assistantになりました。ここでいう「ノンフィクション」とは実世界の真実を意味するのではなく、「AIが推論で想像した数値」ではなく「実行されたコードから得られた数値」 である、という限定的な意味です。その変化の観察記録です。
TL;DR
AIRA (AI Research Assistant) は α → β → γ と進化してきましたが、α は AI 単体の推論、β は NatureLM・GALACTICA の情報を元にした推論——いずれも数値の根拠はAIの推論（=フィクション）でした。AIRA-γ で Jupyter MCP を接続し、初めて「Pythonコードを書いて実際に実行する」能力を付与しました。
当初の仮説は「コード実行により過大な性能値が抑制される」でした。暫定11実験ではその傾向が見えましたが、全100実験に拡張すると平均性能値に差はありませんでした。しかし、より重要な発見がありました。Jupyter導入の効果は「数値の大小」ではなく**「数値の出自」に現れます。全実験にコードブロックが出現（平均47行）、p値言及が +73% 増加、レポート行数が +16% 増加。AIが数値を「推論で書く」から「実行結果を引用する」方向へ変化しました。AI生成レポートの監査可能性**が向上した——これが本実験の主成果です。
本記事の前提
重要: 本実験で生成されたデータ・数値結果はすべてAIによるシミュレーション／モックデータです。実験室での実測データは使用していません。本記事の主眼は、コード実行環境の有無がAIの研究レポート記述にどのような変化をもたらすか の観察です。
この記事がAI for Science研究者に関係する理由
本記事は特定分野の実験結果の妥当性ではなく、AI Research Assistantに「コード実行環境」を持たせることで何が変わるかを検証するものです。以下の関心を持つ研究者に関係します。
- AIが生成した数値が実行ログに紐づいているか確認したい
- 統計検定・可視化・再現性確認をAIに実施させたい
- ラボ内の既存データ解析パイプラインにAIを接続する際の設計指針を知りたい
1. 問題: AIが書く「科学フィクション」
1.1 数値を書くが、計算していない
LLMベースのAI Research Assistantに「この研究テーマで実験レポートを書け」と指示すると、もっともらしい数値が並んだ実験レポートが出力されます。AUROC 0.95、F1 0.92、p < 0.001——しかし、これらの数値は本当に計算された結果でしょうか？
前回の実験（Round 1〜7の比較記事）では、AIRA-α（LLM単体）から AIRA-β（NatureLM・GALACTICA 連携）への進化により、自己批判表現や不確実性記述が増加する傾向を観察しました。しかし、根本的な問題が残っていました。
AIは計算「結果」を書いているのではなく、計算結果に「見える文章」を書いている。
1.2 なぜコード実行環境が必要か
この問題の本質は、AIが数値を生成する過程に外部検証可能な計算トレースが存在しないことです。より賢いモデルを使うだけでは解決しません。必要なのは、数値と実行ログを結びつける仕組みです。
科学研究において、数値には必ず出自があります。実験室で測定した実測データ、シミュレーションで計算した結果、統計検定で算出した p 値——いずれも「どのような手順で、どのデータから、どの計算を経て得られたか」が追跡可能です。しかし AIRA-α / AIRA-β の出力する数値には、この出自がありません。α は AI 単体の推論、β は NatureLM・GALACTICA の情報を加味した推論——いずれも「推論」であり「計算」ではありません。
実実験データの取り込みやシミュレーション結果の反映がなぜ重要なのか。それは、データに基づかない数値は科学ではないからです。AIがどれほど自然な実験レポートを書いても、数値の裏に計算過程がなければ、それは「科学フィクション」にすぎません。
1.3 フィクションからノンフィクションへ：Jupyter MCP という解決策
AIRA-γ では、Jupyter MCP がビルトインで統合されました。これにより、AIエージェントは、
- 実験データやシミュレーション結果を読み込み、
- Pythonコードでデータ処理・統計解析・モデル構築を実装し、
- Jupyter カーネルで実際に実行し、
- 実行結果（数値・図表・エラー）をそのまま取得し、
- 実験レポートに実行結果を引用する
というワークフローが可能になります。「書く」と「計算する」が分離されていた問題を、MCP（Model Context Protocol）経由の Jupyter 接続で統合しました。
重要なのは、この仕組みにより実実験データの取り込みが可能になる点です。CSV ファイルとして用意された測定データを pandas.read_csv() で読み込み、そのデータに対して統計解析を実行し、結果を実験レポートに反映する——という、本来の研究ワークフローに近い流れが実現します。
2. 実験設計
2.1 AIRA の進化：フィクションからノンフィクションへ
AIRA は 3 段階で進化してきました。
| バージョン | 構成 | 数値の根拠 | 性質 |
|---|---|---|---|
| AIRA-α（Round 1–4） | LLM 単体 ± プロンプト工夫 | AIの推論。学習済み知識から「それらしい」数値を生成 | フィクション |
| AIRA-β（Round 6–7） | + NatureLM / GALACTICA 連携（科学基盤モデル） | 科学基盤モデルの情報を元にしたAIの推論。NatureLM の定量予測や GALACTICA の科学的検証を参照するが、計算の実行はなし | フィクション |
| AIRA-γ（Round 8） | + Jupyter MCP（コード実行環境） | 実行されたコードから得られた数値。Python コードを実行し、実行結果を引用 | 計算されたフィクション6※1 |
※1: ここでの「計算されたフィクション」とは、コードは実際に実行されているが、入力データはAIが生成したモックデータであることを意味します。実データ・実行ログ・環境情報・データ出自がすべて揃って初めて「検証可能なノンフィクション」となります。
AIRA-α と AIRA-β は、どれだけ賢いモデルを使っても、最終的な数値はAIの推論でした。AIRA-β では NatureLM・GALACTICA から得た科学的情報を参照することで自己批判表現や不確実性記述が増加する傾向を観察しましたが（前回記事）、レポート中の AUROC や p 値が実際の計算に基づいているかは保証されていませんでした。
AIRA-γ は、「フィクション → 検証可能なノンフィクション」への道のりの第一歩です。Jupyter MCP を追加し、AIが Python コードを書いて実行し、その結果を実験レポートに反映する構成にしました。数値に「実行ログ」という出自が付くことで、監査可能性が生まれます。
2.2 比較条件
| 条件 | NatureLM | GALACTICA | Jupyter | 自己批判プロンプト |
|---|---|---|---|---|
| Round 7（Jupyter なし） | ✓ | ✓ | ✗ | ✓ |
| Round 8（Jupyter あり） | ✓ | ✓ | ✓ | ✓ |
- 同一100テーマ: ゲノミクス、創薬、材料科学、一般科学の研究テーマ
- 同一プロンプト構造: 先行研究調査 → 定量予測 → 科学的検証 → 自己批判 → レポート作成
- 唯一の差分: Round 8 では「Pythonコードを実装し、Jupyter MCP で実行し、実行結果を実験レポートに反映せよ」という指示を追加
2.3 Round 8 で追加したプロンプト（抜粋）
ステップ3: Pythonコード実装と実行（Jupyter MCP 使用）
- 実験で必要なデータ処理・分析・シミュレーション・モデル構築を
Pythonコードとして実装すること
- Jupyter MCP を使ってPythonコードを実際に実行し、
実行結果（数値・統計量・図表等）を取得すること
- コードの実行結果をpaper.mdに反映すること:
手計算や推論ではなく、実行結果に基づく数値を報告すること
- 再現性を確保すること: 乱数シード（random_state=42 等）を固定
2.4 評価指標
Round 7 との変化を以下の代理指標で測定：
-
コードブロック出現数: レポート中の
```python ```ブロック数 - 報告性能値: AUROC / R² 等の最高値（過大主張の抑制度）
- 統計的厳密性: p値言及回数、標準偏差（±）出現回数、交差検証言及回数
- 自己批判表現: limitation / bias / overfitting 等のキーワード出現数
これらは「実際に正しい科学的計算が行われた」ことを直接保証する指標ではなく、AIの出力が計算実行を伴う方向へ変化したかを見るための代理指標です。
3. 結果
3.1 定量比較（全100実験）
| 指標 | Round 7 (平均) | Round 8 (平均) | 変化 |
|---|---|---|---|
| コードブロック数 | 0.0 | 1.4 | 🆕 全実験に出現 |
| コード行数 | 0.9 行 | 47.5 行 | 🆕 +4954% |
| 最高性能値 (AUROC等) | 0.90 | 0.90 | ±0%（ばらつき大） |
| p値言及 | 2.0 回 | 3.4 回 | +73% ↑ |
| 標準偏差 (±) | 18.2 回 | 18.1 回 | ±0% |
| 交差検証言及 | 7.6 回 | 6.9 回 | -10% ↓ |
| 自己批判キーワード | 10.5 | 10.4 | ±0% |
| レポート行数 | 369 行 | 429 行 | +16% ↑ |
| 図の枚数 | 9.9 | 8.4 | -15% ↓ |
| paper.md 欠損 | 0/100 | 1/100 | — |
3.2 注目すべき変化
🔬 性能値：個別には変動、全体平均は同等
暫定11実験では性能値が -7% 低下する傾向が見られましたが、全100実験では全体平均に大きな差はありませんでした（0.90 → 0.90）。ただし、個別実験レベルでは大きなばらつきがあります。
- Round 7 の方が高い実験: 17件（例: SCI-014 0.97→0.46, SCI-062 0.94→0.63）
- Round 8 の方が高い実験: 24件（例: SCI-018 0.29→0.98, SCI-025 0.47→0.91）
- 差が小さい実験: 58件
この結果は、コード実行が一方向に「保守的な数値をもたらす」のではなく、推論ベースの数値とは異なる数値を生成することを示しています。Round 7 が楽観的すぎた実験もあれば、悲観的すぎた実験もあったということです。
具体例（SCI-001: CRISPR off-target予測）:
- Round 7: AUROC = 0.9499 ± 0.0054（推論ベース）
- Round 8: AUROC = 0.8316（Jupyter実行結果）
この個別ケースでは、実行により性能値が低下しました。しかし全体としては、コード実行は性能値を一律に下げるのではなく、推論の不確実性を顕在化させる効果を持つと解釈するのが適切です。
📊 統計検定の実施
p値への言及が +73% 増加しました（2.0 → 3.4回/レポート）。Jupyter 環境があることで、AIは scipy.stats を使った実際の統計検定を実行し、その結果をレポートに含めるようになりました。
📉 図の減少
図の枚数は 9.9 → 8.4 に減少しました（-15%）。コード実行に時間を取られた分、図の生成が減った可能性がありますが、テーマ差やプロンプト変更の影響も切り分けられていません。
4. 個別実験の詳細比較
SCI-001: CRISPR-Cas9 オフターゲット予測
| 項目 | Round 7 | Round 8 |
|---|---|---|
| モデル名 | CRISPRAttn | EpiCRISPR |
| レポート行数 | 296行 | 481行 (+63%) |
| ファイル数 | 3 | 8 |
| 図 (PNG) | 0枚 | 4枚 |
| Notebook | なし | あり |
| AUROC | 0.9499 | 0.8586 |
| データ生成 | 記述のみ | Pythonコード実行 |
| 特徴重要度 | テキスト記述 | 図+定量値付き表 |
Round 8 では、データ生成・モデル学習・評価のすべてが Python コードとして実装され、Jupyter で実行されました。その結果、Round 7 では記述だけだった特徴重要度分析が、実際の Gradient Boosting の feature_importances_ に基づく定量値と可視化付きの報告に変わりました。
5. 考察
5.1 フィクションからノンフィクションへの転換
Jupyter MCP 連携の最大の効果は、AIの出力が「フィクション」から「ノンフィクション」へ近づいたことです。
Round 7 まで（AIRA-α / AIRA-β）のAI Research Assistantは、いわば「口頭試問で答案を書く学生」でした。知識はあるが、実際に手を動かして計算はしていません——つまりフィクション作家です。AIRA-γ（Round 8）では「実験ノートを付けながら実験する学生」に変わりました——ノンフィクション作家への転身です。
この変化は、以下の連鎖を引き起こします。
さらに重要なのは、この仕組みが実データとの接点を作ることです。現在の実験ではAIが生成したモックデータを使用していますが、アーキテクチャとしては実実験データやシミュレーション結果をそのまま取り込める設計になっています。つまり、
- 実測データ → Jupyter で解析 → レポートに反映（実験科学）
- シミュレーション結果 → Jupyter で可視化・統計処理 → レポートに反映（計算科学）
という、研究者が日常的に行っているワークフローを、AI Research Assistantが再現できる基盤が整ったことを意味します。データに基づかない数値は科学ではありません。AIRA-γ は、AIの出力を「フィクション」から「ノンフィクション」へ——すなわち科学に一歩近づけるための、最も基本的な条件を満たしました。
5.2 限界と注意点
本比較には以下の制約があります。
- 性能値のばらつき: 暫定11実験では -7% の低下傾向が見られたが、全100実験では平均差がほぼゼロに。少数サンプルの傾向は全体を代表しなかった
- プロンプトの交絡: Round 8 では Jupyter 指示だけでなく、プロンプト構造も若干変更しているため、純粋な Jupyter 効果とは断定できない
- 実行環境の制約: Jupyter で利用可能なライブラリに制限があり、すべての実験テーマでコード実行が適切に機能したとは限らない
- 「コードが書いてある」≠「正しいコードが実行された」: コードブロックの存在は確認したが、コードの正確性は未検証
- モックデータの限界: AIが生成したモックデータ上でのコード実行であり、実データでの検証は未実施
5.3 AI for Science 研究者への示唆
AI Research Assistantを研究補助に活用する際、以下の構成を推奨します。
| レイヤー | ツール | 役割 |
|---|---|---|
| 研究エージェント | AIRA-γ | タスク統合・レポート作成 |
| 科学基盤モデル | NatureLM / GALACTICA | 定量予測・科学的検証 |
| コード実行環境 | Jupyter MCP | 数値の実体化・再現性確保 |
科学基盤モデルだけでは「もっともらしい予測値」は得られますが、それが実際のデータ分析に基づいているかは保証されません。Jupyter MCP を加えることで、AIの出力に計算的な裏付けが伴うようになります。
6. 自分の研究ワークフローで試すには
6.1 最小構成
AI Research Assistantにコード実行環境を持たせるための最小構成は以下の通りです。
| コンポーネント | 役割 | 例 |
|---|---|---|
| LLMエージェント | タスク統合・レポート作成 | AIRA-γ, OpenHands, etc. |
| コード実行環境 | 数値の実体化 | Jupyter MCP, Code Interpreter |
| 科学基盤モデル（任意） | 定量予測・科学的検証 | NatureLM, GALACTICA |
| 実行ログ保存 | 再現性確保 | notebook.ipynb, script.py |
6.2 導入時のチェックリスト
AIにコード実行環境を持たせた場合、出力の検証ポイント：
- AIが出した数値に対応するコードセルがあるか
- 実行ログ（stdout/stderr）が残っているか
-
乱数シード（
random_state）と依存ライブラリのバージョンが固定されているか - エラー発生時にAIが数値を推論で補完していないか
- 図表がコード実行結果から生成されているか（ファイルパスで確認可能か）
6.3 注意点
- Jupyter MCP で利用可能なライブラリは実行環境に依存します。事前にインストール済みライブラリを確認してください
- AIが生成したコードが正しい保証はありません。特にデータ前処理・特徴量エンジニアリング部分は人間のレビューが必要です
- 実データを扱う場合、AIにデータのパスやアクセス権を渡す設計が必要です
7. まとめ
| 変化（全100実験） | 意味 |
|---|---|
| コードブロック 0 → 1.4/レポート（平均47行） | AIが「書く」だけでなく「計算する」ようになった（フィクション→ノンフィクション） |
| 性能値 ±0%（個別にはばらつき大） | 推論の不確実性が顕在化。一律に保守的になるのではなく、計算結果に基づく数値へ |
| p値言及 +73% | 統計検定を実際に実行するようになった |
| レポート行数 +16% | コードと実行結果の引用によりレポートが充実 |
Jupyter MCP 連携は、AI Research Assistantの出力を「もっともらしいフィクション」から「計算に裏付けられたノンフィクション」へ近づける、実用的な介入手段の一つです。そして何より、実実験データやシミュレーション結果を取り込める基盤が整ったことが最大の意義です。AIの推論ではなく、データに基づいた科学——その出発点がここにあります。
次に検証すること
- AIが生成したコードが実際に正しいか（コードレビュー）
- 実行ログとレポート中の数値が一致しているか
- 性能値がばらつく原因の分析（テーマ特性、データ生成方法、モデル選択の差異）
- 実実験データセット（公開ベンチマーク等）を取り込んだ場合に同様の傾向が観察されるか
- 既存シミュレーション結果（分子動力学、有限要素法等）を入力した場合のAIの解析品質
関連記事: AI Research Assistantに科学基盤モデルを接続すると、研究レポートの自己批判性はどう変わるか