AS400 / IBM i のRPG資産をWeb化したい、5250画面をブラウザ化したい、外部システムからAPIで呼び出したい、という相談は増えています。CGIDEV2、LANSA、RDi、Java、PHP、Node.js、REST API、ローコードなど選択肢は多いですが、最初に決めるべきことはツール名ではありません。
この記事では、AS400のRPGをWeb化・API化する前に確認することを、保守現場の目線で整理します。既存RPG、CL、DDS、物理ファイル、論理ファイル、ジョブ、権限、夜間バッチを壊さずに進めるための入口です。
Web化の前に「何を残すか」を決める
AS400のWeb化は、単に5250画面をブラウザに置き換える作業ではありません。現行の入力チェック、採番、在庫引当、締め処理、帳票出力、エラー時の戻し方がどこにあるかを確認します。画面だけを見ると簡単に見えても、実際の判断はRPG、CL、データベース、ジョブ記述、出力キューに分かれていることがあります。
- 5250画面だけを置き換えるのか
- RPGの業務ロジックは残すのか
- DB2 for i のファイル構造はそのまま使うのか
- 夜間バッチや帳票出力に影響が出ないか
- 障害時に旧手順へ戻せるか
CGIDEV2やLANSAを選ぶ前に見るポイント
CGIDEV2やLANSAのような選択肢は、既存資産を活かしながらWeb化を進める候補になります。ただし、どの製品や方式がよいかは、現行資産の状態で変わります。RPGが固定形式中心なのか、フリーフォーマット化されているのか、画面ファイルと業務ロジックが密結合しているのか、外部公開が必要なのかを先に確認します。
製品比較を始める前に、対象業務を一つに絞って、入力、更新、参照、帳票、承認、エラー処理を分解します。最初から全画面をWeb化しようとすると、範囲が膨らみます。まず問い合わせ画面、承認画面、在庫照会、出荷状況照会など、リスクの低い参照系から始める方が安全です。
API化ではデータ整合性を先に決める
AS400をAPI連携する場合、リアルタイム連携にするか、バッチ連携にするか、再送できるか、二重登録を防げるかが重要です。APIの形だけを作っても、更新単位、排他、コミット、エラー時の取り消しが曖昧だと本番障害につながります。
- どのファイルを正とするか
- 更新はRPG経由か、SQL直接更新か
- コミットメント制御が使われているか
- 同じ伝票を二重処理しないキーがあるか
- 障害時にジョブログやメッセージで追跡できるか
RPGをそのまま呼ぶ場合の注意点
既存RPGをそのまま呼び出す方式は、業務ロジックを再実装しない利点があります。一方で、対話型ジョブを前提にした処理、画面ファイル依存、ライブラリリスト依存、ユーザープロファイル依存、出力キュー依存が残っていると、WebやAPIから呼ぶ時に想定外の待ちや権限エラーが起きます。
特に、MSGWで止まる処理、SBMJOB前提の処理、QTEMPを使う処理、OVRDBFでファイルを差し替える処理は、呼び出し元を変える前に確認します。Web化は見た目の刷新ですが、運用上はジョブ管理の変更でもあります。
最初の一歩は資産棚卸し
Web化・API化の前に、DSPPGMREFで参照ファイルを確認し、DSPFFDでファイル定義を確認し、ジョブログでエラーの出方を確認します。ソースが残っている場合は、RPG、CL、DSPF、PRTF、DDSを分けて棚卸しします。ソース管理がない場合は、変更前に現行ソースとオブジェクトの対応を整理します。
AS400の全体像を先に整理する場合は、AS400初心者向け完全ガイド、置き換え判断は AS400モダナイゼーション・リプレース判断ガイド、API連携の基本は AS400のWeb化・API連携ガイド を合わせて確認してください。
相談前チェックリスト
- 対象業務と画面数を一覧にしたか
- 対象RPG、CL、DDS、物理ファイル、論理ファイルを確認したか
- 夜間バッチ、JOBQ、OUTQ、帳票への影響を確認したか
- API化するデータの主従、再送、二重処理防止を決めたか
- 権限、監査、ログ、障害時の復旧手順を決めたか
- いきなり全面Web化せず、小さい参照系から始められるか
AS400のRPG Web化は、ツール選定よりも現行業務の分解が先です。CGIDEV2、LANSA、API基盤、画面変換ツールのどれを使う場合でも、既存RPG、CL、DB2 for i、ジョブ、権限、障害時の戻し方を整理してから進めることで、失敗しにくくなります。
現場でAIやCodexを使ってソース調査、影響調査、Web化前の棚卸しを進めたい場合は、AS400現場向けCodex研修 も参考にしてください。
