COBOLのリバースエンジニアリングは、対象と目的を決め、解析環境を整えたうえで、静的解析と動的解析、抽象化を経て成果物にまとめる6つの工程で進みます。
COBOL移行を発注する担当者の方に向けて、押さえておきたい論点を4つのテーマに分けて説明します。
- 対象選定とツール準備
- 静的解析・動的解析・抽象化
- 法的リスクとクリーンルーム
- 成果物化と外注・内製の判断
AI駆動開発の基本や工程ごとの活用方法、費用・期間への影響については、無料ホワイトペーパー「【2026年最新版】AI駆動開発の完全ガイドブック」で詳しく解説しています。
COBOLのリバースエンジニアリングの概要
COBOLのリバースエンジニアリングは、ソースコードや実行バイナリから業務仕様・設計情報を逆方向に復元するプロセスです。通常の開発は「要件→設計→実装」の順で進みますが、リバースエンジニアリングでは、その逆に「実装→設計→仕様」の順で情報を抽象化していきます。
リバースエンジニアリングは、設計書が失われた既存システムを理解し、刷新するために欠かせない手法です。レガシーシステムのモダナイゼーションでは、最初のステップに位置づけられます。
他言語との違い・COBOLの特性
COBOLは、JavaやPythonといったモダン言語に比べて、リバースエンジニアリングの難易度が格段に高い言語です。その最大の理由は、IBM汎用機（メインフレーム）上で稼働するシステム特有のホスト仕様が複雑に絡み合っていることです。
JCL（Job Control Language）によるバッチジョブ定義、DB2やIMSなどの固有データベース、VSAMという独自のファイル管理が組み合わさって動いており、汎用ツールでは解析しきれない領域です。さらに、COBOLでは1行のコードが持つ意味の重みがモダン言語と全く異なります。
COBOL 1万行とReact 1万行を比べると、COBOLの1行は業務ロジックを凝縮していることが多いため、単純な行数（LOC：Lines of Code）ベースで解析工数を見積もると、大幅な乖離が生じます。C#やJavaのような中間言語は、逆コンパイルでほぼソースに近い形まで復元できます。一方、COBOLは逆コンパイルができても、業務ロジックの「意味」を読み取るには相当な専門知識が必要です。
主な用途（レガシー移行・仕様書復元・脆弱性診断）
COBOLのリバースエンジニアリングが活用される場面は、大きく3つあります。第一は、DX推進に伴うJavaやPythonへのモダナイゼーションです。設計書がない状態では要件定義を始められないため、まずリバースエンジニアリングで業務仕様を復元し、移行先の新システム設計へつなげる流れが一般的です。
第二は、保守・継承を目的とした仕様書の復元です。ベテランSEの退職前に業務ロジックを文書化し、若手エンジニアでも保守できる体制を整えるために実施されます。
第三は、セキュリティ脆弱性診断です。長年改修を繰り返してきたCOBOLプログラムには、古い認証ロジックや暗号化されていないデータ処理が残っていることがあり、リバースエンジニアリングによって潜在的なリスクを発見します。
COBOLのリバースエンジニアリング6工程
COBOLのリバースエンジニアリングは、目的の曖昧さや解析の漏れがそのままプロジェクトの失敗につながる、繊細なプロセスです。
解析チームが6つの工程を順に進めれば、手戻りを抑えながら業務仕様を復元できます。
工程1. 対象選定・目的明確化
最初に、解析対象のCOBOLプログラムの範囲と、リバースエンジニアリングを行う目的を決めておきます。範囲が曖昧なまま「全システムを解析する」と始めると、工数と費用が際限なく膨らみます。
そのうえで、対象のモジュール一覧、ソースファイル数、総行数（LOC）を洗い出し、優先順位の高い業務領域（例：受発注管理、在庫計算、給与計算）から着手する範囲を絞り込みます。主目的を「モダナイゼーション向け仕様書復元」「継承・保守向けドキュメント整備」「脆弱性診断」のどれにするかで、後工程の解析深度や成果物の粒度が大きく変わります。
解析チームは、著作権法第30条の4に基づく「非享受目的」の記録を適切に残すため、この段階で、調査解析専用の環境を用意し、解析過程をレポートとして記録する体制を整えておく必要があります。
工程2. 解析環境・ツール準備（COBOL特化ツール）
COBOL解析に特化したツール環境を整える段階です。汎用のバイナリ解析ツール（Ghidra、IDA Pro）はセキュリティ領域では有効ですが、COBOLのモダナイゼーション案件では、業務ロジック解析に特化したツールが必要です。
代表的なものとして、MicroFocus（OpenText）の解析ツール群やIBMのApplication Discovery and Delivery Intelligence（ADDI）があります。これらはJCL・VSAM・DB2との依存関係を自動的にマッピングする機能を備えています。ツール選定と並行して、ソースコード管理環境（バージョン管理）とクリーンルーム体制も整えておく必要があります。
クリーンルーム手法とは、解析チームと新規開発チームを完全に分離し、解析チームが作成した仕様書だけを通じて情報を伝える手法です。この手法は、著作権侵害（依拠性）を避けるための重要な法務リスク管理手段で、1980年代のフェニックス・テクノロジーズによるIBM BIOS互換実装が歴史的な成功事例として知られています。
工程3. 静的解析（逆コンパイル・コード構造解析）
静的解析は、プログラムを実行せずにソースコードや中間コードを読み解く工程です。COBOLでは、ソースコードが入手できていれば、まずDIVISION構造（IDENTIFICATION・ENVIRONMENT・DATA・PROCEDURE）を整理します。そのうえで、データ定義（WORKING-STORAGE SECTIONの変数構造）とPROCEDURE DIVISION内の処理フローを把握します。
ソースが残っていない場合はバイナリから逆コンパイルを試みますが、変数名が失われていたり、機械語レベルまで最適化されていたりするため、復元精度には限界があります。静的解析で特に重要なのが、JCLとのインターフェース解析です。
具体的には、どのJCLステップからどのプログラムが呼ばれ、どのVSAMファイルやDB2テーブルにアクセスしているかという依存関係マップを作ることが、後工程での仕様復元の精度を左右します。さらに、このフェーズで制御フローグラフ（CFG）を作っておくと、次の動的解析との対照が容易になります。
工程4. 動的解析（実行トレース・業務シナリオ検証）
動的解析は、実際にプログラムを動作させながら処理の流れを追跡する工程です。テスト環境でデバッガをアタッチし、各業務シナリオ（月末バッチ、受注処理、在庫更新など）を実行しながら、データがどのように変換・移送されているかをリアルタイムで観察します。
静的解析では把握しきれなかった、特定の業務条件でのみ発動する条件分岐を発見できる点が、動的解析の大きなメリットです。COBOLの動的解析で特に注意すべきは、本番環境でしか発動しない業務条件の扱いです。たとえば、月次・年次の締め処理や、特定の取引コード・顧客コードに紐づく例外処理は、テスト環境での再現が困難なケースが多くあります。
こうした場合は、業務部門の担当者に実際の業務フローを聞き取りながら、テストデータを作成して解析を進める必要があります。「コードは読めるが業務の意図が分からない」という、リバースエンジニアリング最大の落とし穴を避けるには、業務部門との連携を工程3の静的解析の段階から始めておくことが望まれます。
工程5. 抽象化（実装レベル→設計レベル→仕様レベルへの引き上げ）
工程3・4で集めた情報を段階的に抽象化し、業務仕様書として組み直す工程です。Design Recovery（設計回復）とも呼ばれ、まず実装レベルの制御フローをプログラムフローチャートに変換します。次に、複数の処理をまとめた業務機能単位（例：「受注登録機能」「在庫引当機能」）ごとに、設計レベルのドキュメントを作成します。
最終的には、新システムの要件として使える仕様レベルの業務仕様書（画面遷移図・データフロー図・業務ルール一覧）にまとめ上げます。COBOLのコードには、30年以上前に意思決定された業務ルールが埋め込まれていることがあります。そのため、業務部門の協力がなければ、「何をしているか（How）」は分かっても、「なぜそうなっているか（Why）」は正確に把握できません。
この工程で最も重要かつ難しいのは、「Why（なぜその仕様になっているか）」の復元です。ベテランの業務担当者へのインタビュー、過去の仕様変更履歴の調査、現行業務フローの確認を並行して進め、コードの背後にある業務上の意思決定を文書化していきます。
工程6. 成果物化（仕様書・新システム設計への接続）
解析と抽象化の結果を正式な成果物にまとめ、次のフェーズ（モダナイゼーション実装）へ引き渡す工程です。成果物の粒度は、発注時に合意しておく必要があります。段階は大きく3つあり、「フローチャートのみ」「業務機能仕様書（業務ルール・画面遷移含む）」「新システム設計に直結する詳細設計書（DB設計・API仕様含む）」があります。
粒度によって費用と期間が大きく変わるため、発注者側が何に使うのかを明確にしたうえで合意することが大切です。そのうえで、成果物には必ず「変数名の意味説明」「業務ロジックのWhy（判断根拠）」「例外処理の業務的な意味」を含めることを要件として明示してください。
これらが欠けた成果物は、表面上は仕様書として存在しても、モダナイゼーションに使おうとすると業務ルールの解釈に迷い、移行後のバグの温床になります。そこで、機械変換後のコードを若手エンジニアでも保守できる品質かどうかを、最終確認の基準に据えると、成果物の質が大きく上がります。
COBOL固有の注意点と失敗パターン
COBOLのリバースエンジニアリングには、他の言語では見られない落とし穴があります。事前に把握しておけば、プロジェクトの失敗リスクを大幅に低減できます。
典型的な失敗パターン
最も多い失敗パターンは、「LOC（行数）課金で見積もりを取ったら、想定の3倍の費用になった」という事例です。前述のとおり、COBOLの1行はReactやPythonの1行とは意味の重みが全く異なります。COBOL 1万行のプログラムには複雑な業務ルールが密集していることが多いため、解析工数は行数に比例しません。
発注者側がLOC単価のみで比較してベンダーを選定すると、後から追加費用が発生しがちです。そのため、見積もりを取る際は「LOC課金の適正単価がCOBOL向けに設定されているか」「COBOL特有の複雑さを見積もりに反映しているか」を必ず確認してください。
次に多いのは、「コードは解析できたが、業務ルールの意味が分からず移行後にバグが多発した」というケースです。COBOLには、「なぜ特定の顧客コードだけ処理を分けているのか」といった、コードからは判断できない経緯が多数潜んでいます。これを防ぐには、最初から業務部門を巻き込み、解析チームが「How」を、業務担当者が「Why」を補う協働体制が欠かせません。
ホスト固有仕様（JCL・DB2・VSAM）のブラックボックス問題
汎用ツールが限界を迎えるのは、ホスト固有仕様（JCL・DB2・VSAM）との連携部分です。JCLは汎用機固有のジョブ制御言語で、COBOLプログラムの実行環境や入出力定義、依存関係をすべて管理しています。そのため、JCLを正しく解析しなければ、COBOLプログラム単体を読んでも全体の処理フローは把握できません。
同様に、VSAMファイルのキー構造やレコード形式、DB2のSQL文と内部処理の対応関係も、COBOL専門の解析ツールなしには正確に把握しにくいものです。こうした仕様への対処としては、IBM ADDIのような専門ツールで依存関係を自動マッピングしつつ、汎用機のオペレーターやジョブ管理担当者への聞き取りを組み合わせるのが有効です。
ベンダーを選ぶ際は、「JCLの解析・VSAM・DB2との依存関係マッピングの実績があるか」を必ず確認してください。この部分の実績がないベンダーに依頼すると、解析が途中で止まるリスクがあります。
法的リスクの回避
COBOLのリバースエンジニアリングを行う際は、必ず確認すべき法的な要件があります。適切な手続きを踏むことで、著作権侵害のリスクを最小化しながら、プロジェクトを進められます。
クリーンルーム手法の実務
クリーンルーム手法は、解析チームと実装チームを完全に分けることで、著作権侵害（依拠性）を避ける手法です。具体的には、解析チーム（Dirty Room）がソースコードを読み解いて業務仕様書を作り、その仕様書だけを実装チーム（Clean Room）に渡します。
実装チームは元のソースコードを一切参照せずに新システムを開発するため、元システムへの依拠性がなく、著作権侵害を問われない体制が整います。さらに、セガ対アッコレード事件の教訓を活かし、両チームの間に「法務・仲介担当者」を置いて、仕様書に著作権保護対象の表現が混入していないかを検査させることが、実務上のベストプラクティスです。
非享受目的での記録方法（著作権法30条の4）
平成30年の著作権法改正（第30条の4）により、「情報解析」や「技術研究」など非享受目的のリバースエンジニアリングは、原則として合法化されました。ただし、この条文の適用を受けるには、「非享受目的であること」を適切に立証できる状態にしておく必要があります。
実務上の対処としては、解析専用に隔離したパソコンや環境を用意することが求められます。さらに、解析の目的（モダナイゼーション、仕様書復元など）を記録した文書を事前に作成し、解析過程を詳細なレポートとして残しておきます。
なお、EULAにリバースエンジニアリング禁止条項がある場合でも、互換性確保に必要不可欠なときや、独占禁止法上の「拘束条件付取引」に当たるときは、その条項が無効とされる可能性があります。いずれの場合も、法務の専門家に確認したうえでプロジェクトを開始することを強く推奨します。
外注 vs 内製の判断軸：リバースとスクラッチのROI比較
COBOLのリバースエンジニアリングに着手する前に検討すべきなのは、根本的なROI判断です。現行COBOLを解析して仕様書復元とモダナイゼーションを行うか、現行COBOLを捨ててスクラッチでゼロから新システムを構築するかを比べます。
リバースエンジニアリングを実施する場合は、発注側が外注（ベンダー委託）か内製（自社エンジニアで対応）かを選ぶ必要があります。
リバース活用 vs スクラッチ開発のROI判断基準
リバース活用によるモダナイゼーションが有利なのは、現行COBOLに長年蓄積された業務ロジックが正確で、その多くを新システムでも必要とする場合です。一方、現行システムに不要な機能が山積している場合、業務プロセス自体を抜本的に再設計したい場合、スクラッチで作り直したほうがトータルコストが安い場合は、リバースエンジニアリングのコストが無駄になる可能性があります。
判断の目安として、「業務ロジック生存率」（新システムでも使える機能の割合）が70%以上ならリバース活用が有利、50%以下ならスクラッチ検討を推奨するフレームワークを使うチームも増えています。また、スクラッチ開発を選ぶ場合でも、「現行の業務ロジックの全貌を正確に把握する」プロセスは必要で、ゼロからのスタートにはならない点に注意が必要です。
外注が適切なケース・内製が適切なケース
外注が適切なのは、社内にCOBOL解析の専門スキルを持つエンジニアがいない場合や、JCL・VSAM・DB2といったホスト固有仕様の解析実績が社内に蓄積されていない場合です。COBOLのリバースエンジニアリングは高度な専門スキルを要するため、専門ベンダーに頼んだほうが、品質とスピードの面で優れた結果になることがほとんどです。
一方、内製が有効なのは、主に成果物の品質チェックや業務部門との調整役、プロジェクト管理の場面です。ただし、技術的な解析作業そのものを内製で行うことには、多くのリスクが伴います。
外注を選ぶ場合は、ベンダーの「COBOLリバースエンジニアリング実績」「クリーンルーム体制の整備状況」「成果物の粒度と品質基準の明確さ」を比べて、選定を進めてください。特に、成果物がモダナイゼーションの実装フェーズに直接使えるレベルかどうかは、後フェーズの工数を大きく左右します。
まとめ
COBOLのリバースエンジニアリングは、レガシーシステムのDX推進で避けて通れない重要なプロセスです。
6つの工程を軸に解説しました。また、ホスト固有仕様と業務部門との協働、見積もりの落とし穴を取り上げました。さらに、法的リスクと外注・内製の判断軸、リバースとスクラッチのROI判断基準も整理しました。
COBOLのリバースエンジニアリングは、技術解析と業務理解、法務対応を組み合わせて進める、総合的なプロジェクト管理が求められる取り組みです。
専門ベンダーへの外注を検討する際は、COBOL固有仕様への対応実績とクリーンルーム体制の有無を必ず確認したうえで、成果物の粒度を事前に合意してから発注を進めることが、プロジェクト成功への最短経路です。
全体ガイドの記事として、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を創業。