開発レポート

OpenAIがCOBOL移行の評価を公開、GPT-6.1 Solは正答率97.9%に

OpenAIがCOBOLやFortranなど学習データの少ない言語でのコーディング性能を公開しました。COBOLを他言語へ移す評価でGPT-6.1 Solは最大97.9%、前世代は5.4%でした。評価用ベンチマークもGitHubで公開。ただし本番投入には専門家のレビューが必要としています。

OpenAIは2026年10月19日(米国時間)、COBOLやFortran、Visual Basicのように公開コードが少ない言語でのコーディング性能をまとめた研究報告を公開しました。COBOLのプログラムをJavaやPythonなどへ動作を変えずに移す評価で、GPT-6.1 Solは正答率86.6%(推論の深さ「低」)、深めの設定では97.9%に達し、前世代のGPT-5.6 Solの5.4%から大きく伸びています。メインフレームのCOBOL資産を抱える金融・保険・公共系のシステム部門やSIerにとって、AIを移行作業の「下書き役」に使えるかを判断する材料になる発表です。

なぜCOBOLやFortranが課題だったのか

大規模言語モデル(LLM)は、学習データとなる公開コードが多い言語ほど得意です。PythonやJavaScriptはGitHubに膨大なコードがありますが、COBOLやFortranは企業の社内に閉じたコードが中心で、公開されている量が桁違いに少なく、これまでのモデルが苦手としてきました。OpenAIも、開発者や企業顧客から「コーディングモデルはこれらの言語で苦戦する」という声を受けて取り組んだと説明しています。

一方で、こうした言語は社会の基盤を支えています。OpenAIはIBMの数字を引き、COBOLが「オンラインバンキングの40%超、対面のカード決済の80%、ATM取引の95%」を支えていると紹介しています。さらに古いシステムは、ドキュメントが不完全で、書いた人はもう社内におらず、業務ルールがコードの中にしか残っていない、という状態になりがちです。AIで読み解いて移行したいという需要が大きい一方、間違えたときの影響も大きい領域です。

2つの評価と結果

OpenAIは今回、性質の違う2つの評価を用意しました。

MultiLangBench(ゼロから作る力)

SQLite互換のデータベースエンジンを、指定された言語でゼロから実装させる評価です。データベースとSQLを入力に与え、出力された結果を本物のSQLiteと照合するため、言語が違っても同じテストで比べられます。対象はC、COBOL、Fortran、Lean、OCaml、Visual Basic、Zigなど20言語です。

最大の推論設定での平均合格率は、GPT-5.6 Solが26.8%、GPT-6 Lunaが40.3%、最上位のGPT-6 Astraが87.4%でした。Astraは20言語中19言語で83%を超えていますが、COBOLだけは72.1%と最も低く、依然として最難関の言語です。軽量なLunaは1サンプルあたりのAPIコストが推定0.77ドルで、GPT-5.6 Solの3.48ドルより約78%安いとしています。

COBOL移行評価(動作を変えずに移す力)

実務により近いのがこちらです。COBOLのプログラムをC++、Java、Kotlin、Python、Rustのいずれかに書き換えさせ、非公開のテストで出力がバイト単位まで一致するかを確かめます。すべてのテストに通ったときだけ成功と数えます。

COBOL移行評価の正答率
出典: OpenAI公式ブログ(2026年10月19日)

OpenAIが具体例として挙げているのが、お金の計算です。COBOLの固定小数点演算は、明示的に丸めを指定しない限り、桁あふれした小数を切り捨てます。移行先で四捨五入してしまうと、プログラムはエラーなく動くのに金額が1円単位でずれる、ということが起こり得ます。今回の評価はこうした「動くけれど結果が違う」失敗も落とす作りになっており、ただコンパイルが通るかを見る評価より厳しいものです。なお、COBOL移行評価にGPT-6 Astraの数字は載っておらず、何本のプログラムで測ったのかも書かれていません。

日本の読者にとっての意味

日本でも、銀行の勘定系や保険、自治体の基幹業務などで、メインフレーム上のCOBOLが今も多く動いています。経済産業省が2018年のDXレポートで「2025年の崖」と呼んだように、古いシステムの維持と担い手の不足は国内でも長く課題になってきました。COBOLを読めるエンジニアが減るなか、AIが仕様の読み解きや移行の下書きを高い精度でこなせるなら、移行計画の見積もりや進め方が変わる可能性があります。

ただし、今回の数字をそのまま自社に当てはめるのは早いと考えられます。評価に使われたのは単体のプログラムで、実際の基幹システムにあるJCL(ジョブ制御言語)やCICSなどのトランザクション基盤、データベースとの結び付き、各社独自の拡張や帳票は評価の外です。日本の現場で多い全角文字や独自の文字コードの扱いについても触れられていません。OpenAI自身も、本番のソフトウェアでは「業務ルールや依存関係に照らした専門家のレビューとテストが引き続き必要」と明記しています。

今回の評価で分かることと分からないこと
出典: OpenAI公式ブログ(2026年10月19日)をもとに編集部作成

AIを使う場合も、移行の正しさを担保するのは「旧システムと新システムに同じ入力を与えて出力を突き合わせる」テストです。今回OpenAIがやったことはまさにそれで、AIの導入より先に、比較テストの仕組みと十分なテストデータを用意できるかが成否を分けるはずです。

使えるモデルと注意点

OpenAIは「最新モデルをAPI経由で、チームが使っている言語のコーディング作業で試せる」としています。評価の仕組みとテスト、言語別の結果はGitHubのMultiLangBenchで公開されています。ChatGPTやCodexでの扱いについて、本文に具体的な記載はありません。

API利用の前提として、GPT-6.1 Solの料金や仕様は公開時の記事にまとめています。また、OpenAIは旧モデルのGPT-4o/4.1のAPI提供を2027年1月に終えると発表済みで、移行支援ツールを古いモデルで組んでいる場合は乗り換えも必要です。顧客の基幹コードを外部APIに送ることになるため、契約上の守秘義務やデータの扱いを事前に確認しておく必要があります。

次にやること

  • 手元のCOBOL資産から、入出力が明確な小さなバッチを1本選び、GPT-6.1 Solで移行を試して、旧システムとの出力比較で差分を確かめる
  • MultiLangBenchのリポジトリで、自社が使う言語(COBOL、Fortran、Visual Basicなど)の言語別結果とテストの作りを確認する
  • 移行プロジェクトを計画中なら、AIの利用以前に、新旧の出力を自動で突き合わせるテストの仕組みとテストデータの準備状況を点検する

出典

関連記事

開発レポートの記事 →