--- title: "COBOL移行と生成AI：OpenAIの正答率86.6%の読み方と発注前の確認事項" url: "https://www.issoh.co.jp/column/details/18815/" published: 2026-10-23 updated: 2026-10-23 categories: ["DX"] publisher: "株式会社一創" --- # COBOL移行と生成AI：OpenAIの正答率86.6%の読み方と発注前の確認事項 生成AIでCOBOLをJavaやPythonへ移行する話が、2026年10月にもう一段現実味を帯びました。OpenAIが10月19日に公表した評価で、GPT-6.1 SolがCOBOLプログラムの移行で正答率86.6%を出したためです。ただしこれはOpenAI自身のベンチマークで、合格の条件も評価に使ったプログラムも自社の資産とは違います。この記事では、数値が何を測ったのかを一次情報で確かめ、COBOL移行を外部に相談する前に確認する事項、契約に入れる受け入れ基準、生成AIを主軸にしてよい案件と見送る案件の分け方までを、発注する側の立場で整理します。 ## まとめ：生成AIのCOBOL移行は出力一致の検証を発注者が握れば任せられる OpenAIの評価は、COBOLプログラムを別の言語へ移し、隠されたテストで出力がバイト単位まで一致するかを見たものです。86.6%は「1本ずつのプログラムを、正解の出力と比べて移せた割合」であり、数千本のプログラムとJCL、データベース、画面がつながった基幹システムを丸ごと移せる確率ではありません。 発注者がやるべきことは、ベンダーの公表値を見積りの根拠にすることではなく、自社のプログラムで同じ物差しを作ることです。現行の本番出力を正解として取り出し、新旧の出力が一致したら合格という受け入れ基準を契約に書く。この基準を発注者側が持っていれば、移行の作業そのものは生成AIを使う開発会社に任せられます。正解の出力が取れない案件では、まず生成AIを主軸にしないほうが安全です。 ## OpenAIが2026年10月に公表したCOBOL移行評価の中身と数値の意味 数値だけが報道で広がると、条件が抜け落ちます。[OpenAIの発表「Advancing coding in low-resource programming languages」](https://openai.com/index/low-resource-programming-languages/)には、評価が2種類あること、それぞれの合格条件が書かれています。 ### GPT-6.1 Solの正答率86.6%と97.9%が測ったプログラム単位の移行 COBOL移行の評価は、COBOLプログラムをC++、Java、Kotlin、Python、Rustのいずれかへ、動作を保ったまま移すよう求めるものです。GPT-6.1 Solは推論量を抑えた設定（low reasoning effort）で86.6%、推論量を増やした設定で97.9%に達しました。前の世代のGPT-5.6 Solは同じ低い設定で5.4%で、OpenAIはAPIコストが61%で済んだとしています。 97.9%について、OpenAI自身が「評価が飽和に近い」と書いている点は見落とせません。問題が易しくなりすぎて差が付かなくなった、という意味です。つまりこの評価で測れる範囲の課題はほぼ解けるようになった一方、評価に入っていない難しさが実案件に残っているかどうかは、この数値からは分かりません。 ### 出力のバイト単位一致を合格条件にした理由と固定小数点の切り捨て 合格の条件は厳しめです。観測できる出力がバイト単位で一致することを求める非公開のテストを使い、全テストに通ったときだけ移行成功と数えています。1件でも出力が違えば失敗です。 OpenAIがこの条件を選んだ理由として挙げているのが、COBOLの固定小数点演算です。COBOLは、端数の丸めを明示しない限り、桁あふれした小数部を切り捨てます。移行先のコードが善意で四捨五入すると、エラーは出ないまま金額だけが変わります。実行できるか、テストが動くかではなく、帳票や送金データの1桁まで同じかで判定しないと、こうした差は見つかりません。発注者が受け入れ基準を作るときも、この考え方をそのまま借りるのが近道です。 ### MultiLangBenchのCOBOL 72.1%との差が示す新規構築と移行の違い 同じ発表には、もう1つの評価があります。[GitHubで公開されたMultiLangBench](https://github.com/openai/MultiLangBench)は、SQLite 3.40.1互換のデータベースエンジンを、指定した言語で一から作らせる評価です。READMEによると、SQLiteのTCLテスト約5万1千件のうち約2万4千件を変換し、標準の評価では先頭が00・01・02の272件を使います。60秒で終わらないテストは失敗扱いです。 この評価でGPT-6 Astraは20言語の平均で87.4%を出しましたが、COBOLは72.1%で20言語のうち最も低い値でした。モデルも課題も違うので単純には比べられません。それでも読み取れるのは、COBOLで新しいものを作るより、既にあるCOBOLの動きを別言語に写すほうが、今のモデルには扱いやすいということです。移行では元のプログラムそのものが仕様書の代わりになるためです。 ## ベンダー自社ベンチマークを自社のCOBOL資産に当てはめる前の注意点 OpenAIは、本番のソフトウェアに当てはめるには専門家のレビューと、業務ルールや依存関係に照らしたテストが引き続き必要だと発表の中で断っています。数値を自社に持ち込む前に、評価に書かれていない条件を洗い出しておきます。 ### 評価問題が非公開のため規模やJCL・DB接続の条件が分からない点 MultiLangBenchはテストまで公開されていますが、COBOL移行の評価について、発表文に問題やテストを公開したという記述はありません。そのため、1本あたりの行数、COPY句で読み込む共通定義の量、JCLで組まれたジョブの有無、Db2などデータベースへのアクセスやCICSの画面処理を含むかどうかは、外から確かめられない状態です。 国内の基幹系COBOLでは、このどれもが移行の難所になります。自社の資産がバッチ処理中心で、ファイルを読んで集計し、ファイルを書く形のプログラムが大半なら、評価の条件に近い可能性があります。画面と業務ロジックが絡み合ったオンライン処理が中心なら、86.6%を目安にする根拠は薄いと考えてください。 ### 1本のプログラム移行と数千本のシステム移行で成功率が変わる理由 仮に1本あたり9割近く移せても、システム全体の話は別です。プログラム同士は共通の定義やファイルを介してつながっており、1本の差分が下流のジョブ全体の出力をずらします。1,000本あれば、1割の失敗でも100本を人が直して再検証することになります。 移行の手間の大半を占めるのは、失敗した1割を見つけて直す工程です。だからこそ評価の合格率より、「どのプログラムが不一致かを機械的に特定できる仕組み」が先に要ります。リライト・リホストなど移行手法ごとの違いは[マイグレーションとリプレイス・モダナイゼーションの違い](https://www.issoh.co.jp/column/details/13177/)で整理しています。 ### 製品のベンチマーク値と自社で測った一致率を混同しない提案資料の読み方 変換ツールやAIサービスの提案資料には、変換率や工数削減率が並びます。読むときに確かめるのは、分母が何か、合格を何で判定したか、誰が測ったか、の3点です。分母が「変換できた行数」なのか「出力が一致したプログラム数」なのかで、同じ90%でも意味はまるで変わります。 実務では、提案資料の数値は候補を絞る材料にとどめ、採否は自社のプログラムで測った一致率で決めます。工程ごとの削減の出方や、ベンダー公表値の分解の仕方は、実装者向けの[生成AIモダナイゼーションの実装手順と費用の読み方](https://www.issoh.co.jp/tech/details/18618/)で詳しく扱っています。 ## 生成AIを使うCOBOL移行で発注者が見積り前に確かめる事項 生成AIを使うかどうかで、発注者の準備は大きくは変わりません。変わるのは、正解の出力を早い段階で用意できるかが、見積りと工期を左右するようになった点です。 ### 移行先言語をJava・Python・Kotlinなどから選ぶ基準と保守要員 OpenAIの評価が対象にした移行先は、C++、Java、Kotlin、Python、Rustの5言語です。移行先を決める基準は、生成AIの得手不得手より、移行後に誰が保守するかです。社内や取引先の開発会社にJavaの技術者が多いならJava、データ処理やバッチの比重が高く、分析の担当者も触るならPythonが候補になります。 注意したいのは金額の扱いです。COBOLの10進の固定小数点を、移行先で浮動小数点型に置き換えると端数がずれます。JavaならBigDecimal、PythonならDecimalのように10進演算の型を使う方針を、言語を決める段階で開発会社と合意しておいてください。COBOLとJavaの金額表現の違いは[COBOLが今も使われ続ける理由とJavaとの比較](https://www.issoh.co.jp/column/details/1937/)でも触れています。 ### 正解の出力を誰が用意するか：現行の本番データとバイト一致テスト 生成AIによる移行の検証は、現行システムに入力を与えて出た出力を正解とし、新しいプログラムの出力と突き合わせる形になります。この正解を作れるのは、現行システムを動かせる発注者側だけです。月次や年次の締め処理、閏年、ゼロ件のファイルなど、出現頻度が低い入力ほど漏れやすいので、業務担当者と一緒に入力の一覧を作ります。 本番データを使う場合は、個人情報や口座情報のマスキングが前提です。マスキングで値を変えると出力も変わるため、マスキング後のデータで現行システムをもう一度動かし、その出力を正解にします。この準備にかかる期間は、見積りの段階で開発会社と分けて計上しておくと、工期の読み違いを防げます。 ### 提案書と見積りの段階で開発会社に聞いておく移行の検証と保守に関する質問の一覧 生成AIを使う移行の提案を比べるとき、最低限そろえて聞く質問は次のとおりです。上から順に、答えが曖昧だと後で揉めやすいものを並べました。 1. 新旧の出力をどの単位で比べ、何を合格とするか（バイト単位一致か、許容差を認めるか） 2. 出力が一致しなかったプログラムを、どう特定し、誰が直すか 3. 使うモデルやツールの名前と版、入力したソースが学習に使われない契約か 4. JCL、COPY句、データベースアクセス、画面処理のそれぞれをどう移すか 5. 移行後のコードの保守を、どの言語の技術者が担う前提か 6. 移行期間中に現行側で入った改修を、移行先にどう反映するか 1と2に具体的な答えが返ってこない提案は、変換の速さを売っていても検証の工数が見積りから抜けている可能性があります。 ### 契約に入れる受け入れ基準と検証で見つかった新旧の出力差分の扱い方 受け入れ基準は「発注者が用意した入力に対し、新旧の出力が全件一致すること」と書くのが基本です。OpenAIの評価が1件の不一致でも失敗とした考え方と同じです。日付や採番のように実行のたびに変わる項目は、比べる前に除外するルールを別表で決めておきます。 差分が見つかったときに、それが移行の誤りか、現行側の不具合か、仕様として許す差かを判定するのは発注者です。現行の不具合を移行先で直すかどうかは、移行と切り離して別の改修として扱います。混ぜると「どこまでが移行の範囲か」が曖昧になり、検収が終わりません。 ## 生成AIでCOBOL移行を進める案件と従来手法を選ぶ案件の判断基準 生成AIを入れるかどうかは、技術の新しさではなく、自社の資産が評価の条件にどれだけ近いかで決めます。ここでは発注者の立場で線を引きます。 ### 生成AIを主軸にしてよい条件はソース完全・バッチ中心・出力の取得 次の3つがそろう資産なら、生成AIを移行の主軸に据えてよいと判断します。本番で動いているソースとCOPY句が全量そろっていること。処理の大半がファイルを入出力するバッチであること。現行システムで入力を流して出力を取り出せる環境があること。 この条件はOpenAIの評価と構造が同じです。正解の出力と比べられる限り、生成AIの誤りは検証で必ず見つかります。見つかる誤りなら、移行の速さという利点だけを取り込めます。 ### 見送るべき場面：オンライン処理中心・正解不明・残り寿命が短い 反対に、画面とトランザクション処理が中心で、操作の順番によって結果が変わる業務は、生成AIを主軸にしません。出力を1回の実行で取り出せず、バイト一致の物差しが作れないからです。ソースの一部が失われている、現行の出力が正しいかを誰も判定できない、といった資産も同じ扱いです。 あと数年で業務ごと廃止する予定のシステムも見送ります。移行して検証する費用を回収する前に寿命が来るなら、COBOLのまま延命するか、廃止に合わせて新しいサービスへ置き換えるほうが安く済みます。脱却するかどうか自体の判断と費用の見積り方は[レガシーシステム脱却の判断基準と進め方](https://www.issoh.co.jp/column/details/16393/)を参照してください。 ### 代表的な数本のプログラムで受け入れ基準を試すPoCの切り出し方 判断に迷う場合は、本番移行の前に小さく試します。対象は、よく動くバッチ1〜2本、金額計算を含むもの1本、COPY句を多く使うもの1本の計3〜5本程度に絞り、受け入れ基準と同じバイト一致で検証します。見るのは一致率そのものより、不一致の原因を特定して直すまでに何日かかったかです。 PoCで手応えがあれば、全体を一度に移さず、業務単位で順に切り替える進め方が取れます。旧システムを動かしたまま機能ごとに置き換える手順は[ストラングラーフィグパターンによる段階移行](https://www.issoh.co.jp/tech/details/16183/)が参考になる資料です。対象プログラムの選び方や受け入れ基準の作り方から相談したい場合は、[一創のシステムマイグレーション・リプレイス](https://www.issoh.co.jp/service/system/migration/)で、資産の棚卸しからPoC、本番移行まで支援しています。 ## よくある質問 生成AIを使ったCOBOL移行について、検討の初期によく出る疑問に答えます。 ### 生成AIだけでCOBOLをJavaへ自動で移行できますか？ 1本ずつのプログラムを移す作業は、かなりの割合で生成AIに任せられる段階に来ています。OpenAIの評価では、GPT-6.1 Solが非公開テストで出力のバイト単位一致を条件に86.6%を出しました。ただし評価はプログラム単位で、JCLやデータベース、画面がつながったシステム全体の移行ではありません。新旧の出力を突き合わせる検証と、不一致を直す人の作業は残ると考えてください。 ### OpenAIのCOBOL移行の評価データは公開されていますか？ 2026年10月19日の発表文で、GitHubへの公開が明記されているのはMultiLangBench（SQLite互換のエンジンを20言語で作る評価）のほうです。COBOL移行の評価は非公開のテストを使うと書かれており、問題やテストを公開したという記述はありません。自社の資産との近さを確かめたい場合は、自社のプログラム数本で同じ条件の検証を行うのが確実です。 ### 生成AIを使うとCOBOL移行の費用はどれくらい下がりますか？ 一律の削減率は言えません。生成AIで縮むのは、現行コードを読む工程と書き換える工程です。新旧の出力を比べるテスト、データの移行、本番の切り替えはあまり縮みません。移行先の言語で保守する体制づくりの費用も残ります。見積りでは工程ごとの内訳を出してもらい、どの工程にどれだけ削減を見込んでいるかを確かめてください。 ### COBOLの移行先にはJavaとPythonのどちらを選ぶべきですか？ 移行後に誰が保守するかで決めます。基幹系の改修を担う技術者がJavaに多いならJavaが無難で、データ処理やバッチの比重が高く分析の担当者も触るならPythonも候補です。どちらを選ぶ場合でも、金額は浮動小数点ではなく、JavaのBigDecimalやPythonのDecimalといった10進演算の型で扱う方針を先に決めておきます。 ### COBOLのソースを社外の生成AIサービスに渡しても大丈夫ですか？ 契約の条件を確かめてから判断します。確認するのは、入力したソースがモデルの学習に使われないこと、処理される地域、ログの保存期間です。ソースに埋め込まれた接続情報や、テストに使う本番データに含まれる個人情報は、渡す前に取り除くかマスキングします。社内規程で外部への送信が禁じられている資産は、対象から外すか、閉じた環境で動く手段を選んでください。 ## 関連記事 - [レガシーシステムとは？再構築が必要な理由を経産省の定義と5要因で解説](https://www.issoh.co.jp/column/details/10413/)：COBOL資産を抱えるシステムが再構築を迫られる理由 - [2025年の崖とは何だったのか｜DXレポートの試算と2026年に刷新を判断する基準](https://www.issoh.co.jp/column/details/16398/)：移行を始める時期を決めるための背景 - [モダナイゼーションとは？レガシー刷新の手法と実装アプローチ・進め方を解説](https://www.issoh.co.jp/tech/details/13374/)：言語移行以外の刷新手法との比較 - [Javaマイグレーションの進め方｜JDK 8→21/25の手順とSpring Boot・Jakarta移行](https://www.issoh.co.jp/tech/details/1314/)：移行先をJavaにした後の版上げの進め方 - [レガシーシステム脱却の判断基準と進め方｜経産省調査が示す停滞要因と費用の見積り方](https://www.issoh.co.jp/column/details/16393/)：脱却するかどうかの判断と費用の見積り方 --- 出典: [COBOL移行と生成AI：OpenAIの正答率86.6%の読み方と発注前の確認事項]()（株式会社一創）