COBOLのシステム開発の見積相場や費用/コスト/値段について

COBOLのシステム開発・刷新費用は、現行資産の調査だけなら300万〜1,000万円、小規模移行なら1,000万〜5,000万円、中規模以上の再構築なら5,000万円〜数億円が目安です。

ただし、COBOLのシステムはプログラムだけで構成されているわけではありません。メインフレーム、JCL、CICS、DB2、VSAM、IMS、帳票、ジョブネット、外部連携、運用手順までが業務を支えているため、同じ「COBOL移行」でも費用は大きく変わります。本記事では、2026年時点の費用レンジを方式別・工程別に整理し、見積もりが上振れする要因、費用を抑える進め方、ベンダーへの依頼方法まで解説します。

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

COBOLのシステムとは？費用を考える前に全体像を確認します

費用を正しく比較するには、COBOLという言語だけでなく、言語が組み込まれた業務システム全体を見なければなりません。ここを曖昧にしたまま「Javaに書き換える費用」だけを尋ねると、後からデータ移行、帳票再現、性能検証、切り戻しの費用が追加されやすくなります。

COBOLのシステムには、画面やバッチのプログラムに加えて、ジョブを実行するJCL、オンライン処理を制御するCICS、データを保持するDB2・VSAM・IMS、帳票定義、外部ファイル、他システムとの連携が含まれることがあります。さらに、締め処理の時刻、障害時の再実行、手作業による補正、監査用のログなど、ソースコードに書かれていない運用ルールも重要です。

たとえば給与計算を新しい言語へ移す場合、画面を再現するだけでは完了しません。給与項目の丸め、支給日が休日の場合の扱い、過去データの照会、銀行ファイルの形式、計算結果の照合、年末調整との連携まで確認する必要があります。この業務知識と周辺資産の棚卸しが、COBOL案件の費用と期間を左右します。

COBOLが長く使われている理由は、大量データを安定して処理できること、既存の業務ルールとデータが蓄積されていること、障害対応の運用ノウハウがあることです。したがって「古い言語だから直ちに廃止する」と決めるのではなく、保守継続、リホスト、リプラットフォーム、リファクタリング、Javaなどへのリライト、SaaSやERPへの移行を業務単位で比較します。

一部の業務だけをAPIで公開し、既存のCOBOLを残したまま新しい画面やサービスを追加する方法もあります。反対に、制度変更が多く、技術者の確保が難しく、機器やミドルウェアの保守期限が迫っている領域は、早めに移行計画を作る価値があります。費用の大小だけでなく、停止リスク、業務継続性、5年から10年後の保守体制を含めて判断することが大切です。

COBOLシステム開発・刷新の進め方を工程別に解説します

COBOL案件では、いきなり開発会社へ丸投げするより、調査、方式比較、試験移行、本開発、並行稼働の順に進める方が追加費用を管理しやすくなります。特に仕様書が古い、担当者が退職している、ソースと本番設定の差分が分からない場合は、最初の調査を独立した工程として見積もることが重要です。

最初に集める資料は、COBOLソース、コピー句、JCL、ジョブネット、DB定義、ファイルレイアウト、画面・帳票一覧、外部連携仕様、運用手順、障害履歴です。ソースの本数だけでなく、オンライン画面数、バッチ数、データ量、実行頻度、連携先、相互依存関係を可視化します。使われていないプログラムを新システムに持ち込まないだけでも、後工程のテスト範囲を絞れる可能性があります。

この工程の費用は、記事作成用の目安として300万〜1,000万円、期間は1〜4か月程度です。これは公開された市場平均ではなく、COBOL特有の資産分析、仕様書の復元、影響範囲の確認を含めた推定レンジです。NTT DATAは2025年の公開記事で、COBOLソースから生成AIを活用して設計書を復元し、COBOL有識者が精度を評価する取り組みを紹介しています。AIを使っても、最終的な業務確認と承認は人が担う前提で計画します。

現行COBOLを保守しながら周辺だけ改善する方法は、最も短期に業務を変えやすい一方、古い基盤への依存が残ります。実行基盤を変えるリホストや、COBOLをオープン系・クラウドで動かすリプラットフォームは、業務ロジックを活かしやすい反面、文字コード、ファイル、性能、運用監視の差異を検証する必要があります。

Javaなどへのリライトや、業務要件を整理して新しく作るリビルドは、保守性や外部連携の改善を期待できますが、単純な自動変換では終わりません。SaaSやERPへ寄せる場合は、標準機能に業務を合わせることで初期費用を抑えられる可能性がありますが、独自ルールを追加開発すると費用が膨らむことがあります。現行維持、段階移行、全面再構築を同じ評価表で比較してください。

COBOLの刷新では、画面が表示されるかだけでなく、旧システムと新システムの業務結果が一致するかを確認します。金額の丸め、日付の境界、負数、ゼロ、桁あふれ、文字コード、ソート順、バッチの締め時刻などをテストデータで比較します。金融・保険・給与・決済のように誤差が許されない業務では、結果の差分を記録し、差異の理由を業務担当者が承認できる状態にします。

本番切り替えでは、一定期間の並行稼働、差分照合、バックアップ、障害時の旧系復帰、休日リリース、利用者教育を計画します。AWSの公開事例では、COBOLで構築されたMeliáの予約システムをモダナイズし、コンピュート費用60％削減、可用性99.99％、応答時間234ミリ秒から160ミリ秒への改善が示されています（出典: AWS「Meliá Hotels Saves 60% in Costs」、2025年閲覧）。このような効果は移行先の設計や業務特性によるため、日本の初期費用に直接当てはめず、効果検証の指標として利用します。

COBOLのシステム費用相場とコストの内訳を整理します

以下の金額は、NotebookLMのリサーチノートにある業務システムの一般相場と、COBOL案件で追加になりやすい資産分析・変換・データ移行・同値性テスト・並行稼働を踏まえた、記事作成用の推定レンジです。公開見積もりの平均値ではなく、正式な金額はアセスメントとRFPへの回答で決まります。見積書では、開発費だけでなく、移行前後の運用費、ライセンス、クラウド利用料も分けて確認してください。

現行資産の棚卸し・影響分析・設計書復元は、300万〜1,000万円、1〜4か月が目安です。対象資産が少なく、資料が揃っていれば下限に近づきますが、ソース、JCL、ジョブ、帳票、外部連携の関係が不明なほど上振れしやすくなります。小規模なCOBOL業務のリホストやリホスト準備は、1,000万〜5,000万円、4〜10か月程度です。

中規模の基幹サブシステムをリプラットフォームする場合は、5,000万〜2億円、8〜18か月程度が目安です。データ変換、API連携、帳票、性能試験、並行稼働を含めるほど上限に近づきます。COBOLからJavaなどへのリライト・リビルドは、3,000万〜数億円、12〜30か月程度です。大規模メインフレーム全体の刷新は、複数業務、災害対策、教育、段階リリースを含めて2億〜10億円超、2〜5年となる可能性があります。

ここで示した期間は、受発注や給与など一つの業務から大規模基幹全体までを含む幅広い目安です。ソースコードの行数だけで期間を決めると、JCLやデータ定義、外部連携、運用手順の影響を見落とします。まずは対象業務、停止可能時間、データ量、移行波を決め、その条件でベンダーに再計算してもらうことが必要です。

費用の内訳は、企画・アセスメント、要件定義、基本設計・詳細設計、変換または開発、データ移行、単体・結合・総合・受入テスト、性能・障害復旧テスト、並行稼働、リリース、教育、運用引き継ぎに分けてください。設計書が不足している場合は、ソース解析と業務ヒアリングの費用を別建てにすると、調査後に開発範囲が変わった理由を説明しやすくなります。

データ移行費には、抽出、クレンジング、コード変換、項目マッピング、移行ツール、リハーサル、本番移行、照合が含まれることがあります。帳票も、出力形式、プリンター、文字幅、バーコード、保存年限まで確認が必要です。これらを「開発一式」にまとめると比較しにくくなるため、成果物と作業範囲を明示してもらいます。

初期費用が安く見えても、移行後のランニングコストが高ければ、総保有コストは下がりません。一般的な業務システムでは、初期費用の年10〜20％程度を保守費の目安とする考え方があります。たとえば初期費用5,000万円の案件なら、保守だけで年間500万〜1,000万円が一つの計算上の範囲となり、リサーチノートでは15〜20％として750万〜1,000万円を試算しています。ただし、これは契約条件によって変わる目安であり、確定料金ではありません。

このほか、メインフレームの利用料、商用COBOLランタイム、データベース、監視、バックアップ、24時間運用、クラウドの従量課金、ネットワーク、セキュリティ対策が発生します。クラウドへ移すと固定的な機器費が下がる場合がありますが、常時稼働、データ転送、バックアップ、ログ保管の使い方によって料金が変わります。見積書では初年度だけでなく、3年から5年の累計で比べることが大切です。

COBOLシステムの見積金額が変動する要因を確認します

同じCOBOLでも、費用が数千万円で収まる案件と数億円になる案件があります。差を生むのは、言語の種類だけではなく、業務の重要度、資産の複雑さ、移行先、停止制約、テストの深さ、データの扱い、発注体制です。次の項目を自社の見積もり依頼書にあらかじめ入れておくと、各社の提案を比較しやすくなります。

プログラム本数やソース行数は出発点に過ぎません。オンラインとバッチの依存関係、ジョブの分岐、コピー句の共有、DBアクセス、外部ファイル、帳票、手作業の補正が複雑になるほど、影響分析とテストが増えます。ソースは少なくても、ひとつの処理が複数業務の締めや決済に関係していれば、慎重な切り替えが必要です。

逆に、利用停止した機能や重複した帳票を事前に整理できれば、移行対象を絞れる可能性があります。現行資産をそのまま一括変換するのではなく、利用頻度、売上・入出金への影響、廃止可能性、法定保存の要否で分類し、段階的に対象を決めることが費用管理につながります。

DB2やVSAMなどのデータをリレーショナルデータベースへ移す場合、項目の型、符号、日付、文字コード、パック十進数、重複キー、履歴の保持方法を確認します。移行先で同じデータを保持するだけでなく、新旧データを照合し、業務画面や帳票で正しく表示できることまで検証します。過去数年分の履歴を移すのか、参照用に別保管するのかでも作業量が変わります。

本番データを扱う場合は、匿名化、アクセス権限、作業ログ、委託先との受け渡し方法も見積条件です。IPAの「情報セキュリティ10大脅威 2025」では、組織向けの脅威としてランサム攻撃、委託先を狙う攻撃、脆弱性の悪用、内部不正などが挙げられています（出典: IPA、2025年）。古い基盤を移すだけでなく、特権ID、バックアップ、監査ログ、復旧訓練まで含めると費用は増えますが、削りにくい領域です。

夜間に数時間停止できる業務と、決済や出荷のように連続稼働が必要な業務では、切り替え方式が異なります。停止できない場合は、並行稼働、二重更新、差分反映、切り戻し環境、リハーサルの回数が増えます。結果として開発そのものより、移行と検証に費用がかかることもあります。

要件定義の段階で、許容停止時間、目標復旧時間、目標復旧時点、切り戻し判断者、障害時の連絡網を決めてください。性能についても、通常時だけでなく月末、年度末、給与支給前、セール日などピーク時の処理量を伝えます。これらの条件がない見積もりは安く見えても、後から高い非機能要件として追加される可能性があります。

生成AIや変換ツールは、ソースの分類、依存関係の分析、設計書のたたき台作成、定型的なコード変換に活用できる可能性があります。AWSは2025年にメインフレーム向けの変革サービスを一般提供し、COBOLを含むワークロードの分析・移行・テスト・運用を支援する機能を案内しています。ツールを使うことで作業時間を短縮できる場合がありますが、AIが出力したコードをそのまま本番へ投入できるという意味ではありません。

特に、仕様書にない業務ルール、例外処理、担当者の経験則は、機械的な変換だけでは判断できません。入力データの匿名化、外部サービスへの情報送信可否、生成物の機密性、レビュー担当者、テスト証跡、承認方法をRFPに書きます。AI活用費を安く見せるより、どの作業を自動化し、どの作業をCOBOL有識者と業務担当者が確認するかを明確にする方が、後戻りの防止につながります。

COBOLシステムの費用を最適化するポイントを紹介します

コスト最適化は、単価を下げることだけではありません。不要な機能を移さない、テストのやり直しを減らす、将来の保守費を抑える、業務停止による損失を防ぐことも含みます。安さだけを優先すると、切り替え後の障害や追加開発で総額が増えるため、初期費用と運用費を一体で評価します。

すべてのCOBOL資産を同じ優先度で移す必要はありません。売上、請求、入出金、給与、在庫、受発注などの中核業務と、参照頻度が低い帳票や廃止候補のバッチを分けます。プログラムの実行ログ、ジョブの利用実績、利用部門へのヒアリングを組み合わせれば、使われていない機能を新環境へ持ち込むリスクを下げられます。

先に小さなサブシステムで移行の型を作ると、データ変換、テスト、リリース、運用引き継ぎの課題を早期に発見できます。最初の波で得た変換ルールやテスト自動化を次の波へ再利用できれば、全体の作業を効率化できます。業務影響の大きい機能を最後まで先送りするのではなく、技術検証に適した範囲と、経営上優先すべき範囲を分けて計画します。

担当者の記憶だけに頼らず、業務フロー、入力条件、出力結果、例外処理、締め処理、障害時の復旧方法を文書化します。仕様書の復元にかかった知見を、次の要件定義や受入テストで再利用できる形にしてください。現行と新システムを比較するテストデータ、期待結果、差異の判定ルールを先に作ると、テスト担当者の判断が揃いやすくなります。

テストを最後にまとめて実施すると、問題の原因がコード、データ、連携、運用のどこにあるか分からなくなります。資産分析の段階から単体・結合・総合・受入テストの対象を紐付け、変換後の自動テストを蓄積します。テストを削るのではなく、リスクに応じて自動化と重点確認を使い分けることが、品質と費用のバランスを取りやすくする方法です。

見積もりの前提条件として、対象プログラム、データ件数、連携先、環境数、対応時間、仕様書の有無、顧客側の作業、テストデータの準備者を明記します。要件変更、想定外のソース、移行データの品質問題、追加の並行稼働、ライセンス増加が起きたときの扱いも確認します。準委任か請負か、検収基準、瑕疵対応、障害時の責任分界も費用と密接に関係します。

納品物は新しいプログラムだけではありません。設計書、データ移行定義、テスト結果、性能測定、運用手順、監視設定、バックアップ・復旧手順、ソースコード、変換ツールの利用条件、教育資料、切り戻し計画まで一覧にします。費用を下げるために成果物を削ると、次の保守会社へ引き継げず、将来の追加費用が増える可能性があります。

会社選びでは、単に「COBOLに対応できる」という説明だけでなく、自社の基盤、業界知識、移行方式、同値性テスト、運用引き継ぎを確認します。富士通系、日立系、IBM系など、既存環境への理解が必要な場合もあります。金融、保険、公共、流通などの業務知識、国内での責任者、オフショア利用時の機密情報管理、COBOL有識者のレビュー体制も比較項目です。

SCSKとFPTジャパンは2025年にレガシーシステムの継続運用・モダン化を支援するCOBOL PARKの事業開始を公表しています（出典: SCSK「COBOL PARKを設立、事業を開始」、2025年）。このような専門体制の有無は参考になりますが、会社名だけで価格や品質が決まるわけではありません。提案時に、対象資産を分解した見積もり、過去の移行方式、テスト証跡、移行後の保守体制を提示できるかを確かめてください。

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

見積もりの精度は、発注側が渡す情報の粒度に左右されます。完璧な仕様書がなくても、分かる範囲で対象業務、現行構成、困っていること、希望時期、停止制約、予算の考え方を共有してください。不明点を不明のまま明記した方が、根拠なく一式計上されるより、調査工程と開発工程を分けて比較できます。

RFPには、現行のハードウェア・OS・ミドルウェア、COBOL方言、プログラム・JCL・ジョブの数、DB・ファイル形式、画面・帳票、連携先、データ量、利用時間、ピーク処理、保守期限を記載します。移行方式はリホスト、リプラットフォーム、リライト、リビルド、段階的なラッピングを比較対象にし、第一候補だけを決め打ちしない方が、現実的な提案を受けやすくなります。

非機能要件には、可用性、性能、復旧時間、バックアップ、監査ログ、アクセス制御、データ所在、暗号化、障害時の連絡、保守時間を含めます。政府・公共系や特定のクラウド利用では、ISMAPの対象や調達条件の確認が必要になる場合もあります。安い構成が要件を満たしているか、金額と要件を一対一で照合してください。

3社程度へ同じ資料を渡し、アセスメント、開発、移行、テスト、保守の費用を同じ項目で提示してもらうと比較しやすくなります。極端に安い提案は、データ移行、並行稼働、ドキュメント、性能試験、切り戻し、ライセンス、クラウド利用料が含まれているかを確認します。反対に高い提案も、対象範囲や品質基準が明確なら単純に割高とは限りません。

価格、納期、技術適合性、業務知識、体制、保守継続性、契約の透明性に評価点を付けます。COBOLを残す方式と変換する方式を一方的に勧める会社より、複数の選択肢とそれぞれのリスクを説明し、PoCや小規模移行で判断材料を作る会社の方が、長期的な費用を管理しやすい傾向があります。

追加費用が発生する条件は、契約前に質問します。たとえば、資料にないプログラムが見つかった場合、想定よりデータが汚れていた場合、性能が基準に届かない場合、並行稼働を延長する場合、移行波を増やす場合の扱いです。発注後に初めて議論すると、納期と予算の両方が動かしにくくなるため、単価、変更管理、承認者を決めておきます。

切り戻し計画も見積もりに含めます。誰がどの条件で旧系へ戻すのか、差分データをどう扱うのか、利用者へどう告知するのか、復旧後にどのログを保存するのかを決めます。切り戻しを想定していない計画は、一見安くても障害発生時の損失が大きくなります。業務継続を守るための費用として、リハーサルと復旧手順を削らないことが重要です。

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

COBOLのシステム費用は、方式、資産量、業務リスク、移行データ、停止制約によって変わります。ここでは、見積もり前に特に質問されやすい内容を、金額を断定しない形で回答します。

現行資産の調査だけなら300万〜1,000万円、小規模なリホストなら1,000万〜5,000万円、中規模のリプラットフォームなら5,000万〜2億円、リライトや大規模刷新なら数億円以上が目安です。これは公開平均ではなく、資産分析、データ移行、同値性テスト、並行稼働を含む記事作成用の推定レンジです。対象範囲と方式を決めたうえで、個別見積もりを取得してください。

自動変換やAI支援で一部の作業時間を短縮できる可能性はありますが、必ず安くなるとは限りません。仕様復元、業務レビュー、データ変換、同値性テスト、性能試験、運用設計が必要なためです。変換率だけでなく、移行後の保守費、障害対応、開発者の確保、ライセンス費まで含めた3〜5年の総額で判断してください。

取得できますが、最初から本開発の確定見積もりを求めるのではなく、現行資産の棚卸し・影響分析を先行させることが現実的です。COBOLソース、JCL、コピー句、DB定義、ジョブネット、帳票、外部連携、障害履歴があれば、調査の出発点になります。NTT DATAの公開事例のように、生成AIで設計書のたたき台を作る方法もありますが、業務担当者とCOBOL有識者による確認は必要です。

短期の初期費用だけなら、現行COBOLを保守し、必要な範囲だけ改修する方が安い場合があります。一方、保守人材が不足している、基盤の保守期限が迫っている、連携や制度対応を追加し続けている場合は、将来の保守費や障害リスクが高くなる可能性があります。現行維持、リホスト、リライト、パッケージ移行を、初期費用だけでなく5年程度の運用費と業務影響で比較してください。

まとめ：COBOLのシステム費用は内訳と変動要因を分けて判断します

最後に、費用相場を判断するときの要点と、見積もり前に取り組むべき内容をまとめます。COBOLの刷新は一度に結論を出すのではなく、現状を見える化してから段階的に判断することで、予算と業務継続性の両方を管理しやすくなります。

COBOLのシステム費用は、調査・設計・変換・データ移行・テスト・並行稼働・保守をどこまで含めるかで変わります。目安として、現行資産の棚卸しは300万〜1,000万円、小規模リホストは1,000万〜5,000万円、中規模リプラットフォームは5,000万〜2億円、リライトや大規模刷新は3,000万〜数億円、または2億〜10億円超のレンジになり得ます。ただし、いずれも対象範囲と前提条件を置いた推定であり、特定金額を保証するものではありません。

まずはCOBOLソース、JCL、DB、帳票、ジョブ、連携、運用手順を棚卸しし、利用頻度と業務影響で移行対象を分けます。そのうえで、現行維持、リホスト、リプラットフォーム、リライト、パッケージ移行を比較し、小さな業務で同値性テストと移行リハーサルを実施します。価格だけでなく、停止リスク、保守費、成果物、切り戻し、移行後の体制まで確認することが、COBOLのシステム刷新を成功させる近道です。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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