LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

IBM i(AS/400)刷新が急がれる理由——保守要員の高齢化とハード保守期限

IBM i(旧称AS/400、その後iSeries、System iと呼ばれた時期を経て現在の名称に至るIBM Power Systems上の基幹プラットフォーム)は、RPG(RPGⅢ・RPG Ⅳ・フリーフォーマットRPGという複数世代の文法が混在しやすい言語)とDB2 for i(OSに統合されたリレーショナルデータベース)、5250画面(緑と黒の文字ベース端末に代表される入出力方式)、CLプログラム(ジョブ制御を担う言語)、そしてライブラリ体系(QSYSを中心にオブジェクトを管理する独自の構造)が一体化した環境です。数十年にわたり基幹業務を支えてきた企業は少なくありません。

刷新を後回しにしにくい背景には、ハードウェアとOSの保守期限が重なっている事情があります。IBM Power9世代のスケールアウト機は2026年1月31日にEnd of Standard Serviceを迎え、以降は予防保守や新規のファームウェア更新が受けられなくなります^*1。またIBM iのOS側でも、7.3は2023年9月末にサポートが終了しており、7.4は2026年9月末にStandard SupportからService Extension(有償・限定的な支援)へ移行する予定です^*2*3。Service Extensionが提供されるのは2029年9月末までで、新規のテクノロジー・リフレッシュは提供されなくなります^*3。

こうしたハード・OSの期限に加えて、RPGやCLを長年保守してきた担当者の退職・高齢化が進んでいる企業も多いのが実情です。IPAが2025年2月から3月にかけて日本企業1,535社を対象に実施した「DX動向2025」調査では、「レガシーシステムはない」と回答した企業は20.0%にとどまり、8割の企業が何らかの形でレガシーシステムを抱えていると回答しています^*4。経済産業省とデジタル庁が参画する「レガシーシステムモダン化委員会」が2025年5月28日に公表した総括レポートでも、ユーザー企業の61%にレガシーシステムが残存していると指摘されました^*5。IBM iはこうした調査対象の一部を占めるプラットフォームであり、決して例外ではありません。

選択肢A：IBM i上でのモダナイズ——RPGフリーフォーマット化とAPI/Web化

1つ目の選択肢は、IBM i自体は維持しながら、画面や外部連携の部分を刷新するモダナイズです。5250画面をブラウザベースのGUIに置き換える、あるいはRPGのビジネスロジックをAPIとして外部に公開し、モバイル端末や他システムから呼び出せるようにする手法が代表的です^*6。IBM自身もRedbookの中で、業務ロジックをAPIとして提供する具体的な手順を整理しています^*6。

コードの書き換えとしては、固定形式で書かれた旧世代のRPGを、可読性の高いフリーフォーマットRPGへ変換する取り組みが挙げられます。IBMはこうした技術転換や、Gitベースのソース管理・CI/CDパイプラインへの統合をモダナイズの要素としてドキュメント化しています^*7。既存のDB2 for iやビジネスロジックはそのまま活用できるため、業務要件をゼロから再定義する必要がない点が、この選択肢の大きな利点です。

一方で、この選択肢を選んでもIBM i本体のハード・OS保守期限という制約は残ります。7.4を使い続けている場合は7.5または7.6への更新が別途必要になりますし、Power9世代のハードを使っている場合は機種更新も検討事項になります^*1*3。またRPGを保守できる技術者は依然として必要であり、モダナイズしたからといって人材面の課題が消えるわけではありません。

選択肢B：オープン系・クラウドへのリホスト/リライト

2つ目の選択肢は、IBM iから離れ、オープン系サーバーやクラウド環境へ移行する方法です。大きく2つのアプローチに分かれます。1つはリホストで、既存のRPGロジックを変換ツールなどで別言語(JavaやC#など)へ機械的に載せ替え、業務仕様そのものは大きく変えずに実行環境を移す手法です。もう1つはリライトで、業務要件を棚卸したうえでゼロから設計・実装し直す手法です。

DB2 for iに格納されているデータは、PostgreSQLなどのオープン系データベースやクラウドのマネージドDBへ移行することになります。5250画面についても、Webブラウザやスマートデバイスで操作できるUIへ全面的に再設計する場面が多くなります。既存のCLプログラムが担っていたジョブ制御やバッチ処理の仕組みも、クラウド側のスケジューラーやワークフローエンジンへ置き換える設計が必要です。

リホスト・リライトのいずれも、変換後のコードの保守性や、長年の改修で仕様書が失われた業務ロジックの解読に工数がかかりやすい移行です。テスト範囲も広くなりやすく、選択肢Aと比べて投資規模とリスクは大きくなる傾向があります。それだけに、移行後の運用体制まで見据えた計画が欠かせません。

選択肢C：パッケージ・SaaSへの移行——3つの選択肢の比較

3つ目の選択肢は、独自開発の基幹システムをやめ、ERPパッケージや業務SaaSに置き換える方法です。会計・人事・在庫管理など、業務プロセスの標準化が進んでいる領域では、パッケージの標準機能に合わせて自社の業務を見直す(Fit to Standard)ことで、開発規模を抑えながら刷新できます。

反対に、独自の生産管理ロジックや複雑な受発注ルールがRPGに深く組み込まれている場合は、標準機能だけでは業務を再現できず、大量のアドオン開発が必要になることも少なくありません。この場合はパッケージ導入のメリットが薄れ、選択肢AやBのほうが現実的な場合もあるでしょう。データ移行の面では、DB2 for i上のマスターデータやトランザクション履歴を、パッケージ側のデータモデルに合わせて変換する作業も欠かせません。

ここまでの3つの選択肢を整理すると、次のように比較できます。

外注時に確認すべき勘所——資産棚卸し・ブラックボックス化解消・RPG技術者確保

どの選択肢を採るにせよ、最初に取り組むべきは資産の棚卸しです。プログラムの本数、プログラム間の呼び出し関係、CLプログラムが制御しているジョブの流れ、ライブラリ構成をあらかじめ可視化しておくことが、移行工数を見積もる前提になります。棚卸しを省いたまま概算だけで契約を進めると、着手後に想定外の依存関係が見つかり、スケジュールが崩れやすくなります。

次に見落とされやすいのが、業務ロジックのブラックボックス化です。長年の改修を経たRPGプログラムでは、仕様書が更新されておらず、変更の経緯を知っているのが退職済みの担当者だけというケースも珍しくありません。こうした状態では、外注先にコードを読み解いてもらうリバースエンジニアリングの工数を、あらかじめ見積りに含めておく必要があります。

加えて、RPG・CLを扱える技術者の確保そのものが難しくなっている点も踏まえておきたいところです。育成の機会が減っている状況で、移行プロジェクトのためだけに新たな技術者を自社で確保するのは容易ではありません。既存資産を読み解けるパートナーを選ぶことが、実務的には近道になりやすいでしょう。委託形態についても、元請（プライムベンダー）として一括で管理する体制なのか、複数の会社に分割発注する多重下請け構造になるのかを、契約前に確認しておくことが望まれます。

委託先の選び方——IBM i実績・移行手法・体制の3軸

委託先を選ぶ際、最初の着眼点はIBM i(AS/400)固有の実績の有無です。RPG・CL・DB2 for i・5250画面といった要素を実際に読み解いた経験があるかどうかで、棚卸しの精度も変わってきます。汎用的なレガシーマイグレーションの実績だけでは、IBM i特有のライブラリ体系やジョブ制御の勘所を見落とすおそれがあります。

次に、移行手法の説明力です。選択肢A・B・Cのどれを推奨するのか、その根拠を業務要件と紐づけて示せるかどうかを見ます。単一の手法だけを提案してくる委託先より、複数の選択肢を比較したうえで自社の状況に合わせた案を出せる委託先のほうが、判断材料としては信頼しやすいものです。

最後に体制です。要件定義から移行後の運用保守まで、一貫して対応できる体制かどうかを確認します。移行対象のプログラム規模やライブラリ構成、既存ドキュメントの整備状況によって、必要な工数は大きく変わってきます。まずは現状の資産を診断したうえで、選択肢を絞り込んでいくことが実務的な進め方です。

まとめ：IBM i刷新・移行で押さえる3つの判断軸

本稿ではIBM i(AS/400)の刷新・移行について、公式情報をもとに選択肢と外注時の勘所を整理しました。要点は3つに集約できます。第一に、Power9のハード保守終了(2026年1月末)やIBM i 7.4のサービス移行(2026年9月末)といった期限が重なり、判断を先送りしにくい状況にあります^*1*3。第二に、移行の選択肢はIBM i上でのモダナイズ、オープン系・クラウドへのリホスト/リライト、パッケージ・SaaSへの移行という3系統に大別され、既存資産の活用度と業務の標準化しやすさによって向き不向きが分かれる点です。第三に、資産棚卸しとブラックボックス化の解消、RPG技術者の確保という体制面の課題が、内製と外注を分ける実務的な判断材料になります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：IBM Community「Power 9 reminder: End of Standard Service is 31 January 2026」（https://community.ibm.com/community/user/discussion/power-9-reminder-end-of-standard-service-is-31-january-2026-1）
2. *2　出典：endoflife.date「IBM i」（IBM公式のサポート終了日を集計したリファレンス）（https://endoflife.date/ibm-i）
3. *3　出典：IT Jungle「And Then There Were Two: Big Blue Withdraws IBM i 7.4」（2025年9月22日、IBM Announcement Letter AD25-0894に基づく報道）（https://www.itjungle.com/2025/09/22/and-then-there-were-two-big-blue-withdraws-ibm-i-7-4/）
4. *4　出典：IPA(独立行政法人情報処理推進機構)「DX動向2025」（2025年6月26日公表、2025年2〜3月に日本企業1,535社を対象に実施した調査）（https://www.ipa.go.jp/digital/chousa/dx-trend/dx-trend-2025.html）
5. *5　出典：デジタル庁ニュース「企業のDXを阻む『レガシーシステム』とは？」（経済産業省・デジタル庁「レガシーシステムモダン化委員会総括レポート」2025年5月28日公表分の紹介記事）（https://digital-agency-news.digital.go.jp/articles/2025-08-27-1）
6. *6　出典：IBM Redbooks「RPG: APIs」（REDP-4324）
7. *7　出典：IBM Redbooks「Introducing IBM i Modernization Engine for Lifecycle Integration」（SG24-8583）（https://www.redbooks.ibm.com/abstracts/sg248583.html）

Tweet