COBOL移行の進め方｜失敗を防ぐ3つのアプローチと成功事例  

【１分でわかるこの記事の要約】

• 迫る「2025年の崖」： COBOL技術者の大量引退と保守コスト増大により、現状維持は年間数千万円の損失とDX停滞を招く経営リスクである。

• ３つの移行戦略： 低コスト・短納期の「リホスト」、言語を刷新する「リライト」、全面再設計の「リビルド」から、自社の資産規模とROIに応じた選択が不可欠。

• 成功の鍵は「可視化」： 失敗の主要因はブラックボックス化にあり、AI解析等を活用した徹底的な現状分析（As-Is）がプロジェクト完遂の絶対条件である。

「マイグレーションの70%以上が未完了」——この数字は、COBOL移行がいかに困難なプロジェクトであるかを端的に示している。

COBOL移行の成否は、移行手法の選定と既存資産の徹底的な解析で決まる。リホスト・リライト・リビルドの3アプローチにはそれぞれ適した場面があり、自社のCOBOL資産の規模・複雑さ・ビジネス要件に応じた選択が不可欠だ。

この記事では、COBOL移行の3つのアプローチを比較し、COBOL特有の技術的課題、費用・期間の目安、実際の失敗パターンと成功事例、そして移行を成功に導くための第一歩を解説する。

COBOL移行が「今」求められる3つの理由

COBOLは1959年の誕生から60年以上、金融・公共・製造業の基幹システムを支え続けてきた。しかし、この「実績」が今、移行の障壁にもなっている。

COBOL技術者の急速な減少

COBOLを熟知した技術者は、そのほとんどが50代後半〜60代だ。2025年を境にベテラン世代の大量定年退職が始まり、COBOL人材の確保は年々困難になっている。

月額単価50〜60万円が相場のCOBOL案件でも、対応できるエンジニアの絶対数が減少しているため、プロジェクトの立ち上げ自体が難しいケースが増えた。新卒がCOBOLを学ぶ機会はほぼゼロであり、IPAも2019年に基本情報技術者試験からCOBOLを廃止した。人材供給のパイプラインは事実上、閉じている。

メインフレーム維持コストの膨張

COBOLシステムの多くはメインフレーム上で稼働している。ある中堅製造業のケースでは、HWリース・SWライセンス・保守委託費を合わせた年間運用コストが8,000万円に達していた。

この金額はメインフレームの維持だけに消えるコストであり、業務改善や新機能の追加には一切使われない。移行プロジェクト（中規模・1.5億円想定）のROIを試算すると、移行後5年間で約67%——約3年で投資を回収できる計算になる。

ビジネス環境への対応限界

COBOLシステムはバッチ処理に最適化された設計であり、リアルタイムのAPI連携やクラウドネイティブなアーキテクチャへの対応は困難だ。マイクロサービス化やモバイル連携といった現代のビジネス要件に応えられず、DX推進の足かせになっている。

経済産業省のDXレポートでも、約7割の企業がレガシーシステムをDX推進の障壁として認識していると指摘されている。

COBOL移行の3つのアプローチ比較

COBOL移行には大きく3つのアプローチがある。どれが最適かは「何を優先するか」で変わる。

リホスト——最速・低リスクだが根本解決にならない

リホストは、COBOLプログラムをメインフレームからLinuxやクラウド環境へそのまま移す手法だ。コードの書き換えが不要なため、最もリスクが低く、期間も短い。

ただし、COBOLのまま残るため技術者不足の問題は解決しない。「時間を稼ぐ」手段としては有効だが、長期的にはリライトやリビルドといった本格的な刷新が必要になる。

リライト——自動変換ツールが鍵

リライトは、COBOLコードをJavaやC#などの現代言語に書き直す手法だ。自動変換ツール（JANUS Studio、Xenlon等）を活用すれば、変換率を高めてヒューマンエラーを抑えられる。

ただし注意点がある。自動変換で生成されるコードは「COBOLライクなJava」になりやすい。TISの報告によれば、COBOLのファイル入出力仕様に合わせたスペース埋め処理や、固定バイト長で項目を区切るメモリ操作が残り、業務仕様とは無関係な冗長ロジックがJavaコードに混在する。結果、COBOLとJavaの両方の知識が必要なコードが生まれるリスクがある。

リビルド——理想的だが覚悟が必要

リビルドは、既存システムの機能を再設計し、最新のアーキテクチャでゼロから構築する手法だ。クラウドネイティブ化やマイクロサービス化を実現でき、将来の拡張性は最も高い。

一方で、コストと期間は桁違いに大きい。ある企業が500万ステップ相当のリビルドをSIerに見積もり依頼したところ、回答は「5年間、1万人月」だった。業務仕様の再定義から必要になるため、IT部門だけでなく業務部門の深い関与も求められる。

COBOL→Java移行で直面する5つの技術的課題

COBOL移行先として最も選ばれるのはJavaだ。金融・公共分野での実績が豊富で、エンジニア人材が潤沢なことが主な理由である。しかし、COBOLとJavaの言語特性の違いは大きく、移行時には固有の技術的課題が発生する。

1. パック10進数（COMP-3）の精度問題

COBOLは固定小数点演算が標準で、金融計算に求められる桁・端数の厳密な制御に優れている。一方、Javaの浮動小数点型（float/double）では丸め誤差が生じる。BigDecimalを使えば対処可能だが、パフォーマンスとのトレードオフがあり、変換時にすべてのデータ項目を精査する必要がある。

2. REDEFINES句の変換困難

COBOLのREDEFINES句は、同一メモリ領域を異なるデータ定義で参照する機能だ。Javaにはこの概念に直接対応する仕組みがなく、変換時に業務ロジックの意図を正確に理解した上での再設計が求められる。

3. ファイル入出力の差異

COBOLの順次ファイルや索引ファイルの入出力処理には、スペース埋め・ゼロ埋めなど固定長レコード特有のロジックが組み込まれている。自動変換ではこれらのロジックがそのままJavaコードに残り、可読性が著しく低下する。

4. バッチ処理の性能劣化

COBOLからJavaに移行すると、バッチ処理の実行時間が2〜3倍になるケースは珍しくない。夜間バッチのように処理時間に厳しい制約があるジョブでは、移行後にパフォーマンスチューニングの追加コストが発生する。

5. 「COBOLライクなJava」の保守性問題

自動変換ツールで変換されたJavaコードは、COBOL的な制御構造や命名規則が残る。三菱重工のプロジェクトでもこの現象が発生したが、「Javaエンジニアが扱えるようになるだけで、組織運営上は極めて健全な環境が実現できる」との判断で、段階的なリファクタリングで対応した。

これら5つの課題に共通するのは、移行前の段階で既存コードの仕様を正確に把握できていれば、大半は事前に対策を打てるという点だ。

COBOL移行の費用・期間の目安

COBOL移行の予算確保・稟議のために、費用感を把握しておく必要がある。規模と手法別の目安を以下に示す。

※上記は開発費の目安。以下の「隠れコスト」が別途発生する。

見落としがちな4つの隠れコスト

1. インフラ刷新コスト: クラウド（AWS・Azure・GCP）のサーバー費用、ネットワーク費用、DBライセンス費用

2. 教育・トレーニングコスト: COBOLしか経験のない担当者への新言語・新環境の研修費

3. 並行稼働コスト: 移行期間中、新旧システムを同時に動かすインフラと人件費の二重負担

4. パフォーマンスチューニングコスト: 変換後コードのボトルネック特定・最適化の専門家費用

ROI試算の考え方

中規模システム（メインフレーム年間運用コスト8,000万円）を1.5億円でリライト移行した場合を試算する。

• 移行後のクラウド運用コスト: 年間3,000万円（メインフレーム比で62%削減）

• 年間削減額: 5,000万円

• 5年間の削減総額: 2.5億円

• ROI: （2.5億円 − 1.5億円）÷ 1.5億円 = 約67%

• 投資回収期間: 約3年

COBOL移行の失敗パターン4選と教訓

この20年で移行しやすいCOBOL資産は既に移行を済ませている。残っているのは「ラスボス」級——巨大で複雑、仕様が不透明な資産ばかりだ。失敗パターンを知り、同じ轍を踏まないことが重要になる。

パターン1: ブラックボックスのまま着手

仕様書がない、担当者もいない。そんな状態で移行プロジェクトを開始し、想定外のプログラムが次々と発覚して頓挫するケース。委託先のSIerもお手上げとなり、投じた費用だけが残る。

教訓: 移行前のASIS解析で「何がどう動いているか」を全て可視化してから着手する。

パターン2: プロジェクトの丸投げ

発注者側がCOBOLシステムの業務知識を持たず、「全部やってくれ」とSIerに委託する。受託者はCOBOLの業務仕様を理解できず、テストデータの作成すらできない。セキュリティ要件も見落とされる。

教訓: 発注者は業務知識を必ず関与させる。少なくとも「何を実現しているシステムか」を言語化できる体制が必要。

パターン3: 一括移行（ビッグバン方式）への固執

段階的な移行ではなく、全システムを一度に切り替えようとして失敗する。切り戻しも不可能な状態に追い込まれ、障害が連鎖する。

教訓: 業務影響度の低いサブシステムから着手し、成功体験を積みながら基幹部分へ拡大する。

パターン4: 自動変換率の過信

変換ツールの出力を十分に検証せず、本番環境にリリースして障害が多発するケース。特に、COBOL特有のデータ型変換や端数処理の差異が金額計算のバグとして顕在化しやすい。

教訓: 自動変換率100%が理想だが、変換後のコードレビューとテストは必須。特に金融系の計算処理は重点検証対象とする。

4つの失敗パターンに共通する根本原因は、移行前の現状把握（ASIS解析）が不十分であることだ。

COBOL移行の成功事例3選

失敗の多いCOBOL移行だが、大規模プロジェクトの成功事例も着実に増えている。

三菱重工——1,500万ステップ・4.5万本のJava変換

三菱重工は、アクセンチュアの支援のもと、1,500万ステップ・4.5万本のCOBOL資産をJavaに変換して脱ホストを実現した。Java変換としては記録的な大規模プロジェクトだ。

成功の要因は、経営層・現場・IT部門を結びつけた有機的なプロジェクト運営にある。自動変換ツールで生成された「COBOLライクなJava」は、段階的なリファクタリングで対応する方針を取り、まず「脱メインフレーム」を最優先目標に設定した。

JAL——マイレージ関連システムのAWS移行

JALは2025年、メインフレーム上のマイレージ関連システムをAWSに移行し、COBOLからJavaへのリライトを完遂した。クラウドネイティブ環境への移行により、スケーラビリティとコスト効率の両立を実現している。

JFEスチール——5,000万ステップの脱メインフレーム

JFEスチールは2025年、5,000万ステップという大規模なCOBOL資産をリライト手法で脱メインフレームに成功した。製造業の基幹システムという高い信頼性要件のもとでの移行であり、入念な移行リハーサルと段階的な切替が成功を支えた。

3つの事例に共通する成功要因は、徹底した事前の資産解析と段階的な移行アプローチだ。いずれのプロジェクトも、移行対象の全貌を正確に把握した上で計画を策定している。

移行成功の鍵は「既存資産の可視化」から

COBOL移行で最も重要なのは、移行の第一歩であるASIS解析（As-Is分析）だ。

仕様書がない、設計書が古い、担当者が退職した——COBOLシステムが抱えるこれらの問題は、すべて「既存資産が見えていない」ことに起因する。見えないまま移行プロジェクトを進めれば、前述の失敗パターンに陥る確率は極めて高い。

ASIS解析で明らかにすべき情報は以下の通りだ。

• ソースコードの規模（ステップ数・本数）と依存関係

• 業務ロジックの処理内容と分岐条件

• バッチ処理のジョブ構成と実行順序

• 外部システムとの連携インターフェース

• データ定義（COPY句・REDEFINES・COMP-3等の特殊仕様）

これらを人手だけで解析するには、COBOLを読めるベテランエンジニアの確保と膨大な工数が必要になる。AIによるコード解析を活用すれば、従来の1/10のコスト・1/10の期間での解析が可能になっている。

COBOLシステムの「見えない仕様」を可視化しませんか？

エイジレスでは、独自AI「ARIADNE」と精鋭部隊「TITANS」（平均年齢57歳・300名）が、

数万本規模のCOBOL資産でも約1ヶ月で可視化します。従来の1/10のコストで、

要件定義書・詳細設計書・テスト仕様書を自動生成。

無料相談はこちら →

まずは情報収集から始めたい方へ

ASIS解析の進め方がわかる資料を無料でお届けします。

資料をダウンロード →

よくある質問

COBOL移行にかかる期間はどのくらいですか？

規模と手法によって大きく異なる。小規模（50万行以下）のリホストなら6ヶ月〜1年、中規模のリライトで1〜3年、大規模（500万行超）のリビルドでは3〜5年が目安だ。三菱重工のプロジェクト（1,500万ステップ）は複数年にわたる大型プロジェクトとなった。

COBOL移行で最も多い移行先言語は何ですか？

Javaが最も主流だ。金融・公共分野での実績が豊富で、エンジニア人材が潤沢なことが選ばれる理由だ。全国銀行データ通信システム（全銀システム）もCOBOLからJavaへの移行を発表している。C#はMicrosoft環境との親和性を重視する場合に選択され、Pythonは業務ロジックの移行先というよりAI活用やデータ分析領域での補完的な役割が多い。

COBOL移行でAIは活用できますか？

活用できる。Amazon Qを使ったCOBOL→Java移行支援、明治安田生命では生成AIでCOBOLシステム改修工数を25%削減した実績がある。エイジレスの独自AI「ARIADNE」はASIS解析に特化し、COBOLコードの仕様書・設計書を自動生成する。AIの活用により、従来の手作業に比べて大幅な効率化が実現している。

COBOL移行を段階的に進めるにはどうすればよいですか？

まず業務影響度の低いサブシステムから着手し、移行のノウハウと成功体験を蓄積する。次に、蓄積した知見を活かして中核のバッチ処理やオンライン処理へ展開する。一括移行（ビッグバン方式）は避け、各フェーズで移行リハーサルを実施してリスクを検証するのが定石だ。