メインフレーム“撤退表明”で待ったなし――AI時代、レガシー刷新は「変換」の話ではなくなった：2035年へのレガシーモダナイゼーション実務論（1）（2/2 ページ）

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

“レガシー刷新の締め切り”は思ったより手前にある――この連載で書くこと

　この連載は全20回を予定している。テーマは移行の実務が進む順番にした（図2）。ツールの紹介でも成功事例の陳列でもない。工程ごとに、どこまでAIに任せられ、どこから人が決めるのかを書いていく。

図2　本連載の道筋──読者の問いと、全20回の構成（提供：アクセンチュア）

　前半は土台の話だ。まず残り時間を測る。ベンダーの撤退日程から逆算すると、締め切りは思ったより手前にある。しかも技術の期限より先に、当時を知る人が退職するという期限が来る。

　その後、AIのCOBOL読解力を何でどう測るのかを設計し、AIが間違える場所には偏りがあることを解剖する。ここまでが「測る」で、その後「渡す」に移る。項目名が何を指しているのかを整理し、資産同士の関係を機械がたどれる形にしておく作業だ。後者は知識グラフと呼ばれる。AIに探させるのではなくたどらせるために、プログラムやファイル、業務用語を点で示し、その関係を線でつないだ地図を作る。

　この土台の上で、3つの宿題のうち最大の課題である、冒頭に紹介した「Why」の復元に取りかかる。ここまでをそろえた状態を「AI Ready」と呼んでいる。AIにデータを読ませられる状態というより、AIと10年付き合える状態のことだ。移行のゴールをそこに置くと、手法の選択の仕方が変わる。

　後半は手法の選び方やデータ移行、テストの作り方、そして見積もりを崩す真犯人の周辺資産など移行の実務について解説する。

　最後の数回で、移行が終わった後の話をする。誰が保守するのか。契約や体制はAIの速度に追いついているのか。そして、経営・業務・システムの三者が同じ絵を見るための装置について書く。稼働中のシステムと同じように動く模型を、別に持っておく。デジタルツインと呼ばれる考え方だ。ステージング環境とは違う。ステージングは人が手で本番に近づける複製だが、ツインは稼働中の実績が自動で流れ込み、実物の変化に追随し続ける。そこに時間軸を足せば、改修を入れる前に時間を進め、その影響を三者それぞれの言葉で確かめられる。夜間バッチが数カ月先も締め切りに間に合うか、コストと期日はどう動くか、といったことだ。

　ただし、ここはまだ確立した方法論ではない。要素の一つ一つにはデジタルツインの用語を定めた「ISO/IEC 30173」など国際標準や、査読を通った研究の裏付けがあるが、組み上げた全体は誰も完成させていない。だから本連載でも、どこまでが裏付けで、どこからが筆者の見立てかを、その都度分けて書く。

　着地点は、人の立ち位置に置いている。輪（ループ）の中に人が入り、AIの出力を一つずつ確認して次へ進める「Human in the Loop」という形だ。AIが書き、AIが直すようになると、人は輪の外に出てその上に立ち、設計と監督と裁定を担う。先の1円の例なら、丸め方の食い違いを見つけるのがAI、旧システムか標準かを決めるのが人だ。そこに至る道筋を、20回かけて書く。各回を読み終えたときに、翌日の会議で使えるものが一つは残るように書く。

---

　次回は期限の話をする。2035年から逆算すると何が見えるか。そして、それより先に来る「人の期限」を書く。

著者紹介

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

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

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

参考文献・一次情報

・本連載の前提となる取材記事

富士通も日立も去る、日本での「メインフレーム脱却」が一筋縄ではいかない理由　＠IT、2026年7月22日

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

COBOLっぽさを残す「JaBOL」の是非を問い直す――Javaらしさはもう問題じゃない　＠IT、2026年8月5日

・「プログラミングとは、人の頭の中に理論を築く作業である」

Peter Naur, “Programming as theory building,” Microprocessing and Microprogramming, 15(5), pp.253-261, 1985.

※ナウアは1960年のALGOL 60報告書の編者であり、2005年にACMチューリング賞を受賞している。

・「ソースコードからはWhyが分からない」

Pamela Zave, Michael Jackson, “Four Dark Corners of Requirements Engineering,” ACM Transactions on Software Engineering and Methodology, 6(1), pp.1-30, 1997.

※コードが表現しているのは仕様であって、その背後にある要求ではない、という要求工学の基本的な区別を示した論文。

・「AIが安くしたのは実装であって、意思決定ではない」

Frederick P. Brooks, Jr., “No Silver Bullet: Essence and Accidents of Software Engineering,” IEEE Computer, 20(4), pp.10-19, 1987.

※ソフトウェア開発の困難を、道具で削減できる偶有的なものと、対象そのものに由来する本質的なものに分けた古典。

・「経営・業務・システムの三者が同じ絵を見る」ことの必要性

経済産業省 商務情報政策局 情報産業課 情報処理基盤産業室「DXの現在地とレガシーシステム脱却に向けて レガシーシステムモダン化委員会総括レポート」2025年5月28日（委員会の事務局はIPA・経済産業省・デジタル庁。掲載はIPAサイト）