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

COBOLのシステムは、プログラムだけでなく、ジョブ制御やデータ、外部連携まで含めた業務基盤です。刷新では、業務ルールと依存関係、停止可能時間を調べたうえで業務ごとに方式を選び、段階的に進めると継続性と保守性を両立できます。

各テーマの詳細は、下の関連記事で確認できます。

AI駆動開発の基本や工程ごとの活用方法、費用・期間への影響については、無料ホワイトペーパー「【2026年最新版】AI駆動開発の完全ガイドブック」で詳しく解説しています。

COBOLのシステムの定義と構成要素

刷新範囲は周辺の構成要素まで見渡して捉えます。

COBOLのシステムは、プログラムを中心に、データベースやファイル、ジョブ制御などを組み合わせた業務処理基盤です。業務アプリケーションに加え、帳票、外部連携、運用監視まで含みます。

メインフレームでは、COBOLとJCL、オンライン制御がデータベースやファイル管理と一体で動くため、言語だけを見て刷新範囲を決めると重要な依存関係を見落とします。

COBOLシステムが支える業務

COBOLシステムは、取引や集計を支える業務の土台になっています。業務ごとに扱う内容は、下の一覧で示します。

取引・会計：売上・請求・入出金、口座振替を扱います。
契約・人事：保険契約や給与を処理します。
供給・生産：在庫、受発注、生産実績、料金計算を管理します。
帳票・集計：出力や、夜間の大量取引の集計を担います。

画面から取引を登録するオンライン処理に加えて、夜間のバッチ処理も重要です。バッチには、計算順序や締め日、丸めの決まりから例外時の扱いまで、制度改定を反映した業務ルールが積み重なっています。

刷新では、画面を作り直すだけでなく、業務の流れを再現することが求められます。そのために、入力データの保存先や後続ジョブを確かめ、帳票や外部システムとの連携まで見ます。

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と同値性を検証

PoCでは、依存関係が比較的少なく業務効果を測りやすいサブシステムを選び、旧システムと新システムの結果を照合します。

処理結果：入力件数、計算結果、エラー処理、データ更新。
出力・運用：帳票、処理時間、監査ログ。
差が出やすい値：金額の丸め、日付の境界、負数、空白、文字コード、桁あふれ。

生成AIや自動変換を使う場合も、成否は変換行数や生成コード量ではなく、業務結果で判断します。そのうえで、業務担当者が代表ケースと異常ケースを承認し、テスト証跡や差分理由、未変換箇所、既知の制約を残します。

PoCでは、技術の実現性に加えて、移行後の保守担当者と納品資料も確認します。

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

本番移行に備えて、並行稼働で結果を比べます。そのうえで、業務特性に合う更新方式と、旧系へ戻す復帰手順を決めます。

突き合わせ：旧システムと新システムを一定期間動かし、同じ入力への結果を比べます。
更新方式：二重更新が難しい場合は、片方の参照専用化や差分連携、締め処理単位の切り替えを検討します。
切り替えの備え：事前バックアップ、移行後の件数照合、旧系への復帰、担当者への連絡網の決定。

リリース判定には、性能と機能、データ件数の完了条件を置きます。帳票や外部連携、監査ログ、復旧時間、利用者教育についても、条件を定めます。

休日や締め処理の直前は避け、切り戻し時間を確保したうえで、複数回リハーサルします。稼働後は、問い合わせ窓口や障害の優先度、監視項目を運用手順に記載します。さらに、復元テストと改善計画も含めます。

ポイント

段階を飛ばさず、方式の比較やPoCの結果を見てから詳細設計と移行に進むかどうかが目安です。PoCで差が出た場合は、対象を小さく区切り直します。

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

見積もりでは開発以外の移行作業も項目として確認できます。

刷新費用は、プログラム本数に加えて、どこまでの作業を含めるかで決まります。見積もりには、現行分析や設計書の復元、データ変換が入ります。さらに、外部連携や同値性テスト、並行稼働、教育、運用引き継ぎも対象です。

金額は、公開見積もりの平均ではなく、一般的な業務システムの費用感にCOBOL特有の工程を加味して本記事で試算したものです。なお、実額は、アセスメントとRFPで確定します。

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

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

アセスメントでは、ソースやJCL、データ定義を棚卸しして、影響範囲と移行候補を整理します。ジョブや帳票、外部連携も対象です。

費用・期間：300万〜1,000万円、1〜4か月が目安です。
抑えやすい条件：対象資産が少なく、資料が整っています。
上振れ要因：仕様書の欠落、担当者しか知らない手作業、複数の実行環境。
省略時の影響：未確認のバッチや例外処理、移行、帳票、運用要件が後から追加されやすくなります。

アセスメントは、見積もりの精度を高めるための投資です。成果物には、資産一覧や依存関係、リスク一覧のほか、対象範囲や方式比較、次工程の見積条件も含まれます。

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

リホストやリプラットフォームでは、小規模業務と中規模の基幹サブシステムで費用・期間が異なります。

小規模業務：1,000万〜5,000万円、4〜10か月。
中規模の基幹サブシステム：5,000万〜2億円、8〜18か月程度。

データ変換やAPI連携、帳票の再現を含めると、実行環境だけの移設より費用がかかります。さらに、性能検証や並行稼働、障害復旧の設計も含まれます。

クラウドでは、開発費のほかに、ネットワークやバックアップ、監視を確認します。ログ保管やセキュリティ、商用ランタイム、データ転送、24時間運用も、費用の確認対象です。

従量課金は利用量によって変わるため、通常月や繁忙期、障害復旧時の上限を試算し、予算の責任者を決めておきます。

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

リライトや大規模刷新は、規模によって費用と期間に幅があります。代表的な目安を、下に並べます。

リライト：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で確認したい項目

RFPは、提案の前提をそろえるために、対象システムから納品物、保守条件まで記載します。

現行環境の情報：対象プログラム・業務、現行基盤、データ量。
接続条件：外部連携と許容停止時間。
検証の進め方：同値性テストと移行リハーサル。
成果物：ソース、設計書、JCL、ジョブネット、帳票。加えて、テストデータ、運用手順、監視設定、障害対応記録。
運用の責任：セキュリティを含む体制と保守の条件。

候補先の質問も、評価の材料になります。締め処理や例外時の再実行、マスタ変更、データ保持、災害復旧、繁忙期の性能を具体的に尋ねる候補は、運用リスクにも目を向けている可能性があります。

ソース行数から短納期や低価格を言い切る提案は、未確認の業務ルールが残っていないか慎重に確認します。

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

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

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

ポイント

会社は、同じ前提で出された見積もりを並べ、移行後の保守まで説明できるかで比べます。知名度だけで選ぶことは避けたいところです。

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

COBOLシステムは、言語だけでなく、実行環境や外部接続、特権ID、バッチファイル、バックアップ、委託先端末まで含めて守ります。また、刷新で接続先や担当が変わり、新たな攻撃経路が生まれることもあります。

脆弱性・特権ID・委託先の管理

IPAの「情報セキュリティ10大脅威 2025」は、組織向けの脅威として、ランサム攻撃や委託先を狙う攻撃を挙げています。脆弱性攻撃や内部不正による漏えいも、そこに含まれます（出典: IPA「情報セキュリティ10大脅威 2025」、2025年）。

アクセス管理：ソースと本番データへの権限を絞り、特権IDを個人単位で発行して操作ログと承認記録を残します。
保管場所の区分：開発、本番、バックアップ環境を分離し、テストデータを匿名化します。
外部の取り扱い：持ち出しデータの保管、暗号化、期限、返却・消去、再委託、事故時の連絡と補償を契約で定めます。
移行後：古い接続口や不要なアカウント、未使用ジョブ、平文の認証情報は取り除きます。

データ同値性と業務継続

移行リスクで特に注意したいのは、処理は動いていても、結果がわずかに変わるケースです。差を確認したうえで、業務継続の備えも整えます。

ずれの生じやすい箇所：十進数精度や符号、日付境界、半角・全角、改行、空白。加えて、コード変換、並び順、欠損値、丸め。
重要項目：金額、残高、保険料、給与、在庫の許容差をゼロにするか、業務責任者が決めます。
障害対応：旧システムへの復帰条件、復旧目標時間、代替入力、手作業受付、後からの再登録方法。

高可用性の採用に加えて、バックアップから実際に復元できるか、担当者が切り替え手順を実行できるかを訓練します。

AI変換の精度とガバナンス

AI解析や変換は、設計書の復元、依存関係の整理、テストケース作成を速める可能性があります。たとえば、2025年にはメインフレームの分析から文書化・リファクタリングまで支援するサービスが一般提供されました。

2026年には、要件やソース、生成コードのつながりを追跡しやすくする機能も公開されています（出典: メインフレーム刷新に関する公式サービス情報、2025〜2026年）。

取り扱い方針：生成物が正しいとは限らないため、機密情報を外部送信しない設定、利用モデル、保存期間を確認します。
確認と記録：生成物のレビュー責任、テストデータの匿名化、変更履歴、承認者、再現可能なテストを定めます。
最後の決定：AIは調査と変換の補助とし、業務判断と本番リリースは人が担います。

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

刷新では、業務の重要度や停止可能時間、人材、資料、データ、将来の連携をまとめて確認します。特に相談の多い質問については、結論から先に回答します。

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

安定して稼働し、業務要件も変わらない場合は、使い続ける選択肢があります。保守を続ける条件を明文にしておくため、点検項目を確認します。

体制：担当者不足や保守期限。
接続面：外部連携の制約やセキュリティ。
コスト面：運用費や障害復旧の難しさ。

全面移行を急がず、API連携や設計書の復元から始める方法もあります。

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

仕様書がなくても、見積もりは取れます。ただし最初は、確定した金額よりも、アセスメント費用を見積もってもらう形になります。

資産資料：ソース、コピー句、JCL、ジョブネット、データ定義、帳票。
補足資料：ログ、運用手順、担当者への聞き取り。

現行仕様を復元して、その成果を次のRFPと詳細見積もりにつなげます。資料が少ないほど、調査費と予備費は別枠で置いておきます。

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

AIや自動変換で、調査や設計書作成、コード変換、テスト準備を短縮できる可能性はあります。ただし、短期間で本番移行できるとは限りません。

業務仕様、データ同値性、例外処理、性能、セキュリティ、利用者の受入確認が必要です。そのうえで、効果は変換率よりも、業務結果の正しさとテスト証跡で評価します。

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

停止可能時間や現行資産の品質、技術者、性能を評価します。さらに、連携や変更頻度、セキュリティ、予算も見ます。

なお、最初から全体を一択にせず、業務単位で方式を分けても問題ありません。停止できず業務ルールが安定しているなら、段階的なリホストやラッピングが候補です。連携拡張や人材確保が目的ならリプラットフォーム、業務自体を変えるならリビルドを検討します。

まとめ

COBOLシステムは、ソースだけでなく、JCLやオンライン制御、データベースを含む業務基盤です。ファイルや帳票、外部連携、運用手順も、その一部です。

長年の安定性と業務知識が蓄積されている一方で、技術者不足や仕様書の欠落、保守費、連携やセキュリティの制約が課題になります。

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

刷新は、現状把握から方式の選定、検証、移行準備へと段階を踏んで計画します。

現行資産と業務を棚卸しし、仕様書にない処理や担当者依存を一覧にします。
保守継続からリビルドまでの各方式を、停止時間や費用、人材、将来性で比べます。
小さな業務で、PoCと同値性テストを実施します。
並行稼働、移行リハーサル、切り戻し、運用引き継ぎを含む段階計画を作成します。

業務単位での判断

COBOLを残すか捨てるかは、最初から二択で決める必要はなく、業務単位で分けて判断できます。

段階的な拡張：止められない処理は現行環境で動かし、周辺からAPI化する。
資料の整備：設計書を復元し、データ分析基盤を分けておく。
進める順番：利用頻度の低い業務から移行を始める。

開発会社には、方式の利点に加えて、移行しない場合のリスクや追加費用の条件、成果物、保守体制、切り戻し条件も説明してもらいます。

▼開発を相談する前に読みたい無料ホワイトペーパー
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。