AS400本番障害の初動対応チェックリスト｜環境確認・影響範囲・ジョブログ調査の順番

AS400 / IBM i の本番障害で一番大事なのは、最初の数分で焦って変な作業をしないことです。本番で障害が起きると、早く直したい気持ちが先に出ます。ですが、環境を見ずにコマンドを打つ、ジョブログを見ずにジョブを止める、MSGW（メッセージ応答待ち）にDやGを返す、SQLで対象ライブラリを間違える、といった初動ミスは二次災害につながります。

このページでは、AS400の本番障害が起きた時に、まず何を確認し、どの順番で調査するかをチェックリスト形式で整理します。販売管理システムのように、受注、出荷、在庫、売上、請求、店舗連携、物流連携がつながっている現場では、技術的なエラーだけでなく業務影響を見ながら判断する必要があります。

本番障害の初動で見る順番

自分が本番対応で最初に確認する順番は、作業者、バックアップ、環境です。誰が何をするかを明確にして、必要なバックアップや戻し方を考え、最後にライブラリリストや対象ファイルなどの環境を確認します。ここを飛ばす人は危ないです。

順番	確認項目	見る理由	関連記事
1	作業者	誰が何を実行するかを明確にする	本番対応の注意点
2	バックアップ	失敗時に戻せる状態か確認する	データリカバリー確認手順
3	環境	本番/テスト、ライブラリリスト、対象ファイルを間違えない	ライブラリ確認
4	影響範囲	受注、出荷、在庫、外部I/Fなど業務影響を見る	夜間バッチ障害対応
5	ジョブログ	原因メッセージと結果メッセージを分けて読む	ジョブログ確認手順
6	MSGW	D/Gなど危険な返答を勝手に返さない	MSGW返答判断表

1. まず作業者を決める

本番障害では、複数人が同時に触ると危険です。誰が画面を見るのか、誰がジョブログを確認するのか、誰が顧客や現場へ連絡するのか、誰が実行担当なのかを決めます。作業者が曖昧なまま進めると、同じジョブを二重に再実行したり、別の人が先にメッセージを返したりすることがあります。

若手に任せる場合でも、最初から単独で本番を触らせるのは避けた方が安全です。画面右上のマシン名を見ていない、本番とテストを勘違いする、F4で入力内容を確認しない、といったミスは実際に起こります。まずは上長やメンバーと作業範囲を合わせます。

2. 本番環境とテスト環境を間違えない

本番対応で一番怖いのは、環境を間違えることです。テスト環境だと思って本番でCLRPFMを実行する、逆に本番だと思ってテスト環境を見て「データがない」と判断する、といったミスは致命的です。画面右上のシステム名、ジョブ情報、ライブラリリスト、対象ファイルを確認します。

確認例:
DSPLIBL
WRKOBJ OBJ(TESTLIB/TEST001R) OBJTYPE(*PGM)
DSPFD FILE(TESTLIB/TESTFILE)
DSPFFD FILE(TESTLIB/TESTFILE)

特にSQLでデータ修正する時は、指定するライブラリ名が一番怖いです。目視確認しかない場面もありますが、だからこそ実行前にメンバーと手順をレビューします。自分だけで「たぶん合っている」と判断しない方が安全です。

3. 影響範囲を先に見る

本番障害では、技術的な原因調査と同時に、業務影響を見ます。販売管理システムなら、まず受注系、発注系、出荷系が動くかを確認します。バックオフィス系は後回しにできることもありますが、商品がお客様に届くところ、外部連携が止まるところは優先度が高いです。

業務領域	止まると怖いこと	初動で見ること
受注	注文処理や出荷指示に影響する	受注データ作成、後続バッチ、I/F
出荷	物流側へデータが渡らない	出荷指示、帳票、物流連携
在庫	引当や在庫数に差異が出る	在庫引当、更新件数、対象ファイル
売上・請求	計上や請求に影響する	二重計上、未計上、会計連携
外部I/F	相手先や店舗に影響する	送受信履歴、再送可否、連携ファイル

障害時にできるPMは、まず状況を確認して、止血を暫定対応で止め、後で本格対応へ持っていきます。だめな対応は、その場しのぎで変な処置をして、あとで二次災害につなげることです。

4. ジョブログで原因を追う

障害調査では、ジョブログを見ます。最後に出ているエラーだけで判断せず、重大度、メッセージID、プログラム名、ファイル名、ライブラリ名、エラー前後の流れを確認します。CPF、RNX、MCHなどの種類を見て、どこで落ちたのか、なぜ落ちたのかを追います。

見るポイント:
・ジョブ名 / ユーザー / 番号
・メッセージID
・重大度
・プログラム名
・対象ファイルとライブラリ
・エラー直前の処理

原因メッセージと結果メッセージを分けることが大切です。最後に出ているエラーが本当の原因ではなく、その前に出ているファイルオープンエラー、数値エラー、権限エラー、ロックなどが原因になっていることがあります。

ジョブログの具体的な読み方は、AS400のジョブログ確認手順 と AS400ジョブログ実例集 にまとめています。

5. MSGWは勝手に返さない

本番障害でMSGWが出ている時は、返答がその後のリカバリーに影響します。Cはキャンセル、Iは無視、Rはリトライ、Dはダンプを取ってキャンセル、Gは後続へ進める系の危険な返答です。特にDやGは、リトライで復旧できた可能性を消したり、落ちた処理を強引に進めたりすることがあります。

MSGWを見つけた若手には、まず上長に報告させます。焦って勝手にDを返す、4番でジョブを強制終了する、といった対応は避けます。メッセージをどう返すかは、ジョブログ、業務影響、再実行可否を見たうえで判断します。

6. データリカバリーが必要か判断する

本番トラブルでは、データリカバリーが必要になることがあります。まず見るのは影響範囲です。対象ファイルは何か、どこまでデータが作られたか、後続処理が動いたか、再実行できるか、SQL修正が必要かを考えます。

リカバリー作業では、手順を箇条書きにしてメンバーに見てもらいます。確認項目を一つずつ点検します。SQLで修正するなら、更新先のライブラリを必ず確認します。ファイル丸ごとバックアップを取る場合もあれば、リハーサル済みでバックアップを取らない場合もありますが、いずれにしても「戻せるか」「二重処理にならないか」を確認します。

本番障害の初動チェックリスト

チェック	確認内容
作業者	誰が画面操作し、誰が確認し、誰が連絡するか決めたか
環境	本番/テスト、システム名、ライブラリリストを確認したか
対象	対象プログラム、対象ファイル、対象ライブラリを確認したか
影響範囲	受注、出荷、在庫、外部I/F、翌日業務への影響を見たか
ジョブログ	最後のエラーだけでなく、前後の流れを見たか
MSGW	D/Gを勝手に返していないか
再実行	再投入して二重処理にならないか確認したか
リカバリー	更新内容、戻し方、レビュー担当を決めたか
共有	ジョブ名、ユーザー、番号、メッセージID、判断内容を共有したか

若手に伝えたいこと

本番対応で若手に伝えたいのは、「焦るな。落ち着け」です。手が滑って変なことをしそうな時ほど危ないです。単体テストを怠るな、納品先は上司ではなくエンドユーザーを意識しろ、運用を意識した作りにしろ、という話と同じで、本番対応も最終的には業務を止めないために行います。

AS400は古臭い画面に見えるかもしれませんが、基幹システムの心臓部として動いていることがあります。だからこそ、本番障害では派手な対応よりも、環境確認、影響範囲確認、ジョブログ確認、レビュー、落ち着いた実行が大切です。

関連して読む記事

• AS400本番対応の注意点
• AS400夜間バッチ障害対応フロー
• AS400のデータリカバリー確認手順
• AS400のジョブログ確認手順
• AS400 MSGW返答判断表
• AS400メッセージID・エラーコード一覧

AS400が遅い時の切り分け

画面、バッチ、帳票、SQLが遅い時は、AS400が遅い時の確認手順 を確認してください。WRKACTJOB、ジョブログ、MSGW、スプール、データ量、抽出条件を順番に見ます。

ロック待ち・LCKWを確認する

LCKWやロック待ちでジョブが進まない時は、AS400のロック待ち確認手順 を確認してください。WRKACTJOB、WRKOBJLCK、ジョブログ、対象ファイル、業務影響を順番に見ます。

MSGWでジョブが止まった時

ジョブがMSGWで止まっている時は、すぐ返信する前に AS400のMSGW対応手順 を確認してください。ジョブ名、メッセージID、ジョブログ、応答候補、業務影響を残してから判断すると、保守会社や開発担当へ説明しやすくなります。

印刷できない・スプールが出ない時

帳票が印刷されない、スプールがOUTQ（出力待ち行列）に溜まる、ライターが止まる場合は、AS400で印刷できない時の確認手順を確認してください。WRKSPLF、WRKOUTQ、OUTQ、ライター、プリンター装置を順番に切り分けます。

通信・ネットワーク・TCP/IPで困った時

5250、FTP、外部連携、ACS接続で通信が疑わしい時は、AS400のTCP/IP通信トラブル確認手順を確認してください。PING、NETSTAT、WRKTCPSTS、VPN、DNS、ポートを分けて見ると、AS400側かネットワーク側かを説明しやすくなります。

FTP転送・CSV連携で困った時

FTP転送できない、IFS（統合ファイルシステム）に置けない、CSVが文字化けする場合は、AS400でFTP転送できない時の確認手順を確認してください。通信、ログイン、権限、IFSパス、文字コード、バッチ実行環境を分けて見ます。

関連: サブシステム停止・開始を伴う作業は、対象業務、JOBQ、WRKACTJOB、QSYSOPR、DSPLOG/QHSTを確認してから進めます。事故を防ぐ確認ポイントは AS400 サブシステム停止・開始の確認ポイント にまとめています。

関連: 障害調査で問題ログも確認したい場合は、WRKPRB・ANZPRBの確認ポイント に、問題番号、発生日時、メッセージID、QSYSOPR、DSPLOG/QHSTと合わせて見る観点を整理しています。

関連: MSGWや夜間バッチ停止を早く見つけたい場合は、MSGWを早期検知してメール通知する考え方 で、検知対象、通知先、返信判断、業務影響を整理してください。

障害記録としてWRKPRBまで確認しておく

ジョブログ、QSYSOPR、DSPLOG/QHSTで初動確認をしたあと、保守会社へ相談する可能性がある場合は WRKPRB / ANZPRB の問題ログ確認 まで進めておくと、発生日時、問題番号、関連メッセージ、未対応状態をそろえやすくなります。障害対応では「何を見たか」が後から効くため、確認順をメモに残してください。

関連: AS400保守でAIやCodexを安全に使う実務記事として、AS400障害調査でCodexに渡すプロンプト例｜ジョブログ・MSGW・業務影響を整理する も追加しました。

初動で迷ったら、復旧方針ごとに確認先を分ける

本番障害では、最初から原因を当てにいくよりも「止まっているのか」「返信待ちなのか」「データを戻す可能性があるのか」「外部連携が絡むのか」を分ける方が早くなります。ここを曖昧にしたまま調査を広げると、ジョブログ、MSGW、バックアップ、ジャーナル、EDIの確認が散らかります。

初動で見えた状態	先に確認すること	次に読む記事
全体像を整理したい	発生時刻、影響範囲、担当者、後続処理	AS400保守・運用完全ガイド
ジョブが応答待ち	MSGW、QSYSOPR、返信候補、業務影響	MSGWジョブの確認手順
返信してよいか判断したい	ジョブログ、直前メッセージ、後続処理、リラン可否	MSGW返信判断表
データを戻す可能性がある	バックアップ、更新前後、対象キー、復旧後確認	AS400データ復旧手順
更新履歴を追う必要がある	ジャーナル、DSPJRN、更新前レコード、更新後レコード	ジャーナルとDSPJRNの確認手順
取引先や外部連携が絡む	送受信時刻、相手先、再送、締め処理、業務連絡	EDIトラブルの業務影響

現場では、技術的な正解だけでなく「誰に、どの時点で、何を伝えるか」も復旧品質に影響します。初動メモに発生時刻、確認済みコマンド、判断者、次の作業を残しておくと、保守会社や外部パートナーへ引き継ぐ時も話が早くなります。

まとめ

本番障害の初動では、作業者と対象環境を固定し、業務影響、ジョブログ、MSGW、後続処理の順に確認します。原因が分からない段階で強制終了やリランへ進まず、復旧条件と確認方法をそろえてから実行します。