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

PL/I のリバースエンジニアリングは、COBOL と並ぶ IBM メインフレームの主要言語として保険・金融・官公庁の基幹システムを支えてきた PL/I プログラムを対象に、失われた設計書や業務仕様書を復元する作業です。設計書なしで数十年稼働し続けてきた「ブラックボックスシステム」の業務ロジックを正確に解析し、次世代システムへの移行に必要な情報を抽出するこのプロセスは、現代における最も重要かつ高度な IT 技術の一つとなっています。

本記事は PL/I のリバースエンジニアリングに関するすべての疑問に答えるピラー記事です。「PL/I リバースエンジニアリングとはそもそも何か」から「なぜ実施するのか」「どのように進めるか」「いくらかかるか」「どこに依頼するか」「法的リスクはどう回避するか」「どんなツールを使うか」まで、概要レベルで網羅的に解説します。各トピックの詳細については、リンク先の専門記事で深く掘り下げています。

▼ 関連記事
・PL/Iのリバースエンジニアリングの進め方・手順・手法を解説
・PL/Iのリバースエンジニアリングでおすすめの開発会社6選と選び方
・PL/Iのリバースエンジニアリングの費用相場・見積もりの考え方
・PL/Iのリバースエンジニアリングを外注する方法・発注前の準備と進め方

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 には対応できないケースが少なくありません。さらに対応できるエンジニア人口が COBOL よりもはるかに少ないため、「解析できるベンダー自体が存在しない」というリスクが現実のものとなっています。

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 システムに潜む脆弱なロジックを特定する目的でも実施されます。

PL/I システムの業務ロジック生存率（現行システムで引き継ぐべき業務ルールの割合）が 60% 以上の場合、リバースエンジニアリングを活用したモダナイゼーションはゼロからの要件定義・開発と比べてプロジェクト期間を 30〜50% 短縮できる可能性があります。既存の業務ロジックを参照することで、業務部門への要件ヒアリング工数が削減され、見落としや漏れのリスクも低減されます。一方、不要な機能が蓄積し業務ロジックの生存率が 40% 未満の場合は、リバースエンジニアリングへの投資よりもスクラッチ開発のほうが ROI が高くなるケースがあります。

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

PL/I のリバースエンジニアリングは、体系化された工程に従って進めることが成功の鍵です。主要な工程を概要レベルで解説します。

最初のステップは「対象選定・目的明確化」です。PL/I システムは数百〜数千のプログラムモジュールで構成されることが多く、全量解析か業務領域を絞った部分解析かによって費用・期間が大幅に変わります。JCL の JOB 定義から実行プログラム一覧を洗い出し、業務上の重要度と変更頻度に基づいて優先順位を設定します。次に「解析環境・ツール準備」として、EBCDIC 対応のエディタ・メインフレーム専用解析ツール（IBM ADDI、Micro Focus Enterprise Analyzer 等）・CICS や IMS/DB のミドルウェア設定ファイルを収集します。

解析フェーズでは「静的解析」（プログラムを実行せずコードと定義を読み解く作業）と「動的解析」（z/OS 上のデバッガを使った実行トレース）を組み合わせます。PL/I の BASED 変数とポインタ操作は静的解析だけでは意味が確定しないため、動的解析との組み合わせが特に重要です。その後、「Design Recovery（抽象化）」として実装レベルから設計・仕様レベルへの段階的抽象化を行い、業務部門との確認会議を通じて「Why」を補完します。

成果物は「フローチャート」「業務仕様書」「詳細設計書」の 3 段階の粒度で設定されます。フローチャートは処理概要の把握に適した最低レベルの成果物であり、業務仕様書は業務ルールの背景（Why）を含む新システム要件定義に活用できるレベルです。詳細設計書は、新システムの画面設計・DB 設計に直結する情報まで含む最も高精度な成果物であり、それぞれ費用と期間が大きく異なります。成果物の品質管理では「変数名の意味・業務コメントの付記」「業務部門によるレビュー承認」「不明箇所リストの完備」を必ず要件化することが重要です。

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

開発会社の選び方

PL/I のリバースエンジニアリングに対応できる国内ベンダーは極めて少なく、適切なパートナー選定がプロジェクトの成否を左右します。ベンダー選定の基準となる主要ポイントを解説します。

ベンダー選定で最初に確認すべきは「PL/I のリバースエンジニアリング実績の具体的な件数と規模」です。「メインフレーム対応」を謳っていても実際には COBOL 中心の実績しかない会社が多く、PL/I 固有の BASED 変数・AREA 属性・ON 条件への対応経験があるかを具体的に確認することが不可欠です。担当予定の技術者の PL/I 実務年数・JCL や IMS/DB・CICS の実務経験・解析ツールの活用実績も提案段階で確認してください。「クリーンルーム手法の自社プロセスとしての整備状況」と「法務担当者の関与体制」も、著作権リスクの観点から必須の確認事項です。

PL/I のリバースエンジニアリングは、技術解析と業務意味付けが交互に進む反復プロセスであるため、業務部門との連携設計をベンダーが標準プロセスとして持っているかが重要な評価軸です。「業務照会リストの管理」「定期レビュー会議の設計」「中間成果物の品質保証基準」が整備されているベンダーは、プロジェクト後半での混乱が起きにくい傾向があります。また、コンサルティング機能を持つベンダーであれば、「How」の技術的解析に加えて「Why」の業務意味付けを補完するビジネス視点での支援が期待でき、最終成果物の精度が高くなります。

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

費用相場

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」の補完に強く、技術解析と業務分析を一体で進められるのが特徴です。プロジェクト規模・業界特性・自社の技術力を勘案したうえで発注先の種類を選定することが重要です。

発注前に準備すべき主要ドキュメントは「システム資産台帳（PL/I ソースファイル一覧・総 LOC・JCL 一覧・IMS/DBD/PSB 定義・CICS トランザクション定義）」「目的と成果物要件の仕様書」「セキュリティ要件の定義書」の 3 点です。RFP には PL/I 固有の技術要件（BASED 変数・AREA 属性対応）とミドルウェア連携解析の扱い、成果物の品質基準を明記します。NDA にはソースコードの著作権確認・第三者開示禁止・プロジェクト終了後のデータ消去義務を含め、クリーンルーム手法の契約条項も整備してください。

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

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

PL/I のリバースエンジニアリングに関わる法的リスクは、著作権法・不正競争防止法・特許法の 3 法が主な関連法令となります。適切な法的管理なしにリバースエンジニアリングを実施すると、深刻な法的問題に発展するリスクがあります。

平成 30 年（2018 年）の著作権法改正により、第 30 条の 4 に「情報解析・システム開発・保守等の非享受目的」のリバースエンジニアリングは原則合法とする規定が整備されました。ただし、「非享受目的」であることを事後的に立証できる記録の整備が重要です。解析専用の隔離 PC・仮想環境の使用、プロジェクト日報への解析目的・対象・手順・結果の記録、解析情報の業務外転用禁止に関する誓約書への署名が、典型的な立証手段となります。自社が開発したシステムや適法に取得したソフトウェアの解析であれば、通常この要件を満たします。

第三者のソフトウェア（他社が開発した PL/I システム）をリバースエンジニアリングして新システムを開発する際には、クリーンルーム手法が著作権侵害リスクを排除する標準的な手法として確立されています。解析チーム（Dirty Room）と開発チーム（Clean Room）を人員レベルで完全に分離し、解析チームが作成した仕様書のみを開発チームに渡す方法で、開発チームは元のコードに「依拠」せずに新システムを開発できます。仕様書には著作権で保護された「表現」ではなく「機能」「アルゴリズム」のみが記述されるよう、法務担当者がフィルタリングを行うプロセスの整備が実務上の核心です。1980 年代のフェニックス・テクノロジーズ対 IBM BIOS 訴訟でこの手法の有効性が確立されており、現在も業界標準として機能しています。

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

PL/I のリバースエンジニアリングには、汎用的なバイナリ解析ツールだけでなく、PL/I とメインフレーム環境に特化したツールの活用が重要です。代表的なツールを紹介します。

IBM Application Discovery and Delivery Intelligence（ADDI）は、PL/I を含むメインフレームアプリケーションの静的解析・依存関係可視化・コール関係マッピングに特化した IBM 純正ツールです。PL/I のプログラム間のデータフロー、JCL との対応関係、CICS トランザクション定義との連携を自動的に解析・図式化する機能を持ち、大規模 PL/I システムの全体像把握に最も適しています。Micro Focus Enterprise Analyzer（現 OpenText Enterprise Analyzer）も PL/I に対応した主要な解析プラットフォームであり、コードの複雑度分析・デッドコード検出・業務ルール抽出機能を提供します。動的解析には z/OS 上で動作する Compuware Xpediter（デバッガ）が標準的に使用されており、CICS トランザクションや IMS/DB アクセスのリアルタイムトレースが可能です。

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 のリバースエンジニアリングに関して、よくいただく質問とその回答をまとめました。

A：ソースコードが存在しない場合でも、コンパイル済みロードモジュール（バイナリ）から解析を行うことは技術的に可能ですが、難易度と工数が大幅に増加します。PL/I のバイナリ解析には Ghidra・IDA Pro を用いた逆アセンブルが基本となりますが、PL/I のコンパイラが生成するコードには最適化による変換が加わっているため、元のソース構造の復元精度に限界があります。ソースコードがある場合と比較して費用・期間が 2〜3 倍になるケースも珍しくないため、まず古いバックアップやアーカイブからソースコードの発掘を試みることを先行して行うことを強くお勧めします。

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 との連携解析という多層的な技術課題が重なるこの領域は、適切な専門パートナーの選定と発注側の十分な準備なしに成功させることはできません。

本記事で紹介した各トピックの詳細は、下記の専門記事で掘り下げています。PL/I システムのモダナイゼーションや仕様書復元をご検討の際は、まず進め方・費用・発注方法・会社比較の各記事を読んで全体像を把握されることをお勧めします。

▼ 関連記事
・PL/Iのリバースエンジニアリングの進め方・手順・手法を解説
・PL/Iのリバースエンジニアリングでおすすめの開発会社6選と選び方
・PL/Iのリバースエンジニアリングの費用相場・見積もりの考え方
・PL/Iのリバースエンジニアリングを外注する方法・発注前の準備と進め方

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

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

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

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

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

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。