AS400本番障害の初動チェックリスト｜MSGW・CPF/RNX・夜間バッチ停止で最初に見ること

2026.06.11

AS400 / IBM i の本番障害では、最初の10分で見る順番を間違えると、復旧までの時間が大きく伸びます。夜間バッチ停止、MSGW、CPF/RNX（RPG実行時エラーのメッセージID）エラー、オブジェクト未検出、ライブラリ違いは、それぞれ見る画面と判断が違います。この記事では、25年以上の現場経験を前提に、本番で慌てないための初動チェックを整理します。

目的は「すぐ原因を断定すること」ではありません。まず、業務を止めるべきか、後続処理を流せるか、担当者へ何を伝えるべきかを判断できる状態にすることです。AS400の障害対応は、ジョブログ、メッセージID、ジョブ状態、ライブラリ、データの順に見ていくと混乱しにくくなります。

初報と並行して「状況の整理」を進める

障害の連絡を受けたら、まず確認できた事象と業務影響を整理します。ただし、全容が判明するまで初報や調査を待つわけではありません。既知と未確認を分けて関係者へ連絡し、役割分担して原因調査と影響確認を並行します。

状況整理では、次の2つを更新していきます。初報で不明な点があっても、未確認として明示します。

  • 何が起こったかを把握する
  • どこに影響が出ているかを調査する

事象や影響範囲が未確定の段階では、確認できた範囲、担当者、次回連絡時刻を共有します。原因の仮説は事実と分け、証跡を保全しながら範囲を絞ります。全容確認のために必要な初動を遅らせないことが重要です。

原因より先に影響を見る

障害対応に慣れていない時は、連絡を受けた瞬間に「なぜ起きたのか」を追いがちです。気持ちは分かりますが、順番が逆です。原因が分かっても、影響範囲が分かっていなければ対処の判断ができません。

整理で出すもの具体的に見ること
何が起こったかいつ、どの処理が、どういう形で止まった／おかしくなったか
どこに影響が出ているか対象データの範囲、後続処理、外部連携、業務がいま止まっているか

影響範囲が確定すると、その後の判断がすべて決まります。戻すか、その場で直すかも、リランしてよいかどうかも、どこまで壊れているかが分からなければ「確実」と言えません。整理は、その後の判断材料を作る作業です。

業務側へは、確認済みの停止処理・影響と、まだ分かっていない点を早めに伝えます。続行や停止の判断が必要な業務と次回報告時刻も示し、判明した情報で続報を更新します。

本番障害で最初に確認する5つ

確認すること見るコマンド・画面判断すること
ジョブが動いているかWRKACTJOB / WRKJOB実行中、待機中、MSGW、異常終了のどれか
何のメッセージで止まったかDSPJOBLOG / DSPMSGCPF、RNX、MCH、MSGWの入口を分ける
後続処理に影響するかJOBQ / 投入済みジョブ / CL定義後続ジョブを流してよいか、止めるべきか
ファイル・ライブラリが合っているかDSPLIBL / WRKOBJ / DSPFFDライブラリ違い、権限、ファイル状態を切り分ける
業務影響がどこまであるか運用メニュー・締め処理・出荷処理在庫照会、請求締め、出荷確定などの影響を確認する

MSGWなら、返信より前にジョブログを見る

MSGWでは、経験が浅い時ほど「とりあえず終わらせる」と判断しやすいため注意が必要です。メッセージによっては適切に返信すれば後続処理を流せる場合があります。逆に、内容を読まずにジョブを終了すると、別途リカバリープログラムや手作業の戻しが必要になることがあります。

MSGWを見たら、まず MSGWでジョブが止まった時の確認手順 と MSGWを早期検知する考え方 を確認してください。夜間バッチで気付くのが遅れる場合は、QSYSOPRや重要ジョブのMSGWを検知してメール通知する仕組みも検討対象です。

CPF・RNX・MCHは同じエラーとして扱わない

AS400の障害調査では、メッセージIDの先頭で入口を分けるだけでも調査時間が短くなります。CPFはファイル、権限、ライブラリ、システム操作に関係することが多く、RNXはRPG実行時のデータや配列、数値変換などに関係することが多いです。MCHはポインターや低レベルの異常として見ます。

入口よく見る原因詳しい確認先
CPFファイル未検出、権限、ライブラリ違い、排他CPFエラーとジョブログ確認
RNXRPG実行時エラー、数値変換、配列、データ不整合RNX8888の確認手順
MCHプログラム異常、ポインター、呼び出し関係メッセージID・エラーコード索引
MSGW応答待ち、夜間バッチ停止、判断待ちMSGW返信判断表

ライブラリ違いは本番障害に見えやすい

本番障害に見えても、実際にはライブラリリスト違い、オブジェクト違い、テスト用ファイル参照が原因のことがあります。特に、保守担当者が変わった直後や、環境移行後、臨時対応後は、DSPLIBL、WRKOBJ、DSPFFDで「どのライブラリの何を見ているか」を確認します。

コマンドを目的から探したい場合は AS400コマンド逆引き、基本操作から整理したい場合は AS400基本操作とコマンド10選 に戻ると確認しやすいです。

業務名とジョブ名を結び付ける

現場では「プログラムが止まった」だけでは判断できません。在庫照会、請求締め、出荷確定のどれに影響するのかを確認して、業務担当者へ伝わる言葉に変換する必要があります。AS400を分かる人がいても、業務が分かる人がいないと復旧判断が遅れます。

  • ジョブ名、ユーザー、開始時刻を控える
  • 直前の正常終了ジョブと、止まったジョブを分ける
  • 締め処理・出荷処理・帳票出力など、業務影響を先に見る
  • 再実行する場合は、二重更新や二重出荷がないか確認する
  • 判断に迷う場合は、ジョブログと入力データを保全してから相談する

AI・Codexで調査時間を減らす時の注意

ジョブログ、CL、RPGソース、ファイル定義をCodexで整理すると、確認観点の抜け漏れを減らしやすくなります。ただし、本番データ、会社名、ユーザー名、取引先名はそのまま入れないことが前提です。AIは判断者ではなく、調査メモを整理する補助役として使うのが安全です。

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

販売管理では「商品が客に届くところ」を優先する

販売管理システムで本番トラブルが起きた時、私ならまず受注系、出荷系、在庫引当、物流連携を優先して見ます。バックオフィス系も重要ですが、商品が客に届くところが止まると、業務影響が一気に大きくなります。

たとえば、受注データは作られているが出荷連携が止まっている場合、画面上は受注済みに見えても、倉庫側に情報が渡っていない可能性があります。逆に、出荷は進んでいるのに売上計上が止まっている場合は、請求や会計連携に影響します。AS400保守では、プログラム単体だけでなく、業務の流れで見ることが大事です。

WRKACTJOBで見るのはMSGWと暴走ジョブ

問い合わせが来た時、AS400保守でよく使う入口がWRKACTJOBです。私はまずCPU使用率を見て、暴走しているジョブがないか、MSGWで止まっているジョブがないかを確認します。

ただし、WRKACTJOBを開いてF5で更新し続けるだけでは原因の切り分けになりません。MSGWや異常なCPU使用率を見つけたら、そのジョブの周辺状況を調べ、ジョブログを確認し、どう対応するかを考える必要があります。WRKACTJOBは眺める画面ではなく、調査の入口です。

  • MSGWのジョブがないか
  • CPUを食っているジョブがないか
  • 夜間バッチがRUNのまま残っていないか
  • DEQWやSELWなど、待ち状態が業務上問題になっていないか
  • 同じようなジョブが複数止まっていないか

WRKACTJOBの基本は、AS400のWRKACTJOBとは？MSGW・暴走ジョブ・バッチ確認で最初に見るポイントで詳しく整理しています。

まとめ

AS400の本番障害では、最初にジョブ状態、メッセージID、後続影響、ライブラリ、業務影響を分けて確認します。焦ってジョブを終わらせるより、復旧判断に必要な情報をそろえる方が結果的に早くなります。応答待ちならMSGW、原因メッセージならCPF/RNXの確認手順へ進み、判明した情報を初報・続報に反映してください。

関連する確認手順

外部へ相談する前に残す情報

本番障害は、復旧を急ぐほど情報が散らばります。AS400 / IBM i の障害を外部へ相談する場合は、ジョブ名やメッセージIDだけでなく、業務影響と確認済み事項をまとめておくと初回の切り分けが早くなります。

残す情報相談時に役立つ理由
発生時刻と業務影響どの処理が止まり、どの部署や締め処理に影響しているかを判断できます。
ジョブ名・ユーザー・画面WRKACTJOB、WRKJOB、DSPJOBLOGで追う対象を絞れます。
メッセージIDCPF、RNX、MCH、CPAなど、調査の入口を分けられます。
実施済みの対応返信、再実行、保留、キャンセルなど、二重対応を避けられます。

初動の確認順をそろえる場合は、AS400保守の初動対応とジョブログ確認手順も合わせて確認してください。復旧判断や再発防止まで相談したい場合は、AS400保守会社に相談する前のチェックリストを見た上で、お問い合わせから概要を共有できます。

スポンサーリンク