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

「システムは今日も正確に動いている。ただ、なぜそう動くのかを説明できる人がほとんどいない」——基幹システムのCOBOL資産について、こうした状態に置かれている企業は少なくありません。

受発注、生産、在庫、出荷、原価といった業務は、20年以上前に書かれたプログラムの上で今も止まらずに処理されています。つまり、品質そのものが問題なのではありません。問題になっているのは変更のスピードと、選べる選択肢の幅です。新しい販売チャネルを追加したい、SaaSとデータ連携したい、需要予測にAIを使いたい——そのたびに「既存システムに手を入れられるかどうか」が最初の関門になり、企画そのものが縮小してしまう。この構造こそが、多くの企業がレガシーシステム刷新を検討し始める実際のきっかけです。

本記事では、COBOL資産を抱える企業の情報システム部門責任者・CTO・CIOに向けて、マイグレーションとモダナイゼーションの違い、リプラットフォーム／リファクタリング／リイマジンの選び分け、AIの現実的な使いどころ、そして5つのフェーズからなる移行プロセスを整理します。

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

COBOLは決して「使われなくなった言語」ではありません。IPAの調査でも、開発言語としてCOBOLは依然として上位に位置づけられており（IPA「ソフトウェア開発分析データ集2022」では16.3%で第2位）、金融・製造・流通の基幹領域では現役の技術です。IPAのDX SQUAREでも、レガシー刷新の判断基準は「技術の古さ」ではなく「ビジネスの変化に適応できるかどうか」だと整理されています。

そのうえで、刷新の検討が現実的な優先課題に変わる理由は、おおむね次の8点に集約されます。

1. 要員リスク（属人化と技術者の減少）

仕様書が更新されていない、あるいは存在しない。結果として、業務ロジックを正確に理解しているのは長年担当してきた特定の技術者だけ、という状態が生まれます。その方の退職や異動が、そのままシステム変更の停止を意味してしまう。COBOL技術者の母数自体が縮小している以上、外部調達で穴埋めする前提も年々成立しにくくなっています。

2. 運用コストの上昇

ハードウェア・ソフトウェアの保守費に加え、影響範囲が読めないことによるテスト工数が積み上がります。「1行直すために3か月テストする」状態は、金額以上に意思決定の速度を奪います。

3. 保守性の低下

長年の改修で分岐が増え続けたプログラムは、実質的にブラックボックス化します。改修そのものより、改修してよいかどうかの調査に時間がかかるようになります。

4. プラットフォーム・ミドルウェアのサポート終了

メインフレームやミドルウェアのライフサイクルは、企業側の都合とは無関係に進みます。たとえば富士通は自社メインフレームについて2030年度の販売終了、2035年度の保守終了を公表しており、業界では「2035年の崖」として議論されています（日経クロステック）。期限が明示された以上、検討開始を先送りするほど選択肢は狭まります。

5. セキュリティと監査対応

サポートが終了した基盤では、脆弱性対応や暗号化方式の更新が難しくなります。監査やセキュリティ要件の高度化に対して「構成上できない」と回答せざるを得ない領域が増えていきます。

6. 連携性（クラウド・API・データ・AI）

データが基幹システムの内側に閉じていると、BI・データ基盤・AI活用のいずれも中途半端になります。連携のたびに個別のバッチ連携を追加する運用は、それ自体が新たなレガシーを生みます。

7. プロダクト開発の速度

フロント側をどれだけ内製・アジャイル化しても、基幹側のリードタイムが変わらなければ全体の速度は上がりません。

8. 業務継続（BCP）

「動いているから安全」ではなく、「復旧できる人と手順があるか」が業務継続の実態です。属人化した基幹システムは、その意味で継続性リスクを抱えています。

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

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

大規模な基幹システムでは、どれか一つを全体に適用するより、領域ごとに3つを組み合わせるのが現実的です。バッチ中心の定型業務はリプラットフォームで基盤リスクを外し、改修頻度の高い受発注まわりはリファクタリングで保守性を確保し、外部連携が必要な一部機能だけをリイマジンする——このような判断ができるかどうかが、投資対効果を大きく左右します。

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

近年、モダナイゼーション領域でもAIの活用が急速に進んでいます。実際に有効性が確認されている用途は次のようなものです。

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

一方で、AIがプロジェクトを丸ごと自動で完了させられるという前提は、現時点では成立しません。理由は明確です。COBOL資産に埋め込まれているのはコードの意味だけでなく、業務上の例外処理と過去の経緯だからです。「この条件分岐は特定の取引先向けの運用ルール」「この丸め処理は会計方針に由来する」といった判断は、コードの静的解析だけでは復元できません。

そのため、BAPが前提とするのはAI-assisted / expert-led（人がループに入る）のモデルです。AIが解析・生成の速度を担い、レガシー領域の有識者、Java・クラウドのエンジニア、QA、そして業務部門が結果を検証する。特に業務部門の関与は、機能等価性を判断する最終的な拠り所になります。

AIは調査と生成の工数を圧縮する手段であり、業務判断の責任主体ではありません。この線引きを曖昧にしたプロジェクトは、テスト工程で必ず破綻します。

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

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

プログラム、ジョブ、シェルスクリプト、帳票、データベースの棚卸しを行い、呼び出し関係とデータの流れを可視化します。ここで「実際には使われていない資産」を切り分けられるかどうかが、後工程の規模を大きく左右します。同時に、業務部門へのヒアリングでドキュメント化されていないルールを引き出します。

フェーズ2：PoCと移行ウェーブの計画

いきなり全体着手はしません。代表的な難易度を持つ業務を1つ選び、変換方針・アーキテクチャ・テスト手法を実証します。PoCの目的は「できるかどうか」ではなく、本番規模に展開したときの工数・品質・リスクを見積もれる状態にすることです。その結果をもとに、業務単位・データ単位で移行ウェーブを分割し、各ウェーブの切替方式（並行稼働の要否を含む）を決めます。

フェーズ3：ソースコード・画面・データ・基盤の変換

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

フェーズ4：機能等価性テストと品質保証

モダナイゼーションの品質は、この工程で決まります。業務仕様を変えない移行であれば、旧系と新系が同じ入力に対して同じ結果を返すことを、証跡として示せなければなりません。実施する主なテストは次のとおりです。

• 単体テスト（ユニットテスト）
• コンポーネントテスト
• バッチ結果の突合比較（旧系・新系の出力比較）
• 結合テスト
• データ整合性検証（データレコンサイル）
• システムテスト
• 性能テスト（特にバッチのウィンドウ内完了）
• セキュリティ検証
• リグレッションテスト
• ユーザー受入テスト（UAT）

フェーズ5：カットオーバー、安定稼働、継続的改善

切替は手順書と切戻し（ロールバック）条件をセットで準備します。切替直後は監視と一次対応の体制を厚くし、安定稼働を確認したうえで通常保守へ移行します。そして、モダナイゼーションはカットオーバーで終わりません。保守しやすい構造を手に入れた後に、API化やクラウドサービスの活用を段階的に進めていく——ここまでを含めて初めて投資が回収されます。

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

• 運用リスクの低減：サポート終了基盤からの脱却と、障害時の対応可能人員の拡大。
• 要員依存の緩和：JavaなどCOBOLより採用母集団の大きい技術へ移すことで、体制の再構築余地が広がる。
• 保守性の向上：構造とドキュメントが整備され、改修時の調査工数が下がる。
• リリースサイクルの短縮：影響範囲が読めることで、テスト範囲を合理的に絞り込める。
• 連携性の獲得：API、クラウド、データ基盤、AI活用への接続点が生まれる。
• 業務ロジックの保全：長年かけて検証されてきた業務ルールを、説明可能な形で次の基盤へ引き継げる。
• ユーザー体験の改善：オンライン画面のWeb化により、端末・ブラウザ制約や操作性の課題を解消できる。
• 長期的なDXの土台：以降の施策が「まず基幹を調べるところから」始まらなくなる。

なお、削減率や投資回収期間は、対象資産の規模・構造・業務要件によって大きく変動します。数値目標は現行資産の調査結果に基づいて設定すべきであり、一般論として提示できる性質のものではありません。

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

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

対象規模は概ね次のとおりです。

• ユーザー画面：約90本
• アプリケーションプログラム：約300本
• バッチ処理・運用向けシェルスクリプト：約85本
• データベーステーブル：約65本

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

BAPの支援領域

BAPは約500名規模の技術者を擁し、ベトナム（ハノイ・ダナン・ホーチミン・フエ）、日本、韓国、オーストラリア、米国に拠点を持つ開発会社です。日本市場向けにはブリッジSEを介した体制を標準としており、要件確認から受入テストまで日本語で完結できる進め方を採用しています。

よくあるご質問

Q1. COBOLをJavaに変換すれば、それでモダナイゼーションは完了しますか？

言語を置き換えただけでは、保守性の課題は残ります。COBOLの制御構造をそのままJavaに写した状態は「Javaで書かれたCOBOL」であり、改修時の調査工数はほとんど変わりません。変換と併せて、パッケージ構成・データアクセス・例外処理の方針を再定義することが前提になります。

Q2. 設計書がまったく残っていませんが、移行できますか？

可能です。実際、ドキュメントが不完全な状態から始まる案件は珍しくありません。ソースコードとジョブ定義、実データの挙動を突き合わせて仕様を再構成し、業務部門へのヒアリングで意図を確認していきます。AIによる解析・ドキュメント生成はこの工程で特に効果を発揮します。

Q3. 一括移行と段階的移行では、どちらを選ぶべきですか？

業務停止の許容度と資産規模によります。一括切替は並行稼働の負担が小さい一方、切戻しの難易度が上がります。段階的移行は各回のリスクを抑えられますが、移行期間中の新旧データ連携という追加の設計課題が生じます。この判断はPoCの結果を踏まえて行うのが安全です。

Q4. 移行後に業務が変わってしまうことはありませんか？

「業務プロセスを変えない」ことを要件とする場合、それは機能等価性テストで担保します。旧系と新系の出力を突合し、差異が出た場合は必ず原因を特定して、仕様なのか不具合なのかを業務部門と確認する——この積み重ねが唯一の方法です。

Q5. メインフレームの保守終了まで時間がありますが、今から検討すべきですか？

資産の調査と方針決定だけでも相応の期間を要し、そこから移行・テスト・安定化が続きます。期限直前に着手すると、選択肢がリプラットフォームに限定されやすくなります。まず現状把握を先行させ、判断材料を揃えておくことをおすすめします。

Q6. まず何から始めればよいですか？

資産の棚卸しと依存関係の可視化です。規模と構造が見えて初めて、リプラットフォーム・リファクタリング・リイマジンの配分を議論できます。この段階では大きな投資判断は不要です。

COBOLモダナイゼーションのご相談

BAPでは、COBOL資産を抱える企業向けに以下のご支援を行っています。

• COBOLモダナイゼーション・アセスメント：現行資産の棚卸しと依存関係の可視化
• 現状課題のディスカッション：要員体制、保守負荷、基盤サポート期限を踏まえた論点整理
• モダナイゼーション・ロードマップの策定：業務領域ごとのアプローチ配分と移行ウェーブ設計
• PoCの実施：大規模投資の前に、方式と見積り精度を検証

「まだ社内で方針が固まっていない」という段階でも問題ありません。現行システムの状況をお聞かせいただければ、検討に必要な論点と進め方をご提案します。まずはお気軽にご相談ください。