AS/400（IBM i）で 30 年蓄積されてきた RPG プログラム資産——数百～数千本のプログラムをどう扱うかが、移行プロジェクトの成否を分けます。最新版 RPG への近代化、オープン系言語（Java／C#／.NET など）への自動変換、パッケージ移行で資産を捨てる選択肢……それぞれに向き不向きがあります。本記事では、RPG 資産の現状把握、3 つのアプローチ比較、自動変換ツールの現実、段階移行 vs 一括移行の判断軸を整理します。
『RPG 資産、活かす？捨てる？変換する？』 25 年の経験で客観評価のお手伝いをします。 無料相談 ＞結論：RPG 移行は『資産整理』から始める
RPG 移行プロジェクトで最も重要なのは、移行手法の選定より 『社内の RPG 資産を客観的に把握する』 工程です。プログラム本数・行数・依存関係・Free-format 比率・実際に使われているコードの割合——これらを可視化しないまま移行を進めると、見積もりが大幅にズレ、後工程で予算オーバーになります。
| アプローチ | RPG 資産の扱い | 適合ケース |
|---|---|---|
| ① 最新版 RPG への近代化 | 活かす（Free-format RPG へ） | IBM i 継続を前提とし、保守性を上げたい |
| ② オープン系言語への自動変換 | 変換して活かす | IBM i から脱却し、オープン系・クラウド基盤に移行したい |
| ③ パッケージ移行 | 清算する | 業務改革を含めて抜本的に刷新したい |
補足：「RPG → COBOL 自動変換」という選択肢もありますが、レガシー言語からレガシー言語への移行となり 真のモダナイゼーションにはならない ため、本記事では主要アプローチには含めず、後述の補足セクションで限定的なユースケースを解説します。
RPG 資産の現状把握
RPG バージョンの分布
RPG には複数のバージョンがあり、移行コストに大きく影響します。
- RPG II（1970 年代～）：固定フォーマット、現在は IBM i では非推奨
- RPG III（1978 年～）：固定フォーマット、まだ多くの企業で使用中
- RPG IV / RPG ILE（1994 年～）：構造化プログラミング対応
- Free-format RPG（2001 年～）：現代的な文法、Java や C# の知識でも理解しやすい
古いバージョン（RPG II / III）の比率が高いほど、移行・変換コストが大きく なります。
プログラム本数の典型例（中堅企業）
業務規模・歴史により異なりますが、中堅企業（年商 50 億円規模）の典型的な AS/400 システムでは：
- RPG プログラム本数：500～3,000 本
- 総行数：10 万～100 万行
- 使用頻度別の内訳：頻繁に使う 30%、月次・年次のみ 50%、実は未使用 20% という分布
重要なのは 『実は未使用の 20%』。要件定義の段階でデッドコードを洗い出し、移行対象から除外することで、コスト削減と工数削減の両方が実現できます。
依存関係マップの作成
RPG プログラム間の呼び出し関係、データベース（DB2 for i）テーブルとの関係、ジョブネットの構造——これらを可視化する 依存関係マップ が、移行プロジェクトの設計図になります。属人化で『誰も全体像を知らない』状態では、移行の正確な見積もりは不可能です。
RPG 移行の『3 つのアプローチ』
アプローチ 1：最新版 RPG（Free-format RPG）への近代化
IBM i を継続する前提で、RPG II/III/IV のコードを Free-format RPG へ書き換える 近代化。新人エンジニアでも理解しやすい現代的な文法に整理し、保守性を上げる。
| メリット | RPG 資産を完全に維持／IBM i 継続前提で投資効率良し／業務影響なし |
|---|---|
| デメリット | IBM i ロックインが続く／RPG 技術者問題は完全には解決しない |
| 費用／期間 | 500 万～2,000 万円／6～12 ヶ月 |
アプローチ 2：オープン系言語（Java／C#／.NET 等）への自動変換
RPG プログラムを オープン系言語（Java／C#／.NET／TypeScript 等） に自動変換。AS/400 から脱却し、Linux・Windows・クラウド基盤など自由なインフラ上で稼働でき、長期的な技術者確保も容易になります。
| メリット | 最新技術スタックへ／オープン系言語の技術者市場は厚い／クラウドネイティブへの進化が可能／インフラの選択肢が広い |
|---|---|
| デメリット | 変換後のコードが機械翻訳的になりがち（オブジェクト指向設計でない）／RPG 固有機能（サブファイル・データキュー等）の再現困難／追加リファクタリングが必要 |
| 費用／期間 | 5,000 万～1.5 億円／15～24 ヶ月 |
移行先言語の選び方：社内・委託先の人材構成、既存周辺システムの言語、クラウド戦略で判断します。Web／業務系の主流は Java、Windows／Microsoft 365 連携や C# 資産がある企業は C#／.NET、Web フロント連携重視なら TypeScript／Node.js など、自社環境に合致する言語を選ぶのが現実的です。
アプローチ 3：パッケージ移行で RPG 資産を清算
RPG 資産を 『負債』として捨てる 判断。業界特化型 ERP パッケージへ全面移行し、業務をパッケージ標準に合わせる。
| メリット | 業務改革効果が大／長期的な TCO 最適化／中堅企業に最も向く |
|---|---|
| デメリット | 30 年蓄積した独自仕様を捨てる／業務をパッケージに合わせる労力 |
| 費用／期間 | 3,000 万～8,000 万円／12～18 ヶ月 |
補足：RPG → COBOL 変換という選択肢
業界では「RPG → COBOL 自動変換」がアプローチの一つとして語られることがあります。しかし、本記事では 主要アプローチには含めていません。理由を整理します。
| 論点 | 評価 |
|---|---|
| 言語の世代 | RPG（1959 年）も COBOL（1959 年）も同世代のレガシー言語。レガシー言語 → レガシー言語の移行となり、モダナイゼーションの本質から外れる |
| 技術者市場の長期見通し | COBOL 技術者も高齢化が進行中。5～10 年後にまた移行が必要になる可能性が高い |
| RPG 固有機能の再現 | サブファイル・データキュー等は COBOL に直接対応する概念がない（オープン系言語と同じ課題が残る） |
| 段階戦略としての価値 | 「COBOL を経由して将来オープン系へ」では二度手間。最初からオープン系言語に移行する方が経済合理性が高いケースが多い |
ただし、限定的なユースケース では COBOL 変換が選択肢になります。社内・グループ会社で COBOL 資産が大量に稼働しており言語を揃えたい場合、IBM z/OS メインフレームへの統合計画がある場合、AS/400 ハードウェア層だけを当面変えたい場合などです。中堅企業の典型的なオフコン移行プロジェクトでは、これらの状況に該当しないケースの方が多いため、本記事では補足扱いとしました。
自動変換ツールの『現実』
RPG → オープン系言語（Java／C#／.NET 等）の自動変換ツールは複数存在し、ベンダーは『100% 変換可』と主張するケースがあります。しかし、現実は次のとおりです。
現実 1：変換できても保守困難
自動変換は『動くコード』を生成しますが、『人間が読める／保守できるコード』ではない ケースが大半。変数名・関数名・ロジック構造が RPG 由来で、変換先言語の自然な書き方になりません。これを『機械翻訳的コード』と呼びます。
現実 2：RPG 固有機能の再現に課題
RPG にはサブファイル、データキュー、レコードロックなど、オープン系言語に直接対応する概念がない機能 があります。これらは個別のフレームワーク・ライブラリで再実装が必要で、変換後の保守性が下がります。
現実 3：追加リファクタリングが必要
変換後のコードを長期的に活用するには、追加でリファクタリング（コード整理・命名規則統一・モジュール構造再設計）が必要。これに自動変換と同等以上の工数がかかるケースも珍しくありません。
現実 4：『100% 自動変換』は基本ありえない
業務固有の例外処理、デッドコード、ベンダー独自拡張など、手動対応が必要な部分が必ず残ります。プロジェクトの予算・期間には、自動変換工数だけでなく『手動対応・テスト・リファクタリング』を必ず織り込んでください。
段階移行 vs 一括移行
段階移行の特徴
| 進め方 | 会計→販売管理→生産管理 のように業務領域単位で順次移行 |
|---|---|
| メリット | 各フェーズの稼働が早い／リスク分散／現場の混乱が少ない |
| デメリット | 総期間が長い（18～30 ヶ月）／旧システムと新システムの並行運用期間が長い |
| 適合ケース | 本業へのインパクトを最小化したい中堅企業 |
一括移行の特徴
| 進め方 | 全業務領域を一度に切り替え |
|---|---|
| メリット | 総期間が短い（12～18 ヶ月）／並行運用コストが少ない |
| デメリット | 失敗時の影響範囲が大／現場の混乱リスク／要件定義のスコープが膨大 |
| 適合ケース | 大規模・体力のある企業／業務領域間の連携が密で分割困難な場合 |
中堅企業では、段階移行の方が成功率が高い ケースが多くなっています。リスク分散と現場負荷の観点から、段階移行を第一選択肢として検討してください。
RPG 移行の『よくある失敗』
失敗 1：自動変換を過信
ベンダーの『100% 自動変換可』という説明を鵜呑みにし、変換後のリファクタリング工数を見積もり忘れる失敗。『変換工数＋リファクタリング工数＋テスト工数』を必ず別建てで予算化 してください。
失敗 2：RPG 資産の調査を後回し
プログラム本数・行数・依存関係を把握せずにベンダー選定を進めると、提案書の見積もり前提が曖昧になり、後で大幅な追加費用が発生。要件定義の最初の 1～2 ヶ月で資産棚卸し を完了させてください。
失敗 3：デッドコードを移行
実際は使われていないプログラムを『動いているから』という理由で全部移行対象にすると、無駄な工数・コストが発生。使用頻度の調査 を移行設計の段階で行い、デッドコードを除外する経営判断が必要です。
失敗 4：RPG 技術者がいるうちに動かない
社内 RPG 技術者の退職を待ってから動き始めると、業務知識の継承ができず、移行プロジェクトが極度に困難になります。技術者在籍中に資産棚卸しと業務ロジック文書化 を完了させることが、移行成功の絶対条件です。
RPG 移行の本質は『資産の価値判断』
RPG 移行プロジェクトの成否は、変換技術ではなく 『RPG 資産の価値を客観評価できるか』 にあります。30 年の蓄積を『資産』と見るか『負債』と見るか、競争力に直結する業務独自性は何割か、デッドコードはどれだけあるか——これらを経営判断のフレームで整理することが、3 アプローチの選定の出発点です。
株式会社クオンツでは、『RPG 資産の客観評価』『3 アプローチの経済合理性比較』『自動変換ツールの妥当性検証』『段階移行設計』 のご相談を、無料で受け付けています。汎用機・オフコンからオープン系・クラウド基盤への移行プロジェクトに 25 年携わってきた経験から、貴社の業務・人材・予算に合わせた現実解を一緒に整理します。机上のコンサルではなく、お客様の現場と並走するスタイルで、次の一歩の選択肢を整理します。
