OpenAIは2026年10月19日、学習データに占める割合が少ないプログラミング言語に関する新たな評価結果を発表した。OpenAIとCOBLに関する研究は、SQLite互換エンジンの構築と既存プログラムの移行を含む。自社テストでは成績が向上しているが、これらのシステムを保守する担当者にとって重要なのは、一見モダンなコードが変えてしまいかねないルールも含め、ソフトウェアの動作を維持することだ。
2つの評価は何を測定するのか
OpenAIは2種類の能力を区別している。MultiLangBenchは、モデルが20のプログラミング言語で動作するソフトウェアをどれだけ構築できるかを測定する。もう一方の評価は、COBLプログラムを出力を保持したまま変換する能力を対象とする。これらはOpenAIが公開したベンチマークであり、銀行システムの移行完了を報告するものではない。このアナウンスは、OpenAIのエージェント的コーディング分野における進捗を示すもので、具体的なタスクと成功基準を可視化している。
MultiLangBenchでは、OpenAIの発表によると、最高の推論レベルでGPT-6 Astraが平均87.4%のテスト通過率を記録し、GPT-5.6 Solの26.8%を大きく上回った。COBLの移行評価では、GPT-6.1 Solが低推論レベルで86.6%を達成し、前モデルの5.4%から大幅に改善。高推論レベルでは97.9%に達する。MultiLangBenchではGPT-6 Lunaが40.3%を記録している。各テストは異なる基準で設計されており、これらの数値をひとつの順位表として並べることはできない。
Our latest model advances bring stronger capabilities for building and migrating software in low-resource programming languages such as COBOL, Fortran, and Visual Basic.
，OpenAI (@OpenAI) October 19, 2026
These languages power software that banks, governments, and businesses depend on. Progress here means… pic.twitter.com/Mulo5P3iCO
企業へのAI導入を注視する立場からすれば、システムに対してどんな問いを立てているかを理解することが肝心だ。新しい関数を書くことと、長年稼働しているプログラムを置き換えることは、重なる部分はあっても、リスクの性質がまったく異なる。後者の場合、合理的に見える単純化が、どこにも文書化されていないルールを変えてしまう恐れがある。評価には、新しいコードが何を維持すべきかという知識も必要になる。
再構築したSQLiteエンジンの検証方法
公開リポジトリ「MultiLangBench」はそのプロトコルを説明している。モデルはSQLite 3.40.1のドキュメントを受け取り、指定された言語で実行可能ファイルを生成しなければならない。各テストケースは初期データベースから始まり、候補プログラムにクエリを適用し、リファレンス実装を使って結果を検証する。これにより、コードを読んで妥当に見えるかどうかだけで判断するのではなく、共通のインターフェースを通じて異なる言語で書かれた実装を評価できる。
READMEは利用可能なデータと推奨サンプルも区別している。元のテストスイートから約2万4000件のケースが変換されているが、コスト上の理由から272件のテストのサブセットが推奨されており、明示すれば拡張したテストも許容される。リポジトリに収録されているケース数を、各評価で必ず実行された件数と同一視するのは正確ではない。この詳細が重要なのは、サンプル、実行環境、実行ルールが明示されて初めて、パーセンテージが比較可能になるからだ。
実行条件としてインターネットアクセスなしの環境が指定され、モデルが再利用できるSQLiteのコピーも除去される。これらは観察対象の能力を分離するために設計された条件だ。ベンチマーク間の比較では、利用できるツールの範囲が結果の一部を成す。ここで問われているのは実装を構築する能力であり、元のプログラムを呼び出せるようにすればタスクの性格が変わり、スコアの情報価値が下がる。
出力の保持が再実装より難しい理由
我々の読み解きでは、最も注目すべき基準はルールの継続性にある。プログラムはコンパイルが通り、高速に応答し、有効なファイルを生成しながらも、エッジケースを異なる方法で処理することがある。例として考えてみると、空のフィールドが「要確認」を意味するアーカイブがあったとする。その値を常にゼロに変換する書き換えは、多くの通常テストをクリアしながら、未完了の案件だけの意味を変えてしまう恐れがある。
以前の出力との比較は類似した差異を特定するために行うものであり。旧来のルールが正しかったかどうかをそれ単独で決定するわけではない。本稿の見解では、既存の動作を再現することと、どの動作を意図的に変更するかを選ぶことは、別々の作業として区別される。両者を混在させると、ある差異が移行時の誤りなのか意図的な変更なのかを判断しにくくなる。特に判断がプログラミング言語の文法ではなくビジネスルールに依存する場合、人間による確認は依然として不可欠だ。
OpenAIが示した具体例によれば、COBOLの固定小数点演算は、明示的な丸め処理が指定されていない場合に超過する小数桁を切り捨てる。その部分を丸め処理付きで書き直すと、実行エラーなしに異なる数値が生じる可能性がある。このため移行テストでは観測可能な出力のバイト単位の一致を要求し、すべてのテストに合格した場合にのみ移行成功とみなされる。「成功」の定義は単なるコンパイル成功よりも厳格だ。
ベンチマークは信頼性テストの代替になるか
実は、SQLiteの公式ドキュメントを参照すると、データベースの堅牢性検証の範囲がいかに広いかがわかる。メモリ枯渇、読み書きエラー、クラッシュ、電源断、破損ファイル、リグレッションに関するテストが記述されている。クエリセット上で観察される機能的な互換性は有用な評価軸の一つだ。しかし環境が障害を起こしたときにデータと状態を保護する能力は別の評価軸であり、そうした条件に特化したテストが必要となる。
本稿の見解では、このベンチマークは不足している検証項目を特定する際に最も有用になる。アーカイブシステムであれば、たとえば障害後の復旧や、そのシステムに問い合わせるアプリケーションとの互換性が重要な検証項目となる。これらは設計すべき検証であり、研究モデルに帰属させる結果ではない。公開されたテストスイートは機能の一部を測定するものであり、代替品の信頼性を評価するには元のシステムの障害や依存関係を前提とした追加テストが必要だ。
比較を再現可能にする条件とは
リポジトリは結果を二つの要素で定義している。テスト合格率とAPIインターフェース呼び出しのコストだ。再現を試みる場合は、モデル、サンプル、設定、実行条件、そして実際の費用を明示する必要がある。本稿の見解では、これらの要素を保存しておくことで、ある差異がより優れたモデルによるものなのか、より多いコストによるものなのかを判断できる。最終的なパーセンテージのみを記録すると、比較を再現するために必要な情報が失われる。
推論レベルにも注意が必要だ。COBOL移行において、86.6%と5.4%はいずれも低レベルの設定に対応し、97.9%はより負荷の高い設定に対応するが、本文中に明確なラベルで特定されているわけではない。これらを混同すると、明示された差異が消えてしまう。ソフトウェアへのAI適用を評価するにあたり、精度と投入リソースの比率は常に可視化されていなければならない。特に自社プロジェクトでどの設定を試すかを判断する場面では、その透明性が欠かせない。
OpenAIとCOBOL: 要点整理
- 確認済み: 10月19日の結果公開と、MultiLangBenchリポジトリへのアクセス可能な状態。
- 未実証: スコアが銀行の本番環境における移行の信頼性と同等であること。
- 継続注視: 外部による再現、宣言されたサンプル、企業システム固有ルールの検証。
より広い視点からの考察
本稿の見解では、最も注目すべき変化は、レガシーソフトウェアに関する作業の一部を可視化できるようになったことだ。公開されたテスト環境によって、具体的な入力、検証項目、エラーについて議論できるようになった。AI評価の独立した検証というテーマが、別のラボからの資料であっても依然として重要である理由はここにある。手法へのアクセスと独立した確認は、それぞれ別の段階だ。
今後注視すべきシグナルは、再現可能な実装、文書化された欠陥、そして記述にかかる時間と検証に要する時間の比較だ。ベンチマークで最高点に近いスコアが出た場合。それは産業上の問題が最終的に解決されたことを示すのではなく、テストをより難しくすべき指標かもしれない。基幹システムを維持する人々にとって、有意義な進歩は受け入れて説明できる変更の質によって測られる。
