「COBOLを読める」と「移行できる」は別問題――AIでは越えられない“レガシーの壁”：2035年へのレガシーモダナイゼーション実務論（4）（2/2 ページ）

[中野恭秀（アクセンチュア）, 編集：遠藤文康，＠IT]

COBOLをJavaに変換するAI、公表されている数字をどう読むか

　自分で測らなくても、公表された数字はある。読み方に気を付ければ参考になる。

　IBMの研究チームが、ソフトウェア工学の国際会議ICSE 2026で発表した論文が分かりやすい。COBOLから「Java」への変換を、大規模言語モデル（LLM）単体ではなく、静的な解析と組み合わせる方式だ。データ定義と処理の流れを機械的に解析し、Java側のクラスやメソッドの骨格を先に決めてしまう。LLMには、その枠の中で書かせる。IBMが用意した「LLM-as-a-Judge」（LLaJ）による0から100点の品質評価スコアは、公開されている20本と顧客固有の10本で評価し、 構造の品質は中央値8割超、機能面で7割5分超と報告している。

　骨格を先に決めるとは、どういうことか。小さな例で言えばこうだ。COBOLのデータ部に「01 顧客レコード」があり、その下に「05 顧客番号 PIC 9(8)」「05 顧客名 PIC X(40)」「05 与信限度額 PIC S9(9)V99 COMP-3」と並んでいる。この入れ子がそのままJavaのクラスになる。顧客レコードがクラス、各項目がフィールドで、桁と型の指定からint、String、BigDecimalが決まる。処理側は、段落や節のまとまりがメソッドの候補だ。COBOLに「クラス」という単位はないが、この2つが代わりを務める。

　この8割と7割5分というのは、合格したプログラムの割合ではない。変換後のJava1本ごとに構造の面と機能の面でスコアを付け、集計した値だ。構造の面は出来上がったJavaの作りを、機能の面は元のCOBOLと同じように動くかどうかを見る。こういう数字を読むときは、2つ確かめたい。何を対象に測ったのか。何をもって合格としたのか。逆に、この2つが書かれていない数字は、高くても低くても比べようがない。

　注目したいのは設計思想の方だ。LLMに自由に書かせず、機械的に決められるところは先に決めておく。取材いただいた記事の2本目で筆者が「ガードレール」と表現したのと同じ考え方だ。

　精度を上げているのは、モデルの賢さではない。渡す前の準備である。

　ツールを選ぶ見方もここから決まる。「どのモデルを使っているのか」より「渡す前に何を機械的に固めているのか」を聞く方がいい。前者は数カ月で陳腐化する。後者は設計思想で、そう簡単には変わらない。

PoCで測るべきは「AIの能力」ではなく「自社の資産」

　一つ勧めたいことがある。

　PoC（本格導入の前に小さく試して見極める検証）で、測る対象を間違えないでほしい。多くのPoCは「AIがどこまでできるか」を測っている。だが、公開の問題で測れる範囲のこと――読解そのものの力――は、自社で測り直しても同じ結論になる。しかもモデルは数カ月で入れ替わる。そこに自社の時間を使う価値はあまりない。

　測る対象を、AI側から自社の資産に移してほしい。1本のプログラムをAIに理解させるのに何を集める必要があったか。集まらなかったものは何か。それを記録する。

　手順はこうだ。まず1本選ぶ。AIに読ませられるかどうかを測る6項目のうち、2つか3つが当てはまるものがいい。全部当てはまる1本は難し過ぎるし、一つも当てはまらない1本は易し過ぎて何も分からない。選んだら、何をしているかをAIに説明させる。大事なのはその次で、説明が実態と食い違った箇所について「なぜ食い違ったのか」を追う。たいていは渡していない情報があったからだ。それが何で、どこにあり、探すのに何日かかったかを記録する。3本もすれば、自社の資産の性格は見えてくる。

　得られるのはAIの評価ではなく、自社の資産の評価だ。その方が長く使える。モデルは来年には別物だが、コピー句が見つからないという事実は来年も同じだからだ。

　測るべきはモデルの能力ではない。自社の資産の渡しやすさである。

　次回は、AIが間違える場所の話をする。誤りは一様には起きない。偏って起きる。その偏りには法則がある。

著者紹介

中野恭秀（なかの・やすひで）

アクセンチュア株式会社 デジタルコア シニア・プリンシパル

レガシーシステムを、新基盤・システムに移行するマイグレーションを中心としたAMO（Application Modernization and Optimization）を手掛ける。アクセンチュア入社以前は、メーカー系SIerや複数のベンダーで約40年にわたりコンバージョンやメインフレームのオープン系プラットフォームへのリホスト業務などを経験。COBOLコンソーシアムの設立にも従事した。

参考文献・一次情報

・情報処理技術者試験の過去問題が公開されていること（第2節・測定に用いる問題の出所）

IPA「過去問題」情報処理技術者試験

※平成21年度（2009年度）以降の問題冊子・解答例・採点講評が公開されている。なお令和2年度から令和4年度までの基本情報技術者試験の問題は非公開であり、本文が対象とする範囲（2009年度春期〜2019年度秋期）はこの非公開期間の手前で閉じている。また平成23年度春期は東日本大震災の影響で中止となり、代替として平成23年度特別情報処理技術者試験が2011年6月26日・7月10日に実施された。実施回数を本文に書く場合は、この特別試験を含めるかどうかで数が変わる。

・基本情報技術者試験からCOBOLが廃止され、Pythonが追加されたこと

IPA、基本情報技術者試験にPythonを追加／COBOLを廃止　＠IT、2019年1月28日

※2019年1月にIPAが出題見直しを公表し、COBOLの出題は2019年度秋期が最後となった。

・プログラム解析とLLMを組み合わせたCOBOL-Java変換（本文中の海外事例）

V. Chakaravarthy, A. R. Choudhury, D. Garg, V. Kanvar, S. Pandian, A. Raghuvanshi, Y. Sabharwal, A. Singhee, “Enterprise-Scale COBOL-to-Java Translation: LLMs Augmented with Program Analysis,” ICSE 2026.

※COBOLのデータ部と制御フローグラフからJavaのクラス・メソッド骨格を推論し、LLMによる変換を誘導する方式。GenAPPの20プログラムと顧客独自の10アプリケーションで評価し、構造品質スコア中央値80％以上、機能スコア75％以上と報告。IBM watsonx Code Assistant for Zに実装。

※投稿トラックはSEIP（Software Engineering in Practice）。著者名の表記はICSE 2026の公式ページに従った。IBM Researchの掲載ページでは Venkatesan Chakravarthy、Shivmaran S と表記されており、綴りに揺れがある。本文の参照先URLは、内容の要約が読めるIBM Researchの掲載ページとした。arXiv版は公開されていない。

・アセスメントで測る6項目（本文中の参照）

本連載第3回「COBOLの移行で『本数とステップ数』の物差しはもう通用しない――その理由と“難易度を測る6項目”」を参照。

・「ガードレール」としてのJava変換（本文中の参照）

メインフレームに眠る『年代物のCOBOLコード』、AIでも苦戦する“読みにくさ”の正体　＠IT、2026年7月29日

※「Javaへのリライトは単に言語を変換するということではなく、『ガードレール、安全装置のような位置付け』に変わってくる」との言及がある。

・図版について

図1・図2はいずれも筆者が作成した。図1は測定の設計を整理したもの、図2は試験問題と実際のレガシー資産の違いを示す概念図である。本稿は特定の測定結果を報告するものではなく、測り方とその限界を整理したものである。