何が起きたか
OpenAIが、研究用ソフトウェアの近代化にAIコーディングエージェントを使った8件の事例をまとめたフィールドレポートを公開しました。対象は生物学分野が中心で、内容は依存関係の整備といった保守作業から、モダン言語への全面書き換えまで幅広く含まれます。
主な成果は具体的です。遺伝データを読むPythonライブラリcyvcf2は、古いビルド・インストール手順をGPT-5.5が現代的な方式に置き換えました。免疫学モデルMHCflurryは約1万行をTensorFlowからPyTorchへ移植し、Claude CodeとCodexが開発者役とレビュー役を交代しながら進めています。2万行超のC/C++で書かれ、すでに活発な保守が止まっているアライナーSTARは、rustar-alignerとしてRustでゼロから作り直され、酵母の短鎖リード1万件での比較ではシングルエンドで99.815%、ペアエンドで99.883%の一致を示し、どちらか一方だけがマップできたリードは存在しませんでした。合成ゲノムデータ生成のHelixForgeはGPU版としてBamSurgeonを全指標で上回り、パイプライン全体で59.6倍、主要な計算工程では98.6倍高速化しています。hifiasmは実際のヒトゲノムデータで約15%、HI.SIMは約31%の実行時間短縮でした。
なぜ重要か
注目すべきは速度ではなく、失敗の質です。エージェントは定義の明確なタスクを高速にこなす一方、その仕事が科学的に正しいかを自力で判断できず、誤ったコードを完全な自信とともに提示しました。RustQCを主導したPhilip Ewels氏はこれを「雄弁で説得力があり、見逃しやすい形で自信満々に間違っている」と表現し、モデルに自分の成果の正確性を判断させることを一切許さず、独立したテスト環境を自前で構築しています。
「速いのに間違っている」が最も危険
bayesmの事例が象徴的です。Rustへの書き換えで2〜20倍高速化したものの、高度な手法2つの初期版には出力を見ただけでは気づけない誤りが潜んでいました。ひとつは重要な制御パラメータが反転し、意図した値の逆数が使われていた不具合で、計算そのものの別のバグは、正解が既知の合成データ数千件との詳細な較正テストでようやく判明しました。もうひとつの手法HARTは全体としてもっともらしい結果を返しながら、不要に高コストな計算やスケーリングを誤った補正係数を抱えていました。
つまり、テストが通ることと正しいことは別物です。METRの調査では、広く使われるSWE-bench Verifiedで「合格」と判定された解の約半数を、実際のメンテナが受け入れないと判断したと報告されています。
分業の型は固まりつつある
8事例に共通していたのは、人間が目的・成功基準・検証方法を定義し、エージェントが実装を担うという分担です。hifiasmでは研究者が学習用と検証用のデータセットを分けたテスト環境を先に用意してからGPT-5.5に最適化を依頼し、HI.SIMではGPT-5.2が単発で各部を最適化した後、新しいモデルによる2回目で出力を変えずにさらに改善点を見つけました。MHCflurryの移植は2025年初頭に一度失敗しており、開発者のSergey Feldman氏はその原因をツールではなく当時のモデル世代に帰しています。
残る宿題は「誰が持ち続けるか」
著者らは、研究ソフトのインストール問題の4分の1〜2分の1をエージェントが解決できれば、100パッケージ分で節約される研究時間は60万ドルから500万ドル近くの価値になると試算します。一方で長期保守は未解決です。書き換えが安くなるほどコミュニティが分断され、限られたメンテナの時間（NumPyでは年間約650時間）がさらに薄く引き伸ばされかねません。所有権の扱いも事例ごとに割れました。保守が止まっていたSTAR由来のrustar-alignerはscverseコンソーシアムに移管され、FastQCの作者はRust版への置き換えを拒否したため、チームは改善を元のJava版に取り込み同じ3倍の高速化を実現しています。curlがAI生成の脆弱性報告に時間を奪われバグバウンティを閉じた件は、保守側のコスト増という同じ問題の別の顔です。
このレポートは完了済みプロジェクトの振り返りであり、関係者の証言に依拠していて、代表性のある調査ではないと著者自身が断っています。なお本レポートはOpenAIの科学領域への注力の一環でもあり、同社はKevin Weil氏が率いる科学専門チームを設置し、4月にはライフサイエンス向けのGPT-Rosalindと、50を超える公開データベース・生物学ツールに接続するCodex用プラグインを公開しています。
💼 事業会社視点：これは自社にどう効くか
受託開発・SIer：レガシー移植（COBOL、旧Java、社内独自フレームワーク）の見積り前提が崩れます。MHCflurryの約1万行移植やSTARの2万行超の再実装が現実に回った以上、「移植工数×人月」で売る提案は買い叩かれます。売るべきは実装ではなく、bayesmで見つかったパラメータ反転のような出力を見ても気づけない欠陥を捕まえる検証設計です。合成データによる較正テスト、旧実装との突合（rustar-alignerが1万リードで99.8%台の一致を確認した方式）を成果物に含め、単価をそこに寄せてください。
SaaS・EC：料金計算、在庫引当、レコメンドのスコアリングなど「静かに間違っても動き続ける」ロジックが最大の危険地帯です。AI書き換えを解禁する前に、旧実装をゴールデンリファレンスとして残し差分を自動比較するシャドー実行の仕組みを先に作るべきです。順序を逆にすると、高速化した誤りを本番に載せます。
役員が今決めること：3点です。(1) エージェントに自分の成果を評価させない（Ewels氏の独立テストハーネス原則）を社内規程化する。(2) レビュー工数を削減目標から外す——生成で浮いた時間はレビューに移るという調査結果があり、削減を評価指標にするとレビューが形骸化します。(3) 書き換えたコードの保守責任者を着手前に指名する。curlのバウンティ停止やNumPyの年650時間が示す通り、詰まるのは作る側ではなく維持する側です。
