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や周辺機器の保守期限が厳しい。現行業務とシステムが合わず、毎月の手作業が増え続けている。こうした状態では、現行調査と並行して移行計画を作る必要があります。
作り直すかどうかを決める前に、現行が何をしているかを社内で説明できる状態が要ります。Codexを使ってRPG/CLの読解や調査メモを整理する方法は、AS400 / IBM i現場向けCodex実践研修でも扱います。
| 危険サイン | 起きやすい問題 | 最初の対策 |
|---|---|---|
| 担当者がいない | 障害時に原因調査や復旧判断が遅れる | ジョブログ、バッチ、重要ファイルを棚卸しする |
| ドキュメントが古い | 実際の処理と仕様書が違い、改修リスクが上がる | DSPPGMREFと現行ソースから影響範囲を作る |
| 手作業が増えている | 二重入力、Excel加工、締め処理の遅れが増える | データ抽出と連携処理を整理する |
| 画面や帳票が限界 | 現場の教育コストや確認ミスが増える | 周辺画面、帳票、CSV出力から改善する |
| 保守期限が厳しい | 障害時の部品・保守対応が難しくなる | バックアップ、復元、移行候補を確認する |
リプレース前に棚卸しする資料
リプレースを検討するなら、いきなり新システムの画面設計に入るのではなく、現行AS400の棚卸しから始めます。どのプログラムがどのファイルを見ているのか、どのバッチがどの順番で動くのか、どの帳票が誰に使われているのかを整理します。
- 主要業務一覧
- 重要プログラムとCLの一覧
- 主要ファイル、物理ファイル、論理ファイル
- 夜間バッチとジョブスケジュール
- スプール、帳票、外部出力
- 障害時の復旧手順
- バックアップと復元手順
- 外部連携、CSV、手作業Excel
AIやCodexを使う場合の位置づけ
CodexのようなAIは、AS400の移行判断そのものを丸投げする道具ではありません。ただし、RPG/CLソースの要約、影響範囲の表化、テスト観点の整理、ジョブログの読み取り補助、ドキュメントのたたき台作成には役立ちます。
保守切れ・ベンダー不在・Web化で相談する前の判断表
AS400の移行やWeb化は、「古いから置き換える」だけで決めると失敗しやすいです。保守切れ、開発ベンダー不在、技術者不足、画面の古さ、外部連携の要望を分けて、残す機能・直す機能・つなぐ機能・置き換える機能を整理します。
| 相談の入口 | 先に確認すること | 次に見るページ |
|---|---|---|
| 保守切れが不安 | バックアップ、復元テスト、障害時の連絡先、代替手順 | バックアップ確認チェックリスト |
| 開発ベンダーがいない | ソース管理、設計書、業務担当者、影響調査できる人 | 保守会社相談前チェックリスト |
| Web化したい | 既存RPG/CL、バッチ、CSV、IFS、認証、権限、戻し方 | Web化・API連携ガイド |
| 画面が古い | 置き換える画面、残す画面、在庫照会・請求締め・出荷確定の業務順 | AS400初心者向け完全ガイド |
| 技術者不足 | ジョブログ、RPG/CL、ファイル定義、調査メモを共有できるか | Codex実践研修 |
想定例：受注処理は残し、倉庫の入力だけ変えたい
以下は判断方法を示す架空の例です。受注・請求は安定している一方、倉庫ではハンディ端末からの入力が必要になったとします。この場合、全置換だけでなく、IBM i側を正本として入力部分を連携する案を比較できます。
- 正本を決める：受注・在庫の確定値をどちらのシステムが管理するか。
- 境界を決める：端末が送るキー、数量、受付結果、重複送信時の扱い。
- 小さく検証する：対象業務を限定し、通信断・再送・取消を含む整合性を確かめる。
- 費用を比べる：連携の開発だけでなく、認証、監視、保守、教育、将来変更を含める。
- 続行条件を決める：照合結果、処理時間、現場の操作、障害復旧を担当者が確認できること。
前提が満たせなければ部分連携案も見直します。具体的な見積りや性能をこの例から保証することはできません。調査対象の整理には設計書・運用資料の棚卸しを使えます。
