「30 年動き続けてきた COBOL のシステムが、最近やたらと『止まる』『遅い』『改修が高い』」「COBOL を読める社員は今や 1～2 名、皆 60 代」——中堅企業の製造・卸売・金融業の経営者から、最近最も多く寄せられる相談です。COBOL マイグレーションは『いつかやればいい』テーマから、『3～5 年以内に決め切らないと業務が止まる』 経営課題に変わりました。本記事では、COBOL 資産の現状認識、移行を急ぐべき 4 つの圧力、3 つの進め方、費用・期間、業界別事例、失敗パターン、経営者の判断チェックリストまで、汎用機・メインフレームからオープン系・クラウドへの移行に 25 年携わった経験で整理します。
『COBOL を読める社員が、もういない』とお感じですか？ 25 年の経験で現実的な移行ロードマップを一緒に整理します。 無料相談 ＞COBOL マイグレーションの現状認識｜『動いているのに、止まりかけている』
COBOL は、1960 年代に登場した業務処理向けプログラミング言語です。日本の中堅・大企業では、汎用機（メインフレーム）や IBM i・富士通 ASP・NEC ACOS といった基幹基盤上で、販売・在庫・生産・会計・与信・保険計算などの 業務の中核ロジック を 30～40 年支えてきました。安定して動き続けてきた一方で、いま静かに『限界』が広がっています。
日本企業に残る COBOL 資産の典型像
| パターン | 稼働環境 | 典型的な状態 |
|---|---|---|
| ① 汎用機（メインフレーム）＋ COBOL | 富士通・日立・NEC・IBM zSeries 等 | 1980～90 年代導入。保守費が年 5,000 万～2 億円規模、リース・電力費も重い |
| ② オフコン（IBM i／富士通 ASP／NEC EXPRESS5800 等）＋ COBOL／RPG | IBM i・ACOS・ASP-X | 1990～2000 年代導入。中堅企業に多い。サポート切れ・部品調達難が進行 |
| ③ Windows／UNIX サーバ移植版 COBOL | Micro Focus・OpenCOBOL 等 | 2000 年代に汎用機からダウンサイジングしたが、ソースは当時のまま |
パターン①～③ のいずれであっても、共通の課題があります。『動いてはいる。しかし、変えられない・読めない・繋げない』。経営層の意思決定スピードに、システム側が追いつかなくなっています。
COBOL 資産の『限界』が現れる 5 つのサイン
- サイン 1：読める技術者の高齢化——COBOL を読み書きできる社員・パートナーが 1～2 名、いずれも 55 歳以上
- サイン 2：改修費の高騰——小さな業務変更でも見積もりが数百万円、納期は数ヶ月
- サイン 3：ハード・OS のサポート切れ——汎用機・オフコンのサポート終了通告、リース更新時期の到来
- サイン 4：法制度・取引先対応の困難——電子帳簿保存法・インボイス・EDI 強化・API 連携の要求に対応不能
- サイン 5：ブラックボックス化——設計書・ドキュメントが現存せず、ソースしか手掛かりがない／改修するとどこに影響するか誰も分からない
3 つ以上当てはまれば、COBOL マイグレーションの本格検討に入る時期です。
なぜ今、COBOL マイグレーションをやるべきか｜4 つの圧力
COBOL マイグレーションは『先送りすれば先送りするほど、選択肢が狭くなる』テーマです。次の 4 つの圧力が、同時に押し寄せています。
圧力 1：COBOL 技術者の引退ラッシュ
日本の COBOL 技術者の中心世代は 1960～1970 年代生まれ。すでに 定年・引退の波 に入っており、2025～2030 年でその大半が現役から退きます。情報処理推進機構（IPA）・経済産業省の各種レポートでも、COBOL を含むレガシー基盤を担う技術者の急速な減少が指摘されています。『今後 5 年以内に、社内で COBOL を読める人がゼロになる』 ——これは、中堅企業の半数以上が直面する現実です。
圧力 2：ハード・OS のサポート切れ
汎用機・オフコンのベンダー保守は、機種ごとにサポート終了が予告されています。サポート切れ後も延長保守（プレミアム保守）で延命する選択肢はありますが、年間保守費が 1.5～3 倍に跳ね上がる ことが多く、経済合理性が崩れます。さらに、部品交換・OS パッチ提供が止まると、障害発生時の業務停止リスクが急上昇します。
圧力 3：法制度・取引先のデジタル化要求
電子帳簿保存法、改正電子取引保存法、インボイス制度、改正消費税法、EDI 強化、API 連携、トレーサビリティ要求——古い COBOL システムでは、これらに対応するための改修費が 都度数百万～数千万円 発生します。改修を重ねるたびに『つぎはぎ』が増え、保守性がさらに低下する悪循環に陥ります。
圧力 4：データ活用・経営判断スピードの要求
経営層から「販売データを分析したい」「在庫の最適化を進めたい」「拠点別の損益をリアルタイムで見たい」といった要求が増加。COBOL システムは、データ取り出し・BI ツール連携・API 公開が技術的に困難なため、データ活用の最大のボトルネック になっています。経営判断のスピードを、システムが律速している状態。
COBOL マイグレーションの進め方｜3 つのアプローチ
COBOL マイグレーションには、主に 3 つのアプローチがあります。業務独自性・予算・移行の緊急度・既存資産の活用度合いで選びます。
アプローチ 1：リホスト（環境だけ載せ替え／ソースは概ね維持）
COBOL ソースをほぼそのまま残し、稼働環境だけを Windows・Linux・クラウド 上の COBOL 実行環境（Micro Focus Visual COBOL・OpenCOBOL／GnuCOBOL 等）へ移行する方式。業務ロジックは変えずに、ハード・OS だけを切り替えます。
| メリット | 業務影響が最小／期間が短い／投資額が比較的小／既存業務知識を最大活用 |
|---|---|
| デメリット | COBOL 資産はそのまま残るため、技術者問題は将来的に再発／業務改革効果は限定的 |
| 適合ケース | サポート切れが目前／業務改革は後回しで延命したい／業務独自性が極めて高い |
| 費用／期間 | 2,000 万～5,000 万円／8～12 ヶ月 |
アプローチ 2：リライト（Java・C# 等へ書き換え）
COBOL ソースを Java・C#・Python・COBOL 以外の言語 へ書き換える方式。業務ロジックは原則維持しつつ、技術基盤を現代化します。自動変換ツール（ロジック変換エンジン）を使う場合と、人手で書き直す場合の組み合わせが一般的。
| メリット | 技術者問題が解消／オープン技術スタックで運用人材確保が容易／API 連携・データ活用が容易 |
|---|---|
| デメリット | 投資額が大／期間が長い／変換後の保守性は『元 COBOL ぽさ』が残る場合あり／自動変換に過信は禁物 |
| 適合ケース | 業務ロジックは資産として残したい／パッケージでは吸収できない業務独自性がある |
| 費用／期間 | 8,000 万～2 億円／18～24 ヶ月 |
アプローチ 3：ERP・業務パッケージへの移行（業務を捨てる判断）
COBOL で組まれた業務独自仕様を 業界特化型 ERP・業務パッケージの標準機能に寄せる 方式。Fit to Standard を経営判断で明示し、独自仕様は『資産か負債か』の視点で取捨選択します。
| メリット | 業界ベストプラクティスを取り込める／長期的な運用コストが下がる／業務改革効果が大きい |
|---|---|
| デメリット | 業務をパッケージに合わせる経営判断が必要／一部の独自仕様は捨てる必要あり |
| 適合ケース | 業務独自性が業界平均的／業務改革を伴う刷新を進めたい／中堅企業の第一選択肢 |
| 費用／期間 | 3,000 万～8,000 万円／10～14 ヶ月 |
3 つのアプローチは『どれが正解』ではなく、『自社の COBOL 資産が、業界差別化に寄与しているか／単に過去の事情で複雑化しているだけか』 という経営判断で選びます。中堅企業の最頻パターンは、『2～3 年でリホスト先行 → 5 年以内に ERP・パッケージで再刷新』 の段階戦略です。
COBOL マイグレーションの費用・期間
規模別・方式別の費用目安
| 従業員規模 | リホスト | リライト | ERP・パッケージ移行 |
|---|---|---|---|
| 50～150 名 | 2,000～4,000 万円 | 6,000 万～1.2 億円 | 2,500～5,000 万円 |
| 150～300 名 | 3,000～6,000 万円 | 8,000 万～1.8 億円 | 5,000 万～1 億円 |
| 300～500 名 | 4,000 万～8,000 万円 | 1.2～2.5 億円 | 8,000 万～1.5 億円 |
これはベンダー支払額のみ。隠れコスト（業務部門工数・並行運用・データ移行・教育・パートナー調整）として 1.4～1.7 倍 を見込んでください。COBOL 特化のリライト案件では、ドキュメント不在・属人化解消の工数が追加で発生するため、隠れコストの倍率が他のレガシー移行より高めに出ます。
期間
検討フェーズ（経営判断・現行解析・RFP・ベンダー選定）3～6 ヶ月＋移行設計・実装・移行・テスト 10～18 ヶ月＋稼働後 90 日定着化を含めると、経営判断から成果獲得まで 15～27 ヶ月 が現実的なスケジュール。リホストは 12 ヶ月前後、リライトは 24 ヶ月超、ERP 移行は 14 ヶ月前後が中心値です。
『隠れコスト』の主な内訳
- 現行解析：ソースコード解析・業務ロジック棚卸し（300～1,000 万円）
- データ移行・クレンジング：過去 10～30 年分の取引データ・マスタの整理（500～2,000 万円）
- 並行運用：新旧システム同時稼働期間のオペレーションコスト
- 業務部門工数：要件確認・テスト・受入の社内工数（外部換算で 1,500～4,000 万円相当）
- 教育・マニュアル整備：現場ユーザー教育・マニュアル作成（300～800 万円）
COBOL マイグレーションの事例（中堅企業モデル）
業種別の典型ケースを示します（業界一般のモデルケース）。
ケース 1：金融業 A 社（与信・債権管理システムをリホスト）
| 規模 | 従業員 250 名（地域金融・債権サービス） |
|---|---|
| 刷新前 | 富士通 GS21 上の COBOL 与信・債権管理（25 年稼働）／保守費 年 1.2 億円／COBOL 技術者 2 名（55 歳・62 歳） |
| 方式 | リホスト（クラウド上の Micro Focus Visual COBOL 環境へ移行） |
| 期間／投資額 | 11 ヶ月／5,500 万円 |
| 主な成果 | 保守費 年 1.2 億円 → 3,500 万円（70% 削減）／法制度対応の改修期間が 1/3 に短縮／業務影響なく稼働切替 |
ケース 2：製造業 B 社（生産管理 COBOL を Java へリライト）
| 規模 | 年商 80 億円／従業員 200 名（部品製造） |
|---|---|
| 刷新前 | NEC ACOS 上の COBOL 生産管理（28 年稼働）／業務独自性が業界差別化に直結／設計書ほぼ現存せず |
| 方式 | リライト（自動変換ツール＋人手で Java へ）／業務ロジックは原則維持 |
| 期間／投資額 | 22 ヶ月／1.4 億円 |
| 主な成果 | COBOL 技術者問題が解消／API 連携で生産データを BI 活用／原価リアルタイム把握／追加改修費が 1/4 に |
ケース 3：卸売業 C 社（販売管理 COBOL を業界特化 ERP へ移行）
| 規模 | 年商 120 億円／従業員 220 名（食品卸） |
|---|---|
| 刷新前 | IBM i 上の COBOL／RPG 販売管理（30 年稼働）／取引先 EDI 強化要求に対応困難／Excel 補完業務が肥大化 |
| 方式 | 食品卸売業界特化 ERP（Fit to Standard 7 割）／業務独自仕様は経営判断で 7 割を捨てる |
| 期間／投資額 | 14 ヶ月／7,800 万円 |
| 主な成果 | 受注処理工数 40% 削減／在庫精度 92% → 99.5%／大手取引先 EDI 対応で新規取引機会獲得／COBOL 資産から完全脱却 |
COBOL マイグレーションの『失敗パターン』
失敗 1：『現行を 100% 再現』を要件にする
20～30 年の改修で積み重なった独自仕様を、新システムでそのまま再現しようとすると、開発費は 1.5～2 倍、期間は 1.3～1.6 倍 に膨らみます。リライト・ERP 移行では特に致命的。『資産か負債か』を経営判断で切り分ける プロセスを、要件定義の最初に置いてください。
失敗 2：自動変換ツールに過信する
COBOL → Java の自動変換ツールは進化していますが、変換後のコードは『動くが、人間が読みやすいとは限らない』 状態になりがち。COBOL の WORKING-STORAGE や PERFORM 構造がそのまま残り、保守性が期待ほど上がらないケースがあります。自動変換 70%＋人手リファクタ 30% のハイブリッドが現実的で、『100% 自動変換で完了』を期待した提案には注意。
失敗 3：現行解析に予算を割かない
COBOL 資産は 設計書・ドキュメントが現存しない ことが多く、ソースコードだけが頼り。要件定義の前に 『現行解析フェーズ』 を独立して設け、業務ロジックの棚卸し・データフローの可視化・廃止候補の特定を行わないと、後工程で必ず炎上します。現行解析に 300～1,000 万円・2～4 ヶ月を予算化することが、結果的に総額を抑えます。
失敗 4：COBOL 技術者の退職タイミングを軽視
プロジェクト開始時には 2 名いた COBOL 技術者が、移行の途中で 1 名退職・もう 1 名が体調不良で離脱、というケースが珍しくありません。キーマンの確保・引継ぎ期間を予算とスケジュールに織り込む。可能であれば、現役を退いた OB を業務委託で再雇用する選択肢も検討。
失敗 5：稼働後の定着支援を予算化しない
本番稼働日を『ゴール』と考えてしまい、稼働後 90 日の定着化フェーズに予算・人員を配分しない失敗。新システムは稼働直後の 90 日が定着化の勝負所。COBOL からの移行では、ユーザーインターフェイスが大きく変わるケースが多く、現場サポート・追加教育・チューニングを集中投入することで、業務改革効果が定着します。
COBOL マイグレーションの『判断チェックリスト』
経営者が現場で確認すべき 10 項目を整理します。3 つ以上当てはまったら、本格的な COBOL マイグレーション検討の時期です。
- ☐ 自社で COBOL を読み書きできる技術者が 1～2 名、いずれも 55 歳以上である
- ☐ 汎用機・オフコンのサポート終了通告またはリース更新時期が 2～3 年以内にある
- ☐ 年間保守費が 3,000 万円超、もしくは初期構築費の 15% を超えている
- ☐ 設計書・業務ドキュメントが現存せず、ソースコードだけが手掛かりになっている
- ☐ 法制度対応（電子帳簿保存法・インボイス等）の改修費が都度数百万～数千万円かかっている
- ☐ 大手取引先から EDI・API 連携・トレーサビリティの要求が来ている
- ☐ 経営層が分析したいデータを、COBOL システムから取り出せていない
- ☐ COBOL の改修依頼を出してから、納品まで 3 ヶ月以上かかる
- ☐ 中期経営計画で『業務効率化』『データ活用』『新規事業』を掲げているが、システム制約で進まない
- ☐ 経営者・後継者から『いつまで COBOL を使い続けるのか』の問題提起が出ている
まとめ｜COBOL マイグレーションは『業務を未来に引き継ぐ』選択
COBOL マイグレーションは、単なる『古い技術からの脱却』ではありません。『業務知識・業界差別化を、次の世代と次の技術基盤へ引き継ぐ』 経営判断です。30 年蓄積された COBOL 資産のうち、何を引き継ぎ・何を捨てるか——これを経営層が決め切れば、現場と技術パートナーが現実的なロードマップを組めます。
技術者引退ラッシュ、サポート切れ、法制度対応、データ活用要求——これら 4 つの圧力は『先送りすれば先送りするほど、選択肢が狭くなる』性質を持っています。リホストで延命できる時期、リライトで業務資産を残せる時期、ERP 移行で業務改革できる時期——これらは『COBOL を読める人がいる』『現行解析ができる』ことを前提に成り立ちます。前提が崩れる前に、3～6 ヶ月以内に方針決定を進める経営姿勢が、最終的な選択肢の幅を確保します。
株式会社クオンツでは、『COBOL 資産の現状診断』『3 方式（リホスト／リライト／ERP 移行）の経済合理性比較』『現実的な移行ロードマップ設計』 のご相談を、無料で受け付けています。汎用機・オフコンからオープン系・クラウド基盤への移行プロジェクトに 25 年携わってきた経験から、貴社の業種・資産規模・人材状況に合わせた現実解を一緒に整理します。机上のコンサルではなく、お客様の現場と並走するスタイルで、次の一歩の選択肢を整理します。
