AS400 / IBM i のRPGソースをAIに読ませると、処理概要の整理、CALL関係の確認、テスト観点の洗い出し、単純なバグ候補の検出などでかなり役に立ちます。特に古いRPGやコメントが少ないソースでは、最初の調査時間を短縮できることがあります。
ただし、AS400の現場では「便利だから全部見せる」は危険です。販売管理、在庫、出荷、請求、店舗連携、物流連携など、基幹システムのソースやログには、会社ごとの業務ルールや機密情報が含まれることがあります。AIに読ませる前に、何を見せてよいかを必ず決めておくべきです。
この記事では、RPGソースをAIに読ませる時の注意点を、AS400保守の現場目線で整理します。Codexに限らず、Claude Codeなど他のAI開発支援ツールを使う場合でも、考え方はほぼ同じです。
現場メモ: 私はAIに本番データや顧客情報が載っているDBは触らせたくありません。必要なら、名称が入っていないDBやコードだけのマスターを作って、それを読ませるようにしています。AIを使うほど、見せる情報の線引きが大事になります。
AIに読ませてよいRPGソースの範囲を決める
最初に決めるべきなのは、AIに読ませてよい範囲です。RPGソースそのものを見せるのか、処理概要だけにするのか、マスキングしたサンプルにするのかで、リスクは大きく変わります。
| 対象 | AIに読ませる時の考え方 | 注意点 |
|---|---|---|
| RPGソース | 必要な範囲だけ切り出す | 顧客名、会社固有名、内部コードが入っていないか確認 |
| CLソース | CALL順、OVRDBF、SBMJOBなどの流れを見る | ライブラリ名や本番環境名をマスクする |
| ジョブログ | 必要なメッセージ周辺だけ使う | ジョブ名、ユーザー、番号、ライブラリ名を確認 |
| DB内容 | 原則そのまま読ませない | 顧客情報、取引情報、個人情報を含む可能性がある |
| テストデータ | AIに作らせやすい | 仕様を明確にし、出力結果は人間が検証する |
RPGソースを読ませる前にマスキングする
AIにRPGソースを読ませるなら、まず固有名詞を消します。会社名、顧客名、店舗名、実ライブラリ名、実ファイル名、実ユーザー名、実ジョブ名などは、できるだけサンプル名へ置き換えます。
たとえば、ライブラリ名は TESTLIB、プログラム名は TEST001R、ファイル名は FILE01 のように置き換えると、処理の構造を残したまま安全に説明しやすくなります。
AIに渡す前の置き換え例 本番ライブラリ名 -> TESTLIB 実プログラム名 -> TEST001R 実ファイル名 -> FILE01 実顧客コード -> CUST001 実店舗コード -> SHOP001
AIに頼むなら「何を見てほしいか」を明確にする
AIにソースを渡す時は、「このRPGを読んで」だけだと結果がぼやけます。AS400保守では、何を確認したいのかを具体的に伝えた方が実用的です。
| 目的 | 指示例 |
|---|---|
| 処理概要を知りたい | このRPGソースの処理概要を、入力、主処理、出力に分けて整理してください。 |
| CALL関係を見たい | 呼び出している外部プログラム、サブルーチン、ファイル参照を一覧化してください。 |
| バグ候補を見たい | 配列の上限、未初期化、桁あふれ、例外処理不足の可能性を確認してください。 |
| テスト観点を作りたい | 正常系、異常系、フル桁入力、件数増加時のテスト観点を作ってください。 |
| 修正影響を見たい | このフィールドを変更した場合に影響しそうな処理、ファイル、帳票を整理してください。 |
私の感覚では、AIは「単純なバグ発見器」としてかなり使えます。たとえば配列の指標エラー、ソースの整合性、呼び出し関係の見落としなど、人間が疲れていると見落としやすいところを拾わせる使い方は相性が良いです。
AIに任せてはいけない作業
RPGソースをAIに読ませることと、AIに本番作業を任せることは別です。ここを混同すると危険です。特にAS400は基幹システムで使われることが多く、販売管理や物流連携では一つの判断ミスが大きな業務影響につながります。
- 本番環境でのコマンド実行
- 本番データの更新SQL作成
- データリカバリー手順の単独判断
- 顧客情報を含むDB調査
- 生成コードの本番反映
- ジョブ停止やMSGW応答の判断
AIが出した回答やコードは、必ず人間が確認します。「AIが作ったので」という言い訳は現場では通用しません。最終的に責任を持つのは人間です。
若手に使わせるなら、まずバグチェックから
若手AS400エンジニアにAIを使わせるなら、最初はバグチェックや処理概要の整理から始めるのが安全です。いきなり改修案を本番反映するような使い方ではなく、調査補助として使う方が現実的です。
AS400保守では、RPGだけでなく、CL、DDS、ファイル定義、ジョブログ、スプール、ライブラリリストまでつながって見なければいけません。AIは便利ですが、業務全体を理解していない人が使うと、きれいな文章で間違った結論を出すこともあります。
RPG/CL修正後のテスト観点は、RPG/CL修正後の単体テスト記事でも整理しています。AIに任せる場合でも、最終的には仕様通りに動くかを確認する必要があります。
まとめ
AS400のRPGソースをAIに読ませること自体は、かなり有効です。処理概要の整理、CALL関係の確認、バグ候補の検出、テスト観点の作成など、保守作業の前段では大きな助けになります。
ただし、本番環境、本番DB、顧客情報、リカバリー作業には踏み込ませないこと。AIを使う前に、見せる範囲、任せる範囲、レビュー責任、検証方法を決めておくことが大切です。
法人向けのAS400 / IBM i x Codex研修について
AS400 / IBM i の開発・保守で生成AIを安全に使う方法を、RPG/CLソース読解、プログラム調査、改修案作成、動作確認・テストまで実戦形式で学べます。実ソースを使う場合も、社内ルールと秘密保持を前提に進めます。
関連して、法人やSIerでAIを導入する前のルールは、AS400開発会社・SIerがCodexを使う前に決めておくべきルールにもまとめています。
AS400の全体像を先に整理したい場合は、AS400総合ガイドから読むと、基本操作、RPG/CL保守、ジョブログ、本番対応のつながりを確認できます。
機密保護・権限で迷った時
ユーザープロファイル、特殊権限、ライブラリ権限、データ出力の扱いで迷った時は、AS400の機密保護・権限確認チェックリスト を確認してください。権限変更前の確認、CSV出力、AI利用時のマスキングを整理しています。
AIで調査時間を減らす保守の使いどころ
機密情報を守る前提を決めたら、次はジョブログ確認、RPG/CL読解、影響調査、テスト観点の洗い出しなど、調査時間を減らしやすい作業から始めるのが現実的です。詳しくはAS400保守でCodexは使えるかで整理しています。
