AS400 / IBM iのジョブログは、最後のエラーだけ見ても原因が分からないことがあります。Codexを使うと、MSGW（メッセージ応答待ち）、CPF、RNX（RPG実行時エラーのメッセージID）、呼び出し順、直前のメッセージを整理し、確認順を作る助けになります。
ただし、ジョブログにはユーザーID、ライブラリ名、取引先名、実データが含まれることがあります。外部へ出してよい情報かを確認し、必要な部分だけマスクして使います。
プロンプト例
以下はAS400のジョブログ抜粋です。 機密情報はマスク済みです。 1. 何が起きたか 2. 最初に見るべきメッセージID 3. MSGW、CPF、RNXの関係 4. 原因候補 5. 追加で確認するコマンド 6. 業務担当者へ確認すること 7. 再実行してよいか判断する前の注意点 を整理してください。 分からない点は断定せず、質問として列挙してください。
要約後に人が見ること
- 原因メッセージと結果メッセージを分ける
- どのCALLやCLで止まったかを見る
- MSGWに勝手に返答しない
- 業務影響を確認する
- 再実行や戻しの承認を取る
Codexで調査時間を減らす全体像は、AS400保守でCodexを使い調査時間を減らす実例も確認してください。
ジョブログ要約は「原因候補」と「次の確認」を分けて出す
ジョブログをCodexに要約させる時は、メッセージを貼って短くまとめるだけでは不十分です。MSGW、CPF、RNX、権限エラー、ファイル未検出、ロック、桁あふれのように、原因候補と次に人が確認することを分けて出させると、現場で使える形になります。機密情報や実データを入れず、メッセージID、発生順、処理名を一般化して渡すのが安全です。
| 要約させる観点 | 出力させる内容 | 注意点 |
|---|---|---|
| 最初の異常 | 最後のメッセージだけでなく、最初に崩れた箇所を探す | 最後のCPFだけで断定しない |
| 原因候補 | 権限、ファイル、ロック、データ、ライブラリリストに分類する | 推測と事実を混ぜない |
| 次の確認 | WRKJOB、DSPJOBLOG、DSPLIBL、WRKOBJLCKなどを見る順番を出す | 本番操作は社内手順に従う |
| 再実行可否 | 二重送信、二重計上、締め後更新の危険を確認する | 再実行前に承認を取る |
| 共有メモ | 運用担当、開発担当、業務担当に渡す要点を分ける | 個人情報や顧客名を入れない |
Codexを使う価値は、ジョブログを読む作業を丸投げすることではなく、調査の抜けを減らすことです。人が最終判断する前提で、原因候補、確認コマンド、業務影響、再実行可否を整理すれば、若手の調査メモも読みやすくなります。研修では、ジョブログの貼り方ではなく、貼ってはいけない情報、要約後に人が見るポイント、チームに共有する形式まで含めて扱うと実務に近づきます。
まとめ
AS400ジョブログをCodexで要約する時は、機密情報をマスクし、原因候補と確認順を整理する用途に使います。AIの回答をそのまま実行せず、人が業務影響と再実行可否を判断します。
関連するAS400確認ルート
Codexでジョブログを要約する場合も、MSGW、CPF、RNX、直前の業務操作を分けて渡すと精度が上がります。AI任せではなく、AS400の調査順に沿って使うのが現場向きです。
ジョブログをそのまま貼らず、見る範囲を指定する
Codexにジョブログを読ませる時は、ログを丸ごと貼るより、前後の範囲と確認したい観点を指定した方が役に立ちます。私は、メッセージID、発生時刻、ジョブ名、直前の処理、業務影響を分けてから、原因候補と次に見るコマンドを出してもらう形にします。
以下はAS400のジョブログから抜き出した内容です。 顧客名、実ユーザー、接続先、金額、個人情報は伏せています。 確認したいこと: 1. 最初に原因として疑うメッセージ 2. 結果として出ているだけのメッセージ 3. 次に確認するAS400コマンド 4. 業務担当へ確認すべきこと ログ抜粋: （ここに前後10〜30行程度を貼る）
重要なのは、Codexの要約をそのまま結論にしないことです。ジョブログの前後、対象ファイル、ライブラリリスト、再実行可否を人が確認してから、調査メモとして整える使い方が安全です。