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、ジョブ、権限、障害時の戻し方を整理してから進めることで、失敗しにくくなります。
関連: AS400 Web化・脱5250を検討する時のチェックリスト｜画面移行より先に見ることもあわせて確認してください。
AS400モダナイゼーションは、全面刷新だけが正解ではない
AS400のモダナイゼーションでは、いきなり全面刷新を狙うと、業務理解、テストデータ、外部連携、締め処理のリスクが大きくなります。まずは帳票PDF化、Web画面化、EDI監視、ジョブログ調査の効率化、ソース解析の可視化など、周辺システムから段階的に改善する選択肢もあります。
関連するAS400実務記事
RPGのWeb化は画面移行だけでなく、現行業務、障害対応、確認コマンド、教育の道筋まで残して進めます。
Web化を決める前に比較する選択肢
RPGのWeb化やAPI化は有効な選択肢ですが、すべてを一気に置き換える前に、継続利用、部分改善、社内提案、リプレースの失敗リスクを並べて比較します。現行AS400 / IBM iの強みと制約を整理してから方式を選ぶほうが、見積もりやPoCの精度も上がります。
| 判断したいこと | 次に読む記事 |
|---|---|
| AS400を使い続けるか判断する | AS400継続利用判断チェックリスト |
| 社内説明用の材料を作る | IBM i更新の社内提案ガイド |
| 全面リプレースの失敗要因を見る | AS400リプレース失敗防止チェック |
| 費用と保守体制を見直す | AS400保守費用削減チェックリスト |
Web化、API化、部分改善、継続利用のどれを選ぶべきか迷う場合は、対象画面、対象RPG/CL、連携先、夜間バッチ、帳票、ユーザー数を整理してお問い合わせから相談できます。
