PL/Iのリバースエンジニアリングの完全ガイド

PL/Iのリバースエンジニアリングは、既存システムの仕様と業務ロジックを明らかにし、保守や次世代システムへの移行を安全に進めるために行います。

設計書がないまま数十年稼働し続けてきた「ブラックボックスシステム」の業務ロジックを読み解き、移行に必要な情報を取り出す、重要かつ高度なIT技術の一つです。

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

進め方と会社選び、費用、外注については、次の関連記事で詳しく解説しています。

PL/Iのリバースエンジニアリングの概要

PL/I（Programming Language One）は、1960年代にIBMが開発した汎用の業務向けプログラミング言語です。FORTRANの数値計算能力とCOBOLのビジネス処理能力を融合させた設計が特徴です。

大型汎用機（メインフレーム）上で動く保険・金融・官公庁の基幹システムの核として、今も現役で稼働しているシステムが数多くあります。

定義と対象範囲

PL/Iのリバースエンジニアリングとは、現行のPL/Iプログラムのソースコードまたはコンパイル済みバイナリを解析し、失われた設計書や業務仕様書を復元するプロセス全体を指します。

解析では、メインフレーム固有の実行環境全体を俯瞰する視点が求められます。JCL（ジョブ制御言語）によるバッチ制御やIMS/DBによるデータベースアクセスも含まれます。さらに、VSAMファイルの操作やCICSによるトランザクション制御も対象になります。

PL/I 特有のデータ型（POINTER 型・BASED 変数・AREA 属性）は逆コンパイルの難度を大幅に上げる要因です。そのため、COBOLのリバースエンジニアリング経験があっても、PL/Iには対応できないケースが少なくありません。加えて、PL/Iに対応できるエンジニアの数はCOBOLよりもはるかに少ないため、「解析できるベンダー自体が存在しない」というリスクが現実のものとなっています。

COBOLとの違い・PL/I固有の難しさ

COBOLのリバースエンジニアリングが比較的標準化された手法で進められるのに対し、PL/Iは技術的な難度がより高くなります。COBOLのデータ定義は固定的で分かりやすいものです。一方、PL/IのBASED変数は、ポインタが指すメモリ領域に動的に構造体を割り当てるため、実行時の状態を追跡しないと意味が確定しません。

AREA属性による動的メモリプール管理は、複数のプログラム間でデータを受け渡す複雑なデータフローを生み出します。また、PL/IのON条件（例外処理）は複雑な入れ子構造になり得るため、通常の処理フローとは別に、例外時の分岐を丁寧に追跡する必要があります。

▶ 詳細はこちら：PL/Iのリバースエンジニアリングの進め方・手順・手法を解説をご覧ください。

PL/Iで実施する目的とメリット

PL/Iのリバースエンジニアリングが実施される背景には、複数の切実なビジネス課題があります。

このプロジェクトは、経営や業務の必要性から推進されるものです。技術的な好奇心から始まるものではありません。

レガシーシステムモダナイゼーションの起点

PL/Iシステムのモダナイゼーション（メインフレームからオープン系・クラウドへの移行）では、リバースエンジニアリングが不可欠な役割を担います。その役割とは、設計書が存在しないシステムから、新システムの構築に必要な業務仕様を取り出すことです。

経済産業省が指摘した「2025年の崖」（老朽化したレガシーシステムへの対処遅延による2025年以降の経済損失リスク）の文脈でも、この点は指摘されています。PL/Iシステムを抱える保険・金融・官公庁にとって、モダナイゼーションは待ったなしの課題です。さらに、PL/Iを扱えるエンジニアの高齢化と退職が急速に進んでおり、リバースエンジニアリングの必要性を高めています。

属人的に保持されてきた業務知識は、エンジニアの退職とともに失われてしまいます。そのため、失われる前にコードから業務ロジックを抽出してドキュメント化することは、企業にとっての「技術継承」そのものです。また、セキュリティ監査の観点から、長年稼働してきたPL/Iシステムに潜む脆弱なロジックを特定する目的でも実施されます。

スクラッチ開発に比べたROIと期間短縮効果

業務ロジック生存率（引き継ぐべき業務ルールの割合）が60%以上の場合、リバースエンジニアリングを活用したモダナイゼーションは、ゼロからの要件定義・開発と比べ、プロジェクト期間を30〜50%短縮できる可能性があります。

既存の業務ロジックを参照することで、業務部門への要件ヒアリングの工数が削減され、見落としや漏れのリスクも低減されます。

不要な機能が蓄積して業務ロジックの生存率が40%未満の場合は、リバースエンジニアリングへの投資よりも、スクラッチ開発のほうがROIが高くなるケースがあります。

ポイント

業務ロジック生存率が60%以上なら期間短縮の可能性があり、40%未満ならスクラッチ開発のほうがROIが高くなることもあります。生存率を先に把握して比べるのが目安です。

PL/Iのリバースエンジニアリングの進め方

最初の対象範囲と目的が、後続の解析作業を方向づけます。

PL/Iのリバースエンジニアリングは、体系化された工程に沿って進めることが成功の鍵です。

対象選定・解析フェーズ

対象選定・解析フェーズは、次の手順で進めます。最初のステップは「対象選定・目的明確化」です。PL/Iシステムは数百〜数千のプログラムモジュールで構成されることが多く、全量解析か業務領域を絞った部分解析かによって、費用と期間が大きく変わります。

対象選定・目的明確化：JCLのJOB定義から実行プログラム一覧を洗い出し、業務上の重要度と変更頻度に基づいて優先順位を設定する
解析環境・ツール準備：EBCDIC対応のエディタを用意し、CICSやIMS/DBのミドルウェア設定ファイルを収集する
静的解析・動的解析：プログラムを実行せずに読む静的解析と、z/OS上のデバッガで実行をトレースする動的解析を使う
Design Recovery（抽象化）：実装レベルから設計・仕様レベルへ段階的に抽象化し、業務部門との確認会議で「Why」を補完する

解析ツールは、IBM ADDIやMicro Focus Enterprise Analyzer等のメインフレーム専用ツールを用意します。特にBASED変数とポインタ操作は、静的解析だけでは意味が確定しないため、動的解析との組み合わせが大きな鍵になります。

成果物化フェーズと品質管理

成果物は「フローチャート」「業務仕様書」「詳細設計書」の3段階の粒度で設定されます。フローチャートは処理概要を把握するのに適した最低レベルの成果物です。業務仕様書は業務ルールの背景（Why）を含み、新システムの要件定義に活用できます。

詳細設計書は、新システムの画面設計やDB設計に直結する情報まで含む、最も精度の高い成果物です。成果物によって費用と期間が大きく異なるため、どの粒度を求めるかを先に決める必要があります。

成果物の品質管理では、「変数名の意味・業務コメントの付記」「業務部門によるレビュー承認」「不明箇所リストの完備」を、要件としてあらかじめ定めておくことが大切です。

ポイント

解析の対象範囲と成果物の粒度で費用と期間が大きく変わるため、最初に対象範囲と求める粒度を決めておくことが、工程全体の判断の起点になります。

開発会社の選び方

技術面とプロジェクト運営面の両方に確認点があります。

PL/Iのリバースエンジニアリングに対応できる国内ベンダーは極めて少ないため、適切なパートナーを選ぶことが、プロジェクトの成否を左右します。選定の基準は、主に「実績と技術力」と「プロジェクト管理体制とサポート」の2点です。

実績と技術力の確認ポイント

ベンダー選定で最初に確認すべきは、「PL/Iのリバースエンジニアリング実績の具体的な件数と規模」です。「メインフレーム対応」を掲げていても、実際にはCOBOL中心の実績しかない会社が多くあります。そのため、PL/I固有のBASED変数・AREA属性・ON条件への対応経験があるかを、具体的に確かめることが欠かせません。

担当予定の技術者については、PL/Iの実務年数、JCLやIMS/DB・CICSの実務経験、解析ツールの活用実績を、提案の段階で確認してください。

著作権リスクの観点では、「クリーンルーム手法の自社プロセスとしての整備状況」と「法務担当者の関与体制」も、必ず確認すべき事項です。

プロジェクト管理体制とサポートの評価

PL/Iのリバースエンジニアリングは、技術解析と業務の意味付けが交互に進む反復プロセスです。そのため、業務部門との連携をどう進めるかを、ベンダーが標準のプロセスとして持っているかが重要な評価軸になります。「業務照会リストの管理」「定期レビュー会議の設計」「中間成果物の品質保証基準」が整備されているベンダーは、プロジェクト後半での混乱が起きにくい傾向があります。

また、コンサルティング機能を持つベンダーであれば、「How」の技術的解析に加えて、「Why」の業務的な意味付けを補うビジネス視点の支援が期待できます。そのため、最終成果物の精度も高くなります。

▶ 詳細はこちら：PL/Iのリバースエンジニアリングでおすすめの開発会社6選と選び方をご覧ください。

ポイント

PL/Iの解析実績と担当技術者の実務経験を具体的に確かめ、業務部門との連携を標準のプロセスとして持つかどうかで候補を比べるのが目安です。

費用相場

PL/Iのリバースエンジニアリング費用は、LOC（ソースコード行数）を基準とした従量課金が基本です。ただし、PL/I固有の複雑さを反映した割増が必要で、他言語のLOC単価を参照することはできません。

規模別の費用目安

PL/I のリバースエンジニアリング単体（ソースコード解析・仕様書復元）では、フローチャートレベルで 1 万行あたり 100〜200 万円が目安です。業務仕様書レベルでは 300〜600 万円、詳細設計書レベルでは 600〜1,200 万円が目安です。

これに加えて、JCL・IMS/DB・CICSの連携解析費用が必要になります。連携解析費用は、ソースコード解析費の20〜50%が目安です。

モダナイゼーション全体では、リホスト（単純移行）が数千万円〜1 億円台・3〜6 か月、リプラットフォームが 1 億円〜3 億円・6〜12 か月が目安です。さらに、リファクタリングは 2 億円〜5 億円・12〜18 か月、リビルドは 5 億円以上・18 か月以上とされています。

費用を左右する主な要因

PL/Iリバースエンジニアリングの費用を左右する主な要因は4つです。第一に「成果物の粒度」で、フローチャートと詳細設計書では単価が6倍以上変わります。第二に「BASED変数・ポインタ操作の密度」で、これらが多用されているコードは解析工数が1.5〜3倍に増加します。

第三に「ミドルウェア連携の複雑さ」で、IMS/DB・CICSの利用規模と複雑度が連携解析費用を決定します。第四に「特急料金」で、通常納期の短縮化で20〜30%、超特急対応で40〜60%の割増が発生します。

▶ 詳細はこちら：PL/Iのリバースエンジニアリングの費用相場・見積もりの考え方をご覧ください。

ポイント

成果物の粒度や解析の複雑さ、特急対応の有無などが重なって費用が決まるため、見積もりは要因をそろえて比べるのが目安です。

発注・外注方法

PL/Iのリバースエンジニアリングを外注する際は、発注側の準備と体制づくりが成功の鍵を握ります。発注では、発注先の種類を把握したうえで、発注前に資料と契約条件を整えます。

発注先の種類と特徴

PL/Iのリバースエンジニアリングの発注先は、大きく「大手SIer（NTT データ・日本 IBM・富士通・日立等）」「コンサルティングファーム系」「独立系専門ベンダー」に分類されます。

大手SIerは、規模・実績・リソースの面で安心感がある一方、小規模案件への対応や費用面の柔軟性には限界があることが多いです。コンサルティングファーム系は、業務的な「Why」の補完に強く、技術解析と業務分析を一体で進められるのが特徴です。

プロジェクトの規模、業界の特性、自社の技術力を踏まえて、発注先の種類を選ぶことが重要です。

発注前に準備すべきドキュメント

発注前に準備すべき主要なドキュメントは3点です。1つ目は「システム資産台帳」で、PL/I ソースファイル一覧・総 LOC・JCL 一覧・IMS/DBD/PSB 定義・CICS トランザクション定義を含みます。2つ目は「目的と成果物要件の仕様書」、3つ目は「セキュリティ要件の定義書」です。

RFPには、PL/I 固有の技術要件（BASED 変数・AREA 属性対応）、ミドルウェア連携解析の扱い、成果物の品質基準を明記します。NDAには、ソースコードの著作権確認と第三者への開示禁止を含めます。加えて、プロジェクト終了後のデータ消去義務も盛り込み、クリーンルーム手法の契約条項を整備してください。

▶ 詳細はこちら：PL/Iのリバースエンジニアリングを外注する方法・発注前の準備と進め方をご覧ください。

法的リスクと対策（著作権法30条の4・クリーンルーム）

両チームの間に置かれるのは、解析からまとめた仕様書です。

PL/Iのリバースエンジニアリングに関わる法的リスクは、著作権法・不正競争防止法・特許法の3法が主な関連法令となります。

法的な管理を欠いたまま進めると、深刻な法的問題に発展するおそれがあります。

著作権法第30条の4と非享受目的の立証

平成30年（2018年）の著作権法改正により、第30条の4には「情報解析・システム開発・保守等の非享受目的」のリバースエンジニアリングは原則合法とする規定が整備されました。

ただし、「非享受目的」であることを事後的に立証できる記録の整備が重要です。解析専用の隔離PC・仮想環境の使用、プロジェクト日報への解析目的・対象・手順・結果の記録、解析情報の業務外転用禁止に関する誓約書への署名が、典型的な立証手段となります。

自社が開発したシステムや適法に取得したソフトウェアの解析であれば、通常この要件を満たします。

クリーンルーム手法による著作権侵害リスクの排除

他社が開発したPL/Iシステムを解析して新システムを作る場合、クリーンルーム手法が著作権侵害リスクを排除する標準的な手法です。この手法の有効性は、1980年代のフェニックス・テクノロジーズ対IBM BIOS訴訟で確立され、現在も業界標準として機能しています。

解析チーム（Dirty Room）と開発チーム（Clean Room）を人員レベルで完全に分け、解析チームが作成した仕様書のみを開発チームに渡します。この方法なら、開発チームは元のコードに「依拠」せずに新システムを開発できます。

仕様書に記すのは、著作権で保護された「表現」を除いた「機能」「アルゴリズム」のみとし、その線引きを法務担当者がフィルタリングします。このフィルタリングを行う体制の整備こそ、実務上の核心です。

ポイント

非享受目的で行うなら原則合法ですが、その目的を事後に立証できる記録を残しておくことが大切です。他社のシステムを解析する場合は、クリーンルーム手法で解析チームと開発チームを分けることが目安です。

PL/I特化の解析ツール紹介

PL/Iのリバースエンジニアリングでは、汎用ツールに加えて、PL/Iとメインフレーム環境に特化したツールを活用することが重要です。

メインフレーム・PL/I専用ツール

PL/Iとメインフレーム環境に特化したツールは、静的解析、プログラム間のデータフローの可視化、動的解析など、用途ごとに役割が分かれます。

IBM Application Discovery and Delivery Intelligence（ADDI）：PL/Iの静的解析に特化したIBM純正ツール
ADDIの解析範囲：PL/Iプログラム間のデータフロー、JCLとの対応関係、CICSトランザクション定義との連携を自動解析して図にする
Micro Focus Enterprise Analyzer（現 OpenText Enterprise Analyzer）：PL/I対応の主要な解析基盤
Enterprise Analyzerの機能：コードの複雑度分析、デッドコード検出、業務ルール抽出
Compuware Xpediter：z/OS上のデバッガで、CICSトランザクションやIMS/DBアクセスのリアルタイムトレースが可能

ADDIは、大規模なPL/Iシステムの全体像をつかむのに最も適しています。また、Xpediterは動的解析で標準的に使われています。

汎用解析ツールとPL/Iへの適用限界

Ghidra（NSA 開発・無料オープンソース）やIDA Pro（業界標準の有料ツール）は、バイナリ・アセンブラレベルの解析に優れています。一方で、PL/Iの高水準構造体（STRUCTURE・BASED変数）の意味論的な解析には限界があります。

そのため、PL/Iのソースコードが入手できる場合は専用ツール（IBM ADDI・Micro Focus EA）を優先します。ソースが存在せずコンパイル済みのロードモジュールしかない場合に限って、GhidraやIDA Proを補助的に使い分けるのが適切です。

いずれのツールを使う場合でも、EBCDICエンコーディングへの対応と、PL/Iの実行時特性（動的メモリ割り当て・ON条件）を踏まえた手動解析との組み合わせが欠かせません。

よくある質問（FAQ）

PL/Iのリバースエンジニアリングについて、よく寄せられる質問を2つ取り上げ、回答します。

Q：ソースコードがない場合でも対応できますか？

A：ソースコードが存在しない場合でも、コンパイル済みロードモジュール（バイナリ）から解析を行うことは技術的に可能です。ただし、難易度と工数が大幅に増加します。

PL/Iのバイナリ解析では、Ghidra・IDA Proによる逆アセンブルが基本となります。一方で、PL/Iのコンパイラが生成するコードには最適化による変換が加わっているため、元のソース構造の復元精度に限界があります。

ソースコードがある場合と比べて費用と期間が2〜3倍になるケースも珍しくありません。そのため、まず古いバックアップやアーカイブからソースコードを探すことを強くお勧めします。

Q：COBOL対応のベンダーにPL/Iも依頼できますか？

A：COBOLとPL/Iは、どちらもIBMメインフレーム向けの言語ですが、データ型・プログラム構造・コンパイラの特性が大きく異なります。

特にPL/IのBASED変数・POINTER型・AREA属性は、COBOLにはない概念です。そのため、COBOL専門のエンジニアがそのままPL/Iを解析することには無理があります。

「メインフレーム対応」「COBOL対応実績あり」といった説明は、判断材料として十分とはいえません。発注を決める前に、必ず「PL/Iの解析実績の具体例」と「担当予定の技術者のPL/I実務経験」を確認してください。

まとめ

PL/Iのリバースエンジニアリングは、保険・金融・官公庁の基幹システムを支えてきたレガシーシステムのモダナイゼーションに欠かせないプロセスです。

COBOL以上に希少なエンジニアリソース、BASED変数・AREA属性・ON条件といった固有データ型の解析難度、JCL・IMS/DB・CICSとの連携解析という多層的な技術課題が重なる領域です。そのため、成功させるには、適切な専門パートナーを選ぶことと、発注側が十分に準備することが欠かせません。

各トピックの詳細は、本文中で紹介した専門記事で掘り下げています。モダナイゼーションや仕様書復元を検討する際は、まず進め方と費用の記事で流れを押さえ、そのうえで発注方法と会社比較の記事を読むと、全体像をつかみやすくなります。

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
 ・スクラッチシステム開発の完全ガイドブック
 ・【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を創業。