UPDATE文の基本｜誤更新を防ぐ本番作業の確認手順

「WHERE句は付けたが、本番で実行するのが怖い」

「更新後に何を確認すれば、作業完了と言えるのだろう」

UPDATE文は、条件を一つ誤るだけで広い範囲のデータを変更します。本番環境では、SQL本文だけでなく、事前確認、承認、実行、事後確認、復旧を一つの作業として準備する必要があります。

安全な更新では、「たぶん1件」ではなく、同じWHERE句のSELECTで対象と件数を確認し、更新前の値を保存します。実行結果が想定どおりかを確認してからCOMMITします。

銀行システムでは、一つのステータス変更が後続バッチ、外部連携、会計処理へ影響することがあります。対象行だけでなく、業務フロー上の影響も確認しなければなりません。

この記事では、UPDATE文を本番で安全に扱うための実務手順を解説します。

UPDATEは「事前確認・実行・事後確認・復旧」で設計する
UPDATEを安全に実行する5ステップ
本番UPDATE作業票のテンプレート
よくある失敗と改善方法
若手SE向けチェックリスト
まとめ：UPDATEは戻せる準備と事後確認まで行う

UPDATEは「事前確認・実行・事後確認・復旧」で設計する

安全なUPDATE作業は、一文のSQLではなく一連の手順です。対象件数、現在値、更新後値、関連処理への影響、戻し方法を説明できる状態で承認を受けます。

作業方法、COMMIT方針、バックアップ方法は環境や運用ルールによって異なります。必ず所属組織の手順と責任者の承認に従ってください。

段階	確認内容	証跡
事前	対象・件数・現在値・影響・復旧	事前SELECT、更新前データ
実行	接続先・SQL・担当・時刻	作業ログ、画面記録
判定	更新件数・更新後値・業務結果	事後SELECT、機能確認
確定	COMMITまたはROLLBACK	承認・実行結果
復旧	戻しSQLと再確認	復旧手順、復旧後証跡

UPDATEを安全に実行する5ステップ

1．同じWHERE句で事前SELECTを実行する

UPDATEと完全に同じWHERE句を使い、対象件数と現在値を確認します。レビュー時も、SELECTとUPDATEの条件差分がないかを確認します。

対象が0件または想定より多い場合は作業を止め、条件やデータ状態を見直します。

-- 事前確認
SELECT
    transaction_id,
    status,
    update_timestamp
FROM transaction_table
WHERE transaction_id = :transaction_id
  AND process_date = :process_date
  AND status = '01';

-- 更新
UPDATE transaction_table
SET status = '02',
    update_timestamp = SYSTIMESTAMP
WHERE transaction_id = :transaction_id
  AND process_date = :process_date
  AND status = '01';

2．更新前データと戻し方法を用意する

更新対象のキーと変更前の列値を保存します。単純な戻しSQLで復旧できるか、後続処理が動いた後は追加対応が必要かを確認します。

更新時刻や更新者を戻すべきかは監査・運用要件によって異なります。自己判断で履歴情報を改変しないようにします。

3．実行直前に接続先と作業条件を再確認する

環境名、DBサービス、スキーマ、対象日時、SQL版、承認番号を声出しまたは指差しで確認します。検証環境のつもりで本番へ接続していた、という事故を防ぎます。

可能であれば実行者と確認者を分け、SQLと対象件数を相互確認します。

接続先DB・サービス名
スキーマ・利用ユーザー
対象件数・対象キー
SQLファイルの版・ハッシュ
作業時刻・後続処理停止状況
承認者・立会者

4．更新件数と更新後データを確認する

実行後はSQLクライアントが返した更新件数を記録し、事前想定と比較します。次に事後SELECTで更新値と非対象データが変わっていないことを確認します。

COMMIT前に確認できる環境では、確認完了後に責任者の判断で確定します。自動コミット設定の有無も事前に把握します。

5．業務・後続処理まで確認する

DBの値が変わっただけで作業完了とせず、画面表示、API応答、バッチ抽出、外部連携など、更新の目的が達成されたかを確認します。

作業結果、更新件数、確認内容、COMMIT時刻を記録し、関係者へ報告します。

本番UPDATE作業票のテンプレート

作業SQLと確認手順を同じ資料で管理すると、実行漏れと確認漏れを防ぎやすくなります。

【目的・承認】
作業目的：
承認番号・承認者：

【対象】
DB・スキーマ：
テーブル・キー：
想定件数：
現在値→更新値：

【事前】
事前SELECT結果：
更新前データ保存先：
後続処理への影響：

【実行・確認】
実行時刻・実行者：
更新件数：
事後SELECT結果：
業務確認：
COMMIT／ROLLBACK：

【復旧】
戻し条件・戻しSQL：

更新対象に個人情報や重要データが含まれる場合は、証跡の保存場所と閲覧権限にも注意します。

よくある失敗と改善方法

失敗	起こる問題	改善方法
WHERE句を手入力で変える	事前SELECTと更新対象がずれる	同一SQLから条件を共有し、差分確認する
更新件数だけで完了にする	更新値や業務結果の誤りを見落とす	事後SELECTと機能確認を行う
戻しSQLだけを用意する	後続処理後は単純に戻せない	業務フローと再処理方法まで確認する

若手SE向けチェックリスト

UPDATEと同じWHERE句で事前SELECTした
対象件数と現在値が想定どおりだった
更新前データを保存した
戻し方法と後続処理への影響を確認した
接続先・スキーマ・SQL版を実行直前に確認した
更新件数と更新後データを確認した
業務結果・COMMIT・作業記録を確認した

まとめ：UPDATEは戻せる準備と事後確認まで行う

UPDATE文を安全に扱うには、慎重にSQLを書くことだけでなく、対象を検証し、結果を確認し、問題時に復旧できる手順が必要です。

本番データ更新で少しでも想定と違う結果が出たら、その場で進めず作業を止め、責任者へ相談しましょう。停止判断も重要なスキルです。

同一WHERE句で対象と件数を事前確認する
更新前データと戻し方法を準備する
更新件数・値・業務結果を確認して確定する

現場で使うSQLの基本へ戻る

「現場で役立つ開発・保守の基本」シリーズトップへ戻る

UPDATE文の基本｜本番データを安全に更新する手順