PL/Iのリバースエンジニアリングは、COBOL と並ぶ基幹業務向け言語として IBM 大型汎用機（メインフレーム）上で稼働する保険・金融・官公庁の基幹システムを対象とした、極めて高度な専門作業です。設計書が存在しないまま数十年にわたって稼働してきたシステムから業務ロジックを正確に復元するためには、PL/I 特有のデータ型や実行環境への深い理解が不可欠であり、COBOL 対応経験のある会社でさえ対応できないケースが少なくありません。

本記事では、PL/I のリバースエンジニアリングとは何か、という基礎から始まり、実際のプロジェクトで踏む 6 つの工程、PL/I 固有の注意点と失敗パターン、法的リスクの回避方法、そして外注と内製の判断軸まで、一貫して解説します。PL/I システムのモダナイゼーションや仕様書復元を検討されている方に、実務的な情報をお届けします。

▼全体ガイドの記事
・PL/Iのリバースエンジニアリングの完全ガイド

PL/Iのリバースエンジニアリングとは

PL/I（Programming Language One）は、1960年代に IBM が汎用業務向けとして開発したプログラミング言語で、FORTRAN の数値計算能力と COBOL の業務処理能力を融合させた設計が特徴です。保険会社の保険金計算システム、証券会社の清算システム、大規模な官公庁の給付管理システムなど、ミッションクリティカルな基幹業務の中核を担ってきました。リバースエンジニアリングとは、このような現行の PL/I プログラムのソースコードやバイナリを解析し、失われた設計書や仕様書を復元する作業を指します。

PL/I のリバースエンジニアリングが COBOL や C 言語の場合と大きく異なるのは、まず言語固有のデータ型の複雑さにあります。POINTER 型による動的メモリ管理、BASED 変数（ポインタが指すメモリ領域に割り当てられる変数）、AREA 属性による動的メモリプール管理など、PL/I 特有のデータ操作機構は逆コンパイル後のコードを著しく難読にします。単純なデータ型しか持たない COBOL では比較的容易に変数の役割を特定できますが、PL/I では BASED 変数のポインタ追跡だけで解析工数の数割を占めるケースがあります。

さらに、PL/I システムの実行環境は IBM メインフレーム固有のミドルウェアと密接に結びついています。JCL（Job Control Language）によるバッチ制御、IMS/DB によるデータベースアクセス、VSAM ファイルの直接操作、CICS トランザクション制御など、これらのミドルウェアとの連携部分は PL/I ソースコードだけを見ても意味が読み取れず、実行環境全体を俯瞰した解析が必要となります。COBOL に比べてもエンジニア人口がさらに少ないため、この実行環境を熟知した解析者を確保すること自体が大きなハードルです。

PL/I のリバースエンジニアリングが実施される主な目的は 3 つに大別されます。第一は、メインフレームからオープン系やクラウド基盤へのモダナイゼーション（レガシー移行）です。稼働中のシステムについて設計書が消失しているか、あるいは初めから整備されていなかった場合に、リバースエンジニアリングによって業務仕様を復元し、新システムの要件定義書として活用します。第二は、セキュリティ監査・脆弱性診断です。長年稼働してきたシステムに潜む脆弱なロジックを特定するために、静的解析・動的解析を組み合わせて実施します。第三は、仕様書復元による技術継承です。PL/I を扱えるエンジニアの退職・高齢化が進むなか、属人的に保持されていた業務知識をドキュメント化し、次世代の担当者が保守できる状態にすることが目的となります。

PL/Iのリバースエンジニアリング 6 工程

PL/I のリバースエンジニアリングを成功させるためには、場当たり的な解析ではなく、体系化された工程に従って進めることが重要です。以下では、実際のプロジェクトで踏むべき 6 つの工程を詳しく解説します。

プロジェクト開始前に「何のためにリバースエンジニアリングを実施するか」を明確にすることが、工数と費用を大きく左右します。PL/I システムは、一つの基幹システムが数百から数千のプログラムモジュールで構成されることも珍しくなく、全量を解析するのか、特定の業務領域に絞るのかによって、期間と費用が数倍単位で変わります。また、最終的な成果物が「フローチャートレベルの処理概要」なのか、「新システム開発に直接使える詳細業務仕様書」なのかを最初に合意することで、後工程での手戻りを防ぐことができます。

対象選定では、JCL の JOB 定義から実行されるプログラム一覧を洗い出し、業務上の重要度と変更頻度に基づいて優先順位をつける手法が有効です。IMS/DB や VSAM のデータセット名とプログラムの対応関係をマトリクス化し、影響範囲を可視化することで、解析の起点となる「コアモジュール」を特定します。

PL/I の解析環境構築は、他のオープン系言語と比べて特殊な準備が必要です。IBM メインフレーム上でコンパイルされた PL/I プログラムは EBCDIC エンコーディングで記述されており、解析ツールやテキストエディタも EBCDIC 対応のものを選定する必要があります。ソースリスト（コンパイラが出力する詳細なリスティング）が存在する場合は最大限に活用し、変数の DCLS（宣言）セクションから全データ構造のマッピングを行うことが解析の基礎となります。

静的解析ツールとしては、IBM Rational Developer for z/OS や Micro Focus Enterprise Analyzer などのメインフレーム専用ツールが PL/I のコード構造解析に対応しています。一般的な Ghidra や IDA Pro はネイティブバイナリの解析には優れますが、PL/I の高水準構造体（STRUCTURE、UNION）やポインタ操作の意味論的解析は苦手なため、PL/I ソースコードが入手できる場合はソースベースの解析ツールを優先します。また、CICS のトランザクション定義や IMS/DB のセグメント定義など、ミドルウェアの設定ファイル類も合わせて収集しておくことが必須です。

静的解析では、プログラムを実行せずにソースコードまたはコンパイル済みバイナリを読み解きます。PL/I の静的解析で特に重要なのは、BASED 変数とポインタの追跡です。ALLOCATE 文と FREE 文の対応関係を全プログラム横断で追い、どのモジュールがどのデータ構造を生成・変更・破棄しているかをマッピングします。この作業は、データの所有者と生存期間を明確にするために不可欠であり、後の業務仕様書作成においてデータフロー図の基礎となります。

制御フロー分析では、PL/I の ON 条件（例外処理）に特別な注意が必要です。ONCODE 関数を使ったエラーハンドリングが複雑に入れ子になっているケースでは、通常の処理フローとは別に例外時の分岐を追跡しなければ、業務上の異常系処理を見落とすリスクがあります。また、CALL 文と ENTRY 文による複数エントリポイントを持つモジュールの存在も PL/I では一般的であり、これを見落とすと業務ロジックの一部が欠落した不完全な仕様書が生成されてしまいます。

動的解析では、実際にプログラムを実行しながら挙動を観察します。PL/I の動的解析はメインフレーム環境下での実施が前提となるため、z/OS 上での Xpediter（Compuware 製のデバッガ）や IBM Debug Tool を用いたトレースが主な手段です。本番環境での動的解析はリスクが高いため、通常はテスト環境（LPAR：論理パーティション）を用意し、本番と同一のデータ（マスキング処理済み）で実行トレースを取得します。

動的解析で特に価値が高いのは、CICS トランザクションの入力データと IMS/DB への書き込みデータの対応関係を実際のデータで確認できる点です。静的解析だけでは「このフィールドに何が入るか」が曖昧なケースでも、実行トレースによって業務上の実際の値が確認でき、計算ロジックの意味解釈の精度が飛躍的に向上します。また、特定の業務イベント（例：月次バッチ、年度更新処理）のみで発火する分岐条件は、静的解析だけでは発見が難しく、動的解析との組み合わせが必須です。

静的・動的解析で得られた情報を、実装レベルから設計レベル、さらに仕様（業務）レベルへと段階的に抽象化するのが Design Recovery です。PL/I の場合、この抽象化プロセスで最も困難なのは「コードが何をしているか（How）は分かるが、なぜそのような実装なのか（Why）が分からない」という問題です。たとえば、特定の計算ロジックが「業法上の規制に基づく特例計算」なのか「過去の障害対応で追加されたパッチ」なのかは、コードからは判断できません。

この問題を解決するには、業務部門の担当者や、当時の開発に関与した人材へのインタビューが不可欠です。解析チームが「このロジックの業務上の意味は何か」「この閾値はどの規定から来ているか」という質問リストを作成し、業務部門と定例の確認会議を設けることで、「Why」の部分を埋めていきます。この業務部門との協働なしに、新システム開発に使える精度の高い仕様書を完成させることは困難です。

解析と抽象化の結果をドキュメントとして整備します。成果物のレベルは、プロジェクト当初の目的設定に基づいて「フローチャート」「業務仕様書」「詳細設計書（画面遷移図・DB 設計含む）」の 3 段階に分類されます。フローチャートレベルは処理の概要を把握する用途に適し、費用・期間が最も短くなります。一方、詳細設計書レベルでは、VSAM ファイルや IMS/DB のセグメント定義をそのまま新システムの DB 設計に転換できるレベルまで情報を整備するため、費用・期間は大幅に増加しますが、新システム開発での手戻りを最小化できます。

成果物には、変数名の意味と役割、業務ルールの背景（Why）、例外処理の業務的意味合いを必ずコメントとして付記することを仕様に含めることを推奨します。機械的な解析だけで生成されたスパゲティコードのような成果物では、新システムの開発者が再び仕様を誤解するリスクがあり、結果として保守性の低いシステムが生まれてしまいます。

PL/I固有の注意点

PL/I には、他言語では見られない特有の技術的難所が複数存在します。これらを事前に把握しておかないと、解析工数が大幅に膨らんだり、重要な業務ロジックを見落としたりするリスクがあります。

PL/I のリバースエンジニアリングで最も多い失敗は、BASED 変数とポインタ操作の追跡漏れです。PL/I では、同一の BASED 変数が複数の異なる構造体を指すよう動的に切り替わるコーディングが珍しくなく、静的解析だけでは「このポインタが実行時にどの構造体を指しているか」が判断できません。この結果、業務上のデータ変換ロジックが不完全にしか復元されず、新システム移行後にデータ不整合が多発するケースがあります。

また、PL/I の AREA 属性（動的メモリプール）を使ったバッファ管理は、プログラム間で AREA を受け渡すことで大量データを効率的に処理しますが、この受け渡し構造を見落とすと、複数モジュールにまたがるデータフローの全体像が把握できなくなります。さらに、長年の運用のなかでパッチ適用によって追加された「暗黙的な業務ルール」（たとえば、特定の顧客コード範囲については計算方法が異なるといった条件）が散在するケースも多く、これをすべて文書化するには業務担当者との丁寧なヒアリングが不可欠です。

PL/I プログラムそのものへの難読化は一般的ではありませんが、メインフレーム固有の環境依存による難読化効果が問題になります。たとえば、IBM MACRO ライブラリを使ったアセンブラ呼び出しが PL/I コード内に混在している場合、そのアセンブラルーチンの動作仕様が失われていると、呼び出し元の PL/I コードの意味を正確に解釈できません。同様に、CICS の BMS（Basic Mapping Support）で定義された画面マップと PL/I プログラムの COMMAREA の対応関係が設計書なしでは追跡困難なケースがあります。

対処策として、IBM の公式マニュアル（IBM Knowledge Center）と合わせて、社内に残存するオペレーション手順書や運用マニュアルを総動員することが有効です。また、CICS の DFHCSDUP コマンドや IMS の DBD/PSB 定義からミドルウェア側の仕様を抽出し、プログラム解析の補助資料として活用することで、メインフレーム固有の「環境依存の謎」を一つずつ解消していく手法が実務では一般的です。

法的リスクの回避

PL/I のリバースエンジニアリングを実施する際には、著作権法・不正競争防止法・特許法など複数の法律への適合を事前に確認することが重要です。特に自社開発でないシステム（他社から導入したパッケージ等）を対象とする場合は、法的整理を慎重に行う必要があります。

クリーンルーム手法とは、解析チーム（Dirty Room）と開発チーム（Clean Room）を完全に分離し、開発チームは解析チームが作成した仕様書のみを基に新システムを開発する手法です。これにより、著作権侵害の要件である「依拠性」（元の著作物に依拠して作成したこと）を法的に否定できます。1980 年代のフェニックス・テクノロジーズ vs IBM BIOS 訴訟でこの手法の有効性が確立されており、現在も業界のスタンダードとして採用されています。

実務的なクリーンルーム運用では、解析チームと開発チームの間に「法務・仲介担当者」を配置し、仕様書に著作権で保護された「表現」が混入していないかを確認したうえで開発チームに渡します。セガ対アッコレード事件の教訓として、この法務フィルタリングのステップを省略すると、仕様書に元コードの「創作的表現」が残存し、著作権侵害と判断されるリスクがあります。外注先がこの手法を自社プロセスとして確立しているかどうかは、ベンダー選定時の重要な確認ポイントです。

平成 30 年の著作権法改正（第 30 条の 4）により、情報解析・システム開発・保守等の「非享受目的」であれば著作物をリバースエンジニアリングすることが原則合法化されました。ただし「非享受目的」であることを事後的に立証できる記録の残し方が重要です。具体的には、解析専用の隔離された PC または仮想環境を用意し、解析目的・対象・手順・結果をプロジェクト日報として記録します。解析過程で得たコードや仕様情報を業務目的以外に転用しないことを誓約する社内規程を整備し、プロジェクト参加者全員が署名することも有効な記録手段です。

外注 vs 内製の判断軸

PL/I のリバースエンジニアリングを内製で行うか外注するかは、社内の技術資源と人材状況によって大きく異なります。判断の基準となる主要な観点を整理します。

PL/I を扱えるエンジニアが社内に存在しない場合や、メインフレーム環境の運用経験が乏しい場合は、外注が現実的な選択肢です。PL/I エンジニアは COBOL エンジニアよりもさらに人材市場での流通量が少なく、即戦力となる人材を採用・育成するコストと時間を考えると、専門ベンダーへの外注が総コスト面でも有利です。また、クリーンルーム手法の法務プロセスを自社で構築・運用するのは体制面の負担が大きく、この点でも専門ベンダーの既存プロセスを活用することにメリットがあります。

ただし、外注先の選定には十分な注意が必要です。「メインフレーム対応」を謳っていても PL/I の実務経験がなく COBOL 中心の実績しかない会社、あるいは CICS や IMS/DB の連携部分を扱えない会社は少なくありません。依頼前に「PL/I のプロジェクト実績件数」「BASED 変数やポインタ操作の解析経験」「JCL・IMS/DB・CICS の連携解析実績」を具体的に確認することが重要です。

社内に PL/I の実務経験を持つシニアエンジニアが在籍しており、かつ対象システムの業務知識を保有している場合は、内製でのリバースエンジニアリングが有効に機能します。特に業務固有の複雑なビジネスルール（保険の特別料率計算や、規制対応のための特例処理など）は、業務知識のある内部担当者でなければ正確に意味解釈できない部分が多く、外注先の技術者がいから優秀でも業務意味の解釈は社内担当者の支援なしには難しいです。

現実的な落とし所として、「ソースコードの技術的解析・ドキュメント化は外注、業務意味の確認・補完は内部の業務部門が担当」というハイブリッド体制が多くの PL/I リバースエンジニアリングプロジェクトで採用されています。このハイブリッド体制を成立させるためには、外注先との定期レビュー会議の設計と、業務部門からの担当者のアサインを発注前に確定させておくことが成功の鍵となります。

まとめ

PL/I のリバースエンジニアリングは、COBOL 以上に専門性が求められる高難度の作業です。POINTER・BASED 変数・AREA 属性などの固有データ型、JCL・IMS/DB・VSAM・CICS との連携部分の解析、そして業務ロジックの「Why」を業務部門と協働で補完するプロセスが、成功の核心にあります。

6 つの工程（対象選定→環境準備→静的解析→動的解析→Design Recovery→成果物化）を体系的に踏み、クリーンルーム手法による法的リスク管理を並行して行うことで、保守性の高い設計書と新システム要件定義書を生み出すことができます。外注と内製の判断は、社内の PL/I 技術者の有無と業務知識の深さを基準に行い、多くの場合はハイブリッド体制が現実解となります。対応できるベンダー自体が極めて少ないこの領域だからこそ、信頼できる専門パートナーを早期に選定することが、プロジェクト全体の成否を左右する最初の重要な意思決定です。

▼全体ガイドの記事
・PL/Iのリバースエンジニアリングの完全ガイド

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

また「Boxシリーズ」による、受発注管理・在庫管理・配送管理・業務システム・生成AI・SaaS・マッチングサイト・EC・アプリ・LINEミニアプリなどの標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」を活用することで、低コスト・短期間でのスクラッチ開発を実現いたします。

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

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

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

執筆者プロフィール

張田谷凌央

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