エラーは出ないのに、金額が変わる。COBOL書き換えで本当に怖いところ

• 怖いのは落ちることではない。動いたまま金額が変わること
• COBOLは20言語でいちばん難しいまま。安いモデルでは17.1%
• OpenAI自身が「本番に当てるには専門家のレビューが必要」と書いている

OpenAIが2026年10月19日、COBOLやFortran、Visual Basicといった言語での能力が上がったと発表した。

数字は大きい。ただ発表文のなかでいちばん重要なのは別のところだと思ったので、そこから書く。

本当に怖いところ

発表文に、こういう一節がある。

COBOLの固定小数点演算は、明示的に丸めを指定しない限り、余分な小数の桁を切り捨てる。それを代わりに丸めるよう書き換えると、エラーなく動作しながら、異なる金融上の結果を生むことがありうる。

ここが本題だ。

COBOLは切り捨てる。新しい言語に書き直すとき、ふつうに書くと四捨五入になることがある。

すると、こうなる。

• テストは通る。例外も出ない
• 画面も正常。ログもきれい
• だが計算結果が1円ずつ違う
• それが何百万件に積み上がる

落ちてくれたほうがまだ良い。落ちれば気づく。

これは前に書いた話と同じ構造だった

先週、PHP5のコードはPHP8でも構文チェックが通る。だから危ないという記事を書いた。

構造が同じだ。機械が「問題なし」と言う範囲が、安全の範囲より広い。

そして発表文には、もう1つ大事なことが書かれていた。業務のルールがコードにしか残っていない場合があるという話だ。

資料は不完全かもしれず、元の開発者は会社を去っているかもしれず、重要な業務ルールはコードの中にしか存在しないかもしれない。

切り捨てが仕様なのか、昔の都合なのか。それを知っている人がもういない。だから移行が難しい。

では、数字はどうだったか

評価は2つある。数字は正確に見たほうがいいので、分けて置く。

1. COBOLを他の言語へ移す

COBOLのプログラムをC++、Java、Kotlin、Python、Rustのいずれかへ、挙動を保ったまま移せるかを測るものだ。

しかも低い推論のほうは、API費用が従来の61%になっている。

判定はかなり厳しい

この数字が意味を持つのは、合格の条件が厳しいからだ。

これらの挙動が保たれているかを調べるため、観測可能な出力についてバイト単位での一致を要求する隠しテストで評価する。すべてのテストが通った場合にのみ、移行は成功とみなす。

「だいたい合っている」は0点になる。1バイト違えば落ちる。先に書いた丸めの話は、この基準でなら捕まる。

2. ゼロからSQLiteを作る（20言語）

もう1つはSQLite互換のデータベースを一から作らせるという評価だ。

発表文に、こうある。20言語のうち19言語で83%を超え、COBOLがいちばん難しいまま72%。

伸びてはいるが、COBOLだけ最後まで残っている。

見落としやすい点：安いモデルでは話が違う

ここは注意したい。同じ評価で、安いほうのモデル（GPT-6 Luna）はこうなっている。

• 20言語の平均 — 40.3%
• COBOL — 10.9% から17.1%
• API費用は1件あたり$0.77（従来は$3.48。約78%安い）

平均40.3%と聞くと使えそうに思える。だがCOBOLは17.1%だ。

平均の数字で判断すると外す。自分が使う言語の行を見る必要がある。機能の一覧には効く条件が書かれていないという話を前日に書いたが、これも同じで、平均には条件が隠れている。

なおOpenAIは評価の仕組みとテストをGitHubで公開し、言語ごとの結果も出している。自分の言語の数字を見られるようにしてある点は良い。

OpenAI自身が付けている但し書き

97.9%という数字のすぐ後に、こう書かれている。

このような挙動を保つ能力は、古いシステムを保守し新しくするチームにとって有用である。ただし本番のソフトウェアに適用するには、専門家によるレビューと、そのシステムの業務ルールおよび依存関係に対する試験が、依然として必要である。

作った側がこう書いているのだから、ここは重く取る。

97.9%は「人がいらない」ではなく「人が見る対象が絞れる」という意味になる。

なぜCOBOLがいま話題なのか

発表文が挙げている数字が分かりやすい。COBOLが支えているとされる範囲だ。

• オンラインバンキングの40%超
• 対面のクレジットカード取引の80%
• ATM取引の95%

Fortranについては天気予報と原子炉の安全解析が挙げられている。

つまり止まると困るものが、学習データの少ない言語で動いている。だから手を付けたい。そしてだから慎重でなければならない。

移すか、書き直すか

前日に古いコードを書き直すか移すかを書いた。今回の発表を読んで、判断の軸が1つ増えたと思う。

挙動の正解を、いま作れるか。

1. いまのシステムの入出力を、先に大量に記録する。これが正解になる
2. 書き換えたものに同じ入力を流し、出力を1バイト単位で比べる
3. 合わない件だけを人が見る

今回の評価がやっているのは、まさにこれだ。正解の作り方が先で、道具は後になる。

逆に正解を用意しないまま書き換えると、丸めの違いは一生見つからない。どこまで任せられるかにも書いたが、確かめ方のないものは任せられない。

まとめ

• 発表は2026年10月19日。COBOL、Fortran、Visual Basicなどが対象
• COBOL移行は低い推論で86.6%、高い推論で97.9%（従来は5.4%）
• 判定は観測可能な出力のバイト単位の一致。全テスト通過のみ成功
• ゼロから作る評価は20言語平均87.4%。COBOLは72.1%で最難
• 安いモデルではCOBOLは17.1%。平均40.3%で判断すると外す
• OpenAIが「本番に当てるには専門家のレビューと試験が必要」と明記
• 本当の危険は切り捨てと丸めの違い。エラーが出ないまま金額が変わる
• やるなら先に正解（いまの入出力）を記録する

出典

• OpenAI「Advancing coding in low-resource programming languages」（2026年10月19日。両評価の数値、言語別の結果、判定基準、固定小数点に関する記述、本番適用についての注意。引用の日本語は筆者による訳）
• COBOLやFortranの利用範囲に関する数値は、同発表が外部の資料を引用して挙げているもの

本記事は2026年10月20日に発表文を取得して確認した内容に基づく。数値はOpenAI自身の評価によるものであり、第三者による検証ではない。移行の判断は、対象システムの業務ルールと依存関係を確かめたうえで行うこと。本記事は法的な助言ではない。