基幹システムの移行時期を決めかねている方へ

メインフレームで基幹システムを動かしていて、移行の時期を決めかねている方に向けて書いています。

決めかねる理由の多くは「まだ動いているから」でした。その前提が変わります。ベンダーが撤退の年を公表したことで、期限が自社の判断ではなくなりました。

公表された期限

@ITの取材記事(2026年7月22日)が、国内ベンダーの状況を整理しています。

ベンダー 状況
富士通 GS21シリーズを2030年度に販売終了、2035年度に保守終了
日立製作所 2017年にハードウェア製造から撤退。2026年5月にOS「VOS3」の販売を2027年11月、保守を2034年12月に終了する方針を発表
BIPROGY Unisys製メインフレームの事業から撤退。ハードウェア・OS・ミドルウェア・関連機器のすべてが対象で、時期は顧客と調整中
NEC ACOSシリーズを継続。2022年5月に新モデルを発表
IBM 継続

国内で継続を表明しているのはIBMとNECの2社です。

日立の販売終了は2027年11月。来年です。

減るのは台数だけではありません

アクセンチュアでモダナイゼーションを担当する中野恭秀氏は、この動きの影響を「国内のマーケットは半分以下になる」と見ています。そして、影響は台数の減少にとどまらないと指摘しています。

**ベンダーが抜けると、COBOLを扱う人材を育てる動きも細ります。**SIerを含めてです。移行を先送りするほど、移行を担える人が減る。この2つが同時に進むところが、通常の保守終了と違います。

AIの効きは移行元で変わります

ここからが本題です。

生成AIでレガシー刷新が速くなる、という話は広がっています。私たちもIBMがレガシー刷新AIで9カ月を3日にしたという発表を扱いました。依存関係の可視化、ビジネスロジックの文書化、Javaへの変換。従来コストがかかっていた工程は、確かに短くなっています。

ただし、その事例のほとんどはIBM系メインフレームの話です。

世界のメインフレーム市場はIBM製が9割以上を占めるとされます。オンライントランザクション処理はCICS、データベースはDb2。標準化された技術スタックで、GitHubにもドキュメントにも情報が積み上がっています。事前学習の量が出力の質を左右する生成AIにとって、これは得意な領域です。

日本は違います。富士通、日立、NECがそれぞれ独自の市場を築いてきました。富士通のオンライントランザクション処理はAIM/DCとネットワーク型データベース。文字コードも、2バイト文字を扱うためにベンダーごとの独自体系が使われています。

こうした技術スタックは、GitHubを含めて公開情報がほとんどありません。中野氏の言葉を借りれば「海外で成功したモダナイゼーションの手法やツールを、そのまま日本へ持ち込んでも通用しない」。

**学習データが薄い領域では、AIの出力は当然薄くなります。**これは道具の優劣ではなく、日本のメインフレームが世界標準から外れたところで育ったことの帰結です。

そこにバブルの後始末が乗っています

中野氏はもう1つ、技術以外の事情を挙げています。

「40年物、50年物のシステムともなれば、ソースコードがないプログラムが100本あることも当たり前」。バブル期に潤沢な資金で構築され、崩壊後に刷新のタイミングを逃し、必要最低限の改修を繰り返して延命されてきた。この経緯そのものが、いまの現場に残っています。

ソースコードがなければ、AIに読ませるものがありません。

それでもAIを使う場所はあります

効きが落ちるからAIを使わない、という結論にはなりません。使う場所が変わります。

**AIが強いのは、残っているものを読む工程です。**動いているコードの依存関係を洗い出す、ジョブの実行順序を再構成する、テストケースを現行動作から起こす。仕様書のないシステムを中身から把握する作業は、独自スタックでも成立します。読む対象が目の前にあるからです。

**AIが弱いのは、書かれていないものを埋める工程です。**独自ミドルウェアの挙動、独自文字コードの変換規則、サードパーティ製データベースの特殊な読み書き。ここは公開情報がないので、AIは知りません。ベンダーのドキュメントか、当時を知る人か、実機での挙動確認で埋めるしかありません。

見積もりを読むときは、この2つが分けて書かれているかを見てください。分けずに全体へ倍率をかけている提案は、測定範囲を示さない生産性の数字と同じ構造をしています。

メインフレーム移行の提案を受けたら聞く5点

  • 移行元は何ですか: IBM系か国産か。事例がIBM系なら、その短縮率は自社に当てはまりません。移行元を揃えた事例を出せるか確認します
  • 独自ミドルウェアの扱いはどこに書いてありますか: AIM/DC、独自文字コード、ネットワーク型データベース。公開情報のない部分を誰がどう解くのかが、工数の主な変動要因です
  • AIが読む工程と人が埋める工程は分かれていますか: 依存関係の解析はAIで速くなります。仕様の復元は人の作業です。分けずに全体へ倍率をかけた見積もりは根拠が確認できません
  • ソースコードの欠落はどこまで確認済みですか: 現物がないプログラムの本数を、契約前に数えます。ここが後から出てくると計画が崩れます
  • 保守終了年から逆算した工程になっていますか: 富士通は2035年度、日立は2034年12月。移行判断ではなく完了時期から引くと、着手の期限が決まります

移行コンペの質問状や、社内の投資判断資料にそのまま転記して使えます

現場メモ

私たちは国産メインフレームの移行を専門にしている会社ではありません。それでも、この記事を書いた理由があります。

レガシー刷新の相談で最初に聞くのは、いつも「現行の仕様がどこまで残っていますか」です。ドキュメント、テスト、当時を知る人。この3つの残り具合で、同じ規模のシステムでも工期が何倍も変わります。AIを使っても、この順序は変わりませんでした。

だから提案書に短縮率の約束は書きません。書けるのは「最初の現状調査で何を確かめるか」までです。メインフレームの撤退で期限が切られたいま、先に決めるべきなのは移行先の技術ではなく、現行仕様がどれだけ失われているかを数える時期だと考えています。ここが分かってから、初めて工期の話ができます。

期限から逆算する

保守終了は、移行の締切ではなく移行完了の締切です。日立のVOS3なら2034年12月。そこから運用の安定化、並行稼働、テスト、開発、現状調査と逆算していくと、着手の時期は思ったより手前に来ます。

そして先送りするほど、扱える人は減ります。ベンダーが抜け、COBOL人材の育成が細るという指摘は、待つことのコストが年々上がるという意味です。

自社のシステムで現行仕様がどこまで残っているのか、どこからAIで読めてどこから人が要るのかを整理したい段階でしたら、お問い合わせからご相談ください。移行先の選定ではなく、いま何が残っていて何が失われているかを数えるところから入ります。