ScienceIDEは、世界中に散らばった科学コードのリポジトリ(repository)を、AIエージェントが実際に実行し、検証し、学べる「プログラム可能な環境」へと変えるインフラだ。こうして作られた環境から得た検証済みの相互作用記録をもとに、PhAI-IDE-72B・9B・4Bという3つのモデルを訓練し、held-out な科学コード修復(held-out scientific-code repair、学習・検証に含めなかったタスク)だけでなく、コード・推論・知識といった一般ベンチマークでも性能が向上したと報告している。つまり「科学的経験」で身につけた能力が、より広い能力へと移っていくという証拠(positive transfer)を示した研究である。
科学コードのリポジトリには、数十年分の人類の知識が実行可能な形で詰まっている。物理シミュレーション、統計モデル、分析ツールが、すべてコードとして固まっているわけだ。問題は、この知識をAIが「学習の経験」として扱うのが非常に難しいという点にある。論文はこの難しさを3つに整理している。
この3つのために、膨大な科学コードがあっても、それを「信頼できる学習経験」へ変換するのが難しい。論文はこのボトルネックを科学的経験のボトルネック(scientific experience bottleneck)と名づけた。
たとえるとこうだ。世界最高峰の研究室の実験ノートや機材が倉庫いっぱいに積み上がっているのに、各ノートは互いに異なる言語と略語で書かれ、機材ごとに電源の入れ方が違い、「実験成功」の基準も研究室ごとにバラバラ。新人研究員(AIエージェント)がこれを独力で習得するのはほぼ不可能だ。整理されていない知識は、どれだけ多くても「経験」にはならない。ScienceIDEは、まさにこの倉庫を「入って実際に実験してみられる実験室」へと改造しようとする試みである。
ScienceIDEの発想は「コードを読ませるのではなく、コードを実行して採点してもらえる環境にしよう」というものだ。核心となる流れは、アブストラクトを基にすると次のとおりである。
まず専門家が科学的ケース(scientific cases)と受け入れ基準(acceptance criteria)を定義する。これが一種の採点基準表であり、出題のガイドラインの役割を果たす。「このリポジトリではこういうタスクを解けるべきで、その結果がこういう条件を満たせば正解とみなす」というガイドを、人があらかじめ立てておくのだ。
次にエージェントがこのガイドを参考に、リポジトリを実行可能な環境(executable environments)へと変換する。この環境は3つをサポートする。
| 機能 | やること |
|---|---|
| タスク生成(task generation) | リポジトリから解くに値する問題を作り出す |
| 実行(execution) | エージェントが実際にコードを走らせてみる |
| 科学的検証(scientific verification) | 結果が受け入れ基準を満たすか採点する |
こうして作られた環境は、3つの学習方式が共有する共通の土台(shared foundation)となる。教師ありファインチューニング(SFT、正解例を見て学ぶ)、強化学習(RL、試行と報酬で学ぶ)、そして評価(evaluation、実力の測定)を、同じ環境の上で行える。
肝となるのは検証済みの相互作用記録(verified interaction trajectories)だ。エージェントが環境の中で問題を解きながら残した行動の軌跡のうち、科学的検証を通過したものだけを選んで学習材料に使う。料理にたとえれば、どんな調理過程でもとにかく真似させるのではなく、「実際に味見を通過したレシピの工程」だけを集めて教えるようなものだ。論文はこの材料で、PhAI-IDE-72B、PhAI-IDE-9B、PhAI-IDE-4Bというサイズの異なる3つのモデルを訓練した。
ここで重要な設計思想は「検証可能性」である。一般的なコーディングデータは「もっともらしく見えるコード」にとどまりがちだが、科学環境は実行と受け入れ基準という客観的な採点器を備えているため、「本当に正しかったのか」を見分けられる。自己採点が可能な学習の場であるという点が、このアプローチの強みだ。
アブストラクトが挙げる成果は大きく2つある。具体的な数値はアブストラクトに示されていないので、ここでは定性的にのみ整理する。
第一に、held-out な科学コード修復(held-out scientific-code repair)で性能が向上した。ただしここでのheld-outは未学習のリポジトリを意味しない — 論文 §3.3は、既存のコードベースの中で学習・検証に含めなかったタスクで評価したと明記している。したがってこの結果は、訓練に使わなかったタスクをより上手に解けるという証拠であり、初めて見るリポジトリへの一般化の証拠と解釈することはできない。
第二に、そしてこの論文で最も興味深い部分だが、選び抜かれた汎用ベンチマーク(code, reasoning, knowledge)でも向上が見られた。科学コードという狭い領域で学んだ経験が、コーディング・推論・知識というより広い領域の能力へと移ったということだ。論文はこれを科学的経験からより広い能力への正の転移(positive transfer)の証拠だと表現している。
意味を整理するとこうなる。AIの訓練用データの作り方は、人が一つひとつ作る・ウェブからかき集めるだけでなく、モデル自身にデータを生成・選別させる方法も以前から存在してきた(たとえばSelf-Instruct(2022)は、モデルが指示文・入力・出力を生成しフィルタリングして学習させる手法を示した)。ScienceIDEはその系譜の上で、「すでに世界に存在する科学ソフトウェア」そのものを、実行と受け入れ基準という客観的な採点器を通して採点可能な学習基盤(shared substrate)へと変えようと提案する点に特徴がある。人類が蓄積してきた科学コードを、エージェントが自ら実行しながら学ぶ材料へ転換できれば、学習データの供給源が根本的に広がる。論文はこれが、エージェント学習と科学実務を一つにつなぐ統合ワークスペース(integrated workspace)の土台になると見ている。
アブストラクトだけで判断するなら、正直に指摘しておくべき点がある。
こうした留保はあるものの、「実行・検証可能な環境を学習の一次材料とする」という方向性そのものは、検証可能なデータが貴重な時代にあって説得力がある。
ONTLEはAIプロジェクトマネージャーを派遣するSaaSだ。ScienceIDEの発想は、私たちがエージェント製品を作るやり方に直接的な示唆を与えてくれる。
第一に、コードベースを「読む対象」ではなく「実行して採点してもらう環境」として扱えという洞察だ。AI PMが顧客企業のリポジトリを扱うとき、コードを要約して読むことを超えて、実際に走らせてみて受け入れ基準で結果を検証するループを備えれば、はるかに信頼できる助手になる。「もっともらしい答え」と「実行で通過した答え」の差は、実務において決定的だ。
第二に、検証済みの相互作用記録だけを学習・改善の材料に使うという原則だ。ONTLEのエージェントが実際の業務をこなしながら残した軌跡のうち、明示的な受け入れ基準を通過した事例だけを選んで蓄積すれば、組織固有の信頼できる経験資産になる。これは私たちが強調してきた「根拠優先・検証可能性」の文化とまさに重なる。
第三に、RAGの観点からの含意だ。単に文書を検索して貼り付けるRAGを超えて、検索対象そのものを「実行可能で採点可能な環境」へと格上げすれば、回答の事実性が実行によって裏づけられる。つまり検索(retrieval)と検証(verification)を一つのパイプラインに束ねる設計が、ドメイン特化エージェントの信頼性を高める実用的な道筋になりうる。
第四に、専門家が先に受け入れ基準を定義するという点は、人とエージェントの役割分担モデルとして参考になる。人は「何を正しいとみなすか」を定め、エージェントはその基準の中で反復的な実行・検証・改善を自動化する。ONTLEのAI PMが目指す協働の構造と、同じ方向性を持っている。
両方にまたがっています。ScienceIDEは科学コードのリポジトリを実行可能な学習環境へ変えるインフラであり、その環境から得た検証済みの記録で訓練した成果物がPhAI-IDE-72B・9B・4Bのモデル群です。インフラが先にあり、モデルはその上から生まれた産物です。
科学コードには膨大な知識が詰まっているのに、断片化したツールチェーン・暗黙のドメイン慣習・特殊な正しさの基準のせいで、それを信頼できる学習経験へ変えるのが難しいという問題を指します。知識は多いのに、学習材料への転換が阻まれているという意味です。
アブストラクトは、held-out な科学コード修復とともに、選び抜かれた一般ベンチマーク(コード・推論・知識)でも向上が見られたと報告し、これを正の転移(positive transfer)の証拠として示しています。ただし具体的な数値や転移が起きるメカニズムはアブストラクトに明記されておらず、本文の確認が必要です。
コードがGitHub(aitofound/ScienceIDE)で公開されているため、確認することができます。ただし専門家が受け入れ基準を先に定義しなければならないという初期コストがあり、アブストラクトには適用範囲・規模に関する定量的な情報がないため、導入前に自分のドメインに合った検証基準の設計が先行する必要があります。