OpenAIは、「低リソースプログラミング言語」向けに2つの新しい評価を発表しました。MultiLangBenchでは、モデルに20の言語を使用してSQLite互換のデータベースエンジンをゼロから実装させるよう要求します。もう一つの評価では、COBOLプログラムをC++、Java、Kotlin、Python、またはRustに移行し、既存の動作を維持するよう求められます。公式結果によると、GPT‑6 AstraはMultiLangBenchで平均テスト通過率87.4％を達成し、GPT‑6.1 Solは高推論強度下でCOBOL移行の正確さを97.9％まで向上させました。これはAIのプログラミング能力がPythonやJavaScriptなどの主流言語から、銀行、政府、研究機関で依然として使用されている旧技術スタックへと拡大していることを示しています。ただし、これらの成果はOpenAIが独自に設計・実行した評価に基づいており、87.4％はテストケースの通過率を示すにすぎず、本番環境で使用可能なSQLite実装が完了したことを意味しません。また、97.9％は銀行が人間のレビューなしにコアシステムを移行できることを意味するものではありません。文章作者、出典：OpenAI
「低リソース」は「すでに誰も使っていない」ことを意味しない
AIプログラミング分野において、低リソース言語とは、モデルの学習に使用できる公開コード、ドキュメント、Q&A資料が比較的少ない言語を指し、これらの言語が現実的な価値を欠いているという意味ではありません。
PythonとJavaScriptは膨大なオープンソースエコシステムを有しており、モデルは訓練時に大量のコード、エラーレポート、修正履歴を参照できます。一方、COBOL、Fortran、Visual Basic、OCamlの公開資料ははるかに少なく、その多くは企業内のシステムに閉じ込められています。
一方で、これらの言語は依然として重要な役割を果たしている。OpenAIはIBMのデータを引用し、COBOLがオンラインバンキングシステムの40％以上、オフラインクレジットカード取引の80％、ATM取引の95％を支えていると述べている。また、Fortranは天気予報や核反応炉の安全分析に引き続き使用されている。
これらのシステムを維持する難しさは、文法が古いためだけではありません。元の開発者はすでに退職している可能性があり、ドキュメントも不完全です。実際のビジネスルールはコード内にのみ存在しています。なぜあるプログラムが小数を切り捨てているのか、存在しないアカウントレコードをどのように処理しているのかといった説明は一切なく、それらは金融計算の結果に直接影響を与えます。
したがって、AIが真に証明すべきことは、「COBOLをより現代的なPythonに翻訳できるかどうか」ではなく、移行後も同じビジネスルールが正確に実行されるかどうかです。
最初のテスト：SQLiteを20の言語で再作成する
OpenAIはMultiLangBenchをリリースしました。これは、モデルに指定された言語を使用して、SQLiteと互換性のあるデータベースエンジンを長時間のプログラミングプロセス中に構築することを要求します。
候補プログラムは初期データベースファイルと1つのSQLクエリを受け取り、実行後に変更されたデータベースを生成します。評価システムは、公式SQLite実装を呼び出して、データベースの内容が標準結果と一致しているかを確認します。データベースファイルという共通のインターフェースを通じて、同じ機能セットを言語間で比較できます。
C、C++、COBOL、Fortran、Java、JavaScript、Lean、OCaml、Python、Rust、Visual Basic、Zigなど20の言語をカバーし、モデルがコードベースを整理し、状態を管理し、エラーを処理し、新機能を追加して既存の機能を破壊しない能力を評価します。テストケースはSQLiteの既存のテストスイートを基に改編されています。
最高推論強度において、GPT‑6 Astraの平均テスト通過率は87.4％であり、GPT‑5.6 Solは26.8％です。OpenAIは、Astraがすべての20言語で向上したと述べています：
COBOLは10.9%から72.1%に上昇、OCamlは25.6%から85.8%に上昇、Fortranは21.4%から83.5%に上昇、Visual Basicは27.5%から89.4%に上昇しました。20種類の言語のうち19種類が83%を超え、COBOLは依然として最も難しい言語です。
（ここには、20種類の言語でのインタラクティブな結果モジュールがあり、各言語における各モデルの成績とコストを確認できます。）
これらの数値は正しく理解する必要があります。87.4%は評価用テストケースの平均通過率であり、モデルがSQLiteのすべての仕様を満たす完全で安定したデータベースを生成する確率が87.4%であることを意味しません。残り約12.6%のテスト失敗は、トランザクション、エラー処理、データ一貫性など、本番環境へのデプロイを阻止する可能性のある問題に対応している可能性があります。
これは、SQLiteがAIによって一度に再書き込みできるようになったという証ではなく、モデルが未知の言語でより複雑なソフトウェアを継続的に構築できることを示している。
より安価なLunaだが、Astraとの能力差は依然として明確である
OpenAIは、より低コストのGPT‑6 Lunaもテストしました。これは20言語での平均合格率が40.3％で、GPT‑5.6 Solの26.8％を上回っています。
Lunaの平均APIコストはサンプルあたり約0.77ドルであり、GPT‑5.6 Solは約3.48ドルで、約78%の削減となります。しかし、その能力の向上はAstraのレベルには達しておらず、LunaのCOBOLでの性能は17.1%、Fortranは31.4%、Visual Basicは41.6%です。
この結果は、2つの異なるルートを示しています。Astraはより多くの推論リソースを使用して、複雑なタスクの完了度を最大化します。一方、Lunaは低コストで多くのサンプルを処理し、バッチ処理、初期分析、リスクの低い補助作業に適しています。
コストとは、評価におけるAPI費用の推定に過ぎず、エンジニアによるレビュー、テスト環境の構築、ビジネス承認、エラー修正に要する人的リソースは含まれません。レガシーシステムの場合、モデル呼び出し費用は移行プロジェクトにおける最大のコストとは限りません。
二番目のテスト：コードを移行する際、旧システムの「奇妙な癖」を維持しなければならない
第二の評価要件は、COBOLプログラムをC++、Java、Kotlin、Python、またはRustに移行することです。
テストの重点は、翻訳コードが整洁かどうかではなく、新旧プログラムの観測可能な出力がバイト単位で一致しているかどうかである。すべての非表示テストを通過しなければ、移行結果は成功と判定されない。
OpenAIは固定小数点の例を挙げています：COBOLでは、プログラムが明示的に四捨五入を要求しない限り、余分な小数桁をそのまま切り捨てる可能性があります。モデルが現代的なプログラミングの習慣に従って勝手に四捨五入に変更すると、プログラムは正常に動作しますが、財務結果が変わってしまいます。
低推論強度では、GPT‑6.1 Solの移行精度は86.6％であるのに対し、GPT‑5.6 Solは5.4％にとどまる。また、前者のAPIコスト推定値は39％低い。推論強度を向上させると、GPT‑6.1 Solは97.9％に達し、この評価セットはほぼ飽和状態となる。
这里的97.9%は「OpenAIのこのテストで隠されたケースを完全に通過したプログラムの割合」であり、「任意のCOBOLシステムの97.9%のコードが安全に自動移行可能」という意味ではありません。
実際の銀行システムは、メインフレーム、独自のデータベース、バッチスケジューラー、内部通信プロトコルと接続されており、テストケースでカバーされていない異常フローも存在します。OpenAIも明確に述べているように、本番移行には専門家のレビューが必要であり、実際のビジネスルールおよび依存関係に基づいて再テストを行う必要があります。
MultiLangBenchを公開しましたが、COBOL移行評価はまだ完全には透明ではありません
OpenAIはMultiLangBenchの評価環境、テストスイート、言語別結果をGitHubにアップロードしました。開発者はテスト内容を確認し、他のモデルまたはAgentフレームワークで再実行できます。
これは単に成績表を表示するよりも価値があります。外部からは、モデルがどのSQL機能で失敗したかを観察でき、プロンプト、ツール権限、推論予算、実行時間の影響で成績がどのように変化するかを比較できます。
しかし、公式記事ではMultiLangBenchの公開のみが発表され、COBOL移行評価の完全なプログラムサンプルと隠しテストも公開されたことは言及されていない。後者の97.9%という成績は、MultiLangBenchのように外部から完全に検証および再現することは現在できない。
これらの2つの評価もOpenAIによって設計され、主にOpenAI自身のモデルを比較するために使用されています。これらは、実際の企業コードベース、長期的な保守コスト、セキュリティ脆弱性、パフォーマンスの劣化、および人間によるレビューに要する時間の範囲をまだカバーしていません。したがって、結果はまず、制御されたタスクにおけるモデルの進歩を示すものであり、企業ソフトウェアの近代化問題がすでに解決されたことを最終的に証明するものではありません。
より大きな変化は、AIプログラミングが忘れられたコードの世界に入り込み始めたことである。
過去2年間、AIプログラミング製品のデモは、ウェブサイト、モバイルアプリ、Pythonツールの作成に集中していた。これらのシナリオは直感的だが、大企業が最もコストのかかるソフトウェアの課題ではない。
銀行、保険、政府、研究機関が真正に扱いにくいのは、数十年にわたり運用され、誰も簡単に変更を試みないコードである。これらは最新のトレンドとは言えないかもしれないが、口座処理、税金計算、サプライチェーン、インフラ運用に不可欠なルールを含んでいる。
MultiLangBenchの意義は、モデルの能力が最も一般的な訓練言語から離れ、データが不足し、ツールが古く、エラーのコストが高い技術スタックにソフトウェア工学の手法を移行できるかどうかにあります。
この能力がさらに向上し続ける場合、AIがもたらす最初の変化は「COBOLを一括削除」ではなく、エンジニアが未知のコードを読み解き、テストを補完し、欠落したドキュメントを復元し、ビジネスルールを特定した上で、検証済みのモジュールごとに移行を進める手助けになる可能性が高い。人間の専門家は、どの機能を維持すべきか、そしていつ本格的に旧システムを置き換えるべきかを決定し続けることになる。