COBOLのシステム開発の発注は、現行資産と業務範囲を洗い出し、業務単位で発注形態を比べるところから始まります。要件を整理して契約したあとに検証し、段階的に移行すると、既存業務を守りやすくなります。
全体像は、COBOLのシステム開発の完全ガイドもご覧ください。
▼全体ガイドの記事
・COBOLのシステム開発の完全ガイド
AI駆動開発の基本や工程ごとの活用方法、費用・期間への影響については、無料ホワイトペーパー「【2026年最新版】AI駆動開発の完全ガイドブック」で詳しく解説しています。
COBOLのシステムの外注前に決める事項
発注の成否は、委託先の知名度より、発注側が何を変え、何を残すかを判断できるかで決まりやすいです。ソースコードだけを渡しても、業務ルールやバッチの実行順序は再現できないことがあります。例外処理や手作業の補完も、ソースコードだけでは再現できない場合があります。
プログラム以外も含めた発注範囲
発注範囲には、ソース以外の資産や業務も含めます。対象は次の3つの領域です。
- 処理・制御：オンライン処理、夜間バッチ、JCL、ジョブスケジューラ、CICS
- データ・周辺機能：DB2・IMS・VSAM、外部ファイル、帳票、API、監視、バックアップ、復旧手順
- 業務の流れ：給与、請求、決済、保険金、在庫、受発注の締め処理やデータ連携
仕様書が古い場合や、担当者の知識が失われている場合は、設計書の復元と業務ヒアリングも発注範囲に入れます。
AWSの公式ドキュメントでは、COBOLやコピー句、JCLを分析する仕組みに、人が確認する工程が組み込まれています。CICS、BMS、Db2、VSAMも、同じ分析の対象です。RFPで資産単位の分析を求めると、単純なソース変換だけの提案かどうかを見極めやすくなります。
外注の目的と成功条件
外注の目的によって、委託する内容と体制が変わります。主な目的は次の3つです。
- 技術者不足：COBOL保守と運用引き継ぎを中心にする
- 保守期限：メインフレームの期限を踏まえた方式の選定
- 新サービス接続：クラウド・API連携や業務再設計に応じて委託先を選ぶ
業務の再設計まで求めるなら、要件定義の段階から伴走できる会社を選ぶ必要があります。
成功条件は、検証できる形で決めておきます。たとえば、月末締めを予定時間内に終えること、旧システムと新システムで金額と件数が一致すること、障害時の切り戻し時間などです。
自社の担当者が運用手順を理解していることも、条件に含められます。一方で、納期や予算だけを条件にすると、テストや文書が削られ、追加費用につながりやすくなります。
COBOLのシステムの発注形態の選び方
発注形態は、業務の重要度と停止可能時間、仕様の明確さを比べて、業務ごとに選びます。データ連携の複雑さも含めると、形態は既存資産をどこまで残し、どこから作り直すかで分かれます。代表的な方式は5つあり、それぞれ残す資産と作り直す範囲が異なります。
- 保守継続：既存COBOLの維持と、障害や制度改定への対応
- リホスト・リプラットフォーム：業務ロジックや資産を活かした実行基盤への移行
- リライト・再構築：別言語への書き換え、または業務要件からの再設計
- パッケージ・SaaS移行：既製の仕組みへの業務の移し替え
- ラッピング：既存機能を残したままの段階的な連携
全面刷新を前提にせず、複数の方式で見積もりを並べて比べると、現実的な選択につながります。
業務を止めないための保守継続
保守継続では、障害対応や制度改定、帳票変更を外部に任せられ、処理が安定し基盤保守契約が有効で、移行の停止リスクが高い業務に向いています。
- 委託作業：既存COBOLの障害対応、制度改定、帳票変更、周辺連携の改修
- 適する状況：処理が安定し、基盤保守契約が有効で、移行停止リスクが高い
担当者の属人化を放置すると、数年後に同じ問題が再発します。
契約には、ソース一覧と担当領域、障害の優先度を記します。受付時間と一次切り分け、月次改善提案も、契約に含めます。設計書の更新方法も書いておきます。
運用手順と仕様の蓄積も、成果物に含めておくと将来の移行準備になります。
リホストとリプラットフォーム、業務ロジックを活かす方式
リホストとリプラットフォームでは、移行時に活かす資産が異なります。
- リホスト：業務ロジックは大きく変えず、実行基盤だけを移す方式
- リプラットフォーム：COBOL資産やデータ構造を活かした、オープン系やクラウド上の稼働
業務ルールの変更を抑えたい企業では、リライトより検証範囲を絞りやすい場合があります。ただし、基盤を変えると、文字コードや日付、10進数の精度が変わる可能性があります。ソート順やファイルロックも変わることがあります。
バッチ時間や印刷制御も変わり得るため、同じデータで入出力を比べる同値性テストを発注条件に入れます。ピーク時の性能試験も求めて、移行後の処理を確かめます。
リライトと再構築による業務の見直し
刷新方式によって、設計の出発点と見直せる範囲が異なります。
- リライト：COBOLのJavaなどへの書き換え
- 再構築：業務要件からの設計と、API、クラウド、開発者採用、画面の見直し
- 業務整理：不要な機能と重複データの整理
会社を選ぶ基準を自動変換率だけに置くと、危険です。コンパイルが通っても、業務上の例外や締め処理の順序が正しいとは限らないためです。
AWSは2026年6月、資産分析から要求事項、コード生成までを追跡できるワークフローを発表しました。また、公式資料も人の確認を前提としています。
AIを使う提案では、生成物のレビュー担当と承認者を確認します。データの持ち出し範囲とテスト証跡も、あわせて確かめます。
RFPと要件整理の進め方
RFPは、作ってほしいものだけでなく、現状の理解やリスク低減の方法も委託先に伝える文書です。資料が不完全な場合も、そのことを隠さず示し、受注側に調査・分析の提案を求めます。
現行資産と業務範囲の一覧
RFPには、現行資産と業務範囲を次の観点で記載します。
- 業務・処理規模：対象業務、利用部門、画面数、バッチ本数、COBOL規模
- 技術資産：コピー句、JCL、CICS、DB2・IMS・VSAM、ファイル形式
- 運用・連携：帳票、外部システム、データ量、月次・年次ピーク、停止可能時間
正確な数字が取れない場合は、現時点の推定値と、その調査方法を分けて示します。
業務担当者からは、例外処理と手作業の補正を集めます。Excelや固定長ファイルとの連携、障害時だけの復旧操作も、あわせて挙げてもらいます。
ソースにない業務ルールを見つけられるかどうかが、COBOL案件の見積精度を左右します。また、機密データは、匿名化データや項目定義だけを先に渡す方法もあります。
機能要件に加えた非機能要件
機能と非機能の条件を分けて整理し、検証時に確認する要件を明らかにします。
- 機能要件：登録、照合、集計、締め、帳票、連携、権限、履歴、再処理
- 非機能要件：処理時間、同時利用者数、バッチ終了時刻、可用性、バックアップ、災害対策
- 安全・復旧要件：監査ログ、暗号化、アクセス制御、復旧時間と復旧時点
測定方法と合格基準も書きます。たとえば、月末バッチを朝7時までに完了する、障害から4時間以内に再開する、直近24時間のデータを復旧する、といった基準です。
異常終了後の再実行や処理途中のデータの扱い、二重計上の防止も、確認の対象になります。
提案書と見積書の提出条件のそろえ方
複数社が同じ条件で提案できるよう、RFPの配布条件をそろえます。
- 案件条件：対象範囲、前提、データ量、納期、停止可能時間
- 選定条件：成果物、評価基準、質問期限、提案期限
前提がそろわないと、安く見える見積もりが対象範囲を含まない場合があります。
提案書では、方式の選定理由と工程、体制を示してもらいます。経験、現行分析、移行波も、あわせて求めます。
テストや並行稼働、切り戻しの方法も示してもらいます。教育と保守、セキュリティも、提案に含めてもらいます。再委託についても求めます。
見積書では、アセスメントや設計、変換・開発の費用を分けます。データ移行やテスト、リリースの費用も、分けて書いてもらいます。運用引き継ぎ、ライセンス、クラウド費用も、分けて記載してもらいます。
COBOLのシステム開発で契約形態を選ぶポイント
契約形態は、案件全体で一つに固定せず、調査から運用までの工程ごとに、不確実性に応じて使い分けます。仕様が分からない段階で請負契約を急ぐと、追加変更や責任分界をめぐる争いにつながります。
調査や伴走型の工程に向く準委任契約
準委任契約は、受託者が専門知識や作業時間を提供し、発注者と協力して進める形態です。
作業量や論点を読みにくい工程では、次のような調査や検討を委託できます。
- 現状把握：資産棚卸し、設計書の復元、業務ヒアリング
- 移行検討：方式比較、PoCなど開始時点で範囲が定まりにくい作業
完成したシステムの動作保証は、契約だけで期待できるとは限りません。
契約では、月次の成果物や会議体、作業報告を具体的に定めます。課題管理やレビュー、人員の扱いも取り決めます。再委託や機密情報、終了時の引き継ぎも、詰めておきます。
特に、時間単価だけでなく、作業後に何が残るかも評価します。
成果物と受入条件を確定した請負契約
請負契約は、成果物を完成させて検査・受入する工程に向いています。たとえば、詳細設計や変換プログラム、データ移行ツールがこれに当たります。
テスト仕様書や操作マニュアルも含め、完成物と検査方法を定義できる範囲で採用します。契約書では、成果物と受入条件に加えて、責任範囲や権利を明確にします。
- 契約条件：対象資産、除外、前提、納期、検収、不具合、変更、遅延時の扱い
- 権利・保護：知的財産、ソース納品、データ消去、秘密保持、損害賠償
旧システムを移行後も保守する場合は、開発契約と保守契約を分け、それぞれの責任分界を定めます。
知的財産と機密情報の扱い
委託先に渡す資産には、ソースや業務ルール、顧客情報が含まれるため、契約で扱いを決めておきます。
- 保護する資産：COBOLソース、コピー句、データ定義、業務ルール、顧客情報
- 契約で確認：設計書、テストデータ、AI入力・学習利用、退職者・再委託先の権限
IPAの「情報セキュリティ10大脅威 2025」では、組織向けの1位がランサム攻撃です。2位はサプライチェーンや委託先を狙った攻撃、3位はシステムの脆弱性を突いた攻撃です（出典：IPA「情報セキュリティ10大脅威 2025」、2025年）。
委託先の安全性は、会社規模より、契約と運用の両方で確かめます。特権IDや接続元、ログ保存を確認します。脆弱性対応、インシデント報告、再委託管理も含めます。
COBOLのシステム外注費用相場と内訳
費用は、ソースコードの行数に加えて、画面やバッチ、DBといった要素で変わります。外部連携や帳票、業界規制も、費用に影響します。並行稼働やテストデータ準備、24時間運用の有無も、費用を左右します。
ここで示す金額は、一般的な業務システムの相場に、COBOL特有の作業を加えた初期検討用の推定レンジです。公開されたCOBOL案件の平均価格ではありません。
方式別の初期費用の幅
現行資産の棚卸しや影響分析、設計書の復元は、資料がなく複数の基盤や業務領域をまたぐほど上振れしやすいです。この作業を省くと、本開発の見積もりが安く見えても、後から追加要件が増えます。
COBOLの外注費用は方式や規模で変わるため、金額と期間の幅を比較します。
- 資産分析：棚卸し・影響分析・設計書の復元は300万円から1,000万円程度、期間は1か月から4か月程度
- 小規模リホスト：リホストやリホスト準備は1,000万円から5,000万円程度
- 中規模サブシステムのリプラットフォーム：5,000万円から2億円程度
- リライト・再構築：3,000万円から数億円程度
- 大規模メインフレーム全体の刷新：2億円から10億円超、期間は2年から5年程度になる場合があります
いずれも、方式と規模、テストや並行稼働の扱いを仮定した推定です。個別見積もりが必要です。
見積書の初期費用と継続費用の区分
見積書では、初期作業と稼働後の費用を分けて確認します。
- 開発工程：調査、要件定義、基本・詳細設計、変換・開発、移行、テスト、教育
- 移行・運用準備：リリース、切り戻し準備、運用引き継ぎ
- 継続費用：商用COBOLランタイム、メインフレーム利用料、クラウド従量課金、監視、バックアップ、セキュリティ製品、24時間対応
保守費は初期開発費の年10％から20％程度を目安とする考え方があります。たとえば、初期費用が5,000万円なら、15％から20％を仮定して年間750万円から1,000万円程度とする試算もあります。
人員待機やライセンス、クラウド利用料を含むかで、金額は変わります。時間外対応の扱いも、金額に影響します。そのうえで、固定額と従量額を分けて確認します。
費用を抑える範囲と移行波の分け方
費用を抑えるためにテストや調査を最初から削るのは、適切ではありません。対象範囲や検証方法は、次のように調整します。
- 移行範囲：重要度の低い帳票と参照機能の、後続波への分割
- 移行順：停止可能な業務からの着手と、共通部品の再利用の検討
- 小規模PoC：変換率ではなく、処理結果や性能、障害復旧を見る検証
AIによる解析や設計書生成は、棚卸しや依存関係の把握を速める可能性があります。
AWSは2025年5月、AWS Transform for mainframeの一般提供を開始しました（出典：AWS公式発表、2025年）。また、2026年6月には、分析から要求事項、コード生成までを追跡する機能を発表しました（出典：AWS公式発表、2026年）。
AIを使っても、機密情報の入力可否や生成物の品質確認は残ります。業務担当者の承認や同値性テストの費用も、なくなりません。そのため、AI利用だけを理由に総額を下げないようにします。
委託先の選定と見積比較で確認するポイント
委託先は、現行基盤や業界知識、移行方式で比べます。テストと運用引き継ぎ、セキュリティも比べる観点です。体制も、確かめる項目に入ります。
COBOLの経験年数からは、保守やクラウド移行、金融・保険・公共などの業務知識の違いは読み取れません。
基盤と役割分担を含む実績の確認
委託先の実績と体制は、次の観点から確認します。
- 基盤・技術：IBM z/OS、富士通系・日立系、CICS、JCL、DB2・VSAM
- 業務実績：領域、規模、停止可能時間、移行後の保守体制
- 実績の確認：守秘義務に配慮した匿名事例や提案段階の技術検証
最近は、既存資産を洗い出す作業と人材の確保を組み合わせた支援も増えています。
NTT DATAは2025年7月の公式記事で、COBOLソースから設計書を復元し、生成AIとCOBOL有識者で精度を評価する取り組みを紹介しています。また、SCSKとFPTジャパンは2025年12月に「COBOL PARK」の事業開始を発表し、継続運用とモダナイゼーションを支援する体制を示しました（出典：SCSK公式発表、2025年）。
AI活用や人材供給に加えて、最終レビューと国内の責任体制も確かめます。提案責任者が、設計や移行、テストにも参加するかを確認します。契約後に別会社や経験の浅い担当者へ移ると、認識がずれやすいためです。
COBOL有識者、業務アナリスト、データ移行担当の役割は、氏名またはスキル条件で明記してもらいます。テスト責任者、インフラ担当、運用引き継ぎ担当も、同じ方法で示してもらいます。
見積比較の前提条件のそろえ方
見積もりは総額だけでなく、範囲と各社の前提条件をそろえて比べます。
- 対象範囲：データクレンジング、移行リハーサル、現行と新システムの並行稼働、利用者教育、帳票の印刷確認、障害時の切り戻し、ドキュメント作成、ソースコード納品
- 見積条件：作業項目、工数、単価、前提、除外、リスク、追加費用の条件
最安値の見積もりには、仕様調査の発注者負担や、提供済みテストデータ、並行稼働の別料金がないかを確かめます。見積もりの差が大きい場合は、前提をそろえた再見積もりを依頼します。
技術対話と小規模検証を組み込んだ選定プロセス
候補を二社から四社程度に絞り、技術対話と小規模検証で比較します。
- 技術対話：ソースや匿名化データを使った、不明点・リスク・代替案・調査計画の確認
- 説明力：できない条件と検証方法を述べられるかを見る
- 有償検証：資産一覧や依存関係、方式、課題、概算、移行波、テスト方針が得られる作業
- 成果物の扱い：契約前に確認する、再利用や別会社への切り替え時の持ち出し
よくある質問
発注や外注の進め方は、現行資産の規模や業務停止の条件によって変わります。データ機密性や社内の判断体制も、進め方を左右します。
COBOLのシステム外注費用はいくらですか？
小規模な資産分析は300万円から1,000万円程度、リホストは1,000万円から5,000万円程度が初期検討の推定レンジです。また、中規模のリプラットフォームは5,000万円から2億円程度、リライトや再構築は3,000万円から数億円です。
大規模刷新は2億円から10億円超になる場合があります。公開された平均価格ではないため、対象資産とテスト範囲をそろえて個別見積もりを取ります。
仕様書がなくてもCOBOLのシステムを外注できますか？
外注できますが、最初から本開発を頼まず、資産を洗い出す作業と設計書の復元を、アセスメント工程として発注する方法が安全です。
設計書の復元には、COBOLソースやコピー句、JCLを組み合わせます。ジョブネットやデータ定義、帳票も材料として使います。運用手順や障害履歴、業務ヒアリングも、あわせて集めます。
分からない部分は、解決済みとして扱わず課題に残します。
AIでCOBOLを変換すれば発注期間と費用を短縮できますか？
AI解析や設計書生成、依存関係の抽出で、調査の一部を効率化できる可能性があります。変換支援も、開発の一部の効率化に関わる可能性があります。
生成コードの業務妥当性や金額計算、日付処理の同値性は、人が確認します。セキュリティと機密情報、テスト証跡も、人が確かめます。
短縮効果は、資産構造とレビュー体制に左右されます。そのため、PoCで実測してから本見積もりに反映します。
COBOLのシステム開発会社は何社に見積もりを依頼すべきですか？
候補を二社から四社程度に絞り、同じRFPと資料で比較する方法が現実的です。
候補が多すぎると、質問への対応や評価が浅くなります。基盤や業界知識、移行方式が異なる会社を含めます。運用体制が異なる会社も、候補に加えます。
提案の前提条件や費目別の金額、体制を、同じ評価表で確認します。リスクや成果物も、同じ表で比べます。
まとめ
COBOLを残すか捨てるかを先に決めず、業務単位で方式を比べます。比べる方式は、保守とリホスト、リプラットフォームです。リライトやパッケージ移行も、候補に入ります。
RFPを作成する前に、資産を洗い出し、業務ルールと停止条件を整理します。非機能要件やテスト基準も、そろえておきます。
発注前に確認する項目
発注前には、対象資産や目的、方式を確認します。RFPや契約、費用の内容も確かめます。体制と非機能要件も、確認の対象です。
同値性テストと並行稼働、切り戻しも対象になります。機密情報と成果物の所有権も含めます。
決められない項目は、無理に確定させず、アセスメントの調査範囲と、調査後に再見積もりする条件を記載します。
最初のアセスメント発注
数年規模の刷新は最初から約束せず、資産調査から段階移行の判断へ、順に進めます。
- 方式・費用の具体化：資産の全体を洗い出し、小さな技術検証で確かめる
- 段階移行：経営、業務、IT、委託先で事実を共有し、業務を止めずに次の移行波を決める
- 契約形態：調査・要件定義は準委任、成果物と受入条件が明確なら請負
- 委託先比較：見積もりの前提と除外をそろえたうえでの、基盤、業務知識、テスト、体制、移行後保守の確認
- アセスメント：資産一覧や依存関係、方式比較、概算費用、移行波、テスト計画をまとめ、社内で共有して発注計画に反映する
契約には、データ移行と並行稼働、切り戻しの扱いを明記します。ソースや運用引き継ぎ、機密情報も書き込みます。再委託の扱いについても、取り決めます。
▼全体ガイドの記事
・COBOLのシステム開発の完全ガイド
▼開発を相談する前に読みたい無料ホワイトペーパー
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。