【初心者向け】AS400保守で使う調査メモの作り方｜障害対応を早くする記録術

AS400（IBM i）の保守では、調査した内容をメモに残すことがとても重要です。ジョブログを見た、ファイルを確認した、プログラムを追った、という作業を頭の中だけで進めると、同じ確認を繰り返したり、原因を見失ったりしやすくなります。

特に障害対応では、短い時間で状況を整理し、関係者へ説明する必要があります。調査メモがあると、原因の切り分け、再発防止、後日の引き継ぎがしやすくなります。

調査メモに書く基本項目

• 発生日時
• 発生した画面や処理名
• ジョブ名、ユーザー、ジョブ番号
• メッセージID
• 対象ライブラリ、ファイル、プログラム
• 実施した確認作業
• 一時対応と恒久対応の区別

最初からきれいな文章にする必要はありません。まずは、見たもの、試したこと、結果を時系列で残します。後から読み返したときに、なぜその判断をしたのかがわかることが大切です。

メモの例

たとえば、CPFエラーが出た場合は、次のようにメモします。

• 2026/05/22 9:15 売上更新バッチで異常終了
• ジョブ名: TEST001R、ユーザー: TESTUSR
• メッセージID: CPFxxxx
• 対象ファイル: TESTLIB/TESTFILE
• 確認結果: 対象ファイルがロックされていた
• 一時対応: ロック元ジョブを確認して再実行
• 恒久対応: 実行時間帯と前処理の見直しが必要

やってはいけないメモ

「直った」「たぶん権限」「前も同じ」だけのメモは、後から役に立ちにくいです。原因が確定していない場合は、確定情報と推測を分けて書くと安全です。

• 推測だけで原因を書かない
• 本番データや個人情報をそのまま貼らない
• 確認したコマンドを省略しすぎない
• 一時対応と恒久対応を混ぜない

よくある質問

調査メモはExcelでもテキストでもよいですか？

形式は現場のルールに合わせれば問題ありません。大切なのは、発生日時、メッセージID、対象オブジェクト、確認結果、対応内容が後から追えることです。

初心者が最初に残すべき情報は何ですか？

まずはエラー発生時刻、メッセージID、ジョブ名、対象ファイルやプログラム名を残しましょう。この4つがあるだけでも、後から状況を振り返りやすくなります。

このサイトの運営方針は、このサイトについて にまとめています。

調査メモを再発防止に使うコツ

調査メモは障害対応中だけでなく、再発防止にも役立ちます。原因、影響範囲、一時対応、恒久対応を分けて残すことで、同じエラーが出たときに短時間で判断できるようになります。

• 原因が確定している情報と推測を分ける
• 一時対応で終わらせず恒久対応の候補を書く
• 関係するファイルやプログラム名を残す
• 再実行手順と注意点を残す
• 次回確認すべきログやコマンドを残す

AS400保守では、長く使われている処理ほど資料が古くなっていることがあります。調査メモを積み上げることは、属人化を減らし、次の担当者が安全に作業するための小さなドキュメント作りにもつながります。

調査メモと本番対応をつなげて考える

調査メモは、障害原因を残すだけでなく、本番対応時に焦って誤操作しないための材料にもなります。本番作業前の確認観点は、AS400の本番対応で初心者がやってはいけないことに整理しています。

調査メモをデータリカバリーに活かす

調査メモは、原因整理だけでなく、本番データリカバリー時の影響範囲確認にも役立ちます。リカバリー作業の進め方は、AS400のデータリカバリーで焦らないための確認手順も参考にしてください。

私が調査メモで残したいこと

AS400保守の調査メモは、きれいな文章を書くためのものではありません。あとから見た時に、何を見て、何を判断して、どこまで確認したのかを追えるようにするためのものです。

特に本番障害やデータリカバリーでは、作業者の頭の中だけで進めるのが危険です。対象ファイル、対象ライブラリー、ジョブログ、実行したコマンド、確認した件数、メンバーにレビューしてもらった内容を残します。

障害: TEST001R が異常終了
確認: DSPJOBLOG で CPFxxxx / RNXxxxx を確認
対象: TESTLIB.TESTFILE
判断: 後続CLを確認し、再実行前に件数確認を実施

調査メモがあると、同じ障害が再発した時にも対応が早くなります。若手には、作業が終わってから思い出して書くのではなく、調査しながら残すように伝えたいです。

AS400の全体像から確認したい場合は、AS400総合ガイドも参考にしてください。基本操作、RPG/CL、ジョブログ、本番対応までまとめています。

調査メモは「次に何をするか」を残すために作る

AS400 / IBM i の保守で使う調査メモは、きれいな議事録を作るためのものではありません。私の感覚では、あとから見た人が「どの環境で、何を見て、何が分かっていて、次に何を確認すればよいか」を判断できるようにするためのものです。

特に販売管理システムでは、受注、出荷、在庫引当、売上計上、請求、店舗連携、物流連携がつながっています。ひとつの処理だけを見て「ここが悪そう」と決めると、後続処理や外部連携側の影響を見落とすことがあります。調査メモには、プログラム名だけでなく、どの業務処理のどこで止まっているのかも残した方が安全です。

最低限メモに残したい項目

悪い調査メモは「結論だけ」で終わっている

初心者の調査メモで危ないのは、「エラーでした」「修正しました」「再実行しました」だけで終わっているものです。これでは、何を見てそう判断したのか、どの環境で実行したのか、再発した時にどこから調べればよいのかが分かりません。

AS400の現場では、ジョブログやスプール、ライブラリリスト、対象ファイルの状態を見れば、かなりのことが分かります。だからこそ、調査メモには「見たもの」を残します。結果だけではなく、判断材料を残すのが大事です。

販売管理システムの調査メモで意識すること

販売管理の保守では、ひとつの障害が別の業務へつながることがあります。たとえば受注データの作成に失敗すると、在庫引当、出荷指示、売上計上、請求、外部連携まで影響する可能性があります。だから調査メモでは、プログラム単体ではなく「業務の流れのどこで止まっているか」を書きます。

私なら、まず商品が客に届くところに関係する処理を優先して見ます。受注、出荷、物流連携の影響が大きい場合は、バックオフィス系より先に確認します。もちろんシステムごとに違いますが、販売管理ではこの優先順位の考え方がかなり大事です。

• 受注系が止まっていないか
• 出荷指示や物流連携に影響していないか
• 在庫引当や売上計上の前後関係が崩れていないか
• 同じデータを二重処理していないか
• 後続バッチが動いてよい状態か

若手に教えるなら、メモより先に全体像を見せる

若手に調査メモを教える時は、いきなり「この形式で書いて」と言うより、先にシステム全体図や周辺システム関連図を見せた方がよいです。受注から出荷、売上、請求、会計連携までの流れが分かっていないと、メモに何を書けばよいかも分かりません。

AS400保守がうまい人は、ジョブログの1行だけで判断しません。ジョブ、プログラム、ファイル、ライブラリ、業務影響をつなげて見ます。調査メモは、その見方をチームに残すための道具です。

Codexに調査メモを手伝わせる時の使い方

Codexを使う場合は、ジョブログ、CL、RPG、ファイル定義などをそのまま丸投げするのではなく、機密情報を除いたうえで「何を整理してほしいか」を明確にします。たとえば、ジョブログのメッセージID一覧を整理する、CLの呼び出し順を表にする、影響しそうなファイル名を抜き出す、といった使い方です。

ただし、本番環境の判断をAIに任せてはいけません。最終的に責任を持つのは人間です。Codexは調査メモのたたき台や整理には便利ですが、ライブラリ名、対象ファイル、実行可否、リカバリー方針は、必ず人間がレビューする必要があります。

関連して、ジョブログの見方は AS400のジョブログ確認手順、本番作業の注意点は AS400の本番対応で初心者がやってはいけないこと、法人向けにCodex活用を学ぶ場合は AS400 / IBM i 現場向けCodex実戦研修 も参考にしてください。

次に確認するAS400保守の入口

調査メモは、障害対応の記録だけでなく、次の担当者がAS400の基本と確認コマンドへ戻れる入口として残します。

• AS400初心者向け完全ガイド
• AS400トラブル逆引き
• AS400コマンド逆引き
• AS400 / IBM i 現場向け Codex実戦研修