AS400障害調査でCodexに渡すプロンプト例｜ジョブログ・MSGW・業務影響を整理する

2026.06.11

AS400 / IBM i の障害調査でCodexを使う時は、ソースや顧客情報をそのまま貼るのではなく、調査に必要な情報だけを整理して渡します。特に本番障害では、ジョブログ、MSGW（メッセージ応答待ち）、処理名、業務影響、再実行可否をそろえるだけで、調査の抜け漏れを減らせます。

Codexに渡す前に整理する情報

項目書く内容注意点
現象何が止まったか、誰が困っているか感想ではなく事実で書く
ジョブログ異常直前から直後のメッセージ顧客名、品番、金額はマスクする
MSGWメッセージID、応答候補、対象ジョブ勝手に応答した内容を混ぜない
業務影響出荷、請求、在庫、締めへの影響技術用語だけにしない
制約本番変更可否、再実行可否、締め時刻やってよいことを明確にする

そのまま使えるプロンプト例

「AS400 / IBM i の本番障害調査です。以下のジョブログとMSGWを見て、原因候補、追加で確認すべきコマンド、業務影響、再実行前の注意点を表で整理してください。機密情報はマスク済みです。断定せず、確認順を優先してください。」

この形にすると、Codexは原因を一発で決めつけるのではなく、確認順の整理役として使いやすくなります。若手担当者にも「次に何を見るか」を説明しやすく、属人化した障害対応の棚卸しにも使えます。

研修につなげる観点

現場でAIを使うには、プロンプトの書き方だけでなく、機密情報の扱い、レビュー手順、回答を鵜呑みにしない確認文化が必要です。研修では、実際のジョブログやMSGWを題材に、調査時間を減らす使い方を練習します。

障害初動は AS400本番障害の初動対応、ジョブログの読み方は AS400ジョブログの読み順、研修相談は AS400 / IBM i 現場向けCodex実戦研修 を確認してください。

関連: AS400保守で使うAIプロンプト集｜ジョブログ・RPG解析・影響調査を早く整理するもあわせて確認してください。

障害調査プロンプトは、技術情報と業務影響を分けて渡す

AS400保守でCodexに障害調査を手伝わせる時は、ジョブログ、メッセージID、実行ジョブ、対象ファイルのような技術情報と、出荷、請求、EDI、夜間バッチへの業務影響を分けて渡すと整理しやすくなります。研修では、この分け方を現場の報告に使える形で練習します。

  • ジョブログを要約させる前に、発生時刻と対象ジョブを固定する
  • 技術原因と業務影響を別見出しで出させる
  • 未確認事項を残し、人が判断すべき点を分ける

障害調査プロンプトは、技術情報と業務影響を同じ箱に入れます

CodexにAS400障害調査を手伝わせる時は、メッセージIDやジョブログだけではなく、どの業務が止まったか、締め前か、EDI相手先がいるか、帳票や出荷に影響するかを一緒に渡します。現場で欲しいのは、正解らしい説明よりも、次に何を確認するべきかです。プロンプトを固定化しておくと、若手や外部要員でも調査の入口をそろえやすくなります。

障害調査プロンプトの記入例

Codexへ渡す内容は、事実、制約、求める出力に分けます。次の形なら回答の根拠を追いやすくなります。

確認点確認内容判断
事実伏字化したMSGID、送信元、前後5件、ジョブ状態、発生時刻見ていない情報を推測で補わない
制約本番実行禁止、データ更新案は影響と戻しを併記、秘密値禁止危険な操作を回答から分離する
出力原因候補、確認順、各候補を否定する条件、追加質問人がジョブログとソースで検証する

回答を採用した場合は、どの提案をどの根拠で採用したかを調査記録へ残します。AIへ渡していない前提条件がある場合は、結論を確定せず再確認します。

関連するAS400確認ルート

障害調査プロンプトは、AS400基本と確認コマンドを押さえた人が使うことで、現場で判断できる調査メモになります。

スポンサーリンク