AS/400（IBM i）のリプレースとモダナイゼーション｜維持・クラウド移行・近代化・置き換えの4つの戦略と、ERPへの移行先

IBM i（旧 AS/400）は、1988年に IBM が発表したミニコンピュータ系の統合 OS で、今も国内の中堅・大手企業で基幹システムの土台として使われています。製造業の生産管理、流通業の在庫・受注管理、金融業の勘定系周辺業務など、ミッションクリティカルな業務を 30〜40年に渡って支えてきました。

版ごとのサポート期限は、IBM の公式の表で確かめられます。2026年9月30日は IBM i 7.4 の標準サポートの最後の日で、10月1日からは延長サポート（Service Extension）の期間（2029年9月30日まで）に入ります。7.3 は同じ日で1回目の延長サポートが終わり、10月1日から2回目の延長（extended Service Extension、2028年9月30日まで）です。7.2 の延長は2026年4月30日で終わり、7.5・7.6 は標準サポートの終わる日がまだ発表されていません。IBM は、その日を12か月以上前に知らせるとしています（IBM Support「Release life cycle」、2026年9月30日確認）。延長サポートで何年延ばせるか、移すなら何から数えるかは、IBM i（AS/400）7.3・7.4のサポート期限の後にやることにまとめています。

移行先の選定を含むERP刷新全体の進め方はERP移行 完全ガイドで整理しています。

一方で、RPG / COBOL 開発者の高齢化、ハードウェア保守費の上昇、クラウド時代のオープン化要求から、IBM i の今後をどうするかは経営判断レベルの論点になっています。本記事では、IBM i とは何か、現在の選択肢、4つの戦略の使い分け、人材リスクへの対応、クラウド移行の具体的なオプション、そして失敗パターンまでを、論理ステップで整理していきます。

基幹システムの刷新で決める7つと、止める条件を動画で解説しています↓↓

1. IBM i / AS/400 とは — 統合 OS としての本質

IBM i は、サーバ・データベース・セキュリティ・ジョブ管理を OS レベルで統合した独自プラットフォームです。1988年に「AS/400」として発表されて以降、iSeries → System i → IBM i と名称変更を重ねながら、IBM Power Systems というハードウェア上で動作してきました。「Db2 for i がOSの一部として組み込まれている」「RPG / COBOL / CL での業務開発が標準」という独自設計により、極めて高い安定性と運用効率を実現しています。

とはいえ、Web / モバイル / クラウドネイティブな現代の業務環境とのギャップは年々広がっており、UI 改修・外部システム連携・分析基盤との接続のたびに、追加投資が必要になります。これが IBM i 利用企業の共通課題になっています。

この記事に関連するサービス

基幹システムの刷新・移行長く使ってきた基幹システムを、止めずに移行する。詳しく見る →システム保守の引継ぎ作った人がいない業務の仕組みを、中身を書き出してから引き継ぎます。詳しく見る →受発注・在庫管理システムの開発FAX・電話・Excelで受けている注文を、取引先がWebで入れる形に。詳しく見る →kintone 導入支援業務に合うアプリ設計から内製化まで伴走します。詳しく見る →勘定奉行クラウド 導入支援部門別管理と内部統制を、業務に合わせて設計する詳しく見る →

2. 現状 — 「捨てる」より「上手く付き合う」が IBM 公式の方針

IBM 自身が公式に打ち出している方針は、「IBM i を一掃する rip-and-replace ではなく、段階的に近代化する」です。理由は明確で、IBM i 上の業務ロジック（RPG / COBOL / CL）が業務に深く埋め込まれており、20〜30年の改修履歴が口承伝承で残っているからです。完全書き直しを試みた企業の多くが、3年プロジェクトで予算 3〜5倍超過、最後はオリジナルの IBM i に戻したという事例が業界には積み上がっています。

2026年現在の主流は、「コアの業務ロジックは IBM i に残し、周辺機能（API / UI / 分析 / AI）をクラウドで拡張する」ハイブリッド構成です。IBM 自身も IBM Power Virtual Server（IBM Cloud 上で動く IBM i）や Db2 Mirror for i を提供しており、オンプレ IBM i をクラウドへ持ち上げつつ、業務ロジックは温存する選択肢が整備されています。

3. IBM i 戦略の4分類 — Stay / Lift / Modernize / Replace

IBM i に対する戦略は、投資の重さで4分類できます。コアロジックの保守性とリスクの大きさで素直に選びます。

4. 戦略選定のフロー — 3つの質問で機械的に絞れます

4つの戦略のうち、自社にどれが合うかは、3つの質問で機械的に絞り込めます。「ハードウェア更新時期が近いか」「業務改革を並行で進めるか」「予算 5億円超 + 業務全体再設計の覚悟があるか」を順に答えていけば、自然と推奨される戦略が決まります（下図の判断フロー）。

5. RPG / COBOL 開発者の枯渇 — 「6〜12ヶ月で1人採用」が現状

IBM i の最大の経営リスクは、RPG / COBOL / CL の開発者が枯渇していることです。業界調査では、適任者の採用に 6〜12ヶ月かかるのが標準で、2025年以降は毎年約3,000人規模で COBOL 技術者が減少すると予測されています。COBOL 開発者の高齢化（平均年齢 55歳超）はよく語られますが、IBM i 専門の RPG 開発者の枯渇はそれよりさらに深刻、という指摘が近年増えています。

対策として現実的な選択肢は3つあります。1つ目は外部パートナー（インド・フィリピン・ベトナムの IBM i 専門 SI）の活用で、Programmers.io、ITconvergence、Maxis Technology などのオフショア企業がこの領域に強く、コスト効率も高めです。2つ目は AI 活用ツールで、トヨタシステムズと日本 IBM が共同開発した「TG4X」のように、生成 AI を使って COBOL / PL/I 経験のない人材でもコード理解・生成を支援する仕組みが登場しています。3つ目は業務ロジックの API 化 + フロント置換で、コア RPG コードは保守体制に依存しつつ、新規開発は API 経由で別言語で行う構成です。

6. クラウド移行（Lift）の3つの選択肢

IBM i のクラウド化を選ぶ場合、選択肢は3つに集約されます。それぞれ提供元と特徴が異なります。

IBM Power Virtual Server は時間単位課金で、Reserved Instance（1年・3年契約）で大幅な割引が利きます。IBM は、PowerVS を最大90日試せる USD 2,500 分のクレジット（PowerVS2500）も案内しています（IBM「IBM Power Virtual Server」、2026年9月30日確認）。Migrate While Active 機能を使えば、IBM i 本体を稼働させたまま、リモートのクラウド先にデータを転送できるため、業務停止を最小化した移行が可能です。

7. Modernize（近代化）の構成 — コア + 周辺の分離

Modernize 戦略を選ぶ場合の標準的な構成は、「コア業務ロジックは IBM i に残し、API 化レイヤを挟んで Web フロントとデータ分析基盤をクラウド側で構築する」ハイブリッドです。IBM i 上の RPG / COBOL プログラムを、IBM 純正の Integrated Web Services (IWS) や、サードパーティの Profound API、Looksoftware で REST API として公開し、Web フロントエンドは React / Vue で別途開発します（下図は標準的なハイブリッド構成）。

このアプローチの利点は、「コアロジックを書き直さないので、業務リスクが低い」ことです。一方、API 化と Web フロントの開発には、公開する処理と作り直す画面の数に応じた投資が必要です。

8. 分析・AI 統合 — Db2 for i のデータをクラウド DWH へ

IBM i の Db2 for i に蓄積されたデータを、クラウド DWH（BigQuery / Snowflake / Redshift）に同期して、BI / 機械学習で活用する構成も増えています。レプリケーションツール（IBM InfoSphere Data Replication、Qlik Replicate、HiT Software DBMoto 等）を使えば、ニアリアルタイムで Db2 → クラウド DWH に同期できます。

これにより、「IBM i の業務データを使った高度な分析・AI 予測」が可能になります。需要予測、在庫最適化、価格最適化など、IBM i 単体ではできなかった分析が、クラウド側で実装できます。コアの業務ロジックは IBM i に残しつつ、分析層だけ近代化するパスは、リスクと効果のバランスが取れた選択肢として中堅以上の企業で増えています。

9. Replace（完全置換）の判断軸 — 3条件が揃わないと失敗します

Replace（完全置換）を合理的に選べるのは限定的なケースです。次の3条件が揃った場合のみ、現実的な選択肢になります。

移行先の選択肢は、製造業なら SAP S/4HANA（大手）か NetSuite / Oracle Fusion（中堅）、流通・小売なら Microsoft Dynamics 365 か独自パッケージ、金融なら勘定系パッケージです。標準機能カバー率が 70% 未満なら、Replace は失敗確率が高いため、Modernize で当面の運用を確保しつつ、5〜10年スパンで段階的にリプレースする方が実務的です。

10. 失敗パターン — 「人材枯渇を放置」「Replace 一直線で頓挫」

IBM i 関連プロジェクトが失敗する典型は2つあります。

10-1. 人材枯渇を放置して、突然動けなくなる

最も多い失敗が、「RPG 開発者の高齢化を見て見ぬふりし、退職と同時にシステムが触れなくなる」パターンです。社内に RPG エンジニアが2〜3人しかおらず、平均年齢が60歳近い、という体制を放置すると、退職タイミングで一気にシステム改修が止まります。打開策は前述の3対策（オフショア活用、AI 活用ツール、API 化）を3〜5年スパンで段階実行することです。

10-2. Replace 一直線で予算3〜5倍超過、最終的に IBM i に戻る

もう1つの典型は、「経営判断で IBM i を全部捨てる」と決めるが、業務側の標準機能カバー率が低く、3年で予算 3〜5倍超過、最終的に IBM i に戻るパターンです。打開策は、Replace を決める前に必ず Modernize の選択肢を比較検討し、業務側の標準機能カバー率を実機で検証することです。「IBM i を捨てる」より「IBM i と上手く付き合う」方が、ROI が出る場合が多いのが現実です。

11. まとめ — 自社にとっての判断軸

IBM i / AS/400 の今後をどうするかは、ハードウェア更新時期、業務改革の意思、予算規模で機械的に絞れます。判断軸を整理すると次の通りです。

判断のコツは、「IBM i は捨てるべきレガシーではなく、上手く付き合うべき資産」として捉えることです。30〜40年積み上げた業務ロジックには、それ自体に競合優位性が含まれている場合が多く、無理に Replace すると競争力を失う可能性もあります。7.3・7.4 の延長サポートの期間に、どの業務を残し、どれを移すかを決める段取りは、IBM i（AS/400）7.3・7.4のサポート期限の後にやることで整理しています。