COBOLマイグレーションの進め方｜段階的モダナイゼーション5つのフェーズとリスク管理

「システムは今日も正確に動いている。ただ、なぜそう動くのかを説明できる人がほとんどいない」――COBOLで構築された基幹システムを抱える企業の多くが、こうした状態に直面しています。

問題は品質ではなく、変更のスピードと選択肢の狭さです。新しい販売チャネルの追加、SaaSとのデータ連携、AIによる需要予測――新しい施策のたびに「既存システムに手を入れられるか」が最初の関門となり、企画そのものが縮小してしまう。この構造こそが、レガシー刷新を検討する本当のきっかけです。

この記事でわかること（情報システム部門責任者・CIO・CTO向け）

COBOL資産の刷新が優先課題になる8つの理由
マイグレーションとモダナイゼーションの違い、3つのアプローチの選び分け
AIに任せられること・任せてはいけないこと
5つのフェーズで進める移行プロセスとBAPの実績

なぜ今、COBOL資産の刷新が優先課題になるのか

COBOLの基幹システムを中心に置き、人材リスク、運用コスト、保守性、サポート終了、セキュリティとコンプライアンス、データ活用、市場投入までの時間、事業継続という8つの圧力が四方から向かっていることを示した図 — 図1：COBOL資産の刷新を後押しする8つの圧力

COBOLは「使われなくなった言語」ではありません。IPA「ソフトウェア開発分析データ集2022」でも開発言語として16.3%で第2位に位置し、金融・製造・流通の基幹領域では現役の技術です。IPAのDX SQUAREでも、刷新の判断基準は「技術の古さ」ではなく「ビジネスの変化に適応できるか」と整理されています。そのうえで、刷新が現実的な課題になる理由は次の8つです。

COBOL資産の刷新を後押しする8つの圧力
圧力	何が起きるか
1. 要員リスク	仕様を理解しているのは特定の担当者だけ。退職・異動がそのまま変更停止を意味し、COBOL技術者の外部調達も年々難しくなる
2. 運用コストの上昇	保守費に加え、影響範囲が読めないためテスト工数が膨らむ。「1行直すのに3か月テスト」が意思決定を遅らせる
3. 保守性の低下	長年の改修で分岐が増え、ブラックボックス化。改修よりも「改修してよいか」の調査に時間がかかる
4. 基盤のサポート終了	富士通はメインフレームの販売終了を2030年度、保守終了を2035年度と公表（いわゆる「2035年の崖」）。先送りするほど選択肢が狭まる
5. セキュリティ・監査	脆弱性対応や暗号方式の更新が難しくなり、要件に「構成上できない」と答える領域が増える
6. 連携性	データが基幹の内側に閉じ、BI・データ基盤・AI活用が中途半端に。個別バッチ連携の追加が新たなレガシーを生む
7. 開発スピード	フロントをアジャイル化しても、基幹側のリードタイムが変わらなければ全体は速くならない
8. 業務継続（BCP）	「動いているから安全」ではない。復旧できる人と手順がなければ、継続性リスクを抱えたままになる

出典：IPA「ソフトウェア開発分析データ集2022」、IPA DX SQUARE、日経クロステック

「マイグレーション」と「モダナイゼーション」は同じではない

検討初期に最も誤解されやすいのがこの点です。稼働環境を移すだけのマイグレーションと、保守・拡張しやすい構造に作り替えるモダナイゼーションは、まったく別の投資判断です。実務では、次の3つのアプローチを業務領域ごとに使い分けます。

3つのアプローチの比較
アプローチ	内容	向いているケース	留意点
リプラットフォーム（脱ホスト・基盤移行）	業務ロジックをほぼ維持したまま、基盤をオープン系・クラウドへ移す	保守終了が迫っており、まず基盤リスクを外したい。業務要件が安定している領域	保守性・属人性の課題は残るため、次の一手を前提に計画する
リファクタリング（COBOL→Java等）	Java/Springなど保守しやすい技術へ変換し、構造を整理する	今後も改修が続く中核業務。要員確保の裾野を広げたい領域	単純な機械変換では「Javaで書かれたCOBOL」になる。設計方針の事前定義が必須
リイマジン（業務機能の再設計）	API・マイクロサービス・クラウドネイティブで業務機能を設計し直す	競争力に直結する領域、外部連携や新チャネル対応が必要な領域	コストと期間が大きい。対象を絞り込むことが前提

現実的な進め方は「組み合わせ」

大規模な基幹システムでは、1つの方式を全体に当てはめるより、領域ごとに組み合わせるのが現実的です。たとえば、バッチ中心の定型業務はリプラットフォーム、改修頻度の高い受発注まわりはリファクタリング、外部連携が必要な一部機能だけをリイマジン。この配分の判断が、投資対効果を大きく左右します。

AI活用モダナイゼーション：どこまで任せ、どこから任せないか

モダナイゼーションでもAIの活用が急速に進んでいます。ただし、AIがプロジェクトを丸ごと自動で完了させられる段階にはありません。

AIが効果を発揮する領域

ソースコードの分類・棚卸し（現用／未使用／重複）
アプリケーション・ディスカバリと依存関係マッピング
設計書が失われた資産のドキュメント生成
業務ロジックの抽出・要約、コード変換の支援
テストケースの生成、テスト自動化、移行ウェーブ計画の支援

人が判断すべき領域

「この分岐は特定取引先向けの運用ルール」といった業務上の例外処理
「この丸め処理は会計方針に由来する」といった過去の経緯
新旧の出力差異が仕様か不具合かの判定
機能等価性の最終確認（業務部門の関与が不可欠）

BAPのアプローチ：AI-assisted / expert-led

AIが解析・生成のスピードを担い、レガシー領域の有識者、Java・クラウドのエンジニア、QA、業務部門が結果を検証します。AIは工数を圧縮する手段であり、業務判断の責任主体ではありません。この線引きを曖昧にしたプロジェクトは、テスト工程で破綻します。

COBOLモダナイゼーションの進め方：5つのフェーズ

調査、PoCとウェーブ計画、変換、等価性テスト、カットオーバーという5つのフェーズを横一列に並べ、各フェーズの成果物を示した図。品質を決める等価性テストがオレンジで強調されている — 図2：5つのフェーズと、各フェーズが出すべき成果

アプリケーション・ディスカバリと依存関係の可視化

プログラム・ジョブ・シェル・帳票・DBを棚卸しし、呼び出し関係とデータの流れを可視化します。「実際には使われていない資産」を切り分けられるかが、後工程の規模を左右します。業務部門へのヒアリングで、文書化されていないルールも引き出します。

PoCと移行ウェーブの計画

代表的な難易度の業務を1つ選び、変換方針・アーキテクチャ・テスト手法を実証します。目的は「できるか」の確認ではなく、本番規模の工数・品質・リスクを見積もれる状態にすること。その結果をもとに移行ウェーブと切替方式（並行稼働の要否を含む）を決めます。

ソースコード・画面・データ・基盤の変換

コード変換に加え、画面のWeb化、帳票の再構築、文字コードやデータ型の差異を含むデータ移行、ミドルウェア・ジョブ運用の移行を並行して進めます。「どのCOBOLプログラムがどのJavaクラスに対応するか」を常に追跡できる状態を保ちます。

機能等価性テストと品質保証

モダナイゼーションの品質はこの工程で決まります。旧系と新系が同じ入力に同じ結果を返すことを、証跡として示す必要があります。

単体テストコンポーネントテストバッチ結果の突合比較結合テストデータ整合性検証システムテスト性能テスト（バッチウィンドウ）セキュリティ検証リグレッションテスト受入テスト（UAT）

カットオーバー、安定稼働、継続的改善

手順書と切戻し条件をセットで準備し、切替直後は監視体制を厚くします。モダナイゼーションはカットオーバーで終わりではありません。保守しやすい構造を得た後、API化やクラウド活用を段階的に進めて初めて投資が回収されます。

モダナイゼーションで得られるビジネス価値

価値	内容
運用リスクの低減	サポート終了基盤から脱却し、障害時に対応できる人員を増やせる
要員依存の緩和	Javaなど採用母集団の大きい技術へ移り、体制を再構築しやすくなる
保守性の向上	構造とドキュメントが整い、改修時の調査工数が下がる
リリースサイクルの短縮	影響範囲が読めるため、テスト範囲を合理的に絞り込める
連携性の獲得	API・クラウド・データ基盤・AIへの接続点が生まれる
業務ロジックの保全	長年検証されてきた業務ルールを、説明可能な形で引き継げる
操作性の改善	画面のWeb化で端末・ブラウザの制約や操作性の課題を解消できる

※削減率や投資回収期間は、対象資産の規模・構造・業務要件によって大きく異なります。数値目標は現行資産の調査結果をもとに設定する必要があります。

BAPの実績：業務プロセスを変えずに基幹業務を新基盤へ

BAPは、受注管理・生産・在庫・出荷といった基幹業務を、既存の業務プロセスを変更しないという前提で旧システムから新プラットフォームへ移行するプロジェクトに参画しました。

約90本

ユーザー画面

約300本

アプリケーションプログラム

約85本

バッチ・運用シェル

約65本

DBテーブル

BAPは現地での要件確認・システム分析、移行方式の提案、開発支援に加え、コンポーネントテストからユーザー受入テストまでを担当しました。「業務プロセスを変えない」という制約は、裏を返せば機能等価性の立証がプロジェクトの中心課題になるということ。テスト工程を上流から設計に組み込む進め方が特に重要です。

BAPの支援領域

領域	内容
現状調査・分析	資産棚卸し、依存関係の可視化、業務ヒアリング、移行方式の比較検討
PoC	本格展開前の実証と、工数・品質・リスクの見積り精度向上
段階的移行	業務単位・データ単位での移行ウェーブ設計と実行
開発	COBOL→Java変換、Java/Springによる開発、Web画面・帳票の再構築
基盤・データ	プラットフォーム／ミドルウェア移行、データ移行と整合性検証
品質保証	単体〜UATまでのテスト、バッチ突合、性能・セキュリティ検証
デリバリー体制	オフショア／オンサイト／ハイブリッド。日本語・英語・韓国語・ベトナム語で対応
刷新後の保守運用	安定稼働支援、継続的な改善・機能追加