メインフレーム撤退時代、中堅企業はいつ・何を決めるべきか

はじめに

「保守終了はまだ10年近く先。今すぐ動く必要はあるのか」

富士通に続き、日立製作所、BIPROGYも相次いでメインフレーム事業からの撤退を明らかにしました。ニュースとしては知っていても、自社にとって「いつまでに、何を決めればよいのか」が整理できていない企業は少なくありません。

結論から言えば、保守終了の年を起点に逆算すると、多くの中堅企業に残された「検討だけに使える時間」は2〜3年程度です。移行そのものに数年、並行稼働とテストに1年以上かかるためです。

一方で、焦って移行方式を決めるのも危険です。調査会社Gartnerは、2026年に始まるメインフレーム脱却プロジェクトの70%超が期待した成果を得られないと予測しています。その主な理由として挙げられているのが、生成AIへの過度な期待です。

本記事では、IT予算と人材が限られる中堅企業を対象に、次の3点を整理します。

1. 各ベンダーの撤退スケジュールと、そこから逆算した意思決定のタイムライン
2. 延命から再構築まで、5つの選択肢の比較
3. 方式を決める前の「最初の90日」でやるべきこと

何が起きているのか：国内メインフレームの「終わり」が確定した

国産メインフレームを提供してきた主要ベンダーのうち、富士通と日立は販売・保守の終了時期を公表し、BIPROGYも撤退を明らかにしています。

ベンダー	対象	販売終了	保守終了
富士通	GS21シリーズ	2030年度	2035年度
日立製作所	メインフレーム向けOS「VOS3」（ハード製造は2017年に終了済み）	2027年11月	2034年12月
BIPROGY	Unisys製メインフレーム	撤退方針を表明（詳細は同社の案内を参照）	撤退方針を表明（詳細は同社の案内を参照）

※2026年10月時点の報道に基づく。最新の日程は各ベンダーの公式発表をご確認ください。

日立の発表は2026年5月で、地方銀行の共同利用型勘定系システムにも影響が及ぶと報じられました。金融機関のような大規模ユーザーが移行を急ぐと、移行を支援できるベンダーや技術者の取り合いが起きます。中堅企業ほど、後回しにされやすい立場にあります。

なお、日本のメインフレーム事情は海外と異なります。欧州では各国のベンダーが撤退し、IBMが事実上の標準になりました。一方、日本では富士通・日立・NECが長く独自のメインフレームを維持してきたため、海外の移行事例や手法がそのまま当てはまらないという指摘もあります。

中堅企業にとって本当の問題は「ハードウェア」ではない

保守終了の本当のリスクは、機械が止まることではなく、移行を判断・実行するための「材料」と「人」が揃わないことです。中堅企業では、次の4つが同時に起きやすくなります。

1. 仕様が分からない

数十年にわたり改修を重ねた結果、仕様書と実際のプログラムが一致していないケースが多くあります。何を移行すべきかが分からなければ、移行方式も見積もりも決められません。

2. 分かる人がいない、または近く退職する

COBOLやJCL、独自のバッチ運用を理解している担当者は、社内に1〜2人という企業も珍しくありません。その人が退職すれば、現状分析そのものが困難になります。

3. 移行を支援する側の人手も足りない

大手企業や金融機関の移行案件が本格化すると、メインフレームに詳しい技術者は大規模案件に集中します。期限が近づくほど、見積もりは高く、着手は遅くなります。

4. 決める人が「技術の話」だと思っている

メインフレーム移行は、業務の見直し、予算、事業継続に関わる経営判断です。情報システム部門だけで方式を決めると、後から業務部門の要件が噴き出し、計画が崩れます。

これらは、ハードウェアの保守期限よりずっと早く表面化します。だからこそ、移行方式より先に「判断できる状態をつくること」から始める必要があります。

いつまでに何を決めるか：保守終了からの逆算

富士通GS21（保守終了2035年度末）を例に逆算すると、移行方式の決定は遅くとも2029年度頃、現状分析は2027年度中に終えておくのが一つの目安です。日立VOS3（保守終了2034年12月）の場合は、全体を約1年前倒しで考える必要があります。

フェーズ	一般的な所要期間（中堅規模の目安）	富士通GS21の場合の目安
① 現状分析・棚卸し	3〜6か月	2026〜2027年度
② 方針決定・予算化	6〜12か月	〜2028年度
③ ベンダー選定・要件定義	6〜12か月	〜2029年度
④ 移行開発	1.5〜3年	2029〜2033年度
⑤ 並行稼働・総合テスト・切替	1年前後	2033〜2034年度
予備期間（遅延・繁忙期回避）	1年程度	2035年度

※所要期間はシステム規模、本数、データ量、業務部門の体制によって大きく変わります。上記は一般的な目安であり、個別の計画は現状分析の結果をもとに立てる必要があります。

日立のケースでは、保守終了より前に販売終了（2027年11月）が来ます。販売終了後は、増設や構成変更の選択肢が限られる可能性があるため、処理量の増加が見込まれる企業は早めに確認しておくべきです。

逆算して分かるのは、「まだ先」と感じている今が、実は現状分析に着手すべき時期だということです。

5つの選択肢：どれか一つに決める必要はない

メインフレームからの移行には大きく5つの選択肢があり、実際には業務領域ごとに組み合わせるのが現実的です。

選択肢	内容	向いているケース	主なリスク
他社メインフレームへの乗り換え	IBMなど提供が続くメインフレームへ移す	処理量・信頼性要件が非常に高く、オープン化のコストが見合わない	新たなベンダー依存、人材問題は残る
リホスト	プログラムをほぼそのまま、オープン環境やクラウド上のエミュレーション基盤へ移す	期限が迫っており、まずハードウェアリスクを下げたい	複雑さ・属人化はそのまま残る
リライト（言語変換）	COBOLなどをJava等へ変換する	ロジックは有効だが、言語と基盤を現代化したい	構造が古いまま残り、変換後も保守しにくい
パッケージ・SaaSへの置き換え	会計・人事など標準的な業務を製品へ移す	他社と差がつきにくい業務	業務を製品に合わせられないと過剰なカスタマイズに
再構築	業務を見直したうえで新たに設計・開発する	競争力に直結し、業務自体を変える必要がある	要件の肥大化、期間とコストの増大

特にリライトには注意が必要です。機械的な言語変換では、COBOLの設計思想や処理構造がJavaにそのまま持ち込まれ、いわゆる「JaBOL」化して、移行後の保守や拡張が難しくなるケースがあります。

例えば、標準的な会計はSaaSへ、独自の受発注ロジックは再構築、安定した周辺バッチはリホストで先に移す、といった組み合わせが考えられます。どの領域にどの方式が合うかを判断する観点は、レガシーシステムは延命・改修・再構築のどれを選ぶべきか｜7つの判断基準で詳しく解説しています。

最初の90日でやるべきこと

最初の90日のゴールは、移行方式を決めることではなく、経営層が判断できる材料を一枚にまとめることです。

1〜30日目：体制と範囲を決める

• 経営・業務・情報システムの責任者を一人ずつ決める
• 対象システムと、今回は対象外とするものを明文化する
• 社内でメインフレームを理解している人をリストアップし、退職予定を確認する
• 現行ベンダーとの保守契約、ライセンス、ハードウェア更新の時期を確認する

31〜60日目：事実を集める

• プログラム本数、言語、JCL、バッチ、帳票、外部連携の一覧をつくる
• 各機能を、どの部門のどの業務が使っているかと結び付ける
• 実際に使われていない機能を洗い出す（廃止候補）
• ベテラン担当者へのヒアリングを、録音・記録しながら優先的に進める

61〜90日目：判断材料にまとめる

• 業務領域ごとに「事業上の重要度」と「技術的な難易度」で分類する
• 領域ごとに有力な選択肢を2つ程度に絞る
• 概算の費用と期間の幅、今後5年の維持コストとの比較をまとめる
• 次の半年で何をするか（詳細分析、PoC、ベンダー選定）を決める

この段階で外部の支援を使う場合も、「移行ありき」の提案ではなく、現状分析と判断材料の整理から伴走してくれる相手かどうかを確認してください。

AIはどこまで使えるか：「変換」より「理解」に使う

生成AIは、メインフレーム移行を自動で終わらせる道具ではありません。最も効果が出やすいのは、変換の前段階にある「現状の理解」です。

Gartnerは2026年6月、2026年に始まるメインフレーム脱却プロジェクトの70%超が想定した効果を得られないと予測しました。理由として、生成AIツールの能力に対する宣伝と実態の差、長年の改修で複雑化したコード、経験者の急減を挙げています。同社はさらに、2030年までにメインフレーム脱却市場のベンダーの75%が事業転換か撤退を迫られるとも見ています。

だからといって、AIを使わないのが正解でもありません。役割を分けることが重要です。

工程	AIが支援できること	人が判断すべきこと
コード理解	処理の要約、プログラム間の呼び出し関係やデータの流れの抽出	抽出結果が実際の動きと合っているか
仕様の復元	仕様書・フロー図の下書き作成	例外処理や暗黙の業務ルール
棚卸し	未使用・重複プログラムの候補抽出	本当に廃止してよいか
移行設計	方式ごとの影響範囲の比較	費用、リスク、最終方針
テスト	テストケース・データの作成支援	業務上の重要シナリオと受入判断

AIが出した分析は「仮説」として扱い、ベテラン担当者の知見や実際の稼働ログと照らし合わせて確定させます。AIで分析を速くし、人が判断の責任を持つ。この分担ができていれば、ベテランが在籍している間に、より多くの暗黙知を形にできます。

よくある質問

Q. 保守終了まで使い続け、その後に考えるのは現実的ですか？

A. おすすめしません。保守終了の直前は移行需要が集中し、支援できる技術者の確保も難しくなります。また、移行には分析から切替まで数年かかるため、保守終了後の障害時に頼れる先がない期間が生まれるおそれがあります。

Q. 第三者保守を使えば延命できますか？

A. 一定期間の延命策にはなり得ますが、部品やOSの更新、セキュリティ対応には限界があります。延命する場合も、期限と再評価の時期を決め、その間に現状分析を進めることが前提です。

Q. 生成AIでCOBOLを一気にJavaへ変換できませんか？

A. 変換自体は可能でも、それだけで移行が成功するとは限りません。構造の古さがそのまま残ったり、業務上の例外処理が漏れたりするリスクがあります。AIはまずコードと仕様の理解に使い、変換は検証可能な範囲から段階的に進めるのが安全です。

Q. 現状分析だけを外部に依頼することはできますか？

A. 可能です。むしろ、移行方式やベンダーを決める前に、利害関係の少ない立場で現状を可視化しておくと、その後の比較検討がしやすくなります。

まとめ：今決めるべきは「方式」ではなく「始め方」

国内ベンダーの撤退により、メインフレームを使い続けるという選択肢には期限が付きました。保守終了から逆算すると、中堅企業が現状分析に着手すべき時期は、すでに来ています。

一方で、焦って移行方式を決めたり、AIによる自動変換に過度に期待したりすることも失敗の原因になります。最初にやるべきことは、次の3つです。

1. 責任者と対象範囲を決める
2. ベテランが在籍しているうちに、仕様と業務の事実を集める
3. 業務領域ごとに選択肢を絞り、経営層が判断できる材料にまとめる

移行の成否は、最初の90日で「判断できる状態」をつくれるかどうかで大きく変わります。

メインフレーム移行の「最初の一歩」をご支援します

Synoraでは、ソースコード、JCL、既存ドキュメント、システム間の依存関係をAIと専門エンジニアで分析し、現状の可視化から領域ごとの移行方針の整理までを支援します。特定の移行方式を前提とせず、事業の優先順位と予算に合わせて、現実的なロードマップをお客様とともに設計します。

「自社のシステムがどの状態にあるのか、まず知りたい」という段階からご相談いただけます。