「メインフレームを止めたい、しかし止められない」。この板挟みで動けなくなっている情報システム部長や DX 推進責任者の相談を、この 1〜2 年で何度も受けるようになりました。動いてはいる、しかし COBOL を触れる要員が定年で去り、保守費は年ごとに膨らみ、ベンダーからは「もう次の保守契約は延長できない」と匂わされる。放置は無理、しかし全面刷新は数億円と数年の話になり、経営会議で議題に上げても結論が出ない。本記事は、この典型的な状況に置かれた担当者に向けて、メインフレームのリプレイスを段階移行に落とし込むための進め方と、費用・期間の相場感を実案件ベースで整理した実務ガイドです。
結論: 「2025 年の崖」以降のメインフレーム リプレイスは段階移行が前提
先に結論を書きます。「2025 年の崖」以降のメインフレーム リプレイスは、全機能を一気に作り直して切り替える「フルリライト＋ビッグバン移行」よりも、区画を絞って少しずつ新側へ寄せていく段階移行のほうが、ほとんどのケースで安全です。理由は 2 つあります。
1 つ目は、メインフレームが企業の勘定系・契約系・生産管理系といった止めたら会社が回らない領域を担っていることが多く、切り替え当日の一点にリスクを集中させるビッグバン移行は事業への影響が大きすぎるという点です。想定外が出て切り戻すにも、メインフレーム側の設定を触った時点でそのまま元通りにはしにくくなります。
2 つ目は、COBOL 資産の読み解きに時間がかかり、「全部把握できた」と思ったあとから抜けが見つかるのが常だという点です。COBOL のプログラムには、コメントに残っていない業務ルールや、コピー句 (COPY 句) を経由した暗黙の依存、JCL に埋め込まれた運用ノウハウが積み重なっており、これは一度に全部を読み切れる規模ではないことがほとんどです。段階移行を取れば、この抜けが本番に出てもその区画に閉じ込められ、他の区画は旧側で動き続けます。
注意
メインフレームは企業の中核業務を担っていることが多く、ビッグバン移行の一点集中リスクは事業影響が桁違いになります。COBOL 資産の読み解きの抜けが後から発覚することを前提に、区画を絞って少しずつ切り替えられる段階移行を軸に組むのが安全です。
段階移行の中身、つまり区画をどう切り、どの順で新側に寄せるかは、汎用の システムリプレイスの進め方完全ガイド で 7 ステップの型を整理しています。本記事はその型を前提に、メインフレーム固有の論点、つまり COBOL の読み解き、VSAM や DB2 のデータ移行、金融・保険領域での監査対応、実案件の費用と期間、といったところを掘り下げます。
メインフレームがまだ現役の日本の実態と、EOL・保守要員の枯渇圧
日本のメインフレーム リプレイスが特殊なのは、市場全体でメインフレームが縮退している一方、日本の主要 SIer は自社製メインフレームの保守撤退や新規販売終了のスケジュールを近年立て続けに公表しているという背景があるためです。実際、大手メーカーは 2020 年代後半から 2030 年代前半にかけてメインフレーム事業の縮小・撤退を打ち出しており、「あと数年でメーカーの保守が受けられなくなる」という話が、経済産業省が指摘した「2025 年の崖」の当時よりも一段リアルなラインとして迫っています。
これに加えて、COBOL を業務レベルで書き直せる要員が加速度的に減っています。COBOL エンジニアの平均年齢は上がる一方で、若手が新規参入するインセンティブは薄く、既存要員の定年退職と入れ替わる形での要員確保が構造的に難しくなっています。ベンダーが数年後に保守撤退を予告し、社内保守要員も定年で減っていく。この 2 つが同時に効いてくるのが、いま多くの企業が置かれている状況です。
FIXITメインフレームってまだ動いてるならそのまま使っちゃダメなの？
動いてる間はいい選択に見えるんですけど、ベンダーの保守撤退と社内の COBOL 要員の定年退職が同時に効いてくるんですよね。
Hayateある日突然「もう保守できません」と言われたときには、リプレイスに要る 1 〜 2 年の時間が残ってなかったりします。
FIXITHayateまずは「業務を変えたいかどうか」で選択肢を絞るところから始めるといいですよ。
「まだ動いている」の裏側で、リプレイスに使える時間は静かに削られています。着手のタイミングを「保守撤退の通告が来てから」に置くと、選択肢がリホスト一択に狭まり、価格交渉の余地もなくなります。相場を掴んで議論を始めるのは、少し早いくらいでちょうど良いフェーズです。
リプレイスの選択肢 4 系統と判断軸
メインフレーム リプレイスには、大きく次の 4 系統の選択肢があります。実務では 1 つに決めきるのではなく、ドメインの区画ごとに方針を分けて組み合わせるのが普通です。
| 選択肢 | 主に変えるもの | 業務フローの扱い | 向く状況 |
|---|---|---|---|
| 延命保守 | 何も変えず、保守運用を継続 | 現状維持 | 2〜3 年で撤廃決定済みで、それまで持たせたい |
| リホスト | 動く基盤 (メインフレーム→x86 サーバー・クラウド) | 業務は変えない | 保守撤退が近く、時間と予算が限られている |
| リアーキテクト | 内部構造・技術スタック (COBOL→Java や Kotlin など) | 業務はおおむね維持 | 動いているが手を入れづらく、保守性を戻したい |
| フルリライト | システム全体と業務フロー | 業務そのものを見直す | 老朽化に加え、業務そのものを変えたい |
判断は 3 つの軸で行います。
**1 つ目は「業務フローを変えたいかどうか」**です。業務を変えずに基盤だけを新しくしたいならリホストが最短で、業務の見直しを含みたいならリアーキテクトかフルリライトの範疇に入ります。ここを最初に決めないと、次の 2 つの判断が空中戦になります。
**2 つ目は「保守要員と設計情報がどれだけ残っているか」**です。COBOL の有識者や設計書が枯渇しているほど、業務ルールを新側にテストとして書き起こしていくリアーキテクトやフルリライトが現実解になっていきます。設計書はなくても、新システム側にテストを書き足していけば、それがそのまま生きた仕様書として残ります。
**3 つ目は「並行稼働できる期間と予算」**です。リホストは早く安く終わる代わりに古い業務の悪癖もそのまま引き継ぎ、リアーキテクトやフルリライトは期間と費用が伸びる代わりに数年後の保守性で回収します。5 年後にもう一度リプレイスの話をしたいのか、10 年は塩漬けにしたいのかで、この選択は変わります。
前述のとおり、実務では 1 つに決めきりません。会計連携部分はリホストで畳み、受発注部分はリアーキテクトで書き直し、新規機能は最初から新基盤でフルスクラッチ、というように、ドメイン責務マップの区画単位で使い分けるのが標準です。見積もりも移行順序もこの単位で分けて考えると、一枚岩で見たときには非現実的だった数字が、区画ごとには実行可能なラインに落ちてきます。区画をどう切るかの汎用手順は システムリプレイスの進め方完全ガイド にまとめています。
AI 駆動で COBOL を読み解いてドメイン責務マップを作る手順
メインフレーム リプレイスで最も時間を吸われるのが、この「現状の COBOL とデータ資産を読み解く」フェーズです。設計書は残っていない、あっても実態と食い違っている、書いた人はもう社内にいない、という状況がほぼ標準で、ここを人手だけで詰めようとすると数ヶ月から半年単位で消えていきます。
この工程は AI 駆動開発と特に相性が良い領域です。COBOL コードとコピー句、JCL のジョブ定義、VSAM や DB2 のスキーマ定義を Claude Code などの AI コーディングツールに読み込ませ、各プログラムの責務、データの流れ、暗黙の業務ルールを要約させると、人手だけで追うより短期間で全体像をつかめます。前提として、AI が出力するのはあくまで仮説であり、そのまま正解として扱うと危険という点は忘れないでください。重要な業務ルールは、後工程でテストと現場ヒアリングで裏取りする運用を組み込みます。
具体的な進め方は次の 4 ステップです。
- COBOL プログラムを機能単位に切り、AI に処理の要約を出させる。プログラム全体を一度に読ませず、CICS トランザクションやジョブ単位に分割して読ませると、精度が上がります。
- コピー句とデータ定義から、データの実態を復元する。同じ物理項目を複数のプログラムがどう解釈しているか、COMP 系のパック形式や再定義でどう使い回されているか、といったメインフレーム特有の癖をここで洗い出します。
- JCL とバッチのスケジュールから、業務のリズムを復元する。月末締めや日次バッチの依存関係は JCL に埋め込まれていることが多く、これを追わずに個別プログラムだけ読むと、後工程でバッチ順序の抜けが本番事故になります。
- 推定した業務ルールを、ドメインの区画ごとにまとめる。受注、在庫、請求、契約、といった業務のまとまりで整理し、まとまり間の依存を矢印で描いたものがドメイン責務マップになります。段階移行の順序は、このマップの上で「依存の少ない末端から」の原則で組みます。
この読み解き工程を AI に任せると、従来 3〜6 ヶ月かかっていた棚卸しが、1〜2 ヶ月まで圧縮できるケースが増えています。ただし、AI に読み解きを丸投げして裏取りを省くと、誤った業務ルールを新システムに固定してしまい、後で高い修正費用を払うことになります。AI に読み解きを任せ、業務ルールをテストとして書き起こし、現場ヒアリングで裏を取る。この分担が、期間を縮めつつ品質を守る勘所です。AI の出力をどう検証に組み込むかは AI 駆動 TDD の考え方が参考になります。
データ層の移行 (VSAM や DB2 から PostgreSQL・Aurora へ)
メインフレーム リプレイスで最も事故が起きやすく、かつ最も軽視されがちなのがこの工程です。VSAM の KSDS や ESDS、DB2 for z/OS のテーブル、といったメインフレーム側のデータを、PostgreSQL や Amazon Aurora のような一般的なリレーショナルデータベースへ移し替えるとき、そのままの直訳では通らない差異がいくつも出てきます。
主な事故ポイントは 5 つです。
- 文字コード。EBCDIC から UTF-8 へ変換するとき、独自の外字や旧字体の扱いで文字化けが発生します。
- 数値の格納形式。COMP-3 のパック 10 進数や、ゾーン 10 進数の負号処理は、そのまま数値カラムへ入れると桁あふれや符号反転を起こします。
- 日付・時刻。西暦下 2 桁での格納や、うるう年判定の実装が旧側にあると、新側の日付型に入れた瞬間に整合性が崩れます。
- VSAM のキーとインデックス設計。KSDS の代替インデックス (AIX) を単純にセカンダリインデックスに写すと、リレーショナル的には性能が出ない構造になることがあります。
- DB2 の分離レベルとロック。z/OS 版 DB2 特有の分離レベル指定や、行ロックの粒度に依存した業務ロジックが、新側の PostgreSQL・Aurora ではそのまま再現できないケースがあります。
これらの事故を防ぐ王道は、本番相当のデータを使って ETL のリハーサルを繰り返すことです。移行スクリプトを流し、移行後のデータが正しいかを件数照合と金額の突合で検証する。一度で完璧になることはまずなく、上記のような問題が必ず出ます。だからこそ、本番当日にぶっつけで流すのではなく、リハーサルを複数回回して手順とスクリプトを枯らしておきます。
コツ
データ移行は本番当日にぶっつけで流さず、本番相当のデータでリハーサルを 20 回以上回す前提で計画します。あわせて移行にかかる実時間も計測しておかないと、許容できる停止時間に収まるかを当日まで判断できません。
リハーサルの回数は、金融や保険といった止められない領域では 20 回以上を目安に取ることが多いです。そこまでいかない領域でも、10 回は下回らないほうが安全です。ETL リハーサルの具体的な設計は データ移行の ETL リハーサル 実務プレイブック に別立てで整理しています。
実案件の費用と期間レンジ
メインフレーム リプレイスの費用と期間は規模で大きく動きますが、実案件で見えているレンジはおおむね次のとおりです。
| 規模の目安 | 期間 | 費用レンジ (税抜) |
|---|---|---|
| 単一領域 (会計、生産、在庫のいずれか 1 つ) | 12〜18 ヶ月 | 5,000 万〜1 億円 |
| 複数領域を含む基幹の一部 (受発注＋在庫など) | 18〜24 ヶ月 | 1 億〜2 億円 |
| 全社基幹 (勘定系、契約系など全面刷新) | 24 ヶ月以上 | 2 億〜3 億円以上 |
費用と期間を左右するのは、対象システムのステップ数そのものよりも、次の変動要因です。
- 外部連携の数。連携先が多いほど、相手側の都合に合わせた検証と切り替え調整が増えます。特に金融の全銀・SWIFT・BOJ、保険の代理店ネットワークなど、業界共通のプロトコルを介した連携は、新側実装の後に相手側の互換確認が要ります。
- データ移行の複雑さ。データの量よりも、過去データの汚れ、システムをまたいだ整合性、法定保管期間との兼ね合いが工数を押し上げます。金融・保険では 10 年前のデータまで整合性を保った状態で移す必要があり、ここで大きな期間を取られます。
- 設計情報の残り具合。設計書が存在せず現状把握から始める案件は、AI 駆動の読み解きを使っても、現場ヒアリングと裏取りの工数がそのまま費用に乗ります。
- 並行稼働の期間。新旧を同期する仕組みの維持コストは、並行稼働が長引くほど積み上がります。金融・保険の勘定系・契約系では、月次や年次の締めを一巡させる必要があり、並行稼働が最低 1 年は下回らないケースが多いです。
AI 駆動開発を取り入れると、これらのうち特に現状 COBOL の読み解きと再実装の工数を圧縮できます。実案件の感触では、従来開発と比べて期間がおおむね半分から 3 分の 2 程度に短縮できることが多いです。ただし、データ移行のリハーサルや外部連携先との調整、現場ヒアリングといった工程は AI で短縮しにくく、ここを削ると事故に直結します。費用が期間と同じ比率でそのまま下がるわけではない、という点は見積もりを読むときに意識してください。
規模別の類似案件の相場感は レガシー刷新の費用と期間 にもまとめており、メインフレーム以外のレガシー刷新と並べて相対的な位置を確認できます。
段階移行 vs ビッグバン移行の使い分けと、実際にビッグバンで失敗する構図
メインフレーム リプレイスの計画で、いまだに議題に上がるのが「段階移行にするか、ビッグバンで一気に切り替えるか」の議論です。結論は前述のとおり段階移行が原則ですが、ビッグバンを検討するケースが皆無というわけではありません。次のような条件がすべて満たされる場合に限って、ビッグバン移行が現実的な選択肢になります。
- 対象システムの規模が小さく、業務ルールと外部連携が隅々まで文書化されている
- データ量が少なく、切り替え時の停止時間が業務上許容される (数時間〜半日)
- 保守撤退の通告が迫っており、並行稼働のコストと期間を負担できない
- 経営層が事業影響を織り込んだうえで一点集中リスクを引き受ける意思決定をしている
これらのうち 1 つでも欠けると、ビッグバン移行は失敗確率が急に跳ね上がります。過去に大手企業や自治体で公表されたビッグバン失敗のケースを追うと、共通しているのは「切り替え当日まで新旧を突き合わせた検証ができていなかった」「データ移行のリハーサル回数が足りていなかった」「事後の切り戻し手順が計画に含まれていなかった」の 3 点です。段階移行を取れば、これらのいずれかが欠けていても被害はその区画に閉じ込められます。
現実的には、金融・保険・自治体・製造の基幹領域では、段階移行を軸にしたうえで、区画の切り替え当日だけをビッグバン的に扱う、という組み合わせが標準です。全体は段階、区画内はビッグバン、という粒度で考えると、実行可能な計画に落ちやすくなります。
監査対応・法定保管との両立
金融・保険・自治体の基幹領域では、リプレイス期間中も監査対応と法定保管の要件を満たし続ける必要があります。ここを見落とすと、リプレイスが順調に見えていても、監査対応で足を取られて期間が伸びるケースがあります。押さえておくべきポイントは次の 3 つです。
1 つ目は、旧システムのアクセスログと変更履歴の保全です。並行稼働中も、旧側で発生した業務は監査対象になります。旧側のログを新側と同じフォーマットで蓄積するか、少なくとも突合可能な形で保管しておく設計にしておくと、監査時に「新旧をまたいだ検索ができない」という事故を防げます。
2 つ目は、法定保管期間中のデータ参照経路の確保です。銀行の勘定系や保険の契約系では、10 年以上前のデータまで参照可能にしておく義務があります。旧側を停止する前に、法定保管対象のデータを新側または独立したアーカイブへ移し、参照経路を用意しておかないと、旧停止のタイミングで参照ができなくなります。
3 つ目は、監査時の証跡としてのテスト成果物です。前述のとおり、業務ルールを新システム側にテストとして書き起こしていく進め方を取ると、そのテスト成果物が「新旧で業務ルールが一致していること」の証跡としてそのまま監査対応に使えます。監査対応を後工程の別作業として立てるのではなく、開発工程のテスト成果物をそのまま監査証跡にするという流れを最初から組んでおくと、期間と費用の両面で無駄が減ります。
失敗を避けるチェックリスト
ここまでの内容を、着手前に確認できるチェックリストとして整理します。
- 選択肢を「延命保守・リホスト・リアーキテクト・フルリライト」で棚卸しし、区画ごとに方針を分けているか
- COBOL 資産の読み解きを、AI 駆動で圧縮しつつ、業務ルールをテストと現場ヒアリングで裏取りする運用になっているか
- VSAM や DB2 のデータ移行を、本番相当データで 10 回以上リハーサルする計画になっているか
- 段階移行を軸にし、Feature Flag と並行稼働で切り戻せる手順を用意しているか
- 並行稼働の期間中に、月次・年次の締め処理と法定業務を一巡させる計画になっているか
- 金融・保険・自治体では、監査対応の証跡と法定保管の参照経路を旧停止前に確保しているか
- 保守撤退の通告が来る前に着手できる時間軸で議論しているか
これらを満たしたうえで、AI 駆動開発が効くのは「COBOL 資産を読み解く速度」と「新側での再実装の速度」です。設計書のない COBOL を読み解く作業は、従来はごく一部のベテランしか担えず、ここが工程全体のボトルネックでした。コードベースを AI に読ませて責務とデータの流れを要約させ、推定した業務ルールをテストに固定し、AI に実装させてテストで検証する。このループを速く回せると、最も時間のかかっていた前半工程が圧縮され、全体の期間が大きく縮みます。
一方で、AI に任せてはいけない判断もはっきりしています。どの区画を先に切り替えるかという移行順序、データ移行の正しさの最終確認、監査対応の証跡設計、旧システムを止める意思決定。これらは業務とリスクへの理解が要る判断で、人間が握り続ける必要があります。
要点
AI に任せるのは COBOL 資産の読み解きと新側の再実装、人間が握るのは区切りの単位を決める移行設計、反映の順序とタイミング、データ移行と監査対応の最終確認、旧システムを止める意思決定です。この線引きが、品質を落とさずに期間を縮める勘所になります。
メインフレーム リプレイスのご相談
メインフレーム リプレイスは、進め方の前半、特に COBOL 資産の読み解きと区画の設計で勝負が決まります。「保守撤退の通告が来る前に、選択肢を握っておきたい」「区画ごとの見積もりを分けて取りたい」という状況こそ、AI 駆動開発で読み解きと再実装を加速できる領域です。FIXIT では基幹システムの刷新・リプレイスの無料相談を承っています。現状の課題や対象システムの規模が固まっていない段階でも構いません。まずは システム刷新・リプレイスのサービス内容 をご覧いただき、お問い合わせ からお気軽にご相談ください。