AS400 / IBM iの保守でよくある悩みが、長年の改修で複雑になったRPG/CLソースを誰も説明できないことです。コメントが古い、命名が分かりにくい、例外処理が多い、担当者が退職している。こうなると、ちょっとした改修でも調査時間が膨らみます。
Codexを使うと、マニアックな人が作成した解読不能なソースを、処理概要、更新ファイル、呼び出し関係、テスト観点に分けて整理しやすくなります。ここでは、AS400現場で安全に使うための流れをまとめます。
最初にやることはソースを丸投げしないこと
本番データ、顧客名、ユーザーID、接続情報、取引先コードなどを含んだままAIに入れてはいけません。まず社内ルールに従い、機密情報をマスクし、必要な範囲だけを切り出します。
Codexに整理させる観点
| 観点 | 確認したいこと | 現場で使う目的 |
|---|---|---|
| 処理概要 | 何を入力し、何を更新し、何を出力するか | 業務担当者へ説明する |
| ファイル | 物理ファイル、論理ファイル、ワークファイル、スプール | 影響範囲を洗い出す |
| 呼び出し関係 | CLから呼ばれるRPG、後続ジョブ、外部連携 | 修正漏れを防ぐ |
| 条件分岐 | 取引区分、出荷区分、締め状態、エラー時処理 | テストケースを作る |
| 障害時確認 | MSGW、ジョブログ、戻し、再送 | 本番障害の初動に使う |
現場で使いやすいプロンプト例
ソースを渡す時は、単に「説明して」ではなく、出力形式を決めると使いやすくなります。
このRPG/CLソースを、AS400保守引き継ぎ用に整理してください。 1. 処理概要 2. 入力ファイル・更新ファイル・出力 3. 呼び出し元と後続処理 4. 業務上の注意点 5. 本番反映前のテスト観点 6. ジョブログやMSGWで確認するポイント 機密情報は推測せず、分からない点は質問として列挙してください。
AIの要約を信じ切らない
Codexの要約は調査時間を減らす助けになりますが、最終判断は人間が行います。特にEDI、締め、在庫、請求、出荷確定に関わる処理は、ソース上の分岐だけでなく、業務担当者への確認、テストデータ、再送条件、戻し手順まで確認します。
保守引き継ぎ資料に落とし込む
AIで読ませて終わりではなく、処理概要、関連ジョブ、更新ファイル、障害時の連絡先、よくあるMSGW、再実行条件を1枚の資料にします。属人化していたソースを、次の担当者が読める形に変えることが目的です。
業務理解を含めた整理は、AS400保守で業務理解がないと設計できない理由 もあわせて確認してください。研修として身につけたい場合は、AS400 / IBM i 現場向けCodex実戦研修 にまとめています。
まとめ
AS400の解読不能なRPG/CLソースは、Codexを使うことで読み始めの負担を下げられます。ただし、機密情報を守り、AIの要約を業務理解と突き合わせ、テスト観点と障害時対応まで整理して初めて、保守引き継ぎに使える資料になります。
ソース解析では、処理概要より更新ファイルと判断条件を見る
CodexでRPG/CLソースを要約する時は、「何をしているプログラムか」だけでなく、どのファイルを読んでいるか、どのファイルを更新しているか、どの条件で処理が分岐するか、異常時にどのメッセージを出すかまで整理します。ここまで出せると、影響調査とテスト観点に使いやすくなります。
- 入力ファイル、更新ファイル、出力帳票を分けて要約する
- CALL、SBMJOB、MONMSG、OVRDBFを見落とさない
- テスト観点は正常系、異常系、再実行、締め後影響に分ける
- Codexでテスト観点を作る
- AS400保守でCodexを使う考え方
