AS400 / IBM i の現場では、「このまま保守し続けてよいのか」「Web化した方がよいのか」「新しいシステムへリプレースすべきか」という相談が必ず出ます。AS400は安定した基幹システムとして長く使われてきましたが、担当者の退職、古いドキュメント、RPG/CLの属人化、周辺システムとの連携、画面の使いにくさが課題になることもあります。
ただし、古いからすぐ捨てる、という判断は危険です。販売管理、在庫、出荷、売上、請求、締め処理のような業務ロジックがAS400に深く入っている場合、置き換えの失敗は業務停止に直結します。この記事では、残す、直す、つなぐ、置き換える判断を現場目線で整理します。
最初に決めるのは残すか捨てるかではない
最初に決めるべきなのは、「AS400を残すか捨てるか」ではありません。まず、今のAS400がどの業務を支えているのか、どの処理が止まると会社に影響するのか、どの部分が本当に困っているのかを分けます。
| 見る観点 | 確認すること | 関連ページ |
|---|---|---|
| 業務範囲 | 受注、出荷、在庫、売上、請求、会計連携、店舗連携 | 販売管理システム保守ガイド |
| 障害時の影響 | 止まるジョブ、止まる部署、再実行できる処理、手作業で代替できる処理 | 本番障害の初動対応 |
| ソースと影響範囲 | RPG、CL、DSPPGMREF、呼び出し関係、参照ファイル | DSPPGMREF影響調査 |
| データ | マスタ、トランザクション、履歴、CSV出力、外部連携 | AS400データ抽出ガイド |
| 運用 | 夜間バッチ、スプール、バックアップ、MSGW、ジョブログ | AS400保守・運用完全ガイド |
残した方がよいケース
AS400を残した方がよいケースは、基幹業務が安定して動いており、現場が処理の流れを理解していて、障害時の復旧手順もある程度そろっている場合です。この状態であれば、すぐ全面リプレースするより、ドキュメント整理、影響調査、保守手順の標準化、周辺機能の改善から始める方が安全です。
- 日次・月次処理が安定している
- 販売管理や在庫管理の業務ロジックが複雑で置き換えリスクが高い
- 既存RPG/CLの修正で業務要件に対応できている
- バックアップ、復元、ジョブログ確認の手順がある
- 利用部門が画面操作に慣れている
直す・つなぐ方がよいケース
全面リプレースではなく、今のAS400を残しながら不足部分だけ直す選択もあります。たとえば、データ抽出を整える、帳票出力を改善する、周辺のWeb画面を作る、外部システムとCSVやAPIで連携する、といった方法です。
この場合、AS400側のファイル定義、出力条件、ジョブの流れ、エラー時の再実行手順を確認してから進めます。見た目だけWeb化しても、裏側の業務ロジックやデータ整合性を理解していないと、後で運用が苦しくなります。
リプレースを検討すべきケース
一方で、リプレースを検討すべきケースもあります。担当者が完全にいなくなり、障害時に誰もジョブログを読めない。OSや周辺機器の保守期限が厳しい。現行業務とシステムが合わず、毎月の手作業が増え続けている。こうした状態では、現行調査と並行して移行計画を作る必要があります。
| 危険サイン | 起きやすい問題 | 最初の対策 |
|---|---|---|
| 担当者がいない | 障害時に原因調査や復旧判断が遅れる | ジョブログ、バッチ、重要ファイルを棚卸しする |
| ドキュメントが古い | 実際の処理と仕様書が違い、改修リスクが上がる | DSPPGMREFと現行ソースから影響範囲を作る |
| 手作業が増えている | 二重入力、Excel加工、締め処理の遅れが増える | データ抽出と連携処理を整理する |
| 画面や帳票が限界 | 現場の教育コストや確認ミスが増える | 周辺画面、帳票、CSV出力から改善する |
| 保守期限が厳しい | 障害時の部品・保守対応が難しくなる | バックアップ、復元、移行候補を確認する |
リプレース前に棚卸しする資料
リプレースを検討するなら、いきなり新システムの画面設計に入るのではなく、現行AS400の棚卸しから始めます。どのプログラムがどのファイルを見ているのか、どのバッチがどの順番で動くのか、どの帳票が誰に使われているのかを整理します。
- 主要業務一覧
- 重要プログラムとCLの一覧
- 主要ファイル、物理ファイル、論理ファイル
- 夜間バッチとジョブスケジュール
- スプール、帳票、外部出力
- 障害時の復旧手順
- バックアップと復元手順
- 外部連携、CSV、手作業Excel
AIやCodexを使う場合の位置づけ
CodexのようなAIは、AS400の移行判断そのものを丸投げする道具ではありません。ただし、RPG/CLソースの要約、影響範囲の表化、テスト観点の整理、ジョブログの読み取り補助、ドキュメントのたたき台作成には役立ちます。
AIに渡す前には、本番データ、顧客名、会社名、ユーザー名、ライブラリ名、機密の業務名をマスキングします。安全な使い方は AS400 / IBM i 現場向けCodex実戦研修 にまとめています。
まとめ
AS400のモダナイゼーションやリプレースは、古いから捨てる、新しいから良い、という単純な話ではありません。残す部分、直す部分、つなぐ部分、置き換える部分を分けて考えることが大切です。
判断に迷う場合は、まず 保守・運用完全ガイド、コマンド逆引き、データ抽出ガイド を使って、現行システムの実態を整理してください。
外部の保守会社へ相談する前に
障害、小改修、データ抽出、リプレースを外部へ相談する場合は、AS400保守会社に相談する前のチェックリスト で、対象業務、現象、緊急度、技術情報、機密情報の扱いを整理してください。
Web化・API連携・開発ツールで迷った時
AS400をWeb化したい、API連携したい、PDM/SEU/RDi/VS Code/Codexの使い分けで迷う時は、AS400のWeb化・API連携ガイド と AS400開発ツールの違い を確認してください。既存RPG、CSV、IFS、夜間バッチ、権限、コンパイル手順を整理してから進めます。
単一レベル記憶・TIMI・将来性を理解する
AS400が長く使われる理由を理解するには、単一レベル記憶、TIMI、IBM iの互換性、ブラックボックス化リスクも押さえる必要があります。詳しくは AS400の単一レベル記憶とTIMIの解説 を確認してください。概念だけでなく、保守・影響調査・移行判断へつなげて整理しています。
バージョン・PTF・サポート状況を確認する
AS400の保守、更改、クラウド移行、PTF適用を考える時は、AS400のバージョン・PTF・サポート確認手順を確認してください。IBM iのバージョン、PTF、Powerサーバー世代、バックアップ、権限、外部連携を整理します。
Git・ソース管理・AI活用の前に
RPG/CLの保守をGitやAI活用へつなげる時は、AS400でGit・ソース管理を始める手順を確認してください。ソースの正本、コンパイル手順、レビュー、切り戻し、Codex利用時の注意点を整理します。
保守切れ・ベンダー不在・Web化で相談する前の判断表
AS400の移行やWeb化は、「古いから置き換える」だけで決めると失敗しやすいです。保守切れ、開発ベンダー不在、技術者不足、画面の古さ、外部連携の要望を分けて、残す機能・直す機能・つなぐ機能・置き換える機能を整理します。
| 相談の入口 | 先に確認すること | 次に見るページ |
|---|---|---|
| 保守切れが不安 | バックアップ、復元テスト、障害時の連絡先、代替手順 | バックアップ確認チェックリスト |
| 開発ベンダーがいない | ソース管理、設計書、業務担当者、影響調査できる人 | 保守会社相談前チェックリスト |
| Web化したい | 既存RPG/CL、バッチ、CSV、IFS、認証、権限、戻し方 | Web化・API連携ガイド |
| 画面が古い | 置き換える画面、残す画面、在庫照会・請求締め・出荷確定の業務順 | AS400初心者向け完全ガイド |
| 技術者不足 | ジョブログ、RPG/CL、ファイル定義、調査メモを共有できるか | Codex実戦研修 |
