COBOLの移行に生成AIは使えます。2026年10月に発表された最新モデルの評価では、COBOLから別言語への変換で97.9%という数字が出ました。ただし、この数字をそのまま自社の基幹システムに当てはめると、計画を誤ります。

AIが得意な工程と苦手な工程を切り分け、検証の仕組みと人材を先に整えた企業が、移行を前に進められます。97.9%の中身、工程ごとの任せ方、現新比較による検証、そしてCOBOLの有識者とAIを使う人の組み合わせ方を順に見ていきます。

この記事でわかること

  • 2026年10月のOpenAI発表の数字が、何を測った数字なのか
  • ベンチマークで高得点でも、基幹システムの移行が失敗する理由
  • 現状分析から並行稼働まで、工程ごとにAIをどこで使いどこで使わないか
  • 現新比較で何を突き合わせ、どこに落とし穴があるか
  • COBOLの有識者とAIを使う人をどう組み合わせるか、ベンダーに何を聞くか

COBOLと生成AIの関係は「変換」より先に「理解」で効く

生成AIがCOBOLの移行で最初に役立つのは、プログラムを別の言語に書き換える場面ではありません。何十万行もあるソースが何をしているのかを読み解く場面です。人間が時間をかけて読んでいた部分を短縮できることが、移行の進め方そのものを変えつつあります。

従来の移行と生成AIを使う移行は、時間のかかる場所が違う

従来のレガシー移行では、最も時間を食うのは新しいコードを書く作業ではありませんでした。設計書が古く、ソースを読んで仕様を復元する作業です。設計書の最終更新が10〜15年前というシステムは珍しくなく、規模は数百万〜数千万ステップに及びます（NTTデータの技術記事）。

生成AIは、この「読む」「整理する」作業を肩代わりします。ソースから依存関係を洗い出し、業務ルールを文章にし、設計書の下書きを作る。その上で変換とテストの生成に進みます。

「書く工程」が速くなったというより、「読む工程」がボトルネックでなくなりつつある。これが実態に近い見方です。

なぜいまCOBOLが話題になっているのか

理由は2つあります。ひとつは、COBOLが生成AIにとって難しい言語だったこと。学習データが少なく、AIはこの種の言語で誤りやすい傾向があります。もうひとつは、2026年に入ってモデルの側が一気に追いついてきたことです。

OpenAIは2026年10月19日、COBOLやFortranなど学習データの少ない言語での性能向上を発表しました（ITmedia AI Watch、ビジネス+IT）。2月には、Claude Codeを使ったCOBOL刷新の方法が公開され、メインフレーム大手の株価が動くほどの反応がありました（GIGAZINE）。

国内でも、富士通が2026年7月にAI活用のモダナイゼーションサービスを提供開始しました（富士通）。リライトとリホスト中心の案件で移行期間を約40%短縮し、人が最終判断をする設計を取る、という内容です。この40%の算出条件は、現時点の公開情報では確認できていません。

「全部AIで自動移行」ではなく「人の判断を残して速くする」が現実解

AIを入れれば移行が自動で終わる、という段階にはありません。当協会が軸に置くのは、AIに任せる工程と人が判断する工程を分けることです。

コード生成AI全般の使い方とリスクはコード生成AIとは？開発現場の使い方と導入リスクで整理しています。COBOLに固有の論点は、このあと順に扱います。

OpenAI発表の数字は、2つの別々の評価を混ぜて読むと誤解する

発表で示された数字は、性質の違う2つの評価から出ています。「SQLiteを一から作れるか」を測る評価と、「既存のCOBOLを別言語に移して出力が完全に一致するか」を測る評価です。この2つを同じ物差しで読むと、COBOLの実力を見誤ります。

MultiLangBenchはSQLite互換のDBエンジンをゼロから作らせる評価

新しく公開されたMultiLangBenchは、SQLite互換のデータベースエンジンを、COBOLやFortranなど20言語でゼロから実装させる評価です。SQLiteの既存テストをもとに、参照実装と出力を照合します（xenospectrum）。

移行ではなく「新規に作れるか」を見ている点が、まず違います。20言語の平均合格率は新モデルで87.4%、前世代で26.8%でした。COBOLだけを見ると、72.1%対10.9%です。

ここで見逃せないのは、COBOLが20言語の中で最も低い点です。ほかの19言語は83%を超えています。COBOLは大きく伸びたものの、まだ「普通の言語並み」には届いていません。97.9%の見出しだけで判断すると、この差を見落とします。

COBOL移行評価は既存プログラムを別言語に移し、出力のバイト一致を求める

もうひとつの「COBOL移行評価」は、既存のCOBOLプログラムをC++、Java、Kotlin、Python、Rustのいずれかに移す評価です。隠しテストで出力がバイト単位で一致する必要があり、すべて通って初めて成功と数えます。

この条件でも、低推論の設定で86.6%（前世代の同じ設定では5.4%）、高推論の設定で97.9%でした。86.6%と97.9%は推論設定が違う数字で、同列には並べられません。

評価何を測るか主な数字読むときの注意
MultiLangBench20言語でSQLite互換DBを一から作る20言語平均87.4%、COBOLは72.1%COBOLは20言語で最下位。新規実装の評価
COBOL移行評価既存COBOLを別言語に移し、出力のバイト一致を求める低推論86.6%、高推論97.9%非公開の評価。推論設定で数字が変わる
低価格モデルの比較MultiLangBenchでの費用対効果平均40.3%、1件約0.77ドル比較相手は最上位モデルではなく前世代

非公開の評価であり、題材は実際の基幹システムではない

この表で押さえておきたいのは、COBOL移行評価が非公開で、第三者による再現が行われていない点です（Let’s Data Science）。評価の設計もOpenAI自身が行っていて、プログラムの本数は発表で示されていません。MultiLangBenchの87.4%がどのテストセットの数字かも、発表からは読み取れません。

さらに根本的な点があります。題材は評価用に用意されたプログラムです。データベース、トランザクション管理、帳票、バッチ運用が絡み合う実際の基幹システムの成功率を示す数字ではありません。

OpenAI自身も、本番導入には業務ルールと外部システムへの依存を踏まえた専門家のレビューとテストが必要、と注記しています（xenospectrum）。

5.4%から86.6%への跳ね上がりは大きな進歩です。ただ、それは「変換の入口を通れるようになった」ことを示す数字で、「移行が終わる」ことを示す数字ではありません。

ベンチマークで高得点でも、基幹移行が失敗する理由は3つある

AIによるレガシー移行は、評価用の課題では高い数字が出ても、実システムでは成功率が大きく下がります。汎用の開発性能が70%を超える最先端モデルでも、レガシー移行の評価（Legacy-Bench）の成功率は約15%だった、というデータがあります。失敗した場合でも、AIが「完了」と報告した割合は97%でした。いずれもNTTデータの記事が引用している数字で、Legacy-Benchの原典は確認できていません（NTTデータ）。

AIが誤りに気づかず「成功しました」と報告する

最も厄介なのは、間違ったまま終わるサイレント失敗です。AIは変換を終えると「完了」と返します。そのコードが丸めの違いで1円ずれていても、AIは気づきません。

人間が全行を読んで検証するのは、数百万行規模では非現実的です。だから「AIの完了報告」を信頼の根拠にせず、機械的に検知する仕組みを先に作る必要があります。

変換率や工数削減率の数字では、動作と保守性が測れない

「何%自動変換できたか」「工数が何%減ったか」という指標は、見栄えは良いのですが、動くかどうかも、あとで保守できるかも教えてくれません。

2024年にNTTデータが指摘した問題は、いま読み返しても具体的です。COBOLのソースだけをAIに入力すると、スペース埋めやバイト単位のメモリ操作といった、業務と無関係なロジックまでそのまま出力に出てきます。結果は読みにくいJavaになります。対策は、Javaの再設計指針をAIに渡すこと、さらにプログラムごとのJava仕様を先に作ってから変換することです。数値項目はint、long、BigIntegerを値の範囲で使い分けます（NTTデータ）。

COBOLの構造をそのまま引きずったJava、いわゆる「JaBOL」を量産しても、保守する人にとっては別のレガシーが増えるだけです。

設計書にない暗黙知が、移行のたびに失われる

COBOLのプログラムには、設計書に書かれていない判断が埋まっています。なぜこの項目だけ端数を切り捨てるのか。なぜこの例外フラグが存在するのか。担当者が退職すると、理由を知る人はいません。

AIはソースにある事実は読めますが、背景は読めません。暗黙知を有識者の知見も含めて設計の前提情報として整えてからAIに投入する、というのがNTTデータの取り組みです。

ガートナーも、2026年に始まるメインフレームなどの脱レガシープロジェクトの70%以上が目標を達成できない、と予測しています。背景にはAIによる自動変換への過度な期待がある、という分析です（@IT、ガートナーの原典は未確認）。

工程別の進め方：AIが効く工程と、人が握る工程を分ける

移行はひとつの作業ではなく、性質の違う工程の連なりです。AIが力を発揮する工程と、人が判断を握る工程を表で分けておくと、ベンダーとの会話も社内の役割分担もぶれません。この表は公開情報をもとにした当協会の整理で、工程別の定量的な公的データは確認できていません。

工程AIの効き方人が握る判断
現状分析・アセスメント効く。依存関係と複雑度の可視化どこを移行対象にするか
仕様の逆生成効く。ソースから業務ルールと設計書の下書きルールが業務として正しいかの確認
方式選定補助的。選択肢の整理リホスト・リライト・リビルドの決定
コード変換効く。ただし再設計指針が前提型・丸めなど仕様判断
テスト生成効く。ケースとデータの下書き網羅性の判断
現新比較比較の自動化は可能差分が許容か不具合かの合否判断
並行稼働・本番切替ほぼ効かない切替の可否と責任

現状分析と仕様の逆生成から始める

最初にAIを使うべき場所は、変換ではなくこの2工程です。AWSのAWS Transform for mainframeは、依存関係と複雑度のアセスメント、業務ルールの抽出、テスト計画とテストデータの生成まで一続きの流れを提供しています。GoogleのMainframe Assessment Toolも、COBOL、コピーブック、JCLなどを解析の対象にします。

仕様を先に文章にしておくと、その文章が変換の指示にも、テストの基準にも、AIの出力を人が確認する基準にもなります。この考え方は仕様駆動開発とは？と同じ構造です。

国内でも富士通が、COBOLなどを解析して設計書を自動生成するSaaSを提供しています。設計書の作成時間を97%削減したと報じられていますが、これは自社の測定値で、条件は公開されていません（innovatopia）。

方式選定は「リホスト」「リライト」「リビルド」のどれかを先に決める

AIで変換できるからといって、すべてを書き換える必要はありません。基盤だけを移すリホスト、ロジックはそのままで言語と基盤を移すリライト、設計から作り直すリビルド。この3つの違いを理解せずにAIを導入すると、変換の精度ばかりが議論になります（DIR）。

生成AIでプログラムの理解が楽になったことで、リホストの有効性が見直されているという指摘もあります。ガートナーは、大企業には業務単位の段階移行を勧めています。全体を一度に動かす計画は、AIを使っても組まないほうが安全です。

変換は仕様書を経由して段階的に行う

変換工程では、ソースをいきなりAIに渡さず、プログラムごとの仕様を一度挟みます。仕様を経由する流れは次のとおりです。

  1. 移行する単位（業務機能やバッチジョブ）を小さく区切る
  2. その単位のソースと関連コピーブックから、AIで仕様書を作る
  3. 有識者が仕様書を確認し、暗黙知を追記する
  4. 再設計指針（型の使い分け、命名、構造）を添えてAIにコードを生成させる
  5. 変換前後の出力を突き合わせて検証する

ステップ3が省略されると、暗黙知の欠落がそのままコードに残ります。ここは人が手を抜けない工程です。

現新比較は機械で差分を出し、人が合否を決める

現新比較は、旧システムと新システムに同じ入力を与え、出力を突き合わせるテストです。AIが完了と言っても、旧システムの出力と一致しなければ失敗として扱えます。人が全行を読む代わりに、機械で差分を検知するための手段です。

見るべき比較対象は、画面や帳票の出力だけではありません。DBに書き込まれた値、ファイル出力、バッチの終了コードまで含めます。比較の実行はAIや自動化で大半をこなせます。差分が「許容できる誤差」なのか「不具合」なのかは、業務を知る人にしか決められません。

完了を判断するのはAIではありません。コードレビューの設計も同じ考え方で、AIコードレビュー導入ガイドに人とAIの分担をまとめています。

数値の精度と文字コードは仕様判断が必要

COBOLは固定長の項目と十進数の演算を前提にしています。Javaでは、この項目をint、long、BigInteger、Stringのどれで持つかを選ぶ必要があり、選び方で桁あふれや丸めの結果が変わります。AIに任せきりにせず、項目ごとに範囲を決めておく領域です。

文字コード（EBCDIC、シフトJIS、外字）、JCLとバッチ運用、性能については、日本語で参照できる公式の具体資料を今回の調査では確認できませんでした。Googleは、VSAMやCICSへの依存が難所になると指摘しています。基盤依存の部分は、変換の対象ではなく設計の論点として早めに洗い出してください。

ここまでの工程をAIと進めるには、仕様をAIに渡せる形に整え、出力を検証する力が要ります。社内で足りないと感じたら、AI駆動開発研修で、AIに任せる範囲を決めて出力を検証する進め方を実務の題材で学べます。

体制は「COBOL有識者」と「AIを使う人」を組にする

AIを使った移行は、COBOLを知る人かAIを使える人のどちらかだけでは回りません。有識者は暗黙知の確認と合否の判断を担い、AIに強い人は指示の設計と検証の自動化を担います。この組み合わせは、公開情報から当協会が整理した推奨の形です。出典付きで裏づけられる資料は確認できていません。

役割を分けて、レビューの責任を明確にする

最低限、次の3つの役割を決めておきます。

  • COBOL有識者：ソースと業務ルールを読み、AIが作った仕様書を確認する。差分の合否を判断する
  • AIを使う開発者：再設計指針とプロンプトを整え、変換とテスト生成を回し、現新比較を自動化する
  • 業務側の責任者：許容できる差分の基準を決め、本番切替を承認する

最終判断を人に残すこと自体は、富士通が明記している設計と同じ方向です。責任者がいないと、AIの出力は誰も責任を取らないまま本番に進みます。

若手が学ぶ機会を残す

AIの出力をそのまま受け入れ続けると、開発者が学ぶ機会を失い、システムがまたブラックボックスになる、という指摘があります。移行後に保守する人が、なぜそのコードになったのか分からなければ、同じ問題を数年後に繰り返します。

有識者が若手にレビューを通じて背景を伝える運用にしておくと、暗黙知の継承にもなります。移行プロジェクトを、COBOLの知識を残す機会としても使えます。AI駆動開発を社内に定着させる全体像は、AI駆動開発導入をPoCから社内定着まで進める方法が参考になります。

ベンダーに聞くべき質問

「AI搭載」をうたう製品でも、中身はルールベースの変換というケースがある、という指摘があります。契約前に、次の点を確認してください。

質問確認したいこと
AIが担う範囲はどこか解析・仕様生成・変換・テストのどれか
検証はどう行うか現新比較の仕組みと、差分の扱い
人が判断する場面はどこか責任の分担
数値の算出条件は何か「何%削減」の対象と測定条件
自社のデータはどこで処理されるかソースコードの扱い

数値の算出条件の確認は、特に外せません。削減率や短縮率は、条件次第で大きく変わるからです。

よくある質問

COBOLの移行に生成AIは本当に使えますか？

使えます。特に現状分析、仕様の逆生成、コード変換、テスト生成で効果があります。ただし業務判断と現新比較の合否判断は人が担う必要があります。

OpenAIの97.9%は、自社の基幹システムでも出ますか？

出る保証はありません。この数字は非公開の評価用プログラムでの結果で、第三者による再現もありません。実システムではDBや外部連携が絡むため、同じ成功率は期待できません。

COBOLのコードをAIに渡すのは情報漏えいになりませんか？

利用するサービスのデータの扱い次第です。入力データが学習に使われない契約か、処理される地域はどこかを確認し、社内のセキュリティ部門と取り決めてから使ってください。

リホスト・リライト・リビルドはどう選べばいいですか？

業務ロジックを変えず早く基盤を移したいならリホスト、言語も移したいならリライト、業務自体を見直すならリビルドです。AIは選択肢の整理を補助できますが、決定は人が行います。

COBOLを読める人がいなくても、AIで移行できますか？

おすすめしません。AIは暗黙知を読めないため、仕様書を確認し差分を判断する有識者が要ります。社内に不在なら、外部の有識者をプロジェクトに組み込んでください。

まとめ

最初の一歩は、移行対象のシステムを小さく区切って、AIで現状分析と仕様の逆生成を試すことです。変換から入らないでください。仕様書の質を有識者に見てもらえば、自社のソースでAIがどこまで読めるかが見えてきます。

その次に、現新比較の仕組みを変換より先に作ります。完了を判断する基準がないまま変換を進めると、サイレント失敗を見逃します。体制は、COBOL有識者、AIを使う開発者、業務側の責任者の3者を最初から揃えるところまで決めてください。

ベンチマークの数字は、次のモデルでまた更新されます。基幹移行の成否を決めるのは、数字ではなく、検証の仕組みと人材です。

AIに任せる範囲を決め、出力を検証しながら開発を進める力は、COBOL移行に限らず使えます。法人の開発チームでその土台を作りたい場合は、AI駆動開発研修をご検討ください。

次に読みたい関連記事