
- OpenAIは10月19日、COBOLからC++やJava、Pythonなどへの移行精度が向上したと発表
- GPT-6.1 Solは低推論努力で挙動保持率87%、高推論で98%と報告
- 専門家は「コードの書き換えはシステムの置き換えではない」と指摘
OpenAIが示した移行の成績
OpenAIは10月19日のブログで、COBOLで書かれたコードをC++、Java、Kotlin、Python、Rustといった現行の言語へ、元のソフトウェアの動作を変えずに移行する実験で「大幅な改善」があったと発表した。同社は「すべてのテストが通った場合に限り、移行は成功と見なされる」とも認めており、動作の同一性を最優先の条件に置いている。
評価結果として公表されたのは、GPT-6.1 Solが推論努力の低い設定で87%、高い設定で98%の挙動保持率を記録したという数値である。低い設定での比較ではGPT-6 Astraが約86%、GPT-6 Solが21%、GPT-5.6 Solが5%だった。同社は、COBOLを含む複数の言語でデータベースソフトウェアを構築する能力も改善したとしている。
推論努力とは、モデルが回答前にどれだけ計算段階を費やすかを指す設定である。OpenAIはこれらの結果を「企業が依存するソフトウェアを近代化するチームにとって、より正確で安価なコード移行への前進」と位置づけている。
COBOLが今も支える基幹系
COBOLは「common business-oriented language」の略で1959年に登場した。IBMによれば、オンラインバンキングシステムの40%以上、対面のクレジットカード取引の80%、ATM取引の95%を支えており、社会保障やIRS(米国国税庁)、大半の州のサービスなど政府系システムの土台にもなっている。
ある概算では、COBOLの非効率が米国のGDPに与える年間コストは約1050億ドルに上る。科学技術計算や気象予報などで使われるFortranも同じ構図にある。これらのシステムは重要すぎて壊すリスクを取れず、理解していたプログラマの多くは引退するか亡くなっている。
インペリアル・カレッジ・ロンドンのAlastair Donaldson教授は「まともな人間なら新規開発にCOBOLを使うことはない」と述べている。それでも稼働し続ける資産が残る点が、移行を難しくしている。
Anthropicの参入とIBM株
Anthropicもレガシーシステムに商機を見ている。2月に段階式の「code modernization playbook」を公開し、コーディングエージェントのClaude CodeでCOBOLをJavaやPythonへ移行できると売り込んだ。性能ベンチマークは示さないまま、「COBOL近代化の経済性は変わった」と宣言している。
レガシーシステムの保守で収益の一部を得ているIBMの株価は、この発表後に急落した。もっとも、今回の発表では実際の企業システムの移行を完了した事例は示されておらず、OpenAIの数値も同社自身の評価にとどまる。
コード生成の性能を示す競争が、基幹系の移行という分野に移りつつあることをうかがわせる動きである。
専門家が指摘する隔たり
オランダ・トゥウェンテ大学でソフトウェア進化を研究するVadim Zaytsev准教授は「コードの書き換えはシステムの置き換えではない」と話す。同氏が見た最大のシステムはCOBOL換算で2億5000万行だったが、それでも世界最大ではないという。コードは複数言語にまたがり、多様な形式で保存されたデータや他システムとの連携、人と組織の期待も考慮する必要がある。
デルフト工科大学のArie van Deursen教授は、OpenAIのブログを「表面的」と評した。ベンチマークは比較的単純で明確な課題を扱っており、学習時に近い種類のシステムで試したものだと指摘する。同氏は「保守は近代化よりはるかに容易だ」としたうえで、評価課題は実際の近代化から「桁違いに」離れていると述べた。
Donaldson教授は、最大の課題はコードの書き換えではなく「システムがどう動くかを理解していないこと」だとする。COBOLを書ける人は今やごく少数で、その理解不足が移行を難しくしている。
検証と残る1%の壁
移行の成否を分けるのは検証である。Donaldson教授は、新旧のシステムで同じワークフローを流して挙動が同一か確かめる方法を挙げる。AIに翻訳の根拠を文書化させ、旧言語に詳しい人がレビューする形も考えられる。数学的に正しさを検証する形式検証は、南デンマーク大学のJacopo Mauro教授によれば「多大な作業」が必要だが、自動チェックは人間の確認より良いとされる。
ただしZaytsev准教授は「移行前後でシステムの挙動にわずかな違いがあっても許されない場合が多い」と述べる。AIが99%のコードを処理できたとしても、残る1%が各处に散らばる100万行になり得るという指摘である。
OpenAIの広報Oscar Haines氏はThe Vergeへのメールで、レガシーコードは「まだ解決済みの問題にはほど遠い」と認めている。Anthropicは締め切りまでにコメントを提供しなかった。
| モデル | 挙動保持率 |
|---|---|
| GPT-6.1 Sol | 87% |
| GPT-6 Astra | 約86% |
| GPT-6 Sol | 21% |
| GPT-5.6 Sol | 5% |
The evaluations shown by OpenAI don't address the key difficulty: Breaking up a complex legacy system into smaller units that can be replaced individually.
OpenAIが示した評価は、複雑なレガシーシステムを個別に置き換え可能な小さな単位へ分割するという中心的難しさに触れていない。
今後の見通し
OpenAIはテスト手法の改善とモデルの言語理解の向上を続けるとしており、次に公表される評価が実システムにどこまで近づくかが焦点になる。判断材料としては、複数言語・複数データ形式が混在する実際の基幹系での検証結果、移行後の挙動の同一性をどう保証するかの手順、そして人間によるレビューを前提とした作業分担が明らかになるかどうかが挙げられる。Anthropicがベンチマークを示せば、両社の比較も可能になるとみられる。
日本の開発者・IT企業にとっての意味
金融・公共・製造などの基幹系に残るCOBOL資産の扱いは、日本のIT企業にとっても長年の課題である。AIによる移行の精度が上がれば、現行仕様の調査やテスト設計、ドキュメント作成の工数削減が期待できる。一方、今回示された数値は整えられた課題での評価であり、実システムの移行判断にそのまま使えるものではない。ベンダーや社内提案では「すべてのテストが通ること」を成功条件に据え、新旧の同一ワークフロー比較や旧言語に詳しい人によるレビューを工程に組み込む必要がある。既存の人材が減るなか、AIを全面委任ではなく検証の補助として位置づけるかが実務上の分かれ目になる。
気になる点
- 日本企業のCOBOLシステムでも同じ効果が期待できるのか
- 原文は米国の事例とOpenAIの社内評価が中心で、日本企業のシステムで検証した結果は示されていない。評価対象は比較的単純で明確な課題だったと専門家は指摘しており、そのまま当てはまるとは限らない。ただしAnthropicは2月に移行手順書を公開しており、進め方の考え方は参照できる。
- 移行にかかるコストはどのくらいか
- 原文に具体的な価格や工数の記載はない。OpenAIは「より正確で安価な移行」に進展があったと述べるのみである。COBOLの非効率が米国GDPに年約1050億ドルとの概算はあるが、これは移行費用ではなく、現状を放置した場合の損失の推計である。
- AIが生成した移行コードはどう検証すればよいのか
- 原文では、新旧システムで同じワークフローを流して挙動が同一か確認する方法、AIに翻訳の根拠を文書化させ旧言語に詳しい人がレビューする方法、数学的に正しさを確かめる形式検証が挙げられている。形式検証は多大な作業が必要とされ、現状は人間による検証が不可欠とされる。
用語解説
- COBOL
- 1959年に登場した事務処理向けプログラミング言語。銀行や政府系の基幹システムで今も広く稼働する。
- レガシーマイグレーション
- 古い言語や基盤で動くシステムを、現行の言語・環境へ移し替える作業。
- 推論努力(reasoning effort)
- モデルが回答を出す前にどれだけ計算段階を費やすかを調整する設定。高いほど精度が上がりやすい。
- 挙動保持率
- 移行前後でソフトウェアの動作がどれだけ変わらず保たれたかを示す指標。
- 形式検証
- 数学的手法を用いて、コードが仕様どおりに動作することを計算機的に確かめる技術。
出典
Can AI help solve the COBOL code crisis?
https://theverge.com/ai-artificial-intelligence/1018434/cobol-migration-legacy-code-openai-anthropic
AI導入も顧問も、お任せください
何から手をつけるか、どこまでAIに任せるか。自社の業務に合わせて整理し、導入から運用まで伴走します。相談だけでも構いません。
AI導入について相談する