OpenAIは2026年10月19日、COBOLやFortranなど、学習に利用できるコードや文書が比較的少ないプログラミング言語におけるAIの開発能力について、新たな評価結果を公表した。20言語でSQLite互換のデータベースエンジンを実装させる「MultiLangBench」では、GPT-6 Astraの平均テスト通過率が87.4%に達し、GPT-5.6 Solの26.8%から大幅に向上した。既存のCOBOLプログラムを別の言語へ移行する評価でも顕著な改善が見られたが、こちらは元のプログラムと完全に同じ結果を返せるかを検証するものだ。今回の成果を理解するには、新しいソフトウェアをどこまで実装できるかという能力と、既存システムの動作を維持したまま書き換えられるかという能力を区別する必要がある。
SQLiteの実装評価で20言語平均87.4%を記録
MultiLangBenchは、指定されたプログラミング言語を使い、SQLiteと互換性のあるデータベースエンジンをゼロから実装させる評価だ。SQLiteはデータベースをファイルに保存する軽量なデータベースエンジンで、モデルはコード全体の設計から状態管理、エラー処理、既存機能との整合性の維持までを担う。OpenAIが「低リソース言語」と呼ぶのは、PythonやJavaScriptなどの主要言語と比べ、AIの学習に利用できるソースコードや技術文書が少ない言語を指す。COBOLやFortran、Visual Basicなどは現在も重要な業務システムで使われているが、AIによる開発支援では学習データの不足が課題となってきた。
OpenAIの評価によると、最大の推論強度で実行したGPT-6 Astraは、対象となった20言語すべてでGPT-5.6 Solを上回った。COBOLのテスト通過率は10.9%から72.1%、Fortranは21.4%から83.5%へと向上した。OCamlも25.6%から85.8%、Visual Basicは27.5%から89.4%に改善している。20言語のうち19言語で83%を超えた一方、COBOLは72.1%にとどまっており、平均値だけでは見えない言語間の性能差も残っている。
低価格モデルのGPT-6 Lunaも、最大の推論強度で平均40.3%のテスト通過率を記録し、20言語すべてでGPT-5.6 Solを上回った。1サンプル当たりの推定平均API費用は0.77ドルで、GPT-5.6 Solの3.48ドルと比べて約78%低い。つまり、費用を抑えながら従来モデルを上回るLunaと、より高い通過率を持つAstraという選択肢が示されたことになる。ただし、この費用比較はLunaとGPT-5.6 Solを対象としたものであり、87.4%を記録したAstraの費用を示すものではない。また、これらの数値はベンチマーク上の推定値であり、実際の開発案件でも同じ費用対効果が得られるとは限らない。
評価の中心は生成コードではなく、実際に変更されたデータベース
OpenAIがGitHubで公開したMultiLangBenchのREADMEによると、この評価ではSQLite 3.40.1の公式ドキュメントをモデルに渡し、それを参考に互換エンジンを実装させる。特徴的なのは、生成したコードの説明や見た目ではなく、実際にデータベースファイルを正しく操作できたかどうかで採点する点だ。候補プログラムが作成したファイルを正規のSQLiteで読み込むため、実装言語が異なっていても共通の基準で動作を検証できる。
具体的には、まず初期状態のデータベースファイルとSQL文を候補プログラムに渡す。候補プログラムはSQL文を処理してデータベースファイルを書き換え、その変更後のファイルをSQLite 3.40.1で開き、検証用のSQL文を実行する。得られた結果が期待される文字列と完全に一致すれば、そのテストは合格となる。この方式なら、SQL文を受け付けるだけで実際には処理できないプログラムや、正しい結果を表示してもデータベースファイルを適切に更新できない実装を区別できる。解説サイトのexplainx.aiも、候補プログラムが残したファイルを正規のSQLiteで検証することで、ディスク上のファイル形式まで評価できる点に注目している。ただし、同サイトの解説は独立した追試結果ではなく、あくまで評価方法を説明したものだ。
不正な方法でテストを通過することを防ぐため、評価環境にも制限が設けられている。READMEでは、既存のSQLiteライブラリや実行ファイルだけでなく、ほかのプログラムに組み込まれたSQLiteの実装も取り除くよう求めている。インターネット接続は認められず、指定された言語以外で実装した場合や複数言語を混在させた場合は、テスト通過率を0%として扱う。また、プログラムがクラッシュした場合や60秒以内に処理を終えられなかった場合も、そのテストは失敗となる。
一方、公開スコアを解釈する際には、使用されたテストの範囲にも注意が必要だ。MultiLangBenchでは、SQLiteの既存TCLテスト約5万1000件のうち、約2万4000件を評価用に変換している。しかし、すべてのテストを実行すると費用が大きくなるため、READMEでは通常の評価に、テスト名が00、01、02で始まる272件の使用を推奨している。全件を使うことも認められているが、その場合は使用したテスト集合を明記する必要がある。OpenAIの発表本文には公表スコアの算出に使ったテスト集合が明示されていないため、87.4%という数字が272件の推奨テストによるものだと断定することはできない。今後、第三者による追試や別モデルとの比較を行う場合には、対象言語だけでなく、テスト集合やAPI費用の算出条件をそろえる必要がある。
COBOLからの移行では、元の動作との完全一致を要求
もう一つの評価では、既存のCOBOLプログラムをC++、Java、Kotlin、Python、Rustのいずれかへ書き換え、元のプログラムと同じ動作を維持できるかを調べている。OpenAIによると、GPT-6.1 Solは低い推論強度で86.6%の成功率を記録し、同条件で5.4%だったGPT-5.6 Solを大幅に上回った。API費用も旧モデルの61%に抑えられており、39%の削減となる。さらに推論強度を高めると、成功率は97.9%に達した。ただし、86.6%と97.9%は推論強度の異なる設定で測定された結果であり、低い推論強度で97.9%を達成したわけではない。
この評価は、MultiLangBenchとは成功の判定方法が異なる。MultiLangBenchでは個々のテストの通過率を集計するのに対し、COBOL移行の評価では、非公開のテストすべてで、外部から観測できる出力がバイト単位で完全に一致することを要求する。一つのプログラムについてすべてのテストを通過して初めて、移行成功として数えられる仕組みだ。したがって、一部の入力で元と同じ結果を返せても、別の入力で結果が異なれば、その移行は成功とは認められない。
OpenAIは、こうした厳密な検証が必要になる例として、COBOLの固定小数点演算を挙げている。COBOLでは、丸めを明示的に指定しなければ、計算結果の余分な小数桁が切り捨てられる場合がある。ところが、移行先の言語で一般的な丸め処理に置き換えてしまうと、プログラム自体は正常に動作しても、計算結果が元のシステムと異なる可能性がある。金融取引や会計処理では、このようなわずかな違いが業務上の問題につながりかねない。単にコンパイルできるコードを生成するだけでは、既存システムを正しく移行したことにはならないというわけだ。
古い業務システムでは、こうした処理の細部が特に重要になる。開発当時の担当者がすでに退職し、設計書や仕様書も十分に残っていない場合、業務上のルールがプログラムの中にしか記録されていないことがある。欠損レコードの扱いや例外処理、数値の丸め方などは、単なる実装上の都合ではなく、長年の業務運用を反映した仕様である可能性がある。COBOLから別の言語への移行では、古い文法を新しい文法に置き換えるだけでなく、こうした暗黙の仕様まで正確に読み取る必要がある。
実際の業務への導入では、言語別の性能と動作の再現性が重要
今回OpenAIが公表した二つの評価は、いずれもAIのプログラミング能力を測るものだが、対象とする作業と合格条件は異なる。その違いを整理すると、次のようになる。
| 評価 | モデルに任せる作業 | 合格の判定基準 | 結果を読む際の注意点 |
|---|---|---|---|
| MultiLangBench | 指定された言語でSQLite互換エンジンを新規実装 | 変更後のデータベースを検証する個々のテストの通過率 | 20言語平均と個別言語の成績を区別し、使用されたテスト集合を確認する |
| COBOL移行 | 既存のCOBOLプログラムを別の言語へ書き換える | 非公開テストすべてで元のプログラムと出力が完全一致した移行の割合 | 推論強度をそろえ、元の処理結果が維持されているかを確認する |
MultiLangBenchで高得点を記録したからといって、既存のCOBOLシステムを同じ成功率で移行できるとは限らない。一方、COBOL移行の評価で97.9%という高い成功率が得られても、あらゆる業務システムを安全に移行できることが証明されたわけではない。今回の数値はいずれもOpenAIによる自社評価であり、実際の企業システムで同等の成果が得られるかは別途検証する必要がある。OpenAI自身も、本番環境への適用には専門家によるレビューに加え、業務ルールや外部システムとの依存関係を踏まえたテストが必要だと説明している。
実際にAIによる開発支援やシステム移行を検討する企業にとっては、平均的なベンチマークスコアよりも、自社で使っている言語やコードに対する性能が重要になる。特に既存システムの移行では、移行前後で同じ入力に対して同じ結果が得られるかを確認し、丸め処理や欠損レコードの扱い、例外発生時の動作まで検証する必要がある。今回の評価結果は、従来AIが苦手としてきた言語でも複雑な開発作業をこなせる可能性が高まったことを示している。ただし、その能力を実際の業務システムの更新につなげるには、生成されたコードの量やテスト通過率だけでなく、既存システムの動作をどこまで忠実に再現できるかが引き続き重要となる。
