メインフレームに眠る「年代物のCOBOLコード」、AIでも苦戦する"読みにくさ"の正体：誰も触りたくない“40年物”のレガシー

複数の国産メインフレームベンダーが撤退方針を明らかにする中で、レガシーシステムの刷新は喫緊の課題だ。一方ではAIエージェントの存在がモダナイズの在り方にも影響を及ぼし始めている。40年物のシステムにどう向き合うべきか。アクセンチュアの中野氏に聞いた。

[遠藤文康，＠IT]

　メインフレーム事業からの撤退方針を既に公表していた富士通に続き、日立製作所もメインフレーム向け独自OSの販売と保守を終了することを発表。国内におけるレガシーシステム刷新の必要性は一段と高まった状況だ。前回「富士通も日立も去る、日本での『メインフレーム脱却』が一筋縄ではいかない理由」は、日本のメインフレームが世界の中でも特殊な事情を抱えており、システム刷新に向けてはそれを考慮しなければならない点に触れた。

　国内メインフレーム市場の縮小モードが色濃くなる一方で、生成AI、AIエージェントの普及はモダナイゼーションの在り方に大きく影響を与えつつある。その象徴的な動きの一つとして、Microsoftが2026年6月に開催した開発者カンファレンス「Microsoft Build 2026」では、AIエージェントを使いやすくするために開発基盤はどう進化するのかが強調された。

　人間が一からプログラムをコーディングする機会は激減している。アクセンチュアの中野恭秀氏（デジタルコア　シニア・プリンシパル）は、レガシーシステムのモダナイゼーションに携わる中でもその影響は大きく、AI駆動開発を前提にした進め方へと転換していると話す。

　ただし長年にわたって塩漬けにされてきたレガシーシステムは、「そのままではAIが理解できる状態ではない」（中野氏）。それを前提に、モダナイゼーションを進めるに当たってどのような手法が有効なのかを考えなければならない。

「40年物のCOBOLコード」はAIにとっても扱いにくい

　企業が向き合うのは、開発当時を知る人も既に引退してしまっているような“40年物も当たり前”のシステムだ。そうしたレガシーシステムについて中野氏は「本来は残っていてはいけないシステムだ」と指摘する。背景にどのような事情があるのか。

Expert's View：中野恭秀氏（アクセンチュア株式会社　デジタルコア　シニア・プリンシパル）

Microsoft Build 2026では前年から方向性が大きく転換した。人間ではなく“AIエージェントにとっての使いやすさ”の観点から、開発環境がどう進化していくかが関心事となった。そうした潮流の中、人間がプログラムを書かなくなる傾向は「加速することはあっても元に戻ることはない」と中野氏は語る。アクセンチュアのJava変換ツール「MAJALIS」を使ったリライトでも、AI駆動開発を前提にそのあるべき姿を定義し直している。

　象徴的なのが2000年問題だ。当時のシステムでは1999年を「99」といったように、西暦を下2桁だけで管理していた。2000年を迎えると「00」となる。1900年と2000年の識別ができなくなり、誤作動する懸念があったため改修が必要になった問題だ。当時はメモリの容量が限られていたことから、そのリソース消費を節約するためのプログラミングが求められたという事情がある。

　もっとも、この問題は開発当時からすれば想定外ではなかった。そもそも2000年を超えて使い続ける前提ではなかったものが、バブル崩壊でIT投資が抑制され、就職氷河期を背景にシステム部門の人員も十分に補充されなかった。「今日まで延命されてきたシステムは、バブルがはじけてデフレに入り、作り替えのタイミングを逸したシステムばかり」（中野氏）だ。

　メンテナンスに最低限の人数しか投入されないとなれば、本来はドキュメントや設計から見直すべきところも、消費税率の改定や法改正など、どうしても対応が必要な改修に絞らざるを得ない。その積み重ねの中でドキュメントは喪失し、さらには開発当初を知る世代の退職でシステムのブラックボックス化が進むという状況に陥る。

　「伊勢神宮の式年遷宮のように、20年ごとに次世代へ技術と知識が受け継がれるのであれば継続できる。だが40年となれば人から人へと引き継がれず、失われたものが大きくなる」（中野氏）

　そうして長きにわたってメンテナンスを続けてきたソースコードは、「誰も触りたがらない」のが当然の事態だろう。結果として、モダナイゼーションにも着手しにくくなってしまう。モダナイゼーションに着手したとしても、ブラックボックスの領域が解消されないままでは、大失敗につながることもある。

理解しにくいのはAIにとっても同じ

　こうした状況を変える存在として台頭してきたのが、膨大な情報の解析や整理、変換を得意とする生成AIだが、実はAIにとっても事情は似ているという。人間がやって理解しにくいものは、AIも同じで「結果的にハルシネーションにつながるリスクがある」（中野氏）からだ。

　例えば中野氏が挙げるのが、40年以上にわたって積み重ねられたコーディングスタイルの違いだ。1980年代前半のCOBOLでは、処理の流れを別の場所へ無条件に飛ばす「GOTO文」を多用するプログラミングが一般的だった。一方、1980年代半ば以降は構造化プログラミングが普及し、GOTO文は原則として避けられるようになった。

　「40年、50年物のレガシーシステムだと3世代ほどのコーディングパターンにまたがるのが一般的」（中野氏）。そうした異なる「作法」が混在するコードだと、いかにAIの進化が著しくても一定のハルシネーションを引き起こす可能性がある。

　AIを使うことが前提になると、モダナイゼーションで何を重視すべきかという評価軸も変わってくると中野氏は指摘する。例えばCOBOLからJavaへのリライトでは、従来はJavaエンジニアが理解しやすいコードにすることが重視されてきた。だがAI駆動開発が前提になると、移行後のメンテナンスを見据えて、AIが正確に理解できる状態にすることが求められる。

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

　日本のメインフレームで長年利用されてきた独自のデータベースや、その入出力処理、さらにはアセンブラ（マシン語に近い低水準のプログラミング言語）などは、Javaに比べて公開情報が少ないので、AIが十分に事前学習できていない。そのためいったんAIが理解しやすいJavaへと変換することで、AIの理解度が上がり、ハルシネーションを抑制しやすくなるという。

刷新手法としてのリホスト、リライト、リビルド

　移行手段としてリライトが選ばれるのは、企業固有のビジネスロジックを維持する必要があることに加えて、既存システムを一から作り直すのが現実的ではない場合だ。

　会計や人事、購買などの標準化しやすい業務領域であればERP（統合基幹業務システム）パッケージで一通りカバーできることもある。業務やシステムの在り方から見直すのであれば、システムを構築し直すリビルドが選択されることもある。長年の運用で蓄積された企業固有のビジネスロジックを維持することを重視し、かつシステムを一から作り直すのが費用面でも移行期間の面でも現実的ではない場合には、予算的にも体制的にも継続性のある手法としてリライトが選択肢になる。

　既存のプログラムをほぼ変更せず、メインフレームからLinuxサーバやクラウドなどのオープン環境へ移す「リホスト」も、モダナイゼーションでは比較的短期間かつ低コストで移行できる手段として広く使われる。こうした手法を検討する上でも、AI駆動開発を前提にした観点が求められるようになってきているという。

　AIエージェントは、多数のタスクを並列に走らせることで作業時間を劇的に短縮できることが特徴だ。今後のAI駆動開発を視野に入れた場合には、その利点をどれだけ生かせる開発環境を整えられるかも欠かせない視点になる。例えばリホストの一般的な選択肢となる商用のCOBOL開発環境は、ライセンスが人間のユーザー数に応じて割り振られる体系になっていることが一般的。タスクに応じて開発環境を柔軟に増減させながら、並列で作業を進めるといった形で大規模にAIエージェントの作業を展開させる場合には、ライセンス払い出しが人間に割り当てることを前提にした手続きになることやライセンス費用などの条件から、本来のスピード感や拡張性を十分に生かしにくくなるケースも考えられる。AIの急速な進化を考慮すれば、そうした面も考慮すべき一面になってきている。

　もちろんライセンス体系や運用の在り方も、AIエージェントの普及を受けて今後どう変わっていくか次第。いずれにしても、将来的にAI駆動開発をどのように組み込んでいくかも見据えた上で、長期的に継続性のある進め方を検討することが重要になる。

---

　次回は、刷新時のアプローチの一つして選択されるCOBOLからJavaへのリライトについて考える。AIの利用を前提にした開発とメンテナンスの必要性がこれから一段と高まる中で、COBOLからJavaに変換する意義を改めて問い直す。