AS400 / IBM i の保守では、QueryやSQLで本番データを確認する場面がよくあります。便利な一方で、抽出条件を間違える、更新SQLを誤って実行する、個人情報を含むCSVを外へ出すなど、事故につながる操作でもあります。ここでは、調査担当者が安全に確認するための順番を整理します。
調査前の確認
| 確認 | 見るもの | 判断 |
|---|---|---|
| 目的 | 何を確認したいか | 件数確認か、明細確認か、原因調査か |
| 対象ファイル | ライブラリ、物理ファイル、論理ファイル | 本当に見るべきファイルか |
| 抽出条件 | 日付、コード、状態区分 | 条件漏れで大量抽出しないか |
| 権限 | 参照権限、更新権限、共用ID | 不要な更新権限で作業していないか |
| 持ち出し | CSV、Excel、メール | 個人情報や取引情報が含まれないか |
SELECTでも安心しすぎない
SELECTだけなら安全に見えますが、抽出範囲が大きすぎると性能影響が出ることがあります。締め処理中や夜間バッチ中に重いSQLを流すと、業務側では「AS400が遅い」と見えることもあります。まず件数確認、次に限定条件、最後に必要な項目だけを見る流れが安全です。
更新SQLは手順と承認を分ける
本番データを更新するSQLは、調査用SQLとは別物として扱います。実行前のバックアップ、対象件数、WHERE条件、戻し手順、承認者、実行ログを残します。1件だけの修正でも、後続処理や帳票に影響する可能性があります。
データ抽出の依頼は AS400データ抽出依頼の確認手順、SQL7008などDB2 for iの確認は SQL7008とDB2 for iの確認、権限面は AS400権限・監査チェックリスト にまとめています。
Codexへ渡す前に匿名化する
SQLの相談でCodexを使う時は、実データ、顧客名、取引先名、個人情報を入れないことが前提です。テーブル名や項目名も必要に応じて仮名にし、目的、条件、確認したい観点だけを渡すと安全です。
関連: AS400専門サイトとしての網羅性を高めるため、AS400ジャーナル・コミットメント制御の確認手順｜更新事故と戻し判断で見ること も追加しました。
関連: 25年以上の現場経験を反映した実務記事として、AS400本番データ修正の承認チェックリスト｜SQL更新・手修正で事故を防ぐ も追加しました。
関連: AS400業務トラブルの具体例として、AS400在庫差異の調べ方｜在庫照会・入出庫履歴・締め処理から原因を見る も追加しました。
