COBOLのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

COBOLのシステム開発は、現行資産を洗い出し、業務ごとに方式を選ぶところから始まります。代表業務で検証してから段階的に移行すると、業務ルールを保ちながら刷新を進められます。

全体像は、COBOLのシステム開発の完全ガイドもあわせてご覧ください。

▼全体ガイドの記事
・COBOLのシステム開発の完全ガイド

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

COBOLのシステム開発の全体像

COBOLのシステムは、プログラムの言語という面だけでなく、業務アプリケーションやバッチ処理まで含めた業務処理の仕組みです。

その中には、オンライン取引、データベース、ジョブ制御、帳票、運用基盤までが含まれます。

開発や刷新では、ソースコードに加えて、JCLやCICS、DB2などの要素も確かめる必要があります。

ソースだけで判断すると、VSAMやIMS、外部ファイル、手作業の運用を見落とすおそれがあります。

COBOLのシステムが担う業務と構成

COBOLシステムでは、次のような業務のデータ登録や集計、帳票出力を扱います。

• 取引・契約：売上、請求、入出金、口座振替、保険契約。
• 社内業務：給与、在庫、受発注、生産実績のデータ登録。
• 処理と出力：照合、集計、締め処理、帳票の出力。

オンライン処理では、高い可用性とトランザクションの正確性が求められます。一方、夜間バッチでは、大量データを一括で計算し、他システムとファイルで連携します。

制度改定や業務変更が長年反映されているため、個々の処理に現場の例外ルールが含まれる場合もあります。

構成を把握するには、ソースコードやJCL、DB定義などを資産台帳に整理します。コピー句やジョブネット、帳票定義などは、この台帳に含めます。外部連携、運用手順、障害履歴も記録します。

設計書が残っていても、現行プログラムと一致するとは限りません。

資料と実装、担当者の知識を照合し、業務ルールと資産の対応を確かめます。

COBOLを残すか移行するかの判断

COBOLを残すか移行するかは、業務ごとに蓄積した価値と将来の運用条件を比べて決めます。

残す根拠がある業務は維持し、残す理由が弱い部分は段階的な選択肢から替えていきます。

• 継続利用の根拠：蓄積した業務ルールや障害時の運用ノウハウがあり、既存データとの整合性や周辺連携の実績もあります。
• 段階的な選択肢：API接続、実行基盤の移行、特定業務の再構築から選べます。古い言語だけを理由に全面置換する判断は、危険です。
• 方式の比較観点：業務の重要度・変更頻度、停止可能時間、人材確保、監査要件、データ連携、5年から10年先の運用費で比べます。
• 仕様書が不足する場合：まずアセスメントを行い、設計書を復元します。

NTT DATAは2025年の公開情報で、COBOLソースから設計情報を復元する取り組みを紹介しています。さらに、COBOL有識者による精度評価も組み合わせています（出典: NTT DATA「レガシーシステムのモダナイゼーションを加速する、生成AIの活用法」、2025年）。

生成AIは、ソースの中身を分かりやすく示す作業を助けます。

業務担当者の承認まで、AIで自動化するものではありません。

COBOLのシステム開発の進め方

COBOLのシステム開発は、要件整理から定着までを6つのフェーズに分けて進めます。そのため、技術課題と業務課題を別々に管理しやすくなります。

各フェーズでは、発注側と開発会社が成果物と判断基準を決め、次工程へ進む前に関係者の合意を取ります。

現行仕様が分からない場合は、最初から全機能を作り始めず、業務単位や移行波単位で小さく検証します。

フェーズ1：要件整理による目的と対象範囲の決定

技術の目標だけでなく、経営と業務の課題も言葉にします。そのうえで、要件整理で集める情報をそろえます。

• 課題の例：保守期限や技術者不足、夜間バッチの長時間化、制度変更への対応遅れ、クラウドやAPI接続、運用費の見直し。
• 課題ごとの記録：現状の数値と目標値、未対応時の影響、対応期限、関係部署を書き留めます。
• 資産台帳：業務名、オンライン画面数、バッチ数、ソース本数、データ量、連携先、実行頻度を一覧にします。
• 運用と調査資料：停止可能時間、担当者、復旧手順を記し、ソース、JCL、コピー句、ジョブ実績、帳票サンプル、入出力ファイルを集めておきます。
• 完了条件：対象と対象外の範囲、重要業務、移行制約、受け入れ基準を文書にまとめ、両部門が承認します。

仕様書がない場合は、運用者へのヒアリングも調査の出発点になります。

フェーズ2：方式と実行基盤の選定

方式は全体で一つに統一せず、業務ごとに候補を選びます。そのうえで、適用領域と比較条件をそろえます。

• 現行維持・基盤移行：リテインはCOBOLを保守し続け、リホストは実行基盤だけを移します。
• 基盤変更・内部整理：リプラットフォームはオープン系やクラウド上でCOBOLを動かし、リファクタリングは内部構造を整えます。
• 書き換え・パッケージ：リライトはJavaなどへ書き換え、パッケージ移行はSaaSやERPへ業務を寄せます。
• 段階利用：ラッピングでは、APIを通じて新システムから段階的に利用します。

選定表では、業務適合度、データ移行量、停止可能時間を比べます。さらに、性能と監査・セキュリティを並べます。また、人材依存、5年間の運用費、ベンダー変更時の移行しやすさも見ます。

現行ロジックを残す業務はリホストなど、標準化できる領域はパッケージを検討します。

新しい顧客接点やAPI連携が重要な領域は、再設計を検討します。

候補を決める前に、代表業務でPoCを行い、処理結果と運用負荷を確かめます。

フェーズ3：設計・開発による業務ルールの再現

現行処理の移し替えと業務の再設計は、分けて扱います。そのうえで、基本設計に必要な情報を次のとおり記録します。

• 業務と機能：業務フロー、機能一覧、データ項目、コード値を記録します。
• 処理ルール：日付と金額の扱い、丸め規則、締め処理、例外処理。
• 統制と接続：権限、帳票、外部連携を記録します。
• 資産との対応：現行資産と新機能を対応付け、処理を残す・廃止・統合・再設計に分類します。

生成AIや静的解析は、ソースから呼び出し関係や入出力、変数の意味を読み取り、設計書のたたき台を作る用途に向きます。

AWSは2025年にメインフレーム向けのAWS Transformを一般提供し、分析や文書作成、リファクタリングなどを支援する機能を公開しました。

2026年には、リファクタリング機能が18リージョンで利用できると案内されています（出典：AWS「AWS Blu Insights is now AWS Transform for mainframe refactor」、2026年）。

AIが生成した設計やコードは、まず機密情報の扱いを確認してから利用します。COBOL有識者と業務担当者がレビューし、承認済みの成果物として管理します。

フェーズ4：テストによる現行と新システムの同値性の確認

画面の表示だけで合格とせず、機能、バッチ、データ、性能を現行と比べて確かめます。

• 機能と境界値：通常処理、月末・年度末、閏年、うるう秒を含む時刻処理、負数、ゼロ、最大桁の境界を確認します。
• 異常系：文字コード、金額の丸め、重複データ、異常終了、再実行、ロールバック。
• バッチ：処理件数、完了時刻、後続ジョブ、帳票件数、エラー件数を現行と比べます。
• 性能：ピーク時の同時利用者数、バッチ時間、I/O、ネットワーク、障害復旧時間。

テストデータは、匿名化した本番相当のデータと、境界値を含む人工データを組み合わせます。

テストでは、日次・月次・年次の代表期間を選び、入力、途中の状態、出力、監査ログを比べます。

「完全一致」以外に許容する差異は、理由とあわせて事前に定めておきます。測定値が基準を満たさない場合は、稼働判定へ進めません。

フェーズ5：稼働と切り戻しの計画

稼働前に決めておく準備と、切り戻しの判断条件を具体的にします。

• 移行準備：データ移行、本番バックアップ、差分取り込み、利用者通知、休日・夜間の体制を決めておきます。
• 運用連絡：監視、問い合わせ窓口、障害時のエスカレーションを整えます。
• 切り替え方式：停止できない業務では、並行稼働、二重更新、差分照合、段階リリースを組み合わせます。
• 判定条件：誰がどの数値を見て、何分以内にどの手順で判断するかを決めます。残高差異、バッチ遅延、連携エラー、処理件数、応答時間、重大障害が対象です。

停止が事業に直結する業務では、切り替えの時間だけでなく、旧系へ戻せる時間と条件も重視します。給与や決済のほか、保険金支払、出荷などが該当します。

Go・No-Goの責任者を決めます。

そのうえで、移行データの作成から照合、障害時の復旧まで複数回リハーサルし、計画と実績の差を修正します。本番直前の一度だけで終わらせず、手順を繰り返し確認することで、切り戻しの実効性を高めます。

フェーズ6：定着と運用引き継ぎ

運用担当者が自分で判断できるように、引き継ぎ資料、訓練、定着後の確認項目をそろえます。

• 運用資料：機能仕様、ジョブネット、監視、バックアップと復旧、障害対応、データ修正承認を引き継ぎます。
• 管理手順：リリース、連絡網、変更管理、ライセンス、契約について、どこまでを誰が受け持つかを明記します。
• 運用訓練：旧担当者が退職しても運用できるかを、実際に訓練して確かめます。
• 月次確認：問い合わせ・障害件数、バッチ完了時刻、復旧時間、手作業削減時間、リリース頻度、利用者の処理時間を毎月追います。

セキュリティ対策も、稼働後に継続して確認します。IPAの「情報セキュリティ10大脅威 2025」では、組織向けにランサム攻撃、サプライチェーンや委託先を狙った攻撃が挙げられています（出典：IPA「情報セキュリティ10大脅威 2025」、2025年）。

脆弱性を突いた攻撃や内部不正も挙げられています。そこで、COBOL刷新では古い実行環境だけでなく、特権ID、外部接続、バッチファイルを運用設計の対象にします。さらに、委託先、バックアップ、監査ログも対象に含めます。

COBOLのシステム開発にかかる費用相場とコストの内訳

刷新費用は、ソース本数だけでなくオンライン画面やバッチ、DBやファイル形式で変わります。帳票、外部連携、データ量も、費用を左右します。

さらに、並行稼働や業界規制、停止可能時間、設計書の有無も関わります。

下に示すレンジは、リサーチノートの業務システム相場と、COBOL案件で追加されやすい作業を踏まえた、記事作成用の推定です。

追加作業には、資産分析やデータ移行、同値性テスト、並行稼働があります（出典: リサーチノート「COBOLのシステム」、2026年）。

ここで示す金額は、公開見積もりの平均値ではありません。

金額は予算計画の起点として使い、アセスメント後に個別見積もりで確定します。対象範囲や制約によって、金額は上下します。

アセスメントと現行資産の棚卸しの費用目安（300万〜1,000万円程度）

アセスメントは、現行資産を調べる作業にかかる費用です。費用と期間は、どこまで調べるか、資料がどれだけ揃っているかで動くため、見積もりの前提をそろえて確かめます。

• 費用と期間：棚卸し、影響分析、設計書の復元、業務ヒアリングは、300万〜1,000万円程度、1〜4か月程度が目安です。
• 調査対象：ソース、JCL、DB定義、ジョブ実績、帳票、外部連携の範囲によって、費用と期間が変わります。
• 上振れ要因：資料不足、担当者の限定、複数の基盤や拠点への資産分散により、調査範囲が増えます。
• 見積もり確認：資産一覧、分析レポート、設計書の粒度、業務部門のレビュー回数、次工程で再利用できる成果物を確かめます。

費用を削りすぎると、未把握の連携や例外処理が後工程で見つかり、追加開発や納期延長につながることがあります。

アセスメントは、報告書の作成で終わらせず、方式選定とRFPの根拠として使います。

移行・再構築の費用幅（1,000万円台から数億円）

方式と規模ごとの費用や期間は、次の範囲が目安です。

• 小規模リホスト：準備を含め1,000万〜5,000万円程度、4〜10か月程度です。
• 中規模リプラットフォーム：基幹サブシステムで5,000万〜2億円程度、8〜18か月程度です。
• リライト・リビルド：COBOLからJavaなどへの刷新で3,000万〜数億円程度、12〜30か月程度です。
• 大規模メインフレーム刷新：複数業務や災害対策、移行、教育、段階リリースを含む場合、2億〜10億円超、2〜5年程度となることがあります。

データ移行やAPI連携のほか、帳票や性能検証、並行稼働を含めるほど、ソース本数が同じでも費用は上がります。

これらは案件ごとの推定レンジで、特定の会社や方式の価格を保証するものではありません。自社の対象範囲と制約を明記したうえで、同じ前提で複数社から個別見積もりを取ります。

保守費・基盤費・移行後の運用費

初期費用に加えて、方式ごとに発生する保守費、基盤費、運用費用も見積もります。

• 保守と基盤：保守契約、商用COBOLランタイム、メインフレームやクラウドの利用料を含めます。
• 運用体制：監視、バックアップ、セキュリティ、24時間運用、障害対応、教育を分けて扱います。
• クラウド費用：従量課金や通信、ログ保管、バックアップを含め、5年分を試算します。災害対策、ライセンス、サポートも対象にします。
• 継続利用費：技術者確保、保守、ハードウェア更新、脆弱性対応、属人化解消も費用に含めます。

リサーチノートでは、業務システムの保守費を初期費用の年10〜20％程度とする一般的な目安を示しています。たとえば、初期開発費が5,000万円なら、保守だけで年間500万〜1,000万円程度が目安です。基盤費や運用体制は、別途必要です。

移行費用と運用費用に、業務停止や失敗のリスクを加えた総保有コストで比べます。そのため、初期費用の安さだけで方式を決めないことが大切です。

COBOLのシステム開発で見積もりを取る際のポイント

見積もりの差は、会社の単価だけでなく前提条件と対象範囲から生まれます。たとえば「COBOLをJavaへ変換する」だけの依頼では、作業範囲が曖昧なままになります。

後から、データ移行や帳票、ジョブ、例外処理が追加される場合があります。並行稼働や教育が加わることもあります。そのため、RFPでは作業範囲と成果物、受け入れ基準を具体化し、どこまでを誰が受け持つかも決めます。

見積もれる粒度での要件と現行資産の整理

作業範囲と前提、成果物を具体的にし、見積もりに必要な情報をそろえます。

• 対象と資産：対象業務と対象外業務、画面一覧、バッチ一覧、ソース本数、依存関係、DB・ファイル定義を洗い出します。
• 規模と制約：データ量、外部連携、帳票のほか、利用者数やピーク時間も記録します。停止可能時間、法令・監査要件も残します。
• 不明項目：「不明」と明記し、調査費を見積もりに含めます。担当者の記憶だけに頼らず、ジョブ実績や本番ログ、障害票、帳票サンプルで前提を補います。
• AI利用条件：入力データを学習に利用しない条件、生成物のレビュー責任を確認します。加えて、プロンプトや変換ルール、再現可能なテスト記録も管理対象にします。

成果物には、要件定義書、方式比較表、復元設計書を含めます。加えて、データ移行設計書や変換後ソース、テスト仕様書と結果証跡も指定します。

運用手順書や教育資料のほか、ソースコードの権利と保管方法も決めます。

複数社の同条件での比較と担当体制の確認

同じ資産台帳や対象業務、移行波、テスト範囲を各社に渡し、価格だけでなく、提案の前提もそろえます。

• 技術・業務経験：COBOL、メインフレーム、JCL、DB、対象業界の知識を確かめます。
• 移行実績：リホスト、リライト、同値性テスト、データ移行、並行稼働の経験を見ます。
• 担当体制：障害対応と移行後の保守を確認します。営業の説明だけでなく、設計とテストの責任者に質問します。
• 海外・委託体制：機密データの扱いや国内責任者、品質レビューを確認します。言語・時差、成果物の引き継ぎ、障害時の連絡時間も確かめます。

2025年12月には、SCSKとFPTジャパンがCOBOL PARKの事業開始を公表しました。同事業は、COBOL人材の確保や、レガシーシステムの継続運用・モダナイズを支援します（出典：SCSK・FPTジャパン「COBOL PARKを設立、事業を開始」、2025年）。

こうした支援体制も選択肢の一つです。自社の基盤と業務では誰が何を担当するのか、提案書で確かめます。

追加費用と切り替えリスクの抑え方

契約条件と試験内容を明確にして、追加費用と切り替えリスクを管理します。

• 費目：アセスメントや要件定義、設計・開発、変換は、それぞれ分けて示します。データ移行、テストデータ作成、性能試験、並行稼働も、別の費目にします。
• 教育・運用：教育、運用引き継ぎ、ライセンス、クラウド利用料、保守も費目に含めます。
• 契約条件：固定価格か準委任か、前提変更の手順、追加単価を確認します。納期、検収、瑕疵対応、ソースや設計書の帰属も確かめます。
• PoCと移行判定：同値性、バッチ時間、データ変換、障害復旧、切り戻しを試し、次の移行波へ進む条件を決めます。
• 責任と追加対応：Go・No-Go基準、重大障害の定義、切り戻し判断者、追加調査の費用負担、納品後の問い合わせ期間を明記します。

金額だけでなく、不確実性をどちらが管理する契約になっているかを見ます。移行リスクは、契約書に書く前に試験で減らします。

条件を明記すると、本番直前の責任の押し付け合いを避けやすくなります。

よくある質問（FAQ）

COBOLのシステム開発では、現行資料の不足、移行方式、費用、停止リスクについて質問が多く寄せられます。発注や社内検討の前に確かめたい疑問には、実務での判断基準から先に答えます。

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

判断の要は、使い続けるかどうかより、将来の条件を満たせるかどうかにあります。

• 維持条件：技術者、保守契約、脆弱性対応、性能、災害対策、周辺連携を将来も維持できるかが基準です。
• 継続・基盤移行：重要業務が安定し、後継者と運用費を確保できるなら選べます。
• 段階移行：人材不足や保守期限が明確なら、まず資産を洗い出し、段階的な移行計画を作ります。

仕様書がなくてもCOBOLのシステムを刷新できますか？

仕様書がない場合は、調査、設計確認、後工程への引き継ぎを分けて進めます。

• 刷新の進め方：仕様書がなくても進められますが、最初から全機能を一括変換しません。
• 現行調査：ソースやJCL、DB定義、ジョブ実績、帳票を集めます。障害履歴や担当者の知識も、調査の材料にします。
• 設計の復元と確認：静的解析や生成AIで設計書案を作り、業務担当者とCOBOL有識者が結果と業務ルールを確認します。
• 後工程への引き継ぎ：承認済みの設計情報だけを使い、資料不足を踏まえて調査費と期間を見積もります。

AIでCOBOLからJavaへ変換すれば費用を下げられますか？

AIや自動化によって、分析や文書作成、変換、テストの一部を効率化できる可能性はあります。ただし、費用が必ず下がるとは限りません。

• 変換後の品質：COBOLとJavaでは、データ型やエラー処理、ジョブ制御、トランザクション、設計思想が異なります。そのため、レビューや再設計が必要です。
• 追加作業：同値性テストと運用教育も必要です。
• 利用条件：機密データの入力可否、生成物のレビュー責任、テスト証跡を確認します。

代表業務のPoCで効果を検証してから適用範囲を広げ、個別条件を確かめたうえで費用を判断します。

COBOLのシステム開発費用はどのくらいかかりますか？

費用は方式や規模で異なるため、次の推定レンジを予算検討の起点にします。

• アセスメント：300万〜1,000万円程度です。
• 小規模リホスト：1,000万〜5,000万円程度です。
• 中規模リプラットフォーム：5,000万〜2億円程度です。
• リライト・リビルド：3,000万〜数億円程度です。大規模刷新は2億〜10億円超になる場合もあります。

いずれも公開平均ではなく推定のレンジです。ソース本数や業務範囲、データ量によって変動し、並行稼働やテスト、停止制約でも変わります。

対象資産を一覧にしたRFPを用意し、複数社へ個別見積もりを依頼します。

まとめ

COBOLのシステム開発では、言語を残すか捨てるかを先に決めるのではなく、業務の重要度と将来の運用条件から方式を選びます。そのうえで、全体を要件整理から定着までの6フェーズに分けて進めます。

各工程の成果物とGo・No-Go基準を設定すると、技術者の経験や曖昧な記憶だけに頼らず計画できます。まず、現行資産と業務ルールを洗い出します。

最初に行う現行資産と業務ルールの洗い出し

ソースコードやJCL、DBを洗い出します。ジョブや帳票、外部連携、運用手順、障害履歴も対象にします。仕様書がない部分も明らかにします。

• 移行検証：代表業務のPoCと移行リハーサルで、データ同値性、性能、復旧、セキュリティを確かめます。
• 費用内訳：アセスメント、開発、移行、テスト、並行稼働、保守に分けます。
• 比較と反映：根拠のあるレンジで候補を並べ、調査結果を方式選定と見積もりに取り入れます。

小さな検証と切り戻せる計画による段階的な進め方

全面刷新を急がず、業務単位で方式を使い分けます。

• テスト証跡：現行と新システムを比べられるテスト証跡を残します。
• 人による判断：AIは設計書の復元やコード分析に使い、最終的な判断は業務担当者と技術者が下します。
• 運用定着：運用資料や教育、監視、脆弱性対応、後継者育成を続け、運用が組織内で回る状態にします。

▼全体ガイドの記事
・COBOLのシステム開発の完全ガイド

▼開発を相談する前に読みたい無料ホワイトペーパー
・【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を創業。