AS/400（IBM i）サポート終了で考える2層ERPでの運用について

サポート終了を「IBM iを捨てる期限」と捉えるのではなく、基幹システムの役割を再設計する機会と捉えるべきです。ここでは5つのポイントを提示します。

• IBM i 7.3への対応は当面の課題ですが、OS、ミドルウェア、アプリケーションには個別のライフサイクルがあります。特定バージョンを更新しても、次々と更新期限はやってきます。
•  
• 古いバージョンを放置すると、セキュリティアップデートを受けられなくなり、障害時の支援や内部統制にも影響します。サポート終了対応では、技術的な延命と業務運用の硬直化を同時に見直す必要があります。
•  
• OSアップグレードやインフラのクラウド移行だけ真正面から取り組むだけでは、古い入力画面、データ連携の難しさ、テレワーク非対応などの不満も残ったままです。次のEOSのタイミングでも同じ議論になる可能性があります。
•  
• 2層ERPでは、IBM iを会計、在庫、マスタなどの正本を管理するバックエンドとして残し、入力、承認、分析、モバイル利用をクラウド側で担います。基幹ロジックを守りながら、現場が使う機能を継続的に更新できます。
•  
• 成功の鍵は、業務をどちらの層で回すか、データの正本をどこに置くか、同期ルールを誰が管理するかを明確にすることです。
•  

以下では、IBM iを取り巻く現状の整理から、他選択肢との比較、2層ERPの役割分担、具体的な運用設計、そして立ち上げ手順までを順に見ていきましょう。

まずは、検討の前提となるIBM iのサポート状況とライフサイクルについて整理します。

IBM iとAS/400の呼び方の違い

議論を進める上で、言葉の定義を整理しておくことが重要です。かつてAS/400として親しまれた製品ラインは、2000年にeServer iSeriesへ再ブランドされ、新規製品では「AS/400」ブランドは使われなくなりました。現在は、ハードウェアとしてのIBM Power、OSとしてのIBM i、およびその上で稼働する基幹アプリケーションの3つの階層に分けて理解する必要があります。

 

2層ERPを検討する際は、これらの階層のうち、どの部分を資産として残し、どの部分をクラウド化するかを明確に区別して議論することが求められます。

サポート終了は今後も繰り返される

IBM公式のリリースライフサイクルによると、IBM i 7.3の標準サポートは2023年9月30日に終了しています。最初のService Extensionは2023年10月1日〜2026年9月30日、extended Service Extensionは2026年10月1日〜2028年9月30日まで利用可能です。「2026年9月30日」は最初の延長サポートの区切りであり、その後も有償延長は選べますが延命コストは上がります。（出典：IBM「Release life cycle」）

 

ハードウェア側では、一部のIBM Power9モデルについて、標準保守終了（End of Standard Service）が2026年1月31日と発表されています。対象は機種ごとに異なるため、自社のマシンタイプ／モデル確認が必要です。（出典：IBM「Important Notice: Upcoming Changes to Power9 Maintenance Services」）

 

IBM Service Extension（有償延長保守）は、製品の標準サポート期間終了後も、追加料金を支払うことでセキュリティ修正や技術サポートを継続できるプログラムですが、一時的な猶予期間を確保するための手段にすぎません。新規パッチが適用されない未対応のシステムを稼働させ続けることは、企業のセキュリティリスクや内部統制上のリスクを増大させる恐れがあります。

 

また、重要な点は、今回の7.3対応を無事に終えたとしても、将来的に7.4や7.5といった後続バージョンでも同様のサポート終了が必ず訪れるということです。基幹パッケージや連携するミドルウェアについても、ライフサイクルに伴う保守期限は必ず到来します。目の前の移行プロジェクトを一度限りのイベントとして終わらせるのではなく、EOSが定期的に発生することを前提とした、中長期的な運用体制の構築が必要です。

 

詳細な日付確認は以下を参照してください。

• IBMハードウェア製品のサポート終了日の調べ方
• IBMソフトウェア製品の基本サポート満了日の調べ方
• IBM i 各リリースのライフサイクル一覧

サポート終了への対応策は、大きく分けて以下の3つの選択肢があります。それぞれの投資規模、導入期間、日常運用への影響を比較して検討する必要があります。

OSアップグレード／延長保守（延命策）

現在の環境を維持しながら、OSのバージョンアップや有償の延長保守を適用するアプローチです。当面のシステムセキュリティは確保しやすいものの、5250エミュレータによる操作性の悪さ、他システムとのデータ連携の難しさ、外出先や自宅からの業務が行えないこと、といった課題は解決されません。次のEOSの時期が来れば、再度同様の検討と投資を迫られることになります。

クラウドリフトまたは全面ERP移行

インフラ環境をクラウド（IBM Power Virtual Serverなど）へ移設するか、あるいはパッケージ製品やSaaSを用いて基幹システム自体を全面的に刷新する手法です。基盤を一新できる一方で、膨大なコストと数年規模の移行期間を要します。要件整理や現行業務との適合性検証、新旧システムを並行稼働させる際の現場の負担は極めて大きいうえ、移行先のシステムのEOSからも逃れられません。

2層ERPでの運用

実績があり安定して動作しているIBM iをバックエンドのデータ蓄積・処理基盤として維持し、ユーザーが直接触れるフロント業務のみをクラウドで刷新する現実的なアプローチです。

IBM iは、正確な処理、長年の業務ロジック、安定稼働に強みがあります。一方、古い画面、連携方法、人材不足が課題になりやすい傾向があります。クラウドは、Web画面、モバイル利用、API連携、素早い改修に向きます。両者を役割分担させる考え方が2層ERPです。戦略の全体像はポストモダンERP（2層ERP）の考え方と進め方、低コストな段階移行はレガシー基幹を捨てずにクラウド化する方法も参考になります。

2層ERPを実務で機能させるためには、バックエンドとフロントエンドの役割分担を明確に設計することが不可欠です。システムの信頼性の要となる以下のような業務や役割は、IBM i（バックエンド）側に配置します。

 

1. 会計および在庫の確定データ処理
2. 取引先や品目などのマスタデータの正本管理
3. 一括処理を行う夜間バッチ業務
4. 監査や内部統制に対応するための変更履歴（ログ）の保持

•  

業務の柔軟性や即時性が求められる領域は、クラウド（フロントエンド）側に移行します。

 

1. 各種データの入力画面および承認ワークフロー
2. 外出先や倉庫からのモバイル端末による受発注・在庫照会
3. 経営ダッシュボードや、各部門でのデータ集計・分析機能

日常の運用イメージ

実際の日々の運用では、以下のようなサイクルでデータを連携することになります。

 

• 朝：IBM iからクラウド側へ、最新の顧客マスタや品目マスタを同期します。
•  
• 日中：現場の従業員はクラウド側の使いやすい画面から受注入力や経費申請を行い、ワークフローに沿って承認処理を進めます。
•  
• 夕方：クラウド側で確定したその日のトランザクションデータを、APIやCSV連携を通じてIBM i側へ書き戻し、一括処理を行います。
•  

例えば、NTTデータビジネスブレインズのSlopebaseのようなクラウド統合管理基盤を活用することで、販売、購買、経費、在庫、生産といったERP周辺（財務・管理会計とHCMを除く）のデータをクラウド上で統合管理し、IBM iとセキュアにデータ連携を行うスマートな2層構成を柔軟に構築できます。

 

IBM iを会計・在庫の正本として残しつつ、入力・承認・照会だけをクラウド側へ切り出したい場合は、レガシーを捨てない拡張アプローチと運用イメージを先に確認しておくと、社内説明の材料が揃います。

フロントに出す業務の選び方

クラウド側に向く業務は、外出先や自宅から使いたい入力・承認、画面改修が多い業務、複数部門が参照する集計・分析です。

受注入力、経費申請、購買申請、見積承認、在庫照会などの業務が該当するでしょう。利用者が多く、操作時間や転記作業を減らせる業務から始めると、導入効果を説明しやすくなります。

バックエンドに残す業務の選び方

一方、IBM i側に残す業務は、会計の正本、在庫の確定処理、締め処理、複雑な原価計算、長年使われている個別ロジックです。

障害時の影響が大きい処理や、変更頻度が低く安定性を優先する処理もバックエンドに向きます。クラウド化できるかではなく、移す効果が移行リスクを上回るかで判断しましょう。

2層ERPの仕組みを安定して継続運用するためには、情報システム部門と各業務の管理職が、事前に以下の5つの論点について合意を形成しておく必要があります。

データの正本の定義

同一のデータが双方のシステムに存在する場合、どちらを、信頼できる唯一のデータ（正本）とするかを明確にします。データに矛盾が生じた際の優先ルールをあらかじめ策定しておきます。

同期の頻度とデータ連携方式

リアルタイム性が要求される業務（例えば急を要する在庫引き当てなど）にはAPI連携を採用し、日次や月次の処理で足りる業務には夜間バッチやCSV連携を用いるなど、業務特性に応じた使い分けをルール化します。API連携の進め方はノーコードで始めるAPIデータ連携も参考になります。

エラー発生時のリカバリー手順

ネットワークの遮断などによって連携エラーが発生した際、手動で再送するのか、あるいはシステムが自動リトライを行うのかを決めます。エラーを検知した際の管理者への通知フローや、業務を止めないための暫定的な代替運用ルールを明確にしておきます。

アクセス権限の管理と変更監査

クラウド側でのユーザーの承認権限の付与ルール、IBM i側におけるアクセスログの保存方法など、セキュリティと内部統制の基準を満たすための責任分担を定義します。

二系統のシステム変更管理ルール

変更要望に対して迅速に対応すべきフロントエンド（クラウド側）と、安定稼働を重視して計画的にパッチ適用や改修を行うべきバックエンド（IBM i側）で、開発・検証・本番適用の承認フローを切り分けて運用します。

 

これらの論点を曖昧にしたまま連携ツールだけを導入すると、現場での二重入力の発生や、データの不整合による業務の混乱を招く原因となります。技術構成より先に運用責任を決めることが大切です。部門乱立とレガシーのつなぎ方は、データ連携とレガシー対策のアプローチも確認すると整理しやすいです。

 

IBM iとクラウドの間で正本・同期・エラー復旧のルールを先に固めたいなら、分散データの連携イメージとスモールスタートの進め方を把握しておくと、検討会議と社内説明が早く進みます

2層ERPの運用を円滑に立ち上げるためのアプローチを、3つのステップに分けて説明します。

ステップ1：業務の棚卸しとサポート期限の一覧化

現在IBM iだけで行っている業務をすべて洗い出し、クラウド化することで効果が出やすい業務を候補として選定します。例えば、受注入力や経費精算などが該当するでしょう。同時に、現在利用しているOS、基幹パッケージ、ミドルウェアのサポート期限を整理したIT資産台帳を作成し、中長期的なEOSのスケジュールを見える化します。

ステップ2：クラウド側でのパイロット運用開始

対象業務とシステム構成を定義したら、まずは特定の部門や限定した拠点でスモールスタートによるパイロット運用を実施します。実際の使い勝提示を確かめながら、クラウド側の画面デザインやワークフローの調整を行います。

ステップ3：連携ルールとガバナンスの確立

パイロット運用で得られた知見を基に、APIやCSVによる連携処理、エラー発生時の対応手順、および本格運用に向けたガバナンスルールを固めます。

 

OSのアップグレード計画と2層ERPの導入は、ひとつのロードマップに組み込んで進めます。これにより、目の前の7.3サポート終了対応を単なる延命作業で終わらせず、将来のバージョンアップや周辺システムのEOSにも動じない、強固な運用体制へと発展させることができます。手順はデータを捨てずに移行する現実的な3ステップを参考にしてください。

ここでは、2層ERPの運用を確立した従業員約200名の中堅製造業C社を、想定事例として整理します。特定企業の実績ではありません。

【導入前の課題】

C社では、IBM i 7.3上で動作する独自の受発注・在庫管理システムを15年以上にわたり利用してきました。7.3のサポート終了期限が迫る中、全面移行を検討したものの、見積もりは数億円規模に達し、経営陣の承認が得られず対応が難航していました。一方、現場では、外出先から在庫の確認ができず、営業担当者は毎回、電話で倉庫や内勤担当者に問い合わせる必要がありました。さらに、画面の文言を変更するだけでも高額な改修費用と長い開発期間が必要となるため、現場の使いやすさは長年二の次にされていました。

【導入後の効果と日常運用】

C社は、IBM iを会計と在庫データの正本として残し、受注入力と承認ワークフローをクラウド側で行う2層ERPモデルを採用しました。

 

• 営業部門責任者の声
  「外出先からスマートフォンやPCでリアルタイムに在庫状況を確認できるようになり、その場で受注登録まで完了できるようになりました。営業活動のスピードが劇的に向上し、内勤アシスタントの電話応対の負担も大幅に軽減されています」
•  
• 情報システム担当者の声
  「全面移行と比べて投資額を抑えつつ、OSのバージョンアッププロジェクトとフロントの刷新を並行して進めることができました。日常のデータ連携では、夕方にクラウドの確定データをCSV形式でIBM iへ書き戻しています。万が一データ連携でエラーが起きた際には、営業の責任者とあらかじめ取り決めた手順に従い、情シス側で速やかに手動再処理を行うルールを整備しているため、現場が混乱することはありません」
•  

C社は、マスタの正本をIBM i上で管理し、入力や参照を行う画面はクラウドに任せるという明確な設計思想のもと、低コストで安全なIT環境への移行を達成しました。

Q. IBM i 7.3のサポート終了後も、今後サポート終了は起きますか。

はい。OS、ハードウェア、基幹パッケージ、ミドルウェアには個別のライフサイクルがあり、将来も更新対応が必要です。7.3はextended Service Extension（〜2028年9月30日）もありますが延命コストは上がるため、次のEOSを前提にした運用設計が本筋です。

Q. 2層ERPとは何ですか。IBM iを残したまま運用できますか。

IBM iをバックエンドとして残し、入力、承認、分析などをクラウドで担う運用モデルです。全面移行より投資と期間を抑えつつ、現場の使い勝手を改善できます。

Q. サポート終了対応と2層ERP導入は同時に進められますか。

進められます。OS更新で安全性を確保しながら、効果が見えやすい業務からクラウド化します。

Q. 2層ERPではデータの正本はどちらに置くべきですか。

データごとに決めます。会計や在庫の確定値はIBM i、申請途中のデータはクラウドとする設計が一般的です。矛盾時の優先ルールを文書化してください。

Q. IBM iとクラウドの連携はAPIとCSVのどちらを使うべきですか。

即時性や件数が重要ならAPI、日次処理や小規模な開始ならCSVが選択肢です。復旧方法も含めて判断し、最初からすべてリアルタイム化する必要はありません。

Q. 2層ERP運用と全面ERP移行の違いは何ですか。

2層ERPは既存基幹を残して段階的に改善します。全面ERP移行は基幹機能とデータを新環境へまとめて移します。後者は効果大きいですが、負荷も大きくなります。

読者が本当に求めているのは終了日の知識ではなく、次の到達点です。IBM i 7.3の延長サポート期限が迫り、全面移行の予算も通らない状況で、基幹を捨てずに現場の入力・承認・モバイルを刷新し、次のEOSにも耐えられる運用体制を社内合意のうえで立ち上げたい——その判断材料が必要です。

 

回答後に最初に着手すべきこと：

1. OS／ハードウェア／基幹パッケージ／ミドルウェアのサポート期限を1枚の台帳にまとめる
2. 「IBM iに残す業務」と「クラウドへ出す業務」を、利用者数・改修頻度・障害影響で優先順位付けする
3. 正本・同期頻度・エラー時代替運用を、情シスと業務責任者の合意文書にする

 

避けたい失敗は、延長保守だけで現場使い勝手を放置し次のEOSで同じ議論に戻ること、および正本・復旧手順を決めないまま連携ツールを入れ二重入力で現場信頼を失うことです。

 

成功状態の定義例：

•  
• 現場：外出先から在庫照会と受注入力ができ、電話問い合わせが常態ではない
•  
• 数字：締め遅延の主因が「画面が使えない／転記ミス」ではなく業務判断に移っている
•  
• 心理：次のOS更新や周辺EOSでも、「全面移行か延命か」で止まらずフロント刷新の延長線で議論できる
•  

今日使えるチェックリスト：

•  
• □IBM iバージョンと契約中サポート種別（標準／Service Extension）を確認した
• □Power9などハードウェアの対象モデルとEOSS日を確認した
• □パイロット業務を1つに絞り、成功指標（電話問い合わせ件数、転記工数など）を決めた
• □正本・同期・復旧の責任者名を書き出した
• □OS更新と2層ERP立ち上げを同一ロードマップの別レーンで描いた

 

ここまでできれば、サポート終了対応はイベント作業ではなく、継続的な運用設計の入口に変わります。

IBM i 7.3への対応は非常に重要ですが、EOSは今後も繰り返されます。全面移行や単なるバージョンアップといった二者択一ではなく、システムの役割を分けて考える2層ERPでの運用は、企業の堅牢性と変化への柔軟性を両立する現実的な解決策といえるでしょう。

 

業務の棚卸しを行い、バックエンドのIBM iとフロントエンドのクラウドの分担ルールを明確な5つの論点に沿って設計することで、一度の対応で終わらない継続的なアップデートに耐えるシステム運用体制が整います。サポート期限対応を乗り越え、今後の企業のビジネス成長を加速させる足がかりとなることを願っています。

 

ERP周辺のデータ統合と、IBM iを残したままのフロント刷新をあわせて検討したい方は、Slopebaseの製品情報も参考にしてください。Slopebaseサイトではレガシー対策やデータ連携の解説を掲載しています。サポート期限台帳やパイロット業務の切り出しについて相談したい方は、お問い合わせページからご連絡ください。