INSIGHT
AIの修正案を、そのまま業務データへ上書きするな——変わる範囲と戻し方を確かめる
AIの修正案を上書きする前に、何が変わり、どう元へ戻せるか説明できるか。
取引先名の表記が間違っている。AIに頼むと画面はすぐ直せた。続けて、過去のデータもまとめて直す修正案が出てきた。見た目は同じ修正に見えるが、過去の請求、当時の承認、外部へ送った記録まで同じ名前へ変えてよいかは、別の判断である。
蓄積したデータは、画面に表示する文字だけではない。ある時点で誰が何を決めたか、別の記録と何で結び付くか、後からどう説明するかを支えている。
記録の意味、関連する仕事、変更前へ戻す方法を説明できないなら、AIの修正案を本番データへ実行してはいけない。
表示名と、記録を識別する値を切り離す
取引先名、商品名、担当者名のように人が読む値は変わる。一方、注文、支払い、問い合わせを同じ対象へ結び付けるには、変わりにくい識別子が必要になる。
たとえば取引先の表示名を直したつもりでも、名称そのものを識別に使っていれば、過去の請求と現在の取引先が切れるかもしれない。二つの取引先を統合する変更なら、片方の番号を消すことで、以前の問い合わせがどちらに属したか分からなくなる場合もある。
変更前に、画面で見える値、記録を結ぶ識別子、関連する表やファイル、外部へ渡している値を分ける。「何を新しい値にするか」だけでなく、「何は変えずに残すか」を業務責任者と決める。名称の訂正、対象の統合、過去記録の訂正は、同じ置換として扱わない。
過去値を消す前に、履歴として必要かを問う
誤字なら古い値は不要に見える。それでも、その表記で発行した帳票や顧客とのやり取りが残っていれば、当時の記録と照合する手掛かりになる。契約条件や承認結果の変更なら、以前の状態を消すことで「その時点で何を根拠に処理したか」が読めなくなる。
変更方法には複数ある。表示だけを新しくする。新旧の対応表を持つ。訂正記録を追加し、元の値も残す。対象を統合しても、旧識別子から新しい対象をたどれるようにする。どの方法が合うかは、問い合わせ、集計、監査、再計算など、後から必要になる仕事で決める。
変更履歴は、担当者の失敗を記録するためではない。誰が、いつ、どの対象を、何の理由で変え、どの結果を確認したかを次の担当者へ渡すためにある。変更前の件数と値を追えないなら、一括変更の結果が正しかったかも確かめにくい。
いまの画面が正しく見えることは、過去の意味と他の記録との対応が保たれた証拠にはならない。
実行する条件と、結果を照合する条件を分ける
一括変更の作業には、二つの条件が要る。一つは、どの記録を変更対象として選ぶか。もう一つは、変更後に何を見て正しいと判定するかである。
「旧名称と一致する行を更新する」という実行条件だけでは、表記揺れ、すでに訂正済みの記録、別の対象に同じ名称が使われる場合を見落とす。照合条件には、対象件数、除外件数、識別子ごとの新旧対応、関連する請求や集計の結果、外部連携へ送る値を置く。実行前に対象一覧を出し、業務担当が意図した範囲と合うかを見る。
許可されたデータを使い、本番と同じ構造を持つ検証環境で試し、変更前後の件数と関連を比較する。本番へ段階的に適用する場合も、対象・影響・戻し方を確認し、所定の承認を得てから行う。少数なら無断で試してよい、という意味ではない。成功・失敗の表示だけで終えず、一部だけ更新された場合を検知できる記録も残す。
対象一覧を承認してから実行するまでに、別の担当者が対象を追加・訂正する場合もある。確認した一覧と実行時の対象が違えば、その承認をそのまま流用しない。更新を一時的に止める時間を設けるか、実行直前に差分を取り直すかを決めておく。
NISTのSecure Software Development Framework は、設計、レビュー、コードの検証、部品の来歴、公開後の脆弱性対応などを扱う。個別のデータ変更を許可する基準でも、AI生成コードの品質保証でもない。変更の作成と検証を別の仕事として残す一般的な枠組みとして参照できる。
「バックアップがある」ではなく、変更を戻して確かめる
戻す方法は、変更を実行する前に試す。どの時点のデータへ戻すか、今回の対象だけを戻せるか、変更後に入った正しい処理をどう扱うか、誰が復元と業務確認を担当するかを決める。
AWS Well-Architectedの復元確認に関する資料 は、復元を定期的に実施し、データの内容、利用可否、復元時間を業務の目標と比べる考え方を示す。AI固有の事故率や、自社に必要な復元時間を示す資料ではない。管理画面にバックアップがあることを、今回の変更を戻せる証拠にしないための補助線になる。
検証では、本番を傷つけない場所に変更前の状態を戻し、対象件数、関連記録、権限、主要な業務を確かめる。全体復元しかできないなら、今回の変更後に入った正しい記録を失わずに戻す方法も要る。切戻しが別の大きな変更になるなら、その影響も実行前の判断に含める。
本番へ適用する前に、変更対象と戻し方を渡す
本番の上書き・削除を伴う変更は、次の五つを示せるまで止める。
- 変更する値と、残す識別子・過去値・履歴が決まっている。
- 同じデータを使う画面、集計、帳票、外部連携への影響を追えている。
- 対象抽出の条件と、変更後の照合条件を別々に確認している。
- 実行者、業務確認者、承認者が決まり、操作記録が残る。
- 失敗を検知し、変更前へ戻して業務を確認できる。
そろわない場合は、表示だけの修正、新しい欄や対応表の利用、対象の限定など、影響を狭める案を業務担当へ相談する。これらも本番への変更なら、必要な確認と承認を省略しない。一括更新の便利さを先に取りにいかず、履歴を残せる方法を選ぶ。
修正案ができても、適用は別の仕事である。変更前の状態と差分を残し、誰が範囲と結果を確認するかを決めてから実行する。
変更範囲と確認結果をそろえ、適用を判断する担当者へ渡す
画面の文言は、いま見える結果で確かめやすい。蓄積したデータは、過去と現在、別の仕事同士を結ぶため、同じ感覚では直せない。
実行する前に、変更前の状態、対象一覧、変更後に確かめる結果を並べる。そのうえで、業務確認と適用を認める担当者へ渡す。自分で決めてよい範囲が分からなければ、AIの修正案は案のまま止める。この順序で、速く作れた修正を、説明できる変更へつなげる。