AS400 / IBM i 保守でAIを使う時は、毎回ゼロから質問を作るより、よく使うプロンプトを型にしておくと調査時間を減らせます。ここでは、ジョブログ、MSGW（メッセージ応答待ち）、RPG解析、影響調査、テスト観点の5つに分けて、現場で使いやすい聞き方を整理します。
ジョブログ調査のプロンプト
「以下はAS400 / IBM i のジョブログ抜粋です。異常終了の直接原因、直前に確認すべきメッセージ、追加で見るコマンド、業務影響、再実行前の注意点を表で整理してください。顧客名や金額はマスク済みです。」
RPG解析のプロンプト
「以下のRPGソースについて、処理概要、入力ファイル、更新ファイル、呼び出し先、条件分岐、エラー処理、業務上の注意点を整理してください。断定できない部分は不明として分けてください。」
影響調査のプロンプト
「このAS400改修で変更する画面、プログラム、ファイル、帳票、バッチ、外部連携の影響候補を洗い出してください。DSPPGMREF、DSPFFD、ジョブログ、テスト観点で確認する順番も出してください。」
テスト観点のプロンプト
「この修正の単体テスト観点を、正常系、異常系、境界値、権限、締め処理、再実行、戻し手順に分けて整理してください。AS400の本番運用で確認漏れになりやすい点も追加してください。」
詳しい障害調査の聞き方は AS400障害調査でCodexに渡すプロンプト例、RPG解析の注意は AS400 RPGソース解析をAIに手伝わせる時のチェックリスト、実戦練習は AS400 / IBM i 現場向けCodex実戦研修 を確認してください。
関連: AS400本番反映前にAIでレビューするチェックリスト｜鵜呑みにせず確認漏れを減らすもあわせて確認してください。
AS400保守のプロンプトは、用途別に分けて持つ
AS400保守で使うプロンプトは、ジョブログ要約、RPG/CLソース解析、影響調査、テスト観点、報告文の5つに分けておくと使いやすくなります。毎回ゼロから聞くより、用途別に型を持つことで調査時間を減らせます。
- ジョブログ要約: 発生時刻、ジョブ名、メッセージIDを渡す
- ソース解析: 入出力ファイル、CALL先、更新処理を抜き出す
- 報告文: 分かったこと、未確認、次の確認を分ける
- ジョブログ要約プロンプト
AIプロンプトは、AS400の業務影響を聞く形にすると現場で使えます
AS400保守でAIを使う時は、単にソースを説明させるだけでは足りません。夜間バッチ、MSGW、EDI、締め処理、帳票、影響ファイル、戻し手順まで確認する聞き方にすると、調査結果を現場で判断しやすくなります。
- RPG/CLソース解析の進め方を見る
- トラブル逆引きで業務影響から確認する
保守プロンプトへ渡す情報の具体例
AIへ「原因を教えて」とだけ頼むより、確認済みの事実と禁止事項を分けて渡す方が検証しやすい回答になります。
| 確認点 | 確認内容 | 判断 |
|---|---|---|
| 入力 | 伏字にしたメッセージID、前後のジョブログ、対象処理の目的 | 実名、顧客データ、秘密値は渡さない |
| 制約 | 本番コマンドは実行しない、推測は推測と表示する | 危険な提案をそのまま採用しない |
| 出力 | 原因候補、確認順、追加で必要な情報、戻し観点を表で求める | 回答をソース、ジョブログ、IBM資料で照合する |
プロンプトと回答は調査メモであり、変更承認書ではありません。採用した判断には、人が確認した根拠と実施者を別に残します。
関連するAS400確認ルート
AIプロンプトは便利な文例集ではなく、AS400基本、障害逆引き、確認コマンドを短時間で整理するための道具です。