AS400 / IBM i の本番反映前にAIを使うなら、答えを鵜呑みにするのではなく、確認漏れを減らすレビュー補助として使うのが安全です。変更内容、影響範囲、テスト観点、戻し手順、業務連絡を整理させると、リーダー確認の前段として役立ちます。
AIに確認させる項目
| 項目 | 確認内容 | 人が見ること |
|---|---|---|
| 変更内容 | 何を変えたか | 依頼内容と合っているか |
| 影響範囲 | 画面、帳票、バッチ、外部連携 | 業務順序と締めへの影響 |
| テスト | 正常系、異常系、境界値 | 本番データに近い条件か |
| 戻し手順 | ソース、オブジェクト、データ | 本当に戻せるか |
| 連絡 | 誰に知らせるか | 営業、物流、経理への影響 |
使ってはいけない聞き方
「この修正は本番反映して大丈夫ですか」と丸投げする聞き方は危険です。AIは本番環境、業務締め、運用ルール、顧客との約束を知りません。判断は人が行い、AIには確認観点の抜けを出させる役割にします。
本番前プロンプト例
「AS400の本番反映前レビューです。変更概要、影響範囲、テスト結果、戻し手順を見て、確認漏れ候補と追加で確認すべき質問を出してください。反映可否は判断せず、リスク観点だけ整理してください。」
本番反映の判断は AS400本番リリースGo/No-Goチェックリスト、単体テストは AS400単体テスト手順、AIへの聞き方は AS400保守で使うAIプロンプト集 を確認してください。
AIレビュー結果は、そのまま本番反映しない
AIレビューは便利ですが、AS400の本番反映では必ず人が確認します。影響範囲、テスト結果、承認、戻し手順、機密情報の扱いを確認し、AIの提案はレビュー材料として扱うのが安全です。
- AIが指摘した修正内容を人が読み直す
- 本番反映前にテスト観点と証跡を確認する
- 承認者と戻し手順を明確にする
- 本番対応チェックリスト
AIレビューは、本番反映を軽くするためではなく確認漏れを減らすために使います
AS400の本番反映前にAIやCodexを使う場合、生成結果をそのまま信用してはいけません。RPG/CLの変更点、影響ファイル、ジョブログ、テスト観点、戻し手順を整理させ、人が確認する材料を作る用途に絞ると安全です。
次に確認したいAS400記事
AIレビューは最後の確認役ではなく、本番反映前にAS400基本、障害時の戻し方、確認コマンドを漏れなく見るための補助として使います。
AIレビューは本番反映の代替ではなく確認漏れ防止に使う
本番反映前にAIでレビューする時は、「問題なし」と言わせるためではなく、確認漏れを拾うために使います。AS400の改修では、対象ソース、更新ファイル、夜間バッチ、戻し手順、帳票、EDI、締め処理への影響を分けて渡すと、抜けやすい観点が出やすくなります。
- 変更したソースだけでなく、呼び出し元と後続処理も確認する
- テスト済み条件と未確認条件を分ける
- 戻し手順が「元に戻す」だけになっていないか見る
- AIの指摘は人がジョブログ・実データ・業務影響で確認する
AI提案を本番反映前に検証する例
AIがRPGやCLの修正案を出しても、対象環境のファイルレベルや呼び出し条件までは保証しません。提案を差分として扱い、人が検証します。
| 確認点 | 確認内容 | 判断 |
|---|---|---|
| コンパイル | 参照ファイル、コピー句、バインド、コンパイル一覧を確認する | 警告を無視せず既存版との差を読む |
| 実行条件 | パラメータ、ライブラリリスト、権限、コミット制御を確認する | テスト成功を本番条件へそのまま当てはめない |
| 戻し | 旧オブジェクト、ソース、反映順、切戻し条件を準備する | 承認者が不在なら反映を延期する |
AI回答はレビュー観点を増やす材料です。最終判断には、実機テスト、既存ソース、ジョブログ、業務担当の受入結果を使います。