AIは自らのエラーを見抜けない　OpenAI次期モデル「Astra」が科学研究で直面する検証の壁

OpenAIは2026年7月28日、AIコーディングエージェントを科学ソフトウェアの刷新に利用した8件の事例をまとめた、探索的なフィールドレポートを公開した。その後、同社は次期主要モデルファミリー「Astra」の名称と、数学・理論計算機科学における成果を公表した。

OpenAIはこれとは別に、2026年9月までに、限定された研究課題へ一定期間ほぼ自律的に取り組める「AIリサーチインターン」の実現を目標としている。ただし、Astraがそのシステムになることや、9月に公開されることは確認されていない。今回の8事例は、今後の自律型研究AIを評価するうえで重要となる、科学的妥当性の検証という課題を浮き彫りにしている。

■科学ソフトウェアの刷新で浮かび上がった検証の壁

2026年7月28日に公開されたフィールドレポートには、研究チームがAIコーディングエージェントを使用し、主に生命科学分野のソフトウェアを刷新した8件の事例が収録されている。5件ではOpenAIのCodexのみを使い、残る3件ではCodexとAnthropicのClaude Codeを組み合わせた。

成果には、RNAシーケンシングの品質管理で最大60.2倍の高速化を達成した事例、2万行規模のゲノムアライナーをRustで全面的に書き換え、特定のベンチマークで99.8％を超える一致率を得た事例、GPUネイティブの設計によって合成ゲノム生成パイプラインの処理時間を26分50秒（1,610秒）から27秒へ短縮した事例などがある。

ただし、これは8件の初期事例を振り返った探索的な報告であり、ランダム化比較試験でも、AIコーディングエージェント全般を代表する性能評価でもない。得られた数値は、それぞれのチームが特定のソフトウェア、データ、ハードウェア、検証条件の下で報告した結果として読む必要がある。

8件に共通して見られたのは、エージェントが実装作業を大幅に進められる一方、生成物が科学的に妥当かどうかを確実には判断できなかったことだ。とりわけHelixForgeでは、テスト自体のバグを実装側の問題だと誤認し、正常なコードを変更しようとした事例が確認された。

このため、現在の主要なボトルネックは、単にコードを書くことから、何を正解とするかを人間が定義し、その基準で結果を検証することへ移りつつある。

科学分野でこの問題が特に重大なのは、ソフトウェアの正しさが、テストへの合格だけでは決まらないためだ。期待される出力が、物理法則、生物学的現実、統計的性質、数学的条件などと整合していなければならない場合、誤ったテストに合格しても科学的に正しいことにはならない。

現代のゲノミクス、生物学、気候研究などを支える計算基盤の多くは、小規模な研究チームが特定の論文や研究課題のために開発したツールから成り立っている。長期的な保守を前提とせずに作られ、本番用ソフトウェアと同じ水準のテスト、文書化、パッケージング、継続的保守が行われていないものも少なくない。

公表済みの研究では、調査対象となった研究用Rスクリプトの74％がクリーンな計算環境での初回実行に失敗した。また、別の調査では、対象となったゲノミクスツールの57％が、文書化されたインストール手順に従っても正常に導入できなかった。

AIコーディングエージェントは、こうした技術的負債を減らす手段になり得る。小規模な研究チームには対応する時間や専門人材が不足していた、パッケージング、依存関係の更新、性能改善、言語移行などの作業を支援できるからだ。

一方で、テストに合格するまでコードを変更するだけでは、科学的妥当性を保証できない。テスト自体が不完全、過度に限定的、または誤っている可能性も検討する必要がある。

■2万行規模のコードを書き換え、人間の検証で99.8％超の一致率へ

rustar-alignerは、C／C++で書かれた2万行規模のRNAシーケンシング用ゲノムアライナー「STAR」を、Rustで再実装するプロジェクトだ。STARとの互換性を保ちながら、新しい言語と保守体制へ移行することを目指した。

検証では、酵母由来のRNAシーケンシングリード1万件を使い、位置、CIGAR文字列、アライメント品質スコア、NHタグ、proper-pairフラグなどを比較した。特定のベンチマークでは、シングルエンドリードで99.815％、ペアエンドリードで99.883％の一致率を達成した。サフィックスアレイは元の実装とバイト単位で一致した。

ただし、これらはプロジェクトが設定したベンチマークで得られた数値である。あらゆる生物種、データ、パラメーター、利用環境においてSTARと完全に同等であることを意味するものではない。

一致率が約90％に達した段階で、プロジェクトは行き詰まった。残っていた差異には複数のバグが重なっており、1つを修正すると別の場所でリグレッションが発生した。テストが失敗すると、エージェントは自身の変更を元に戻すこともあった。

この状況を突破するため、人間の研究者がSTARとrustar-alignerの両方へデバッグ出力を追加し、同じリードが2つのアライメント処理でどのように扱われるかを、1件ずつ並行して追跡した。この比較方法によって、テスト結果だけでは切り分けられなかった差異の原因を特定した。

また、エージェントはコンパイラディレクティブによって無効化され、実際の実行経路から到達できないコードブロックを繰り返し編集した。こうしたデッドコードを変更してもテスト結果は変わらない。エージェントは最終的に追加調査へ進んだが、結果が変化しない理由を理解し、適切な調査方法を設計するうえで人間の判断が重要だった。

rustar-alignerは現在、scverseコミュニティーの下で開発されている。特定の一人だけに保守責任を集中させず、継続的な開発体制を整えることもプロジェクトの課題となっている。

■「雄弁で説得力があり、見落としやすい形で自信満々に間違える」

SeqeraでRustQCプロジェクトを率いたPhilip Ewels氏は、15個のツールを順番に実行していた品質管理パイプラインを、1回のファイル読み込みで複数の処理を行う単一のRustバイナリに置き換えた。

元の構成では、15個のツールがそれぞれ同じ大規模なアライメントファイルを読み込み、個別の中間ファイルを書き出していた。RustQCでは、ファイルを1回読み込み、必要な計算をまとめて実行する。主なボトルネックは演算処理ではなく、ディスクI/Oだった。

プロジェクトの測定では、個々のツールとの比較で最大26倍、1億8,600万リードのデータセット全体で60.2倍の高速化が報告された。

Ewels氏は、AIエージェントについて「雄弁で説得力があり、見落としやすい形で自信満々に間違える」と表現した。エージェントは元のツールとの小さな数値差を認識していたものの、修正すべきリグレッションではなく、「科学的に妥当」または「許容できる」差異だと判断することがあった。

このため、複数の生物種から得た公開シーケンシングデータを、実際の利用に近い規模で処理する外部検証ハーネスが必要になった。もっともらしい説明を生成できることと、出力が科学的に正しいことは別の問題である。

シーケンシングデータに合成変異を挿入するCPUツール「BamSurgeon」をGPU向けに再設計したHelixForgeでは、プロジェクトの測定で、エンドツーエンドの処理が59.6倍、ゲノム編集工程が98.6倍高速になった。

このプロジェクトでは、ストランドバランスを調べる監査処理が偽陽性を返した。原因はGPU実装ではなく、監査側のダウンサンプリング処理に含まれていたバグだった。しかし、エージェントはGPU実装に問題があると判断し、そのコードを変更しようとした。問題がテスト側にあると特定したのは人間のレビュアーだった。

この事例は、エージェントがコードのバグとテストのバグを常に正しく区別できるわけではないことを具体的に示している。ただし、同一の失敗が8件すべてで発生したとまでは確認されていない。

■敵対的ペアリングで発見できる誤りと、残る限界

8件のうち3件では、CodexとClaude Codeを組み合わせた「敵対的ペアリング」が使われた。2つのエージェントが、コードを書くコントリビューターと、そのコードを評価するレビュアーの役割を交互に担う方法だ。

この手法では、エージェントごとに異なる種類の問題を発見でき、単独のエージェントでは抜け出せなかった停滞を打破できる場合があった。

MHCflurryのプロジェクトでは、以前に学習した重みを読み込む機能を維持しながら、約1万行の免疫学モデリングコードをTensorFlowからPyTorchへ移行した。2026年1月下旬から3月中旬にかけて、約130ファイルの大部分が変更された。2025年初頭に利用可能だったモデルで同じ移行を試みた際には、完了できなかったという。

敵対的ペアリングは、単独のエージェントによる実装と比べて有効な場合がある。しかし、2つのエージェントが互いの構文やロジックを確認しても、科学的に正しい出力を自動的に保証できるわけではない。

正しい結果を判断するには、コードが表現すべき物理的、生物学的、統計的、数学的性質についての知識が必要になる。ソフトウェア工学上の誤りを発見できても、ゲノミクス研究者、免疫学者、統計家、物理学者などにしか見抜けない問題が残る可能性がある。

bayesm-rsの事例では、ベイズ統計ライブラリをRustで再実装し、元のRコードと比べて2倍から20倍の速度で動作した。しかし、2つの高度な統計手法の初期実装には、出力を見ただけでは分かりにくい誤りが含まれていた。

1つの手法では、意図した制御パラメーターではなく、その逆数が使われていた。この誤りは、正解となる統計的性質が分かっている数千件の合成データセットを使った較正によって発見された。もう1つの手法では、補正係数のスケーリングを誤っていたにもかかわらず、もっともらしい出力が生成されていた。

出力がもっともらしく見えることは、実装が正しいことの証拠にはならない。

■SWE-bench Verifiedにも見つかったテストの問題

科学ソフトウェアに限らず、テストへの合格を正しさの代用にすることには限界がある。

Model Evaluation and Threat Research（METR）は2026年3月、SWE-bench Verifiedの自動評価に合格したAI生成のプルリクエストを、実際のプロジェクト保守担当者に評価させた結果を公表した。

調査対象は、SWE-bench Verifiedに含まれる12リポジトリーのうち3つ、500件の課題のうち95件であり、4人の現役保守担当者が296件のAI生成プルリクエストを評価した。結果として、自動評価に合格した変更であっても、保守担当者の基準では約半数がそのままマージできないと判断された。

ただし、AIには人間の開発者のようにレビュー結果を受けて修正を繰り返す機会が与えられていなかった。METRも、この結果をAIの根本的な能力限界とは位置付けず、ベンチマークスコアを実務能力へ単純に置き換えると、有用性を過大評価する可能性があるとしている。

OpenAIは2026年2月、SWE-bench Verifiedのスコア報告を中止し、ほかのモデル開発者にも使用をやめるよう推奨した。

OpenAIが監査したのは、SWE-bench Verified全500問のうち、モデルが頻繁に失敗した138問である。これは全体の27.6％に相当する。その監査対象138問の少なくとも59.4％に、正しい解答を拒否し得るテスト設計や問題記述上の重大な問題があった。

したがって、「SWE-bench Verified全体の59.4％に欠陥がある」と解釈するのは正確ではない。59.4％は、難問を中心に抽出された監査対象内での割合である。

OpenAIはさらに、公開リポジトリー由来の問題や正解がモデルの学習データに含まれている可能性も指摘した。現在のフロンティアモデルを比較する指標としてSWE-bench Verifiedが適切でなくなった理由には、テストの問題だけでなく、データ汚染も含まれる。

■Astraの数学的成果と科学ソフトウェア検証の違い

OpenAIは2026年8月1日、内部版の次期主要モデルファミリー「Astra」が、数学と理論計算機科学における10件の未解決問題に取り組んだ成果を公開した。

公開された成果には、人間が読める数学的議論に加え、Leanで形式化された証明が含まれている。Leanは、形式化された定理と証明が論理規則に従っているかを機械的に検査できる。

これは、自然言語だけで数学的解答を示す場合と比べて、正しさを検証するための強力な仕組みである。一方、Leanによる証明があるからといって、専門家の役割がすべて不要になるわけではない。

機械検証が直接保証するのは、形式化された命題に対して証明が成立していることだ。形式化された命題が本来の問題と正確に一致しているか、採用した前提が適切か、結果が数学的または科学的にどのような意味を持つかについては、人間による確認と解釈が必要になる。Astraが出力した成果についても、人間の研究者が論文の準備や証明の形式化に関与した。

Astraは、長時間にわたる課題を複数のエージェントで処理するモデルファミリーとして説明されている。ルートとなるエージェントがサブエージェントへ課題を分配し、その結果を統合する構成が報じられている。

ただし、Astraの一般公開日や正式な製品名、GPT-6になるのかGPT-5系列の派生モデルになるのかは確定していない。Astraが2026年9月に予定されるAIリサーチインターンそのものになることも確認されていない。

OpenAIのチーフサイエンティストであるJakub Pachocki氏は、2026年9月までに、限定された研究課題を一定期間ほぼ自律的に処理できるAIリサーチインターンを構築する計画を説明している。さらに、2028年には、より大規模な研究プロジェクトへ取り組む完全自動型のマルチエージェント研究システムを目指している。

形式数学では、正しさを機械検証できる形へ落とし込める場合がある。科学計算では、正しさが物理的、生物学的、統計的現実との一致によって決まることが多く、何を測れば正しいと判断できるのかを人間が定義しなければならない。

Astraを含む将来の研究AIを評価するには、コードを生成できるか、テストに合格できるかだけでは不十分である。適切な検証基準を設定し、テストや前提そのものを疑い、結果の科学的意味を判断できるかが重要になる。

■研究ソフトウェアを高速化するためのコスト

AI支援によるソフトウェア刷新が、研究ソフトウェアのインストール失敗の4分の1から半分を防げると仮定した試算では、100パッケージ全体で節約できる時間の価値は60万ドルから約490万ドルとされた。

計算には、福利厚生費などを含む人件費として1時間当たり75ドルから150ドルが使われている。1ドル＝157円で概算すると、約1万1,800円から約2万3,600円に相当し、全体の価値は約9,420万円から約7億6,930万円になる。

NumPyだけを対象とした試算では、エージェントによって年間約650時間の保守作業を削減できる可能性があり、その価値は年間約4万9,000ドルから9万8,000ドル、同じ為替レートで約769万円から約1,539万円とされた。

ただし、これらは一定の導入効果と人件費を仮定した試算であり、実際にそれだけの節約が実現したことを示す実測値ではない。また、検証基盤そのものを構築する費用は含まれていない。

8件の事例では、多くのプロジェクトで、人間の主要な役割が実装から検証へ移った。エージェントの出力を、信頼できる参照実装、既知の結果、期待される統計的性質などと比較する外部検証ハーネスの構築が必要だった。

検証ハーネスの設計にはドメイン知識が、実行には現実を代表するテストデータが、結果の解釈にはテストが失敗した理由を考える能力が必要になる。HelixForgeの事例が示すように、テスト自体が誤っている可能性も考慮しなければならない。

2026年7月27日にPLoS Computational Biologyで発表された研究も、AI支援による科学コード開発では、人間が判断主体であり続け、堅牢な検証手順とドメイン知識を維持する必要があると指摘している。

同研究は、AIコーディングツールの生産性効果についても、状況や研究方法によって結果が異なるとしている。AIによって常に開発が高速化すると一般化するのではなく、開発者の経験、課題の複雑さ、コードベースの特性などを考慮する必要がある。

■高速化後の運営：AIが書き換えたツールは誰が保守するのか

検証と並ぶ課題が、継続的な運営と保守である。書き換えのコストが低下すれば、同じツールに対する複数の再実装が作られる可能性がある。

複数の研究グループが、保守の停滞した同じツールを個別に書き換えて公開すると、ユーザーコミュニティーが分裂し、専門家の注意が複数のコードベースへ分散する。AIによって解消されるはずだった保守負担が、なくなるのではなく再分配される可能性がある。

8件のプロジェクトでは異なる対応が取られた。MHCflurryのPyTorch移行版はMHCflurry 2.2.0としてリリースされ、既存プロジェクトへ組み込まれた。Brent Pedersen氏によるcyvcf2のパッケージング改善も、既存プロジェクトへ直接提供された。

rustar-alignerはscverseコミュニティーへ移され、継続的な保守体制の構築が進められている。Rustによる書き換えの過程で見つかったFastQCの性能改善は、別のツールとして分離するのではなく、元のJava版FastQCへ移植された。

こうした例は、新しい実装を作るだけでなく、誰が所有し、誰が保守し、既存ユーザーをどのように移行させるかを早い段階で決める必要があることを示している。

Pedersen氏は、現状を次のように表現している。「コーディングエージェントを使えば、速く進むのはかなり簡単だ。しかし今のところ、科学で遠くまで進むには、依然として専門家の指導、理解、判断力、そして細心の注意が必要だ」

■現在AIコーディングツールを評価する研究者への結論

8件の事例は、AIコーディングエージェントが、明確に定義された科学ソフトウェアの実装、保守、移行、性能改善で大きな効果をもたらす可能性を示した。

特に、比較対象となる既存実装、正解が分かっているデータセット、明確な数学的仕様、期待される統計的性質がある場合には、エージェントの出力を検証しやすい。

RustQCで最大60.2倍の高速化、rustar-alignerで99.8％を超える一致率が報告されたことは重要な成果である。ただし、これらは個別プロジェクトの条件下で測定された結果であり、独立した第三者によってあらゆる環境で再現された性能として扱うべきではない。

すべての導入で一律に同じ検証方法が必要になるわけではないが、科学的に重要なコードでは、正しい出力を理解する人物が検証基準の設計に関与する必要がある。

その人物は、以前のようにすべてのコードを自分で書く必要はなくなるかもしれない。しかし、何を作るべきかを定義し、エージェントが生成したものを検証し、公開可能な品質へ達したかを判断しなければならない。

人間の仕事が単純に減少するのではなく、実装から、課題設定、検証、判断、長期的な運営へ移る可能性がある。

■注目ポイントQ&A

●AIコーディングエージェントはバイオインフォマティクス研究者や研究ソフトウェアエンジニアの代わりになりますか？

現在公開されている事例だけから、代わりになるとは判断できません。AIエージェントは実装、移行、最適化などを大幅に支援できますが、科学的妥当性の判断、検証方法の設計、公開可否の判断、長期的な保守には人間の専門知識が必要です。

人間の役割は、コードを直接書く作業から、目標の定義、検証基盤の構築、結果の解釈へ移りつつあります。AIがコード生成を高速化するほど、人間によるレビューと科学的検証が重要になる場合があります。

●AI支援による科学計算の「検証のボトルネック」とは何ですか？

クラッシュせずに実行できるコードと、科学的に正しい結果を生成するコードとの間にある隔たりです。

エージェントは、構文エラーをなくし、既存のテストへ合格するコードを作成できる場合があります。しかし、テストが科学的妥当性を十分に表現していなかったり、テスト自体に誤りがあったりすれば、テストへの合格だけでは正しさを保証できません。

bayesm-rsでは、もっともらしい結果を生成する統計手法に数式上の誤りが残っていました。既知の性質を持つ数千件の合成データセットを使って較正することで、初めて問題を発見できました。このような検証基盤の構築にも、相当な専門知識と工数が必要です。

●Astraが科学研究に有効かどうかを判断するには、何を確認する必要がありますか？

Astraが2026年9月のAIリサーチインターンになることは確認されていません。また、一般公開日も確定していません。

今後評価すべきなのは、長時間にわたる課題を処理できるか、複数エージェント間で誤りを増幅せずに協調できるか、検証基準を適切に設定できるか、テストや前提そのものの誤りを疑えるかという点です。

Leanによる数学的証明は、形式化された命題に対する証明を機械検証できる点で重要です。しかし、科学計算では、生物学的、物理的、統計的な現実との一致をどのように測るかを定義する作業が別途必要になります。

●AIによって書き換えられた科学ツールは、元のツールと比べてどの程度正確ですか？

精度や一致率は、ツール、データ、測定条件によって異なります。

rustar-alignerでは、酵母由来の1万件のRNAシーケンシングリードを使ったベンチマークで、シングルエンドリードが99.815％、ペアエンドリードが99.883％の一致率に達しました。サフィックスアレイも元の実装とバイト単位で一致しました。

ただし、この結果は特定のベンチマーク条件に基づくものです。すべてのデータ、パラメーター、利用環境における完全な互換性を保証するものではありません。また、この水準へ達するまでには、人間が主導する反復的な検証が必要でした。

元記事: AI Coding Agents Proved Blind to Their Own Errors: What Astra Must Fix for Science