GPT-6.1 Sol、COBOL移行評価で97.9% 評価の中身と企業導入の課題
2026年10月22日 11:05
OpenAIは2026年10月19日、GPT-6.1 SolがCOBOLプログラムの移行評価で97.9%の成功率を達成したと発表した。既存プログラムの動作を別の言語で再現する能力の向上に加え、20言語で新規開発能力を比較する「MultiLangBench」の結果も公開した。
金融や行政の基幹システムを更新する企業にとって、コード変換の精度と費用は重要な判断材料となる。実際の導入では、共有データ定義、ジョブの実行手順、長年蓄積された業務規則を把握し、移行後のシステム全体を検証する作業も必要になる。
■97.9%は既存プログラムの動作を保つ移行評価
OpenAIのCOBOL移行評価は、既存のCOBOLプログラムをC++、Java、Kotlin、Python、Rustへ書き換え、観測可能な出力がバイト単位で一致するかを調べるものだ。各移行は、非公開テストの全てに合格した場合に成功と数えられる。
同社発表では、推論に割り当てる処理量を低く設定した条件で、GPT-6.1 Solの成功率は86.6%だった。同じ設定のGPT-5.6 Solの5.4%に対して約16倍となり、評価に要したAPIコストも39%低かった。
さらに推論量を増やした条件では、成功率が97.9%に達した。OpenAIは、この結果を評価の上限に近づいたものと説明している。
動作の維持には、計算結果だけでなく、丸め規則やレコード欠損時の処理などを引き継ぐ必要がある。例えば、小数点以下の余分な桁を切り捨てていた処理を、移行先で丸めるように変えると、実行時にエラーが出なくても金額が変わり得る。
OpenAIは、本番システムへの適用には、専門家によるレビューと、業務規則や依存関係を踏まえたテストが必要だとしている。企業が活用する際は、現行システムの出力を比較できるテストデータと、結果の差異を判断する業務知識を用意することが重要になる。
■2500億行のCOBOLと、移行時に守るべき仕様
IBMが2026年4月に更新した解説では、本番環境で使われるCOBOLコードは推定2500億行に上る。同社の2026年2月更新の解説は、COBOLがオンラインバンキングシステムの40%以上、対面クレジットカード取引の80%、ATM取引の95%を支えているとしている。
COBOLはCommon Business-Oriented Languageの略で、業務データ処理を目的に開発された。米国防総省の取り組みを背景に、1959年に発足したCODASYLで開発が進み、最初の仕様は1960年、最初の標準化は1968年だった。
英語の文章に近い構文と、見出し部、環境部、データ部、手続き部という4つの部を基本とする構造を持つ。従来の固定形式のソース記述に加え、レベル番号によるデータの階層定義や、小数点の位置を定めて扱う固定小数点演算が特徴だ。
データ転送では、数値や英数字の項目の定義に従って、内部表現の変換、桁の調整、切り捨てなどが行われる。移行先の言語では、こうした規則を明示的に実装する必要があるため、構文を置き換える作業と、同じ入出力を保つ作業を併せて進めることになる。
1950年代にIBMが開発したFortranも、長期間利用される科学技術計算のコードを抱える。NOAAの予報関連ソフトウェアや欧州中期予報センターの予報システムで使われ、原子炉の安全解析や数値流体力学にも利用されている。こうしたコードの更新では、計算手順とともに、モデルの前提や検証方法を引き継ぐことが重要になる。
■MultiLangBenchは20言語の新規開発能力を比較
MultiLangBenchは、指定されたプログラミング言語でSQLite互換のデータベースエンジンをゼロから構築する評価だ。モデルはコードベースを組み立て、状態やエラーを管理し、既存の機能を保ちながら実装を進める。
評価にはデータベースファイルを共通の入出力として使う。初期データベースにSQLクエリを実行させ、変更後のデータベースを参照用SQLiteで検査することで、実装言語が違っても同じ判定方式を適用する。
公開された評価環境はSQLite 3.40.1を基準とする。SQLiteの既存テスト約5万1000件から約2万4000件をこの形式へ変換し、通常の評価では、そのうち指定された272件を使う設計だ。OpenAIはGitHubで評価環境とテスト群を公開している。
OpenAI発表によると、最大の推論量を使ったGPT-6 Astraの平均テスト合格率は87.4%で、GPT-5.6 Solの26.8%から上昇した。20言語中19言語で83%を超え、COBOLは10.9%から72.1%、OCamlは25.6%から85.8%、Fortranは21.4%から83.5%、Visual Basicは27.5%から89.4%に改善した。
対象言語には、この4言語に加えてC、C#、C++、Common Lisp、Go、Java、JavaScript、Lean、PHP、PowerShell、Python、Ruby、Rust、Scala、Swift、Zigが含まれる。言語ごとの結果を比較することで、自社で使う言語における実装能力を検討できる。
低コストのGPT-6 Lunaは平均40.3%で、全ての対象言語でGPT-5.6 Solを上回った。COBOLは17.1%、OCamlは34.1%、Fortranは31.4%、Visual Basicは41.6%だった。2026年10月19日の発表における推定平均APIコストは1サンプル当たり0.77ドル（約122円）で、GPT-5.6 Solの3.48ドル（約550円）より約78%低い。
■学習資料の少ない言語を支える研究
OpenAIは、COBOL、Fortran、OCaml、Visual Basicなどを、PythonやJavaScriptに比べて学習に使えるコードや文書が少ない言語と位置付けている。企業内で長年使われてきたコードを扱うには、言語の構文に加え、特有のデータ表現やプログラミング慣行を理解する必要がある。
関連研究のMultiPL-Tは、Pythonコードからテストを生成し、別の言語への翻訳を実行テストで検証して、追加学習用のデータを作る手法だ。研究チームはJulia、Lua、OCaml、R、Racket向けに検証済みデータを生成し、それを使って追加学習したモデルの性能向上を報告した。
2026年4月に公開されたプレプリント「COBOL-Coder」では、研究チームがQwen2.5-Coderを基にCOBOL向けの追加学習を行い、コード生成とCOBOL・Java間の翻訳を評価した。研究者らは、自分たちの評価が単一ファイルを対象とし、共有コピーブックやファイル間の依存関係などを扱うには、リポジトリ全体を理解する能力が重要になると説明している。
これらの研究には、生成したコードをコンパイルや実行で確かめ、検証結果を学習や改善につなげるという共通の発想がある。企業での活用でも、入力、期待する出力、判定手順を明確にすることが、AIの作業を評価する土台になる。
■コピーブック、JCL、CICSを含めたシステムの理解
コピーブックは、COPY文を通じてソースへ取り込む共通の記述をまとめたもので、データレイアウトの共有に使われる。一つの定義が数十、数百のプログラムで利用される場合もあり、変更時には、それを参照するプログラムへの影響を調べる必要がある。
IBMメインフレームのバッチ処理では、JCL（Job Control Language、ジョブ制御言語）が、実行するプログラム、ファイルやデータセットの割り当て、処理の順序などを定める。プログラムを移行する際には、前後のジョブが受け渡すデータや、運用上の実行条件も確認することになる。
オンライン処理では、CICS（Customer Information Control System）などのトランザクション処理環境も重要になる。CICSを利用するアプリケーションの移行では、業務ロジックとともに、データの整合性、資源の共有、処理の確定や取り消しといった取引管理の仕組みを引き継ぐ必要がある。
長年の改修を経たシステムでは、業務規則がコードにだけ残り、文書や担当者の記憶から読み取れる情報が限られる場合もある。更新作業では、コードから規則を抽出し、業務担当者と確認して、移行後の期待動作として記録することが求められる。
Factoryが2026年4月1日に公表したLegacy-Benchは、既存コードのバグ修正、機能追加、言語間移行などを評価した。同社によると、給与計算の課題では29件中24件のテストに合格しながら控除額を誤る例があり、どのモデルも解けなかった44課題のうち31件がCOBOLだった。
この種の誤りを見つけるには、コンパイルの成否に加え、金額、桁位置、空白、文字コードなどを含む出力の比較が役立つ。プログラム単位の検証を、ファイルの受け渡しや取引処理を含むシステム全体の検証へ広げることが、企業導入の重要な工程となる。
■人材不足と移行計画をめぐる課題
COBOLの保守人材について、専門媒体TechChannelは2019年10月の記事で、プログラマーの平均年齢を58歳、年間の退職割合を約10%と伝えていた。経験者が持つ業務知識の記録と、後継者への引き継ぎは、システム更新と並行して進める課題となる。
Deloitteの委託でForrester Consultingが2020年6月に実施した調査では、メインフレームの意思決定に関わるビジネス・IT担当者261人の71%が、自社のメインフレームチームは人員不足だと回答した。同調査は、人材の育成や再教育にも時間と資源が必要になると指摘している。
ACT-IACが2024年12月23日に公表した連邦政府向けレガシーコード更新の報告書も、人材不足を課題に挙げた。報告書は、2020年の報道にメインフレーム開発者の欠員が8万4000件とする記述があったことを紹介している。
Gartnerは2026年6月18日、同年に始まるメインフレーム撤退プロジェクトの70%以上が、意図した効果を得られないとの予測を公表した。同社は生成AIツールへの過大な期待を理由に挙げ、既存のメインフレーム上での改善も含め、システムの規模や複雑さに応じて更新方法を選ぶよう提言している。
■競合各社は分析から検証までの支援を拡充
IBMのwatsonx Code Assistant for Zは、アプリケーションの分析、説明、リファクタリング、COBOLからJavaへの変換、検証を支援する。2025年12月に登場した2.8系では、Model Context Protocol（MCP）に対応したツールを通じ、アプリケーションのメタデータ取得や依存関係の影響分析を組み合わせる仕組みを導入した。
IBMの日本語公式資料によると、2026年の更新では、コード説明時のコピーブックやJCLのINCLUDEファイルの展開、大規模COBOLプログラムの文書生成なども拡充された。実際のコードや関連情報を開発支援ツールへ渡せることは、システム全体を理解する上で強みになる。
AWSは2025年5月15日、AWS Transform for mainframeの一般提供を開始した。同社はメインフレーム更新向けの初のエージェント型AIサービスと位置付け、分析、文書化、プログラムの分解、変換などを支援するとしている。AWSはメインフレーム更新事業の顧客例として、Transamerica、Allianz、Marriott Hotelsを挙げている。
GitHubは、Copilotを使ったCOBOLコードの説明、業務ロジックの整理、テスト計画の作成、移行先コードのテスト生成などの手順を公開している。Anthropicも2026年2月23日の解説で、Claude Codeによる依存関係の把握や文書化を通じ、移行前の探索・分析にかかる費用を減らせると主張した。
Devinを開発するCognitionは2026年4月8日、ラテンアメリカ最大の民間銀行Itaú UnibancoなどでのCOBOL更新事例を公表した。同社によると、同行の納税者番号に関するリファクタリングでは本番エラーがゼロで、同行の移行作業では人員を増やさず5〜6倍の高速化を達成した。Cognitionは文書化、バッチ移行、大規模リファクタリングを実績として挙げている。
■企業は変換精度と検証体制を併せて評価
境界が明確で、入出力や仕様を把握できるCOBOLプログラムは、AI支援移行を試す候補になる。対象を絞り、現行コードと移行後コードを同じデータで実行して比較すれば、自社の業務における精度や作業時間を評価できる。
相互依存の強いシステムでは、コピーブックの参照関係、ジョブの実行順序、データの流れ、取引の境界を整理する作業が重要になる。専門家の知識を文書とテストへ移し、変換作業とシステム全体の検証を計画に組み込むことが、AI活用の前提となる。
公開されたMultiLangBenchは、各社が同じ条件で評価するための比較材料となる。ほかのモデル提供企業も結果を公表すれば、SWE-benchのような共通の比較軸へ育つ可能性がある。企業側も、公開評価と自社システムの試験結果を組み合わせて、モデルと開発支援環境を選べるようになる。
OpenAIの今回の発表は、AIによる開発支援の対象が、現代的なソフトウェア開発から、金融や行政を支える長寿命のコードへ広がる動きを示すものだ。コード変換、業務知識の整理、実行環境との統合、継続的な検証を組み合わせることが、企業システムの更新を進める鍵になる。
元記事: GPT-6 Cracks COBOL: 97.9% Migration Accuracy Shifts AI Bottleneck from Code to Enterprise