AS400を使い続けるか、別のシステムへ移行するかは、製品名の古さでは決められません。業務要件を満たし、保守・復旧・人員を確保できるなら継続利用が候補になります。逆に、その条件を更新や部分改修でも満たせないなら、全面移行を比較する必要があります。
この記事は、現在のIBM i環境を棚卸しし、「継続」「基盤更新」「周辺改善」「全面移行」を同じ条件で比較するための手順です。サポート期限の一覧だけを知りたい場合は、IBM iのサポート期限と確認手順を先に確認してください。
25年の現場で見てきた継続利用と、その限界
運営者が25年以上関わってきた範囲では、他のプラットフォームへ切り替えるお客様は少なく、更改時にもIBM iを選ぶケースが多くありました。販売管理、在庫、出荷、請求など、既存業務が安定していることは継続する理由になります。ただし、これは市場全体の統計ではなく、私が担当した現場での経験です。
安定していたからといって、故障しない、将来も変更不要という意味ではありません。私自身も電源装置の故障と復元後のアクセスパス再作成で業務が止まった経験があります。継続利用の判断には、業務の適合性だけでなく復旧にかかる時間を含めます。
まず1枚に集める現状と期限
| 対象 | 記録する事実 | 判断に使う証拠 |
|---|---|---|
| 業務 | 止められる時間、月次・年次処理、今後変わる業務 | 利用部門の要件と処理一覧 |
| OS・機器 | IBM iリリース、PTF、Power機種、保守期限 | システム表示、契約書、IBMの対応表 |
| 周辺製品 | ACS、帳票、バックアップ、EDI、ODBC/JDBCの対応条件 | 各製品ベンダーのサポート情報 |
| 復旧 | 保存対象、復元時点、実測した復旧時間、失われる更新 | 保管ログ、復元テスト結果、業務側の許容条件 |
| 人・ソース | 担当者、委託先、ソースと稼働物の対応、引継ぎ状況 | 担当表、変更履歴、調査記録 |
| 費用 | 保守・機器・改修・教育・移行・並行稼働の費用 | 同じ期間と対象範囲で取得した見積り |
期限は「OS」「機器」「周辺製品」「担当者の退職・契約終了」に分け、最も近い期限から逆算します。未確認欄は空欄にせず、確認先と回答期限を付けます。バージョン確認はIBM iのバージョン確認手順、業務の聞き取りは業務ヒアリングシートを使ってください。
2026年9月はIBM i 7.4の保守切替を先送りしない
2026年9月17日に確認したIBM公式情報では、IBM i 7.4は2026年9月30日に標準サポート期間から切り替わり、Service Extensionの提供期間は2026年10月1日〜2029年9月30日です。その日にOSが動かなくなるわけではありませんが、延長は自動ではなく、契約・対象製品・提供範囲の確認が必要です。
出典：IBM Release life cycle。OS以外の期限は別です。「3〜5年後に更新する」という一律の計画を置かず、自社の期限と契約条件に合わせて更新または延長の手配を進めます。
4つの案を、できることと残る問題で比較する
| 案 | 合いやすい状況 | その案だけでは残る問題 |
|---|---|---|
| 現行環境を維持 | 業務要件と保守期限に余裕があり、復旧と担当体制を確認できる | 老朽化や将来の更新費を先送りにしない |
| OS・Powerを更新 | 基幹業務は適合するが、期限・性能・可用性に課題がある | 古い業務ルールや属人化は基盤更新だけでは消えない |
| 基幹を残して周辺改善 | 帳票、Web参照、データ連携など限定した範囲に課題がある | 二重入力、連携失敗、認証・運用の担当を増やす可能性 |
| 別基盤・パッケージへ移行 | 業務要件や保守確保の問題を上の案で満たせない | 例外業務、データ変換、教育、切戻しを新たに検証する必要 |
「触れる人がいないから移行する」場合も、現行仕様と例外業務の確認は必要です。分からない部分をそのまま新システムへ持ち込まないよう、稼働中ソース、ジョブログ、帳票、利用部門の説明を突き合わせます。AIによる解析結果も、仕様の確定ではなく確認候補として扱います。
期限から逆算する実務ロードマップ
| 時点 | 行うこと | 次へ進める条件 |
|---|---|---|
| 計画着手時 | 期限と業務影響を棚卸し、期限が近い契約・機器を先に調整 | 更新または延長の可否、担当者、回答期限が決まっている |
| 比較・見積り前 | 4案を同じ期間、対象業務、復旧条件で比較する | 残る問題と費用の前提を業務側も説明できる |
| 更新・移行前 | 対応リリース、周辺製品、PTF、テスト、切戻しを具体化する | 重要機能の試験結果と未解決差異の扱いが承認されている |
| 切替直後 | 業務結果、実行時間、帳票、外部連携を旧環境の記録と照合する | 業務側の確認完了と、旧環境を保持する期間が決まっている |
| 継続運用中 | 期限の更新、復元テスト、手順と担当者の引継ぎを定期確認する | 次回の確認日と担当者を記録している |
期間は会社ごとに異なります。サポート終了や機器故障の危険が目前にある場合、全面移行が間に合うとは限りません。短期の保守確保と、中期の更改・移行を別の計画として扱います。
機種を入れ替えた後は、全機能の動作確認をする
私が関わった更改では、切替後に問題が起きた経験はありません。事前に全機能のテストを行っていました。ただし、それが今後の無障害を保証するわけではありません。更改を主導したのは情報システム部門で、基幹側は当日の待機や確認作業への同席という形で関わっています。
OS更新ではコマンドのパラメーター、SQL、周辺製品の対応などに差があり得ます。「基本的に互換性がある」と「自社の全機能を確認した」は別です。対象リリースの変更点と自社が使う機能を照合してください。
- 画面：照会だけでなく、登録・変更・取消と権限別の動作を確認する
- バッチ：日次・月次・年次、異常時・再実行まで確認する
- 帳票・外部連携：数字、出力先、相手側取込、再送・重複防止を確認する
- 性能：同じ条件・データ量で、変更前後の処理時間を記録する
遅くなった時にハード側・アプリ側のどちらの問題か議論するだけでは調査が進みません。変更前後の所要時間、件数、ジョブログを残しておくと切り分けの材料になります。具体的な試験項目は移行プロジェクトの失敗を防ぐチェックリストへまとめています。
継続利用を決めた後も、知識の引継ぎを計画に入れる
基盤を更新しても、業務の判断が一人に集中したままでは保守は続きません。調査した根拠、未確認事項、締め・EDIへの影響を他の人がたどれる形に残します。社内育成の進め方は若手エンジニアの育成カリキュラム、AI解析に使う資料の扱いはRPGソースをAIに読ませる際の注意点を確認してください。
判断のゴールは「AS400を残す」と先に決めることではなく、自社業務を、いつまで、誰が、どの費用と復旧条件で支えられるかを説明できることです。確認できない条件があれば、継続案にも移行案にも課題として残します。
