Mar 22, 2026

ScienceAgentBench: 研究タスクにおけるPythonコード生成ベンチマーク

大規模言語モデル（LLM）が自律的にツールを使いながらタスクを遂行するシステムである「AIエージェント」を、科学研究に活用する動きが広がっています。研究活動には、「データの前処理」、「データ解析」、「可視化」といった多様なタスクがありますが、それら個別タスクをAIエージェントはどこまでの性能で実行できるのか？

この問いに対して、個別タスクの中でも「Pythonコード生成」におけるAIエージェントの遂行能力を測定するベンチマークがScienceAgentBenchです。「データを前処理してモデルを構築し、結果を可視化する」といった、科学者が日常的に行うPythonコード作成タスクを102問集め、AIエージェントの実力を定量評価する仕組みとその結果が報告されています。

本記事では、論文とGitHubから読み取れるScienceAgentBenchの概要説明と、自分のPC環境で論文の再現実験を試みた結果を報告します。論文を読むだけでは見えなかった発見がいくつかあったので、本記事で共有しようと思います。

ScienceAgentBenchとは

概要

ScienceAgentBenchは、データ駆動型科学（データの前処理・分析・モデル構築・可視化といった、データを扱う科学研究の一連の作業）におけるAIエージェントの能力を評価するベンチマークです。Ohio State UniversityとUW-Madisonの研究チームが開発し、ICLR (International Conference on Learning Representations) 2025に採択されています。

具体的には、「自然言語の指示とデータセットを受け取り、自己完結型のPythonプログラムを生成して、科学的に有意義な結果を出力する」というタスクが102問用意されています。

タスクの構成

102問は以下4つの科学分野を含みます：

分野	内容の例
バイオインフォマティクス	細胞画像の分析、遺伝子データの処理
計算化学	分子の毒性予測、構造-活性相関の分析
地理情報科学	洪水リスクマップの作成、空間分析
心理学・認知神経科学	EEG（脳波）の時系列分析、睡眠データ解析

各タスクには、データ処理、モデル開発（機械学習・深層学習）、データ分析、可視化といったサブタスクが含まれます。1つのタスクが複数のサブタスクを含む場合もあり、たとえば「分子データを特徴量に変換し、グラフニューラルネットワークで毒性を予測し、結果をグラフで可視化する」というタスクには、データ処理・深層学習・可視化の3つのサブタスクが含まれます。

※ データはこちらのHuggingFaceを参照。

タスクは専門家により人手で作成された

このベンチマークの特徴の1つは、すべてのタスクが人手で作成されている点にあります。

以下の5段階のプロセスで102問のタスクは作成されました：

44の査読済み論文からコード例を特定
データセットを収集・前処理
正解プログラム（リファレンス実装）を作成
タスク固有の成功判定関数を実装
自然言語のタスク指示を記述

これを9人の大学院生アノテーターが実施し、さらに各分野の専門家（Ph.D.学生・教授）が検証しています。他者が作成したタスクの再現確認まで行っており、品質管理がされています。

データ汚染対策

ベンチマークに使うデータセットと正解コードはオープンソースの論文から抽出しているため、LLMの事前学習データに含まれている可能性があります。つまり、LLMが「問題を解いた」のではなく「学習データに含まれていたコードを再現した」だけ、という状況が起こりえます。

このデータ汚染問題に対して、ScienceAgentBenchは2つの対策を講じています：

テストデータからのサンプル削除: 各データセットのテストデータから5つのサンプルをランダムに削除。もしLLMが学習データに含まれていた元論文のデータ読み込み処理をそのまま再現し、オリジナルのデータセットを取得してしまうと、サンプルが除去されたテストデータとの間で出力結果にズレが生じ、成功基準を満たせなくなります。この仕組みにより、LLMが「問題を解いた」のか「学習データに含まれていたコードを再現した」だけなのかを検出できます。
テストセットラベルのダミー値置換: HuggingFace等の公共に出すデータの正解ラベルを-999などのダミー値に置換しておくことで、LLMへの学習を防いでいます。ユーザーが実際にベンチマークを利用するためにデータをダウンロードする際には実際の正解ラベルが提供されます。

評価の仕組み

ScienceAgentBenchの評価は、「生成されたコードが動くか」、「結果が科学的に正しいか」、「コードの品質はどうか」の3層で構成されています。

3つの主要指標

指標	何を測るか	値の範囲
VER（Valid Execution Rate）	生成プログラムがエラーなく実行でき、正しいファイル名で出力を保存できたか	0 or 1（タスク単位）→ 全体で割合（%）
SR（Success Rate）	タスク固有の成功基準を満たしたか	0 or 1（タスク単位）→ 全体で割合（%）
CBS（CodeBERTScore）	生成コードと正解コードの意味的類似度	0〜1の連続値（トークン埋め込みに基づくF1スコア）

VERとSRは階層関係にあり、VER=0（コードが動かない）なら、自動的にSR=0（成功判定不可）になります。たとえばSR=23.5%という報告は、102問中約24問で科学的に正しい結果が得られたことを意味します。

SR=1（タスク成功）の場合、CBS=1.0に強制設定。結果が正しいなら、コードの書き方が正解と違っていても品質は十分と見なす設計となっています。

タスク固有の評価関数：102個のeval_programs

SRの判定は、タスクごとに用意された個別の評価関数で行われます。benchmark/eval_programs/ディレクトリに102個のPythonコードがあり、それぞれにeval()関数が定義されています。この関数は成功（1）か失敗（0）を返します。

評価関数の判定方法は、大きく3種類：

数値比較: モデルの精度指標（AUC、F1、RMSEなど）がタスクごとに設定された閾値を超えるかで判定。たとえば「ROC-AUCが0.77以上なら成功」のように、タスクの難易度に応じた閾値が個別に定められています
集合・リスト・データフレームの一致判定: 予測されたTop-K特徴量や分類結果が正解と構造的に一致するかを判定。集合の一致、順序付きリストの完全一致、DataFrameの構造一致など、タスクに応じた比較方法が使われます
図の評価（GPT-4oジャッジ）: 出力が図（PNG画像）の場合、GPT-4oに生成された図と正解の図を見比べさせて0〜100のスコアをつけさせます。60点以上で成功と判定。全評価スクリプトの約63%がこのパターンであり、最多カテゴリ

図の評価：GPT-4oジャッジのプロンプト

図の評価は、正解の図を100点の基準として生成された図が正解にどれだけ似ているかを、LLMに0〜100で採点させる仕組みとなっています。これを3回実行して平均スコアを算出し、60点以上で成功と判定されます。

ルーブリック評価：部分点を測る仕組み

SR（成功率）は「完全に正解か否か」の二値判定です。しかし、「データの読み込みまではできたが、モデリングで失敗した」といった部分的な成功を評価したい場合もあるかと思います。

この目的のために、ScienceAgentBenchはルーブリック（採点基準表）ベースの評価を導入しています。各タスクを5段階のステップに分解し、どこまで達成できたかを評価：

Data Loading: データの読み込み
Data Processing: データの前処理
Modeling or Visualization: モデリングまたは可視化
Output Formatting: 出力フォーマット
Output Saving: 出力の保存

各ステップにはさらに細かい項目と配点が設定されています（タスクあたり平均約8項目、合計20〜90点）。項目および配点の詳細は、ベンチマークダウンロード時に一緒にダウンロードされます。なお、ポイント配分の基準を明示的に説明するドキュメントはリポジトリ内に見当たらず、配点のロジックは不透明です。

実験結果と考察

実験設定

論文では5つのLLM（GPT-4o、OpenAI o1-preview、Claude-3.5-Sonnet、Llama-3.1-70B/405B、Mistral-Large-2）を3種類の動作方式で評価しています。ただし、o1-previewは評価時点でハイパーパラメータの変更が制限されておりOpenHandsとの互換性がなかったため、Direct PromptingとSelf-Debugの2方式のみで評価されています。動作方式の違いは以下の通り：

Direct Prompting: LLMに1回だけプロンプトを送り、一度の応答でプログラム全体を生成。実行環境とのやり取りはなし。「一回のみのLLM応答」のコード生成能力を測ります
Self-Debug: まずコードを生成し、それを実行してエラーが出たら、エラーメッセージと元のコードをLLMに再入力して修正。このサイクルを繰り返します。2回連続で同じコードが出力されたら完了
OpenHands CodeAct: OpenHandsは、Pythonインタプリタ、bashシェル、Webブラウザの3つのツールを使いながら、自律的にタスクを解決するオープンソースの汎用AIエージェントフレームワーク。これを使ってプログラム生成を行います

各タスクを3回独立に実行し、「最大SR → 最大VER → 最大CBS → 最小Cost」の優先順で最良の結果を選択します。

また、エージェントに与える情報に2つの条件があります：

Without Knowledge: タスク指示とデータセット情報のみ
With Knowledge: 上記に加え、専門家が用意したヒント（科学用語の説明、数式、ライブラリの使用例など）を追加

主要結果

以下の表は、論文Table 3を抜粋したもの（GPT-4oとo1-previewの結果）です。SRが高いほど多くのタスクで正しい結果を出力できたことを意味します。

専門知識なし（Without Knowledge）:

モデル	フレームワーク	VER (%)	SR (%)	CBS	Cost/タスク
GPT-4o (2024-05-13)	Direct Prompting	52.9	11.8	82.6	$0.011
GPT-4o (2024-05-13)	Self-Debug	83.3	22.6	84.4	$0.047
GPT-4o (2024-05-13)	OpenHands CodeAct	78.4	19.6	83.1	$0.803
OpenAI o1-preview	Direct Prompting	70.6	34.8	87.1	$0.221
OpenAI o1-preview	Self-Debug	92.2	42.2	88.4	$0.636

専門知識あり（With Knowledge）:

モデル	フレームワーク	VER (%)	SR (%)	CBS	Cost/タスク
GPT-4o (2024-05-13)	Direct Prompting	41.2	10.8	83.8	$0.012
GPT-4o (2024-05-13)	Self-Debug	71.6	23.5	85.6	$0.046
GPT-4o (2024-05-13)	OpenHands CodeAct	73.5	27.5	86.3	$1.094
OpenAI o1-preview	Direct Prompting	63.7	31.4	87.4	$0.236
OpenAI o1-preview	Self-Debug	91.2	41.2	88.9	$0.713

論文の考察

1. 実行フィードバック(Self-Debug)は正解率を高める

Self-Debugにより、SRはDirect Promptingの約2倍に向上します。たとえばGPT-4oでは専門知識なしで11.8%→22.6%に改善。論文は「LLM生成コードは構造は正しいが実装エラーを含みやすく、実行→修正サイクルが不可欠」と分析しています。

2. シンプルな動作方式の方が高コストパフォーマンスな傾向にある

論文で評価された5つのLLM中4つで、Self-DebugがOpenHands CodeActを上回っています。論文は「大きなアクション空間や複雑なツールが常に有利とは限らない。コストと性能の両面で動作方式を選ぶべき」と結論付けています。

3. 専門知識はSRを上げるがVERを下げる

専門知識を与えるとSRは改善するが、VERはむしろ低下。論文が挙げる理由は2つ：(1) 馴染みのない専門ライブラリの使用が促され、API誤用やインストール失敗が増加傾向。(2) 知識なしでは空の出力で「実行成功」だったものが、具体的な処理を試みるようになりエラーが発生。それでも「ユーザー視点ではより有用なプログラムになる」というのが論文の立場となっています。

4. 成功タスクは単純なものに集中

成功タスクの75%以上は、正解プログラムが平均行数（58.6行）未満の比較的単純なもの。複雑なデータ処理や高度なモデル構築（CNN、Graph Neural Network等）が必要なタスクでは失敗率が高いと考察されています。

5. ボトルネックはデータの読み込みと前処理

論文は全102プログラムに対し、2名の評価者によるルーブリック手動評価が実施されています。5段階の各ステップで成功・失敗プログラムのスコア分布を比較した結果、Data LoadingとData Processingがボトルネックと判明。一方、Output FormattingやOutput Savingでは成功・失敗間に差がほとんどなく、LLMはこの種の指示には問題なく従えることが示されています。ルーブリック評価の自動化は将来課題として残されています。

再現実験

やったこと

論文の結果を自分の環境で再現できるか試みました。条件は以下の通り：

モデル: gpt-4o
動作方式: Self-Debug（専門知識あり）
環境: Apple Silicon Mac（ARM64）、Docker内のconda環境
評価: 論文と同じDockerized評価ハーネス、ジャッジモデルはgpt-4o

推論コードは公式リポジトリに合わせて修正し、できる限り論文環境に近づけました。評価のコードは公式リポジトリと同じものを使っています。

結果：再現できなかった

指標	論文値	我々の結果	差
SR	23.5%	14.7%	-8.8pp
VER	71.6%	55.9%	-15.7pp
CBS	85.6	80.7	-4.9pp

SR（成功率）は8.8ポイント、VER（実行成功率）は15.7ポイント低い結果となりました。

原因分析：なぜ再現しなかったか

再現できなかった最大の要因は、PCのアーキテクチャ差異（我々のARM64 vs 論文著者のx86_64 Linux）と考えます。以下、この結論に至った過程です。

まず疑ったのはジャッジモデルの違いです。最初は図の評価にgpt-5.2を利用していましたが、論文では図の評価にGPT-4oを使うため、モデルバージョンの差が結果に影響している可能性を考えました。しかし、論文の同一モデルであるgpt-4o-2024-05-13を使っても評価結果は全く同じだったため、この仮説は棄却しました。

次に推論コードの差異を検証。推論に使っているagent.pyの差分は約180行あったが、主にlitellmのフォールバック処理やパッケージ名マッピングの拡充であり、推論結果に大きな影響を与えるものではないと判断しました。

最終的にアーキテクチャ差異が最も大きな原因と考えました。根拠は3つです：

Deep Learningタスクの集中的な失敗: 全102タスク中、Deep Learning（深層学習）を含むタスクは14件。私達の環境ではこのうち11件がVER失敗でした。VERギャップは15.7ポイント（論文71.6% − 我々55.9%）ですが、もし論文著者たちの環境でこの11件のVERが成功だと仮定すると、この11件でギャップの大部分を説明できます。なお、残り88タスクはscikit-learn、pandas、geopandasなどCPUのみで動作するライブラリを使用しており、アーキテクチャの影響を受けにくい。Deep Learningタスクの失敗は、deepchemやDGL（Deep Graph Library：グラフ構造データを扱う深層学習ライブラリ）などがARM64向けのビルドを提供しておらず、インストール自体が失敗することが原因の1つと考えています
論文著者がx86_64 GPU環境を使用している可能性が高い: 私たちはARM64環境を利用して再現実験したが、論文著者たちはx86_64 GPU環境を使っている可能性が高いと推測しました。その理由は下記2点です。
- 推論コードにx86_64前提の記述があった: agent.py内で、DGLのインストール先URLが cu121/manylinux1_x86_64.whl とハードコード。
- 論文内の言及: 論文のAcknowledgmentsに「Ohio Supercomputer Center」への謝辞あり。OSCはx86_64 Linux GPUクラスタを提供

この結果から、ベンチマーク再現において実行環境の一致が重要である可能性が高いと考えました。CPUアーキテクチャやGPUの有無といったインフラレベルの違いが結果を左右している可能性が高いです。環境エラーとコードバグの区別をするには実行結果を目視で確認する必要があります。

まとめ

ScienceAgentBenchは、専門家が人手で作成・検証した、科学タスクにおけるAIエージェントのPythonコード生成能力を測るベンチマークです。本記事の内容を以下に整理します。

ベンチマークの設計: 4分野・102問のタスクが用意され、VER（実行成功率）・SR（成功率）・CBS（コード類似度）の3層で評価される。図の評価（全体の約63%）にはGPT-4oジャッジが使われている
論文の主要知見: 最高性能のエージェント（o1-preview + Self-Debug）でもSRは42.2%にとどまる。ボトルネックはデータの読み込みと前処理と考察されている
再現実験の結果: ARM64環境（Apple Silicon Mac）ではSR 14.7%（論文値23.5%）と再現できなかった。主因はCPUアーキテクチャ差異によるDeep Learningライブラリのインストール失敗と考えられる

おわりに

再現実験を通じて、いくつかの気づきがありました。

図の評価について。今回の再現実験では、GPT-4oとGPT-5.2の2モデルでジャッジを実行したところ、成功判定のタスク数が一致（15件）しており、モデル間での判定のブレは小さいことが確認できました。ただし、これは1条件での比較にとどまるため、一般的な結論を出すにはさらなる検証が必要です。また、図の「見た目の類似度」だけでは科学的正しさを完全には捉えきれない面もあり、目視確認との併用が有効だと考えます。

再現性と実行環境について。今回の経験から、ベンチマークの再現実験を行う際には、CPUアーキテクチャやGPUの有無といったインフラレベルの条件を論文の実行環境に合わせることが重要だと改めて実感しました。特にDeep Learning関連のライブラリはプラットフォーム依存が大きいため、再現実験に取り組む際は事前に環境の互換性は要チェックだと感じました。

今後の展望。論文報告時点では最高SRが42.2%であり、科学研究の完全自動化には遠いものの、比較的単純なデータ処理や可視化タスクでは実用的な性能が出始めています。最近ではGPT-5.4やClaude Opus 4.6などの新たなモデルが公開されており、性能はさらに向上している可能性があります。私達も最新モデルを使った実験を行い、どれだけ性能が向上しているか確かめていきたいと思います。

参考リンク

論文: ScienceAgentBench: Toward Rigorous Assessment of Language Agents for Data-Driven Scientific Discovery
GitHub: ScienceAgentBench
Hugging Face: https://huggingface.co/papers/2410.05080

Contact

Science Aidは、研究を中心とした幅広い領域をAIによって支援します。システム開発やコンサルティング、共同研究、セミナーのご依頼などお気軽にご相談ください

お問い合わせ