COBOL基幹システムの移行ガイド【2026年版】｜2027年問題・移行先4選択肢・費用相場・進め方ロードマップ
「COBOLで動いている基幹システムをいつまで使い続けるべきか」「ベテランCOBOLエンジニアの定年退職が迫っており、保守できる人材がいなくなる」「経営層から『2027年問題』への対応を求められた」——金融・保険・公共・製造業の情シス担当者が共通して抱える深刻な悩みです。
経済産業省のDXレポートで指摘された 「2025年の崖」は2026年現在も解消されておらず、特に COBOL基幹システムを抱える企業 にとって、人材不足とコスト増加が深刻化しています。野村総合研究所の調査では、COBOLエンジニアの平均年齢は55歳超、2027年には供給が需要を大幅に下回ると予測されています。
本記事では、COBOL基幹システムを抱える企業の情シス・経営企画向けに、2027年問題の本質・移行先4選択肢の比較・費用相場・進め方ロードマップ・失敗しないための判断基準 を実務ベースで解説します。
この記事でわかること
- 2027年問題（COBOL人材不足）の現状と企業への影響
- COBOLを使い続けるリスクの定量評価
- 移行先4選択肢（リライト・リプレース・リホスト・リファクタリング）の比較
- 規模別の費用相場と期間目安
- 移行プロジェクトの進め方ロードマップ
- 失敗しないための5つの判断基準
目次
想定読者
本記事は、次のような方を想定しています。
- COBOL基幹システムを保有する金融・保険・公共・製造業の情シス担当者
- 経営層から2027年問題対応を求められている経営企画・事業責任者
- COBOL移行の見積もりを取ったが、判断軸が分からないDX推進担当者
- 既存COBOLシステムの保守ベンダーから値上げ要請を受けている企業
2027年問題（COBOL人材不足）の現状
COBOLエンジニアの構成比
| 年齢層 | COBOLエンジニア構成比 | 状況 |
|---|---|---|
| 60歳以上 | 約30% | 段階的に引退中 |
| 50〜59歳 | 約40% | 2027年までに大量定年 |
| 40〜49歳 | 約20% | 一部が退職・転職 |
| 39歳以下 | 約10% | 新規参入はほぼなし |
2027年時点での予測：
- COBOL保守可能人材は現在の半分以下に
- 保守単価は1.5〜2倍に上昇
- 障害発生時の復旧時間が2〜3倍に延長
COBOLを使い続ける3つのリスク
| リスク | 内容 | 経営インパクト |
|---|---|---|
| 保守人材の枯渇 | 退職後の引き継ぎ先がない | 障害時に対応不能で業務停止 |
| 保守コストの急騰 | 単価上昇＋希少性プレミアム | 年間保守費用が2倍以上に |
| 改修対応の遅延 | 改修可能なエンジニアがいない | 法改正・税制改正に追従できない |
「いつかやらなければ」ではなく、2027年が事実上の最終ライン と認識すべき段階です。
COBOL移行の4つの選択肢
COBOLからの移行アプローチは大きく4つに分類されます。それぞれメリット・デメリット・適用ケースが異なります。
| 選択肢 | 概要 | メリット | デメリット | 費用感 |
|---|---|---|---|---|
| リライト | COBOLをJava・C#等に書き換え | 機能維持・段階的に進められる | 工数大・テスト負荷高 | 中〜大 |
| リプレース（パッケージ） | ERPパッケージ等に置き換え | 最新業務プラクティス導入 | 業務フロー変更が必要・カスタマイズ範囲制約 | 中〜大 |
| リホスト（IaaS化） | COBOL環境をクラウドに移行 | 短期間・低コスト・既存資産活用 | 根本解決にならず人材問題は残る | 小〜中 |
| リファクタリング | COBOLのまま整理・モジュール化 | リスク最小・段階的移行への布石 | 人材問題は解決せず時間稼ぎ | 小 |
選択肢1：リライト（COBOL → Java/C#等）
概要： COBOLのソースコードを、Java・C#・Pythonなど現代的な言語に書き換える方式。業務ロジックは維持。
向いているケース：
- 業務プロセスを大きく変えたくない
- 自社開発した独自ロジックが多い
- 十分な期間（2〜5年）と予算（数千万〜数億円）が確保できる
注意点：
- AI翻訳ツール（GitHub Copilot for COBOL等）で工数削減できるが、業務理解とテストは依然必須
- 自動翻訳の品質は高くないため、人間によるレビューが不可欠
選択肢2：リプレース（パッケージ・SaaSへの置き換え）
概要： SAP・Oracle ERP・Microsoft Dynamics等の業務パッケージへの移行。
向いているケース：
- 業務プロセスの標準化を機に進めたい
- 自社の業務が業界標準で対応できる
- 内製コストよりパッケージライセンスを許容
注意点：
- カスタマイズ範囲・追加開発の費用試算が必須
- データ移行の難易度（マッピング作業）を侮らない
- 業務部門の合意形成と運用変革が成否を分ける
選択肢3：リホスト（メインフレーム→クラウド）
概要： メインフレーム上のCOBOLを、クラウド上のCOBOLランタイム（Micro Focus Enterprise Server等）に移行。
向いているケース：
- 緊急避難的に運用コスト削減が必要
- リライト・リプレース予算がすぐには確保できない
- メインフレームのハードウェア保守期限が迫っている
注意点：
- 根本的な人材問題は解決しない（COBOLは残る）
- 時間稼ぎ施策として位置づけ、並行してリライト計画を進める
選択肢4：リファクタリング（COBOLのまま改善）
概要： COBOLコードを整理・モジュール化し、保守性を改善する方式。
向いているケース：
- 短期的に大きな投資ができない
- まずはコードの「見える化」を進めたい
- 段階的にリライトに移行する前段階
注意点：
- 人材問題は解決しない（COBOLが残るため）
- 中長期的な移行計画の 第一段階 として位置づけるべき
規模別の費用相場と期間目安
| システム規模 | COBOL行数の目安 | リライト費用 | 期間目安 |
|---|---|---|---|
| 小規模 | 〜10万行 | 3,000万〜1億円 | 1〜2年 |
| 中規模 | 10万〜50万行 | 1〜5億円 | 2〜3年 |
| 大規模 | 50万〜100万行 | 5〜15億円 | 3〜5年 |
| 超大規模 | 100万行〜 | 15億円〜（個別見積） | 5年以上 |
費用に影響する3つの変数：
- 業務複雑度：金融商品計算など複雑なロジックは工数増
- ドキュメント整備度：仕様書がない場合、リバースエンジニアリングが必要
- テスト範囲：金融・公共系は徹底的なテストが必須
「自社のCOBOLシステムにどの選択肢が最適か、第三者の視点で評価したい」「移行費用の概算を知りたい」——そんな場合は、レガシー移行の実績豊富なパートナーに相談するのが近道です。
移行プロジェクトの進め方ロードマップ
COBOL移行は 2〜5年に及ぶ長期プロジェクト です。フェーズを切って段階的に進めます。
フェーズ1：現状分析（3〜6ヶ月）
- COBOLソース行数のカウント
- 機能・モジュール一覧の作成
- ベンダー・保守人材のリスク棚卸し
- 業務フローの再現性確認（ドキュメント整備度）
- 経営層への移行必要性の説明資料作成
フェーズ2：戦略策定（3ヶ月）
- 移行先選定（リライト/リプレース/リホスト/リファクタ）
- 概算費用・期間の試算
- 段階移行 vs 一括移行の判断
- ベンダー選定とRFP作成
フェーズ3：要件定義・設計（6〜12ヶ月）
- 既存仕様のリバースエンジニアリング
- 新システムの業務要件定義
- データ移行設計
- インターフェース設計（周辺システムとの連携）
フェーズ4：開発・テスト（12〜36ヶ月）
- 段階的な実装と単体テスト
- 結合テスト・総合テスト
- データ移行リハーサル
- 並行稼働テスト
フェーズ5：移行・定着（3〜6ヶ月）
- 段階移行の実施
- 業務部門のトレーニング
- 旧システム停止判断
- 運用安定化
失敗しないための5つの判断基準
基準1：移行する「目的」を明確にする
「COBOLが古いから」は理由になりません。何を解決したいか（コスト削減・人材確保・新機能追加・コンプライアンス対応）を明確にし、移行先選定の軸にします。
基準2：業務プロセスを変えるか・残すかを早期に決める
業務を残す → リライト or リホスト
業務を変える → リプレース（パッケージ）
この判断が遅れると、後工程の見積もり・スケジュールが大きくぶれます。
基準3：段階移行を前提に計画する
一括移行は 失敗リスクが最大化 します。基幹システムであっても、機能単位・部門単位で段階移行できないか必ず検討します。
基準4：ベンダー選定は3社以上の比較を必須に
COBOL移行は属人的なノウハウが大きいため、ベンダーごとの提案内容・費用差が大きくなります。3社以上から提案を受け、移行手法・体制・実績を比較しましょう。
基準5：「動くものを早く作る」より「確実に動くものを作る」
金融・公共系は データの正確性・処理結果の一致 が絶対条件です。スピード優先より、テスト工程を厚く取る計画を立てます。
よくある質問
Q. COBOLからJavaへの移行は、自動翻訳ツールで完結できますか？
A. 完結できません。AI・自動翻訳ツール（Micro Focus・GitHub Copilot等）はコード変換の一部を支援しますが、業務ロジックの理解・テスト・周辺システム連携の調整 は人間の作業が不可欠です。「自動化で工数50%削減」は現実的ですが、「自動化だけで完了」は現時点では不可能です。
Q. 移行を待つほど不利になるのは事実ですか？
A. 事実です。COBOL人材は減少の一途で、移行プロジェクト自体を担えるベンダーも縮小傾向です。2027〜2028年には「移行したくても、対応できるベンダーがいない」状態になる可能性があります。早期着手ほど、選択肢と価格交渉力が確保できます。
Q. うちは数十万行のCOBOLがあるので、5年以上かかると思います。今から始めて間に合いますか?
A. 段階移行が前提なら間に合います。一括移行は確かに5年以上かかりますが、機能ごと・部門ごとに切り出して段階的に移行すれば、2〜3年で重要機能の移行完了まで到達できます。「全部一度に」と考えると動けないので、まずは現状分析だけでも今月から始めましょう。
Q. 既存ベンダーに移行を依頼するのが安全ですか？
A. 必ずしもそうではありません。既存ベンダーは現行システムの理解度は高い一方、新技術への移行スキルが不足 していることがあります。「現行ベンダー＋移行専門ベンダー」の組み合わせで進めるのが安全です。RFPは複数社で実施することを強く推奨します。
Q. 経営層への説明で、何を伝えれば動いてもらえますか？
A. 「コスト・リスク・期限」の3点で訴求します。具体的には：
- 5年後の保守コスト試算（現在の1.5〜2倍）
- 障害発生時の業務停止リスク（人材不足で復旧時間が長期化）
- 2027年がベンダー対応の最終ライン
これに加えて、段階的に進めれば年間予算は分散できることを示すと、経営判断が下りやすくなります。
まとめ
本記事のポイントをまとめます。
- 2027年問題：COBOL人材は2027年までに半減・保守単価2倍・障害復旧時間3倍
- 使い続けるリスク：人材枯渇・コスト急騰・改修不能化
- 移行先4選択肢：リライト／リプレース／リホスト／リファクタリングを目的に応じて選定
- 規模別費用：小規模3,000万〜大規模15億円。期間1〜5年以上
- 5フェーズロードマップ：現状分析 → 戦略策定 → 要件定義 → 開発テスト → 移行定着
- 5つの判断基準：目的明確化・業務継承判断・段階移行・3社比較・確実性優先
COBOL移行は「いつかやる」テーマではなく、2027年までに着手できているかが企業継続の分岐点です。すべてを今すぐ実行する必要はありませんが、現状分析だけは今月から始める ことを強く推奨します。
c3index に相談する
シースリーインデックスは、COBOL基幹システムの移行支援・現状分析・ベンダー選定支援・移行プロジェクト伴走まで対応するシステム会社です。「自社のCOBOLシステムにどの選択肢が最適か」「移行費用の概算を知りたい」「経営層への説明資料を作りたい」——そうしたご相談にも対応しています。
金融・公共・製造業を中心としたレガシーシステム移行支援の実績をもとに、御社の業務・規模・予算に合わせた 2027年問題に間に合う現実的な移行計画をご提案いたします。まずはお気軽にお問い合わせください。
