AS400本番作業チェック｜CLRPFM前に見る環境・バックアップ・戻し手順

2026.05.24

AS400 / IBM iの本番作業で怖いのは、コマンドを知らないことよりも、環境や対象を取り違えたまま更新・削除を実行することです。

特にCLRPFMやデータ更新では、ライブラリリスト、対象ファイル、バックアップ、戻し手順、作業者の役割を先に確認します。この記事では、初心者が実行キーを押す前に見る順番を、現場向けチェックリストとして整理します。

本番作業前に私が確認する順番

本番対応では、確認項目をたくさん並べるだけでは不十分です。現場では、どの順番で確認するかも大事です。私なら、まず作業者、次にバックアップ、最後に環境の順番で確認します。

順番確認するもの現場で見る理由
1作業者誰が何をするのかを先に明確にします。担当が曖昧なまま本番作業を始めると、確認漏れや二重作業が起きやすくなります。
2バックアップ失敗した時に戻せる状態かを確認します。作業前に戻し方を考えていない本番対応は危険です。
3環境ライブラリリスト、対象ライブラリ、対象ファイルを確認します。AS400ではここを間違えると、正しいコマンドでも事故になります。

初心者は、いきなりコマンドやSQLに目が行きがちです。しかし本番作業では、先に「誰が実行するのか」「戻せるのか」「どこに対して実行するのか」を固めます。ここが曖昧なまま作業すると、手順は合っていても結果が危なくなります。

本番環境とテスト環境を間違える人が見落とすところ

本番環境とテスト環境を間違える人は、単純に画面右上のマシン名を見ていないことが多いと思います。AS400の画面は似て見えるので、思い込みで作業すると危険です。

「本番のつもりでテスト機を見ていた」「テストのつもりで本番機を触っていた」という取り違えは、作業者本人が気づきにくいです。だからこそ、コマンド実行前に画面右上のマシン名、ライブラリリスト、対象ライブラリを声に出して確認するくらいでちょうどよいです。

DSPJOB
DSPLIBL
WRKOBJ OBJ(TESTLIB/TEST001R) OBJTYPE(*PGM)

特に CLRPFM のようなデータを消すコマンドでは、最低限ライブラリ名を必ず確認します。ファイル名だけを見て安心してはいけません。同じ名前のファイルが複数ライブラリにあるのがAS400の現場です。

焦っている人に本番作業を任せる時の怖さ

本番対応で焦りは禁物です。焦っている人は、手が滑って変な操作をしたり、確認を一つ飛ばしたりします。本人は急いで助けようとしているつもりでも、本番環境ではその一手が二次災害になることがあります。

若手に本番対応を任せる前に一つだけ守らせるなら、私はやはり環境確認です。どのマシンに入っているのか、どのライブラリを見ているのか、どのファイルを触るのか。ここを確認できない人に、本番の更新系作業は任せられません。

一番危ないのは、環境を取り違えることです。

テスト環境で作業しているつもりが本番環境だった。本番のつもりで確認していたら、実は検証環境だった。こういう取り違えは、慣れていない人ほど起こしやすいです。

AS400の現場では、ライブラリ名やジョブ環境、サインオン先、ライブラリリストの状態によって、見えているデータや更新先が変わります。画面の見た目が似ていると、本人は正しい環境で作業しているつもりでも、実際には別環境を触っていることがあります。

WRKLIB LIB(TESTLIB)
WRKOBJ OBJ(TESTLIB/*ALL)
DSPLIBL

上のような確認コマンドは、ただ打てばよいわけではありません。今どのライブラリを見ているのか、これからどのライブラリを更新するのかを確認するために使います。

CLRPFMのようなコマンドは特に慎重に扱う

CLRPFM は物理ファイルメンバーのレコードをクリアするコマンドです。便利な場面もありますが、本番環境で対象を間違えると大きな事故につながります。

CLRPFM FILE(TESTLIB/TESTFILE)

このようなコマンドを使う前には、少なくとも次の確認が必要です。

確認項目見る理由
サインオンしている環境本番・検証・開発を取り違えていないか確認する
ライブラリリスト意図しないライブラリが優先されていないか確認する
対象ライブラリ更新先・削除先が本当に正しいか確認する
対象ファイル同名ファイルや似た名前のファイルを取り違えていないか確認する
バックアップ戻せる状態を作ってから作業しているか確認する

初心者ほど「コマンドを覚えたら作業できる」と考えがちですが、本番対応ではコマンドそのものより、実行前の確認の方が大事です。

データリカバリーで最初に確認すること

データリカバリー作業で最初に見るべきものは、やはり環境です。

ライブラリリストを点検し、SQLでリカバリーする場合も、更新先のライブラリを必ず確認します。SQLは便利ですが、対象指定を誤ると一瞬で本番データを書き換えてしまいます。

DSPLIBL
SELECT * FROM TESTLIB.TESTFILE FETCH FIRST 10 ROWS ONLY

リカバリー時は、次の順番で考えると落ち着いて確認しやすくなります。

  1. どの環境で作業しているか確認する
  2. どのライブラリを更新するか確認する
  3. 更新前のデータを退避する
  4. 更新対象件数を確認する
  5. 作業手順をメンバーとレビューする
  6. 実行後に結果件数と業務影響を確認する

特に本番障害中は「すぐ直してほしい」という空気になります。ですが、急いでいるときほど、更新先の確認を省略してはいけません。

焦っている人がやりがちな行動

焦っている人は、とにかく急いで作業しようとします。確認を飛ばす、手順を書かない、周りに見せない、ログを残さない。こういう行動が出ると危ないです。

本番対応では、一度落ち着いて作業手順を作成し、メンバーとレビューする方が結果的に早いことが多いです。障害対応中に手順書を書く時間が惜しいと感じるかもしれませんが、手順がないまま作業して二次災害を起こす方が、はるかに時間を失います。

できるPMとできないPMの違い

本番障害時は、PMの判断によって現場の疲弊度が大きく変わります。

できるPMは、まず障害状況を確認します。そして、いきなり完全解決を狙うのではなく、まずは止血をします。暫定対応で業務影響を止め、落ち着いてから本格対応に進める方向へ持っていきます。

一方で、よくないPMは、その場しのぎの変な対応をしてしまうことがあります。目の前の問題だけを消そうとして、後で二次災害につなげてしまう。現場で一番つらいのは、このパターンです。

場面良い進め方危ない進め方
障害発生直後状況・影響範囲・優先度を整理する原因が曖昧なまま作業を急がせる
暫定対応止血を優先し、後で本格対応するその場しのぎで複雑な修正を入れる
作業指示手順と確認者を決める担当者に丸投げする
対応後原因と再発防止を整理する動いたから終わりにする

若手に守ってほしい3つのこと

若手や初心者に伝えたいことは、次の3つです。

単体テストを怠らない

単体テストは地味ですが、ここを軽く見ると後工程で必ず苦しくなります。自分が作ったものが本当に想定通りに動くのか、異常系でどうなるのか、データが0件のときにどうなるのか。最低限の確認を自分でやる習慣が大事です。

納品先は上司ではなくエンドユーザーだと考える

上司に言われた通りに作るだけでは足りません。実際に使うのはエンドユーザーです。画面、帳票、バッチ、エラー時の運用まで含めて、使う人が困らないかを考える必要があります。

運用を意識した作りにする

言われたものを言われた通りに作るだけでは、保守しづらいシステムになりがちです。障害時に調査しやすいか、ログは追えるか、再実行できるか、リカバリーしやすいか。AS400の業務システムでは、運用を意識した作りがとても重要です。

大変な現場から得られるものもある

本番稼働前後は本当に大変なことがあります。トラブルが起きれば、待ったなしでデータを直さなければいけない場面もあります。失敗すれば多くの店舗や業務に影響するかもしれない。その責任の重さで精神的に疲れることもあります。

ただ、若い頃にそういう現場を経験すること自体は、悪いことばかりではありません。もちろん無茶な働き方を肯定するつもりはありませんが、厳しい局面を経験すると、次の現場で落ち着いて動けるようになります。経験値として残るものはあります。

大事なのは、ただ耐えることではありません。何が危なかったのか、どの判断が良かったのか、どこで二次災害を防げたのかを振り返り、次につなげることです。

本番対応前のチェックリスト

本番対応の前には、最低限このチェックリストを確認しておきたいです。

  • 本番・検証・開発のどの環境で作業しているか確認したか
  • ライブラリリストを確認したか
  • 更新先ライブラリを明示しているか
  • 対象ファイル・対象メンバーを確認したか
  • 更新前データを退避したか
  • 更新対象件数を事前に確認したか
  • 作業手順を文章にしたか
  • メンバーまたは責任者とレビューしたか
  • 実行後の確認方法を決めているか
  • 戻し手順を用意しているか

本番対応を怖がっている初心者へ

本番対応は怖くて当然です。むしろ、怖さがまったくない方が危ないと思います。業務データを触る以上、緊張感は必要です。

ただし、焦ってはいけません。

あせるな。おちつけ。

本番対応で大事なのは、特別な度胸ではありません。環境を確認すること、手順を作ること、レビューすること、戻せる状態を作ること。この基本を守るだけで、防げる事故はかなりあります。

AS400 / IBM i の現場は、今でも止められない業務を支えています。だからこそ、初心者のうちから「作る力」だけでなく「安全に運用する力」を意識しておくと、現場で信頼されるエンジニアに近づけると思います。

AS400の基礎から順番に学びたい方は、AS400学習ロードマップもあわせて確認してみてください。

本番トラブルでデータリカバリーが必要になったら

本番対応中にデータ修正や戻し作業が必要になった場合は、環境確認だけでなく、影響範囲、リハーサル、ライブラリ名の確認も重要です。具体的な考え方は、AS400のデータリカバリーで慌てないための確認手順にまとめています。

AS400のWRKACTJOB画面でMSGW状態のジョブが表示されている例。PGM-TEST001Rがメッセージ待ちになっている
MSGWは、ジョブがメッセージ応答待ちになっている状態です。焦ってDを返すのではなく、ジョブログと後続処理への影響を確認してから、C、I、Rなどの応答を判断します。

本番対応では、実行前データと戻し方を先に決める

本番環境で更新・削除系の作業をするときは、コマンドを実行できることより、戻し方を説明できることが重要です。CLRPFM、UPDATE、DFU、CPYF、リラン、締め処理の再実行では、対象ライブラリ、対象ファイル、件数、承認、バックアップ、ジャーナル、再実行可否を先に確認します。

本番作業の確認順は研修でそろえておく

本番作業は、コマンドを知っているだけでは事故を防ぎきれません。対象ライブラリ、対象ファイル、バックアップ、戻し手順、作業者と確認者の分担を、毎回同じ順番で確認できる状態にしておくことが大切です。

若手や後任者へ引き継ぐ場合は、実際の画面やジョブログを見ながら「どこで止まって確認するか」を一緒に決める方が定着しやすくなります。法人向けの研修として整えたい場合は、AS400 / IBM i 現場向けCodex研修を確認し、対象業務と研修希望内容を研修問い合わせフォームから送ってください。

  • 作業前に対象ライブラリ、対象ファイル、対象メンバーを確認する
  • 更新前データをSELECT、CPYF、CSV、またはDSPJRNで残す
  • 対象件数、承認者、戻し手順、リラン条件を作業前に決める
  • EDI、請求締め、出荷確定、夜間バッチへの影響を確認する
  • 戻せる証拠がない、対象件数が想定と違う、MSGWが残っている場合は止まる

本番作業で迷った時に次に確認すること

本番対応は「早く直す」より「間違った場所を触らない」を優先します。状況に応じて、次の記事で確認対象を絞ってください。

若手や外部エンジニアに任せる場合も、「何を実行してよいか」だけでなく「どこで止まるべきか」を共有します。作業前の確認、第三者レビュー、実行後の証跡、戻し方までそろっていない場合は、無理に本番操作へ進まない方が安全です。

スポンサーリンク