基幹システムを長年支えてきたCOBOLプログラムは、担当者の退職やドキュメントの散逸によって、今や社内でも「何をしているのか分からない」ブラックボックスになっているケースが少なくありません。DX推進の波に乗ってモダナイゼーションを進めたいと考えても、設計書がなければ何をどう移行すればよいか判断できず、プロジェクトが動き出せない状況が続いています。
本記事では、COBOLのリバースエンジニアリングの進め方を6つの工程に分けて解説します。ホスト固有仕様のブラックボックス化という難題や、業務ロジックの「Why（なぜその仕様なのか）」を正しく復元するための業務部門との協働体制、さらに外注と内製の判断軸まで、実務で役立つ知識を網羅的にまとめました。COBOL移行プロジェクトを担当するITマネージャーやPMの方に、ぜひ最後までお読みいただけますと幸いです。
▼全体ガイドの記事
・COBOLのリバースエンジニアリングの完全ガイド
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とのインターフェース解析です。COBOLプログラム単体ではなく、どのJCLステップからどのプログラムが呼ばれ、どのVSAMファイルやDB2テーブルにアクセスしているかという依存関係マップを作成することが、後工程での仕様復元の精度を左右します。このフェーズで制御フローグラフ（CFG）を作成しておくと、次の動的解析との対照が容易になります。
工程4. 動的解析（実行トレース・業務シナリオ検証）
動的解析は、実際にプログラムを動作させながら処理の流れを追跡する工程です。テスト環境でデバッガをアタッチし、各業務シナリオ（月末バッチ、受注処理、在庫更新など）を実行しながら、データがどのように変換・移送されているかをリアルタイムで観察します。静的解析だけでは把握しきれなかった条件分岐のパターン（特定の業務条件でのみ発動するロジック）を発見できるのが動的解析の大きなメリットです。
COBOLの動的解析で特に注意すべきなのは、本番環境でしか発動しない業務条件の扱いです。月次・年次の締め処理や、特定の取引コード・顧客コードに紐づく例外処理は、テスト環境での再現が困難なケースが多くあります。このような場合は業務部門の担当者に実際の業務フローを聞き取りながら、テストデータを作成して解析を進める必要があります。「コードは読めるが業務の意図が分からない」というリバースエンジニアリング最大の落とし穴を回避するために、業務部門との連携は工程3の静的解析段階から開始しておくことが望まれます。
工程5. 抽象化（実装レベル→設計レベル→仕様レベルへの引き上げ）
工程3・4で収集した情報を段階的に抽象化し、業務仕様書として再構築する工程です。Design Recovery（設計回復）とも呼ばれるこのプロセスでは、まず実装レベルの制御フローをプログラムフローチャートに変換し、次に複数の処理を束ねた業務機能単位（例：「受注登録機能」「在庫引当機能」）として設計レベルのドキュメントを作成します。最終的には、新システム開発の要件として使用できる仕様レベルの業務仕様書（画面遷移図・データフロー図・業務ルール一覧）に昇華させます。
この工程で最も重要かつ難しいのが、「Why（なぜその仕様になっているか）」の復元です。COBOLのコードには30年以上前に意思決定された業務ルールが埋め込まれていることがあり、業務部門の協力なしに「何をしているか（How）」は分かっても「なぜそうなっているのか（Why）」を正確に把握することはできません。ベテランの業務担当者へのインタビュー、過去の仕様変更履歴の調査、現行業務フローの確認を並行して進めることで、コードの背後にある業務上の意思決定を文書化していきます。
工程6. 成果物化（仕様書・新システム設計への接続）
解析・抽象化の結果を正式な成果物としてまとめ、次フェーズ（モダナイゼーション実装）に引き渡す工程です。成果物の粒度は発注時に明確に合意しておく必要があり、大きく「フローチャートのみ」「業務機能仕様書（業務ルール・画面遷移含む）」「新システム設計に直結する詳細設計書（DB設計・API仕様含む）」の3段階があります。粒度によって費用と期間が大きく変わるため、発注者側が何のために使うのかを明確にした上で合意することが重要です。
成果物には必ず「変数名の意味説明」「業務ロジックのWhy（判断根拠）」「例外処理の業務的意味」を含めることを要件として明示してください。これらが欠けた成果物は、表面上は仕様書として存在しますが、実際にモダナイゼーションに使おうとすると業務ルールの解釈に迷い、移行後バグの温床となります。機械変換後のコードが若手エンジニアでも保守できる品質かどうかを最終確認の基準に据えることで、成果物の質が大幅に向上します。
COBOL固有の注意点と失敗パターン
COBOLのリバースエンジニアリングには、他の言語では見られないCOBOL特有の落とし穴が存在します。これらを事前に把握しておくことで、プロジェクトの失敗リスクを大幅に低減できます。
典型的な失敗パターン
最も多い失敗パターンは「LOC（行数）課金で見積もりを取ったら、想定の3倍の費用になった」という事例です。前述のとおり、COBOLの1行はReactやPythonの1行とは意味の重みが全く異なります。COBOL 1万行のプログラムには、複雑な業務ルールが密集していることが多く、解析工数は行数の単純比例ではありません。発注者側がLOC単価のみで比較してベンダーを選定すると、後から追加費用が発生する事態になりがちです。見積もりを取る際は「LOC課金の適正単価がCOBOL向けに設定されているか」「COBOL特有の複雑さを見積もりに反映しているか」を必ず確認してください。
次に多い失敗パターンは「コードは解析できたが、業務ルールの意味が分からず移行後にバグが多発した」というケースです。COBOLプログラムには「なぜ特定の顧客コードの場合だけ処理を分岐させているのか」「この計算式の業務的な根拠は何か」といった、コードを読んだだけでは判断できない経緯が多数潜んでいます。この問題を防ぐためには、リバースエンジニアリングの最初から業務部門を巻き込み、解析チームが「How（どう動いているか）」を読み解きながら、業務担当者が「Why（なぜそうなのか）」を補完するという協働体制を構築することが不可欠です。
ホスト固有仕様（JCL・DB2・VSAM）のブラックボックス問題
COBOLのリバースエンジニアリングで汎用ツールが「限界」を迎えるのが、ホスト固有仕様（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のリバースエンジニアリングを実施する際に必ず検討すべきなのが、「現行COBOLをリバースエンジニアリングして仕様書復元・モダナイゼーションを行うか」vs「現行COBOLを捨ててスクラッチでゼロから新システムを構築するか」という根本的なROI判断です。また、実施する場合でも外注（ベンダー委託）か内製（自社エンジニアで対応）かの選択も重要な意思決定ポイントです。
リバース活用 vs スクラッチ開発のROI判断基準
リバースエンジニアリングを活用したモダナイゼーションが有利なのは、現行COBOLに長年蓄積された業務ロジックが正確で、かつその多くが新システムでも必要とされる場合です。一方、「現行システムには不要な機能が山積している」「業務プロセス自体を抜本的に再設計したい」「スクラッチで作り直したほうがトータルコストが安い」という状況では、リバースエンジニアリングのコストが無駄になる可能性があります。
判断の目安として、現行COBOLの「業務ロジック生存率」（新システムでも使える機能の割合）が70%以上であればリバース活用が有利、50%以下であればスクラッチ検討を推奨するフレームワークを活用するチームも増えています。また、スクラッチ開発を選択する場合でも、リバースエンジニアリングによって「現行の業務ロジックの全貌を正確に把握する」プロセスは必要であり、完全にゼロスタートにはならない点に注意が必要です。
外注が適切なケース・内製が適切なケース
外注が適切なのは、社内にCOBOL解析の専門スキルを持つエンジニアがいない場合、またはJCL・VSAM・DB2といったホスト固有仕様の解析実績が社内に蓄積されていない場合です。COBOLのリバースエンジニアリングは高度な専門スキルを要するため、専門ベンダーに依頼した方が品質・スピードの面で優れた結果になることがほとんどです。内製が有効なのは、主に成果物の品質チェックや業務部門との調整役、プロジェクト管理においてであり、技術的な解析作業そのものを内製で行うことには多くのリスクが伴います。
外注を選択する場合は、ベンダーの「COBOLリバースエンジニアリング実績」「クリーンルーム体制の整備状況」「成果物の粒度と品質基準の明確さ」を比較軸に選定を進めてください。特に「成果物がモダナイゼーションの実装フェーズに直接使えるレベルか」という観点は、後フェーズの工数を左右する重要な判断ポイントです。
まとめ
COBOLのリバースエンジニアリングは、レガシーシステムのDX推進において避けて通れない重要なプロセスです。本記事では6つの工程（対象選定・ツール準備・静的解析・動的解析・抽象化・成果物化）を中心に、COBOL特有のホスト仕様（JCL・DB2・VSAM）のブラックボックス問題、業務ロジックの「Why」を復元するための業務部門協働の必要性、LOC課金の落とし穴と適正な見積もり方法、クリーンルーム手法による法的リスク管理、そしてリバース活用 vs スクラッチのROI判断基準について解説しました。
COBOLのリバースエンジニアリングはツールを揃えれば完結するものではなく、技術解析と業務理解と法務対応を組み合わせた総合的なプロジェクト管理が求められます。専門ベンダーへの外注を検討する際は、COBOL固有仕様への対応実績とクリーンルーム体制の有無を必ず確認した上で、成果物の粒度を事前に合意してから発注を進めることが、プロジェクト成功への最短経路です。
▼全体ガイドの記事
・COBOLのリバースエンジニアリングの完全ガイド
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。