COBOLのシステム開発の完全ガイド - ブログ

COBOLのシステムは、業務ルールと大量データを安定して処理する基幹システム全体であり、現行資産を棚卸しして業務単位で段階的に残す・移す判断をすることが最適解です。

「COBOLのシステムはまだ使い続けてよいのか」「Javaやクラウドへ移行すべきか」「費用や期間はどれくらいかかるのか」と悩む方に向けて、COBOLで作られた基幹システムの全体像、種類、刷新方式、進め方、費用相場、開発会社・ベンダーの選び方、セキュリティ、FAQまでを解説します。COBOLを古い言語という理由だけで一括置換するのではなく、業務継続性と将来の保守性を両立するための判断材料を整理します。

COBOLのシステムとは何ですか？

COBOLのシステムとは、COBOLで書かれたプログラムだけではなく、業務アプリケーション、データベース、ファイル、ジョブ制御、帳票、外部連携、運用監視までを組み合わせた業務処理基盤です。特にメインフレーム上では、COBOL、JCL、オンライン制御、データベース、ファイル管理が一体となって動作しているため、言語だけを見て刷新範囲を決めると重要な依存関係を見落とします。

どのような業務を支えていますか？

代表的な処理は、売上・請求・入出金、口座振替、保険契約、給与、在庫、受発注、生産実績、料金計算、帳票出力です。画面から一件ずつ登録するオンライン処理だけでなく、夜間に大量の取引をまとめて集計するバッチ処理も重要な役割を担います。計算順序、締め日、丸め、例外時の扱いなど、長年の制度改定を反映した業務ルールが蓄積されている点が特徴です。

このため、利用者が見ている画面を新しくするだけでは、システム刷新とはいえません。入力データがどのファイルやデータベースに保存され、どのジョブが後続処理を呼び出し、どの帳票や外部システムへ渡るのかまで確認して、業務の流れを再現する必要があります。

COBOL・JCL・データベースはどのようにつながりますか？

COBOLは業務ロジックを記述する言語で、JCLはジョブの実行順序や入出力ファイルを制御する仕組みです。オンライン処理ではトランザクション制御、データ管理ではリレーショナルデータベースや階層型データベース、固定長ファイルなどが使われます。ソースコード、コピー句、ジョブネット、データ定義、画面定義、帳票レイアウト、運用手順を一緒に確認して初めて、現行システムの全体像が見えます。

現行資料が不足していても調査は可能です。ソースの静的解析、ジョブの依存関係分析、実行ログの確認、担当者へのヒアリング、入出力データの照合を組み合わせて、設計書を復元します。2025年以降は生成AIでソースから設計書や業務ルールの候補を作る技術も実用化が進んでいますが、生成結果をそのまま正解にせず、COBOL有識者と業務担当者が承認する工程が必要です（出典: レガシーシステムの生成AI活用に関する公式技術記事、2025年）。

COBOLのシステムにはどんな種類がありますか？

COBOLのシステムは、利用する業界だけでなく、処理方式と刷新方針によって整理すると比較しやすくなります。オンライン中心かバッチ中心か、現行COBOLを残すか新しい言語へ移すか、専用環境を維持するかクラウドへ移すかを分けて考えることがポイントです。

オンライン処理とバッチ処理

オンライン処理は、窓口や担当者が入力した取引を短時間で受け付け、残高、在庫、契約状態などを更新する方式です。同時更新、排他制御、障害時の再実行、応答時間、利用可能時間が重要になります。金融、保険、公共料金、受発注など、処理結果をすぐに次の業務へ渡す領域で使われます。

バッチ処理は、一定期間の取引をまとめて集計・照合・請求・給与計算する方式です。ジョブの順序、処理件数、実行時間、異常終了時の再開位置、前日データとの境界を管理します。オンラインとバッチが同じデータを扱う場合は、締め処理中の更新制御と、遅延したジョブが後続業務へ与える影響を確認します。

メインフレーム型とオープン系・クラウド型

メインフレーム型は、長時間の連続稼働、大量トランザクション、集中管理、障害復旧の運用ノウハウを活かしやすい構成です。処理の安定性と既存データの継承が強みである一方、専門人材の確保、実行環境の維持費、外部APIとの接続、開発環境の更新が課題になりやすいです。

オープン系やクラウド型は、一般的な開発環境、API、監視、データ分析基盤と組み合わせやすく、開発者を確保しやすい可能性があります。ただし、文字コード、日付、数値精度、ファイル形式、トランザクション、ジョブ制御を移し替える必要があります。環境を変えること自体を目的にせず、連携拡張や保守体制などの経営課題に結び付けて判断します。

リテイン・リホスト・リライトなどの違い

リテインは現行COBOLを保守しながら必要な部分だけ改善する方式です。リホストは業務ロジックを大きく変えずに実行基盤を移す方式で、リプラットフォームはCOBOLをオープン系の実行環境へ移す方式です。ラッピングは既存機能をAPIなどで外部から利用し、新しい画面やサービスを段階的に追加する考え方です。

リファクタリングは内部構造を整理し、リライトは別の言語へ書き換えます。リビルドは業務要件を見直して新しいシステムとして再構築する方法です。業務ルールが安定しており停止できないならリテインやリホスト、連携拡張や人材確保を急ぐならラッピングやリプラットフォーム、制度や業務そのものを変えるならリビルドを候補にします。

COBOLのシステム開発・刷新はどのように進めますか？

COBOLの刷新は、いきなり変換ツールを動かすのではなく、現状把握、目的と範囲の決定、方式比較、PoC、詳細設計、移行リハーサル、本番移行、運用定着の順に進めます。特に重要なのは、仕様書がない状態でも見積もりを急がず、ソースコードと業務の依存関係を調査することです。

現行資産の棚卸しとアセスメント

最初に集める資料は、COBOLソース、コピー句、JCL、プロシージャ、画面定義、帳票定義、データベース定義、ファイルレイアウト、ジョブネット、外部インターフェース、障害履歴、運用手順です。プログラム本数だけでなく、オンライン画面数、バッチ数、月次・年次処理、データ量、利用頻度、外部接続先、停止可能時間を一覧化します。

仕様書が欠落している場合は、静的解析で呼び出し関係や入出力を調べ、実行ログと照合します。担当者の記憶に依存する例外処理や手作業もヒアリングで補います。2026年時点の公式なモダナイゼーション資料では、COBOLだけでなくコピー句、JCL、画面定義、データベース、ファイルまでを分析対象にし、人間の確認を途中に置く方式が示されています（出典: 主要クラウド公式ドキュメント、2026年確認）。

小さな業務でPoCと同値性を検証

全体を一度に変換する前に、依存関係が比較的少なく、業務効果を測りやすいサブシステムを選びます。入力件数、計算結果、エラー処理、帳票、処理時間、データ更新、監査ログを旧システムと新システムで比較します。金額の丸め、日付の境界、負数、空白、文字コード、桁あふれは、変換後に差が出やすい項目です。

生成AIや自動変換を使う場合も、変換できた行数や生成コードの量だけで成功と判断しません。業務担当者が代表ケースと異常ケースを承認し、テスト証跡、差分の理由、未変換箇所、既知の制約を残します。PoCでは技術の実現性だけでなく、移行後に誰が保守するか、どの資料を納品してもらうかまで確認します。

並行稼働・移行リハーサル・切り戻し

本番移行では、旧システムと新システムを一定期間並行稼働させ、同じ入力に対する結果を比較する方法が有効です。二重更新が難しい場合は、片方を参照専用にする、差分データだけ連携する、締め処理単位で切り替えるなど、業務特性に合わせて設計します。移行前のバックアップ、移行後の件数照合、障害時の旧系復帰、担当者への連絡網を事前に決めます。

リリース判定には、性能、機能、データ件数、帳票、外部連携、監査ログ、復旧時間、利用者教育の完了条件を置きます。休日や締め処理の直前を避けるだけでなく、切り戻し可能な時間を確保し、実データに近い条件で複数回リハーサルを行います。稼働後は問い合わせ窓口、障害の優先度、監視項目、バックアップ復元テスト、改善計画を運用手順に落とし込みます。

COBOLのシステムの費用相場と開発期間

COBOLの刷新費用は、プログラム本数だけでは決まりません。現行分析、設計書の復元、データ変換、外部連携、同値性テスト、並行稼働、教育、運用引き継ぎを含める必要があります。以下の金額は公開見積もりの平均ではなく、一般的な業務システムの費用感にCOBOL特有の工程を加味した、本記事作成上の試算です。実際の金額はアセスメントとRFPで確定します。

▶ 詳細はこちら：COBOLのシステム開発の見積相場や費用/コスト/値段について

アセスメント・設計書復元の費用

ソース、JCL、データ定義、ジョブ、帳票、外部連携を棚卸しし、影響範囲と移行候補を整理する費用は、目安として300万〜1,000万円、期間は1〜4か月です。対象資産が少なく資料も整っていれば抑えやすく、仕様書が欠落している、担当者しか知らない手作業が多い、複数の実行環境が混在している場合は上振れします。

この工程は、開発前の付加作業ではなく、見積もりの精度を高めるための投資です。アセスメントを省いて低い初期見積もりを出すと、後から未確認のバッチ、例外処理、データ移行、帳票、運用要件が追加されやすいです。成果物として、資産一覧、依存関係、リスク一覧、対象範囲、方式比較、次工程の見積条件を受け取ります。

リホスト・リプラットフォームの費用

小規模なCOBOL業務のリホストや準備は1,000万〜5,000万円、4〜10か月が一つの目安です。中規模の基幹サブシステムを移す場合は5,000万〜2億円、8〜18か月程度を想定します。データ変換、API連携、帳票の再現、性能検証、並行稼働、障害復旧の設計まで含めると、単純な実行環境の移設より大きくなります。

クラウドへ移す場合は、開発費だけでなく、ネットワーク、バックアップ、監視、ログ保管、セキュリティ、商用ランタイム、データ転送、24時間運用の費用も確認します。従量課金は利用量が増えたときに変動するため、通常月、繁忙期、障害復旧時の上限を試算し、予算管理の責任者を決めておきます。

リライト・リビルドの費用と保守費

COBOLから別の言語へリライトする場合は3,000万円〜数億円、12〜30か月が目安です。大規模メインフレーム全体の刷新では2億〜10億円超、2〜5年に及ぶこともあります。これはコード変換だけでなく、業務仕様の再確認、画面・帳票の作り直し、データ移行、連携テスト、教育、段階リリース、災害対策まで含めた場合の幅です。

初期費用5,000万円の案件では、年間保守費を初期費用の15〜20%、つまり750万〜1,000万円程度で試算することがあります。ただし、これは一般的な目安であり、実行環境の利用料、クラウド費用、監視、ライセンス、24時間対応、セキュリティ対策は別途発生する場合があります。見積書では、開発、移行、保守、利用料を分けて記載してもらいます。

公開されている海外の大規模な国防関連システムの刷新事例では、メインフレームからクラウド基盤へ移行し、ホスティング費用だけで年間750万ドル、全体では年間2,500万ドルの削減効果が示されています（出典: 大規模メインフレーム刷新の公式事例、2026年確認）。ただし、これは複数年の運用費と大規模な利用環境を含む事例であり、日本の開発費相場へそのまま換算できません。自社では、現行の保守費、設備費、ライセンス費、運用人件費、障害対応費を分けて比較します。

COBOLのシステム開発会社・ベンダーの選び方

開発会社・ベンダーは、知名度や提示価格だけでなく、現行資産を読み解き、業務を止めずに移行し、稼働後の運用を引き継げるかで比較します。COBOLを新規に書けることと、既存システムの仕様復元・データ移行・同値性テストができることは別の能力です。

現行基盤と業務領域の経験を確認します

候補先には、利用中のメインフレームや実行環境、COBOLの方言、オンライン制御、データベース、ファイル形式、ジョブ制御を扱った経験を確認します。金融、保険、公共、流通、製造などの業務知識が必要な場合は、制度や締め処理を理解する担当者が提案・設計・テストに参加するかを見ます。過去の実績は社名や件数だけでなく、対象範囲、移行方式、停止時間、成果物、移行後の保守体制まで説明してもらいます。

人材の属人化を解消したい案件では、COBOL有識者、移行設計者、データ担当、テスト責任者、業務責任者の役割を明確にします。再委託や海外拠点を含む場合は、機密データの取り扱い、アクセス権、国内での責任者、レビュー方法、成果物の引き継ぎ、担当者が交代した場合の継続性を契約前に確認します。

提案内容と見積もりの透明性を比べます

提案書では、リテイン、リホスト、リプラットフォーム、リライト、リビルドの候補を同じ前提で比較してもらいます。自社にとって都合のよい方式だけを勧めるのではなく、対象範囲、停止時間、データ移行、テスト、切り戻し、運用負荷、将来の拡張性を評価軸にした比較表を求めます。AI変換を使う場合は、生成物のレビュー、入力データの匿名化、学習利用の扱い、テスト証跡、未変換箇所の責任分界も確認します。

見積書は、アセスメント、設計書復元、変換・実装、データ移行、外部連携、試験、並行稼働、教育、運用引き継ぎ、保守、ライセンス、インフラを分けます。「一式」だけの見積もりは追加費用の条件が分かりにくいため、前提資料、対象外、変更管理、納品物、検収条件、障害対応の範囲を明記してもらいます。

RFPで必ず確認する10項目

RFPには、対象プログラムと業務、現行基盤、データ量、外部連携、許容停止時間、同値性テスト、移行リハーサル、成果物、セキュリティ、体制と保守を記載します。特に、ソースコードと設計書だけでなく、JCL、ジョブネット、帳票、テストデータ、運用手順、監視設定、障害対応記録まで納品対象に含めることが重要です。

候補先からの質問内容も評価材料になります。業務の締め処理、例外時の再実行、マスタ変更、データ保持、災害時の復旧、繁忙期の性能について具体的に質問する候補は、技術だけでなく運用リスクを見ている可能性があります。反対に、ソースの行数だけで短納期や低価格を断定する提案は、未確認の業務ルールが残っていないか慎重に確認します。

▶ 詳細はこちら：COBOLのシステム開発でおすすめの開発会社/ベンダー6選と選び方

▶ 詳細はこちら：COBOLのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

▶ 詳細はこちら：COBOLのシステム開発の発注/外注/依頼/委託方法について

COBOLのシステム刷新で注意すべきリスクと対策

COBOLのシステムでは、言語そのものだけでなく、古い実行環境、外部接続、特権ID、バッチファイル、バックアップ、委託先の作業端末までを一つのシステムとして守ります。刷新によって接続先や運用担当が変わると、これまで閉じていた環境に新しい攻撃経路が生まれることもあります。

脆弱性・特権ID・委託先を管理します

IPAの「情報セキュリティ10大脅威 2025」では、組織向けの脅威として、ランサム攻撃、サプライチェーンや委託先を狙った攻撃、脆弱性を突いた攻撃、内部不正による情報漏えいなどが挙げられています（出典: IPA「情報セキュリティ10大脅威 2025」、2025年）。COBOL刷新でも、ソースや本番データへのアクセスを必要最小限にし、特権IDを個人単位で発行し、操作ログと承認記録を残します。

開発環境、本番環境、バックアップ環境を分離し、テストデータは匿名化します。委託先がソースやデータを持ち出す場合は、保管場所、暗号化、アクセス期限、返却・消去、再委託、事故時の連絡と補償を契約に入れます。移行後は古い接続口、不要なアカウント、使われていないジョブ、平文の認証情報を残さないことも確認します。

データ同値性と業務継続を守ります

移行リスクで特に注意するのは、処理は動くのに結果がわずかに変わるケースです。十進数の精度、符号、日付の境界、半角・全角、改行、空白、コード変換、並び順、欠損値、丸め処理を比較し、金額・残高・保険料・給与・在庫など重要項目の許容差をゼロにするか業務責任者が決めます。

業務継続の観点では、障害時に旧システムへ戻す条件、復旧目標時間、代替入力、手作業での受付、後からの再登録方法を設計します。高可用性を採用するだけでは不十分で、実際にバックアップから復元できるか、担当者が切り替え手順を実行できるかを訓練します。

AI変換の精度とガバナンスを確認します

AIによるコード解析や変換は、設計書の復元、依存関係の整理、テストケース作成を速める可能性があります。2025年にはメインフレームの分析からコード文書化・リファクタリングまでを支援するサービスが一般提供され、2026年には要件、ソース、生成コードのつながりを追跡しやすくする機能も公開されています（出典: メインフレーム刷新に関する公式サービス情報、2025〜2026年）。

ただし、AIが生成した設計書やコードが業務上正しいとは限りません。機密情報を外部へ送信しない設定、利用モデルと保存期間の確認、生成物のレビュー責任、テストデータの匿名化、変更履歴、承認者、再現可能なテストを定めます。AIは調査と変換を補助する道具と位置付け、最終的な業務判断と本番リリースは人が担います。

COBOLのシステムに関するよくある質問

COBOLのシステム刷新では、「古いから移行する」という単純な判断より、業務の重要度、停止可能時間、人材、資料、データ、将来の連携をまとめて確認することが大切です。ここでは、特に相談の多い質問へ先に結論から回答します。

COBOLのシステムは使い続けても問題ありませんか？

安定稼働していて業務要件も変わらない場合は、使い続ける選択肢があります。ただし、担当者不足、保守期限、外部連携の制約、セキュリティ、運用費、障害復旧の難しさを点検し、保守継続の条件を明文化します。全面移行を急ぐのではなく、API連携や設計書復元から始める方法もあります。

仕様書がなくてもCOBOLの移行見積もりは取れますか？

取れますが、最初から確定額を求めるのではなく、アセスメントの見積もりを先に取ることが現実的です。ソース、コピー句、JCL、ジョブネット、データ定義、帳票、ログ、運用手順、担当者ヒアリングをもとに現行仕様を復元し、その成果を次のRFPと詳細見積もりへつなげます。資料が少ないほど、調査費と予備費を別枠で置きます。

AIでCOBOLを自動変換すれば短期間で移行できますか？

AIや自動変換によって調査、設計書作成、コード変換、テスト準備の期間を短縮できる可能性はありますが、短期間で本番移行できるとは限りません。業務仕様の確認、データ同値性、例外処理、性能、セキュリティ、利用者の受入確認は必要です。変換率ではなく、業務結果の正しさとテスト証跡で効果を評価します。

COBOLを残すかJavaなどへ移すか、どう決めればよいですか？

業務の停止可能時間、現行資産の品質、技術者の確保、処理性能、外部連携、将来の変更頻度、セキュリティ、予算を評価して決めます。停止できず業務ルールが安定しているなら段階的なリホストやラッピング、連携拡張や保守人材の確保が目的ならリプラットフォーム、業務そのものを変えるならリビルドを候補にします。最初に全体を一択へ決めず、業務単位で方式を分けても問題ありません。

まとめ

COBOLのシステムは、COBOLのソースだけでなく、JCL、オンライン制御、データベース、ファイル、帳票、外部連携、運用手順まで含む業務基盤です。長年の安定性と業務知識が蓄積されている一方、技術者不足、仕様書の欠落、保守費、連携やセキュリティの制約が課題になります。

最初に行うべき4つのこと

まず、現行資産と業務を棚卸しして、仕様書にない処理や担当者依存を可視化します。次に、保守継続、リホスト、リプラットフォーム、リライト、リビルドを、停止時間・費用・人材・将来性で比較します。その後、小さな業務でPoCと同値性テストを行い、最後に並行稼働、移行リハーサル、切り戻し、運用引き継ぎまで含む段階計画を作ります。

全面刷新ではなく業務単位で判断します

COBOLを残すか捨てるかを最初から二択にする必要はありません。止められない処理は現行環境で安定稼働させ、周辺からAPI化する、設計書を復元する、データ分析基盤を分ける、利用頻度の低い業務から移すなど、リスクを分散する方法があります。開発会社・ベンダーには、方式のメリットだけでなく、移行しない場合のリスク、追加費用の条件、成果物、保守体制、切り戻し条件まで説明してもらうことが大切です。